Many EJB's and ejb-jar.xml

I will have about 20 EJB's who have relationships with each other.
Now all those EJB's come in the same deployment descriptor, causing it to grow to over 2000 lines.
Is it possible to split the ejb-jar.xml in several ejb-jar.xml's? One for every EJB or one for every EJB group as a business object pattern.
Or is there another solution?

No - this is a case of "what you sow, you reap." In other words, if you have that many relations, you have a large ejb-jar.xml, since all the Entities involved in the relations must be in the same .jar file. What I would try to do is break down the relations into logical groupings and, ideally, those groups would not have relations with each other. Then split those groups out into separate deployments. Or if the relation between two groups is "light" (maybe only one), you can manually handle the relation through remote calls, instead of using CMR.

Similar Messages

What is the difference between ejb reference and ejb handle?

Hi:
I am newbie for J2EE.
I want to know what is the difference between ejb reference and ejb handle
from the client view and from the container view?
Very Thanks!
Stive

Hi John,,
1) Ejb Object Handle are nothing but a long lived proxy for the
ejb object, using this handle user can disconnect from the Ejb Server/Container
at any time
and after some time using the same handle he can able to resume the conversational
state
with the server / container where he was been disconnected From.
And there are currently two Handles , HomeHandle and Handle for EjbHomeObject
and EjbObject
Respectively. Both these handles have Persistent reference to the EJB Object
2) Ejb Reference is used to lookup a bean from other Enterprise Bean
Ejb reference is a nickname for the JNDI Location that you want to lookup a bean.
your code will looks up a Home object via using this nickname
and the deployer will bind the
nickname to the JNDI location of its choice
EJb Reference are declared in the deployment descriptor
Regards
Karthikeyan Gangadharan
SIP Technologies, Chennai
E-mail-ID : [email protected]
"John Stive" <[email protected]> wrote:
>
Hi:
I am newbie for J2EE.
I want to know what is the difference between ejb reference and ejb
handle
from the client view and from the container view?
Very Thanks!
Stive

Servlet jndi lookup to remote EJB, servlet and EJB not in the same application

Hi,
I think that the subject explain my problem.
I have Oracle IAS9i 9.0.2.0.0, and JDeveloper 9.0.2.829
I have deployed and EJB in IAS9i and i want to use from the developer machines, which have JDeveloper.
how can i to do remote calls from JDeveloper?.
I have modifed the orion-application.xml, and added remote=true.
I have modifed the rmi.xml and added the hosts where the Jdeveloper placed.
Any ideas?
Thanks and cheers
P.D The app server and jdeveloper are in the same net.
if it is posible replys me to [email protected] too.

Steps to access a remote EJB from within OC4J
++++++++++++++++++++++++++++++++++++++++++++++
1) Deploy EJB application (ApplicationRemote) to remote container (REMOTE)
"java -jar admin.jar -deploy ormi://REMOTE.hostname:REMOTE.port REMOTE.username REMOTE.password -deploy -file ApplicationRemote.ear
-deploymentName ApplicationRemote"
2) Ensure that local application (ApplicationLocal) has ejb-ref tags for remote EJBs accessed (in web.xml or ejb-jar.xml)
3) Deploy to local container (LOCAL) an empty application (ApplicationEmpty) with the same name as the remote application (ApplicationRemote)
"java -jar admin.jar -deploy ormi://LOCAL.hostname:LOCAL.port LOCAL.username LOCAL.password -deploy -file ApplicationEmpty.ear -deploymentName
ApplicationRemote"
5) Deploy local application (ApplicationLocal) to local container (LOCAL)
"java -jar admin.jar -deploy ormi://LOCAL.hostname:LOCAL.port LOCAL.username LOCAL.password -deploy -file ApplicationLocal.ear -deploymentName
ApplicationLocal"
4)Restart local container
ApplicationEmpty should consist of just an application.xml file - no modules. The same file can be deployed with different application names for all the remote
applications that must be accessed.
ApplicationLocal should access the remote EJB by using the following JNDI properties
java.naming.factory.initial = "com.evermind.server.rmi.RMIInitialContextFactory"
java.naming.provider.url = "ormi://REMOTE.hostname:REMOTE.port/ApplicationRemote"
java.naming.security.principal = "REMOTE.username"
java.naming.security.credentials = "REMOTE.password"
regards
Debu Panda

Ejb-ref and ejb-local-ref tags

