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

Similar Messages

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

Files missing in the ear and client jar

Hi,
I'm following the examples to build a web service using ANT servicegen task. My
web service calls a lot of other java classes, and those java classes in turn
call other classes. When I used the following taskes to generate the service and
client code, I found the generated ear, war and client jar files only contain
the compiled classes which are used directly by the web service class. Those classes
called indirectly by web service are missing.
<target name="ear">
<servicegen
destEar="${build}/${ear_file}"
warName="${war_file}">
<service
javaClassComponents="com.iit.integration.txlife.txlife28.txlifeProcessor.TxlifeProcessor"
targetNamespace="${namespace}"
serviceName="TxlifeWebService"
serviceURI="/txlifews"
generateTypes="True"
expandMethods="True">
<client
packageName="com.iit.integration.txlife.txlife28.client"
clientJarName="${client_jar_file}"
/>
</service>
<classpath>
<pathelement path="${build}"/>
<pathelement path="${java.class.path}"/>
</classpath>
</servicegen>
</target>

<target name="client" depends="ear">
<clientgen
ear="${build}/${ear_file}"
warName="${war_file}"
packageName="com.iit.integration.txlife.txlife28.client"
clientJar="${client}/${client_jar_file}">
<classpath>
<pathelement path="${build}"/>
<pathelement path="${java.class.path}"/>
</classpath>
</clientgen>
So when I invoked the client code, I always got the class not found exception.
Not sure if I missed anything here.
Thanks a lot,
Henry
[build.xml]

Any required support classes have to be in the client's/server's classpath. Or
at least that's what I do.
"Henry Niu" <[email protected]> wrote:
>
>
>
Hi,
I'm following the examples to build a web service using ANT servicegen
task. My
web service calls a lot of other java classes, and those java classes
in turn
call other classes. When I used the following taskes to generate the
service and
client code, I found the generated ear, war and client jar files only
contain
the compiled classes which are used directly by the web service class.
Those classes
called indirectly by web service are missing.
<target name="ear">
<servicegen
destEar="${build}/${ear_file}"
warName="${war_file}">
<service
javaClassComponents="com.iit.integration.txlife.txlife28.txlifeProcessor.TxlifeProcessor"
targetNamespace="${namespace}"
serviceName="TxlifeWebService"
serviceURI="/txlifews"
generateTypes="True"
expandMethods="True">
<client
packageName="com.iit.integration.txlife.txlife28.client"
clientJarName="${client_jar_file}"
/>
</service>
<classpath>
<pathelement path="${build}"/>
<pathelement path="${java.class.path}"/>
</classpath>
</servicegen>
</target>

<target name="client" depends="ear">
<clientgen
ear="${build}/${ear_file}"
warName="${war_file}"
packageName="com.iit.integration.txlife.txlife28.client"
clientJar="${client}/${client_jar_file}">
<classpath>
<pathelement path="${build}"/>
<pathelement path="${java.class.path}"/>
</classpath>
</clientgen>
So when I invoked the client code, I always got the class not found exception.
Not sure if I missed anything here.
Thanks a lot,
Henry

EJB- HRS and Client Error

This is the error i get when i do the 1st part of the Human resource reservation in Jdeveloper tutorial:
what could cause the error:
C:\jdeveloper\jdk\bin\javaw.exe -ojvm -XXdebug,quiet,port1033 -classpath C:\jdeveloper\jdev\mywork\MyHRApplication\EJB-Tier\classes;C:\jdeveloper\jdev\lib\jdev-rt.jar;C:\jdeveloper\j2ee\home\lib\activation.jar;C:\jdeveloper\j2ee\home\lib\ejb.jar;C:\jdeveloper\j2ee\home\lib\jaas.jar;C:\jdeveloper\j2ee\home\lib\jaxp.jar;C:\jdeveloper\j2ee\home\lib\jcert.jar;C:\jdeveloper\j2ee\home\lib\jdbc.jar;C:\jdeveloper\j2ee\home\lib\jms.jar;C:\jdeveloper\j2ee\home\lib\jndi.jar;C:\jdeveloper\j2ee\home\lib\jnet.jar;C:\jdeveloper\j2ee\home\lib\jsse.jar;C:\jdeveloper\j2ee\home\lib\jta.jar;C:\jdeveloper\j2ee\home\lib\mail.jar;C:\jdeveloper\j2ee\home\oc4j.jar;C:\jdeveloper\lib\xmlparserv2.jar;C:\jdeveloper\lib\xmlcomp.jar Samplehr.hrAppClient
Debugger connected to local process.
javax.naming.NamingException: Lookup error: java.net.ConnectException: Connection refused: connect; nested exception is:
     java.net.ConnectException: Connection refused: connect
     java.lang.Object com.evermind.server.rmi.RMIContext.lookup(java.lang.String)
          RMIContext.java:134
     java.lang.Object javax.naming.InitialContext.lookup(java.lang.String)
          InitialContext.java:350
     void Samplehr.hrAppClient.main(java.lang.String[])
          hrAppClient.java:18
