NetBeans Forums

 FAQFAQ   SearchSearch   MemberlistMemberlist   RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
  

Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi
Goto page 1, 2  Next
 
Post new topic   Reply to topic    NetBeans Forums -> NetBeans Platform Users
View previous topic :: View next topic  
Author Message
Jay Smathers



Joined: 24 Oct 2008
Posts: 8

PostPosted: Fri Oct 24, 2008 5:52 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

Hi, I'm really hoping someone has some helpful knowledge here....



I am experiencing exceptions when trying to connect my module suite to a gf2
server. I really need some help…

According to glassfish documentation, a remote standalone java application
can bootstrap to the glassfish server’s jndi in order to access remote ejb
interface methods by
1) copying javaee.jar and appserv-rt.jar from glassfish’shome dir/lib into
the library jars of your stand alone client
2) In your client code, to get your bean from the server, you simply use:
InitialContext ic = new InitialContext();
Foo foo = (Foo) ic.lookup("FooEJB");

There is some mention that additional jars from glassfish might be required
and that one should examine the appser.rt manifest to see what other jars
are required.

Question 1: Should this work for a netbeans module suite, or is it already
known that netbeans platform apps will not play nice in this scenario?

Question 2: If yes, can someone give me instructions one how to examine the
appserv-rt.jar meta-data/manifest to determine what other jars I should
include? (I need the basics here: what is it, where is it, how do you read
it.)

Regarding which glassfish jars are required to make this work, I should note
that when I use netbeans 6.1 to build a (non- netbeans platform) Java
Desktop Application, and follow those steps above everything works like it
should, I get my bean and can call methods on the server. This would imply
the only two glassfish jars a stand alone client needs access to, are the
two listed above, and no more.

But when I create a Netbeans platform suite, and follow the identical
procedure, when I attempt the ic.lookup() I get the exception:

java.lang.NoClassDefFoundError: com/sun/logging/LogDomains
at com.sun.enterprise.util.ORBManager.<clinit>(ORBManager.java:93)
at
com.sun.enterprise.naming.SerialInitContextFactory.<clinit>(SerialInitContextFactory.java:65)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at
com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:46)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:654)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:175)

If I add all the glassfish jars to my netbeans module library, the exception
changes to:

WARNING [javax.enterprise.resource.corba.ee.S1AS-ORB.rpc.transport]:
"IOP00410201: (COMM_FAILURE) Connection failure: socketType:
IIOP_CLEAR_TEXT; hostname: localhost; port: 3700"
java.net.ConnectException: Connection refused: connect
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
at
com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:105)
at
com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:332)

Question 3: Is there an explanation why a netbeans based app would require
more glassfish jars in order to be able to make an rmi connection with
glass fish? I am thinking having insufficiant glassfish jars visible to my
application is not the issue, but Im not sure.