Hi everyone,
Can someone please tell me
1) Is it necessary for me to define ejb-ref or ejb-local-ref tags if I am referering one ejb from other ejb? I mean to say is it mandatory that I should have these deployment descriptor tags?
2) What is purpose of ejb-link tag ?

Hi everyone,
Can someone please tell me
1) Is it necessary for me to define ejb-ref or
ejb-local-ref tags if I am referering one ejb from
other ejb? I mean to say is it mandatory that I should
have these deployment descriptor tags?Yes, to write portable J2EE components, every time you have a dependency on an ejb, you need to declare an ejb-ref (for a Remote EJB client) or ejb-local-ref (for a Local EJB client). This is true no matter what kind of J2EE component is accessing the ejb (Application Client, JSP, Servlet, or another ejb).
Think of the ejb-ref or ejb-local-ref as a pointer. It's different from the thing that is pointed to. Instead, it represents a dependency between a client component and a target ejb.
2) What is purpose of ejb-link tag ?Every ejb-ref or ejb-local-ref must be resolved to unambiguously point to the target ejb. The ejb-link tag is one way to resolve this dependency for the case where the target ejb lives in the same .ear as the referring component. The ejb-link tag is the ejb-name (or <ejb-jar uri>#<ejb-name>) of the target ejb.
Note that this means ejb-link is the ONLY way to resolve an ejb-local-ref, since by definition Local EJB access can only take place between two ejbs within the same .ear or a web component/ejb that live within the same .ear.
For ejb-refs, you can use ejb-link if the target ejb is within the same .ear. If not, the ejb specification does not prescribe how the dependency is resolved. It's left up to the J2EE implementation. The most common approach is for the vendor to provide a product-specific runtime .xml element that resolves the ejb-ref by associating it with the global JNDI name of the target EJB. That's the approach used in the J2EE SDK and Sun Java System Application Server.
Kenneth Saks
J2EE SDK Team
SUN Microsystems

Error trying to deserialize EJB HomeHandle and EJB Handle classes

I get the following exception when I try to deserialize both a javax.ejb.HomeHandle and a javax.ejb.Handle. I serialize and immediately deserialize within the same application using the same classloader so there are not alot of external variables that may cause the problem. Any ideas on why I can't deserialize an ejb handle?
The reason I am doing this is to try and get around the need to reference another application just to call a remote method in that application. I want to serialize the remote home interface handle or the remote component interface handle and deserialize it using my local application classloader. Does anybody know if this would work?
#1#java.lang.ClassNotFoundException: Loader /L_service:ejb could not load class turtle.registry.SBRegistryRemoteHome
     at com.sap.vmc.core.impl.sapjvm.sharing.NativeSharedClassLoaderImpl.loadClass(NativeSharedClassLoaderImpl.java:609)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:265)
     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:333)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:242)
     at java.io.ObjectInputStream.resolveProxyClass(ObjectInputStream.java:656)
     at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1499)
     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1462)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
     at com.sap.engine.services.ejb3.runtime.impl.LocalHandleDelegate.readStub(LocalHandleDelegate.java:177)
     at com.sap.engine.services.ejb3.runtime.impl.ServerHandleDelegate.readStub(ServerHandleDelegate.java:64)
     at com.sap.engine.services.ejb3.runtime.impl.LocalHandleDelegate.readEJBHome(LocalHandleDelegate.java:101)
     at com.sap.engine.services.ejb3.runtime.impl.StatelessHomeHandleImpl.readObject(StatelessHomeHandleImpl.java:73)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:585)
     at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
     at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1818)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1718)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
     at turtle.common.util.SerializationHelper.convertObject(SerializationHelper.java:43)
     at turtle.common.server.connect.RemoteFactory.getRemoteSAPWAS(RemoteFactory.java:206)
     at turtle.common.server.connect.RemoteFactory.getRemote(RemoteFactory.java:46)
     at turtle.common.server.connect.RemoteProxyFactory.getRemote(RemoteProxyFactory.java:99)
     at turtle.common.server.connect.RemoteProxyFactory.create(RemoteProxyFactory.java:91)
     at turtle.common.server.connect.RemoteProxyFactory.createProxy(RemoteProxyFactory.java:52)
     at turtle.server.runtime.registry.RegistryFacade.connectToRegistry(RegistryFacade.java:932)
     at turtle.server.runtime.registry.RegistryFacade.getGenericRegistryBI(RegistryFacade.java:987)
     at turtle.server.runtime.registry.RegistryFacade.unbindObjectsInProject(RegistryFacade.java:857)
     at turtle.registry.ProjectRegistrar$1$1.run(ProjectRegistrar.java:130)
     at java.security.AccessController.doPrivileged(Native Method)
     at javax.security.auth.Subject.doAs(Subject.java:337)
     at turtle.common.security.auth.AuthenticatorBase.doAs(AuthenticatorBase.java:387)
     at turtle.registry.ProjectRegistrar$1.run(ProjectRegistrar.java:172)
     at java.util.TimerThread.mainLoop(Timer.java:512)
     at java.util.TimerThread.run(Timer.java:462)

