Setting up JBOSS 5 Server on my local computer

[maflatoun]

Hi all,

I've just started playing around with Java (day 2) since our company
(bought out) is moving away from asp.net. I've installed Eclipse and
JBOSS. Following the instructions on a few 'hello world' apps works
fine however, every time you make a change you have to jar.exe -cvf
helloworld.war. *.jsp...etc. I'm pretty sure on a local server that's
a lot of work every time you modify your .jsp (presentation layer)
since when I'm doing ASP.NET or PHP I make 100+ changes to my
presentation layer and all I press is refresh button in the browser
and see my changes. How can I do same thing using JBOSS. How can I
create a folder and copy all the necessary files (compile java
classes) but keeping my .jsp pages separate so that I can (on the
development server) test my .jsp pages before packaging them all
together. I'm sure it's possible because on the jboss server I can go
to some of the administration pages
eg. http://localhost:8080/web-console/ServerInfo.jsp and modify the
ServerInfo.jsp page directly and press refresh to see my changes.
Also, can someone please explain the steps to set up Eclipse with
JBOSS 5? so that when I run my code in Eclipse I can view it my
browser? similar to ASP.NET.

Thank you and I really appreciate your help since I've never been any
more confused.
Maz

 

[Tom Anderson]

I've just started playing around with Java (day 2) since our company
(bought out) is moving away from asp.net. I've installed Eclipse and
JBOSS. Following the instructions on a few 'hello world' apps works fine
however, every time you make a change you have to jar.exe -cvf
helloworld.war. *.jsp...etc. I'm pretty sure on a local server that's a
lot of work every time you modify your .jsp (presentation layer) since
when I'm doing ASP.NET or PHP I make 100+ changes to my presentation
layer and all I press is refresh button in the browser and see my
changes. How can I do same thing using JBOSS. How can I create a folder
and copy all the necessary files (compile java classes) but keeping my
.jsp pages separate so that I can (on the development server) test my
.jsp pages before packaging them all together. I'm sure it's possible
because on the jboss server I can go to some of the administration pages
eg. http://localhost:8080/web-console/ServerInfo.jsp and modify the
ServerInfo.jsp page directly and press refresh to see my changes. Also,
can someone please explain the steps to set up Eclipse with JBOSS 5? so
that when I run my code in Eclipse I can view it my browser? similar to
ASP.NET.

It requires a simple trick. After you give the WAR or EAR to JBoss to
deploy, it expands it into a folder hierarchy. You find the folder that
holds the JSP sources, delete it, and symlink it to the corresponding
folder in your Eclipse project. When you update the JSPs in Eclipse, JBoss
will notice that 'its' copy of the page has changed, and recompile it. You
can also link in Eclipse's build folder in the same way, so changes to
your java code are live.

I can't remember if there are any special flags you need to give JBoss to
make it sensitive to the changes. I don't think so, BICBW.

We have a shell script used to start our app which builds the EAR, deploys
it into JBoss, then does the symlinking, so we can do all this
automatically.

You can also deploy a folder tree rather than a WAR - you just copy it in
as if it were a WAR. I imagine a symlink would work too, in which case all
you need to do is symlink the right bit of your Eclipse project (which has
to be laid out in the right way) into JBoss's deploy folder.

It sounds like you're on Windows. Does Windows have symlinks? If not,
you'll have to do all this the other way round, and change the settings of
your Eclipse project to use the expanded WAR/EAR as the folder for JSPs.

tom

 

[Donkey Hottie]

Also, can someone please explain the steps to set up Eclipse with
JBOSS 5? so that when I run my code in Eclipse I can view it my
browser? similar to ASP.NET.

I don't have much experience with Eclipse, but I guess it works the same
there.

I use Netbeans. I register my server into it, I create a Web Application
Project, put my jsp pages and java code into it, and run it.

IDE starts the server, deploys the classes and jsp pages in a WAR to the
server, and starts a browser.

All I have to do is command "run" or "debug", and it runs.

No need for manual jar commands. IDE does it all.

 

[Lew]

It requires a simple trick. After you give the WAR or EAR to JBoss to
deploy, it expands it into a folder hierarchy. You find the folder that
holds the JSP sources, delete it, and symlink it to the corresponding
folder in your Eclipse project. When you update the JSPs in Eclipse,
JBoss will notice that 'its' copy of the page has changed, and recompile
it. You can also link in Eclipse's build folder in the same way, so
changes to your java code are live.

I rate this as bad advice. First of all, you're linking source to JBoss,
instead of built artifacts. Second, you're bypassing the JBoss deployment
process and subverting its setup. This runs the risk of not being able to
deploy the project to a test or production site, because all one will know is
how to run directly from development artifacts.