I found a post in this forum over 2 years old where another developer had my
initial exception, (see here:
http://www.nabble.com/J2EE-client-td3861217.html#a3861217 ) while attempting
the same thing.

He claimed to resolve this exception and connect successfully with glassfish
by using the advice given in the thread to pass netbeans a run time
parameter that changes how netbeans loads classes. The magic flag he used
is:

-J-Dorg.netbeans.core.startup.specialResource=org/omg/CORBA

It is stated that netbeans uses its own optimized class loading procedure,
and that was creating the NoClassDefFoundError, and this flag turns off this
optimization.

Question 4: Does anyone know if this flag is required. That is if you want
your platform app to be a stand alone JEE client, it will not be able to
connect unless you invoke this change. (Using netbeans 6.1 and gf2). If so,
could someone explain more about what this flag is, what it does and most of
all, -how to properly invoke it? I tried several ways to use it, but see no
new results. Also, I amgetting the feeling that using a platform app as a
glassfish client must be much more unusual (or a bad idea for some reason)
than I realizes -comments on this merits of this approach are welcome.

I am about to abandon netbeans platform over this..

Please help and Thanks, -jay

--
View this message in context: http://www.nabble.com/Unable-to-get-my-nb-platform-module-suite-to-bootsrtrap-to-glassfish%27s-jndi-tp20154866p20154866.html
Sent from the Netbeans RCP/Platform Users (Open API) mailing list archive at Nabble.com.
Back to top
Antonio
Posted via mailing list.





PostPosted: Fri Oct 24, 2008 6:32 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

Hi Jay,

I've never tried this out, but I may be of some help.

1.- Jars you need

As far as I've seen out there in the blogosphere you'll need
"appserv-rt.jar, appserv-admin.jar and javaee.jar" in your application.

For the exact list of jar files you'll need open those files with Ark or
Winzip (or whatever they call it) and open the "META-INF/MANIFEST.MF"
file, there should be a line starting with "Class-Path:" with a list of
jar files. Those are the dependencies you'll need.

These jar files should be visible between them, so I'd create a Library
Wrapper Module (let's call it GLW, from Glassfish Library Wrapper) with
those jar files.

Of course, whenever you want to access glassfish from within a NetBeans
Module, then you'll need a dependency with GLW.

2.- InitialContext with standalone applications

The "InitialContext" object is created always with a set or properties.
If you don't specify a "java.util.Properties" yourself then
"InitialContext" will seek for a "jndi.properties" file in all your jar
files, and read info from there.

You probably want to create your InitialContext with something like:

Properties p = new Properties();
p.put("org.omg.CORBA.ORBInitialHost","localhost");
p.put("org.omg.CORBA.ORBInitialPort","3700");
InitialContext ctx = new InitialContext(p);

(This assumes your glassfish is running in "localhost". If your
glassfish is in another location kilometers away you should specify the
host name or IP there, and make sure you can get to port 3700 (try a
"telnet 3700") and that there're no proxies/firewalls in the middle).

I don't know if NetBeans has a "jndi.properties" in a jar file
somewhere. If it has then it may interfere in the way "InitialContext"
seeks for those properties. If in doubt, and to make sure everything
works well, you may go take a look inside glassfish jar files (with
ark/winzip) and seek for the "jndi.properties" file, and then specify
those properties in your "java.util.Properties" in the code above.


Question 1: Does it work?

I don't know if NetBeans RCP apps play well with glassfish. They should
work well, as far as I know, if you play nice with glassfish (adding all
jar files within the same library wrapper module).

Question 2: Number of jar files

Glassfish application clients are huge (several megabytes). So beware of
adding up to several megabytes of jar files to your standalone java
application.

Question 3: Special flags

You should require none. If in doubt I'd try with:

-Dorg.omg.CORBA.ORBInitialHost=[hostname here]
-Dorg.omg.CORBA.ORBInitialPort=3700

Question 4: Are these flags required?

The fact is that I don't know. I haven't *yet* tried to build J2EE
client applications using the NetBeans RCP. I may try it out during the
coming months, though.

Finally let me say that I think NetBeans RCP is a great way of building
rich client applications, and that using it to run clients for J2EE
applications is a good idea. Not many people use RMI these days, though,
because most people prefer going with web services. Of course they'll
miss JMS access (and thus ability to listen to JMS topics, this is, to
receive information back from the server in an scalable way).

Let us know if things work for you,

Cheers,
Antonio







jbsmathers wrote:
Quote:
Hi, I'm really hoping someone has some helpful knowledge here....



I am experiencing exceptions when trying to connect my module suite to a gf2
server. I really need some help…

According to glassfish documentation, a remote standalone java application
can bootstrap to the glassfish server’s jndi in order to access remote ejb
interface methods by
1) copying javaee.jar and appserv-rt.jar from glassfish’shome dir/lib into
the library jars of your stand alone client
2) In your client code, to get your bean from the server, you simply use:
InitialContext ic = new InitialContext();
Foo foo = (Foo) ic.lookup("FooEJB");

There is some mention that additional jars from glassfish might be required
and that one should examine the appser.rt manifest to see what other jars
are required.

Question 1: Should this work for a netbeans module suite, or is it already
known that netbeans platform apps will not play nice in this scenario?

Question 2: If yes, can someone give me instructions one how to examine the
appserv-rt.jar meta-data/manifest to determine what other jars I should
include? (I need the basics here: what is it, where is it, how do you read
it.)

Regarding which glassfish jars are required to make this work, I should note
that when I use netbeans 6.1 to build a (non- netbeans platform) Java
Desktop Application, and follow those steps above everything works like it
should, I get my bean and can call methods on the server. This would imply
the only two glassfish jars a stand alone client needs access to, are the
two listed above, and no more.

But when I create a Netbeans platform suite, and follow the identical
procedure, when I attempt the ic.lookup() I get the exception:

java.lang.NoClassDefFoundError: com/sun/logging/LogDomains
at com.sun.enterprise.util.ORBManager.<clinit>(ORBManager.java:93)
at
com.sun.enterprise.naming.SerialInitContextFactory.<clinit>(SerialInitContextFactory.java:65)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at
com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:46)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:654)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:175)

If I add all the glassfish jars to my netbeans module library, the exception
changes to:

WARNING [javax.enterprise.resource.corba.ee.S1AS-ORB.rpc.transport]:
"IOP00410201: (COMM_FAILURE) Connection failure: socketType:
IIOP_CLEAR_TEXT; hostname: localhost; port: 3700"
java.net.ConnectException: Connection refused: connect
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
at
com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:105)
at
com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:332)

Question 3: Is there an explanation why a netbeans based app would require
more glassfish jars in order to be able to make an rmi connection with
glass fish? I am thinking having insufficiant glassfish jars visible to my
application is not the issue, but Im not sure.