Has anyone been able to get this to work? Or can anyone confirm that this is a bug?
As a simpler test, I modified the UserManagementBean of the Car Rental example application. I added some code in the register method that serializes and deserializes the Handle object obtained from the SessionContext.getEJBObject().getHandle() method. The serialization completes without issue. However, I get the same error when trying to deserialize the Handle object:
java.lang.ClassNotFoundException: Loader /L_service:ejb could not load class com.sap.engine.examples.epf.ejb.controller.customer.UserManagementHome
     at com.sap.vmc.core.impl.sapjvm.sharing.NativeSharedClassLoaderImpl.loadClass(NativeSharedClassLoaderImpl.java:609)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:265)
     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:333)
     at java.lang.Class.forName0(Native Method)
     at java.lang.Class.forName(Class.java:242)
     at java.io.ObjectInputStream.resolveProxyClass(ObjectInputStream.java:656)
     at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1499)
     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1462)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
     at com.sap.engine.services.ejb3.runtime.impl.LocalHandleDelegate.readStub(LocalHandleDelegate.java:177)
     at com.sap.engine.services.ejb3.runtime.impl.ServerHandleDelegate.readStub(ServerHandleDelegate.java:64)
     at com.sap.engine.services.ejb3.runtime.impl.LocalHandleDelegate.readEJBHome(LocalHandleDelegate.java:101)
     at com.sap.engine.services.ejb3.runtime.impl.StatelessHomeHandleImpl.readObject(StatelessHomeHandleImpl.java:73)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:585)
     at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946)
     at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1818)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1718)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
     at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1917)
     at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1841)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1718)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
     at com.sap.engine.examples.epf.ejb.controller.customer.SerializationUtils.deSerialize(SerializationUtils.java:33)
     at com.sap.engine.examples.epf.ejb.controller.customer.SerializationUtils.deepClone(SerializationUtils.java:59)
     at com.sap.engine.examples.epf.ejb.controller.customer.UserManagementBean.register(UserManagementBean.java:75)

Question on EJB, JNDI and client jars

Hi,
This is a very fundamental question on EJBs and their clients - what
all should go into the client jar of an ejb?
I know for sure that just the remote and home interface classes of the
ejb are sufficient on the client's classpath to work with an EJB on a
totally different server, but I dont understand the logic behind it.
If the client has to pass its object parameters over the network to
the server where the ejb bean is located, should the container
generated stub not be present on the client's classpath? After the
client does the JNDI lookup of the ejb home on the server, how does it
serialize and pass the parameters over the network if the container
generated stub is not present?
Any help would be greatly appreciated. Pointers to material on the
internet which explain this/related things in detail would be a great
help.
Thank you,
Anoushka

"Anoushka" <[email protected]> writes:
I know for sure that just the remote and home interface classes of the
ejb are sufficient on the client's classpath to work with an EJB on a
totally different server, but I dont understand the logic behind it.
If the client has to pass its object parameters over the network to
the server where the ejb bean is located, should the container
generated stub not be present on the client's classpath? After the
client does the JNDI lookup of the ejb home on the server, how does it
serialize and pass the parameters over the network if the container
generated stub is not present?Most protocols (IIOP, T3, JRMP) provide a slot for encoding a codebase
in RMI requests. The codebase is usually an http URL that specifies
where to get classes that are not currently available to the
client. This URL is used to construct a java.net.URLClassLoader which
then downloads classes on demand. These classes can include stubs,
object arguments - pretty much anything you like. There are certain
security restrictions on the URLClassLoader which is why you sometimes
have to specifiy a security manager in a client. T3 will for
preference generate stubs in the client rather than download them,
however this is not allowed in an applet - and so in this case T3 will
also download stubs from the server.
The net of this is that you don't have to put very much at all in a
client jar UNLESS you can't use the URLClassLoader. In that instance
you have to put EVERYTHING you need in the client jar.
HTH
andy