Debugger disconnected from local process.
Process exited with exit code 0.

Try below solution :
1. Take a copy of HReports.jar (Updated file) from the FR Report Server instance.
2. Bring the copied file to the User's Local Workstation and replace it with the one located under %HYPERION_HOME%\products\biplus\lib
3. Re-launch the FR Studio.
4. Open any of the FR Reports and now it can successfully print preview the FR Reports from the FR Studio.
above error happens if any FR patch is installed on FR server but not on client. So try above and if it does not resolve then make sure server and client has same patch level.

What is the relation betweent stubs and client jars?

I'm new to EJB and I was trying to have a stateless EJB A call another stateless EJB B that's in the same JVM but in another EAR? I believe to do this my EJB A needs to have the stubs from EJB B. Correct? How do I generate them using WSAD 5 if anyone knows? Are these stubs that I need part of client jars?
Vishal

Well I figured it out. For those that need to know the answer when trying to make a call from one ejb to another ejb that's in a different ear you have to get a client jar. The client jar has the remote home and remote interface stubs. The reason you need a client jars so that you can cast your reference after doing a JNDI lookup.
In WSAD (Websphere Studio 5) there is no real functionality built in to create client jar so what you have to do is create an EJB Jar and then delete all classes except for the stubs that I mentioned above. This client jar is then imported into your EJB project as a library jar. Now you can import this package in you EJB session bean and use it to cast you reference.
Vishal

FileGeneration/Wlappc not including local ejb interfaces in client jar

With the following setting in the EJB source:
@FileGeneration(
          remoteClass = Constants.Bool.TRUE,
          remoteHome = Constants.Bool.TRUE,
          remoteClassName = "ReportService",
          remoteHomeName = "ReportServiceHome",
          localClass = Constants.Bool.TRUE,
          localHome = Constants.Bool.TRUE,
          localClassName = "ReportSvc",
          localHomeName = "ReportSvcHome")
          @JarSettings(ejbClientJar = "dist/ReportFacadeClient.jar")
          @JndiName(remote="service-ReportFacade", local="local-ReportFacade")
          @Session(maxBeansInFreePool = "100",
                    initialBeansInFreePool = "10",
                    transTimeoutSeconds = "0",
                    type = Session.SessionType.STATELESS,
                    defaultTransaction = Constants.TransactionAttribute.SUPPORTS,
                    ejbName = "statelessSession",
                    enableCallByReference = Constants.Bool.TRUE)
Along with the "<ejb-client-jar>ReportServiceClient.jar</ejb-client-jar>" entry in the ejb-jar.xml
the ant build script invocation of wlappc successfully creates the "dist/ReportFacadeClient.jar" file as specified which includes the Remote Home and Remote interface, however the local definitions are absent.
It is confirmed that the wlcompile does create the local implementation and interface files, they are just missing from the client jar.
Do I need to manually append them to the jar or is there a configuration setting that I am missing to have this done automatically as is is done
for the remote interface?
Thanks.

Hi,
the local interface and local home is for local client which is within the same application (.ear). So local client needn't any client jar. it can always load the classes (local interface, local home, etc. ) it needs.
so there isn't needs to put local interface and local home to a client jar.
the client jar is for client out of the application, and it will be a remote invocation certainly.

Missing ejb stubs in client.jar

Hi,
When I deploy me ear file then sunOne will generate a clientEjb.jar for me automatically with the stubs inside.
Now I recently had to change the remote ejb's with local ejb's, but when I now deploy the ear the client jar does not include the stubs, yet then I get a javax.naming. NamingException: invoccation exception. If I include the stubs manually, it works.
Any idea why now suddenly these stubs are not included anymore
Version SunOne AS = Sun ONE Application Server 7.0.0_02
OS = Windows XP
J2EE=1.3
Thank you in advance

Hi joyv,
Please post the exception stack trace you observed. That will help to debug the problem further. Thanks.
--ken

Question about weblogic 8.x client jar.

