Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Setting up JBOSS 5 Server on my local computer

Reply
Thread Tools

Setting up JBOSS 5 Server on my local computer

 
 
maflatoun@gmail.com
Guest
Posts: n/a
 
      11-23-2008
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
 
Reply With Quote
 
 
 
 
Tom Anderson
Guest
Posts: n/a
 
      11-23-2008
On Sun, 23 Nov 2008, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> 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

--
No Hype Just Science
 
Reply With Quote
 
 
 
 
Donkey Hottie
Guest
Posts: n/a
 
      11-23-2008
"(E-Mail Removed)" <(E-Mail Removed)> wrote in news:6a852acc-a0c8-
(E-Mail Removed):
> 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.


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-23-2008
(E-Mail Removed) wrote:
>> 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.


Tom Anderson wrote:
> 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.

--
Lew
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      11-23-2008
On Sun, 23 Nov 2008, Lew wrote:

> (E-Mail Removed) wrote:
>>> 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.

>
> Tom Anderson wrote:
>> 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.


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

--
there is not much call for a Chinese George Michael
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-23-2008
Lew wrote:
>> First of all, you're linking source to
>> JBoss, instead of built artifacts.


Tom Anderson wrote:
> 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
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-23-2008
Lew wrote:
>> 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.


Tom Anderson wrote:
> 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.

--
Lew
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      11-24-2008
On Sun, 23 Nov 2008, Lew wrote:

> Lew wrote:
>>> First of all, you're linking source to JBoss, instead of built artifacts.

>
> Tom Anderson wrote:
>> 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.


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

--
Tomorrow has made a phone call to today.
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      11-24-2008
On Sun, 23 Nov 2008, Lew wrote:

> Lew wrote:
>>> 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.

>
> Tom Anderson wrote:
>> 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.


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

--
Tomorrow has made a phone call to today.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Internet Application in JBoss Portal on Liferay JBoss LprzemekL Java 0 04-10-2008 12:03 PM
Eclipse/Lomboz/JBoss: Cannot Start JBoss (Debug) Server from Eclipse Using Lomboz Plugin Jubz Java 0 05-30-2006 10:24 PM
jboss 4.0.3 jboss portal 2.2.1 han Java 0 05-08-2006 10:35 AM
Debugging local variables in JBoss/Tomcat using Eclipse Ronald Java 1 11-18-2003 03:42 PM
Can't use 'local' to find sql server instances on local machine karim ASP .Net 1 06-26-2003 09:17 PM



Advertisments