Fundamental question on EJB, JNDI and client jars

Hi,
This is a very fundamental question on EJBs and their clients - what
all should go into the client jar of an ejb?
I know for sure that just the remote and home interface classes of the
ejb are sufficient on the client's classpath to work with an EJB on a
totally different server, but I dont understand the logic behind it.
If the client has to pass its object parameters over the network to
the server where the ejb bean is located, should the container
generated stub not be present on the client's classpath? After the
client does the JNDI lookup of the ejb home on the server, how does it
serialize and pass the parameters over the network if the container
generated stub is not present?
Any help would be greatly appreciated. Pointers to material on the
internet which explain this/related things in detail would be a great
help.
Thank you,
Anoushka

hello,
well, the process is fairly simple actually.. The client needn't necessarily have
the container generated stub. as a client u could contact what is known as a boot-strap
service to download the stub over the wire.. infact one of the advantages of RMI
is precisely that. and since RMI is the underlying architecture of EJBs, it all
becomes rather simple. when u 'lookup' a bean, what u are in essence doing is
asking the server to send down the stub to your JVM. well.. right now this is
what i got time for..i will try to post a lengthier explanation in a couple of
days at leisure..
Vijay
"Anoushka" <[email protected]> wrote:
>
Hi,
This is a very fundamental question on EJBs and their clients - what
all should go into the client jar of an ejb?
I know for sure that just the remote and home interface classes of the
ejb are sufficient on the client's classpath to work with an EJB on a
totally different server, but I dont understand the logic behind it.
If the client has to pass its object parameters over the network to
the server where the ejb bean is located, should the container
generated stub not be present on the client's classpath? After the
client does the JNDI lookup of the ejb home on the server, how does it
serialize and pass the parameters over the network if the container
generated stub is not present?
Any help would be greatly appreciated. Pointers to material on the
internet which explain this/related things in detail would be a great
help.
Thank you,
Anoushka

EJB-QL and ejb-name bug

Hi,
I think I found a bug when using EJB-QL with oc4j.
If the name of your bean (<ejb-name> tag) is set to something with a "dot". E.g. "mytests.MyLocalBean" then the finder methods (using EJB-QL) will return an SQL exception. The exception says that no table named "MyLocalBean" can be found. The "mytests" prefix seems to be missing in the dynamically generated SQL statement.
If I change the bean name to "MylocalBean" everything works fine.
I'm currently using Iterbase DB, but I think this is an error in the oc4j container.
/johan

Johan -- I will take a look at it.
Thanks -- Jeff

Can't create EJB from existing .java AND ejb-jar.xml entries

I've noticed that I can create the source files for an EJB outside of JDeveloper, then I can do the "Create Entity Bean" thing, and specify the path to the source files, and it will use those source files, instead of forcing me to create them again.
However, I've noticed that if I manually add the information to the "ejb-jar.xml" file, and then try to add the bean, it won't let me. I've found I have to delete the entry from the ejb-jar.xml file and let JDeveloper control the creation of the fields, even if I know exactly what needs to be set.

If you are adding/modifying ejb-jar.xml outside JDeveloper and trying to see the changes.
Save the ejb-jar.xml file which is being modified externally
Select ejb-jar.xml in JDeveloper
and do View | Refresh
This will load in the changes (providing the source path has been set properly)
raghu
JDev Team

Stateless session Bean - xml and ejb-jar.xml file ???

Dear Experts,
Stateless-session bean
For Creating an ear file
we need ejb-jar.xml and weblogic-ejb-jar.xml files
Is these files are already available
or we have to type these files ??
Advance Thanks
Rengaraj.R

My best advice: surrender to use an IDE.
You wonder sometimes at how much productivity (read as 'time') could be wasted by doing something that could be done automatically. For a learning experience or a once only exercise is fine but as a routine thing, not worth it.
Cheers

JNDI and env. vars. in ejb-jar.xml