I found a post in this forum over 2 years old where another developer had my
initial exception, (see here:
http://www.nabble.com/J2EE-client-td3861217.html#a3861217 ) while attempting
the same thing.

He claimed to resolve this exception and connect successfully with glassfish
by using the advice given in the thread to pass netbeans a run time
parameter that changes how netbeans loads classes. The magic flag he used
is:

-J-Dorg.netbeans.core.startup.specialResource=org/omg/CORBA

It is stated that netbeans uses its own optimized class loading procedure,
and that was creating the NoClassDefFoundError, and this flag turns off this
optimization.

Question 4: Does anyone know if this flag is required. That is if you want
your platform app to be a stand alone JEE client, it will not be able to
connect unless you invoke this change. (Using netbeans 6.1 and gf2). If so,
could someone explain more about what this flag is, what it does and most of
all, -how to properly invoke it? I tried several ways to use it, but see no
new results. Also, I amgetting the feeling that using a platform app as a
glassfish client must be much more unusual (or a bad idea for some reason)
than I realizes -comments on this merits of this approach are welcome.

I am about to abandon netbeans platform over this..

Please help and Thanks, -jay
Back to top
sergej



Joined: 18 Aug 2008
Posts: 99
Location: Cremona (ITALY)

PostPosted: Fri Oct 24, 2008 6:51 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

In my app I have:

1) a lib module with the following jars:

<class-path-extension>
<runtime-relative-path>ext/appserv-ext.jar</runtime-relative-path>
<binary-origin>release/modules/ext/appserv-ext.jar</binary-origin>
</class-path-extension>
<class-path-extension>
<runtime-relative-path>ext/appserv-deployment-client.jar</runtime-relative-path>
<binary-origin>release/modules/ext/appserv-deployment-client.jar</binary-origin>
</class-path-extension>
<class-path-extension>
<runtime-relative-path>ext/jmxremote_optional.jar</runtime-relative-path>
<binary-origin>release/modules/ext/jmxremote_optional.jar</binary-origin>
</class-path-extension>
<class-path-extension>
<runtime-relative-path>ext/javaee.jar</runtime-relative-path>
<binary-origin>release/modules/ext/javaee.jar</binary-origin>
</class-path-extension>
<class-path-extension>
<runtime-relative-path>ext/appserv-rt.jar</runtime-relative-path>
<binary-origin>release/modules/ext/appserv-rt.jar</binary-origin>
</class-path-extension>

2) a module with utility classes for lookups etc, like:

import javax.naming.InitialContext;
import javax.naming.NamingException;

/**
*
* @author sergio
*/
public class JEE {

public static <T> T findEJBBean(final Class<T> c) throws NamingException {

return (T) (new InitialContext()).lookup(c.getName());

}

}

3) in my RCP Project Properties :

[...]
appserver.home=/home/sergio/bin/glassfish
appserverprj.home=/home/sergio/NetBeansProjects/STRIKE
run.args.extra=-J-da -J-Dorg.omg.CORBA.ORBInitialHost=localhost -J-Dorg.omg.CORBA.ORBInitialPort=3700 \
-cp:a ${appserver.home}/lib/appserv-rt.jar:\
${appserver.home}/lib/appserv-ext.jar:\
${appserver.home}/lib/appserv-deployment-client.jar:\
${appserver.home}/lib/javaee.jar:\
${appserver.home}/lib/jmxremote_optional.jar:\
${appserver.home}/lib/toplink-essentials.jar:\
${appserverprj.home}/STRIKE-ejb/dist/STRIKE-ejb.jar:\
${appserverprj.home}/STRIKE-lib/dist/STRIKE-lib.jar:\
${appserverprj.home}/STRIKE-orm/dist/STRIKE-orm.jar



Beware: it's not a clean solution, just a starting point. I've not considered deployment problems and other issues yet.

Hope it helps,
Sergio

On Fri, 2008-10-24 at 10:52 -0700, jbsmathers wrote:
Quote:
Quote:

Hi, I'm really hoping someone has some helpful knowledge here....



I am experiencing exceptions when trying to connect my module suite to a gf2
server. I really need some help…

According to glassfish documentation, a remote standalone java application
can bootstrap to the glassfish server’s jndi in order to access remote ejb
interface methods by
1) copying javaee.jar and appserv-rt.jar from glassfish’shome dir/lib into
the library jars of your stand alone client
2) In your client code, to get your bean from the server, you simply use:
InitialContext ic = new InitialContext();
Foo foo = (Foo) ic.lookup("FooEJB");

There is some mention that additional jars from glassfish might be required
and that one should examine the appser.rt manifest to see what other jars
are required.

Question 1: Should this work for a netbeans module suite, or is it already
known that netbeans platform apps will not play nice in this scenario?

Question 2: If yes, can someone give me instructions one how to examine the
appserv-rt.jar meta-data/manifest to determine what other jars I should
include? (I need the basics here: what is it, where is it, how do you read
it.)

Regarding which glassfish jars are required to make this work, I should note
that when I use netbeans 6.1 to build a (non- netbeans platform) Java
Desktop Application, and follow those steps above everything works like it
should, I get my bean and can call methods on the server. This would imply
the only two glassfish jars a stand alone client needs access to, are the
two listed above, and no more.

But when I create a Netbeans platform suite, and follow the identical
procedure, when I attempt the ic.lookup() I get the exception:

