Thanks danch for the Awnser.
All my EJB's are in the same ejb-jar file, but my problem is with the files
that are used by the bean's which are not ejb's
that get called by the session bean which then call the entity beans ??
So calling is like this : Call to session bean -> Session bean call normal
Bean -> Normal Bean call Entity Beans.
So what is the correct way extend the CLASSPATH ?
> Hi All
>
> I have a question just to verify that we are doing is ok in JBOSS !
> I have a little scenario where we are using naormal JavaBeans no
Enterprise
> bean (Call it a vanilla bean!!) to implement a service in our program this
> bean call some Entity EJB's. Which Trnsaction settings are set to Required
> so they will create a transaction for themselves if none exists. Then We
> have an Session benan that basically wraps the Service Class (Vanilla
bean).
>
> What I am realizing now is that these Vanilla classes of mine that is
using
> the Entity EJB's tell me they can not found the Remote + Home interfaces
of
> the Entity Beans. I get around this by putting these classes ()Home +
> Remoeteinterfaces in the lib\ext directory of JBoss - bit of a funny
> because these classes(interfaces) are already in my deploy directory.... I
> think this cause some funnies to happen in our server.
>
> Can I you this methodology in JBoss (We did a similar thing in Websphere
no
> problem). What is the correct way to extend the of JBoss classpath ???
*You _can_ do this, but you'd probably be better off with various other
*techniques. For starters, is there anything preventing you from
*packaging all of your EJBs into a single ejb-jar? Barring that, package
*all of the ejb-jars into a single .ear?
*really the problem with putting your application classes into lib/ext is
*twofold: it mixes application classes with infrastructure, which will
*make upgrades, server re-configuration, scaling onto multiple servers,
*and various other administrative tasks more difficult. It also makes
*that application's classes available to all applications deployed on any
*JBoss instance that runs from that directory, which is messy at best.
*
*Having said that, you can also do the equivalent by adding a
*ClassPathExtension MBean to jboss.conf, pointing to a directory
*containing jars of your application classes. This only does away with a
*couple of the above objections.
-danch
**********************************************************************
The information in this e-mail is confidential and is legally privileged.
It is intended solely for the addressee. If this email is not intended for
you, you cannot copy, distribute, or disclose the included information
to any-one
If you are not the intended recipient please delete the mail. Whilst
all reasonable steps have been taken to ensure the accuracy and
integrity of all data transmitted electronically, no liability is accepted
if the data, for whatever reason, is corrupt or does not reach it's
intended destination.
All business is undertaken, subject to our standard trading conditions
which are available on request.
*******************************************************************
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