I have been trying for several days now to have my EJB session bean access
its env. vars. stored in the ejb-jar.xml document. I have been unsuccessful.
The only place I have been able to store my env. vars. is in the web.xml
document outside my .jar file. Although workable, it would be preferable to
store them in the ejb-jar.xml document in my .jar file.
I am hoping some one can help me. I am using the following code in my ejb:
Context init = new InitialContext();
Context env = (Context)init.lookup("java:comp/env");
m_bTruncCorporate =
((Boolean)env.lookup(MICRworks.MICR_ENV_TRUNCORP)).booleanValue();
m_strOptPath = (String)env.lookup(MICRworks.MICR_ENV_OPFLPATH);
m_strOptAccount = (String)env.lookup(MICRworks.MICR_ENV_OPFLACCT);
m_strOptRouting = (String)env.lookup(MICRworks.MICR_ENV_OPFLROUT);
My ejb-jar.xml follows:
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>MICRworksBean</ejb-name>
<home>USDataworks.MICRworks.MICRworksHome</home>
<remote>USDataworks.MICRworks.MICRworks</remote>
<ejb-class>USDataworks.MICRworks.MICRworksBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<env-entry>
<description>Flag indicating whether to convert corporate
checks</description>
<env-entry-name>TruncateCorporate</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>true</env-entry-value>
</env-entry>
<env-entry>
<description>Location of the 1For1 exclusion files</description>
<env-entry-name>OptionFilePath</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>http://localhost:7001/MICRworksLite/files/</env-entry-value
>
</env-entry>
<env-entry>
<description>Name of the 1For1 account exclusions file</description>
<env-entry-name>OptionFileAccount</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>account_file.txt</env-entry-value>
</env-entry>
<env-entry>
<description>Name of the 1For1 routing exclusion file</description>
<env-entry-name>OptionFileRouting</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>routing_file.txt</env-entry-value>
</env-entry>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>MICRworksBean</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Supports</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
and my weblogic-ejb-jar.xml:
<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0
EJB//EN' 'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>MICRworksBean</ejb-name>
<stateless-session-descriptor>
<pool>
</pool>
<stateless-clustering>
</stateless-clustering>
</stateless-session-descriptor>
<transaction-descriptor>
</transaction-descriptor>
<jndi-name>MICRworksBean</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
My feeling is that I am missing some sort of reference in the
weblogic-ejb-jar.xml that points to the ejb-jar.xml but I have tried several
things without success.
I would appreciate any help I can get...especially if it contains specific
code I can use as I am rather new to writing and deploying ejbs!
Thanx in advance. Marek :-)