java.lang.NoClassDefFoundError: com/sun/logging/LogDomains
at com.sun.enterprise.util.ORBManager.<clinit>(ORBManager.java:93)
at
com.sun.enterprise.naming.SerialInitContextFactory.<clinit>(SerialInitContextFactory.java:65)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at
com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:46)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:654)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:175)

If I add all the glassfish jars to my netbeans module library, the exception
changes to:

WARNING [javax.enterprise.resource.corba.ee.S1AS-ORB.rpc.transport]:
"IOP00410201: (COMM_FAILURE) Connection failure: socketType:
IIOP_CLEAR_TEXT; hostname: localhost; port: 3700"
java.net.ConnectException: Connection refused: connect
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507)
at
com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:105)
at
com.sun.enterprise.iiop.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:332)

Question 3: Is there an explanation why a netbeans based app would require
more glassfish jars in order to be able to make an rmi connection with
glass fish? I am thinking having insufficiant glassfish jars visible to my
application is not the issue, but Im not sure.

I found a post in this forum over 2 years old where another developer had my
initial exception, (see here:
http://www.nabble.com/J2EE-client-td3861217.html#a3861217 ) while attempting
the same thing.

He claimed to resolve this exception and connect successfully with glassfish
by using the advice given in the thread to pass netbeans a run time
parameter that changes how netbeans loads classes. The magic flag he used
is:

-J-Dorg.netbeans.core.startup.specialResource=org/omg/CORBA

It is stated that netbeans uses its own optimized class loading procedure,
and that was creating the NoClassDefFoundError, and this flag turns off this
optimization.

Question 4: Does anyone know if this flag is required. That is if you want
your platform app to be a stand alone JEE client, it will not be able to
connect unless you invoke this change. (Using netbeans 6.1 and gf2). If so,
could someone explain more about what this flag is, what it does and most of
all, -how to properly invoke it? I tried several ways to use it, but see no
new results. Also, I amgetting the feeling that using a platform app as a
glassfish client must be much more unusual (or a bad idea for some reason)
than I realizes -comments on this merits of this approach are welcome.

I am about to abandon netbeans platform over this..

Please help and Thanks, -jay

Quote:

--
Sergio Bello - Software Architect

Sintechno S.r.l. [www.sintechno.it]

Via Dante, 188
26100 - Cremona (ITALY)

Phone 0372 22942
Fax 0372 565287
Mobile 329 9499343
EMail address-removed ([email]address-removed[/email])
--
There are only 10 types of people in the world:
those who understand binary, and those who don't...
Back to top
Jay Smathers



Joined: 24 Oct 2008
Posts: 8

PostPosted: Fri Oct 24, 2008 9:37 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

Antonio and Sergio, thanks much. You both helped me to understand more than I
did.

I now understand a jar's manifest, and I can understand which glassfish
dependencies are needed and I see that they match the jars which Sergio is
including.

Unfortunately, the probelm persists.

Now my exception is-
javax.naming.NamingException: ejb ref resolution error for remote business
interfaceff.fc.ume.session.UmeAccessBeanRemote [Root exception is
java.lang.RuntimeException: Could not invoke defineClass!]

My primary observations is this: Any basic java app connects to glassfish as
exactly as advertised using initialContext.lookup() when only the two jars
javaee and appsever-rt are part of its library. Therefore, one might expect
a netbeans platform application would do the same. But it does not.

So the question becomes what about a netbeans app would screw up the ability
of the initialContext.lookup() invocation to execute code in
appsever-rt.jar properly.

Its beyond me to trouble shoot that. Besides I was hoping to use the nb
platform to reduce work, not increase it.

Ive searched many posts on this. This post was intriguing:
http://openide.netbeans.org/servlets/ReadMsg?list=dev&msgNo=20713

But I was unable to use this command to resolve my issue.

The fact that many are struggling to simply connect a netbeans app to a
server is a statement about the popularity of web services as much as
anything.

For now I need to put either netbeans or glassfish aside.

thanks again, -js
--
View this message in context: http://www.nabble.com/Unable-to-get-my-nb-platform-module-suite-to-bootsrtrap-to-glassfish%27s-jndi-tp20154866p20157635.html
Sent from the Netbeans RCP/Platform Users (Open API) mailing list archive at Nabble.com.
Back to top
Antonio
Posted via mailing list.





PostPosted: Fri Oct 24, 2008 10:58 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

Hi,

Say you want to invoke an EJB remotely. And that the EJB is sending you
an object of type "my.package.MyClass".

What is happening is that the J2EE server serializes the "MyClass"
instance in the remote server and then sends the serialized bytes back
to your running application.

In your running application what happens is that those bytes are
converted back into a "MyClass" object.

If your "MyClass.class" is not in your client-side classloader (your
RCP application) then you won't be able to load your object, and you'll
get a "NoClassDefFoundError" or a "ClassNotFoundException" or the
classloader is not able to load your class (so it cannot "invoke
defineclass").

So what you have to do is to place the "MyClass" object in the same
class loader as the classes that invoke the remote server, so that those
classes (responsible for de-serializing "MyClass" objects) can see the
"MyClass" class.

What this means is that you should add "MyClass" to those "Glassfish
Library Wrapper Module" we were talking about in an earlier post.

Sergio's solution is to add all classes (MyClass.class and all J2EE
server-side classes) in a special class loader used by the whole
application (by using "-cp:a" in the command line).

I don't like that solution myself, as it's not very "modular". But it
will work for sure.

Please let us again know how you're doing.

Cheers,
Antonio


jbsmathers wrote:
Quote:
Antonio and Sergio, thanks much. You both helped me to understand more than I
did.

I now understand a jar's manifest, and I can understand which glassfish
dependencies are needed and I see that they match the jars which Sergio is
including.

Unfortunately, the probelm persists.

Now my exception is-
javax.naming.NamingException: ejb ref resolution error for remote business
interfaceff.fc.ume.session.UmeAccessBeanRemote [Root exception is
java.lang.RuntimeException: Could not invoke defineClass!]

My primary observations is this: Any basic java app connects to glassfish as
exactly as advertised using initialContext.lookup() when only the two jars
javaee and appsever-rt are part of its library. Therefore, one might expect
a netbeans platform application would do the same. But it does not.

So the question becomes what about a netbeans app would screw up the ability
of the initialContext.lookup() invocation to execute code in
appsever-rt.jar properly.

Its beyond me to trouble shoot that. Besides I was hoping to use the nb
platform to reduce work, not increase it.

Ive searched many posts on this. This post was intriguing:
http://openide.netbeans.org/servlets/ReadMsg?list=dev&msgNo=20713

But I was unable to use this command to resolve my issue.

The fact that many are struggling to simply connect a netbeans app to a
server is a statement about the popularity of web services as much as
anything.

For now I need to put either netbeans or glassfish aside.

thanks again, -js
Back to top
Jay Smathers



Joined: 24 Oct 2008
Posts: 8

PostPosted: Fri Oct 24, 2008 11:26 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

Hi Antonio,

My netbeans module, where the code which attempts the lookup() is located,
has a declared a dependency on the glassfish wrapper module, as well as
declared dependency on a customEjb module which contains "MyObject".

Are you saying that the glassfish wrapper module needs to declare a
dependence on my customEJB module? I can give that a try.

I guess I can see that makes sense. The strict modularity of the netbeans
modules is something I need to be more aware of.

Thanks very much for your help and patience, -js




AntonioV wrote:
Quote:

Hi,

Say you want to invoke an EJB remotely. And that the EJB is sending you
an object of type "my.package.MyClass".

What is happening is that the J2EE server serializes the "MyClass"
instance in the remote server and then sends the serialized bytes back
to your running application.

In your running application what happens is that those bytes are
converted back into a "MyClass" object.

If your "MyClass.class" is not in your client-side classloader (your
RCP application) then you won't be able to load your object, and you'll
get a "NoClassDefFoundError" or a "ClassNotFoundException" or the
classloader is not able to load your class (so it cannot "invoke
defineclass").

So what you have to do is to place the "MyClass" object in the same
class loader as the classes that invoke the remote server, so that those
classes (responsible for de-serializing "MyClass" objects) can see the
"MyClass" class.

What this means is that you should add "MyClass" to those "Glassfish
Library Wrapper Module" we were talking about in an earlier post.

Sergio's solution is to add all classes (MyClass.class and all J2EE
server-side classes) in a special class loader used by the whole
application (by using "-cp:a" in the command line).

I don't like that solution myself, as it's not very "modular". But it
will work for sure.

Please let us again know how you're doing.

Cheers,
Antonio


jbsmathers wrote:
Quote:
Antonio and Sergio, thanks much. You both helped me to understand more
than I
did.

I now understand a jar's manifest, and I can understand which glassfish
dependencies are needed and I see that they match the jars which Sergio
is
including.

Unfortunately, the probelm persists.

Now my exception is-
javax.naming.NamingException: ejb ref resolution error for remote
business
interfaceff.fc.ume.session.UmeAccessBeanRemote [Root exception is
java.lang.RuntimeException: Could not invoke defineClass!]

My primary observations is this: Any basic java app connects to glassfish
as
exactly as advertised using initialContext.lookup() when only the two
jars
javaee and appsever-rt are part of its library. Therefore, one might
expect
a netbeans platform application would do the same. But it does not.

So the question becomes what about a netbeans app would screw up the
ability
of the initialContext.lookup() invocation to execute code in
appsever-rt.jar properly.

Its beyond me to trouble shoot that. Besides I was hoping to use the nb
platform to reduce work, not increase it.

Ive searched many posts on this. This post was intriguing:
http://openide.netbeans.org/servlets/ReadMsg?list=dev&msgNo=20713

But I was unable to use this command to resolve my issue.

The fact that many are struggling to simply connect a netbeans app to a
server is a statement about the popularity of web services as much as
anything.

For now I need to put either netbeans or glassfish aside.

thanks again, -js




--
View this message in context: http://www.nabble.com/Unable-to-get-my-nb-platform-module-suite-to-bootsrtrap-to-glassfish%27s-jndi-tp20154866p20159385.html
Sent from the Netbeans RCP/Platform Users (Open API) mailing list archive at Nabble.com.
Back to top
sergej



Joined: 18 Aug 2008
Posts: 99
Location: Cremona (ITALY)

PostPosted: Fri Oct 24, 2008 11:32 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

On Sat, 2008-10-25 at 00:58 +0200, Antonio wrote:
Quote:

Sergio's solution is to add all classes (MyClass.class and all J2EE
server-side classes) in a special class loader used by the whole
application (by using "-cp:a" in the command line).