It is better to register the server with Eclipse and use the "Run As... / Run
on Server" deployment options in Eclipse to deploy the app to the JBoss
instance, or to use JBoss's own deployment tools to deploy the WAR or EAR
files you build with Eclipse. Do not symlink your Eclipse workspace into JBoss's.

Yecch.

 

[Tom Anderson]

I rate this as bad advice. First of all, you're linking source to JBoss,
instead of built artifacts.

Why is that a problem? Indeed, if you're linking JSPs, is there any other
way?

Second, you're bypassing the JBoss deployment process and subverting its
setup. This runs the risk of not being able to deploy the project to a
test or production site, because all one will know is how to run
directly from development artifacts.

That's a good point. If you do this for development, you need to make sure
that you maintain the ability to do a normal deploy as well - that could
be part of an overnight build and test process, or it could be done as
part of the pre-checkin testing ritual.

It is better to register the server with Eclipse and use the "Run As...
/ Run on Server" deployment options in Eclipse to deploy the app to the
JBoss instance, or to use JBoss's own deployment tools to deploy the WAR
or EAR files you build with Eclipse.

How long does that take? The useful thing about linking is that changes
are reflected instantaneously, so you can get rapid feedback on what
you're doing. If you have a broken test, you can edit the JSP, run the
test, and see if it's fixed it. If the deploy takes thirty seconds, and
you have to do it every time you make a change, that dramatically slows
down your decision loop.

tom

 

[Lew]

Why is that a problem? Indeed, if you're linking JSPs, is there any
other way?

Source directories don't match deployment structures. For example,

Source for Java:
project / src / java /

Deployed Java:
project_root / WEB-INF / classes /

JSP source:
project / web /

JSP deployment:
project_root /

Subdirectoried resources may differ between source and deployment.

And where to put translated JSPs and their compiled class files?

Continuing,

JARs:
project / lib /

Deployed JARs:
project_root / WEB-INF / lib /

It's all too different from the deployed structure to link to source directories.

It's better to use the IDE to build the WAR, then either use the IDE to deploy
it to the server or use the server's deployment tools. After that you have a
repeatably deployable WAR file.

 

[Lew]

How long does that take? The useful thing about linking is that changes
are reflected instantaneously, so you can get rapid feedback on what
you're doing. If you have a broken test, you can edit the JSP, run the
test, and see if it's fixed it. If the deploy takes thirty seconds, and
you have to do it every time you make a change, that dramatically slows
down your decision loop.

The drama is in the beholder, methinks.

That thirty seconds likely still happens your way, due to the necessity to
translate and compile JSPs. IDEs often make the shortcut for you, deploying
directly from its own target directories by dint of clever use of server
config options, buying you whatever benefit there is if you don't subvert the
feature by symlinking away those target directories. You don't need to turn
your mind off during the thirty seconds, thus "dramatically" improving your
decision loop. The cost of using the tools in an idiosyncratic way is likely
to exceed the asserted but un-evidenced benefit.

 

[Tom Anderson]

Source directories don't match deployment structures. For example,

Source for Java:
project / src / java /

Deployed Java:
project_root / WEB-INF / classes /

JSP source:
project / web /

JSP deployment:
project_root /

Subdirectoried resources may differ between source and deployment.