Thanks for the reference. I was using another book as a reference (Using
Java 2 Enterprise Edition by Mark Wutka) which had the same sort of example
and as you can see below, I coded my bean as they suggest...I'm still unable
to access the env. vars.!
I deployed by bean using WebLogic's Builder and but didn't create any sort
of application. I let WebLogic do what it would on its own. The WebLogic
documentation seemed to indicate for simple testing this would work
fine...is it wrong?
btw. MICRworks.MICR_ENV_TRUNCORP equates to "TruncateCorporate" as you
probably guessed.
The WebLogic Admin Console shows the environment variables in the EJB
Descriptors for my EJB but they do not show up when I view the JNDI tree for
my server. I have taken this to mean that the deployment tool is not
binding my env. vars. for some reason which would explain why my bean can't
find them.
I know it must be something stupid I am doing (or not doing) but I just
can't see it. Please help!
"Ryan LeCompte" <[email protected]> wrote in message
news:[email protected]...
>
Hello Marek,
I would suggest that you download the free book "Mastering EJB 2ndEdition" by
Ed Roman, Scott Ambler, and Tyler Jewell. The source code for the book isalso
freely available and is meant to be deployed specifically on WebLogic.Look for
a sample application called "Jasmine", which shows how to use environmententries.
You will see a concrete example of how they are defined and later accessedfrom
within EJBs. The book and source code are available at the followingaddress:
>
http://www.theserverside.com/books/masteringEJB/index.jsp
Best regards,
Ryan LeCompte
[email protected]
http://www.louisiana.edu/~rml7669
"Marek Kossak" <[email protected]> wrote:
I have been trying for several days now to have my EJB session bean
access
its env. vars. stored in the ejb-jar.xml document. I have beenunsuccessful.
The only place I have been able to store my env. vars. is in the web.xml
document outside my .jar file. Although workable, it would be preferable
to
store them in the ejb-jar.xml document in my .jar file.
I am hoping some one can help me. I am using the following code in my
ejb:
Context init = new InitialContext();
Context env = (Context)init.lookup("java:comp/env");
m_bTruncCorporate =
((Boolean)env.lookup(MICRworks.MICR_ENV_TRUNCORP)).booleanValue();
m_strOptPath = (String)env.lookup(MICRworks.MICR_ENV_OPFLPATH);
m_strOptAccount = (String)env.lookup(MICRworks.MICR_ENV_OPFLACCT);
m_strOptRouting = (String)env.lookup(MICRworks.MICR_ENV_OPFLROUT);
My ejb-jar.xml follows:
<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>MICRworksBean</ejb-name>
<home>USDataworks.MICRworks.MICRworksHome</home>
<remote>USDataworks.MICRworks.MICRworks</remote>
<ejb-class>USDataworks.MICRworks.MICRworksBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<env-entry>
<description>Flag indicating whether to convert corporate
checks</description>
<env-entry-name>TruncateCorporate</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>true</env-entry-value>
</env-entry>
<env-entry>
<description>Location of the 1For1 exclusion files</description>
<env-entry-name>OptionFilePath</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>http://localhost:7001/MICRworksLite/files/</env-entry-valu
e
>>>
</env-entry>
<env-entry>
<description>Name of the 1For1 account exclusions file</description>
<env-entry-name>OptionFileAccount</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>account_file.txt</env-entry-value>
</env-entry>
<env-entry>
<description>Name of the 1For1 routing exclusion file</description>
<env-entry-name>OptionFileRouting</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>routing_file.txt</env-entry-value>
</env-entry>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>MICRworksBean</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Supports</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
and my weblogic-ejb-jar.xml:
<!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic
7.0.0
EJB//EN' 'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>MICRworksBean</ejb-name>
<stateless-session-descriptor>
<pool>
</pool>
<stateless-clustering>
</stateless-clustering>
</stateless-session-descriptor>
<transaction-descriptor>
</transaction-descriptor>
<jndi-name>MICRworksBean</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
My feeling is that I am missing some sort of reference in the
weblogic-ejb-jar.xml that points to the ejb-jar.xml but I have tried
several
things without success.
I would appreciate any help I can get...especially if it containsspecific
code I can use as I am rather new to writing and deploying ejbs!
Thanx in advance. Marek :-)

Using JMX to read ejb manifest jar and ejb-jar.xml in ejb jar inside ear