I don't like that solution myself, as it's not very "modular". But it
will work for sure.

Yes, exactly. I'm sorry for the 'quick & dirty' explanation, but i was
in a hurry...
You have to include remote interfaces, common custom libraries (DTO,
beans etc.) and (if it's your case) JPA entities on the client side,
also.

I reference them by means of:
[...]
${appserverprj.home}/STRIKE-ejb/dist/STRIKE-ejb.jar:\
${appserverprj.home}/STRIKE-lib/dist/STRIKE-lib.jar:\
${appserverprj.home}/STRIKE-orm/dist/STRIKE-orm.jar

As I said, my solution is not the best around, but I have a very short
timeline, so I had to be fast to be on track, cleaning up the code when
water calms down ;)

Anyway, Jay, give it another try: once up, you'll be running!

Sergio

Quote:
Please let us again know how you're doing.

Cheers,
Antonio


jbsmathers wrote:
Quote:
Antonio and Sergio, thanks much. You both helped me to understand more than I
did.

I now understand a jar's manifest, and I can understand which glassfish
dependencies are needed and I see that they match the jars which Sergio is
including.

Unfortunately, the probelm persists.

Now my exception is-
javax.naming.NamingException: ejb ref resolution error for remote business
interfaceff.fc.ume.session.UmeAccessBeanRemote [Root exception is
java.lang.RuntimeException: Could not invoke defineClass!]

