JPA Deployment Architecture

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JPA Deployment Architecture

Jeff Genender
Hi,

I wanted to begin getting a little discussion on the JPA deployer as I
am beginning to work on this.  So I wanted to throw out some discussions
for architecture that may affect the entire OpenEJB as I would really
like that our deployers are consistent.  Forgive me in advance if I am
asking ignorant questions as I am spewing my thoughts...and they are not
always intelligent ;-)

1) What do we want our deployers to cough up - an object with
classloader representing the module with all of the necessary components
prepared?

2) I am assuming the JPA deployer will receive a "module" of some form
that represents either the module's file representation with that
classloader all ready pre-prepped, or will it be responsible for fully
creating this "module" object?  i.e., I would like to leverage code that
has already been developed to handle this w/o re-inventing the wheel.
Pointers to code would be great ;-)

3) We want the JPA deployer (as well as others) to be embeddable...so
that they can be used "out of container", such as directly in Unit
tests, or just about anywhere?

Thoughts, comments, ideas?

Jeff

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JPA Deployment Architecture

GDamour2
Hi,

I think that we have nothing to re-invent as SPI contracts have been
defined as part of the specs: David B. explains here how to integrate a
JPA provider within the container:
http://docs.codehaus.org/display/OPENEJB/JPA+Notes.

Thanks,
Gianny

Jeff Genender wrote:

>Hi,
>
>I wanted to begin getting a little discussion on the JPA deployer as I
>am beginning to work on this.  So I wanted to throw out some discussions
>for architecture that may affect the entire OpenEJB as I would really
>like that our deployers are consistent.  Forgive me in advance if I am
>asking ignorant questions as I am spewing my thoughts...and they are not
>always intelligent ;-)
>
>1) What do we want our deployers to cough up - an object with
>classloader representing the module with all of the necessary components
>prepared?
>
>2) I am assuming the JPA deployer will receive a "module" of some form
>that represents either the module's file representation with that
>classloader all ready pre-prepped, or will it be responsible for fully
>creating this "module" object?  i.e., I would like to leverage code that
>has already been developed to handle this w/o re-inventing the wheel.
>Pointers to code would be great ;-)
>
>3) We want the JPA deployer (as well as others) to be embeddable...so
>that they can be used "out of container", such as directly in Unit
>tests, or just about anywhere?
>
>Thoughts, comments, ideas?
>
>Jeff
>
>
>
>  
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JPA Deployment Architecture

Jeff Genender
Right...but I was talking way beyond the specs.  We will implement the
specs, but upon reading them, I saw nothing about the deployer, etc.  I
am talking more about the big picture of what we want to offer from our
deployment other than what the specs delivers.  This encompasses issues
such as classloaders (i.e. who gets what), encapsulation of delivered
objects, etc.  If this was purely an appserver deployment, then I could
easily leverage the Geronimo objects and classloaders, etc, but I am
assuming we want to be able to be a drop in for anywhere, so I want to
think beyond just an app server.

Jeff

Gianny Damour wrote:

> Hi,
>
> I think that we have nothing to re-invent as SPI contracts have been
> defined as part of the specs: David B. explains here how to integrate a
> JPA provider within the container:
> http://docs.codehaus.org/display/OPENEJB/JPA+Notes.
>
> Thanks,
> Gianny
>
> Jeff Genender wrote:
>
>> Hi,
>>
>> I wanted to begin getting a little discussion on the JPA deployer as I
>> am beginning to work on this.  So I wanted to throw out some discussions
>> for architecture that may affect the entire OpenEJB as I would really
>> like that our deployers are consistent.  Forgive me in advance if I am
>> asking ignorant questions as I am spewing my thoughts...and they are not
>> always intelligent ;-)
>>
>> 1) What do we want our deployers to cough up - an object with
>> classloader representing the module with all of the necessary components
>> prepared?
>>
>> 2) I am assuming the JPA deployer will receive a "module" of some form
>> that represents either the module's file representation with that
>> classloader all ready pre-prepped, or will it be responsible for fully
>> creating this "module" object?  i.e., I would like to leverage code that
>> has already been developed to handle this w/o re-inventing the wheel.
>> Pointers to code would be great ;-)
>>
>> 3) We want the JPA deployer (as well as others) to be embeddable...so
>> that they can be used "out of container", such as directly in Unit
>> tests, or just about anywhere?
>>
>> Thoughts, comments, ideas?
>>
>> Jeff
>>
>>
>>
>>  
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JPA Deployment Architecture

dblevins
Administrator
In reply to this post by Jeff Genender
On Feb 18, 2006, at 11:35 AM, Jeff Genender wrote:

> Hi,
>
> I wanted to begin getting a little discussion on the JPA deployer as I
> am beginning to work on this.  So I wanted to throw out some  
> discussions
> for architecture that may affect the entire OpenEJB as I would really
> like that our deployers are consistent.  Forgive me in advance if I am
> asking ignorant questions as I am spewing my thoughts...and they  
> are not
> always intelligent ;-)

Yea, i have the same questions in my head.  Generally "what is  
deployment going to look like?"  Not too many concrete answers yet,  
just a vague image with lots of holes in it still.  This will be a  
moving target for a bit longer.

Regardless, supporting an Application-managed entity manager doesn't  
require any fancy container work as it's supportable in a Java SE  
environment.  Since OpenJPA is going to be available soon, we might  
want to think about adding Application-managed entity manager support  
in Geronimo now so servlets or ejbs could look them up from JNDI.

For those reading; application-managed entity manager support is  
litterally just about making the provider's EntityManagerFactory  
available to the application in JNDI as-is and with no special JTA  
hookups, connection tracking, or anything.

What do you think about that?  If you like it, let's propose it on  
[hidden email]

-David


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JPA Deployment Architecture

dblevins
Administrator
In reply to this post by Jeff Genender
[posted this in the beginning of the day, didn't seem to arrive.  
reposting]

On Feb 18, 2006, at 11:35 AM, Jeff Genender wrote:

> Hi,
>
> I wanted to begin getting a little discussion on the JPA deployer as I
> am beginning to work on this.  So I wanted to throw out some  
> discussions
> for architecture that may affect the entire OpenEJB as I would really
> like that our deployers are consistent.  Forgive me in advance if I am
> asking ignorant questions as I am spewing my thoughts...and they  
> are not
> always intelligent ;-)
>

Yea, i have the same questions in my head.  Generally "what is  
deployment going to look like?"  Not too many concrete answers yet,  
just a vague image with lots of holes in it still.  This will be a  
moving target for a bit longer.

Regardless, supporting an Application-managed entity manager doesn't  
require any fancy container work as it's supportable in a Java SE  
environment.  Since OpenJPA is going to be available soon, we might  
want to think about adding Application-managed entity manager support  
in Geronimo now so servlets or ejbs could look them up from JNDI.

For those reading; application-managed entity manager support is  
litterally just about making the provider's EntityManagerFactory  
available to the application in JNDI as-is and with no special JTA  
hookups, connection tracking, or anything.

What do you think about that?  If you like it, let's propose it on  
[hidden email]

-David

Loading...