We have some rich client applications that uses our J2EE service hosted on our Weblogic instance using T3. The actual weblogic.jar take about 40Mo. We don't want to add this 40Mo to client applications.
We see in weblogic 8 lib directory some thin jar (wlclient.jar) but il client uses these jars we have this error (By the way, we use Spring framework 1.0.2):
DEBUG [main] JndiTemplate$1.doInContext(119) | Looking up JNDI object with name 'com.foo.positionservice.bean.PositionService'
DEBUG [main] AbstractJndiLocator.lookup(182) | Successfully looked up object with jndiName 'com.foo.positionservice.bean.PositionService': value=[com.sun.corba.se.internal.iiop.CDRInputStream_1_0$1:IOR:000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000100000000000006ac000102000000000e31302e3235322e34392e313135001b64000000a80042454108010300000000124d534c4d616e6167656453657276657232000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000433313800000000014245412800000010000000000000000074a8daeef7d35d3900000006000000010000002c0000000000010020000000030001002000010001050100010001010000000003000101000001010905010001000000190000004e0000000000000046687474703a2f2f31302e3235322e34392e3131353a373031322f6265615f776c735f696e7465726e616c2f636c61737365732f506f736974696f6e2053657276696365402f0000000000001f000000040000000300000020000000040000000100000021000000580001000000000001000000000000002200000000004000000000000806066781020101010000001f0401000806066781020101010000000f7765626c6f67696344454641554c54000000000000000000000000000000000042454103000004d8000000000000000c726f756e642d726f62696e00010000000000003c636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636500000000020000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000100000000000001cc000102000000000e31302e3235322e34392e313135001b64000000a80042454108010300000000124d534c4d616e6167656453657276657232000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000433313800000000014245412800000010000000000000000074a8daeef7d35d3900000005000000010000002c0000000000010020000000030001002000010001050100010001010000000003000101000001010905010001000000190000004e0000000000000046687474703a2f2f31302e3235322e34392e3131353a373031322f6265615f776c735f696e7465726e616c2f636c61737365732f506f736974696f6e2053657276696365402f0000000000001f000000040000000300000020000000040000000100000021000000580001000000000001000000000000002200000000004000000000000806066781020101010000001f0401000806066781020101010000000f7765626c6f67696344454641554c5400000000000000000000000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000100000000000001cc000102000000000e7061722d6d736c746573743032001b64000000a80042454108010300000000124d534c4d616e6167656453657276657234000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a303030303030303030303030303030300000000000043331380000000001424541280000001000000000000000004104c46f39b6126a00000005000000010000002c0000000000010020000000030001002000010001050100010001010000000003000101000001010905010001000000190000004e0000000000000046687474703a2f2f7061722d6d736c7465737430323a373031322f6265615f776c735f696e7465726e616c2f636c61737365732f506f736974696f6e2053657276696365402f0000000000001f000000040000000300000020000000040000000100000021000000580001000000000001000000000000002200000000004000000000000806066781020101010000001f0401000806066781020101010000000f7765626c6f67696344454641554c540000000000000000000000000000000000000000000000000031896fa3]
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'PositionService' defined in (no description): Initialization of bean failed; nested exception is org.springframework.beans.FatalBeanException: Cannot create EJB proxy: EJB home [com.sun.corba.se.internal.iiop.CDRInputStream_1_0$1:IOR:000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000100000000000006ac000102000000000e31302e3235322e34392e313135001b64000000a80042454108010300000000124d534c4d616e6167656453657276657232000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000433313800000000014245412800000010000000000000000074a8daeef7d35d3900000006000000010000002c0000000000010020000000030001002000010001050100010001010000000003000101000001010905010001000000190000004e0000000000000046687474703a2f2f31302e3235322e34392e3131353a373031322f6265615f776c735f696e7465726e616c2f636c61737365732f506f736974696f6e2053657276696365402f0000000000001f000000040000000300000020000000040000000100000021000000580001000000000001000000000000002200000000004000000000000806066781020101010000001f0401000806066781020101010000000f7765626c6f67696344454641554c54000000000000000000000000000000000042454103000004d8000000000000000c726f756e642d726f62696e00010000000000003c636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636500000000020000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000100000000000001cc000102000000000e31302e3235322e34392e313135001b64000000a80042454108010300000000124d534c4d616e6167656453657276657232000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000433313800000000014245412800000010000000000000000074a8daeef7d35d3900000005000000010000002c0000000000010020000000030001002000010001050100010001010000000003000101000001010905010001000000190000004e0000000000000046687474703a2f2f31302e3235322e34392e3131353a373031322f6265615f776c735f696e7465726e616c2f636c61737365732f506f736974696f6e2053657276696365402f0000000000001f000000040000000300000020000000040000000100000021000000580001000000000001000000000000002200000000004000000000000806066781020101010000001f0401000806066781020101010000000f7765626c6f67696344454641554c5400000000000000000000000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000100000000000001cc000102000000000e7061722d6d736c746573743032001b64000000a80042454108010300000000124d534c4d616e6167656453657276657234000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a303030303030303030303030303030300000000000043331380000000001424541280000001000000000000000004104c46f39b6126a00000005000000010000002c0000000000010020000000030001002000010001050100010001010000000003000101000001010905010001000000190000004e0000000000000046687474703a2f2f7061722d6d736c7465737430323a373031322f6265615f776c735f696e7465726e616c2f636c61737365732f506f736974696f6e2053657276696365402f0000000000001f000000040000000300000020000000040000000100000021000000580001000000000001000000000000002200000000004000000000000806066781020101010000001f0401000806066781020101010000000f7765626c6f67696344454641554c540000000000000000000000000000000000000000000000000031896fa3] has no no-arg create() method
org.springframework.beans.FatalBeanException: Cannot create EJB proxy: EJB home [com.sun.corba.se.internal.iiop.CDRInputStream_1_0$1:IOR:000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000100000000000006ac000102000000000e31302e3235322e34392e313135001b64000000a80042454108010300000000124d534c4d616e6167656453657276657232000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000433313800000000014245412800000010000000000000000074a8daeef7d35d3900000006000000010000002c0000000000010020000000030001002000010001050100010001010000000003000101000001010905010001000000190000004e0000000000000046687474703a2f2f31302e3235322e34392e3131353a373031322f6265615f776c735f696e7465726e616c2f636c61737365732f506f736974696f6e2053657276696365402f0000000000001f000000040000000300000020000000040000000100000021000000580001000000000001000000000000002200000000004000000000000806066781020101010000001f0401000806066781020101010000000f7765626c6f67696344454641554c54000000000000000000000000000000000042454103000004d8000000000000000c726f756e642d726f62696e00010000000000003c636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636500000000020000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000100000000000001cc000102000000000e31302e3235322e34392e313135001b64000000a80042454108010300000000124d534c4d616e6167656453657276657232000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000433313800000000014245412800000010000000000000000074a8daeef7d35d3900000005000000010000002c0000000000010020000000030001002000010001050100010001010000000003000101000001010905010001000000190000004e0000000000000046687474703a2f2f31302e3235322e34392e3131353a373031322f6265615f776c735f696e7465726e616c2f636c61737365732f506f736974696f6e2053657276696365402f0000000000001f000000040000000300000020000000040000000100000021000000580001000000000001000000000000002200000000004000000000000806066781020101010000001f0401000806066781020101010000000f7765626c6f67696344454641554c5400000000000000000000000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a3030303030303030303030303030303000000000000100000000000001cc000102000000000e7061722d6d736c746573743032001b64000000a80042454108010300000000124d534c4d616e6167656453657276657234000000000000000000005b524d493a636f6d2e626e70706172696261732e6571642e6d736c2e706f736974696f6e736572766963652e6265616e2e506f736974696f6e5365727669636552656d6f7465486f6d653a303030303030303030303030303030300000000000043331380000000001424541280000001000000000000000004104c46f39b6126a00000005000000010000002c0000000000010020000000030001002000010001050100010001010000000003000101000001010905010001000000190000004e0000000000000046687474703a2f2f7061722d6d736c7465737430323a373031322f6265615f776c735f696e7465726e616c2f636c61737365732f506f736974696f6e2053657276696365402f0000000000001f000000040000000300000020000000040000000100000021000000580001000000000001000000000000002200000000004000000000000806066781020101010000001f0401000806066781020101010000000f7765626c6f67696344454641554c540000000000000000000000000000000000000000000000000031896fa3] has no no-arg create() method
It is working fine with weblogic.jar (40Mo)
Thx,
-emmanuel

