You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2009/03/11 20:26:32 UTC
EJB 3.1 PFD2 is up for download
The JSR #318 Expert Group has put another Proposed Final Draft (PFD)
up for download:
Enterprise JavaBeans 3.1
http://jcp.org/aboutJava/communityprocess/pfd/jsr318/index.html
Note this is still a draft and no the final spec.
Have a look at chapter 22 and see if anything feels familiar.
Essentially this:
Properties p = new Properties();
p.put("java.naming.factory.initial",
"org.apache.openejb.client.LocalInitialContextFactory");
p.put("movieDatabase", "new://Resource?type=DataSource");
p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
p.put("movieDatabaseUnmanaged.JdbcDriver",
"org.hsqldb.jdbcDriver");
p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged.JtaManaged", "false");
Context context = new InitialContext(p);
Movies movies = (Movies) context.lookup("MoviesLocal");
Becomes this:
Properties p = new Properties();
p.put("javax.ejb.embeddable.initial",
"org.apache.openejb.client.LocalInitialContextFactory");
p.put("movieDatabase", "new://Resource?type=DataSource");
p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
p.put("movieDatabaseUnmanaged.JdbcDriver",
"org.hsqldb.jdbcDriver");
p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged.JtaManaged", "false");
EJBContainer container = EJBContainer.createEJBContainer(p);
Context context = container.getContext();
Movies movies = (Movies) context.lookup("MoviesLocal");
-David
Re: POJO Injection (Re: EJB 3.1 PFD2 is up for download)
Posted by David Blevins <da...@visi.com>.
On Apr 22, 2009, at 2:22 PM, David Blevins wrote:
> On Mar 12, 2009, at 12:45 PM, David Blevins wrote:
>
>> On Mar 12, 2009, at 5:25 AM, Karan Malhi wrote:
>>
>>>>
>>>> Regardless, that won't stop us from implementing it :) I suspect
>>>> if we do
>>>> it and other vendors follow suit, it'll pretty much have to make
>>>> it into the
>>>> spec next time around.
>>>
>>> Nice! . Is this on the top of your priority list? I have an area
>>> in struts2
>>> integration which could use this funcionality.
>>
>> Not the top, but very high. Top priority in my mind right now is
>> getting our JNDI awkwardness straightened out.
>>
>> The easiest way to implement this would be to scan at deployment
>> like everything else perhaps by adding an
>> "@org.apache.openejb.annotations.Injectable" annotation or
>> something. Would be great if we didn't have to do even that, but
>> certainly would be the easiest first step. Could probably get that
>> in in a day or two and wouldn't at all limit our ability to do it
>> without the annotation later. With the annotation, the user would
>> get the same deploy time checks as other EE components and without
>> it'd be all runtime checks. So both seem like a pretty ideal
>> solution.
>
> Going to see if I can't take a swing at this feature as described
> here. Likely will involve adding a new container/openejb-
> annotation/ module to hold the annotation so people have a jar they
> can use free of any other dependencies and just holds "API" things.
> If we end up supporting more annotations, we'll have a place to put
> them.
Took a swing at this a couple weeks ago but had to put it down to
focus on other things. Took today to polish off what I had and get it
in as we need to start the release process -- would be really great to
have a release out by JavaOne.
Had to scale back what I was imagining to get it in. So currently
what we have is essentially a way for plain java clients (i.e. non-
J2EE application clients) to get some injection action. And more
specifically it's limited to local clients which are most likely test
cases or other embedded usage. Would be great to expand this to
remote clients accessing the server over a network, but that will have
to wait. Would also be great to allow any class to be injectable even
if it isn't a "client" in the strictest sense, but that will also have
to wait.
Anyway, check out the example:
http://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/testcase-injection/
-David
POJO Injection (Re: EJB 3.1 PFD2 is up for download)
Posted by David Blevins <da...@visi.com>.
On Mar 12, 2009, at 12:45 PM, David Blevins wrote:
> On Mar 12, 2009, at 5:25 AM, Karan Malhi wrote:
>
>>>
>>> Regardless, that won't stop us from implementing it :) I suspect
>>> if we do
>>> it and other vendors follow suit, it'll pretty much have to make
>>> it into the
>>> spec next time around.
>>
>> Nice! . Is this on the top of your priority list? I have an area
>> in struts2
>> integration which could use this funcionality.
>
> Not the top, but very high. Top priority in my mind right now is
> getting our JNDI awkwardness straightened out.
>
> The easiest way to implement this would be to scan at deployment
> like everything else perhaps by adding an
> "@org.apache.openejb.annotations.Injectable" annotation or
> something. Would be great if we didn't have to do even that, but
> certainly would be the easiest first step. Could probably get that
> in in a day or two and wouldn't at all limit our ability to do it
> without the annotation later. With the annotation, the user would
> get the same deploy time checks as other EE components and without
> it'd be all runtime checks. So both seem like a pretty ideal
> solution.
Going to see if I can't take a swing at this feature as described
here. Likely will involve adding a new container/openejb-annotation/
module to hold the annotation so people have a jar they can use free
of any other dependencies and just holds "API" things. If we end up
supporting more annotations, we'll have a place to put them.
-David
Re: EJB 3.1 PFD2 is up for download
Posted by David Blevins <da...@visi.com>.
On Mar 12, 2009, at 5:25 AM, Karan Malhi wrote:
>>
>> Regardless, that won't stop us from implementing it :) I suspect
>> if we do
>> it and other vendors follow suit, it'll pretty much have to make it
>> into the
>> spec next time around.
>
> Nice! . Is this on the top of your priority list? I have an area in
> struts2
> integration which could use this funcionality.
Not the top, but very high. Top priority in my mind right now is
getting our JNDI awkwardness straightened out.
The easiest way to implement this would be to scan at deployment like
everything else perhaps by adding an
"@org.apache.openejb.annotations.Injectable" annotation or something.
Would be great if we didn't have to do even that, but certainly would
be the easiest first step. Could probably get that in in a day or two
and wouldn't at all limit our ability to do it without the annotation
later. With the annotation, the user would get the same deploy time
checks as other EE components and without it'd be all runtime checks.
So both seem like a pretty ideal solution.
>> 3) if more than one EJBContainer is active and the most recently
>> created
>> one is closed, do you return the current closed container, the most
>> recent
>> open container, null, or throw an exception.
>>
> This is tricky.Does that mean that per JVM there could be multiple
> EJBContainer's? If thats the case then this method could throw an
> exception.
Not a requirement which is good, but some thought it might imply that.
In our impl, the number of container systems you can put in your VM
depends on the number of classloaders that have loaded the openejb-
loader and openejb-core jars. In most cases that's going to be
exactly one as people load those jars right in the system classpath.
Basically, it boils down to the statics. If you have five sibling
classloaders and each of them have their own openejb-loader and
openejb-container jars and the parent classloader has neither of those
jars, you could have five container systems, one in each classloader.
-David
Re: EJB 3.1 PFD2 is up for download
Posted by Karan Malhi <ka...@gmail.com>.
On Thu, Mar 12, 2009 at 12:39 AM, David Blevins <da...@visi.com>wrote:
>
> On Mar 11, 2009, at 7:43 PM, Karan Malhi wrote:
>
>
>>> Definitely. We went with the new class over the InitialContext as it
>>> gives
>>> us the ability to add methods and functionality in future specs. Always
>>> a
>>> nice door to leave open.
>>>
>>> EJBContainer container = EJBContainer.createEJBContainer(p);
>>>>
>>>>>
>>>>>
>>>> Would love to see some more methods in EJBContainer like
>>
>> public Object inject(Class clazz){
>> // creates a new instance of the clazz and injects dependencies in it and
>> returns the object
>> }
>> public void inject(Object obj){
>> // inject dependencies into obj
>> }
>>
>> The above would make it easy to add injection support to other frameworks
>> like struts, jsf etc.
>>
>
> You and me both.
Wanted to mention that we discussed the above methods on IRC. Wanted to
share them with the dev list
> There was talk of general functionality like that at the JSR-316 (EE 6)
> level and as a result there was moratorium on identical functionality in the
> other specs. The talks stalled and nothing was ever flushed out. Now it's
> too late.
>
> Regardless, that won't stop us from implementing it :) I suspect if we do
> it and other vendors follow suit, it'll pretty much have to make it into the
> spec next time around.
Nice! . Is this on the top of your priority list? I have an area in struts2
integration which could use this funcionality.
>
>
> Would also be nice to have a method which returns the current instance of
>> the EJBContainer.
>>
>
> We had something like that and it got messy quick. The questions it raises
> are
> 1) what happens if it is called before createEJBContainer and no instance
> has yet been created; do you create one automatically, return null, or throw
> an exception,
return null
> 2) what happens if it is called after the EJBContainer has been closed
>
return null
> 3) if more than one EJBContainer is active and the most recently created
> one is closed, do you return the current closed container, the most recent
> open container, null, or throw an exception.
>
This is tricky.Does that mean that per JVM there could be multiple
EJBContainer's? If thats the case then this method could throw an
exception.
>
> I personally never liked it as 'public static EJBContainer ejbContainer' in
> your own code is extremely simple and doesn't require people to learn
> anything, reduces the amount of new things they have to deal with, and
> there's zero chance for misinterpreting the spec.
Agree, we could always write our own utility for that. So ignore the
responses to 1,2,3 above :)
>
> -David
>
>
--
Karan Singh Malhi
Re: EJB 3.1 PFD2 is up for download
Posted by David Blevins <da...@visi.com>.
On Mar 11, 2009, at 7:43 PM, Karan Malhi wrote:
>>
>> Definitely. We went with the new class over the InitialContext as
>> it gives
>> us the ability to add methods and functionality in future specs.
>> Always a
>> nice door to leave open.
>>
>>> EJBContainer container = EJBContainer.createEJBContainer(p);
>>>>
>>>
> Would love to see some more methods in EJBContainer like
>
> public Object inject(Class clazz){
> // creates a new instance of the clazz and injects dependencies in
> it and
> returns the object
> }
> public void inject(Object obj){
> // inject dependencies into obj
> }
>
> The above would make it easy to add injection support to other
> frameworks
> like struts, jsf etc.
You and me both. There was talk of general functionality like that at
the JSR-316 (EE 6) level and as a result there was moratorium on
identical functionality in the other specs. The talks stalled and
nothing was ever flushed out. Now it's too late.
Regardless, that won't stop us from implementing it :) I suspect if
we do it and other vendors follow suit, it'll pretty much have to make
it into the spec next time around.
> Would also be nice to have a method which returns the current
> instance of
> the EJBContainer.
We had something like that and it got messy quick. The questions it
raises are 1) what happens if it is called before createEJBContainer
and no instance has yet been created; do you create one automatically,
return null, or throw an exception, 2) what happens if it is called
after the EJBContainer has been closed 3) if more than one
EJBContainer is active and the most recently created one is closed, do
you return the current closed container, the most recent open
container, null, or throw an exception.
I personally never liked it as 'public static EJBContainer
ejbContainer' in your own code is extremely simple and doesn't require
people to learn anything, reduces the amount of new things they have
to deal with, and there's zero chance for misinterpreting the spec.
-David
Re: EJB 3.1 PFD2 is up for download
Posted by Karan Malhi <ka...@gmail.com>.
>
> Definitely. We went with the new class over the InitialContext as it gives
> us the ability to add methods and functionality in future specs. Always a
> nice door to leave open.
>
>> EJBContainer container = EJBContainer.createEJBContainer(p);
>>>
>>
Would love to see some more methods in EJBContainer like
public Object inject(Class clazz){
// creates a new instance of the clazz and injects dependencies in it and
returns the object
}
public void inject(Object obj){
// inject dependencies into obj
}
The above would make it easy to add injection support to other frameworks
like struts, jsf etc.
Would also be nice to have a method which returns the current instance of
the EJBContainer.
--
Karan Singh Malhi
Re: EJB 3.1 PFD2 is up for download
Posted by David Blevins <da...@visi.com>.
On Mar 11, 2009, at 12:56 PM, Karan Malhi wrote:
> Awesome,
>
> This feature could pretty much make it into the spec as is !! . Very
> cool !
Definitely. We went with the new class over the InitialContext as it
gives us the ability to add methods and functionality in future
specs. Always a nice door to leave open.
-David
> On Wed, Mar 11, 2009 at 3:26 PM, David Blevins
> <da...@visi.com>wrote:
>
>> The JSR #318 Expert Group has put another Proposed Final Draft
>> (PFD) up for
>> download:
>>
>> Enterprise JavaBeans 3.1
>>
>> http://jcp.org/aboutJava/communityprocess/pfd/jsr318/index.html
>>
>> Note this is still a draft and no the final spec.
>>
>> Have a look at chapter 22 and see if anything feels familiar.
>>
>> Essentially this:
>>
>> Properties p = new Properties();
>> p.put("java.naming.factory.initial",
>> "org.apache.openejb.client.LocalInitialContextFactory");
>> p.put("movieDatabase", "new://Resource?type=DataSource");
>> p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
>> p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
>>
>> p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
>> p.put("movieDatabaseUnmanaged.JdbcDriver",
>> "org.hsqldb.jdbcDriver");
>> p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
>> p.put("movieDatabaseUnmanaged.JtaManaged", "false");
>>
>> Context context = new InitialContext(p);
>>
>> Movies movies = (Movies) context.lookup("MoviesLocal");
>>
>> Becomes this:
>>
>> Properties p = new Properties();
>> p.put("javax.ejb.embeddable.initial",
>> "org.apache.openejb.client.LocalInitialContextFactory");
>> p.put("movieDatabase", "new://Resource?type=DataSource");
>> p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
>> p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
>>
>> p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
>> p.put("movieDatabaseUnmanaged.JdbcDriver",
>> "org.hsqldb.jdbcDriver");
>> p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
>> p.put("movieDatabaseUnmanaged.JtaManaged", "false");
>>
>> EJBContainer container = EJBContainer.createEJBContainer(p);
>>
>> Context context = container.getContext();
>>
>> Movies movies = (Movies) context.lookup("MoviesLocal");
>>
>>
>> -David
>>
>>
>
>
> --
> Karan Singh Malhi
Re: EJB 3.1 PFD2 is up for download
Posted by Karan Malhi <ka...@gmail.com>.
Awesome,
This feature could pretty much make it into the spec as is !! . Very cool !
On Wed, Mar 11, 2009 at 3:26 PM, David Blevins <da...@visi.com>wrote:
> The JSR #318 Expert Group has put another Proposed Final Draft (PFD) up for
> download:
>
> Enterprise JavaBeans 3.1
>
> http://jcp.org/aboutJava/communityprocess/pfd/jsr318/index.html
>
> Note this is still a draft and no the final spec.
>
> Have a look at chapter 22 and see if anything feels familiar.
>
> Essentially this:
>
> Properties p = new Properties();
> p.put("java.naming.factory.initial",
> "org.apache.openejb.client.LocalInitialContextFactory");
> p.put("movieDatabase", "new://Resource?type=DataSource");
> p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
> p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
>
> p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
> p.put("movieDatabaseUnmanaged.JdbcDriver", "org.hsqldb.jdbcDriver");
> p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
> p.put("movieDatabaseUnmanaged.JtaManaged", "false");
>
> Context context = new InitialContext(p);
>
> Movies movies = (Movies) context.lookup("MoviesLocal");
>
> Becomes this:
>
> Properties p = new Properties();
> p.put("javax.ejb.embeddable.initial",
> "org.apache.openejb.client.LocalInitialContextFactory");
> p.put("movieDatabase", "new://Resource?type=DataSource");
> p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
> p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
>
> p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
> p.put("movieDatabaseUnmanaged.JdbcDriver", "org.hsqldb.jdbcDriver");
> p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
> p.put("movieDatabaseUnmanaged.JtaManaged", "false");
>
> EJBContainer container = EJBContainer.createEJBContainer(p);
>
> Context context = container.getContext();
>
> Movies movies = (Movies) context.lookup("MoviesLocal");
>
>
> -David
>
>
--
Karan Singh Malhi
Re: EJB 3.1 PFD2 is up for download
Posted by is_maximum <mn...@gmail.com>.
Great.
Does this EJBContainer, probabely, have a getSession() or (getUnitOfWork())
or something in which we can access the session and set parameters to be
valid in the request scope and accessible across the application during
serving of a request?
The idea of unit-of-work is really nice and in my experience with EJB I
frequently was in trouble for lacking of this feature
please have a look at this article:
http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-abomination
The nice thing in EJB3.1 is Singleton session beans and I am eager to see it
in actual work
but another problem is exceptions thrown from the JPA. I didn't have enough
time to read the draft completely but is there any exception defined like
UniqueConstraintViolatedException?
This exception is really vital. consider a user entered a code which is
already inserted and we have a unique-constraint defined in DB. how we can
notify the user that the code you inserted is already taken by another
record? Currently the only exception we get is PersistenceException and you
can't even parse it to find out what the problem is!!! and we send back the
general message "You made a mistake in entered data!!!!" and you know how
much users will be angered by this vague message.
The only solution is to enquiry for each insertion request to check if the
code is already exist and I don't think this is a good idea in terms of
performance and desing.
Thanks
-----
--
Regards
Mohammad Norouzi
Help each other to reach the future faster
http://pixelshot.wordpress.com Pixelshot Photoblog
http://brainable.blogspot.com Brainable Blog
--
View this message in context: http://www.nabble.com/EJB-3.1-PFD2-is-up-for-download-tp22462651p22470431.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.