My primary observations is this: Any basic java app connects to glassfish as
exactly as advertised using initialContext.lookup() when only the two jars
javaee and appsever-rt are part of its library. Therefore, one might expect
a netbeans platform application would do the same. But it does not.

So the question becomes what about a netbeans app would screw up the ability
of the initialContext.lookup() invocation to execute code in
appsever-rt.jar properly.

Its beyond me to trouble shoot that. Besides I was hoping to use the nb
platform to reduce work, not increase it.

Ive searched many posts on this. This post was intriguing:
http://openide.netbeans.org/servlets/ReadMsg?list=dev&msgNo=20713

But I was unable to use this command to resolve my issue.

The fact that many are struggling to simply connect a netbeans app to a
server is a statement about the popularity of web services as much as
anything.

For now I need to put either netbeans or glassfish aside.

thanks again, -js
--
Sergio Bello - Software Architect

Sintechno S.r.l. [www.sintechno.it]

Via Dante, 188
26100 - Cremona (ITALY)

Phone 0372 22942
Fax 0372 565287
Mobile 329 9499343
EMail address-removed
--
There are only 10 types of people in the world:
those who understand binary, and those who don't...
Back to top
Antonio
Posted via mailing list.





PostPosted: Fri Oct 24, 2008 11:51 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

jbsmathers wrote:
Quote:
Hi Antonio,

My netbeans module, where the code which attempts the lookup() is located,
has a declared a dependency on the glassfish wrapper module, as well as
declared dependency on a customEjb module which contains "MyObject".

Which is not what you want...

Quote:

Are you saying that the glassfish wrapper module needs to declare a
dependence on my customEJB module? I can give that a try.

... because it's the the glassfish classes that will have to know about
your "MyClass.class". Otherwise they won't be able to load your objects
coming from your EJB through the wire!

Quote:

I guess I can see that makes sense. The strict modularity of the netbeans
modules is something I need to be more aware of.

Thanks very much for your help and patience, -js
Back to top
Jay Smathers



Joined: 24 Oct 2008
Posts: 8

PostPosted: Fri Oct 24, 2008 11:54 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

ill give it try and let you know, thx again -jay


AntonioV wrote:
Quote:

jbsmathers wrote:
Quote:
Hi Antonio,

My netbeans module, where the code which attempts the lookup() is
located,
has a declared a dependency on the glassfish wrapper module, as well as
declared dependency on a customEjb module which contains "MyObject".

Which is not what you want...

Quote:

Are you saying that the glassfish wrapper module needs to declare a
dependence on my customEJB module? I can give that a try.

... because it's the the glassfish classes that will have to know about
your "MyClass.class". Otherwise they won't be able to load your objects
coming from your EJB through the wire!

Quote:

I guess I can see that makes sense. The strict modularity of the netbeans
modules is something I need to be more aware of.

Thanks very much for your help and patience, -js





--
View this message in context: http://www.nabble.com/Unable-to-get-my-nb-platform-module-suite-to-bootsrtrap-to-glassfish%27s-jndi-tp20154866p20159661.html
Sent from the Netbeans RCP/Platform Users (Open API) mailing list archive at Nabble.com.
Back to top
Antonio
Posted via mailing list.