naveen.g wrote:
How to get the path of the domain, where my application is running, in a java code?
For example, my domain path is "D:\bea\user_projects\domains\production". How to get this path dynamically?Please start a new topic instead of resurrecting an old and non-related thread and hijacking others' threads.

Fundamental questions on redo logs and rollbacks

Hi all,
Some basic questions, I really want to understand it very clearly.
Suppose that we have updated few records in a table. We know that the blocks to be updated will be fetched into buffer cache, they will be updated with new value and commited eventually. The questions I have are ,
1) What exact information will go to redo log ? is it a copy of the block before change and copy of the block after change ?
2) What exactly goes to rollback segment? is it copy of block before change (for update) and just the rowid for inserted row and the copy of block for a deleted row ?
3) Whatever we do, is it the whole block that goes to redo or rollback ? Means if there are 10 rows in the block and we update one of them, still whole block goes to redo or rollback ?
4) If we rollback, what goes where ? Is there anything that goes to redo if we rollback ?
Please explain.
Thanks.

Redo stores changes made in the database, and undo/rollback stores the reverse of those changes. Data blocks may be changed prior to a commit, and recorded in both locations.
So, when a database is recovered, redo is applied to the backup datafiles, rolling every change forward, and then undo is applied to reverse any uncomitted transactions.
Undo/rollback can also be used simply to roll back a transaction in an active instance. Redo is only used during instance recovery.
I don't know if this is tracked via the storage of block images, or if it just stores the change itself.
-cf

