[Q] ClassNotFoundException for EJB stub in Webstart application

Hi,
Why does an EJB client application running in Webstart need to be explicitly provided
with the EJB stubs, while the same application run on the command-line is able
to download the stubs from the server automatically?
To elaborate, I have a Java application running in Webstart 1.0.1, doing a JNDI
lookup of an EJB on a WLS5.1 SP9 server on NT. Unless I jar up the EJB stub classes
(SomeBeanHomeImpl_ServiceStub etc.) and define them in the Webstart application,
I get the exception given at the end of this mail.
Now, what I don't understand is, when I run the same application directly on the
command line (i.e., not in Webstart), it works just fine; it is somehow able to
download the stubs from the server. Why does it behave differently in Webstart,
and is there any way around it, so that I don't have to deploy the stubs along
with my client application?
Thanks,
Ravi
The exception is given below:
javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException:
class SomeBeanHomeImpl_ServiceStub previously not found
 at weblogic.rjvm.MsgAbbrev.read(MsgAbbrev.java:181)
 at weblogic.socket.JVMAbbrevSocket.readMsgAbbrevs(JVMAbbrevSocket.java:505)
 at weblogic.rjvm.MsgAbbrevInputStream.prime(MsgAbbrevInputStream.java:134)
 at weblogic.rjvm.RJVMImpl.dispatch(RJVMImpl.java:610)
 at weblogic.rjvm.ConnectionManagerClient.handleRJVM(ConnectionManagerClient.java:34)
 at weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:630)
 at weblogic.socket.JVMAbbrevSocket.dispatch(JVMAbbrevSocket.java:393)
 at weblogic.socket.JVMSocketT3.dispatch(JVMSocketT3.java:342)
 at weblogic.socket.SSLFilter.dispatch(SSLFilter.java:226)
 at weblogic.socket.JavaSocketMuxer.processSockets(JavaSocketMuxer.java:247)
 at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
--------------- nested within: ------------------
weblogic.rmi.UnmarshalException: Unmarshalling return
- with nested exception:
[java.lang.ClassNotFoundException: class SomeBeanHomeImpl_ServiceStub previously
not found]
 at weblogic.jndi.toolkit.BasicWLContext_WLStub.lookup(BasicWLContext_WLStub.java:256)
 at weblogic.jndi.toolkit.WLContextStub.lookup(WLContextStub.java:545)
 at javax.naming.InitialContext.lookup(Unknown Source)
 at Client.lookupHome(Client.java:118)
 at Client.<init>(Client.java:29)
 at Client.main(Client.java:67)
 at java.lang.reflect.Method.invoke(Native Method)
 at com.sun.javaws.Launcher.executeApplication(Unknown Source)
 at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
 at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
 at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
 at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
 at com.sun.javaws.Launcher.run(Unknown Source)
 at java.lang.Thread.run(Unknown Source)

