Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / JavaBeans / April 2005

Tip: Looking for answers? Try searching our database.

Jboss Hot deployment

Thread view: 
Jason Price - 01 Apr 2005 10:29 GMT
We have a EJB project that contains about 10 EJBs that are common to
most of our web and client applications. As the EJB are generic, so to
speak, this is packaged and deployed as the only thing in the ear
file. Everything works fine except for when we need to change any of
these EJBs and redeploy. When we redeploy, everything appears to
redeploy properly but the webapps then start generating class cast
exceptions and the only way to fix it is to restart jboss or redploy
every app that uses the ejbs. This happens on our single jboss server
and the 10 clustered machines we have (running jboss4.0.1sp1 on gentoo
with one the machines set-up as loadbalancer using mod_jk and apache).

Is this expected behaviour?
What is standard practice for this sort of common code. I am at a loss
as to how we can deploy to a live enviroment without any impact on the
users and client applications. I thought that this is what hot
deployment is all about but it doesn't seem to work.

BTW all the EJBs are stateless session beans that just provide glue
between web apps/clients and the Business Classes (using Data Factory
pattern).

I have asked the same question on the jboss forums but no one is
replying.  This may be a implementation issue.
I am not sure if the way in which I have designed the applications are
the correct j2ee way but I can find no pattern for common business
objects and ejbs.  I need to have one location with this code in that
can be referenced across various web and client apps, which is why I
chose ejbs as I thought this is what they are designed for!
Frank Langelage - 01 Apr 2005 12:50 GMT
> Is this expected behaviour?
>
> BTW all the EJBs are stateless session beans that just provide glue
> between web apps/clients and the Business Classes (using Data Factory
> pattern).

Just 2 questions from me:
1. what was changed before redeployment ?
    Only the implementation code of the SLSB or did the interface
    classes (Remote-/Local- Home and Object) change ?
2. where are those interface classes put in ?
    In the ejb ear-file or in web- and client-apps ?
R.F. Pels - 01 Apr 2005 15:55 GMT
> these EJBs and redeploy. When we redeploy, everything appears to
> redeploy properly but the webapps then start generating class cast
> exceptions and the only way to fix it is to restart jboss or redploy
> every app that uses the ejbs. This happens on our single jboss server

Did you properly serialize the necessary classes (included the generated
ones that derive from Serializable)???

Signature

Ruurd
.o.
..o
ooo

John M Flinchbaugh - 04 Apr 2005 06:05 GMT
> file. Everything works fine except for when we need to change any of
> these EJBs and redeploy. When we redeploy, everything appears to
> redeploy properly but the webapps then start generating class cast
> exceptions and the only way to fix it is to restart jboss or redploy
> every app that uses the ejbs. This happens on our single jboss server

It's most likely JBoss' Unified Class Loader causing you troubles.  I've
been most successful disabling the UCL in Tomcat, so it doesn't
interfere with Tomcat's standard classloading.

Relative to your deploy directory, edit your
jbossweb-tomcat50.sar/META-INF/jboss-service.xml, change:
   <attribute name="UseJBossWebLoader">true</attribute>
to:
   <attribute name="UseJBossWebLoader">false</attribute>

After a restart then, you should be able to redeploy without getting
ClassCastExceptions.

The UCL tries to flatten the whole classloading hierarchy to make it
simpler for beginners (EJB interfaces deployed in ejb jar files will
magically be visible to the web components, without having to actually
be deployed in the war).  This causes confusion then when the EJB
interfaces are redeployed.

You can take further steps to properly isolate each EJB component from
others, by specifying custom UCL domains or something, but I've not
found that necessary yet.  Just getting Tomcat to ignore the UCL has
made things works as I'd expect.

Good luck.
Signature

John M Flinchbaugh
john@hjsoft.com



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.