Ejb-client.jar

Hi,
I've got an EJB system that until now have been packaging as just a
bean jar and not bothering with a ejb-client.jar. I now want to
package as follows
a). A bean EAR file (containing bean jar, and dependency jars) - for
deploying on EJB server.
b). An app EAR file (containing WAR, containing ejb-client.jar).
The first part is done. The second raised questions about the contents
of the ejb-client.jar. I have packaged the Home/Remote interfaces and
all necessary utility classes (i.e omitting the Local/LocalHome/EJB
classes). What I need to know is what goes in there in terms of
descriptors.
Do I just package the exact same ejb-jar.xml, jboss.xml,
jbosscmp-jdbc.xml, weblogic-ejb-jar.xml, weblogic-cmp-rdbms-jar.xml ?
or do I have to change these in some way ?
Do I also add the ejb-client-jar tag to the ejb-jar.xml ? (would this
also go in the ejb-jar.xml that goes in the bean jar ?) ... and indeed
what would I put in there ... just the name of ejb-client-jar file
even though its only being packaged into any application WAR (what
purpose does it serve) ?
TIA

The ejb-link value should include pathnames relative to the top level of the EAR
file.
<ejb-link>../my_beans-client.jar#CurrencyExchange</ejb-link>
Andy Jefferson <[email protected]> wrote:
Deepak Vohra wrote:
An ejb-client.jar contains the class files, the home and remote interfaces
and the primary key class, a client program needs to call the EJBs
contained in the ejb-jar file.
Also, ejb-client.jar contains a copy of any classes from the ejb-jarfile
that
are referenced by the home and remote interfaces and the primary key
class. Deployment descriptors are not required in the ejb-client.jar.
ejb-client-jar element is not a required element in ejb-jar.xml. If
ejb-client-jar.xml is specified in ejb-jar.xml ejbc generates the
ejb-clent.jar file.
Thx. I'm not interested in using any server-specific tools (like ejbc)
since
I'm deploying to multiple servers and so am generating the ejb-client
jar
myself in my build process. In this context, what purpose does the
<ejb-client-jar> tag in the ejb-jar.xml descriptor have ? Why does the
beans jar need to know anything about where the client stubs are ?
As far as I can tell I'm including the right things in my ejb-client.jar,
and I've tried deploying my web-app EAR to WebLogic 7.0 and I always
get
that it can't find the ejb-link elements. What i've got in my EAR is
my_app.war
META-INF/application.xml
and in the WAR
my JSP files
WEB-INF/web.xml
WEB-INF/jboss-web.xml
lib/my_beans-client.jar
In the WEB-INF I have ejb-ref's like the following
<ejb-ref >
<ejb-ref-name>ejb/CurrencyExchangeHome</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>my_domain.CurrencyExchangeHome</home>
<remote>my_domain.CurrencyExchangeRemote</remote>
<ejb-link>my_beans-client.jar#CurrencyExchange</ejb-link>
</ejb-ref>
Should I be putting the my_beans-client.jar in the EAR and not the WAR
Seems I am missing something, but not sure what exactly.

EJB client needs both source and generated jars?

From within JDeveloper, I created a basic EJB with a default package called EJBHello. Here is my directory structure after building and deploying this EJB:
h:\EJBHello\EJBHello\EJBHome.java, etc.
h:\EJBHello\EJBsource.jar
h:\EJBHello\EJBgenerated.jar
h:\EJBHello\EJBClient.java
With only EJBgenerated.jar in the classpath, the client ran fine in this environment. However, when I renamed h:\EJBHome\EJBHome to h:\EJBHome\temp, the client would no longer run - java said it could not find EJBHello\EJBHome.class. I then added EJBsource.jar to the classpath, and the client would once again run. Does this mean that, in general, I must ship both the source and generated jars with the client classes?

You need to deploy the class files specific to your client as well as the generated stubs for the EJB.

Client EJB JNDI lookup broken in OC4J 9.0.2?