It is an issue with Webstart - something regarding the classloader.
I think you need some code that does something like this:
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
"Ravi Shankar" <[email protected]> wrote in message
news:[email protected]...
>
Hi,
Why does an EJB client application running in Webstart need to beexplicitly provided
with the EJB stubs, while the same application run on the command-line isable
to download the stubs from the server automatically?
To elaborate, I have a Java application running in Webstart 1.0.1, doing aJNDI
lookup of an EJB on a WLS5.1 SP9 server on NT. Unless I jar up the EJBstub classes
(SomeBeanHomeImpl_ServiceStub etc.) and define them in the Webstartapplication,
I get the exception given at the end of this mail.
Now, what I don't understand is, when I run the same application directlyon the
command line (i.e., not in Webstart), it works just fine; it is somehowable to
download the stubs from the server. Why does it behave differently inWebstart,
and is there any way around it, so that I don't have to deploy the stubsalong
with my client application?
Thanks,
Ravi
The exception is given below:
javax.naming.CommunicationException. Root exception isjava.lang.ClassNotFoundException:
class SomeBeanHomeImpl_ServiceStub previously not found
at weblogic.rjvm.MsgAbbrev.read(MsgAbbrev.java:181)
atweblogic.socket.JVMAbbrevSocket.readMsgAbbrevs(JVMAbbrevSocket.java:505)
at weblogic.rjvm.MsgAbbrevInputStream.prime(MsgAbbrevInputStream.java:134)
at weblogic.rjvm.RJVMImpl.dispatch(RJVMImpl.java:610)
atweblogic.rjvm.ConnectionManagerClient.handleRJVM(ConnectionManagerClient.jav
a:34)
at weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:630)
at weblogic.socket.JVMAbbrevSocket.dispatch(JVMAbbrevSocket.java:393)
at weblogic.socket.JVMSocketT3.dispatch(JVMSocketT3.java:342)
at weblogic.socket.SSLFilter.dispatch(SSLFilter.java:226)
atweblogic.socket.JavaSocketMuxer.processSockets(JavaSocketMuxer.java:247)
atweblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
--------------- nested within: ------------------
weblogic.rmi.UnmarshalException: Unmarshalling return
- with nested exception:
[java.lang.ClassNotFoundException: class SomeBeanHomeImpl_ServiceStub
previously> not found
atweblogic.jndi.toolkit.BasicWLContext_WLStub.lookup(BasicWLContext_WLStub.jav
a:256)
at weblogic.jndi.toolkit.WLContextStub.lookup(WLContextStub.java:545)
at javax.naming.InitialContext.lookup(Unknown Source)
at Client.lookupHome(Client.java:118)
at Client.<init>(Client.java:29)
at Client.main(Client.java:67)
at java.lang.reflect.Method.invoke(Native Method)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Similar Messages

What data binding framework to use for EJB(JPA) - Swing desktop application

Hi!
I am developing EJB server application which mostly uses the same entities and session EJB's both for web and for desktop user interface. While JSF is working nicely, I am stuck with necessity to make decision with data binding framework to use for desktop application - I investigated:
- JSR295 reference impementation at java.net (beans binding)
- Eclipse JFace
- JSR295 implementation at kenai.com (better beans binding)
- JGoodies binding
At present I like JGoodies, but I am not sure whether I am not missing something - I guess - large enterprises should develop a lot of desktop applications as well and what binding framework they are using?

user454720 wrote:
At present I like JGoodies, but I am not sure whether I am not missing something - I guess - large enterprises should develop a lot of desktop applications as well and what binding framework they are using?No, not really. I create them sometimes but they are service tools, not part of the main application framework. Generally you keep everything on the server, web based - this keeps it secure, accessible and contained. With all the web 2.0 javascript toolkits available nowadays you can go quite far creating a desktop experience in a browser, with limitations.

RMI Timout for EJB Stubs

I can get RMI timeouts working by manually adding timeout="N" to the
XXX_EOImplRTD.xml file in the compiled EJB jar. For example:
<rmi Name="ejb.XXX_EOImpl">
<cluster clusterable="true" />
<method name="*" timeout="500" />
</rmi>
Is there a way to set the timeout by passing a parameter to ejbc or
adding a tag to the weblogic-ejb-jar.xml?
Thanks,
Bob

I didn't find any
Bob Lee <[email protected]> wrote:
I can get RMI timeouts working by manually adding timeout="N" to the
XXX_EOImplRTD.xml file in the compiled EJB jar. For example:
<rmi Name="ejb.XXX_EOImpl">
<cluster clusterable="true" />
<method name="*" timeout="500" />
</rmi>
Is there a way to set the timeout by passing a parameter to ejbc or
adding a tag to the weblogic-ejb-jar.xml?
Thanks,
Bob--
Dimitri

Excessive cxs socket connections created for ejb access

We are seeing a large number of TCP connections being created to the cxs engine for ejb access in our application.
We are running iPlanet application server 6.0, sp3 on Solaris 8. We have a web application that accesses a singleton component running in a kjs engine. That singleton accesses cmp entity beans and stateless session beans for serving client requests over the RMI/IIOP bridge. When three clients are connected and making requests, the number of TCP connections to the IIOP port (9010) starts to increase until everything freezes. I believe the "freezing" of the client apps is due to the open socket limit of 1024 being exceeded. According to the developer doc we can increase rlim_fd_max to 8192 to fix that problem.
However, my question is why are there an increasing number of socket connections? We are caching the ejb instances in the singleton so we should not be creating a large pool of EJBs. I have verfied the large number of sockets using netstat and also using RMI runtime logging in the kjs engine.
Does anyone have any ideas what could be happening here?
Thanks,
Mark

I noticed that most of the TCP connections are made to port 32787. Can anyone from iPlanet tell me what is listening on this port? The large number of socket connections is really tying up server resources.
Thanks,
Mark

Global Application Parameters for EJB

Hello all, I did a search for this on these forums and there are there a TON of threads of developers wanting to implement the classic Singleton pattern so that all EJB's of an application can access "Global Application Parameters". Most of these I've been reading achieve this by workarounds that breakdown at the clustering level, since Singletons won't span multiple JVMs.
Suppose you deploy an EAR that only has EJB jars, so you don't have access to all the convenience of the web tier (context parameters, context Initialization, etc.), so there is no way for your EJB's to detect/intercept an "Application Startup" event and load any necessary values into a Global Application parameter repository.
This seems such a widely demanded functionality that I wonder if there now a "best practice" way to achieve equivalent of the Singleton pattern in the EJB world that works nicely in a clustered environment?

I have the same problem
Thanks

EJB stubs not updated

Hi all,
Question - does anyone where the EJB stubs are stored? Can you find them on the hard drive?
It appears as if my EJB stubs are not being updated after I update my ear deployment (using the Weblogic 9 console). I added a new create method to one of my entity beans and when I try to call it I get java.lang.AbstractMethodError.
I wrote some debug code. After I lookup and narrow the home interface I printout the class name and all the methods (and thier parameters).
The home class name is ImportFilesHomeStub (obviously a stub), and the only create method this stub has is the original one. I even deleted the old create method from the bean and the home interface, deleted the deployment, restarted the weblogic server and redeployed the new .ear file, yet the stub still shows only the old create method.
The original create method for my ImportFiles entity took a single parameter - a ImportFilesBean object. The new create method takes three parameters - two Strings and a BigDecimal.
After rebuilding the .ear file and updating the deployment the debug shows that the stub has not changed.
I looked in the files I found in the 'D:\bea\user_projects\domains\base_domain\servers\ManagedServer_1\cache\EJBCompilerCache\' folder and they show the new create method, no evidence of the old one.
Does anyone know what could be happening here, or how to force the stubs to be regenerated?
thanks

I neglected to state that I am calling this EJB from a java client application. Also I am not explicitly generating the stubs using appc, but rather relying on the Weblogic Server to generate them at runtime.
thanks

Location of ejbc Utility for generating stub and skeleton in SunONe.

Hi everybody,
I am using Sun One Application Server 7 update 2. Looking for the location of ejbc utility in filesystem for generating stub and skeleton.. Any help regarding this will be appreciated.
Thanks,
Santa

Try the following forum (about EJB technology)
http://forum.java.sun.com/forum.jspa?forumID=13

EJB stub and skeleton code

I would like to examine the EJB stub and skeleton code that OC4J is generating for my applications. Is there a way to do this?

The stub and skeleton code is built into the $OC4J_HOME/application_deployments... The file is called deployment.cache which is a ZIP file of the stubs and skeleton code.

Options for EJB - Corba - correct?

Hi,
I'm looking at the options for EJB->CORBA and CORBA->EJB method calls in Weblogic Server 5.1 (although we may be moving to 6 soon)
We are currently using CORBA 2.1 C++ code, and are looking for a migration path into EJBs.
I've tried to pull together small list of our options, with apologies to Eduardo Ceballos who wrote most of this text originally, and anyone else who's work is included.
Does any one have the time to read the below, and make any comments on important options that I've missed, or pitfalls that they can see?
Thankyou in advance;
Notes:
-- RMI over IIOP is only available under JDK 1.3
-- if we use a pre Corba 2.3 implementation (as we currently are), only primitive types may be passed (no OBV available).
-- Another option is to use WebLogic Enterprise, but we are currently using WebLogic Server. ‘WebLogic Enterprise Connectivity gives you the ability to create IIOP connection pools to a BEA WebLogic Enterprise, allowing you to execute WebLogic Enterprise CORBA objects from WebLogic Server servlets and Enterprise JavaBeans.’
Calling from a WLS into a CORBA server:
========================================
There are several variations on two ways:
1. expose the CORBA interface;
To expose the CORBA interface, you collocate the ORB of your choice within the WLS instance and bind CORBA stubs into the JNDI tree as needed. The application looks up CORBA objects and uses the CORBA server interfaces as you would regardless of WLS.
This is an example of designing the RMI interface so that it maps in a usable way to the IDL interface.
2. hide the CORBA interface.
To hide the CORBA interface, create a RMI interface and a RMI server class; run 'weblogic.rmic -iiop -idl ...' on that class; take the resulting idl and add it to the interfaces which the CORBA servers implement. To gain access to the CORBA servers, use COSNaming to bind the CORBA servers into the WLS JNDI tree. As above, the application looks up the CORBA servers in the JNDI tree, but in this case the application uses the RMI-IIOP stubs to communicate with the CORBA servers.
This is an example of adding RMI interfaces to existing CORBA servers to establish some level of connectivity.
If you are using an RMI-IIOP implementation of some sort, then you are effectively hiding the CORBA interface, except you'd ignore any of work that would be done at the IDL level.
Note: We should use rmic and the –noValueTypes flag (as we aren’t using Orbix 2.3).
Calling from a Corba server into WLS
======================================
It is possible to host an Orb in the app server, contained within a WebLogic startup class. This will allow Corba calls to be delegated to app-server components (see option 1, above).
Thanks again.

Comments inline....
G Morgan wrote:
Hi,
I'm looking at the options for EJB->CORBA and CORBA->EJB method calls in Weblogic Server 5.1 (although we may be moving to 6 soon)Yes, move to 6.0.
>
>
We are currently using CORBA 2.1 C++ code, and are looking for a migration path into EJBs.
I've tried to pull together small list of our options, with apologies to Eduardo Ceballos who wrote most of this text originally, and anyone else who's work is included.
Does any one have the time to read the below, and make any comments on important options that I've missed, or pitfalls that they can see?
Thankyou in advance;As far as I can tell, pre-2.3 ORBs can not handle type ids that start with "RMI:". So pretty much the only option at the moment with a pre-2.3 ORB is to delegate through a colocated ORB. As with the the previous response, it's a good idea to host the ORB in a WLS client, that way if the ORB goes south, it doesn't take the server with it.
>
>
Notes:
-- RMI over IIOP is only available under JDK 1.3
-- if we use a pre Corba 2.3 implementation (as we currently are), only primitive types may be passed (no OBV available).
-- Another option is to use WebLogic Enterprise, but we are currently using WebLogic Server. ‘WebLogic Enterprise Connectivity gives you the ability to create IIOP connection pools to a BEA WebLogic Enterprise, allowing you to execute WebLogic Enterprise CORBA objects from WebLogic Server servlets and Enterprise JavaBeans.’
Calling from a WLS into a CORBA server:
========================================
There are several variations on two ways:
1. expose the CORBA interface;
To expose the CORBA interface, you collocate the ORB of your choice within the WLS instance and bind CORBA stubs into the JNDI tree as needed. The application looks up CORBA objects and uses the CORBA server interfaces as you would regardless of WLS.
This is an example of designing the RMI interface so that it maps in a usable way to the IDL interface.
2. hide the CORBA interface.
To hide the CORBA interface, create a RMI interface and a RMI server class; run 'weblogic.rmic -iiop -idl ...' on that class; take the resulting idl and add it to the interfaces which the CORBA servers implement. To gain access to the CORBA servers, use COSNaming to bind the CORBA servers into the WLS JNDI tree. As above, the application looks up the CORBA servers in the JNDI tree, but in this case the application uses the RMI-IIOP stubs to communicate with the CORBA servers.
This is an example of adding RMI interfaces to existing CORBA servers to establish some level of connectivity.
If you are using an RMI-IIOP implementation of some sort, then you are effectively hiding the CORBA interface, except you'd ignore any of work that would be done at the IDL level.
Note: We should use rmic and the –noValueTypes flag (as we aren’t using Orbix 2.3).
Calling from a Corba server into WLS
======================================
It is possible to host an Orb in the app server, contained within a WebLogic startup class. This will allow Corba calls to be delegated to app-server components (see option 1, above).
Thanks again.

Super 1.5 - source code level tracing for EJB, JSP and others

Would you want to try new installation for Super 1.6?
Please visit www.acelet.com
Thanks.
"Dominique Jean-Prost" <[email protected]> wrote:
If only your installation tool was easy to use ...
dom
"Wei Jiang" <[email protected]> a écrit dans le message news:
[email protected]...
Super supports source code level tracing for Java and JSP!
Announcement: Super 1.5 - an EJB/J2EE monitoring tool with
SuperPeekPoke
SuperLogging
SuperStress
SuperEnvironment
It is free for development.
You can anomyously down load it from:
http://www.acelet.com.
Super is a component based administration tool for EJB/J2ee.
It provides built-in functionality as well as
extensions, as SuperComponents. Users can install
SuperComponents onto it, or uninstall them from it.
Super has the following functions:
* A J2EE/EJB monitor.
* A gateway to EJB servers from different vendors.
* A framework holding user defined SuperComponents.
* A PeekPoke tool to read/write attributes from EJBs.
* A full-featured logging/tracing tool for centralized, chronologicallogging.
* A Stress test tool.
* A global environment tool.
It is written in pure Java.
The current version support:
* Universal servers.
* Weblogic 5.1
* Weblogic 6.0
What is new:
Version 1.50 August, 2001
Enhancement:
1. Source code level tracing supports EJB, JSP, java helper and other
programs which are written in native languages (as long as you
write correct log messages in your application).
2. Redress supports JSP now.
3. New installation with full help document: hope it will be easier.
4. Support WebSphere 4.0
Version 1.40 June, 2001
Enhancement:
1. Add SuperEnvironment which is a Kaleidoscope with TableView,TimeSeriesView
and PieView for GlobalProperties.
GlobalProperties is an open source program from Acelet.
2. SuperPeekPoke adds Kaleidoscope with TableView, TimeSeriesView andPieView.
Changes:
1. The structure of log database changed. You need delete old installationand
install everything new.
2. The format of time stamp of SuperLogging changed. It is not localedependent:
better for report utilities.
3. Time stamp of SuperLogging added machine name: better for clusteringenvironment.
Bug fix:
1. Under JDK 1.3, when you close Trace Panel, the timer may not bestopped
and
Style Panel may not show up.
Version 1.30 May, 2001
Enhancement:
1. Add ConnectionPlugin support.
2. Add support for Borland AppServer.
Version 1.20 April, 2001
Enhancement:
1. Redress with option to save a backup file
2. More data validation on Dump Panel.
3. Add uninstall for Super itself.
4. Add Log Database Panel for changing the log database parameters.
5. Register Class: you can type in name or browse on file system.
6. New tour with new examples.
Bug fix:
1. Redress: save file may fail.
2. Install Bean: some may fail due to missing manifest file. Now, itis
treated
as foreign beans.
3. Installation: Both installServerSideLibrary and installLogDatabasecan
be worked
on the original file, do not need copy to a temporary directory anymore.
4. PeekPoke: if there is no stub available, JNDI list would be emptyfor
Weblogic5-6.
Now it pick up all availble ones and give warning messages.
5. Stress: Launch>Save>Cancel generated a null pointer exception.
Changes:
1. installLogDatabase has been changed from .zip file to .jar file.
2. SuperLogging: If the log database is broken, the log methods willnot
try to
access the log database. It is consistent with the document now.
3. SuperLogging will not read system properties now. You can put logdatabase
parameters in SuperLoggingEJB's deployment descriptor.
Version 1.10 Feb., 2001
Enhancement:
1. Re-written PeekPoke with Save/Restore functions.
2. New SuperComponent: SuperStress for stress test.
3. Set a mark at the highlighted line on the Source Code
Panel (as a work-a-round for JDK 1.3).
4. Add support for WebLogic 6.0
Bug fix:
1. Uninstall bean does physically delete the jar file now.
2. WebLogic51 Envoy may not always list all JNDI names. This is fixed.
Version 1.00 Oct., 2000
Enhancement:
1. Support Universal server (virtual all EJB servers).
2. Add Lost and Found for JNDI names, in case you need it.
3. JNDI ComboBox is editable now, so you can PeekPoke not listed JNDIname
(mainly
for Envoys which do not support JNDI list).
Version 0.90: Sept, 2000
Enhancement:
1. PeekPoke supports arbitrary objects (except for Vector, Hashtable
and alike) as input values.
2. Reworked help documents.
Bug fix:
1. Clicking Cancel button on Pace Panel set 0 to pace. It causes
further time-out.
2. MDI related bugs under JDK 1.3.
Version 0.80: Aug, 2000
Enhancement:
1. With full-featured SuperLogging.
Version 0.72: July, 2000
Bug fix:
1. Ignore unknown objects, so Weblogic5.1 can show JNDI list.
Version 0.71: July, 2000
Enhancement:
1. Re-worked peek algorithm, doing better for concurent use.
2. Add cacellable Wait dialog, showing Super is busy.
3. Add Stop button on Peek Panel.
4. Add undeploy example button.
Bug fix:
1. Deletion on Peek Panel may cause error under JDK 1.3. Now it worksfor
both
1.2 and 1.3
Version 0.70: July, 2000
Enhancement:
1. PeekPoke EJBs without programming.
Bug fix:
1. Did not show many windows under JDK 1.3. Now it works for both 1.2and
1.3
Changes:
1. All changes are backward compatible, but you may need to recompilemonitor
windows defined by you.
Version 0.61: June, 2000
Bug fix:
1. First time if you choose BUFFER as logging device, message willnot
show.
2. Fixed LoggingPanel related bugs.
Version 0.60: May, 2000
Enhancement:
1. Add DATABASE as a logging device for persistent logging message.
2. Made alertInterval configurable.
3. Made pace for tracing configurable.
Bug fix:
1. Fixed many bugs.
Version 0.51, 0.52 and 0.53: April, 2000
Enhancement:
1. Add support to Weblogic 5.1 (support for Logging/Tracing and
user defined GUI window, not support for regular monitoring).
Bug fix:
1. Context sensitive help is available for most of windows: pressF1.
2. Fix installation related problems.
Version 0.50: April, 2000
Enhancement:
1. Use JavaHelp for help system.
2. Add shutdown functionality for J2EE.
3. Add support to Weblogic 4.5 (support for Logging/Tracing and
user defined GUI window, not support for regular monitoring).
Bug fix:
1. Better exception handling for null Application.
Version 0.40: March, 2000
Enhancement:
1.New installation program, solves installation related problems.
2. Installation deploys AceletSuperApp application.
3. Add deploy/undeploy facilities.
4. Add EJB and application lists.
Change:
1.SimpleMonitorInterface: now more simple.
Version 0.30: January, 2000
Enhancement:
1. Add realm support to J2EE
2. Come with installation program: you just install what you want
the first time you run Super.
Version 0.20: January, 2000
Enhancement:
Add support to J2EE Sun-RI.
Change:
1. Replace logging device "file" with "buffer" to be
compliant to EJB 1.1. Your code do not need to change.
Version 0.10: December, 1999
Enhancement:
1. provide SimpleMonitorInterface, so GUI experience is
not necessary for developing most monitoring applications.
2. Sortable table for table based windows by mouse
click (left or right).
Version 0.01 November., 1999:
1. Bug fix: An exception thrown when log file is large.
2. Enhancement: Add tour section in Help information.
Version 0.00: October, 1999
Thanks.

RMI - ClassNotFound for the Stub

Hi guys and thank you in advance for any help.
I have a simple RMI application. When I try to bind my remote object to the registry I am receiving an UnmarshallException caused by a ClassNotFoundException. My Stub.class and Skel.class are in the same directory as my implementation class.
I am relatively new to this stub. Can anyone shed any light on this?
Many thanks
Elliot

You may also look into setting the path to your stubs dynamically at the command prompt, with the -Djava.rmi.server.codebase=file:///<path_to_stubs>
or -Djava.rmi.server.codebase=c:\<path_to_stubs>
(for windows users)

Java Webstart application problem with TLS certificate revocation checks (Java 1.7.0_76)

We have a problem with our Java Web Start Application regarding the TLS certificate revocation check:
The application is running on a server within a wide area network which is separated from the internet.
The application users have access to the WAN, and also access to the internet over some corporate proxy/firewall.
The user has to enter, for example "https://my-site.de/myapp/ma.jnlp" within a webbrowser or could also call "javaws https://my-site.de/myapp/ma.jnlp" to start the application client.
The webserver has a certificate from a trusted certificate authority. This certificate seems to be ok, the browser is even configured to perform OCSP status check.
The application files are signed with a certificate from another trusted certificate authority. This certificate seems also to be ok. Regarding this certificate there
are no problems with certificate revocation checks.
The problem is, while starting the application client there is a message box which tell us something like "the connection to this website ist not trustworthy",
"Website: https://my-site.de:80", and something about an invalid certificate, meaning the webserver certificate.
Obviously the jvm runtime, which is executed on the users workstation, tries to perform a revocation check for the webservers certificate, but this fails because
it cannot fetch the certificate under https://my-site.de:80.
The application will execute without further problems after that message but the users are very concerned about the "invalid" certificate, so here are my questions:
- Why is the application trying to get the webserver certificate over Port 80. Our application developers told me, there is no corresponding statement. Calling this address
has to fail while "https://my-site.de:443" or "https://my-site.de" would not have a problem.
- Is there a way to make the application go on without performing a tls revocation check? I mean, by adjusting the application sourcecode and not by configuring the users Java Control Panel.
While disabling the TLS Certificate Revocation check in the Java Control Panel, the Webstart Application executes without a warning message, but this is not a workable solution for
our users.
It would be great if someone can help me with a hint so i can send our developers into the right direction;-)
Many thanks!
This is a part from a java console output after calling "javaws -verbose https://my-site.de/myapp/"
(sorry for this is in german... and also my english above)
network: Verbindung von http://ocsp.serverpass.telesec.de/ocspr mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
network: Verbindung von http://ocsp.serverpass.telesec.de/ocspr mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
security: OCSP Response: GOOD
network: Verbindung von http://ocsp.serverpass.telesec.de/ocspr mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
security: UNAUTHORIZED
security: Failing over to CRLs: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED
network: Cacheeintrag gefunden [URL: http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl, Version: null] prevalidated=false/0
cache: Adding MemoryCache entry: http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl
cache: Resource http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl has expired.
network: Verbindung von http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
network: Verbindung von http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl mit Proxy=HTTP @ internet-proxy.***:80 wird hergestellt
network: ResponseCode für http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl: 200
network: Codierung für http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl: null
network: Verbindung mit http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl trennen
CacheEntry[http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl]: updateAvailable=true,lastModified=Tue Mar 24 10:50:01 CET 2015,length=53241
network: Verbindung von http://crl.serverpass.telesec.de/rl/TeleSec_ServerPass_CA_1.crl mit Proxy=HTTP @ internet-proxy.***:80 wird
network: Verbindung von socket://ldap.serverpass.telesec.de:389 mit Proxy=DIRECT wird hergestellt
security: Revocation Status Unknown
com.sun.deploy.security.RevocationChecker$StatusUnknownException: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED
    at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source)
    at com.sun.deploy.security.RevocationChecker.check(Unknown Source)
    at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)
    at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)
    at com.sun.deploy.security.RevocationCheckHelper.checkRevocationStatus(Unknown Source)
    at com.sun.deploy.security.X509TrustManagerDelegate.checkTrusted(Unknown Source)
    at com.sun.deploy.security.X509Extended7DeployTrustManagerDelegate.checkServerTrusted(Unknown Source)
    at com.sun.deploy.security.X509Extended7DeployTrustManager.checkServerTrusted(Unknown Source)
    at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
    at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
    at sun.security.ssl.Handshaker.processLoop(Unknown Source)
    at sun.security.ssl.Handshaker.process_record(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
    at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
    at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
    at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.deploy.model.ResourceProvider.getResource(Unknown Source)
    at com.sun.javaws.jnl.LaunchDescFactory._buildDescriptor(Unknown Source)
    at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
    at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
    at com.sun.javaws.Main.launchApp(Unknown Source)
    at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
    at com.sun.javaws.Main.access$000(Unknown Source)
    at com.sun.javaws.Main$1.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
    Suppressed: com.sun.deploy.security.RevocationChecker$StatusUnknownException
        at com.sun.deploy.security.RevocationChecker.checkCRLs(Unknown Source)
        ... 35 more
Caused by: java.security.cert.CertPathValidatorException: OCSP response error: UNAUTHORIZED
    at sun.security.provider.certpath.OCSP.check(Unknown Source)
    at sun.security.provider.certpath.OCSP.check(Unknown Source)
    at sun.security.provider.certpath.OCSP.check(Unknown Source)
    ... 36 more
security: Ungültiges Zertifikat vom HTTPS-Server
network: Cacheeintrag nicht gefunden [URL: https://my-site.de:80, Version: null]

Add the JSF Jars to the WEB-INF/lib directory of the application. If still getting error add to the CLASSPATH variable in the startWebLogic script in the domain/bin directory.

JNDI Lookup in JSP fails for EJB 3.0

I am new to Java technology. I read the EJB FAQ, NetBeans docs and may forum discussions and I am still confused with the error I am having.
Background:
I have developed a persistance bean and related sessions beans (similar to the customer-cmp-ear application in the Java App Server samples). Now I am trying to access this bean using a JSP. After deploying the war file in the App Server and try to access the page, I get the following error.
javax.naming.NameNotFoundException: No object bound to name java:comp/env/ConsumerSessionLocal
After reading many articles, I understood that I dont have to prepare any descriptors, or JAR files for EJB 3.0.
Environment Details:
Java App Server Ver 9.0
NetBeans 5.5
I normally build the war files using NetBeans.
I use App Server Admin console to deploy the web applications using the above war file.
EJB details:
Persistance EJB : person.java
Session Objects
Consumer.java (this implements ConsumerSessionLocal, ConsumerSessionRemote). This Stateless bean accesses the methods in person.java.
ConsumerSessionLocal.java - local interface
ConsumerSessionRemote.java - remote interface
SearchConsumer.jsp
This JSP page is calling the ConsumerSessionLocal using the JNDI lookup through InitialContext.
Here is the Code snippet:
try {
InitialContext ic = new InitialContext();
Object o = ic.lookup("java:comp/env/ConsumerSessionLocal");
ConsumerSessionLocal consSession = (ConsumerSessionLocal) o;
I am able to see the jsp page in the browser, however, after a submit action, I get the Java Naming Exception error.
javax.naming.NameNotFoundException: No object bound for java:comp/env/ConsumerSessionLocal
I would appreciate your help/any of your thoughts.
Thanks in advance.
-Ram

I did not really solve it. Instead I used some of the tutorials that used JNDI lookup and modified those as my way forward. I did not really find out exactly what I was doing wrong.
/Anders

Error while using LiveCycle java APIs with Http servlets:"Remote EJBObject lookup failed for ejb/Inv

Hi all,
When i try to run more than one servelt of the Quick Start samples that using Livecycle Java APIs and i get an error of "Remote EJBObject lookup failed for ejb/Invocation provider" from any servelt i run.
I try some Quick samples which is not servelts (java class) and it works fine, which makes me sure that my connection properties is true.
Environment:
The LiveCycle is based on "Websphere v6.1", and i use "Eclipse Platform
Version: 3.4.1".
i install "tomcat 5.5.17" to test the servelts in developing time through Eclipse.(only for test in developing time not for deploy on )
The Jars i added in the classpath:
adobe-forms-client.jar
adobe-livecycle-client.jar
adobe-usermanager-client.jar
adobe-utilities.jar
ejb.jar
j2ee.jar
ecutlis.jar
com.ibm.ws.admin.client_6.1.0.jar
com.ibm.ws.webservices.thinclient_6.1.0.jar
server.jar
utlis.jar
wsexception.jar
My code is :
Properties ConnectionProps = new Properties();
ConnectionProps.setProperty(ServiceClientFactoryProperties.DSC_DEFAULT_EJB_ENDPOINT, "iiop://localhost:2809");
ConnectionProps.setProperty ServiceClientFactoryProperties.DSC_TRANSPORT_PROTOCOL,ServiceClientFactoryProperties.DSC_ EJB_PROTOCOL);
ConnectionProps.setProperty(ServiceClientFactoryProperties.DSC_SERVER_TYPE,ServiceClientFa ctoryProperties.DSC_WEBSPHERE_SERVER_TYPE);
ConnectionProps.setProperty(ServiceClientFactoryProperties.DSC_CREDENTIAL_USERNAME, "Administrator");
ConnectionProps.setProperty(ServiceClientFactoryProperties.DSC_CREDENTIAL_PASSWORD, "password");
ConnectionProps.setProperty("java.naming.factory.initial", "com.ibm.ws.naming.util.WsnInitCtxFactory");
//Create a ServiceClientFactory object
ServiceClientFactory myFactory = ServiceClientFactory.createInstance(ConnectionProps);
//Create a FormsServiceClient object
FormsServiceClient formsClient = new FormsServiceClient(myFactory);
//Get Form data to pass to the processFormSubmission method
Document formData = new Document(req.getInputStream());
//Set run-time options
RenderOptionsSpec processSpec = new RenderOptionsSpec();
processSpec.setLocale("en_US");
//Invoke the processFormSubmission method
FormsResult formOut = formsClient.processFormSubmission(formData,"CONTENT_TYPE=application/pdf&CONTENT_TYPE=app lication/vnd.adobe.xdp+xml&CONTENT_TYPE=text/xml", "",processSpec);
List fileAttachments = formOut.getAttachments();
Iterator iter = fileAttachments.iterator();
int i = 0 ;
while (iter.hasNext()) {
Document file = (Document)iter.next();
file.copyToFile(new File("C:\\Adobe\\tempFile"+i+".jp i++;
short processState = formOut.getAction();
...... (To the end of the sample)
My Error was:
com.adobe.livecycle.formsservice.exception.ProcessFormSubmissionException: ALC-DSC-031-000: com.adobe.idp.dsc.net.DSCNamingException: Remote EJBObject lookup failed for ejb/Invocation provider
at com.adobe.livecycle.formsservice.client.FormsServiceClient.processFormSubmission(FormsSer viceClient.java:416)
at HandleData.doPost(HandleData.java:62)
at HandleData.doGet(HandleData.java:31)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j ava:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
a

I assume here that your application is deployed on a different physical machine of where LCES is deployed and running.
Do the following test:
- Say that LCES is deployed on machine1 and your application is deployed on machine2. Ping machine1 from machine2 and note the ip address.
- Ping machine1 from machine1 and note the ip address.
The two pings should match.
- Ping machine2 from machine1 and note the ip address.
- Ping machine2 from machine2 and note the ip address.
The two pings should match.
Usually this kind of error would happen if your servers have internal and external ip addresses.

Using EJBs in Web Dynpro Applications

I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro Applications</a>).
I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
- It violates the MVC paradigm by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
- Doesn't carry its own weight. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
- Unnecessarily complicates error handling. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
- Produces unnecessary DCs. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
- Not a typical application of the Command pattern. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
- specify, queue and execute requests at different times
- decouple execution of a command from its invoker
- support undo operations
- support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

Hi Romeo,
You would be disappointed, this reply ain't anywhere nearby to what you are talking about...
I wanted to mail you, but you have not mentioned your email in your profile.
I am really impressed by your flair for writing. It would be far better had you written a blog on this topic. Believe me, it would really be better. There is a much wider audience waiting out there to read your views rather than on the forums. This is what I believe. To top it, you would be rewarded for writing something like this from SDN. On the blogs too, people can comment and all, difference being there you would be rewarded by SDN, here people who reply to you would be rewarded by you. Doesn't make much a difference.
Anyways the ball is still in your court
As far as I am concerned, it has still not been much time since I have started working on Web Dynpro. So can't really comment on the issue...
Bye
Ankur

[Q] ClassNotFoundException for EJB stub in Webstart application

Similar Messages

Maybe you are looking for