You don't have to use one link for the whole project - we make two, one
for class files and one for JSPs, or more for other components. Assuming
you use an exploded deployment to begin with, something like (obviously
assuming you have your Eclipse project set up like the one in my head - i
don't have a copy of Eclipse to hand):

SERVER=DevSetup
APP=MyApp
rm -rf /opt/jboss/server/$SERVER/deploy/$APP.war/jsp
ln -s /opt/eclipse-projects/$APP/src/jsp /opt/jboss-4/server/$SERVER/deploy/$APP.war/jsp
rm -rf /opt/jboss/server/$SERVER/deploy/$APP.war/html
ln -s /opt/eclipse-projects/$APP/static-content /opt/jboss-4/server/$SERVER/deploy/$APP.war/html
rm -rf /opt/jboss/server/$SERVER/deploy/$APP.war/WEB-INF/classes
ln -s /opt/eclipse-projects/$APP/build/classes /opt/jboss-4/server/$SERVER/deploy/$APP.war/WEB-INF/classes

Note that you don't link the java sources in at all - just the class
files.

Note also that this does involve putting all your web documents in one or
more directories under the root, rather than right in the root. We don't
find this is a big deal. On suitably advanced OSs, and given suitably
obscure wizarding knowledge, you could use a union mount to get this
right. Or you could do something unclean with symlinks inside your own
project file.

And where to put translated JSPs and their compiled class files?

Wherever JBoss wants to put them. If that directory then comes under the
Eclipse project root, cvsignore it.

Continuing,

JARs:
project / lib /

Deployed JARs:
project_root / WEB-INF / lib /

It's all too different from the deployed structure to link to source
directories.

A link for each. Sorry i didn't explain this more fully beforehand.

tom

 

[Tom Anderson]

The drama is in the beholder, methinks.

That thirty seconds likely still happens your way, due to the necessity to
translate and compile JSPs.

Nope - only the JSP i've touched has to be recompiled, and that happens in
a flash. I edit, i reload the page in the browser, i see the result. No
thirty seconds involved.

IDEs often make the shortcut for you, deploying directly from its own
target directories by dint of clever use of server config options,
buying you whatever benefit there is if you don't subvert the feature by
symlinking away those target directories.

I'm not sure what you mean - they copy from their build and JSP source
directories directly to the app server deploy directory? But they still go
through the thirty-second app server deploy process?

You don't need to turn your mind off during the thirty seconds, thus
"dramatically" improving your decision loop.

That isn't how decision loops work. You make a change, you observe the
effect of the change, then you think about it. If you wait thirty seconds
between making the change and seeing the effects, you have nothing to
think about during that time. At least, not to do with the task in hand.

The cost of using the tools in an idiosyncratic way is likely to exceed
the asserted but un-evidenced benefit.

'Asserted but un-evidenced'? Do you not believe that our method avoids the
thirty-second wait, or do you not believe that it's a benefit?

And as for the likeliness of exceeding, all i can tell you is that it
doesn't. We (the company - mostly before i joined) have built a number of
websites which are now live, on the internet and large corporate
intranets, this way. I can't see how sitting around for thirty seconds
every time we tweak a page would have helped us to do that any better.

I don't understand where this fear of breakage comes from. You're using a
normal web app layout, it's just that you futz two or three of the
directories to point to Eclipse's version of that directory, rather than
the one in the expanded WAR. They have exactly the same layout, so when
you do do a deploy, it's the same stuff, and pretty much guaranteed to
work.

If it makes you happier, you can even arrange the artifacts that
contribute to the WAR in a WAR-like structure in your eclipse project. Set
your Eclipse project up so it looks like:

/
src/
your java sources go here
lib/
your library JARs go here
war/
pages/
your JSPs, HTML, images, etc go here
WEB_INF/
web.xml
taglib1.tld
taglib2.tld
taglib3.tld
classes/
set this to be Eclipse's java build output directory
lib/
see below!
MANIFEST.MF
work/
all Eclipse's other occasional junk goes here

Then you really can just symlink the whole /war directory into the app
server deploy directory - no deployment, just go for it. Use a name ending
in .war, of course.

The WAR's lib directory could be handled in a few ways. It could itself be
a symlink to the main lib directory. Or, you could dispense with the main
lib directory, and just tell Eclipse to use /war/WEB-INF/lib as your lib
directory. Or you could keep copies of the libraries in /war/WEB-INF/lib,
and have some automatic or semi-automatic process to keep it in sync with
the main /lib (a shell script, an ant task - the latter could be triggered
by changes to /lib, or refreshing the project or something). It depends on
whether you might want libraries in /lib that don't need to go into the
WAR - app server classes you're coding against, for example. Or you could
put those in a separate Eclipse project, and import that into your app
project.

You have a similar decision with unit test code. If you want to include
unit tests in the project, but not in the WAR, you need to keep their
code, libraries, and compiled class files separate; source and libraries
are easy enough to do - can you tell eclipse to put build output from
different source directories in different output directories?
Alternatively, you put all the tests in a separate project, and have that
import the app project.

I should add that we don't use this whole approach, because we're using a
framework which wants things to be bundled up into big huge EARs in a
certain way using a magic assembly tool. Our startup script builds the
EAR, puts it into the deploy directory, then makes the necessary symlinks,
then starts JBoss. However, as long as you're not changing the
configuration of the framework, which we do fairly infrequently, you don't
need to do a full redeploy.

In any case, even if you don't like the all-in-one
already-looks-like-a-WAR approach, part of your development process is an
automatic overnight build which doesn't use the trickery, and checks out,
builds, deploys and tests the app in the conventional way. Any change
which screws up the deployability will be detected within 24 hours. You
soon get into the habit of testing any change which could affect
deployability (to manifests, deployment descriptors, whatever) by doing a
full deploy before committing the change.

tom