I have a client program that connects to an EJB in the application server and invokes methods on it. If it look up the EJB using the actual JNDI binding, it works fine. If I look it up in java:comp/env (and use the ejb-ref in application-client.xml and ejb-ref-mapping in orion-application-client.xml) the client program catches the following exception:
caught : javax.naming.NameNotFoundException: No object bound for java:comp/env/ejb/logging/Logger
javax.naming.NameNotFoundException: No object bound for java:comp/env/ejb/logging/Logger
at com.sun.enterprise.naming.java.javaURLContext.lookup(javaURLContext.java:116)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at com.mycompany.common.logging.ejb.test.LoggerEJBTest.main(LoggerEJBTest.java:37)
Now, assuming I don't have any typos (and I'd be thrilled if someone pointed it out if that were the case), then it looks like this is a bug in OC4J 9.0.2: the ejb-ref and ejb-ref-mapping elements do not work. For the record, I am using the same ejb-ref and ejb-ref-mapping elements for a servlet's web.xml and orion-web.xml, respectively, without problems.
Here are relevant file excerpts:
LoggerEJBTest.java:
String hostName = "localhost";
String hostPort = "23791";
String userName = "abc";
String password = "def";
String providerURL = "ormi://" + hostName + ":" + hostPort + "/ghi";
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.ApplicationClientInitialContextFactory");
env.put(Context.PROVIDER_URL, providerURL);
env.put(Context.SECURITY_PRINCIPAL, userName);
env.put(Context.SECURITY_CREDENTIALS, password);
System.out.println("create initial context");
Context context = new InitialContext(env);
System.out.println("get home object");
//works when uncommented
//Object homeObject = context.lookup("logging/Logger");
//broken:
Object homeObject = context.lookup("java:comp/env/ejb/logging/Logger");
ejb-jar.xml:
<?xml version="1.0"?>
<!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>
<description>abc</description>
<display-name>abc</display-name>
<enterprise-beans>
<session>
<description>Logger Bean</description>
<display-name>Logger</display-name>
<ejb-name>Logger</ejb-name>
<home>com.mycompany.common.logging.ejb.LoggerHome</home>
<remote>com.mycompany.common.logging.ejb.Logger</remote>
<ejb-class>com.mycompany.common.logging.ejb.LoggerBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
orion-ejb-jar.xml:
<?xml version="1.0"?>
<!DOCTYPE orion-ejb-jar PUBLIC "-//Evermind//DTD Enterprise JavaBeans 2.0 runtime//EN" "http://xmlns.oracle.com/ias/dtds/orion-ejb-jar.dtd">
<orion-ejb-jar>
     <enterprise-beans>
          <session-deployment name="Logger" location="logging/Logger">
     </enterprise-beans>
</orion-ejb-jar>
application-client.xml:
<?xml version="1.0"?>
<!DOCTYPE application-client PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application Client 1.3//EN" "http://java.sun.com/dtd/application-client_1_3.dtd">
<application-client>
     <display-name>logging test</display-name>
<ejb-ref>
<ejb-ref-name>ejb/logging/Logger</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.mycompany.common.logging.ejb.LoggerHome</home>
<remote>com.mycompany.common.logging.ejb.Logger</remote>
<ejb-link>Logger</ejb-link>
</ejb-ref>
</application-client>
orion-application-client.xml:
<?xml version="1.0"?>
<!DOCTYPE orion-application-client PUBLIC "-//Evermind//DTD J2EE Application-client runtime 1.2//EN" "http://xmlns.oracle.com/ias/dtds/orion-application-client.dtd">
<orion-application-client>
<ejb-ref-mapping location="logging/Logger" name="ejb/logging/Logger" />
</orion-application-client>

As far as I know, the only way to lookup an EJB (deployed to
OC4J) from a regular java class using the "ApplicationClientInitialContextFactory"
class and the logical JNDI name is to include your regular java
class (i.e. the client) in your application's EAR file (the file
you use to deploy your application to OC4J).OK, but that sounds like a pretty silly constraint. Shouldn't the ApplicationClientInitialContextFactory know how to do the mapping using the application-client.xml and orion-application-client.xml settings? What does the OC4J server provide that makes this magically work?
From the information you have supplied, it appears that you may
not want to include your client (java) class in your EAR file.That is correct. It is an integration test program, not meant to be deployed into the application server.
So now the question is, "Do you want to make your client part
of your J2EE application, and include it in the application
EAR file?"
If you do, then you have made several mistakes which prevent
you from doing that, but I don't want to explain further, since
you may not want to do that, anyway!Not applicable. But on that topic, aside from being able to auto-start a client application within the OC4J JVM, are there any other reasons why I might want to deploy a client in that manner? I mean, honestly, these things are called "clients" and "servers" for a reason.
Now if you have been reading other postings to this forum,
and if you have read the documentation for OC4J, you would
know that it requires J2SDK 1.3.1 only (not 1.4.0).I am well aware of the other postings on that topic. I am, however, counting on Oracle to live up to their promise to certify 1.4 with with the next update to OC4J:
Limits of 10g
That aside, I already consider OC4J 9.0.2 to be a broken product at this point anyway, so hacking it to use Java 1.4 doesn't bother me that much. OC4J 9.0.2 works about as well with Java 1.4 as with Java 1.3, assuming one replaces the tools.jar. The other major incompatibility is that Oracle SOAP breaks if a web service EJB home&remote interface is compiled with Java 1.4:
http://forums.oracle.com/forums/message.jsp?id=936894
Alas, we're using Apache SOAP 2.3 rather than the ass-backwards stuff in OC4J, anyways, so there's no problem.

