- This topic has 21 replies, 2 voices, and was last updated 17 years, 7 months ago by
.
-
Posts
-
Can somebody explain what settings I need to setup JBoss 4.0.5? I’m using Eclipse 3.2.0 and MyEclipse 5.0.
Under “Paths” what directories, files, etc… do I need to include for the “Prepend to classpath”, “Append to classpath”, and “Append to library path”?
What is the JBoss IDE plugin for Eclipse? If I’m using MyEclipse do I need the JBoss IDE?
Thanks
Actually you don’t need to worry about the Paths settings at all unless you are trying to do something fancy. MyEclipse will pickup all the default libs for you. So all you need to do is set the few values on the front page of the JBoss connector, and you are done.
Ok I got it so JBoss can be started and stopped from within Eclipse. But how do I setup it up so I don’t have to do an entire deploy in order to see changes I make to my Java code?
Just use an exploded deployment. That way, as soon as you save the file, MyEclipse deploys it immediately out to your app server.
I’m switching from Resin to JBoss and I cannot get JBoss setup the same way I had Resin setup in Eclipse and MyEclipse.
Is there a support number I can call to get more help on this? Trying to explain the entire setup here is going to be difficult.
Support for MyEclipse is handled via these forums. If it helps, you can always PM me screenshots of screens that may help explain what the issue is. Just be sure to include a link to this thread in your PMs for reference.
Ok I’ll try and explain how I have Resin setup with Eclipse and MyEclipse and the problems I’m having with using JBoss.
I have two web projects in Eclipse – “admin2” and “dynamics”. They are physically located here:
admin2: F:\workspace\admin2
dynamics: F:\workspace\dynamicsThese are paths to the projects. Then inside of these directories there is another directory called webApplication. This is the directory where all the files for deployment are held. Compiled source code, JSP, HTML files, WEB-INF directory, etc…
So for admin2 the deployment files would be located:
F:\workspace\admin2\webApplication
And for dynamics it would be:
F:\workspace\dynamics\webApplication
Then I have Resin configured (using the resin.conf file) to point at the webApplication directory for each project. In the resin.conf file is where I setup the project name for each project as well. So when I start up Resin I can view the project at the following URLs:
admin2:
http://localhost:8080/admin2dynamics:
http://localhost:8080/dynamicsHaving Resin setup this way means I do not have to deploy a WAR file every time I make a change to my source code. Once I save the source code file in Eclipse it is automatically compiled and since Resin is pointed at the directory where the classes are held the changes are picked up.
Now when I use JBoss I can not figure out how to configure it the same way I have Resin configured. I want to be able to tell JBoss where the deployment files are located and what project name should be used with those files.
Can JBoss use exploded deployments without having to name the directory “.war”? If so can you tell it the name / mapping to use with those directories?
Star, yes JBoss supported exploded deployments which do exactly what you want. Just because the directory itself is named with an extension doesn’t mean it’s not exploded, that is required by the JBoss server so our deployment utility does this.
Regardless of those details however, at the end of the day you get the same behavior. As soon as a resource is modified and saved, it’s copied out to the server.
This should be working out of the box for you.
I realize JBoss supports exploded deployments and I’m currently using them.
The problem is JBoss wants all the deployment files in a directory named a certain way.
Using Resin I put all my deployment files in a directory called “webApplication” then I setup Resin to point to that directory and tell it the name / mapping to use.
Now with JBoss I can not put all my deployment files in a directory called “webApplication” for two reasons.
1. The directory does not ended in “.war”
2. JBoss uses the name of the directory for the project name / mapping. So “webApplication” would be the name of the project which is not right.Does this make sense? Do you understand the problem I’m having?
I’m not sure if this is a miscommunication or not… the problem you are having is because you are trying to avoid using the MyEclipse deployment tool, which will do all this for you automatically.
When you create a new web project, or convert a java project to a web project, you are asked for the “Web Root directory”, this directory maps perfectly to your “webApplication” directory. So when you go to deploy your application to your app server, MyEclipse takes that Web Root directory and deploys it out to your app server under the context name you gave it, like /myapp
So you get exactly the same end result…
Given that, I’m trying to understand if this is a misunderstanding (e.g. didn’t know about the deployment step) or if you know about it, hate it, and just want to skip using it even though it ends up with the same end result? Once I understand that, I think I can address your concerns more effectively… atleast I hope so.
For developing I do not use the deployment tool at all. It takes too long to compile everything and move the files to another location every time I make a JSP, HTML, etc… change.
I have the application server point directly at the “webApplication” directory where all the WEB-INF directory, class files, etc…. are located. This way when I save a file the changes are picked up right away.
For developing I do not use the deployment tool at all.
Then this question is a JBoss-specific configuration question, and I cannot help with that.
It takes too long to compile everything and move the files to another location every time I make a JSP, HTML, etc… change.
This only happens the first after with an exploded deployment. After that, every time something changes it’s immediately copied out.
This way when I save a file the changes are picked up right away.
This is the identical behavior you get when using an exploded deployment.
