You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Zachary1234 <st...@live.co.uk> on 2011/06/06 07:15:32 UTC
OPEN EJB most recent version and POJO's.
I it possible to simply deploy a plain old java object to
openEJB as a compiled class in a jar file,
and not as a fully blown EJB bean?
Does this object need to have a class annotation?
What is this annotation, what is it's import statement,
what is the lib jar file for it (is it in SE/EE Java)?
Presumably one can dispense with an xml
deployment description file?
--
View this message in context: http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3576153.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: OPEN EJB most recent version and POJO's.
Posted by David Blevins <da...@gmail.com>.
On Jun 7, 2011, at 8:38 PM, Zachary1234 wrote:
>
> Sorry, I had this message mixed up with another one.
> What I really wanted to ask was:
>
>
> Do I have to use the libs included with openEJB for the Bean Annotations described,
>
> or can I put javaee.jar, from the J2EE 5, in order to use the annotations
>
> from the default of the language itself, and still have the application server
>
> pick up the annotations and treat the annotated class as expected?
>
> Can I use javaee.jar, in a situation where I just want to or need to for other reasons?
You can certainly compile your classes and use any javaee jar you want in your IDE.
In terms of running in the server you should use the server provided libraries. It's hard to know what is or is not in the "javaee" jar of any vendor.
Strictly speaking the Java EE TCK tests that the required APIs are present and compliant in the classpath, but it does not test if they are in the same jar or spread across multiple jars. Geronimo for example doesn't have a javaee jar, instead each individual specification has its own jar. We do have a "javaee" jar made from the individual jars Geronimo produces, but with javamail excluded because that "API" is really an implementation and fixing bugs on it would require making a new javaee jar each time. The JACC API is also somewhat implementation heavy, but we include that in our javaee jar. As well OpenEJB has support internally for some EJB 3.1 features like @Singleton, etc. We put those in a separate jar because we didn't want people dependent on our javaee-api-5.0.jar to unknowingly become dependent on Java EE 6 features. We even gave it the name "ejb31-experimental-api.jar" so it communicated clearly that the spec was not final and everything was subject to change. We could probably change that to "ejb31-partial-api.jar" as the spec has been closed.
Some people have successfully swapped out the javaee api jar in the server as well. Wouldn't be something I would recommend until things are working well. And certainly in terms of submitting any bugs definitely first verify the bug also exists with the original version shipped by OpenEJB before filing anything.
-David
> Date: Tue, 7 Jun 2011 19:15:05 -0700
> From: ml-node+3581464-1241930645-42018@n4.nabble.com
> To: stargate7thsymbol@live.co.uk
> Subject: Re: OPEN EJB most recent version and POJO's.
>
>
>
>
> On Jun 7, 2011, at 5:11 PM, Zachary1234 wrote:
>
>
>> Do I have to use the libs included with JBOSS AS for the Bean Annotations described,
>
>> or can I put javaee.jar, from the J2EE 5, in order to use the annotations
>
>> from the default of the language itself, and still have the application server
>
>> pick up the annotations and treat the annotated class as expected?
>
>> Is there any extra conf/xml configuration required here?
>
>
> OpenEJB and JBoss are both implementations of EJB. Like OSX and Windows. Don't worry, you're not the first person to be confused by the project name and ask for JBoss or WebLogic or other server support :) We're a very patient bunch and understand it's hard when learning.
>
>
> If you wanted to use OpenEJB, this would be the best tutorial:
>
>
> https://cwiki.apache.org/OPENEJBx30/hello-world.html
>
> No xml required. Just use the libraries shown in that tutorial and you'll have your first EJB up and running.
>
>
> These examples are very nice too:
>
>
> http://openejb.apache.org/examples.html
>
>
> -David
>
>
>> Date: Tue, 7 Jun 2011 12:07:07 -0700
>
>> From: [hidden email]
>
>> To: [hidden email]
>
>> Subject: Re: OPEN EJB most recent version and POJO's.
>
>>
>
>>
>
>>
>
>> As of EJB 3.0 everything is based on POJOs exactly as you describe. POJOs with Remote and local access is supported through JNDI lookup. Different lifecycles are available. And all of it is standard and handled by the container exactly as you describe.
>
>>
>
>>
>
>> In addition they can offer security and transaction support and interceptors. Security is off by default, transactions are on by default but can be shut off, and interceptors don't factor in unless you explicitly add some.
>
>>
>
>>
>
>> On Jun 7, 2011, at 12:47 AM, Zachary1234 wrote:
>
>>
>
>>
>
>>> -A Pojo which I can have instantiated within openEJB
>
>>
>
>>> by the context.lookup call either
>
>>
>
>>
>
>> - @Stateful gives you a POJO that will be instantiated on lookup. Each lookup will result in a new instance of the POJO.
>
>>
>
>> - @Singleton gives you a POJO that will be instantiated on *first* lookup. Each subsequent lookup will give you a reference to the same bean.
>
>>
>
>>
>
>> See http://openejb.apache.org/3.0/simple-stateful-example.html
>> See http://openejb.apache.org/3.0/singleton-example.html
>>
>
>> There is another lifecycle called @Stateless, but doesn't sound like what you want. That is essentially a small pool of reusable instances hooked up to JNDI.
>
>>
>
>>
>
>> To get something into JNDI you need to use one of these three annotations on the POJO so we know how you want us to handle its lifecycle when lookups occur. I.e. it tells us what you want us to give the caller; a new instance, the same instance, or an instance from a pool.
>
>>
>
>>
>
>>> -from within another static class/object within the same openEJB instance
>
>>
>
>>
>
>> Putting @LocalBean on the pojo class will make it available locally for JNDI lookup -- no interface required. By default the MyClass pojo will be available in JNDI under the name "MyPojoLocalBean". This is configurable.
>
>>
>
>>
>
>> Putting @Local on an interface and implementing that interface in the pojo will make it available locally for lookup. Only the methods of the interface will be accessible by others in the same VM. By default the MyClass pojo will be available under the name "MyClassLocal"
>
>>
>
>>
>
>> To lookup specify org.apache.openejb.client.LocalInitialContextFactory as your Context.INITIAL_CONTEXT_FACTORY when creating the InitialContext, then use the name described above.
>
>>
>
>>
>
>> Note for unit testing, any @Remote interfaces (described below) can be looked up from the LocalInitialContextFactory as well. This is nice as the LocalInitialContextFactory involves no ports or actual networking code. Just plain direct access to JNDI of the VM you are in.
>
>>
>
>>
>
>>> -on the same PC in a seperate JVM.
>
>>
>
>>> -Or on a seperate PC in a seperate JVM, through a classic network.
>
>>
>
>>
>
>> Putting @Remote on an interface and implementing that interface in the bean will make it available remote for lookup and execution from another vm outside the server, either on the same PC or elsewhere in the network. By default the MyClass pojo will be available in JNDI under "MyClassRemote". This is configurable.
>
>>
>
>>
>
>> To lookup from a client in another vm specify org.apache.openejb.cient.RemoteInitialContextFactory as the Context.INITIAL_CONTEXT_FACTORY and "ejbd://theserver:4201" as the Context.PROVIDER_URL.
>
>>
>
>>
>
>>
>
>>> Of course, from seperate VM's, I intend to use JNDI.
>
>>
>
>>>
>
>>
>
>>> -If just calling a class from within another class,
>
>>
>
>>> do I just deploy the compiled class in a jar file
>
>>
>
>>> to the JBOSS AS deployment directory, as per normal?
>
>>
>
>>
>
>> Two options. You can put the app in a server, or you can put the server in your app.
>
>>
>
>>
>
>> Here is an example if putting the server in your app.
>
>>
>
>>
>
>> http://openejb.apache.org/3.0/embedded-and-remotable.html
>>
>
>> To put the app in a server, you just put the jar file of your app into the ${openejb.home}/apps/ directory and start the openejb server.
>
>>
>
>>
>
>>> -How can I run code like a main method
>
>>
>
>>> inside the Microcontainer/AS (non EJB, any version standard)?
>
>>
>
>>
>
>> I'm not sure what you might mean with this one, but the 'embedded-and-remote' might be what you are after. That gives you a plain 'main method' java application that can also service requests from remote clients.
>
>>
>
>>
>
>>> -If I then wish to use JNDI for context lookups,
>
>>
>
>>> how do I declare the POJO in my openEJB .class,.jar?
>
>>
>
>>> Is a simple annotation necessary for this?
>
>>
>
>>> -If annotation is necessary, what is the annotation
>
>>
>
>>> name/import statement/.jar lib filename?
>
>>
>
>>
>
>> This tutorial is a great one for showing all the steps with annotations and compiling and running. No IDE or build tool is used which makes it easier to see what is going on:
>
>>
>
>>
>
>> http://openejb.apache.org/hello-world.html
>>
>
>>
>
>> -David
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> If you reply to this email, your message will be added to the discussion below:
>
>> http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3580513.html
>>
>
>>
>
>>
>
>> To unsubscribe from OPEN EJB most recent version and POJO's., click here.
>
>>
>
>>
>
>> --
>
>> View this message in context: http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3581234.html
>> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
>
>
>
>
>
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3581464.html
>
>
>
> To unsubscribe from OPEN EJB most recent version and POJO's., click here.
>
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3581555.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
RE: OPEN EJB most recent version and POJO's.
Posted by Zachary1234 <st...@live.co.uk>.
Sorry, I had this message mixed up with another one.
What I really wanted to ask was:
Do I have to use the libs included with openEJB for the Bean Annotations described,
or can I put javaee.jar, from the J2EE 5, in order to use the annotations
from the default of the language itself, and still have the application server
pick up the annotations and treat the annotated class as expected?
Can I use javaee.jar, in a situation where I just want to or need to for other reasons?
Date: Tue, 7 Jun 2011 19:15:05 -0700
From: ml-node+3581464-1241930645-42018@n4.nabble.com
To: stargate7thsymbol@live.co.uk
Subject: Re: OPEN EJB most recent version and POJO's.
On Jun 7, 2011, at 5:11 PM, Zachary1234 wrote:
> Do I have to use the libs included with JBOSS AS for the Bean Annotations described,
> or can I put javaee.jar, from the J2EE 5, in order to use the annotations
> from the default of the language itself, and still have the application server
> pick up the annotations and treat the annotated class as expected?
> Is there any extra conf/xml configuration required here?
OpenEJB and JBoss are both implementations of EJB. Like OSX and Windows. Don't worry, you're not the first person to be confused by the project name and ask for JBoss or WebLogic or other server support :) We're a very patient bunch and understand it's hard when learning.
If you wanted to use OpenEJB, this would be the best tutorial:
https://cwiki.apache.org/OPENEJBx30/hello-world.html
No xml required. Just use the libraries shown in that tutorial and you'll have your first EJB up and running.
These examples are very nice too:
http://openejb.apache.org/examples.html
-David
> Date: Tue, 7 Jun 2011 12:07:07 -0700
> From: [hidden email]
> To: [hidden email]
> Subject: Re: OPEN EJB most recent version and POJO's.
>
>
>
> As of EJB 3.0 everything is based on POJOs exactly as you describe. POJOs with Remote and local access is supported through JNDI lookup. Different lifecycles are available. And all of it is standard and handled by the container exactly as you describe.
>
>
> In addition they can offer security and transaction support and interceptors. Security is off by default, transactions are on by default but can be shut off, and interceptors don't factor in unless you explicitly add some.
>
>
> On Jun 7, 2011, at 12:47 AM, Zachary1234 wrote:
>
>
>> -A Pojo which I can have instantiated within openEJB
>
>> by the context.lookup call either
>
>
> - @Stateful gives you a POJO that will be instantiated on lookup. Each lookup will result in a new instance of the POJO.
>
> - @Singleton gives you a POJO that will be instantiated on *first* lookup. Each subsequent lookup will give you a reference to the same bean.
>
>
> See http://openejb.apache.org/3.0/simple-stateful-example.html
> See http://openejb.apache.org/3.0/singleton-example.html
>
> There is another lifecycle called @Stateless, but doesn't sound like what you want. That is essentially a small pool of reusable instances hooked up to JNDI.
>
>
> To get something into JNDI you need to use one of these three annotations on the POJO so we know how you want us to handle its lifecycle when lookups occur. I.e. it tells us what you want us to give the caller; a new instance, the same instance, or an instance from a pool.
>
>
>> -from within another static class/object within the same openEJB instance
>
>
> Putting @LocalBean on the pojo class will make it available locally for JNDI lookup -- no interface required. By default the MyClass pojo will be available in JNDI under the name "MyPojoLocalBean". This is configurable.
>
>
> Putting @Local on an interface and implementing that interface in the pojo will make it available locally for lookup. Only the methods of the interface will be accessible by others in the same VM. By default the MyClass pojo will be available under the name "MyClassLocal"
>
>
> To lookup specify org.apache.openejb.client.LocalInitialContextFactory as your Context.INITIAL_CONTEXT_FACTORY when creating the InitialContext, then use the name described above.
>
>
> Note for unit testing, any @Remote interfaces (described below) can be looked up from the LocalInitialContextFactory as well. This is nice as the LocalInitialContextFactory involves no ports or actual networking code. Just plain direct access to JNDI of the VM you are in.
>
>
>> -on the same PC in a seperate JVM.
>
>> -Or on a seperate PC in a seperate JVM, through a classic network.
>
>
> Putting @Remote on an interface and implementing that interface in the bean will make it available remote for lookup and execution from another vm outside the server, either on the same PC or elsewhere in the network. By default the MyClass pojo will be available in JNDI under "MyClassRemote". This is configurable.
>
>
> To lookup from a client in another vm specify org.apache.openejb.cient.RemoteInitialContextFactory as the Context.INITIAL_CONTEXT_FACTORY and "ejbd://theserver:4201" as the Context.PROVIDER_URL.
>
>
>
>> Of course, from seperate VM's, I intend to use JNDI.
>
>>
>
>> -If just calling a class from within another class,
>
>> do I just deploy the compiled class in a jar file
>
>> to the JBOSS AS deployment directory, as per normal?
>
>
> Two options. You can put the app in a server, or you can put the server in your app.
>
>
> Here is an example if putting the server in your app.
>
>
> http://openejb.apache.org/3.0/embedded-and-remotable.html
>
> To put the app in a server, you just put the jar file of your app into the ${openejb.home}/apps/ directory and start the openejb server.
>
>
>> -How can I run code like a main method
>
>> inside the Microcontainer/AS (non EJB, any version standard)?
>
>
> I'm not sure what you might mean with this one, but the 'embedded-and-remote' might be what you are after. That gives you a plain 'main method' java application that can also service requests from remote clients.
>
>
>> -If I then wish to use JNDI for context lookups,
>
>> how do I declare the POJO in my openEJB .class,.jar?
>
>> Is a simple annotation necessary for this?
>
>> -If annotation is necessary, what is the annotation
>
>> name/import statement/.jar lib filename?
>
>
> This tutorial is a great one for showing all the steps with annotations and compiling and running. No IDE or build tool is used which makes it easier to see what is going on:
>
>
> http://openejb.apache.org/hello-world.html
>
>
> -David
>
>
>
>
>
>
>
>
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3580513.html
>
>
>
> To unsubscribe from OPEN EJB most recent version and POJO's., click here.
>
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3581234.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
If you reply to this email, your message will be added to the discussion below:
http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3581464.html
To unsubscribe from OPEN EJB most recent version and POJO's., click here.
--
View this message in context: http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3581555.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: OPEN EJB most recent version and POJO's.
Posted by David Blevins <da...@gmail.com>.
On Jun 7, 2011, at 5:11 PM, Zachary1234 wrote:
> Do I have to use the libs included with JBOSS AS for the Bean Annotations described,
> or can I put javaee.jar, from the J2EE 5, in order to use the annotations
> from the default of the language itself, and still have the application server
> pick up the annotations and treat the annotated class as expected?
> Is there any extra conf/xml configuration required here?
OpenEJB and JBoss are both implementations of EJB. Like OSX and Windows. Don't worry, you're not the first person to be confused by the project name and ask for JBoss or WebLogic or other server support :) We're a very patient bunch and understand it's hard when learning.
If you wanted to use OpenEJB, this would be the best tutorial:
https://cwiki.apache.org/OPENEJBx30/hello-world.html
No xml required. Just use the libraries shown in that tutorial and you'll have your first EJB up and running.
These examples are very nice too:
http://openejb.apache.org/examples.html
-David
> Date: Tue, 7 Jun 2011 12:07:07 -0700
> From: ml-node+3580513-1291411689-42018@n4.nabble.com
> To: stargate7thsymbol@live.co.uk
> Subject: Re: OPEN EJB most recent version and POJO's.
>
>
>
> As of EJB 3.0 everything is based on POJOs exactly as you describe. POJOs with Remote and local access is supported through JNDI lookup. Different lifecycles are available. And all of it is standard and handled by the container exactly as you describe.
>
>
> In addition they can offer security and transaction support and interceptors. Security is off by default, transactions are on by default but can be shut off, and interceptors don't factor in unless you explicitly add some.
>
>
> On Jun 7, 2011, at 12:47 AM, Zachary1234 wrote:
>
>
>> -A Pojo which I can have instantiated within openEJB
>
>> by the context.lookup call either
>
>
> - @Stateful gives you a POJO that will be instantiated on lookup. Each lookup will result in a new instance of the POJO.
>
> - @Singleton gives you a POJO that will be instantiated on *first* lookup. Each subsequent lookup will give you a reference to the same bean.
>
>
> See http://openejb.apache.org/3.0/simple-stateful-example.html
> See http://openejb.apache.org/3.0/singleton-example.html
>
> There is another lifecycle called @Stateless, but doesn't sound like what you want. That is essentially a small pool of reusable instances hooked up to JNDI.
>
>
> To get something into JNDI you need to use one of these three annotations on the POJO so we know how you want us to handle its lifecycle when lookups occur. I.e. it tells us what you want us to give the caller; a new instance, the same instance, or an instance from a pool.
>
>
>> -from within another static class/object within the same openEJB instance
>
>
> Putting @LocalBean on the pojo class will make it available locally for JNDI lookup -- no interface required. By default the MyClass pojo will be available in JNDI under the name "MyPojoLocalBean". This is configurable.
>
>
> Putting @Local on an interface and implementing that interface in the pojo will make it available locally for lookup. Only the methods of the interface will be accessible by others in the same VM. By default the MyClass pojo will be available under the name "MyClassLocal"
>
>
> To lookup specify org.apache.openejb.client.LocalInitialContextFactory as your Context.INITIAL_CONTEXT_FACTORY when creating the InitialContext, then use the name described above.
>
>
> Note for unit testing, any @Remote interfaces (described below) can be looked up from the LocalInitialContextFactory as well. This is nice as the LocalInitialContextFactory involves no ports or actual networking code. Just plain direct access to JNDI of the VM you are in.
>
>
>> -on the same PC in a seperate JVM.
>
>> -Or on a seperate PC in a seperate JVM, through a classic network.
>
>
> Putting @Remote on an interface and implementing that interface in the bean will make it available remote for lookup and execution from another vm outside the server, either on the same PC or elsewhere in the network. By default the MyClass pojo will be available in JNDI under "MyClassRemote". This is configurable.
>
>
> To lookup from a client in another vm specify org.apache.openejb.cient.RemoteInitialContextFactory as the Context.INITIAL_CONTEXT_FACTORY and "ejbd://theserver:4201" as the Context.PROVIDER_URL.
>
>
>
>> Of course, from seperate VM's, I intend to use JNDI.
>
>>
>
>> -If just calling a class from within another class,
>
>> do I just deploy the compiled class in a jar file
>
>> to the JBOSS AS deployment directory, as per normal?
>
>
> Two options. You can put the app in a server, or you can put the server in your app.
>
>
> Here is an example if putting the server in your app.
>
>
> http://openejb.apache.org/3.0/embedded-and-remotable.html
>
> To put the app in a server, you just put the jar file of your app into the ${openejb.home}/apps/ directory and start the openejb server.
>
>
>> -How can I run code like a main method
>
>> inside the Microcontainer/AS (non EJB, any version standard)?
>
>
> I'm not sure what you might mean with this one, but the 'embedded-and-remote' might be what you are after. That gives you a plain 'main method' java application that can also service requests from remote clients.
>
>
>> -If I then wish to use JNDI for context lookups,
>
>> how do I declare the POJO in my openEJB .class,.jar?
>
>> Is a simple annotation necessary for this?
>
>> -If annotation is necessary, what is the annotation
>
>> name/import statement/.jar lib filename?
>
>
> This tutorial is a great one for showing all the steps with annotations and compiling and running. No IDE or build tool is used which makes it easier to see what is going on:
>
>
> http://openejb.apache.org/hello-world.html
>
>
> -David
>
>
>
>
>
>
>
>
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3580513.html
>
>
>
> To unsubscribe from OPEN EJB most recent version and POJO's., click here.
>
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3581234.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
RE: OPEN EJB most recent version and POJO's.
Posted by Zachary1234 <st...@live.co.uk>.
Do I have to use the libs included with JBOSS AS for the Bean Annotations described,
or can I put javaee.jar, from the J2EE 5, in order to use the annotations
from the default of the language itself, and still have the application server
pick up the annotations and treat the annotated class as expected?
Is there any extra conf/xml configuration required here?
Date: Tue, 7 Jun 2011 12:07:07 -0700
From: ml-node+3580513-1291411689-42018@n4.nabble.com
To: stargate7thsymbol@live.co.uk
Subject: Re: OPEN EJB most recent version and POJO's.
As of EJB 3.0 everything is based on POJOs exactly as you describe. POJOs with Remote and local access is supported through JNDI lookup. Different lifecycles are available. And all of it is standard and handled by the container exactly as you describe.
In addition they can offer security and transaction support and interceptors. Security is off by default, transactions are on by default but can be shut off, and interceptors don't factor in unless you explicitly add some.
On Jun 7, 2011, at 12:47 AM, Zachary1234 wrote:
> -A Pojo which I can have instantiated within openEJB
> by the context.lookup call either
- @Stateful gives you a POJO that will be instantiated on lookup. Each lookup will result in a new instance of the POJO.
- @Singleton gives you a POJO that will be instantiated on *first* lookup. Each subsequent lookup will give you a reference to the same bean.
See http://openejb.apache.org/3.0/simple-stateful-example.html
See http://openejb.apache.org/3.0/singleton-example.html
There is another lifecycle called @Stateless, but doesn't sound like what you want. That is essentially a small pool of reusable instances hooked up to JNDI.
To get something into JNDI you need to use one of these three annotations on the POJO so we know how you want us to handle its lifecycle when lookups occur. I.e. it tells us what you want us to give the caller; a new instance, the same instance, or an instance from a pool.
> -from within another static class/object within the same openEJB instance
Putting @LocalBean on the pojo class will make it available locally for JNDI lookup -- no interface required. By default the MyClass pojo will be available in JNDI under the name "MyPojoLocalBean". This is configurable.
Putting @Local on an interface and implementing that interface in the pojo will make it available locally for lookup. Only the methods of the interface will be accessible by others in the same VM. By default the MyClass pojo will be available under the name "MyClassLocal"
To lookup specify org.apache.openejb.client.LocalInitialContextFactory as your Context.INITIAL_CONTEXT_FACTORY when creating the InitialContext, then use the name described above.
Note for unit testing, any @Remote interfaces (described below) can be looked up from the LocalInitialContextFactory as well. This is nice as the LocalInitialContextFactory involves no ports or actual networking code. Just plain direct access to JNDI of the VM you are in.
> -on the same PC in a seperate JVM.
> -Or on a seperate PC in a seperate JVM, through a classic network.
Putting @Remote on an interface and implementing that interface in the bean will make it available remote for lookup and execution from another vm outside the server, either on the same PC or elsewhere in the network. By default the MyClass pojo will be available in JNDI under "MyClassRemote". This is configurable.
To lookup from a client in another vm specify org.apache.openejb.cient.RemoteInitialContextFactory as the Context.INITIAL_CONTEXT_FACTORY and "ejbd://theserver:4201" as the Context.PROVIDER_URL.
> Of course, from seperate VM's, I intend to use JNDI.
>
> -If just calling a class from within another class,
> do I just deploy the compiled class in a jar file
> to the JBOSS AS deployment directory, as per normal?
Two options. You can put the app in a server, or you can put the server in your app.
Here is an example if putting the server in your app.
http://openejb.apache.org/3.0/embedded-and-remotable.html
To put the app in a server, you just put the jar file of your app into the ${openejb.home}/apps/ directory and start the openejb server.
> -How can I run code like a main method
> inside the Microcontainer/AS (non EJB, any version standard)?
I'm not sure what you might mean with this one, but the 'embedded-and-remote' might be what you are after. That gives you a plain 'main method' java application that can also service requests from remote clients.
> -If I then wish to use JNDI for context lookups,
> how do I declare the POJO in my openEJB .class,.jar?
> Is a simple annotation necessary for this?
> -If annotation is necessary, what is the annotation
> name/import statement/.jar lib filename?
This tutorial is a great one for showing all the steps with annotations and compiling and running. No IDE or build tool is used which makes it easier to see what is going on:
http://openejb.apache.org/hello-world.html
-David
If you reply to this email, your message will be added to the discussion below:
http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3580513.html
To unsubscribe from OPEN EJB most recent version and POJO's., click here.
--
View this message in context: http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3581234.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: OPEN EJB most recent version and POJO's.
Posted by David Blevins <da...@gmail.com>.
As of EJB 3.0 everything is based on POJOs exactly as you describe. POJOs with Remote and local access is supported through JNDI lookup. Different lifecycles are available. And all of it is standard and handled by the container exactly as you describe.
In addition they can offer security and transaction support and interceptors. Security is off by default, transactions are on by default but can be shut off, and interceptors don't factor in unless you explicitly add some.
On Jun 7, 2011, at 12:47 AM, Zachary1234 wrote:
> -A Pojo which I can have instantiated within openEJB
> by the context.lookup call either
- @Stateful gives you a POJO that will be instantiated on lookup. Each lookup will result in a new instance of the POJO.
- @Singleton gives you a POJO that will be instantiated on *first* lookup. Each subsequent lookup will give you a reference to the same bean.
See http://openejb.apache.org/3.0/simple-stateful-example.html
See http://openejb.apache.org/3.0/singleton-example.html
There is another lifecycle called @Stateless, but doesn't sound like what you want. That is essentially a small pool of reusable instances hooked up to JNDI.
To get something into JNDI you need to use one of these three annotations on the POJO so we know how you want us to handle its lifecycle when lookups occur. I.e. it tells us what you want us to give the caller; a new instance, the same instance, or an instance from a pool.
> -from within another static class/object within the same openEJB instance
Putting @LocalBean on the pojo class will make it available locally for JNDI lookup -- no interface required. By default the MyClass pojo will be available in JNDI under the name "MyPojoLocalBean". This is configurable.
Putting @Local on an interface and implementing that interface in the pojo will make it available locally for lookup. Only the methods of the interface will be accessible by others in the same VM. By default the MyClass pojo will be available under the name "MyClassLocal"
To lookup specify org.apache.openejb.client.LocalInitialContextFactory as your Context.INITIAL_CONTEXT_FACTORY when creating the InitialContext, then use the name described above.
Note for unit testing, any @Remote interfaces (described below) can be looked up from the LocalInitialContextFactory as well. This is nice as the LocalInitialContextFactory involves no ports or actual networking code. Just plain direct access to JNDI of the VM you are in.
> -on the same PC in a seperate JVM.
> -Or on a seperate PC in a seperate JVM, through a classic network.
Putting @Remote on an interface and implementing that interface in the bean will make it available remote for lookup and execution from another vm outside the server, either on the same PC or elsewhere in the network. By default the MyClass pojo will be available in JNDI under "MyClassRemote". This is configurable.
To lookup from a client in another vm specify org.apache.openejb.cient.RemoteInitialContextFactory as the Context.INITIAL_CONTEXT_FACTORY and "ejbd://theserver:4201" as the Context.PROVIDER_URL.
> Of course, from seperate VM's, I intend to use JNDI.
>
> -If just calling a class from within another class,
> do I just deploy the compiled class in a jar file
> to the JBOSS AS deployment directory, as per normal?
Two options. You can put the app in a server, or you can put the server in your app.
Here is an example if putting the server in your app.
http://openejb.apache.org/3.0/embedded-and-remotable.html
To put the app in a server, you just put the jar file of your app into the ${openejb.home}/apps/ directory and start the openejb server.
> -How can I run code like a main method
> inside the Microcontainer/AS (non EJB, any version standard)?
I'm not sure what you might mean with this one, but the 'embedded-and-remote' might be what you are after. That gives you a plain 'main method' java application that can also service requests from remote clients.
> -If I then wish to use JNDI for context lookups,
> how do I declare the POJO in my openEJB .class,.jar?
> Is a simple annotation necessary for this?
> -If annotation is necessary, what is the annotation
> name/import statement/.jar lib filename?
This tutorial is a great one for showing all the steps with annotations and compiling and running. No IDE or build tool is used which makes it easier to see what is going on:
http://openejb.apache.org/hello-world.html
-David
Re: OPEN EJB most recent version and POJO's.
Posted by Zachary1234 <st...@live.co.uk>.
Not quite, I'm simply looking for an example for how to
declare
-A Pojo which I can have instantiated within openEJB
by the context.lookup call either
-from within another static class/object within the same openEJB instance
-on the same PC in a seperate JVM.
-Or on a seperate PC in a seperate JVM, through a classic network.
Of course, from seperate VM's, I intend to use JNDI.
-If just calling a class from within another class,
do I just deploy the compiled class in a jar file
to the JBOSS AS deployment directory, as per normal?
-How can I run code like a main method
inside the Microcontainer/AS (non EJB, any version standard)?
-If I then wish to use JNDI for context lookups,
how do I declare the POJO in my openEJB .class,.jar?
Is a simple annotation necessary for this?
-If annotation is necessary, what is the annotation
name/import statement/.jar lib filename?
--
View this message in context: http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3578871.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: OPEN EJB most recent version and POJO's.
Posted by David Blevins <da...@gmail.com>.
On Jun 6, 2011, at 4:15 PM, Zachary1234 wrote:
>
> However, if I wish to access the pojo outside of openEJB,
> or even on another network pc, the way to go is JNDI.
> Is there an easy way to bind a class or interface pojo
> to JNDI? Will just @JNDI (with an optional name)
> at the top do the trick?
I suspect you might be falling victim to the "EJB is bad and heavy" marketing.
Here are some performance numbers
240,000 http://people.apache.org/~dblevins/pojo-performance.png
212,000 http://people.apache.org/~dblevins/openejb-3.1.4-local-performance.png
112,000 http://people.apache.org/~dblevins/openejb-3.1.4-remote-serverside-performance.png
31,600 http://people.apache.org/~dblevins/openejb-3.1.4-remote-clientside-performance.png
Each with 20 threads invoking this object https://gist.github.com/1011785
The first numbers are the class being invoked via calling it directly, not as an EJB.
The second set of numbers are it being invoked as an EJB via its @Local interface.
The third set is it being invoked as an @Remote EJB, but still inside the vm of the server. We use the same code for Local and Remote interfaces when calls are in the same VM as the server where the bean lives. Under the covers the only actual difference is we have to perform an extra serialization step as required by the EJB spec.
The fourth set is it being invoked by a client over the network. Now we're getting into sockets and networking hardware. It looks bad next to the pojo and local calls, but it's actually pretty great. To put in perspective, last time I did this measuring I added Jetty to the picture as it's known to have great performance. Our socket handling code came in about 3x faster. It's not apples to apples as they are designed for different things. Here's the details on that:
http://openejb.979440.n4.nabble.com/Remote-client-performance-td987613.html
Also note, you get some pretty create failover support in the ejb client code:
http://openejb.apache.org/3.0/failover.html
Happy to give all the setup code if you want to do some playing on your own. Uses all open source tools.
-David
RE: OPEN EJB most recent version and POJO's.
Posted by Zachary1234 <st...@live.co.uk>.
However, if I wish to access the pojo outside of openEJB,
or even on another network pc, the way to go is JNDI.
Is there an easy way to bind a class or interface pojo
to JNDI? Will just @JNDI (with an optional name)
at the top do the trick?
Date: Mon, 6 Jun 2011 05:47:52 -0700
From: ml-node+3576817-2077569707-42018@n4.nabble.com
To: stargate7thsymbol@live.co.uk
Subject: Re: OPEN EJB most recent version and POJO's.
Yes, it's possible.
I'm using something like this:
Swing -> @Stateless Session Beans -> POJOs, @Entities and Database operations.
You don't have to annotate it.
If you reply to this email, your message will be added to the discussion below:
http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3576817.html
To unsubscribe from OPEN EJB most recent version and POJO's., click here.
--
View this message in context: http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3578286.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: OPEN EJB most recent version and POJO's.
Posted by Andre Brito <an...@gmail.com>.
Yes, it's possible.
I'm using something like this:
Swing -> @Stateless Session Beans -> POJOs, @Entities and Database
operations.
You don't have to annotate it.
--
View this message in context: http://openejb.979440.n4.nabble.com/OPEN-EJB-most-recent-version-and-POJO-s-tp3576153p3576817.html
Sent from the OpenEJB User mailing list archive at Nabble.com.