ejb-client-jar example from the core specification

Hello all,
the ejb3.0 specification says (chapter 60 page 241):
the jar file that contains the client should contain one of the following:
a reference to the ejb-client JAR file
a reference to the ejb-jar file that contains the client view classes
a copy of the client view classes There is also an example on page 242:
In this example, the Bean Provider has chosen to package the enterprise bean client view classes in a
separate jar file and to reference that jar file from the other jar files that need those classes. Those classes
are needed both by ejb2.jar, packaged in the same application as ejb1.jar, and by ejb3.jar,
packaged in a different application. Those classes are also needed by ejb1.jar itself because they
define the remote interface of the enterprise beans in ejb1.jar, and the Bean Provider has chosen the
by reference approach to making these classes available.
The deployment descriptor for ejb1.jar names the client view jar file in the ejb-client-jar
element. Because ejb2.jar requires these client view classes, it includes a Class-Path reference to
ejb1_client.jar.
The Class-Path mechanism must be used by components in app2.ear to reference the client view jar
file that corresponds to the enterprise beans packaged in ejb1.jar of app1.ear. Those enterprise
beans are referenced by enterprise beans in ejb3.jar. Note that the client view jar file must be
included directly in the app2.ear file.
    app1.ear:
        META-INF/application.xml
        ejb1.jar Class-Path: ejb1_client.jar
            deployment descriptor contains:
                <ejb-client-jar>ejb1_client.jar</ejb-client-jar>
        ejb1_client.jar
        ejb2.jar Class-Path: ejb1_client.jar
    app2.ear:
        META-INF/application.xml
        ejb1_client.jar
        ejb3.jar Class-Path: ejb1_client.jarNow finally my questions are:
1. Why did we need to include the ejb1_client.jar in app2.ear (or even in app1.ear), wasn't it enough to deploy the ejb1_client.jar separately then refer to it (using class-path in Manifest, or may be just by using <ejb-client-jar>) as the bullets quoted first suggest?
2. How come we didn't need to use <ejb-client-jar> for ejb2.jar
3. Since both of ejb1.jar and ejb2.jar are packaged in app1.ear couldn't we simply refer to the ejb1_client.jar in the Manifest file of app1.ear?
Please, I appreciate your input on this

I am guessing here and please correct me if I am wrong:
ejb1.jar uses interfaces in ejb1_client.jar as the interface for some of the beans so we needed to use ejb-client-jar and we needed a reference in the manifest file.
ejb2.jar uses some of the claess/interfaces as may be a return type but not as an interface for one of its beans so we didn't need to use ejb-client-jar but we needed an entry in the manifest file.
regarding app1.ear, we can put the ejb1_client.jar in the META-INF/lib app1.ear without the need for any entries in the manifest files.
Edited by: malrawi on Jun 14, 2009 11:59 PM

Ejb-ref and JNDI lookup problem

Hi,
I use WLS6.1sp2. I created one EntityBean and SessionBean jar files. I tried to
use session bean to refer entity bean, I failed. The details are as following:
In EntityBean's weblogic-ejb-jar.xml, I set:
<jndi-name>cabin.CabinHome</jndi-name>
In sessionbean's ejb-jar.xml
<ejb-ref>
<ejb-ref-name>ejb/CabinHome</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>com.titan.cabin.CabinHome</home>
<remote>com.titan.cabin.Cabin</remote>
</ejb-ref>
In sessionbean's weblogic-ejb-jar.xml
<reference-descriptor>
     <ejb-reference-description>
          <ejb-ref-name>ejb/CabinHome</ejb-ref-name>
          <jndi-name>ejb/CabinHome</jndi-name>
     </ejb-reference-description>
</reference-descriptor>
At sessionbean's client, I use
javax.naming.Context jndiContext = getInitialContext();
Object obj = jndiContext.lookup("java:comp/env/ejb/CabinHome");
When I run client file, I get the following error message:
- with nested exception:
[javax.naming.LinkException: [Root exception is javax.naming.NameNotFoundException:
Unable to resolve ejb.CabinHome Resolved: '' Unresolved:'ejb' ; remaining name
'CabinHome']; Link Remaining Name: 'ejb/CabinHome']>
javax.naming.LinkException: . Root exception is javax.naming.NameNotFoundException:
Unable to resolve ejb.CabinHome Resolved: '' Unresolved:'ejb' ; remaining name
'CabinHome'
     <<no stack trace available>>