PostPosted: Sat Oct 25, 2008 10:55 am    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

Hi,

Just to clarify my previous emails, let me explain with an example. Say
you have three modules:

- B module, with presentation tier business logic (your rich client app
module, with TopComponents and the such).

- I module, with interfaces and classes interchanged with remote EJBs
(including EJB stubs/skeletons). If your EJBs send you "MyClass.class"
then this module will contain such a class. Recent versions of Glassfish
don't require EJB stubs and skeletons (see [1]) but other app servers
will probably need these.

- G module, a library wrapper module with all glassfish internals (not
to run Glassfish inside your app, just to be able to be a client of
glassfish). (appserv-rt.jar and companions)

Dependencies should be:

B -> I
because your TopComponents in B need to use "MyClass.class" inside module I

B -> G
because your TopComponents need to access InitialContext stuff, which is
inside glassfish internals. Note: you should be using a "ServiceLocator"
pattern somewhere.

G -> I (G needs I to instantiate classes coming from EJBs too)
because your glassfish internal stuff should have access to
"MyClass.class" in order to be able to instantiate stuff coming from
your EJBs, as well as EJBs stubs and skeletons to invoke your EJBs.


With those dependencies I think things should work without problems, and
you'll still have a modular NB-based application (being able to
auto-update "I" when your server-side stubs/skeletons are updated, for
instance, which is something you'll probably need).

I'm not sure if this works or not (I may build a little example by next
week, though, just to verify), but I think everything *should* work well.

Hope it helps,
Antonio

[1] - https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#RMIStubsNeeded





jbsmathers wrote:
Quote:
Hi Antonio,

My netbeans module, where the code which attempts the lookup() is located,
has a declared a dependency on the glassfish wrapper module, as well as
declared dependency on a customEjb module which contains "MyObject".

Are you saying that the glassfish wrapper module needs to declare a
dependence on my customEJB module? I can give that a try.

I guess I can see that makes sense. The strict modularity of the netbeans
modules is something I need to be more aware of.

Thanks very much for your help and patience, -js




AntonioV wrote:
Quote:
Hi,

Say you want to invoke an EJB remotely. And that the EJB is sending you
an object of type "my.package.MyClass".

What is happening is that the J2EE server serializes the "MyClass"
instance in the remote server and then sends the serialized bytes back
to your running application.

In your running application what happens is that those bytes are
converted back into a "MyClass" object.

If your "MyClass.class" is not in your client-side classloader (your
RCP application) then you won't be able to load your object, and you'll
get a "NoClassDefFoundError" or a "ClassNotFoundException" or the
classloader is not able to load your class (so it cannot "invoke
defineclass").

So what you have to do is to place the "MyClass" object in the same
class loader as the classes that invoke the remote server, so that those
classes (responsible for de-serializing "MyClass" objects) can see the
"MyClass" class.

What this means is that you should add "MyClass" to those "Glassfish
Library Wrapper Module" we were talking about in an earlier post.

Sergio's solution is to add all classes (MyClass.class and all J2EE
server-side classes) in a special class loader used by the whole
application (by using "-cp:a" in the command line).

I don't like that solution myself, as it's not very "modular". But it
will work for sure.

Please let us again know how you're doing.

Cheers,
Antonio


jbsmathers wrote:
Quote:
Antonio and Sergio, thanks much. You both helped me to understand more
than I
did.

I now understand a jar's manifest, and I can understand which glassfish
dependencies are needed and I see that they match the jars which Sergio
is
including.

Unfortunately, the probelm persists.

Now my exception is-
javax.naming.NamingException: ejb ref resolution error for remote
business
interfaceff.fc.ume.session.UmeAccessBeanRemote [Root exception is
java.lang.RuntimeException: Could not invoke defineClass!]

My primary observations is this: Any basic java app connects to glassfish
as
exactly as advertised using initialContext.lookup() when only the two
jars
javaee and appsever-rt are part of its library. Therefore, one might
expect
a netbeans platform application would do the same. But it does not.

So the question becomes what about a netbeans app would screw up the
ability
of the initialContext.lookup() invocation to execute code in
appsever-rt.jar properly.

Its beyond me to trouble shoot that. Besides I was hoping to use the nb
platform to reduce work, not increase it.

Ive searched many posts on this. This post was intriguing:
http://openide.netbeans.org/servlets/ReadMsg?list=dev&msgNo=20713

But I was unable to use this command to resolve my issue.

The fact that many are struggling to simply connect a netbeans app to a
server is a statement about the popularity of web services as much as
anything.

For now I need to put either netbeans or glassfish aside.

thanks again, -js


Back to top
Jay Smathers



Joined: 24 Oct 2008
Posts: 8

PostPosted: Sat Oct 25, 2008 2:23 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

So far this has not resolved the issue.

After a nights sleep it also occurred to me the only thing my bean is
sending back to the client at this stage is a String, and perhaps this would
not require the glassfish jar to know about my classes.