Hello,
I have an ear deployed on weblogic console. I need to check contents of manifest file and ejb-jar.xml of a jar that is present in the deployed ear.
Currently I am using below code to access jar inside ear deployed :
Hashtable env = new Hashtable(5);
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL,
url);
env.put(Context.SECURITY_PRINCIPAL, user);
env.put(Context.SECURITY_CREDENTIALS, password);
Context ctx = new InitialContext(env);
mBeanHome = (MBeanHome)ctx.lookup(MBeanHome.ADMIN_JNDI_NAME);
String type = "EJBComponentRuntime";
Set beans = mBeanHome.getMBeansByType(type);
try{
for(Iterator it=beans.iterator();it.hasNext();)
EJBComponentRuntimeMBean rt = (EJBComponentRuntimeMBean)it.next();
if(rt.getParent().getName().equals("xxx")){
System.out.println(rt.getName());
l.add(rt.getName());
Here xxx is the ear. Now I need to get inside the jar (represented) by variable rt and access its manifest file,ejb-jar.xml
Does anyone have an idea how to do this?
regards
Sameer

Isn't it possible to put them there manually? :)

Ejb-jar.xml and orion-ejb-jar.xml configuration issue

Chris,
We have an application that uses the Oracle 10g Application Server and WebSphere MQ v5.3 w/ fixpack 9.
Our application is a J2EE messaging system which essentially consists of Message Driven Beans, the EJB
realization of the J2EE Java Message Service (JMS) API. Our application has Message Driven Beans which
listen to queues and send messages to queues -- a simple messaging system. Currently we can listen to queues, but
cannot send messages to queues in the Oracle 10g Application Server environment.
Any J2EE application server has its own implementation of Java Naming Directory Interface (JNDI) API that
deployed J2EE applications utilize to lookup resources such as Data Sources, JMS Destinations (i.e. MQ Queue),
JMS QueueConnectionFactories (i.e. MQ QManagers).
Our application uses the 3rd party JMS Provider, WebSphere MQ.
MQ ships with a JMSAdmin tool which allows one to create JMS administered objects (i.e. objects a java
application searches for in some JNDI directory) that reside in some JNDI context. We create a JNDI context for
MQ resources, queues and QManagers. We configure the MQ provided
JMSAdmin tool with two property name/value pairs:
PROVIDER_URL=file:/opt/mqm/JNDI-Directory
INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
A resultant .bindings file is created in /opt/mqm/JNDI-Directory which represents our JDNI context
containing our JMS administered objects. A standalone java application that needs to directly access this
JNDI context can simply conduct a JNDI lookup on the following context: "java:comp/resource/MQSeries/". An
example of how a standalone application would lookup a JMS administered object named "qNumber1" would be to
lookup "java:comp/resource/MQSeries/qNumber1". This lookup would result in the standalone java application
having a JMS reference to an MQ Queue.
There is a major difference in how an enterprise EJB application deployed into a J2EE Container (Oracle 10g App Server)
conducts a JNDI lookup on a 3rd party resource such as MQ as a JMS Provider. A typical EJB application deployed
into a J2EE container as an .ear (enterprise archive) file has implicit access to the application server's own
JNDI context. This JNDI context is usually "java:comp/env/". Looking up the Application Server's own Data Source or
it's own JMS Resources is easy. An application that needs references to these Application Server provided resources
simply conducts a lookup for "java:comp/env/jms/someQ" or "java:comp/env/jdbc/myDataSource".
The problem we face is mapping our MQ JNDI context to the Oracle App Server's own JNDI context. We believe this is
accomplished through mappings defined in both the ejb-jar.xml (EJB Descriptor) and the application server specific
counterpart, orion-ejb-jar.xml. Note that Oracle 10g Application Server uses the popular orion J2EE container for
hosting J2EE enterpise applications.
Our Message Driven Beans (MDBs)currently listen to the Queue at the JNDI location "prodQ". Our problem is that we cannot
get our MDB to send messages to any queues. Note that the MQ implementation of the queues and Queue Managers work
flawlessly with standalone java applications. It's safe to say that the MQ objects are working.
We are looking for a solid example of how the ejb-jar.xml and the orion-ejb-jar.xml map 3rd party JMS provider
JNDI locations to the App Server's JNDI context.
Below is how we have attempted to configure our own ejb-jar.xml and orion-ejb-jar.xml:
ejb-jar.xml begin >>>>>>>>>>>>>>><?xml version = '1.0' encoding = 'UTF-8'?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar>
<display-name>Production Message Driven Bean</display-name>
<enterprise-beans>
<message-driven>
<display-name>prodMdb</display-name>
<ejb-name>prodMdb</ejb-name>
<ejb-class>message.handler.AIDMSMessageConsumerBean</ejb-class>
<transaction-type>Bean</transaction-type>
<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
     <resource-ref>
<res-ref-name>prodQCF</res-ref-name>
<res-type>javax.jms.QueueConnectionFactory</res-type>
<res-auth>Application</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
     <resource-ref>
<res-ref-name>prodQ</res-ref-name>
<res-type>javax.jms.Queue</res-type>
<res-auth>Application</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
               <resource-ref>
<res-ref-name>prodR</res-ref-name>
<res-type>javax.jms.Queue</res-type>
<res-auth>Application</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</message-driven>
</enterprise-beans>
</ejb-jar>
<<<<<<<< ejb-jar.xml end <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
begin orion-ejb-jar.xml >>>>>>>>>>>>>>>>>>>>>>>>>>><orion-ejb-jar>
<enterprise-beans>
<message-driven-deployment name="prodMdb" connection-factory-location="java:comp/resource/MQSeries/prodQCF" destination-location="java:comp/resource/MQSeries/prodR">
          <resource-ref-mapping location="prodQ" name="prodQ">
               <lookup-context location="java:comp/resource/MQSeries/" >
                    
               </lookup-context>
          </resource-ref-mapping>
          <resource-ref-mapping location="prodR" name="prodR">
               <lookup-context location="java:comp/resource/MQSeries/" >
                    
               </lookup-context>
          </resource-ref-mapping>
     </message-driven-deployment>
</enterprise-beans>
</orion-ejb-jar>
<<<<<<<<< end orion-ejb-jar.xml <<<<<<<<<<<<<<<<<<<<<<<<

If you look at the contents of a deployment plan (Plan.xml) when you have it generated
<deployment-plan ...>
<module-override>
    <module-name>ejb.jar</module-name>
    <module-type>ejb</module-type>
    <module-descriptor external="true">
      <root-element>weblogic-ejb-jar</root-element>
      <uri>META-INF/weblogic-ejb-jar.xml</uri>
    </module-descriptor>
    <module-descriptor external="false">
      <root-element>ejb-jar</root-element>
      <uri>META-INF/ejb-jar.xml</uri>
    </module-descriptor>
    <module-descriptor external="true">
      <root-element>persistence-configuration</root-element>
      <uri>META-INF/persistence-configuration.xml</uri>
    </module-descriptor>
    <module-descriptor external="false">
      <root-element>persistence</root-element>
      <uri>META-INF/persistence.xml</uri>
    </module-descriptor>
</module-override>
</deployment-plan>You can see which files can be external and which can be not. The weblogic-ejb-jar.xml can be external
but in this case you need a deployment plan to point weblogic to the file. The ejb-jar.xml cannot be
external (see external=false)
The benefit of storing the weblogic-ejb-jar.xml is that your administrator can fine tune certain
configurations by using a deployment plan, instead of having to extract the contents from the jar file
and then repackage it again.
No need to worry about a clustered environment, you can place the jar and the deployment plan
on the server where the admin server is located, when you deploy an application you deploy it to
the cluster and everything is taken care off.
More information on deployment plans can be found here: http://download.oracle.com/docs/cd/E11035_01/wls100/deployment/config.html

Deploytool not deleting fields in ejb-jar.xml and sun-cmp-mappings.xml

Java(TM) 2 Platform, Enterprise Edition 1.4 SDK Developer Release deploytool
This situation was found on a simple, but original application using CMP EJB's. The database is MySQL using numeric id's and foreign keys.
I changed some fields in the database and went through the usual 14 attempts at getting deploytool to recognize a new schema without success. The one thing that is noticed is that when I tried to open the CMP display in the Entity selection the tool would not show any data, also it appears to lockup; however, if you select EJB in the choice box of the upper left you can get the view to close.
In desperation (mind you decoding machine generated XML is NOT my favorite activity) I looked at the descriptor viewer and notice fields existed in the descriptor that were deleted in the database. The tool had read the schema because the new fields were also present.
In sun-cmp-mappings.xml the old <cmp-field-mapping> definitions were still present. and in ejb-jar.xml the <query> and <cmp-field> were still present.
After deleting them out -- happy, happy, happy, joy, joy, joy. Deploytool accepted the new schema (keeping all the proper old stuff correctly. yea!!!) and a simple create mapping process brought the beans and database into sync.
I didn't want to report a bug, since I am actually new to EJB's so if anybody wishes to comment please do. I just wanted to provide a heads up in case this was something not noticed.
BTW I'm a recent expert at EJB's anybody got a job? :-)

Have you tried to unmap your fields and relationships?
Go through all your enterprise beans in the CMP Database window and click Unmap All until the Persistent Field Mappings table is empty of mappings. Then click Create Database Mappings, select the new schema, and verify the fields and relationships were mapped. This should clear out any old field mappings.
-Ian Evans

Orion-ejb-jar.xml is overwritten every deployment and not using from .jar

My application is an ear file containing a single jar and a war.
My configuration looks like:
/applications/<appname>/myejbs.jar
within myejbs.jar, exists meta-inf\orion-ejb-jar.xml
Every time I redeploy (copy .ear into /applications and restart server) a version of orion-ejb-jar.xml is copied into /application-deployments/myejbs/orion-ejb-jar.xml but it is not the version that I bundle within my jar. It appears this is the auto-generated version.
Why is this file being overwritten? I thought it should detect if a version of orion-ejb-jar already exists and leave it intact if so. Is there a config setting I've missed somewhere?

Well, we had the some problem.
We solved it when we wrote in the orion-ejb-jar.xml deployment version for actual oc4j.
example orion-ejb-jar.xml for oc4j 904:
<orion-ejb-jar deployment-version="9.0.4.0.0">
or
<orion-ejb-jar deployment-version="1.5.0">
example orion-ejb-jar.xml for oc4j 903:
<orion-ejb-jar deployment-version="9.0.3.0.0">
Zajo

Many EJB's and ejb-jar.xml

Similar Messages

Maybe you are looking for