--------------- nested within: ------------------
javax.ejb.EJBException
- with nested exception:
[javax.naming.LinkException: [Root exception is javax.naming.NameNotFoundException:
Unable to resolve ejb.CabinHome Resolved: '' Unresolved:'ejb' ; remaining name
'CabinHome']; Link Remaining Name: 'ejb/CabinHome']
     at com.titan.travelagent.TravelAgentBean.listCabins(TravelAgentBean.java:45)
     at com.titan.travelagent.TravelAgentBean_a4c3ph_EOImpl.listCabins(TravelAgentBean_a4c3ph_EOImpl.java:37)
     at com.titan.travelagent.TravelAgentBean_a4c3ph_EOImpl_WLSkel.invoke(Unknown
Source)
     at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:298)
     at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:93)
     at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:267)
     at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:22)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
####<Feb 1, 2002 11:32:40 PM PST> <Info> <Management> <dj> <travelServer> <ExecuteThread:
'14' for queue: 'default'> <system> <> <140009> <Configuration changes for domain
saved to the repository.>
Do you know what's wrong? how to fix this problem?
Thanks in advance.
DJ

Slava,
I took "cabin." out from weblogic-ejb-jar.xml, I got the same error.
DJ
"Slava Imeshev" <[email protected]> wrote:
Hi DJ,
I think you don't need "cabin." in weblogic-ejb-jar.xml :
<jndi-name>cabin.CabinHome</jndi-name>
Regards,
Slava Imeshev
"DJ" <[email protected]> wrote in message
news:[email protected]...
Hi,
I use WLS6.1sp2. I created one EntityBean and SessionBean jar files.I
tried to
use session bean to refer entity bean, I failed. The details are asfollowing:
In EntityBean's weblogic-ejb-jar.xml, I set:
<jndi-name>cabin.CabinHome</jndi-name>
In sessionbean's ejb-jar.xml
<ejb-ref>
<ejb-ref-name>ejb/CabinHome</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>com.titan.cabin.CabinHome</home>
<remote>com.titan.cabin.Cabin</remote>
</ejb-ref>
In sessionbean's weblogic-ejb-jar.xml
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>ejb/CabinHome</ejb-ref-name>
<jndi-name>ejb/CabinHome</jndi-name>
</ejb-reference-description>
</reference-descriptor>
At sessionbean's client, I use
javax.naming.Context jndiContext = getInitialContext();
Object obj = jndiContext.lookup("java:comp/env/ejb/CabinHome");
When I run client file, I get the following error message:
- with nested exception:
[javax.naming.LinkException: [Root exception is
javax.naming.NameNotFoundException:>> Unable to resolve ejb.CabinHome Resolved: '' Unresolved:'ejb' ; remaining>name>> 'CabinHome'; Link Remaining Name: 'ejb/CabinHome']>
javax.naming.LinkException: . Root exception isjavax.naming.NameNotFoundException:
Unable to resolve ejb.CabinHome Resolved: '' Unresolved:'ejb' ; remainingname
'CabinHome'
<<no stack trace available>>
--------------- nested within: ------------------
javax.ejb.EJBException
- with nested exception:
[javax.naming.LinkException: [Root exception is
javax.naming.NameNotFoundException:>> Unable to resolve ejb.CabinHome Resolved: '' Unresolved:'ejb' ; remaining>name>> 'CabinHome'; Link Remaining Name: 'ejb/CabinHome']
atcom.titan.travelagent.TravelAgentBean.listCabins(TravelAgentBean.java:45)
atcom.titan.travelagent.TravelAgentBean_a4c3ph_EOImpl.listCabins(TravelAgentBe
an_a4c3ph_EOImpl.java:37)
atcom.titan.travelagent.TravelAgentBean_a4c3ph_EOImpl_WLSkel.invoke(Unknown
Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:298)
atweblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java
:93)
atweblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:267)
atweblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
2)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
####<Feb 1, 2002 11:32:40 PM PST> <Info> <Management> <dj> <travelServer><ExecuteThread:
'14' for queue: 'default'> <system> <> <140009> <Configuration changesfor
domain
saved to the repository.>
Do you know what's wrong? how to fix this problem?
Thanks in advance.
DJ

Using JarSettings to generate EJB client jar, but supported classes missed

Appreciated for any comments in advance.
I am using @jarSetting to generate EJB client jar file from workshop 9.2. The remote method of EJB has one input parameter that is defined as an interface. The interface is included in client jar, but the implementation of this interface is not.
Please advise how I can add the implementation of this interface to client jar?
Best Regards,
James

Hi James,
I believe the algorithm for creating the client jar is to simply inspect the EJB interfaces using reflection and to include all user defined classes and exceptions that are referenced by the interfaces. In your case, it sounds like a class is not being included because it is not directly referenced by one of the EJB interfaces.
I think the client jar creation algorithm can be described as "best effort" and unfortunately, it does not always end up including all classes needed by the client. I would recommend you add the additional classes manually using the jar tool.
- Matt

Fundamental question on EJB, JNDI and client jars

Similar Messages

Maybe you are looking for