Anyway I will re-check everything give it some more tries.

thx, -jay
--
View this message in context: http://www.nabble.com/Unable-to-get-my-nb-platform-module-suite-to-bootsrtrap-to-glassfish%27s-jndi-tp20154866p20164563.html
Sent from the Netbeans RCP/Platform Users (Open API) mailing list archive at Nabble.com.
Back to top
Antonio
Posted via mailing list.





PostPosted: Sat Oct 25, 2008 3:30 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

Hi,

I've been doing some experiments and it seems there's a classloader
issue that is preventing the RCP Application to correctly load the
following class:

com.sun.ejb.containers.GenericEJBHome

I've created an issue for this [1] and I've attached a test case there too.

Let's see what experts have to say regarding this.

Meanwhile, and as a workaround, I think you'd better place all jar files
in the system classloader (i.e. follow Sergio's recommendation).

Cheers,
Antonio

[1] - http://www.netbeans.org/issues/show_bug.cgi?id=151368


jbsmathers wrote:
Quote:
So far this has not resolved the issue.

After a nights sleep it also occurred to me the only thing my bean is
sending back to the client at this stage is a String, and perhaps this would
not require the glassfish jar to know about my classes.

Anyway I will re-check everything give it some more tries.

thx, -jay
Back to top
Antonio
Posted via mailing list.





PostPosted: Sat Oct 25, 2008 4:32 pm    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

Hi again,

After some more testing, I've seen that things seem to work if your ejb
objects and the glassfish client-side jars are bundled within the same
module.

Otherwise the bug will show its ugly face and things won't work.

Cheers,
Antonio


Antonio wrote:
Quote:
Hi,

I've been doing some experiments and it seems there's a classloader
issue that is preventing the RCP Application to correctly load the
following class:

com.sun.ejb.containers.GenericEJBHome

I've created an issue for this [1] and I've attached a test case there too.

Let's see what experts have to say regarding this.

Meanwhile, and as a workaround, I think you'd better place all jar files
in the system classloader (i.e. follow Sergio's recommendation).

Cheers,
Antonio

[1] - http://www.netbeans.org/issues/show_bug.cgi?id=151368


jbsmathers wrote:
Quote:
So far this has not resolved the issue.
After a nights sleep it also occurred to me the only thing my bean is
sending back to the client at this stage is a String, and perhaps this
would
not require the glassfish jar to know about my classes.

Anyway I will re-check everything give it some more tries.

thx, -jay

Back to top
sergej



Joined: 18 Aug 2008
Posts: 99
Location: Cremona (ITALY)

PostPosted: Sun Oct 26, 2008 10:07 am    Post subject: Unable to get my nb platform module suite to bootsrtrap to glassfish's jndi Reply with quote

Thanks, Antonio.
I'll try it, too, next week (I'm away from office just now).

Sergio


On Sat, 2008-10-25 at 18:31 +0200, Antonio wrote:
Quote:
Hi again,

After some more testing, I've seen that things seem to work if your ejb
objects and the glassfish client-side jars are bundled within the same
module.

Otherwise the bug will show its ugly face and things won't work.

Cheers,
Antonio


Antonio wrote:
Quote:
Hi,

I've been doing some experiments and it seems there's a classloader
issue that is preventing the RCP Application to correctly load the
following class:

com.sun.ejb.containers.GenericEJBHome

I've created an issue for this [1] and I've attached a test case there too.

Let's see what experts have to say regarding this.

Meanwhile, and as a workaround, I think you'd better place all jar files
in the system classloader (i.e. follow Sergio's recommendation).

Cheers,
Antonio

[1] - http://www.netbeans.org/issues/show_bug.cgi?id=151368


jbsmathers wrote:
Quote:
So far this has not resolved the issue.
After a nights sleep it also occurred to me the only thing my bean is
sending back to the client at this stage is a String, and perhaps this
would
not require the glassfish jar to know about my classes.

Anyway I will re-check everything give it some more tries.

thx, -jay


--
Sergio Bello - Software Architect

Sintechno S.r.l. [www.sintechno.it]

Via Dante, 188
26100 - Cremona (ITALY)

Phone 0372 22942
Fax 0372 565287
Mobile 329 9499343
EMail address-removed
--
There are only 10 types of people in the world:
those who understand binary, and those who don't...
Back to top
Jay Smathers



Joined: 24 Oct 2008
Posts: 8

PostPosted: Mon Oct 27, 2008 4:55 am    Post subject: also got it working by placing my ejbs and the glassfish jars in the same module... Reply with quote

Thanks so much to you both for the help.

I have been able to call my ejbs from a nb platform app by placing copies of my ejbs along side copies of the glassfish rmi jars and wrapping all these jars in one single nb library module.

i never would have tried that without your passing the information that it works, so thanks.

since this is not a good long term way to do things, how can I keep track of weather any progress is made to remedy this requirement by the netbeans developers?

-jay
Back to top
Display posts from previous:   
Post new topic   Reply to topic    NetBeans Forums -> NetBeans Platform Users All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo