You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Mark Struberg <st...@yahoo.de> on 2012/05/04 21:56:34 UTC
[DISCUSS] deltaspike-jpa module features
Hi!
It's time to start the discussion about our deltaspike-jpa module I think ;)
a.) where
I suggest that we create a ee-modules project with submodules jsf, jpa, etc
b.) what
*) @Transactional
*) TransactionalInterceptor with SimplePersistenceStrategy, JtaPersistenceStrategy
*) ConfigurableDataSource, evaluate if we can make use of a special PersistenceUnitInfo for JPA2 providers, but would that work in EE containers as well?
Because I often get asked if we can add this: I think we do _not_ need to cover the (imo) broken Exception handling stuff which spring introduced in their transaction interceptor. An Exception is an Exception is an Exception! Logical return values and Business results must get propagated via standard java return values or content holder objects.
Oki the details:
1.) @Transational
I suggest that we temporarily implement the javax.transaction.* stuff of the _new_ Transaction Specification in DeltaSpike. We can take parts from OpenEJB, some JBoss api stuff (as far as covered by the grants) and various geronimo spec jars [1]
Once the spec is finished, we will move all the transaction-api.jar stuff over to geronimo-specs [1]. Since this all is ALv2 it will be no problem for JBoss folks to also just take the code and provide it in the JBossAS project once we are finished.
2.) I like the way we implemented the TransactionalInterceptor in CODI [2]. Our interceptor basically does exactly ... *nothing* ;)
All the work is done via an @Dependent PersistenceStrategy which gets injected into the interceptor. @Dependent because then we don't get any interceptor and it's really fast.
The BIG benefit of this little trick is that we are able to provide and use DIFFERENT PersistenceStrategies! A user can use @Alternative, @Specializes etc to define which PersistenceStrategy he likes to use in his project.
By default I'd like to provide the following PersistenceStrategies:
* SimplePersistenceStrategy: does just flush on all involved EntityManagers and afterwards a commit. Not JTA transaction save, but good enough for most use cases
* JtaPersistenceStrategy: uses a JTA bound @UserTransaction to control the EntitaManagers. This needs some exploration how we can do it. David Blevins and Arne Limburg are pretty good into this stuff. I'm dreaming of kind of the features of EJB standard transations, but NOT just for an EJB invocation, but @RequestScoped! The first invocation starts the UserTransaction, the @Disposes closes it. Just an idea ...
3.) ConfigurableDataSource
You all know the dilemma: you cannot make a JNDI configuration in a way that this stuff works with multiple EE servers since the locations where you have your DataSource configured will pop up under different locations in JNDI (based on which EE server/version you take). Otoh I don't like to hardcode my credentials to the persistence.xml neither.
Thus we came up with the ConfigurableDataSource [3]which just moves this information to a CDI bean where you can use @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even programmatic lookup!. I call this 'typesafe configuration'...
Oki, any other ideas?
LieGrue,
strub
[1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
[2] https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
[3] https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
Re: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Here the jndi name should be respected.
So lookup on the name you provided.
Le 5 mai 2012 12:17, "Mark Struberg" <st...@yahoo.de> a écrit :
> Hi Romain!
>
> You mean
>
>
> http://docs.oracle.com/javaee/6/api/javax/annotation/sql/DataSourceDefinition.html
>
> https://blogs.oracle.com/Lance/entry/introducing_the_datasourcedefinition_annotation
> ?
>
> I'm still not sure how this works in practice (despite the fact that e.g.
> tomcat doesn't support it).
> This takes the configuration info from the annotation and binds it to the
> given name= ... JNDI location, right?
> That would be ok for the part where the app contains the credentials and
> stuff.
>
> Let's play some mind-games with a standard project.
> My App has 4 different ProjectStage configurations:
> * local development/unit testing
> * CI integration testing
> * user test staging area
> * production system
> (in our project we have even 2 more)
>
> Each of them can be used with the following databases:
> * MySQL (the default we use for local development)
> * Oracle (the default we use in production and staging)
> * PostgreSQL (the future default for our production and staging
> environments)
>
> That means we have quite a lot different db configurations. But that's how
> it often is in big real world projects...
>
> For simplicity we have default credentials (username/pwd) in our app
> (using CODI @ProjectStageActivated) for all the systems and configs except
> staging and production. For those we rely on JNDI. But depending on the
> server we deploy the app on (JBoss, Glassfish, WebSphere, TomEE, etc) the
> JNDI location for a container-configured DataSource changes heavily. Thus
> even in those cases we need to change the configuration: we need to adopt
> the JNDI location where the DataSource can be picked up. That's really a
> big mess in EE!
>
> How would such a scenario work using the @DataSourceConfig?
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > Cc:
> > Sent: Saturday, May 5, 2012 12:55 AM
> > Subject: Re: [DISCUSS] deltaspike-jpa module features
> >
> > Hi,
> >
> > isn't the ConfigurableDataSource in JEE6? (datasourceconfiguration by
> > annotation or in the web.xml)?
> >
> > a really really big +1 for a pagination solution (typically a hades light
> > is a must have!)
> >
> > - Romain
> >
> >
> > 2012/5/4 Gerhard Petracek <ge...@gmail.com>
> >
> >> hi @ all,
> >>
> >> @ a)
> >> +1
> >>
> >> @ b)
> >> +1 for the basic concepts, however, @Transactional and
> @TransactionScoped
> >> need to be refactored (i'm currently working on it).
> >>
> >> furthermore, we should discuss a thin query layer which supports e.g.
> >> pagination,... easily (we also need it for a security-jpa module).
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2012/5/4 Mark Struberg <st...@yahoo.de>
> >>
> >> > Hi!
> >> >
> >> > It's time to start the discussion about our deltaspike-jpa module
> > I think
> >> > ;)
> >> >
> >> > a.) where
> >> > I suggest that we create a ee-modules project with submodules jsf,
> > jpa,
> >> > etc
> >> >
> >> > b.) what
> >> > *) @Transactional
> >> > *) TransactionalInterceptor with SimplePersistenceStrategy,
> >> > JtaPersistenceStrategy
> >> > *) ConfigurableDataSource, evaluate if we can make use of a special
> >> > PersistenceUnitInfo for JPA2 providers, but would that work in EE
> >> > containers as well?
> >> >
> >> > Because I often get asked if we can add this: I think we do _not_
> need
> > to
> >> > cover the (imo) broken Exception handling stuff which spring
> > introduced
> >> in
> >> > their transaction interceptor. An Exception is an Exception is an
> >> > Exception! Logical return values and Business results must get
> > propagated
> >> > via standard java return values or content holder objects.
> >> >
> >> > Oki the details:
> >> >
> >> > 1.) @Transational
> >> >
> >> > I suggest that we temporarily implement the javax.transaction.* stuff
> > of
> >> > the _new_ Transaction Specification in DeltaSpike. We can take parts
> > from
> >> > OpenEJB, some JBoss api stuff (as far as covered by the grants) and
> >> various
> >> > geronimo spec jars [1]
> >> > Once the spec is finished, we will move all the transaction-api.jar
> > stuff
> >> > over to geronimo-specs [1]. Since this all is ALv2 it will be no
> > problem
> >> > for JBoss folks to also just take the code and provide it in the
> > JBossAS
> >> > project once we are finished.
> >> >
> >> > 2.) I like the way we implemented the TransactionalInterceptor in
> CODI
> >> > [2]. Our interceptor basically does exactly ... *nothing* ;)
> >> > All the work is done via an @Dependent PersistenceStrategy which
> gets
> >> > injected into the interceptor. @Dependent because then we don't
> > get any
> >> > interceptor and it's really fast.
> >> > The BIG benefit of this little trick is that we are able to provide
> > and
> >> > use DIFFERENT PersistenceStrategies! A user can use @Alternative,
> >> > @Specializes etc to define which PersistenceStrategy he likes to use
> > in
> >> his
> >> > project.
> >> >
> >> > By default I'd like to provide the following
> > PersistenceStrategies:
> >> > * SimplePersistenceStrategy: does just flush on all involved
> >> > EntityManagers and afterwards a commit. Not JTA transaction save, but
> >> good
> >> > enough for most use cases
> >> > * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to
> > control
> >> > the EntitaManagers. This needs some exploration how we can do it.
> > David
> >> > Blevins and Arne Limburg are pretty good into this stuff. I'm
> > dreaming of
> >> > kind of the features of EJB standard transations, but NOT just for an
> > EJB
> >> > invocation, but @RequestScoped! The first invocation starts the
> >> > UserTransaction, the @Disposes closes it. Just an idea ...
> >> >
> >> >
> >> > 3.) ConfigurableDataSource
> >> > You all know the dilemma: you cannot make a JNDI configuration in a
> > way
> >> > that this stuff works with multiple EE servers since the locations
> > where
> >> > you have your DataSource configured will pop up under different
> > locations
> >> > in JNDI (based on which EE server/version you take). Otoh I don't
> > like to
> >> > hardcode my credentials to the persistence.xml neither.
> >> >
> >> > Thus we came up with the ConfigurableDataSource [3]which just moves
> > this
> >> > information to a CDI bean where you can use
> >> > @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even
> >> > programmatic lookup!. I call this 'typesafe configuration'...
> >> >
> >> >
> >> >
> >> > Oki, any other ideas?
> >> >
> >> > LieGrue,
> >> > strub
> >> >
> >> >
> >> > [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
> >> >
> >> > [2]
> >> >
> >>
> >
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
> >> >
> >> > [3]
> >> >
> >>
> >
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
> >> >
> >>
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
Hi Romain!
You mean
http://docs.oracle.com/javaee/6/api/javax/annotation/sql/DataSourceDefinition.html
https://blogs.oracle.com/Lance/entry/introducing_the_datasourcedefinition_annotation
?
I'm still not sure how this works in practice (despite the fact that e.g. tomcat doesn't support it).
This takes the configuration info from the annotation and binds it to the given name= ... JNDI location, right?
That would be ok for the part where the app contains the credentials and stuff.
Let's play some mind-games with a standard project.
My App has 4 different ProjectStage configurations:
* local development/unit testing
* CI integration testing
* user test staging area
* production system
(in our project we have even 2 more)
Each of them can be used with the following databases:
* MySQL (the default we use for local development)
* Oracle (the default we use in production and staging)
* PostgreSQL (the future default for our production and staging environments)
That means we have quite a lot different db configurations. But that's how it often is in big real world projects...
For simplicity we have default credentials (username/pwd) in our app (using CODI @ProjectStageActivated) for all the systems and configs except staging and production. For those we rely on JNDI. But depending on the server we deploy the app on (JBoss, Glassfish, WebSphere, TomEE, etc) the JNDI location for a container-configured DataSource changes heavily. Thus even in those cases we need to change the configuration: we need to adopt the JNDI location where the DataSource can be picked up. That's really a big mess in EE!
How would such a scenario work using the @DataSourceConfig?
LieGrue,
strub
----- Original Message -----
> From: Romain Manni-Bucau <rm...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Saturday, May 5, 2012 12:55 AM
> Subject: Re: [DISCUSS] deltaspike-jpa module features
>
> Hi,
>
> isn't the ConfigurableDataSource in JEE6? (datasourceconfiguration by
> annotation or in the web.xml)?
>
> a really really big +1 for a pagination solution (typically a hades light
> is a must have!)
>
> - Romain
>
>
> 2012/5/4 Gerhard Petracek <ge...@gmail.com>
>
>> hi @ all,
>>
>> @ a)
>> +1
>>
>> @ b)
>> +1 for the basic concepts, however, @Transactional and @TransactionScoped
>> need to be refactored (i'm currently working on it).
>>
>> furthermore, we should discuss a thin query layer which supports e.g.
>> pagination,... easily (we also need it for a security-jpa module).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2012/5/4 Mark Struberg <st...@yahoo.de>
>>
>> > Hi!
>> >
>> > It's time to start the discussion about our deltaspike-jpa module
> I think
>> > ;)
>> >
>> > a.) where
>> > I suggest that we create a ee-modules project with submodules jsf,
> jpa,
>> > etc
>> >
>> > b.) what
>> > *) @Transactional
>> > *) TransactionalInterceptor with SimplePersistenceStrategy,
>> > JtaPersistenceStrategy
>> > *) ConfigurableDataSource, evaluate if we can make use of a special
>> > PersistenceUnitInfo for JPA2 providers, but would that work in EE
>> > containers as well?
>> >
>> > Because I often get asked if we can add this: I think we do _not_ need
> to
>> > cover the (imo) broken Exception handling stuff which spring
> introduced
>> in
>> > their transaction interceptor. An Exception is an Exception is an
>> > Exception! Logical return values and Business results must get
> propagated
>> > via standard java return values or content holder objects.
>> >
>> > Oki the details:
>> >
>> > 1.) @Transational
>> >
>> > I suggest that we temporarily implement the javax.transaction.* stuff
> of
>> > the _new_ Transaction Specification in DeltaSpike. We can take parts
> from
>> > OpenEJB, some JBoss api stuff (as far as covered by the grants) and
>> various
>> > geronimo spec jars [1]
>> > Once the spec is finished, we will move all the transaction-api.jar
> stuff
>> > over to geronimo-specs [1]. Since this all is ALv2 it will be no
> problem
>> > for JBoss folks to also just take the code and provide it in the
> JBossAS
>> > project once we are finished.
>> >
>> > 2.) I like the way we implemented the TransactionalInterceptor in CODI
>> > [2]. Our interceptor basically does exactly ... *nothing* ;)
>> > All the work is done via an @Dependent PersistenceStrategy which gets
>> > injected into the interceptor. @Dependent because then we don't
> get any
>> > interceptor and it's really fast.
>> > The BIG benefit of this little trick is that we are able to provide
> and
>> > use DIFFERENT PersistenceStrategies! A user can use @Alternative,
>> > @Specializes etc to define which PersistenceStrategy he likes to use
> in
>> his
>> > project.
>> >
>> > By default I'd like to provide the following
> PersistenceStrategies:
>> > * SimplePersistenceStrategy: does just flush on all involved
>> > EntityManagers and afterwards a commit. Not JTA transaction save, but
>> good
>> > enough for most use cases
>> > * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to
> control
>> > the EntitaManagers. This needs some exploration how we can do it.
> David
>> > Blevins and Arne Limburg are pretty good into this stuff. I'm
> dreaming of
>> > kind of the features of EJB standard transations, but NOT just for an
> EJB
>> > invocation, but @RequestScoped! The first invocation starts the
>> > UserTransaction, the @Disposes closes it. Just an idea ...
>> >
>> >
>> > 3.) ConfigurableDataSource
>> > You all know the dilemma: you cannot make a JNDI configuration in a
> way
>> > that this stuff works with multiple EE servers since the locations
> where
>> > you have your DataSource configured will pop up under different
> locations
>> > in JNDI (based on which EE server/version you take). Otoh I don't
> like to
>> > hardcode my credentials to the persistence.xml neither.
>> >
>> > Thus we came up with the ConfigurableDataSource [3]which just moves
> this
>> > information to a CDI bean where you can use
>> > @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even
>> > programmatic lookup!. I call this 'typesafe configuration'...
>> >
>> >
>> >
>> > Oki, any other ideas?
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> > [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>> >
>> > [2]
>> >
>>
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
>> >
>> > [3]
>> >
>>
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
>> >
>>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Jason Porter <li...@gmail.com>.
Sent from my iPhone
On May 6, 2012, at 16:11, Mark Struberg <st...@yahoo.de> wrote:
> Hi David!
>
> Thanks for this valuable input!
>
> I guess I need to think about that and put it up in a sample app to test it's usability.
>
> I always need some piece of code to verify if it is _really_ working.
>
>
> Btw, are we still d'accord that we like to support EE5, EE6 and EE7 servers with our stuff?
> Maybe we could provide a 'legacy path' for EE5 and another one for EE6 and 7 servers?
That all depends on which features we have and how much we want to create other jars. I know EE5 is probably in more use than EE6 currently. That may be a good reason. We've also stated we're not supporting JDK5. We'll need more CI jobs, documented setup for adding CDI into an EE5 container. It's certainly possible. If we had more users I'd say let them vote, but we're not there yet.
> We should also make sure that this way does work _without_ any EE server as well - means with pure JPA. Because that is was is used in most unit tests.
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: David Blevins <da...@gmail.com>
>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@yahoo.de>
>> Cc:
>> Sent: Sunday, May 6, 2012 10:47 PM
>> Subject: Re: [DISCUSS] deltaspike-jpa module features
>>
>>
>> On May 6, 2012, at 1:32 PM, David Blevins wrote:
>>
>>> I recall your app and I'd guess the heart of your distaste is that you
>> essentially configure two datasources and then pick one at runtime.
>>>
>>> In static code, this is possible (there is equivalent xml):
>>>
>>> @DataSourceDefinition(name = "java:app/test/ds" ....)
>>> @DataSourceDefinition(name = "java:app/prod/ds" ....)
>>> @Resource(name = "java:app/ds",
>> lookup="java:app/prod/ds")
>>> public class SomeCdiBean {
>>> }
>>>
>>> Two datasources are declared and one symlink that the application can use
>> safely. Clearly the above "symlink" is still hardcoded, so to get
>> some more dynamic behavior you could potentially put the "@Resource"
>> link on a separate class in a separate jar. Perhaps a "prod.jar" to
>> hold all the mappings for production and a "test.jar" to hold all the
>> mappings for test, then make sure only one of them is in the application at any
>> given time.
>>>
>>> Still limited of course as changing the archive is required and often that
>> isn't allowed between test and production.
>>
>> For the sake of completeness, I should also say that swapping the descriptors
>> out without modifying the archive is the reason for the alternate deployment
>> descriptor functionality (alt-dd) all full profile certified servers support.
>> So even that concept has been addressed at the spec level.
>>
>> One of the things not supported by plain Tomcat or Jetty, so also not commonly
>> known or used.
>>
>>
>> -David
>>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
Hi David!
Thanks for this valuable input!
I guess I need to think about that and put it up in a sample app to test it's usability.
I always need some piece of code to verify if it is _really_ working.
Btw, are we still d'accord that we like to support EE5, EE6 and EE7 servers with our stuff?
Maybe we could provide a 'legacy path' for EE5 and another one for EE6 and 7 servers?
We should also make sure that this way does work _without_ any EE server as well - means with pure JPA. Because that is was is used in most unit tests.
LieGrue,
strub
----- Original Message -----
> From: David Blevins <da...@gmail.com>
> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Sunday, May 6, 2012 10:47 PM
> Subject: Re: [DISCUSS] deltaspike-jpa module features
>
>
> On May 6, 2012, at 1:32 PM, David Blevins wrote:
>
>> I recall your app and I'd guess the heart of your distaste is that you
> essentially configure two datasources and then pick one at runtime.
>>
>> In static code, this is possible (there is equivalent xml):
>>
>> @DataSourceDefinition(name = "java:app/test/ds" ....)
>> @DataSourceDefinition(name = "java:app/prod/ds" ....)
>> @Resource(name = "java:app/ds",
> lookup="java:app/prod/ds")
>> public class SomeCdiBean {
>> }
>>
>> Two datasources are declared and one symlink that the application can use
> safely. Clearly the above "symlink" is still hardcoded, so to get
> some more dynamic behavior you could potentially put the "@Resource"
> link on a separate class in a separate jar. Perhaps a "prod.jar" to
> hold all the mappings for production and a "test.jar" to hold all the
> mappings for test, then make sure only one of them is in the application at any
> given time.
>>
>> Still limited of course as changing the archive is required and often that
> isn't allowed between test and production.
>
> For the sake of completeness, I should also say that swapping the descriptors
> out without modifying the archive is the reason for the alternate deployment
> descriptor functionality (alt-dd) all full profile certified servers support.
> So even that concept has been addressed at the spec level.
>
> One of the things not supported by plain Tomcat or Jetty, so also not commonly
> known or used.
>
>
> -David
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by David Blevins <da...@gmail.com>.
On May 6, 2012, at 1:32 PM, David Blevins wrote:
> I recall your app and I'd guess the heart of your distaste is that you essentially configure two datasources and then pick one at runtime.
>
> In static code, this is possible (there is equivalent xml):
>
> @DataSourceDefinition(name = "java:app/test/ds" ....)
> @DataSourceDefinition(name = "java:app/prod/ds" ....)
> @Resource(name = "java:app/ds", lookup="java:app/prod/ds")
> public class SomeCdiBean {
> }
>
> Two datasources are declared and one symlink that the application can use safely. Clearly the above "symlink" is still hardcoded, so to get some more dynamic behavior you could potentially put the "@Resource" link on a separate class in a separate jar. Perhaps a "prod.jar" to hold all the mappings for production and a "test.jar" to hold all the mappings for test, then make sure only one of them is in the application at any given time.
>
> Still limited of course as changing the archive is required and often that isn't allowed between test and production.
For the sake of completeness, I should also say that swapping the descriptors out without modifying the archive is the reason for the alternate deployment descriptor functionality (alt-dd) all full profile certified servers support. So even that concept has been addressed at the spec level.
One of the things not supported by plain Tomcat or Jetty, so also not commonly known or used.
-David
Re: [DISCUSS] deltaspike-jpa module features
Posted by David Blevins <da...@gmail.com>.
On May 6, 2012, at 4:48 AM, Mark Struberg wrote:
>
>
> David, exactly this doesn't work out in practice!
>
> look at jboss5 datasource xml as an example:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
> <local-tx-datasource>
> <jndi-name>myDS</jndi-name>
> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-url>
> <user-name>user</user-name>
> <password>pwd</password>
> <driver-class>org.postgresql.Driver</driver-class>
> </local-tx-datasource>
> </datasources>
>
> This will create the following JNDI location in JBossAS5: java:/myDS
>
> NO comp, NO lang, NO other qualifier.
That's because you didn't declare the reference using the portable mechanisms I described: via @Resource annotation on a field, method or class of a component, or <resource-ref> in the web.xml.
Step 1 is to chose a name and declare it via standard means and use only that name in your app.
Step 2 is to use the vendor specific means to link that name to the target environment.
Doing it any other way is every bit as non-portable as you say.
Yes, Step 2 is vendor specific, you really can't avoid that (well actually you can, more on that later), but what it does is get the vendor specific out of your code. It's pretty easy to put mapping files for several vendors in their app.
For OpenEJB/TomEE there usually is no Step 2 required and just declaring the reference and creating a datasource is enough.
As of JavaEE 6 you can skip Step 2 portably via declaring the datasource via the new @DataSourceDefinition.
I recall your app and I'd guess the heart of your distaste is that you essentially configure two datasources and then pick one at runtime.
In static code, this is possible (there is equivalent xml):
@DataSourceDefinition(name = "java:app/test/ds" ....)
@DataSourceDefinition(name = "java:app/prod/ds" ....)
@Resource(name = "java:app/ds", lookup="java:app/prod/ds")
public class SomeCdiBean {
}
Two datasources are declared and one symlink that the application can use safely. Clearly the above "symlink" is still hardcoded, so to get some more dynamic behavior you could potentially put the "@Resource" link on a separate class in a separate jar. Perhaps a "prod.jar" to hold all the mappings for production and a "test.jar" to hold all the mappings for test, then make sure only one of them is in the application at any given time.
Still limited of course as changing the archive is required and often that isn't allowed between test and production.
There are several ways CDI could help with this that haven't been directly addressed and are not tested, so not likely to work now, but definitely something we should address. The ideas are too cool to ignore.
Q1. Alternatives and JavaEE Resource annotations. What happens if a CDI bean is annotated with "@Resource(name = "java:app/ds", lookup="java:app/prod/ds")", but has an alternate annotated with "@Resource(name = "java:app/ds", lookup="java:app/test/ds")?
One would hope that either the main bean's JNDI entries *or* the alternate bean's JNDI entries will go into effect, not both. This isn't explicitly covered so I doubt will work. Something we might want to add at the spec level.
Q2. Extensions adding/removing beans. What happens if a CDI bean is annotated with "@Resource(name = "java:app/ds", lookup="java:app/prod/ds")" and is vetoed by an Extension?
One would hope that the JNDI entries that would be added by the vetoed bean are also essentially vetoed and the bean does not have an impact on the JNDI namespace. Also not explicitly addressed and something we might want to tackle at the spec level.
-David
Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Couldnt this debate wait spec feedbacks?
a lot of other JPA stuff is doable before i think
- Romain
2012/5/7 Mark Struberg <st...@yahoo.de>
> > But, I am afraid that this is underspecified...
> good guess, same here ;)
>
> Since this stuff is NOT covered by the CDI spec, I expect that not CDI but
> the EE container scans those annotations. And another guess: it will give a
> damn about enabled or disabled beans ...
>
> We are in a very grey area I assume.
>
> LieGrue,
> strub
>
>
> ----- Original Message -----
> > From: Arne Limburg <ar...@openknowledge.de>
> > To: "deltaspike-dev@incubator.apache.org" <
> deltaspike-dev@incubator.apache.org>
> > Cc:
> > Sent: Sunday, May 6, 2012 3:48 PM
> > Subject: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
> >
> > If so, what would be the semantic of such definition?
> > Btw. that classes would only become CDI beans when the deployment is in
> the
> > correct project stage. Otherwise we would veto them away, before they
> become
> > beans...
> > And, which part of the jee container would scan that class? My guess is,
> that it
> > would be the responsibility of the CDI implementation. And - just a
> second guess
> > - they ignore it...
> >
> > I'll take a look into the JPA spec to see what the official semantic of
> the
> > usage I proposed would be. But, I am afraid that this is
> underspecified...
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 15:40
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
> >
> > Cdi is in jee so jee containers scans cdi beans and same for resources
> > (@persistencontext).
> > Le 6 mai 2012 15:36, "Arne Limburg"
> > <ar...@openknowledge.de> a écrit :
> >
> >> If not, we can use other annotations, but I think jee containers just
> >> scan EJBs...
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> >> Gesendet: Sonntag, 6. Mai 2012 15:28
> >> An: deltaspike-dev@incubator.apache.org
> >> Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
> >>
> >> Not sure it works in a jee container.
> >>
> >> - Romain
> >> Le 6 mai 2012 15:26, "Arne Limburg"
> > <ar...@openknowledge.de> a
> >> écrit :
> >>
> >> > You could configure your production jta-datasource in the
> >> > persistence.xml and add the following bean to your test deployment:
> >> >
> >> > @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> >> > @PersistenceContext(unitName = "myPU", properties =
> >> > @PersistenceProperty(name =
> > "javax.persistence.nonJtaDataSource",
> >> > value =
> >> > "java:/comp/env/myDS"))
> >> > public class MyIntegrationTestConfiguration { }
> >> >
> >> > For local testing, you could even switch off JNDI:
> >> > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> >> > @PersistenceContext(unitName = "myPU", properties =
> >> > {@PersistenceProperty(name =
> > "javax.persistence.transactionType",
> >> > value = "RESOURCE_LOCAL"),
> >> >
> >> > @PersistenceProperty(name =
> >> > "javax.persistence.jdbc.url", value =
> > "jdbc:h2:mem:myDB"), ...})
> >> > public class MyDevelopmentConfiguration { }
> >> >
> >> > WDYT?
> >> >
> >> > Romain,
> >> > Noone needs to repackage his application, since we can put this
> >> > properties into a map and use it as the second parameter of
> >> emf.createEntityManager...
> >> >
> >> > - Arne
> >> >
> >> > -----Ursprüngliche Nachricht-----
> >> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> >> > Gesendet: Sonntag, 6. Mai 2012 15:14
> >> > An: deltaspike-dev@incubator.apache.org
> >> > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> >> >
> >> > How do you manage it from persistence.xml if you dont repackage your
> >> > archive as Mark said?
> >> >
> >> > Personally i agree ;)
> >> >
> >> > - Romain
> >> > Le 6 mai 2012 15:06, "Arne Limburg"
> > <ar...@openknowledge.de>
> >> > a écrit :
> >> >
> >> > > OK,
> >> > > but do we really need a container-independent way for
> > JNDI-DataSources?
> >> > > What's the use case for it?
> >> > > The user always knows his container and thus his specific
> > JNDI-name.
> >> > >
> >> > > I think we need an easy way for users to configure different
> >> > > JNDI-DataSources for different deployment scenarios, like
> >> > > - a JTA-datasource for my JBoss AS 7 in production
> >> > > - a Non-JTA-datasource from another JNDI-location for the Tomcat
> >> > > for testing
> >> > > - a RESOURCE_LOCAL EntityManager for local testing...
> >> > >
> >> > > We need to find an easy way for the users to configure the
> >> > > JNDI-location, but imho we don't need to handle different
> >> > > JNDI-locations
> >> > in our code?
> >> > >
> >> > > WDYT? Am I missing a use case?
> >> > >
> >> > > Cheers,
> >> > > Arne
> >> > >
> >> > > -----Ursprüngliche Nachricht-----
> >> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> >> > > Gesendet: Sonntag, 6. Mai 2012 14:49
> >> > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> >> > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> >> > >
> >> > > ConfigurableDataSource doesnt solve it. If you build the emf from
> >
> >> > > persistence info you manage it yourself. It should be IMO a
> >> > > compatibility mode and spec you be fixed.
> >> > >
> >> > > But well, the most important subjects are not here, pagination,
> >> > > dynamic dao etc are really more valuable.
> >> > >
> >> > > - Romain
> >> > > Le 6 mai 2012 14:44, "Mark Struberg"
> > <st...@yahoo.de> a écrit :
> >> > >
> >> > > >
> >> > > >
> >> > > > The problem here is that this is NOT under our control -
> > this is
> >> > > > not even CDI related!
> >> > > >
> >> > > > You need to _exactly_ specify the JNDI location in your
> >> > persistence.xml.
> >> > > > And this info get's parsed by JPA or the EE container at
> > deploy time.
> >> > > >
> >> > > >
> >> > > > Maybe there's a trick with a PersistenceUnitInfo. But
> > since
> >> > > > those are also managed by the server (and thus show the same
> >
> >> > > > unspecified
> >> > > > behaviour) we imo cannot leverage those.
> >> > > >
> >> > > > LieGrue,
> >> > > > strub
> >> > > >
> >> > > >
> >> > > > >________________________________
> >> > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> >> > > > >To: Mark Struberg <st...@yahoo.de>;
> >> > > > deltaspike-dev@incubator.apache.org
> >> > > > >Sent: Sunday, May 6, 2012 2:37 PM
> >> > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> >> > > > >
> >> > > > >
> >> > > > >I understand. On another side how many differeny
> > locations are
> >> there?
> >> > > > Isnt it manageable?
> >> > > > >- Romain
> >> > > > >Le 6 mai 2012 14:29, "Mark Struberg"
> > <st...@yahoo.de> a écrit :
> >> > > > >
> >> > > > >
> >> > > > >>
> >> > > > >>PS: I _fully_ agree that this mess should best get
> > fixed in EE7.
> >> > > > >>But
> >> > > > sadly we also need to support older containers!
> >> > > > >>
> >> > > > >>I know about folks who have OWB and CODI running on
> > old
> >> > > > >>WebSphere
> >> > > > >>6 and
> >> > > > 7 servers. And others who use OWB on WebLogic 10.3. And
> > those
> >> > > > companies are big banks, stock exchanges and insurrance
> >> > > > companies
> >> > > > - they cannot easily upgrade to a new server...
> >> > > > >>
> >> > > > >>LieGrue,
> >> > > > >>strub
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> > > > >>>________________________________
> >> > > > >>> From: Mark Struberg <st...@yahoo.de>
> >> > > > >>>To: Romain Manni-Bucau
> > <rm...@gmail.com>; deltaspike <
> >> > > > deltaspike-dev@incubator.apache.org>
> >> > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> >> > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module
> > features
> >> > > > >>>
> >> > > > >>>
> >> > > > >>>
> >> > > > >>>No, the container is NOT buggy, because it's
> > simply NOT defined!
> >> > > > >>>That's the whole mess about JNDI...
> >> > > > >>>
> >> > > > >>>LieGrue,
> >> > > > >>>strub
> >> > > > >>>
> >> > > > >>>
> >> > > > >>>
> >> > > > >>>
> >> > > > >>>>________________________________
> >> > > > >>>> From: Romain Manni-Bucau
> > <rm...@gmail.com>
> >> > > > >>>>To: Mark Struberg <st...@yahoo.de>
> >> > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> >> > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module
> > features
> >> > > > >>>>
> >> > > > >>>>
> >> > > > >>>>So this container is buggy, report an issue
> > ;) Thinking of
> >> > > > >>>>it this jndi path issue couldnt be resolved
> > by
> >> > > > configresolvers in ds?
> >> > > > >>>>- Romain
> >> > > > >>>>Le 6 mai 2012 13:58, "Mark
> > Struberg" <st...@yahoo.de> a
> >> écrit :
> >> > > > >>>>
> >> > > > >>>>yes, that crashes the container...
> >> > > > >>>>>
> >> > > > >>>>>
> >> > > > >>>>>
> >> > > > >>>>>
> >> > > > >>>>>
> >> > > > >>>>>>________________________________
> >> > > > >>>>>> From: Romain Manni-Bucau
> > <rm...@gmail.com>
> >> > > > >>>>>>To: Mark Struberg
> > <st...@yahoo.de>;
> >> > > > deltaspike-dev@incubator.apache.org
> >> > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> >> > > > >>>>>>Subject: Re: [DISCUSS]
> > deltaspike-jpa module features
> >> > > > >>>>>>
> >> > > > >>>>>>
> >> > > > >>>>>>Mark, did you try providing a name
> > starting with java:?
> >> > > > >>>>>>- Romain
> >> > > > >>>>>>Le 6 mai 2012 13:49, "Mark
> > Struberg" <st...@yahoo.de> a
> >> > écrit :
> >> > > > >>>>>>
> >> > > > >>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>David, exactly this doesn't
> > work out in practice!
> >> > > > >>>>>>>
> >> > > > >>>>>>>look at jboss5 datasource xml as
> > an example:
> >> > > > >>>>>>>
> >> > > > >>>>>>><?xml version="1.0"
> > encoding="UTF-8"?> <datasources>
> >> > > > >>>>>>>
> > <local-tx-datasource>
> >> > > > >>>>>>>
> > <jndi-name>myDS</jndi-name>
> >> > > > >>>>>>>
> >> > > >
> > <connection-url>jdbc:postgresql://someserver:5432/someDb</connec
> >> > > > ti
> >> > > > on
> >> > > > -u
> >> > > > rl>
> >> > > > >>>>>>>
> > <user-name>user</user-name>
> >> > > > >>>>>>>
> > <password>pwd</password>
> >> > > > >>>>>>>
> >> > > >
> > <driver-class>org.postgresql.Driver</driver-class>
> >> > > > >>>>>>>
> > </local-tx-datasource> </datasources>
> >> > > > >>>>>>>
> >> > > > >>>>>>>This will create the following
> > JNDI location in JBossAS5:
> >> > > > >>>>>>>java:/myDS
> >> > > > >>>>>>>
> >> > > > >>>>>>>NO comp, NO lang, NO other
> > qualifier.
> >> > > > >>>>>>>
> >> > > > >>>>>>>Configuring the same in Geronimo
> > gives you
> >> > > > >>>>>>>java:/comp/env/myDS and it's
> > again COMPLETEY different in
> >> > > > >>>>>>>JBossAS6, AS7, Glassfish,
> >> > > > TomEE, etc
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>Thus: which JNDI location would
> > you configure in your
> >> > > > persistence.xml?
> >> > > > >>>>>>>
> >> > > > >>>>>>>That's the reason why we
> > came up with the
> >> > ConfigurableDataSource.
> >> > > > >>>>>>>
> >> > > > >>>>>>>Of course, we need to extend
> > this concept and create a
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>public interface
> > ConfigurableXaDataSource extends
> >> > > > ConfigurableDataSource, XaDataSource {}
> >> > > > >>>>>>>
> >> > > > >>>>>>>See what I mean?
> >> > > > >>>>>>>
> >> > > > >>>>>>>LieGrue,
> >> > > > >>>>>>>strub
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>>----- Original Message -----
> >> > > > >>>>>>>> From: David Blevins
> > <da...@gmail.com>
> >> > > > >>>>>>>> To:
> > deltaspike-dev@incubator.apache.org; Mark Struberg
> >> > > > >>>>>>>> <
> >> > > > struberg@yahoo.de>
> >> > > > >>>>>>>> Cc:
> >> > > > >>>>>>>> Sent: Sunday, May 6, 2012
> > 1:25 PM
> >> > > > >>>>>>>> Subject: Re: [DISCUSS]
> > deltaspike-jpa module features
> >> > > > >>>>>>>>
> >> > > > >>>>>>>>
> >> > > > >>>>>>>> On May 6, 2012, at 2:37 AM,
> > Mark Struberg wrote:
> >> > > > >>>>>>>>
> >> > > > >>>>>>>>>> In plain Tomcat or
> >> > > > >>>>>>>>>> Jetty servers this
> > needs to be configured in a
> >> > > > container-specific way.
> >> > > > >>>>>>>>> The problem with the
> > container specific stuff is that
> >> > > > >>>>>>>>> every
> >> > > > container
> >> > > > >>>>>>>> serves the xml configured
> > datasource on a different
> >> > > > >>>>>>>> location in
> >> > > > JNDI! So you
> >> > > > >>>>>>>> cannot provide a container
> > independent implementation
> >> > > > >>>>>>>> that way :/
> >> > > > >>>>>>>>
> >> > > > >>>>>>>> The portable way would be
> > to declare your datasource
> >> > > > >>>>>>>> properly via
> > @Resource(name="java:app/Foo",
> >> > > > >>>>>>>> type=DataSource.class) or
> > via <resource-ref> xml.
> >> > > > >>>>>>>>
> >> > > > >>>>>>>> Most servers can map those
> > references with little to no
> >> > config.
> >> > > > >>>>>>>>
> >> > > > >>>>>>>>
> >> > > > >>>>>>>> -David
> >> > > > >>>>>>>>
> >> > > > >>>>>>>
> >> > > > >>>>>>
> >> > > > >>>>>>
> >> > > > >>>>
> >> > > > >>>>
> >> > > > >>>
> >> > > > >>>
> >> > > > >>>
> >> > > > >>
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
> But, I am afraid that this is underspecified...
good guess, same here ;)
Since this stuff is NOT covered by the CDI spec, I expect that not CDI but the EE container scans those annotations. And another guess: it will give a damn about enabled or disabled beans ...
We are in a very grey area I assume.
LieGrue,
strub
----- Original Message -----
> From: Arne Limburg <ar...@openknowledge.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> Cc:
> Sent: Sunday, May 6, 2012 3:48 PM
> Subject: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> If so, what would be the semantic of such definition?
> Btw. that classes would only become CDI beans when the deployment is in the
> correct project stage. Otherwise we would veto them away, before they become
> beans...
> And, which part of the jee container would scan that class? My guess is, that it
> would be the responsibility of the CDI implementation. And - just a second guess
> - they ignore it...
>
> I'll take a look into the JPA spec to see what the official semantic of the
> usage I proposed would be. But, I am afraid that this is underspecified...
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 15:40
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> Cdi is in jee so jee containers scans cdi beans and same for resources
> (@persistencontext).
> Le 6 mai 2012 15:36, "Arne Limburg"
> <ar...@openknowledge.de> a écrit :
>
>> If not, we can use other annotations, but I think jee containers just
>> scan EJBs...
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> Gesendet: Sonntag, 6. Mai 2012 15:28
>> An: deltaspike-dev@incubator.apache.org
>> Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
>>
>> Not sure it works in a jee container.
>>
>> - Romain
>> Le 6 mai 2012 15:26, "Arne Limburg"
> <ar...@openknowledge.de> a
>> écrit :
>>
>> > You could configure your production jta-datasource in the
>> > persistence.xml and add the following bean to your test deployment:
>> >
>> > @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
>> > @PersistenceContext(unitName = "myPU", properties =
>> > @PersistenceProperty(name =
> "javax.persistence.nonJtaDataSource",
>> > value =
>> > "java:/comp/env/myDS"))
>> > public class MyIntegrationTestConfiguration { }
>> >
>> > For local testing, you could even switch off JNDI:
>> > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
>> > @PersistenceContext(unitName = "myPU", properties =
>> > {@PersistenceProperty(name =
> "javax.persistence.transactionType",
>> > value = "RESOURCE_LOCAL"),
>> >
>> > @PersistenceProperty(name =
>> > "javax.persistence.jdbc.url", value =
> "jdbc:h2:mem:myDB"), ...})
>> > public class MyDevelopmentConfiguration { }
>> >
>> > WDYT?
>> >
>> > Romain,
>> > Noone needs to repackage his application, since we can put this
>> > properties into a map and use it as the second parameter of
>> emf.createEntityManager...
>> >
>> > - Arne
>> >
>> > -----Ursprüngliche Nachricht-----
>> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > Gesendet: Sonntag, 6. Mai 2012 15:14
>> > An: deltaspike-dev@incubator.apache.org
>> > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
>> >
>> > How do you manage it from persistence.xml if you dont repackage your
>> > archive as Mark said?
>> >
>> > Personally i agree ;)
>> >
>> > - Romain
>> > Le 6 mai 2012 15:06, "Arne Limburg"
> <ar...@openknowledge.de>
>> > a écrit :
>> >
>> > > OK,
>> > > but do we really need a container-independent way for
> JNDI-DataSources?
>> > > What's the use case for it?
>> > > The user always knows his container and thus his specific
> JNDI-name.
>> > >
>> > > I think we need an easy way for users to configure different
>> > > JNDI-DataSources for different deployment scenarios, like
>> > > - a JTA-datasource for my JBoss AS 7 in production
>> > > - a Non-JTA-datasource from another JNDI-location for the Tomcat
>> > > for testing
>> > > - a RESOURCE_LOCAL EntityManager for local testing...
>> > >
>> > > We need to find an easy way for the users to configure the
>> > > JNDI-location, but imho we don't need to handle different
>> > > JNDI-locations
>> > in our code?
>> > >
>> > > WDYT? Am I missing a use case?
>> > >
>> > > Cheers,
>> > > Arne
>> > >
>> > > -----Ursprüngliche Nachricht-----
>> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > > Gesendet: Sonntag, 6. Mai 2012 14:49
>> > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
>> > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
>> > >
>> > > ConfigurableDataSource doesnt solve it. If you build the emf from
>
>> > > persistence info you manage it yourself. It should be IMO a
>> > > compatibility mode and spec you be fixed.
>> > >
>> > > But well, the most important subjects are not here, pagination,
>> > > dynamic dao etc are really more valuable.
>> > >
>> > > - Romain
>> > > Le 6 mai 2012 14:44, "Mark Struberg"
> <st...@yahoo.de> a écrit :
>> > >
>> > > >
>> > > >
>> > > > The problem here is that this is NOT under our control -
> this is
>> > > > not even CDI related!
>> > > >
>> > > > You need to _exactly_ specify the JNDI location in your
>> > persistence.xml.
>> > > > And this info get's parsed by JPA or the EE container at
> deploy time.
>> > > >
>> > > >
>> > > > Maybe there's a trick with a PersistenceUnitInfo. But
> since
>> > > > those are also managed by the server (and thus show the same
>
>> > > > unspecified
>> > > > behaviour) we imo cannot leverage those.
>> > > >
>> > > > LieGrue,
>> > > > strub
>> > > >
>> > > >
>> > > > >________________________________
>> > > > > From: Romain Manni-Bucau <rm...@gmail.com>
>> > > > >To: Mark Struberg <st...@yahoo.de>;
>> > > > deltaspike-dev@incubator.apache.org
>> > > > >Sent: Sunday, May 6, 2012 2:37 PM
>> > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
>> > > > >
>> > > > >
>> > > > >I understand. On another side how many differeny
> locations are
>> there?
>> > > > Isnt it manageable?
>> > > > >- Romain
>> > > > >Le 6 mai 2012 14:29, "Mark Struberg"
> <st...@yahoo.de> a écrit :
>> > > > >
>> > > > >
>> > > > >>
>> > > > >>PS: I _fully_ agree that this mess should best get
> fixed in EE7.
>> > > > >>But
>> > > > sadly we also need to support older containers!
>> > > > >>
>> > > > >>I know about folks who have OWB and CODI running on
> old
>> > > > >>WebSphere
>> > > > >>6 and
>> > > > 7 servers. And others who use OWB on WebLogic 10.3. And
> those
>> > > > companies are big banks, stock exchanges and insurrance
>> > > > companies
>> > > > - they cannot easily upgrade to a new server...
>> > > > >>
>> > > > >>LieGrue,
>> > > > >>strub
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >>>________________________________
>> > > > >>> From: Mark Struberg <st...@yahoo.de>
>> > > > >>>To: Romain Manni-Bucau
> <rm...@gmail.com>; deltaspike <
>> > > > deltaspike-dev@incubator.apache.org>
>> > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
>> > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module
> features
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>>No, the container is NOT buggy, because it's
> simply NOT defined!
>> > > > >>>That's the whole mess about JNDI...
>> > > > >>>
>> > > > >>>LieGrue,
>> > > > >>>strub
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>>>________________________________
>> > > > >>>> From: Romain Manni-Bucau
> <rm...@gmail.com>
>> > > > >>>>To: Mark Struberg <st...@yahoo.de>
>> > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
>> > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module
> features
>> > > > >>>>
>> > > > >>>>
>> > > > >>>>So this container is buggy, report an issue
> ;) Thinking of
>> > > > >>>>it this jndi path issue couldnt be resolved
> by
>> > > > configresolvers in ds?
>> > > > >>>>- Romain
>> > > > >>>>Le 6 mai 2012 13:58, "Mark
> Struberg" <st...@yahoo.de> a
>> écrit :
>> > > > >>>>
>> > > > >>>>yes, that crashes the container...
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>
>> > > > >>>>>>________________________________
>> > > > >>>>>> From: Romain Manni-Bucau
> <rm...@gmail.com>
>> > > > >>>>>>To: Mark Struberg
> <st...@yahoo.de>;
>> > > > deltaspike-dev@incubator.apache.org
>> > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
>> > > > >>>>>>Subject: Re: [DISCUSS]
> deltaspike-jpa module features
>> > > > >>>>>>
>> > > > >>>>>>
>> > > > >>>>>>Mark, did you try providing a name
> starting with java:?
>> > > > >>>>>>- Romain
>> > > > >>>>>>Le 6 mai 2012 13:49, "Mark
> Struberg" <st...@yahoo.de> a
>> > écrit :
>> > > > >>>>>>
>> > > > >>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>David, exactly this doesn't
> work out in practice!
>> > > > >>>>>>>
>> > > > >>>>>>>look at jboss5 datasource xml as
> an example:
>> > > > >>>>>>>
>> > > > >>>>>>><?xml version="1.0"
> encoding="UTF-8"?> <datasources>
>> > > > >>>>>>>
> <local-tx-datasource>
>> > > > >>>>>>>
> <jndi-name>myDS</jndi-name>
>> > > > >>>>>>>
>> > > >
> <connection-url>jdbc:postgresql://someserver:5432/someDb</connec
>> > > > ti
>> > > > on
>> > > > -u
>> > > > rl>
>> > > > >>>>>>>
> <user-name>user</user-name>
>> > > > >>>>>>>
> <password>pwd</password>
>> > > > >>>>>>>
>> > > >
> <driver-class>org.postgresql.Driver</driver-class>
>> > > > >>>>>>>
> </local-tx-datasource> </datasources>
>> > > > >>>>>>>
>> > > > >>>>>>>This will create the following
> JNDI location in JBossAS5:
>> > > > >>>>>>>java:/myDS
>> > > > >>>>>>>
>> > > > >>>>>>>NO comp, NO lang, NO other
> qualifier.
>> > > > >>>>>>>
>> > > > >>>>>>>Configuring the same in Geronimo
> gives you
>> > > > >>>>>>>java:/comp/env/myDS and it's
> again COMPLETEY different in
>> > > > >>>>>>>JBossAS6, AS7, Glassfish,
>> > > > TomEE, etc
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>Thus: which JNDI location would
> you configure in your
>> > > > persistence.xml?
>> > > > >>>>>>>
>> > > > >>>>>>>That's the reason why we
> came up with the
>> > ConfigurableDataSource.
>> > > > >>>>>>>
>> > > > >>>>>>>Of course, we need to extend
> this concept and create a
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>public interface
> ConfigurableXaDataSource extends
>> > > > ConfigurableDataSource, XaDataSource {}
>> > > > >>>>>>>
>> > > > >>>>>>>See what I mean?
>> > > > >>>>>>>
>> > > > >>>>>>>LieGrue,
>> > > > >>>>>>>strub
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>>----- Original Message -----
>> > > > >>>>>>>> From: David Blevins
> <da...@gmail.com>
>> > > > >>>>>>>> To:
> deltaspike-dev@incubator.apache.org; Mark Struberg
>> > > > >>>>>>>> <
>> > > > struberg@yahoo.de>
>> > > > >>>>>>>> Cc:
>> > > > >>>>>>>> Sent: Sunday, May 6, 2012
> 1:25 PM
>> > > > >>>>>>>> Subject: Re: [DISCUSS]
> deltaspike-jpa module features
>> > > > >>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>>> On May 6, 2012, at 2:37 AM,
> Mark Struberg wrote:
>> > > > >>>>>>>>
>> > > > >>>>>>>>>> In plain Tomcat or
>> > > > >>>>>>>>>> Jetty servers this
> needs to be configured in a
>> > > > container-specific way.
>> > > > >>>>>>>>> The problem with the
> container specific stuff is that
>> > > > >>>>>>>>> every
>> > > > container
>> > > > >>>>>>>> serves the xml configured
> datasource on a different
>> > > > >>>>>>>> location in
>> > > > JNDI! So you
>> > > > >>>>>>>> cannot provide a container
> independent implementation
>> > > > >>>>>>>> that way :/
>> > > > >>>>>>>>
>> > > > >>>>>>>> The portable way would be
> to declare your datasource
>> > > > >>>>>>>> properly via
> @Resource(name="java:app/Foo",
>> > > > >>>>>>>> type=DataSource.class) or
> via <resource-ref> xml.
>> > > > >>>>>>>>
>> > > > >>>>>>>> Most servers can map those
> references with little to no
>> > config.
>> > > > >>>>>>>>
>> > > > >>>>>>>>
>> > > > >>>>>>>> -David
>> > > > >>>>>>>>
>> > > > >>>>>>>
>> > > > >>>>>>
>> > > > >>>>>>
>> > > > >>>>
>> > > > >>>>
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
AW: AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
features
Posted by Arne Limburg <ar...@openknowledge.de>.
Hi Mark,
Assuming that deltaspike creates the EntityManager, we could hand over this definition to the createEntityManager method via the second argument (the map) and thus override the persistence.xml.
Cheers,
Arne
-----Ursprüngliche Nachricht-----
Von: Mark Struberg [mailto:struberg@yahoo.de]
Gesendet: Montag, 7. Mai 2012 00:04
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Thought about such a thing as well. The problem here is: how do you tell the persistence.xml about our Qualifiers?
In fact the whole JPA environment gives a damn about CDI atm :(
LieGrue,
strub
----- Original Message -----
> From: Arne Limburg <ar...@openknowledge.de>
> To: "deltaspike-dev@incubator.apache.org"
> <de...@incubator.apache.org>
> Cc:
> Sent: Sunday, May 6, 2012 4:19 PM
> Subject: AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> features
>
> Never mind ;-)
> Maybe it is better to provide qualifiers for all the JPA properties? Like this:
>
> public class MyJpaConfig {
>
> @Produces
> @NonJtaDataSource
> @Exclude(exceptIfProjectStage =
> ProjectStage.IntegrationTest.class)
> public String getIntegrationTestDataSource() {
> ...
> }
>
> @Produces
> @TransactionType
> @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> public String getDevelopmentTransactionType() {
> ...
> }
>
> @Produces
> @JdbcUrl
> @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> public String getDevelopmentJdbcUrl() {
> ...
> }
> }
>
> Then we can feed the createEntityManager method with this properties...
>
> - Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 16:10
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> features
>
> Yep but an em needs an emf ;)
> Le 6 mai 2012 16:05, "Arne Limburg"
> <ar...@openknowledge.de> a écrit :
>
>> OK, I think, this is not correct since it expresses a dependency to
>> an EntityManager and not to an EntityManagerFactory (in opposition
>> to @PersistenceUnit).
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> Gesendet: Sonntag, 6. Mai 2012 16:00
>> An: deltaspike-dev@incubator.apache.org
>> Betreff: Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
>> features
>>
>> It tomee we create the entitymanagerfactory associated.
>> Le 6 mai 2012 15:53, "Arne Limburg"
> <ar...@openknowledge.de> a
>> écrit :
>>
>> > OK and the meaning of this annotation at class-level would be:
>> > "a dependency on a container-managed entity manager and its >
>> associated persistence context." That's perfectly the
> semantics we
>> > need ;-)
>> >
>> > But what would a jee container do when he observes such annotation
>> > at class-level? I can't read it from the spec...
>> > I think, we have to try... Or does someone at this list know?
>> >
>> > -----Ursprüngliche Nachricht-----
>> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com] >
>> Gesendet: Sonntag, 6. Mai 2012 15:49 > An:
>> deltaspike-dev@incubator.apache.org
>> > Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module >
>> features > > The container will scan persistencecontext annotation
>> with no link > with cdi.
>> > Le 6 mai 2012 15:46, "Arne Limburg"
> <ar...@openknowledge.de>
>> > a écrit :
>> >
>> > > If so, what would be the semantic of such definition?
>> > > Btw. that classes would only become CDI beans when the
>> deployment > > is in the correct project stage. Otherwise we would
>> veto them > > away, before they become beans...
>> > > And, which part of the jee container would scan that class? My
>> > > guess is, that it would be the responsibility of the CDI
> implementation.
>> > > And
>> > > - just a second guess - they ignore it...
>> > >
>> > > I'll take a look into the JPA spec to see what the official > >
>> semantic of the usage I proposed would be. But, I am afraid that > >
>> this is underspecified...
>> > >
>> > > -----Ursprüngliche Nachricht----- > > Von: Romain Manni-Bucau
>> [mailto:rmannibucau@gmail.com] > > Gesendet: Sonntag, 6. Mai 2012
>> 15:40 > > An: deltaspike-dev@incubator.apache.org
>> > > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module
>> features > > > > Cdi is in jee so jee containers scans cdi beans
>> and same for > > resources (@persistencontext).
>> > > Le 6 mai 2012 15:36, "Arne Limburg"
>> > > <ar...@openknowledge.de> a écrit :
>> > >
>> > > > If not, we can use other annotations, but I think jee
> containers
>> > > > just scan EJBs...
>> > > >
>> > > > -----Ursprüngliche Nachricht----- > > > Von: Romain
>> Manni-Bucau [mailto:rmannibucau@gmail.com] > > > Gesendet: Sonntag,
>> 6. Mai 2012 15:28 > > > An: deltaspike-dev@incubator.apache.org
>> > > > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module
> features
>> > > >
>> > > > Not sure it works in a jee container.
>> > > >
>> > > > - Romain
>> > > > Le 6 mai 2012 15:26, "Arne Limburg"
>> > > > <ar...@openknowledge.de> a écrit :
>> > > >
>> > > > > You could configure your production jta-datasource in
> the
>> > > > > persistence.xml and add the following bean to your test
> deployment:
>> > > > >
>> > > > > @Exclude(exceptIfProjectStage = > > > >
>> ProjectStage.IntegrationTest.class)
>> > > > > @PersistenceContext(unitName = "myPU",
> properties =
>> > > > > @PersistenceProperty(name =
>> > > > > "javax.persistence.nonJtaDataSource",
>> > > > > value =
>> > > > > "java:/comp/env/myDS"))
>> > > > > public class MyIntegrationTestConfiguration { } > > > > >
>> > > > For local testing, you could even switch off JNDI:
>> > > > > @Exclude(exceptIfProjectStage = > > > >
>> ProjectStage.Development.class)
> @PersistenceContext(unitName =
>> > > > > "myPU", properties =
> {@PersistenceProperty(name =
>> > > > > "javax.persistence.transactionType",
>> > > > > value = "RESOURCE_LOCAL"),
>> > > > >
>> > > > > @PersistenceProperty(name
> =
>> > > > > "javax.persistence.jdbc.url", value =
> "jdbc:h2:mem:myDB"),
>> > > > > ...}) public class MyDevelopmentConfiguration { } > > > >
>> > > > > WDYT?
>> > > > >
>> > > > > Romain,
>> > > > > Noone needs to repackage his application, since we can
> put
>> > > > > this properties into a map and use it as the second
> parameter
>> > > > > of
>> > > > emf.createEntityManager...
>> > > > >
>> > > > > - Arne
>> > > > >
>> > > > > -----Ursprüngliche Nachricht----- > > > > Von: Romain
>> Manni-Bucau [mailto:rmannibucau@gmail.com] > > > > Gesendet:
>> Sonntag, 6. Mai 2012 15:14 > > > > An:
>> deltaspike-dev@incubator.apache.org
>> > > > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module
> features
>> > > > >
>> > > > > How do you manage it from persistence.xml if you dont > > >
>> > repackage your archive as Mark said?
>> > > > >
>> > > > > Personally i agree ;)
>> > > > >
>> > > > > - Romain
>> > > > > Le 6 mai 2012 15:06, "Arne Limburg"
>> > > > > <ar...@openknowledge.de> a écrit :
>> > > > >
>> > > > > > OK,
>> > > > > > but do we really need a container-independent way
> for
>> > > JNDI-DataSources?
>> > > > > > What's the use case for it?
>> > > > > > The user always knows his container and thus his
> specific
>> > JNDI-name.
>> > > > > >
>> > > > > > I think we need an easy way for users to configure
> different
>> > > > > > JNDI-DataSources for different deployment
> scenarios, like
>> > > > > > - a JTA-datasource for my JBoss AS 7 in production > > >
>> > > - a Non-JTA-datasource from another JNDI-location
> for the
>> > > > > > Tomcat for testing
>> > > > > > - a RESOURCE_LOCAL EntityManager for local
> testing...
>> > > > > >
>> > > > > > We need to find an easy way for the users to
> configure the
>> > > > > > JNDI-location, but imho we don't need to
> handle different
>> > > > > > JNDI-locations
>> > > > > in our code?
>> > > > > >
>> > > > > > WDYT? Am I missing a use case?
>> > > > > >
>> > > > > > Cheers,
>> > > > > > Arne
>> > > > > >
>> > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: Romain
>> Manni-Bucau
> [mailto:rmannibucau@gmail.com]
>> > > > > > Gesendet: Sonntag, 6. Mai 2012 14:49 > > > > > An: Mark
>> Struberg;
> deltaspike-dev@incubator.apache.org
>> > > > > > Betreff: Re: [DISCUSS] deltaspike-jpa module
> features
>> > > > > >
>> > > > > > ConfigurableDataSource doesnt solve it. If you
> build the emf
>> > > > > > from persistence info you manage it yourself. It
> should be
>> > > > > > IMO a compatibility mode and spec you be fixed.
>> > > > > >
>> > > > > > But well, the most important subjects are not
> here,
>> > > > > > pagination, dynamic dao etc are really more
> valuable.
>> > > > > >
>> > > > > > - Romain
>> > > > > > Le 6 mai 2012 14:44, "Mark Struberg"
> <st...@yahoo.de> a
>> écrit :
>> > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > The problem here is that this is NOT under
> our control -
>> > > > > > > this is not even CDI related!
>> > > > > > >
>> > > > > > > You need to _exactly_ specify the JNDI
> location in your
>> > > > > persistence.xml.
>> > > > > > > And this info get's parsed by JPA or the
> EE container at
>> > > > > > > deploy
>> > > time.
>> > > > > > >
>> > > > > > >
>> > > > > > > Maybe there's a trick with a
> PersistenceUnitInfo. But
>> > > > > > > since those are also managed by the server
> (and thus show
>> > > > > > > the same unspecified
>> > > > > > > behaviour) we imo cannot leverage those.
>> > > > > > >
>> > > > > > > LieGrue,
>> > > > > > > strub
>> > > > > > >
>> > > > > > >
>> > > > > > > >________________________________ > > > > > > > From:
>> Romain Manni-Bucau
> <rm...@gmail.com>
>> > > > > > > >To: Mark Struberg
> <st...@yahoo.de>;
>> > > > > > > deltaspike-dev@incubator.apache.org
>> > > > > > > >Sent: Sunday, May 6, 2012 2:37 PM > > > > > >
>> >Subject: Re: [DISCUSS] deltaspike-jpa
> module features
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >I understand. On another side how many
> differeny
>> > > > > > > >locations are
>> > > > there?
>> > > > > > > Isnt it manageable?
>> > > > > > > >- Romain
>> > > > > > > >Le 6 mai 2012 14:29, "Mark
> Struberg" <st...@yahoo.de>
>> > > > > > > >a écrit
>> > > :
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >>
>> > > > > > > >>PS: I _fully_ agree that this mess
> should best get fixed
>> > > > > > > >>in
>> > EE7.
>> > > > > > > >>But
>> > > > > > > sadly we also need to support older
> containers!
>> > > > > > > >>
>> > > > > > > >>I know about folks who have OWB and
> CODI running on old
>> > > > > > > >>WebSphere
>> > > > > > > >>6 and
>> > > > > > > 7 servers. And others who use OWB on WebLogic
> 10.3. And
>> > > > > > > those companies are big banks, stock
> exchanges and
>> > > > > > > insurrance companies
>> > > > > > > - they cannot easily upgrade to a new
> server...
>> > > > > > > >>
>> > > > > > > >>LieGrue,
>> > > > > > > >>strub
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>>________________________________
>> > > > > > > >>> From: Mark Struberg
> <st...@yahoo.de>
>> > > > > > > >>>To: Romain Manni-Bucau
> <rm...@gmail.com>;
>> > > > > > > >>>deltaspike <
>> > > > > > > deltaspike-dev@incubator.apache.org>
>> > > > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM > > > > > >
>> >>>Subject: Re: [DISCUSS]
> deltaspike-jpa module features
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>No, the container is NOT buggy,
> because it's simply NOT
>> > defined!
>> > > > > > > >>>That's the whole mess about
> JNDI...
>> > > > > > > >>>
>> > > > > > > >>>LieGrue,
>> > > > > > > >>>strub
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > >
>>>>> ________________________________
>> > > > > > > >>>> From: Romain Manni-Bucau
> <rm...@gmail.com>
>> > > > > > > >>>>To: Mark Struberg
> <st...@yahoo.de>
>> > > > > > > >>>>Sent: Sunday, May 6, 2012
> 2:01 PM
>> > > > > > > >>>>Subject: Re: [DISCUSS]
> deltaspike-jpa module features
>> > > > > > > >>>>
>> > > > > > > >>>>
>> > > > > > > >>>>So this container is buggy,
> report an issue ;)
>> > > > > > > >>>>Thinking of it this jndi path
> issue couldnt be
>> > > > > > > >>>>resolved by
>> > > > > > > configresolvers in ds?
>> > > > > > > >>>>- Romain
>> > > > > > > >>>>Le 6 mai 2012 13:58,
> "Mark Struberg"
>> > > > > > > >>>><st...@yahoo.de> a > > > écrit :
>> > > > > > > >>>>
>> > > > > > > >>>>yes, that crashes the
> container...
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > >
>>>>>>> ________________________________
>> > > > > > > >>>>>> From: Romain
> Manni-Bucau <rm...@gmail.com>
>> > > > > > > >>>>>>To: Mark Struberg
> <st...@yahoo.de>;
>> > > > > > > deltaspike-dev@incubator.apache.org
>> > > > > > > >>>>>>Sent: Sunday, May 6,
> 2012 1:52 PM
>> > > > > > > >>>>>>Subject: Re:
> [DISCUSS] deltaspike-jpa module
>> > > > > > > >>>>>>features
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>Mark, did you try
> providing a name starting with java:?
>> > > > > > > >>>>>>- Romain
>> > > > > > > >>>>>>Le 6 mai 2012 13:49,
> "Mark Struberg"
>> > > > > > >
>>>>>>> <st...@yahoo.de> a
>> > > > > écrit :
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>David, exactly
> this doesn't work out in practice!
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>look at jboss5
> datasource xml as an example:
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>><?xml
> version="1.0" encoding="UTF-8"?> <datasources>
>> > > > > > > >>>>>>>
> <local-tx-datasource>
>> > > > > > > >>>>>>>
> <jndi-name>myDS</jndi-name>
>> > > > > > > >>>>>>>
>> > > > > > >
> <connection-url>jdbc:postgresql://someserver:5432/someDb</
>> > > > > > > co
>> > > > > > > nn
>> > > > > > > ec
>> > > > > > > ti
>> > > > > > > on
>> > > > > > > -u
>> > > > > > > rl>
>> > > > > > > >>>>>>>
> <user-name>user</user-name>
>> > > > > > > >>>>>>>
> <password>pwd</password>
>> > > > > > > >>>>>>>
>> > > > > > >
> <driver-class>org.postgresql.Driver</driver-class>
>> > > > > > > >>>>>>>
> </local-tx-datasource> </datasources>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>This will create
> the following JNDI location in
>> JBossAS5:
>> > > > > > > >>>>>>>java:/myDS
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>NO comp, NO lang,
> NO other qualifier.
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>Configuring the
> same in Geronimo gives you
>> > > > > > >
>>>>>>>> java:/comp/env/myDS and it's again COMPLETEY
>> > > > > > > >>>>>>>different in
> JBossAS6, AS7, Glassfish,
>> > > > > > > TomEE, etc
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>Thus: which JNDI
> location would you configure in
>> > > > > > > >>>>>>>your
>> > > > > > > persistence.xml?
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>That's the
> reason why we came up with the
>> > > > > ConfigurableDataSource.
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>Of course, we
> need to extend this concept and
>> > > > > > > >>>>>>>create a
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>public interface
> ConfigurableXaDataSource extends
>> > > > > > > ConfigurableDataSource, XaDataSource {} > > > > > >
>> >>>>>>> > > > > > > >>>>>>>See what I mean?
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>LieGrue,
>> > > > > > > >>>>>>>strub
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>----- Original
> Message -----
>> > > > > > > >>>>>>>> From: David
> Blevins <da...@gmail.com>
>> > > > > > > >>>>>>>> To:
> deltaspike-dev@incubator.apache.org; Mark
>> > > > > > > >>>>>>>> Struberg
> <
>> > > > > > > struberg@yahoo.de>
>> > > > > > > >>>>>>>> Cc:
>> > > > > > > >>>>>>>> Sent:
> Sunday, May 6, 2012 1:25 PM
>> > > > > > > >>>>>>>> Subject: Re:
> [DISCUSS] deltaspike-jpa module
>> > > > > > > >>>>>>>> features
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> On May 6,
> 2012, at 2:37 AM, Mark Struberg wrote:
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>>> In
> plain Tomcat or Jetty servers this needs
>> > > > > > > >>>>>>>>>> to
> be configured in a
>> > > > > > > container-specific way.
>> > > > > > > >>>>>>>>> The
> problem with the container specific stuff
>> > > > > > > >>>>>>>>> is that
> every
>> > > > > > > container
>> > > > > > > >>>>>>>> serves the
> xml configured datasource on a
>> > > > > > > >>>>>>>> different
> location in
>> > > > > > > JNDI! So you
>> > > > > > > >>>>>>>> cannot
> provide a container independent
>> > > > > > > >>>>>>>>
> implementation that way :/
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> The portable
> way would be to declare your
>> > > > > > > >>>>>>>> datasource
> properly via
>> > > > > > > >>>>>>>>
> @Resource(name="java:app/Foo",
>> > > > > > > >>>>>>>>
> type=DataSource.class) or via <resource-ref> xml.
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> Most servers
> can map those references with little
>> > > > > > > >>>>>>>> to no
>> > > > > config.
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> -David
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>
>> > > > > > > >>>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
Thought about such a thing as well. The problem here is: how do you tell the persistence.xml about our Qualifiers?
In fact the whole JPA environment gives a damn about CDI atm :(
LieGrue,
strub
----- Original Message -----
> From: Arne Limburg <ar...@openknowledge.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> Cc:
> Sent: Sunday, May 6, 2012 4:19 PM
> Subject: AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> Never mind ;-)
> Maybe it is better to provide qualifiers for all the JPA properties? Like this:
>
> public class MyJpaConfig {
>
> @Produces
> @NonJtaDataSource
> @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> public String getIntegrationTestDataSource() {
> ...
> }
>
> @Produces
> @TransactionType
> @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> public String getDevelopmentTransactionType() {
> ...
> }
>
> @Produces
> @JdbcUrl
> @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> public String getDevelopmentJdbcUrl() {
> ...
> }
> }
>
> Then we can feed the createEntityManager method with this properties...
>
> - Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 16:10
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> Yep but an em needs an emf ;)
> Le 6 mai 2012 16:05, "Arne Limburg"
> <ar...@openknowledge.de> a écrit :
>
>> OK, I think, this is not correct since it expresses a dependency to an
>> EntityManager and not to an EntityManagerFactory (in opposition to
>> @PersistenceUnit).
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> Gesendet: Sonntag, 6. Mai 2012 16:00
>> An: deltaspike-dev@incubator.apache.org
>> Betreff: Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
>> features
>>
>> It tomee we create the entitymanagerfactory associated.
>> Le 6 mai 2012 15:53, "Arne Limburg"
> <ar...@openknowledge.de> a
>> écrit :
>>
>> > OK and the meaning of this annotation at class-level would be:
>> > "a dependency on a container-managed entity manager and its
>> > associated persistence context." That's perfectly the
> semantics we
>> > need ;-)
>> >
>> > But what would a jee container do when he observes such annotation
>> > at class-level? I can't read it from the spec...
>> > I think, we have to try... Or does someone at this list know?
>> >
>> > -----Ursprüngliche Nachricht-----
>> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > Gesendet: Sonntag, 6. Mai 2012 15:49
>> > An: deltaspike-dev@incubator.apache.org
>> > Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
>> > features
>> >
>> > The container will scan persistencecontext annotation with no link
>> > with cdi.
>> > Le 6 mai 2012 15:46, "Arne Limburg"
> <ar...@openknowledge.de>
>> > a écrit :
>> >
>> > > If so, what would be the semantic of such definition?
>> > > Btw. that classes would only become CDI beans when the deployment
>> > > is in the correct project stage. Otherwise we would veto them
>> > > away, before they become beans...
>> > > And, which part of the jee container would scan that class? My
>> > > guess is, that it would be the responsibility of the CDI
> implementation.
>> > > And
>> > > - just a second guess - they ignore it...
>> > >
>> > > I'll take a look into the JPA spec to see what the official
>> > > semantic of the usage I proposed would be. But, I am afraid that
>> > > this is underspecified...
>> > >
>> > > -----Ursprüngliche Nachricht-----
>> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > > Gesendet: Sonntag, 6. Mai 2012 15:40
>> > > An: deltaspike-dev@incubator.apache.org
>> > > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>> > >
>> > > Cdi is in jee so jee containers scans cdi beans and same for
>> > > resources (@persistencontext).
>> > > Le 6 mai 2012 15:36, "Arne Limburg"
>> > > <ar...@openknowledge.de> a écrit :
>> > >
>> > > > If not, we can use other annotations, but I think jee
> containers
>> > > > just scan EJBs...
>> > > >
>> > > > -----Ursprüngliche Nachricht-----
>> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > > > Gesendet: Sonntag, 6. Mai 2012 15:28
>> > > > An: deltaspike-dev@incubator.apache.org
>> > > > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module
> features
>> > > >
>> > > > Not sure it works in a jee container.
>> > > >
>> > > > - Romain
>> > > > Le 6 mai 2012 15:26, "Arne Limburg"
>> > > > <ar...@openknowledge.de> a écrit :
>> > > >
>> > > > > You could configure your production jta-datasource in
> the
>> > > > > persistence.xml and add the following bean to your test
> deployment:
>> > > > >
>> > > > > @Exclude(exceptIfProjectStage =
>> > > > > ProjectStage.IntegrationTest.class)
>> > > > > @PersistenceContext(unitName = "myPU",
> properties =
>> > > > > @PersistenceProperty(name =
>> > > > > "javax.persistence.nonJtaDataSource",
>> > > > > value =
>> > > > > "java:/comp/env/myDS"))
>> > > > > public class MyIntegrationTestConfiguration { }
>> > > > >
>> > > > > For local testing, you could even switch off JNDI:
>> > > > > @Exclude(exceptIfProjectStage =
>> > > > > ProjectStage.Development.class)
> @PersistenceContext(unitName =
>> > > > > "myPU", properties =
> {@PersistenceProperty(name =
>> > > > > "javax.persistence.transactionType",
>> > > > > value = "RESOURCE_LOCAL"),
>> > > > >
>> > > > > @PersistenceProperty(name
> =
>> > > > > "javax.persistence.jdbc.url", value =
> "jdbc:h2:mem:myDB"),
>> > > > > ...}) public class MyDevelopmentConfiguration { }
>> > > > >
>> > > > > WDYT?
>> > > > >
>> > > > > Romain,
>> > > > > Noone needs to repackage his application, since we can
> put
>> > > > > this properties into a map and use it as the second
> parameter
>> > > > > of
>> > > > emf.createEntityManager...
>> > > > >
>> > > > > - Arne
>> > > > >
>> > > > > -----Ursprüngliche Nachricht-----
>> > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > > > > Gesendet: Sonntag, 6. Mai 2012 15:14
>> > > > > An: deltaspike-dev@incubator.apache.org
>> > > > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module
> features
>> > > > >
>> > > > > How do you manage it from persistence.xml if you dont
>> > > > > repackage your archive as Mark said?
>> > > > >
>> > > > > Personally i agree ;)
>> > > > >
>> > > > > - Romain
>> > > > > Le 6 mai 2012 15:06, "Arne Limburg"
>> > > > > <ar...@openknowledge.de> a écrit :
>> > > > >
>> > > > > > OK,
>> > > > > > but do we really need a container-independent way
> for
>> > > JNDI-DataSources?
>> > > > > > What's the use case for it?
>> > > > > > The user always knows his container and thus his
> specific
>> > JNDI-name.
>> > > > > >
>> > > > > > I think we need an easy way for users to configure
> different
>> > > > > > JNDI-DataSources for different deployment
> scenarios, like
>> > > > > > - a JTA-datasource for my JBoss AS 7 in production
>> > > > > > - a Non-JTA-datasource from another JNDI-location
> for the
>> > > > > > Tomcat for testing
>> > > > > > - a RESOURCE_LOCAL EntityManager for local
> testing...
>> > > > > >
>> > > > > > We need to find an easy way for the users to
> configure the
>> > > > > > JNDI-location, but imho we don't need to
> handle different
>> > > > > > JNDI-locations
>> > > > > in our code?
>> > > > > >
>> > > > > > WDYT? Am I missing a use case?
>> > > > > >
>> > > > > > Cheers,
>> > > > > > Arne
>> > > > > >
>> > > > > > -----Ursprüngliche Nachricht-----
>> > > > > > Von: Romain Manni-Bucau
> [mailto:rmannibucau@gmail.com]
>> > > > > > Gesendet: Sonntag, 6. Mai 2012 14:49
>> > > > > > An: Mark Struberg;
> deltaspike-dev@incubator.apache.org
>> > > > > > Betreff: Re: [DISCUSS] deltaspike-jpa module
> features
>> > > > > >
>> > > > > > ConfigurableDataSource doesnt solve it. If you
> build the emf
>> > > > > > from persistence info you manage it yourself. It
> should be
>> > > > > > IMO a compatibility mode and spec you be fixed.
>> > > > > >
>> > > > > > But well, the most important subjects are not
> here,
>> > > > > > pagination, dynamic dao etc are really more
> valuable.
>> > > > > >
>> > > > > > - Romain
>> > > > > > Le 6 mai 2012 14:44, "Mark Struberg"
> <st...@yahoo.de> a
>> écrit :
>> > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > The problem here is that this is NOT under
> our control -
>> > > > > > > this is not even CDI related!
>> > > > > > >
>> > > > > > > You need to _exactly_ specify the JNDI
> location in your
>> > > > > persistence.xml.
>> > > > > > > And this info get's parsed by JPA or the
> EE container at
>> > > > > > > deploy
>> > > time.
>> > > > > > >
>> > > > > > >
>> > > > > > > Maybe there's a trick with a
> PersistenceUnitInfo. But
>> > > > > > > since those are also managed by the server
> (and thus show
>> > > > > > > the same unspecified
>> > > > > > > behaviour) we imo cannot leverage those.
>> > > > > > >
>> > > > > > > LieGrue,
>> > > > > > > strub
>> > > > > > >
>> > > > > > >
>> > > > > > > >________________________________
>> > > > > > > > From: Romain Manni-Bucau
> <rm...@gmail.com>
>> > > > > > > >To: Mark Struberg
> <st...@yahoo.de>;
>> > > > > > > deltaspike-dev@incubator.apache.org
>> > > > > > > >Sent: Sunday, May 6, 2012 2:37 PM
>> > > > > > > >Subject: Re: [DISCUSS] deltaspike-jpa
> module features
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >I understand. On another side how many
> differeny
>> > > > > > > >locations are
>> > > > there?
>> > > > > > > Isnt it manageable?
>> > > > > > > >- Romain
>> > > > > > > >Le 6 mai 2012 14:29, "Mark
> Struberg" <st...@yahoo.de>
>> > > > > > > >a écrit
>> > > :
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >>
>> > > > > > > >>PS: I _fully_ agree that this mess
> should best get fixed
>> > > > > > > >>in
>> > EE7.
>> > > > > > > >>But
>> > > > > > > sadly we also need to support older
> containers!
>> > > > > > > >>
>> > > > > > > >>I know about folks who have OWB and
> CODI running on old
>> > > > > > > >>WebSphere
>> > > > > > > >>6 and
>> > > > > > > 7 servers. And others who use OWB on WebLogic
> 10.3. And
>> > > > > > > those companies are big banks, stock
> exchanges and
>> > > > > > > insurrance companies
>> > > > > > > - they cannot easily upgrade to a new
> server...
>> > > > > > > >>
>> > > > > > > >>LieGrue,
>> > > > > > > >>strub
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>>________________________________
>> > > > > > > >>> From: Mark Struberg
> <st...@yahoo.de>
>> > > > > > > >>>To: Romain Manni-Bucau
> <rm...@gmail.com>;
>> > > > > > > >>>deltaspike <
>> > > > > > > deltaspike-dev@incubator.apache.org>
>> > > > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
>> > > > > > > >>>Subject: Re: [DISCUSS]
> deltaspike-jpa module features
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>No, the container is NOT buggy,
> because it's simply NOT
>> > defined!
>> > > > > > > >>>That's the whole mess about
> JNDI...
>> > > > > > > >>>
>> > > > > > > >>>LieGrue,
>> > > > > > > >>>strub
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > >
>>>>> ________________________________
>> > > > > > > >>>> From: Romain Manni-Bucau
> <rm...@gmail.com>
>> > > > > > > >>>>To: Mark Struberg
> <st...@yahoo.de>
>> > > > > > > >>>>Sent: Sunday, May 6, 2012
> 2:01 PM
>> > > > > > > >>>>Subject: Re: [DISCUSS]
> deltaspike-jpa module features
>> > > > > > > >>>>
>> > > > > > > >>>>
>> > > > > > > >>>>So this container is buggy,
> report an issue ;)
>> > > > > > > >>>>Thinking of it this jndi path
> issue couldnt be
>> > > > > > > >>>>resolved by
>> > > > > > > configresolvers in ds?
>> > > > > > > >>>>- Romain
>> > > > > > > >>>>Le 6 mai 2012 13:58,
> "Mark Struberg"
>> > > > > > > >>>><st...@yahoo.de> a
>> > > > écrit :
>> > > > > > > >>>>
>> > > > > > > >>>>yes, that crashes the
> container...
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > >
>>>>>>> ________________________________
>> > > > > > > >>>>>> From: Romain
> Manni-Bucau <rm...@gmail.com>
>> > > > > > > >>>>>>To: Mark Struberg
> <st...@yahoo.de>;
>> > > > > > > deltaspike-dev@incubator.apache.org
>> > > > > > > >>>>>>Sent: Sunday, May 6,
> 2012 1:52 PM
>> > > > > > > >>>>>>Subject: Re:
> [DISCUSS] deltaspike-jpa module
>> > > > > > > >>>>>>features
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>Mark, did you try
> providing a name starting with java:?
>> > > > > > > >>>>>>- Romain
>> > > > > > > >>>>>>Le 6 mai 2012 13:49,
> "Mark Struberg"
>> > > > > > >
>>>>>>> <st...@yahoo.de> a
>> > > > > écrit :
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>David, exactly
> this doesn't work out in practice!
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>look at jboss5
> datasource xml as an example:
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>><?xml
> version="1.0" encoding="UTF-8"?> <datasources>
>> > > > > > > >>>>>>>
> <local-tx-datasource>
>> > > > > > > >>>>>>>
> <jndi-name>myDS</jndi-name>
>> > > > > > > >>>>>>>
>> > > > > > >
> <connection-url>jdbc:postgresql://someserver:5432/someDb</
>> > > > > > > co
>> > > > > > > nn
>> > > > > > > ec
>> > > > > > > ti
>> > > > > > > on
>> > > > > > > -u
>> > > > > > > rl>
>> > > > > > > >>>>>>>
> <user-name>user</user-name>
>> > > > > > > >>>>>>>
> <password>pwd</password>
>> > > > > > > >>>>>>>
>> > > > > > >
> <driver-class>org.postgresql.Driver</driver-class>
>> > > > > > > >>>>>>>
> </local-tx-datasource> </datasources>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>This will create
> the following JNDI location in
>> JBossAS5:
>> > > > > > > >>>>>>>java:/myDS
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>NO comp, NO lang,
> NO other qualifier.
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>Configuring the
> same in Geronimo gives you
>> > > > > > >
>>>>>>>> java:/comp/env/myDS and it's again COMPLETEY
>> > > > > > > >>>>>>>different in
> JBossAS6, AS7, Glassfish,
>> > > > > > > TomEE, etc
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>Thus: which JNDI
> location would you configure in
>> > > > > > > >>>>>>>your
>> > > > > > > persistence.xml?
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>That's the
> reason why we came up with the
>> > > > > ConfigurableDataSource.
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>Of course, we
> need to extend this concept and
>> > > > > > > >>>>>>>create a
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>public interface
> ConfigurableXaDataSource extends
>> > > > > > > ConfigurableDataSource, XaDataSource {}
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>See what I mean?
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>LieGrue,
>> > > > > > > >>>>>>>strub
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>----- Original
> Message -----
>> > > > > > > >>>>>>>> From: David
> Blevins <da...@gmail.com>
>> > > > > > > >>>>>>>> To:
> deltaspike-dev@incubator.apache.org; Mark
>> > > > > > > >>>>>>>> Struberg
> <
>> > > > > > > struberg@yahoo.de>
>> > > > > > > >>>>>>>> Cc:
>> > > > > > > >>>>>>>> Sent:
> Sunday, May 6, 2012 1:25 PM
>> > > > > > > >>>>>>>> Subject: Re:
> [DISCUSS] deltaspike-jpa module
>> > > > > > > >>>>>>>> features
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> On May 6,
> 2012, at 2:37 AM, Mark Struberg wrote:
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>>> In
> plain Tomcat or Jetty servers this needs
>> > > > > > > >>>>>>>>>> to
> be configured in a
>> > > > > > > container-specific way.
>> > > > > > > >>>>>>>>> The
> problem with the container specific stuff
>> > > > > > > >>>>>>>>> is that
> every
>> > > > > > > container
>> > > > > > > >>>>>>>> serves the
> xml configured datasource on a
>> > > > > > > >>>>>>>> different
> location in
>> > > > > > > JNDI! So you
>> > > > > > > >>>>>>>> cannot
> provide a container independent
>> > > > > > > >>>>>>>>
> implementation that way :/
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> The portable
> way would be to declare your
>> > > > > > > >>>>>>>> datasource
> properly via
>> > > > > > > >>>>>>>>
> @Resource(name="java:app/Foo",
>> > > > > > > >>>>>>>>
> type=DataSource.class) or via <resource-ref> xml.
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> Most servers
> can map those references with little
>> > > > > > > >>>>>>>> to no
>> > > > > config.
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> -David
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>
>> > > > > > > >>>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: AW: AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm i dont think @Named could be used too.
- Romain
Le 6 mai 2012 16:36, "Arne Limburg" <ar...@openknowledge.de> a
écrit :
> Several persistence units should be distinguished via qualifiers like CoDI
> does:
>
> public class MyJpaConfig {
>
> @Produces
> @Users
> @NonJtaDataSource
> @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> public String getIntegrationTestDataSource() {
> ...
> }
>
> @Produces
> @Common
> @NonJtaDataSource
> @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> public String getIntegrationTestDataSource() {
> ...
> }
> }
>
> Should we do a default-matching between the name of the qualifier and the
> persistence-unit name? I.e. the above would correspond to the following two
> persistence units:
> <persistence-unit name="users">...</persistence-unit>
> <persistence-unit name="common">...</persistence-unit>
>
> - Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 16:20
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> features
>
> That's cool but IMO it should be in the spec and not in DS.
>
> Moreover you need a name if you have several datasources.
>
> - Romain
> Le 6 mai 2012 16:17, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > Never mind ;-)
> > Maybe it is better to provide qualifiers for all the JPA properties?
> > Like
> > this:
> >
> > public class MyJpaConfig {
> >
> > @Produces
> > @NonJtaDataSource
> > @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> > public String getIntegrationTestDataSource() {
> > ...
> > }
> >
> > @Produces
> > @TransactionType
> > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> > public String getDevelopmentTransactionType() {
> > ...
> > }
> >
> > @Produces
> > @JdbcUrl
> > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> > public String getDevelopmentJdbcUrl() {
> > ...
> > }
> > }
> >
> > Then we can feed the createEntityManager method with this properties...
> >
> > - Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 16:10
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> > features
> >
> > Yep but an em needs an emf ;)
> > Le 6 mai 2012 16:05, "Arne Limburg" <ar...@openknowledge.de> a
> > écrit :
> >
> > > OK, I think, this is not correct since it expresses a dependency to
> > > an EntityManager and not to an EntityManagerFactory (in opposition
> > > to @PersistenceUnit).
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 16:00
> > > An: deltaspike-dev@incubator.apache.org
> > > Betreff: Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> > > features
> > >
> > > It tomee we create the entitymanagerfactory associated.
> > > Le 6 mai 2012 15:53, "Arne Limburg" <ar...@openknowledge.de>
> > > a écrit :
> > >
> > > > OK and the meaning of this annotation at class-level would be:
> > > > "a dependency on a container-managed entity manager and its
> > > > associated persistence context." That's perfectly the semantics we
> > > > need ;-)
> > > >
> > > > But what would a jee container do when he observes such annotation
> > > > at class-level? I can't read it from the spec...
> > > > I think, we have to try... Or does someone at this list know?
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > Gesendet: Sonntag, 6. Mai 2012 15:49
> > > > An: deltaspike-dev@incubator.apache.org
> > > > Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> > > > features
> > > >
> > > > The container will scan persistencecontext annotation with no link
> > > > with cdi.
> > > > Le 6 mai 2012 15:46, "Arne Limburg"
> > > > <ar...@openknowledge.de> a écrit :
> > > >
> > > > > If so, what would be the semantic of such definition?
> > > > > Btw. that classes would only become CDI beans when the
> > > > > deployment is in the correct project stage. Otherwise we would
> > > > > veto them away, before they become beans...
> > > > > And, which part of the jee container would scan that class? My
> > > > > guess is, that it would be the responsibility of the CDI
> > implementation.
> > > > > And
> > > > > - just a second guess - they ignore it...
> > > > >
> > > > > I'll take a look into the JPA spec to see what the official
> > > > > semantic of the usage I proposed would be. But, I am afraid that
> > > > > this is underspecified...
> > > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > Gesendet: Sonntag, 6. Mai 2012 15:40
> > > > > An: deltaspike-dev@incubator.apache.org
> > > > > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> > > > > features
> > > > >
> > > > > Cdi is in jee so jee containers scans cdi beans and same for
> > > > > resources (@persistencontext).
> > > > > Le 6 mai 2012 15:36, "Arne Limburg"
> > > > > <ar...@openknowledge.de> a écrit :
> > > > >
> > > > > > If not, we can use other annotations, but I think jee
> > > > > > containers just scan EJBs...
> > > > > >
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > > Gesendet: Sonntag, 6. Mai 2012 15:28
> > > > > > An: deltaspike-dev@incubator.apache.org
> > > > > > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
> > > > > >
> > > > > > Not sure it works in a jee container.
> > > > > >
> > > > > > - Romain
> > > > > > Le 6 mai 2012 15:26, "Arne Limburg"
> > > > > > <ar...@openknowledge.de> a écrit :
> > > > > >
> > > > > > > You could configure your production jta-datasource in the
> > > > > > > persistence.xml and add the following bean to your test
> > deployment:
> > > > > > >
> > > > > > > @Exclude(exceptIfProjectStage =
> > > > > > > ProjectStage.IntegrationTest.class)
> > > > > > > @PersistenceContext(unitName = "myPU", properties =
> > > > > > > @PersistenceProperty(name =
> > > > > > > "javax.persistence.nonJtaDataSource",
> > > > > > > value =
> > > > > > > "java:/comp/env/myDS"))
> > > > > > > public class MyIntegrationTestConfiguration { }
> > > > > > >
> > > > > > > For local testing, you could even switch off JNDI:
> > > > > > > @Exclude(exceptIfProjectStage =
> > > > > > > ProjectStage.Development.class) @PersistenceContext(unitName
> > > > > > > = "myPU", properties = {@PersistenceProperty(name =
> > > > > > > "javax.persistence.transactionType",
> > > > > > > value = "RESOURCE_LOCAL"),
> > > > > > >
> > > > > > > @PersistenceProperty(name =
> > > > > > > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"),
> > > > > > > ...}) public class MyDevelopmentConfiguration { }
> > > > > > >
> > > > > > > WDYT?
> > > > > > >
> > > > > > > Romain,
> > > > > > > Noone needs to repackage his application, since we can put
> > > > > > > this properties into a map and use it as the second
> > > > > > > parameter of
> > > > > > emf.createEntityManager...
> > > > > > >
> > > > > > > - Arne
> > > > > > >
> > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > > > Gesendet: Sonntag, 6. Mai 2012 15:14
> > > > > > > An: deltaspike-dev@incubator.apache.org
> > > > > > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> > > > > > >
> > > > > > > How do you manage it from persistence.xml if you dont
> > > > > > > repackage your archive as Mark said?
> > > > > > >
> > > > > > > Personally i agree ;)
> > > > > > >
> > > > > > > - Romain
> > > > > > > Le 6 mai 2012 15:06, "Arne Limburg"
> > > > > > > <ar...@openknowledge.de> a écrit :
> > > > > > >
> > > > > > > > OK,
> > > > > > > > but do we really need a container-independent way for
> > > > > JNDI-DataSources?
> > > > > > > > What's the use case for it?
> > > > > > > > The user always knows his container and thus his specific
> > > > JNDI-name.
> > > > > > > >
> > > > > > > > I think we need an easy way for users to configure
> > > > > > > > different JNDI-DataSources for different deployment
> > > > > > > > scenarios, like
> > > > > > > > - a JTA-datasource for my JBoss AS 7 in production
> > > > > > > > - a Non-JTA-datasource from another JNDI-location for the
> > > > > > > > Tomcat for testing
> > > > > > > > - a RESOURCE_LOCAL EntityManager for local testing...
> > > > > > > >
> > > > > > > > We need to find an easy way for the users to configure the
> > > > > > > > JNDI-location, but imho we don't need to handle different
> > > > > > > > JNDI-locations
> > > > > > > in our code?
> > > > > > > >
> > > > > > > > WDYT? Am I missing a use case?
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > Arne
> > > > > > > >
> > > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > > > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > > > > > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > > > > > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > >
> > > > > > > > ConfigurableDataSource doesnt solve it. If you build the
> > > > > > > > emf from persistence info you manage it yourself. It
> > > > > > > > should be IMO a compatibility mode and spec you be fixed.
> > > > > > > >
> > > > > > > > But well, the most important subjects are not here,
> > > > > > > > pagination, dynamic dao etc are really more valuable.
> > > > > > > >
> > > > > > > > - Romain
> > > > > > > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a
> > > écrit :
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > The problem here is that this is NOT under our control -
> > > > > > > > > this is not even CDI related!
> > > > > > > > >
> > > > > > > > > You need to _exactly_ specify the JNDI location in your
> > > > > > > persistence.xml.
> > > > > > > > > And this info get's parsed by JPA or the EE container at
> > > > > > > > > deploy
> > > > > time.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Maybe there's a trick with a PersistenceUnitInfo. But
> > > > > > > > > since those are also managed by the server (and thus
> > > > > > > > > show the same unspecified
> > > > > > > > > behaviour) we imo cannot leverage those.
> > > > > > > > >
> > > > > > > > > LieGrue,
> > > > > > > > > strub
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >________________________________
> > > > > > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > > > > > > deltaspike-dev@incubator.apache.org
> > > > > > > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > > > > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >I understand. On another side how many differeny
> > > > > > > > > >locations are
> > > > > > there?
> > > > > > > > > Isnt it manageable?
> > > > > > > > > >- Romain
> > > > > > > > > >Le 6 mai 2012 14:29, "Mark Struberg"
> > > > > > > > > ><st...@yahoo.de> a écrit
> > > > > :
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >>
> > > > > > > > > >>PS: I _fully_ agree that this mess should best get
> > > > > > > > > >>fixed in
> > > > EE7.
> > > > > > > > > >>But
> > > > > > > > > sadly we also need to support older containers!
> > > > > > > > > >>
> > > > > > > > > >>I know about folks who have OWB and CODI running on
> > > > > > > > > >>old WebSphere
> > > > > > > > > >>6 and
> > > > > > > > > 7 servers. And others who use OWB on WebLogic 10.3. And
> > > > > > > > > those companies are big banks, stock exchanges and
> > > > > > > > > insurrance companies
> > > > > > > > > - they cannot easily upgrade to a new server...
> > > > > > > > > >>
> > > > > > > > > >>LieGrue,
> > > > > > > > > >>strub
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>>________________________________
> > > > > > > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > > > > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>;
> > > > > > > > > >>>deltaspike <
> > > > > > > > > deltaspike-dev@incubator.apache.org>
> > > > > > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > > > > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>>No, the container is NOT buggy, because it's simply
> > > > > > > > > >>>NOT
> > > > defined!
> > > > > > > > > >>>That's the whole mess about JNDI...
> > > > > > > > > >>>
> > > > > > > > > >>>LieGrue,
> > > > > > > > > >>>strub
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>>>________________________________
> > > > > > > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > > > > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > > > > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > > > >>>>features
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>So this container is buggy, report an issue ;)
> > > > > > > > > >>>>Thinking of it this jndi path issue couldnt be
> > > > > > > > > >>>>resolved by
> > > > > > > > > configresolvers in ds?
> > > > > > > > > >>>>- Romain
> > > > > > > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg"
> > > > > > > > > >>>><st...@yahoo.de> a
> > > > > > écrit :
> > > > > > > > > >>>>
> > > > > > > > > >>>>yes, that crashes the container...
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>>________________________________
> > > > > > > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > > > > > > deltaspike-dev@incubator.apache.org
> > > > > > > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > > > > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > > > >>>>>>features
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>>Mark, did you try providing a name starting with
> java:?
> > > > > > > > > >>>>>>- Romain
> > > > > > > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg"
> > > > > > > > > >>>>>><st...@yahoo.de> a
> > > > > > > écrit :
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > > > > > > >>>>>>> <local-tx-datasource>
> > > > > > > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > > > > > > >>>>>>>
> > > > > > > > > <connection-url>jdbc:postgresql://someserver:5432/someDb
> > > > > > > > > </
> > > > > > > > > co
> > > > > > > > > nn
> > > > > > > > > ec
> > > > > > > > > ti
> > > > > > > > > on
> > > > > > > > > -u
> > > > > > > > > rl>
> > > > > > > > > >>>>>>> <user-name>user</user-name>
> > > > > > > > > >>>>>>> <password>pwd</password>
> > > > > > > > > >>>>>>>
> > > > > > > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > > > > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>This will create the following JNDI location in
> > > JBossAS5:
> > > > > > > > > >>>>>>>java:/myDS
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > > > > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY
> > > > > > > > > >>>>>>>different in JBossAS6, AS7, Glassfish,
> > > > > > > > > TomEE, etc
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>Thus: which JNDI location would you configure in
> > > > > > > > > >>>>>>>your
> > > > > > > > > persistence.xml?
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>That's the reason why we came up with the
> > > > > > > ConfigurableDataSource.
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>Of course, we need to extend this concept and
> > > > > > > > > >>>>>>>create a
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > > > > > > ConfigurableDataSource, XaDataSource {}
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>See what I mean?
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>LieGrue,
> > > > > > > > > >>>>>>>strub
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>----- Original Message -----
> > > > > > > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > > > > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark
> > > > > > > > > >>>>>>>> Struberg <
> > > > > > > > > struberg@yahoo.de>
> > > > > > > > > >>>>>>>> Cc:
> > > > > > > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > > > > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > > > >>>>>>>> features
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>>>> In plain Tomcat or Jetty servers this needs
> > > > > > > > > >>>>>>>>>> to be configured in a
> > > > > > > > > container-specific way.
> > > > > > > > > >>>>>>>>> The problem with the container specific stuff
> > > > > > > > > >>>>>>>>> is that every
> > > > > > > > > container
> > > > > > > > > >>>>>>>> serves the xml configured datasource on a
> > > > > > > > > >>>>>>>> different location in
> > > > > > > > > JNDI! So you
> > > > > > > > > >>>>>>>> cannot provide a container independent
> > > > > > > > > >>>>>>>> implementation that way :/
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> The portable way would be to declare your
> > > > > > > > > >>>>>>>> datasource properly via
> > > > > > > > > >>>>>>>> @Resource(name="java:app/Foo",
> > > > > > > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> Most servers can map those references with
> > > > > > > > > >>>>>>>> little to no
> > > > > > > config.
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> -David
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
AW: AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
features
Posted by Arne Limburg <ar...@openknowledge.de>.
Several persistence units should be distinguished via qualifiers like CoDI does:
public class MyJpaConfig {
@Produces
@Users
@NonJtaDataSource
@Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
public String getIntegrationTestDataSource() {
...
}
@Produces
@Common
@NonJtaDataSource
@Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
public String getIntegrationTestDataSource() {
...
}
}
Should we do a default-matching between the name of the qualifier and the persistence-unit name? I.e. the above would correspond to the following two persistence units:
<persistence-unit name="users">...</persistence-unit>
<persistence-unit name="common">...</persistence-unit>
- Arne
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Sonntag, 6. Mai 2012 16:20
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
That's cool but IMO it should be in the spec and not in DS.
Moreover you need a name if you have several datasources.
- Romain
Le 6 mai 2012 16:17, "Arne Limburg" <ar...@openknowledge.de> a écrit :
> Never mind ;-)
> Maybe it is better to provide qualifiers for all the JPA properties?
> Like
> this:
>
> public class MyJpaConfig {
>
> @Produces
> @NonJtaDataSource
> @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> public String getIntegrationTestDataSource() {
> ...
> }
>
> @Produces
> @TransactionType
> @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> public String getDevelopmentTransactionType() {
> ...
> }
>
> @Produces
> @JdbcUrl
> @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> public String getDevelopmentJdbcUrl() {
> ...
> }
> }
>
> Then we can feed the createEntityManager method with this properties...
>
> - Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 16:10
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> features
>
> Yep but an em needs an emf ;)
> Le 6 mai 2012 16:05, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > OK, I think, this is not correct since it expresses a dependency to
> > an EntityManager and not to an EntityManagerFactory (in opposition
> > to @PersistenceUnit).
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 16:00
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> > features
> >
> > It tomee we create the entitymanagerfactory associated.
> > Le 6 mai 2012 15:53, "Arne Limburg" <ar...@openknowledge.de>
> > a écrit :
> >
> > > OK and the meaning of this annotation at class-level would be:
> > > "a dependency on a container-managed entity manager and its
> > > associated persistence context." That's perfectly the semantics we
> > > need ;-)
> > >
> > > But what would a jee container do when he observes such annotation
> > > at class-level? I can't read it from the spec...
> > > I think, we have to try... Or does someone at this list know?
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 15:49
> > > An: deltaspike-dev@incubator.apache.org
> > > Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> > > features
> > >
> > > The container will scan persistencecontext annotation with no link
> > > with cdi.
> > > Le 6 mai 2012 15:46, "Arne Limburg"
> > > <ar...@openknowledge.de> a écrit :
> > >
> > > > If so, what would be the semantic of such definition?
> > > > Btw. that classes would only become CDI beans when the
> > > > deployment is in the correct project stage. Otherwise we would
> > > > veto them away, before they become beans...
> > > > And, which part of the jee container would scan that class? My
> > > > guess is, that it would be the responsibility of the CDI
> implementation.
> > > > And
> > > > - just a second guess - they ignore it...
> > > >
> > > > I'll take a look into the JPA spec to see what the official
> > > > semantic of the usage I proposed would be. But, I am afraid that
> > > > this is underspecified...
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > Gesendet: Sonntag, 6. Mai 2012 15:40
> > > > An: deltaspike-dev@incubator.apache.org
> > > > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> > > > features
> > > >
> > > > Cdi is in jee so jee containers scans cdi beans and same for
> > > > resources (@persistencontext).
> > > > Le 6 mai 2012 15:36, "Arne Limburg"
> > > > <ar...@openknowledge.de> a écrit :
> > > >
> > > > > If not, we can use other annotations, but I think jee
> > > > > containers just scan EJBs...
> > > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > Gesendet: Sonntag, 6. Mai 2012 15:28
> > > > > An: deltaspike-dev@incubator.apache.org
> > > > > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
> > > > >
> > > > > Not sure it works in a jee container.
> > > > >
> > > > > - Romain
> > > > > Le 6 mai 2012 15:26, "Arne Limburg"
> > > > > <ar...@openknowledge.de> a écrit :
> > > > >
> > > > > > You could configure your production jta-datasource in the
> > > > > > persistence.xml and add the following bean to your test
> deployment:
> > > > > >
> > > > > > @Exclude(exceptIfProjectStage =
> > > > > > ProjectStage.IntegrationTest.class)
> > > > > > @PersistenceContext(unitName = "myPU", properties =
> > > > > > @PersistenceProperty(name =
> > > > > > "javax.persistence.nonJtaDataSource",
> > > > > > value =
> > > > > > "java:/comp/env/myDS"))
> > > > > > public class MyIntegrationTestConfiguration { }
> > > > > >
> > > > > > For local testing, you could even switch off JNDI:
> > > > > > @Exclude(exceptIfProjectStage =
> > > > > > ProjectStage.Development.class) @PersistenceContext(unitName
> > > > > > = "myPU", properties = {@PersistenceProperty(name =
> > > > > > "javax.persistence.transactionType",
> > > > > > value = "RESOURCE_LOCAL"),
> > > > > >
> > > > > > @PersistenceProperty(name =
> > > > > > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"),
> > > > > > ...}) public class MyDevelopmentConfiguration { }
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > Romain,
> > > > > > Noone needs to repackage his application, since we can put
> > > > > > this properties into a map and use it as the second
> > > > > > parameter of
> > > > > emf.createEntityManager...
> > > > > >
> > > > > > - Arne
> > > > > >
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > > Gesendet: Sonntag, 6. Mai 2012 15:14
> > > > > > An: deltaspike-dev@incubator.apache.org
> > > > > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> > > > > >
> > > > > > How do you manage it from persistence.xml if you dont
> > > > > > repackage your archive as Mark said?
> > > > > >
> > > > > > Personally i agree ;)
> > > > > >
> > > > > > - Romain
> > > > > > Le 6 mai 2012 15:06, "Arne Limburg"
> > > > > > <ar...@openknowledge.de> a écrit :
> > > > > >
> > > > > > > OK,
> > > > > > > but do we really need a container-independent way for
> > > > JNDI-DataSources?
> > > > > > > What's the use case for it?
> > > > > > > The user always knows his container and thus his specific
> > > JNDI-name.
> > > > > > >
> > > > > > > I think we need an easy way for users to configure
> > > > > > > different JNDI-DataSources for different deployment
> > > > > > > scenarios, like
> > > > > > > - a JTA-datasource for my JBoss AS 7 in production
> > > > > > > - a Non-JTA-datasource from another JNDI-location for the
> > > > > > > Tomcat for testing
> > > > > > > - a RESOURCE_LOCAL EntityManager for local testing...
> > > > > > >
> > > > > > > We need to find an easy way for the users to configure the
> > > > > > > JNDI-location, but imho we don't need to handle different
> > > > > > > JNDI-locations
> > > > > > in our code?
> > > > > > >
> > > > > > > WDYT? Am I missing a use case?
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Arne
> > > > > > >
> > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > > > > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > > > > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >
> > > > > > > ConfigurableDataSource doesnt solve it. If you build the
> > > > > > > emf from persistence info you manage it yourself. It
> > > > > > > should be IMO a compatibility mode and spec you be fixed.
> > > > > > >
> > > > > > > But well, the most important subjects are not here,
> > > > > > > pagination, dynamic dao etc are really more valuable.
> > > > > > >
> > > > > > > - Romain
> > > > > > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a
> > écrit :
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > The problem here is that this is NOT under our control -
> > > > > > > > this is not even CDI related!
> > > > > > > >
> > > > > > > > You need to _exactly_ specify the JNDI location in your
> > > > > > persistence.xml.
> > > > > > > > And this info get's parsed by JPA or the EE container at
> > > > > > > > deploy
> > > > time.
> > > > > > > >
> > > > > > > >
> > > > > > > > Maybe there's a trick with a PersistenceUnitInfo. But
> > > > > > > > since those are also managed by the server (and thus
> > > > > > > > show the same unspecified
> > > > > > > > behaviour) we imo cannot leverage those.
> > > > > > > >
> > > > > > > > LieGrue,
> > > > > > > > strub
> > > > > > > >
> > > > > > > >
> > > > > > > > >________________________________
> > > > > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > > > > > deltaspike-dev@incubator.apache.org
> > > > > > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > > > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >I understand. On another side how many differeny
> > > > > > > > >locations are
> > > > > there?
> > > > > > > > Isnt it manageable?
> > > > > > > > >- Romain
> > > > > > > > >Le 6 mai 2012 14:29, "Mark Struberg"
> > > > > > > > ><st...@yahoo.de> a écrit
> > > > :
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >>
> > > > > > > > >>PS: I _fully_ agree that this mess should best get
> > > > > > > > >>fixed in
> > > EE7.
> > > > > > > > >>But
> > > > > > > > sadly we also need to support older containers!
> > > > > > > > >>
> > > > > > > > >>I know about folks who have OWB and CODI running on
> > > > > > > > >>old WebSphere
> > > > > > > > >>6 and
> > > > > > > > 7 servers. And others who use OWB on WebLogic 10.3. And
> > > > > > > > those companies are big banks, stock exchanges and
> > > > > > > > insurrance companies
> > > > > > > > - they cannot easily upgrade to a new server...
> > > > > > > > >>
> > > > > > > > >>LieGrue,
> > > > > > > > >>strub
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>>________________________________
> > > > > > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > > > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>;
> > > > > > > > >>>deltaspike <
> > > > > > > > deltaspike-dev@incubator.apache.org>
> > > > > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > > > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>No, the container is NOT buggy, because it's simply
> > > > > > > > >>>NOT
> > > defined!
> > > > > > > > >>>That's the whole mess about JNDI...
> > > > > > > > >>>
> > > > > > > > >>>LieGrue,
> > > > > > > > >>>strub
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>>________________________________
> > > > > > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > > > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > > > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > > >>>>features
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>So this container is buggy, report an issue ;)
> > > > > > > > >>>>Thinking of it this jndi path issue couldnt be
> > > > > > > > >>>>resolved by
> > > > > > > > configresolvers in ds?
> > > > > > > > >>>>- Romain
> > > > > > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg"
> > > > > > > > >>>><st...@yahoo.de> a
> > > > > écrit :
> > > > > > > > >>>>
> > > > > > > > >>>>yes, that crashes the container...
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>>>________________________________
> > > > > > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > > > > > deltaspike-dev@incubator.apache.org
> > > > > > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > > > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > > >>>>>>features
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>Mark, did you try providing a name starting with java:?
> > > > > > > > >>>>>>- Romain
> > > > > > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg"
> > > > > > > > >>>>>><st...@yahoo.de> a
> > > > > > écrit :
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > > > > > >>>>>>> <local-tx-datasource>
> > > > > > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > > > > > >>>>>>>
> > > > > > > > <connection-url>jdbc:postgresql://someserver:5432/someDb
> > > > > > > > </
> > > > > > > > co
> > > > > > > > nn
> > > > > > > > ec
> > > > > > > > ti
> > > > > > > > on
> > > > > > > > -u
> > > > > > > > rl>
> > > > > > > > >>>>>>> <user-name>user</user-name>
> > > > > > > > >>>>>>> <password>pwd</password>
> > > > > > > > >>>>>>>
> > > > > > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > > > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>This will create the following JNDI location in
> > JBossAS5:
> > > > > > > > >>>>>>>java:/myDS
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > > > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY
> > > > > > > > >>>>>>>different in JBossAS6, AS7, Glassfish,
> > > > > > > > TomEE, etc
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>Thus: which JNDI location would you configure in
> > > > > > > > >>>>>>>your
> > > > > > > > persistence.xml?
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>That's the reason why we came up with the
> > > > > > ConfigurableDataSource.
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>Of course, we need to extend this concept and
> > > > > > > > >>>>>>>create a
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > > > > > ConfigurableDataSource, XaDataSource {}
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>See what I mean?
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>LieGrue,
> > > > > > > > >>>>>>>strub
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>----- Original Message -----
> > > > > > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > > > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark
> > > > > > > > >>>>>>>> Struberg <
> > > > > > > > struberg@yahoo.de>
> > > > > > > > >>>>>>>> Cc:
> > > > > > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > > > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > > >>>>>>>> features
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>>> In plain Tomcat or Jetty servers this needs
> > > > > > > > >>>>>>>>>> to be configured in a
> > > > > > > > container-specific way.
> > > > > > > > >>>>>>>>> The problem with the container specific stuff
> > > > > > > > >>>>>>>>> is that every
> > > > > > > > container
> > > > > > > > >>>>>>>> serves the xml configured datasource on a
> > > > > > > > >>>>>>>> different location in
> > > > > > > > JNDI! So you
> > > > > > > > >>>>>>>> cannot provide a container independent
> > > > > > > > >>>>>>>> implementation that way :/
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> The portable way would be to declare your
> > > > > > > > >>>>>>>> datasource properly via
> > > > > > > > >>>>>>>> @Resource(name="java:app/Foo",
> > > > > > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> Most servers can map those references with
> > > > > > > > >>>>>>>> little to no
> > > > > > config.
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> -David
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
That's cool but IMO it should be in the spec and not in DS.
Moreover you need a name if you have several datasources.
- Romain
Le 6 mai 2012 16:17, "Arne Limburg" <ar...@openknowledge.de> a
écrit :
> Never mind ;-)
> Maybe it is better to provide qualifiers for all the JPA properties? Like
> this:
>
> public class MyJpaConfig {
>
> @Produces
> @NonJtaDataSource
> @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> public String getIntegrationTestDataSource() {
> ...
> }
>
> @Produces
> @TransactionType
> @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> public String getDevelopmentTransactionType() {
> ...
> }
>
> @Produces
> @JdbcUrl
> @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> public String getDevelopmentJdbcUrl() {
> ...
> }
> }
>
> Then we can feed the createEntityManager method with this properties...
>
> - Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 16:10
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> features
>
> Yep but an em needs an emf ;)
> Le 6 mai 2012 16:05, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > OK, I think, this is not correct since it expresses a dependency to an
> > EntityManager and not to an EntityManagerFactory (in opposition to
> > @PersistenceUnit).
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 16:00
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> > features
> >
> > It tomee we create the entitymanagerfactory associated.
> > Le 6 mai 2012 15:53, "Arne Limburg" <ar...@openknowledge.de> a
> > écrit :
> >
> > > OK and the meaning of this annotation at class-level would be:
> > > "a dependency on a container-managed entity manager and its
> > > associated persistence context." That's perfectly the semantics we
> > > need ;-)
> > >
> > > But what would a jee container do when he observes such annotation
> > > at class-level? I can't read it from the spec...
> > > I think, we have to try... Or does someone at this list know?
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 15:49
> > > An: deltaspike-dev@incubator.apache.org
> > > Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> > > features
> > >
> > > The container will scan persistencecontext annotation with no link
> > > with cdi.
> > > Le 6 mai 2012 15:46, "Arne Limburg" <ar...@openknowledge.de>
> > > a écrit :
> > >
> > > > If so, what would be the semantic of such definition?
> > > > Btw. that classes would only become CDI beans when the deployment
> > > > is in the correct project stage. Otherwise we would veto them
> > > > away, before they become beans...
> > > > And, which part of the jee container would scan that class? My
> > > > guess is, that it would be the responsibility of the CDI
> implementation.
> > > > And
> > > > - just a second guess - they ignore it...
> > > >
> > > > I'll take a look into the JPA spec to see what the official
> > > > semantic of the usage I proposed would be. But, I am afraid that
> > > > this is underspecified...
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > Gesendet: Sonntag, 6. Mai 2012 15:40
> > > > An: deltaspike-dev@incubator.apache.org
> > > > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
> > > >
> > > > Cdi is in jee so jee containers scans cdi beans and same for
> > > > resources (@persistencontext).
> > > > Le 6 mai 2012 15:36, "Arne Limburg"
> > > > <ar...@openknowledge.de> a écrit :
> > > >
> > > > > If not, we can use other annotations, but I think jee containers
> > > > > just scan EJBs...
> > > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > Gesendet: Sonntag, 6. Mai 2012 15:28
> > > > > An: deltaspike-dev@incubator.apache.org
> > > > > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
> > > > >
> > > > > Not sure it works in a jee container.
> > > > >
> > > > > - Romain
> > > > > Le 6 mai 2012 15:26, "Arne Limburg"
> > > > > <ar...@openknowledge.de> a écrit :
> > > > >
> > > > > > You could configure your production jta-datasource in the
> > > > > > persistence.xml and add the following bean to your test
> deployment:
> > > > > >
> > > > > > @Exclude(exceptIfProjectStage =
> > > > > > ProjectStage.IntegrationTest.class)
> > > > > > @PersistenceContext(unitName = "myPU", properties =
> > > > > > @PersistenceProperty(name =
> > > > > > "javax.persistence.nonJtaDataSource",
> > > > > > value =
> > > > > > "java:/comp/env/myDS"))
> > > > > > public class MyIntegrationTestConfiguration { }
> > > > > >
> > > > > > For local testing, you could even switch off JNDI:
> > > > > > @Exclude(exceptIfProjectStage =
> > > > > > ProjectStage.Development.class) @PersistenceContext(unitName =
> > > > > > "myPU", properties = {@PersistenceProperty(name =
> > > > > > "javax.persistence.transactionType",
> > > > > > value = "RESOURCE_LOCAL"),
> > > > > >
> > > > > > @PersistenceProperty(name =
> > > > > > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"),
> > > > > > ...}) public class MyDevelopmentConfiguration { }
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > Romain,
> > > > > > Noone needs to repackage his application, since we can put
> > > > > > this properties into a map and use it as the second parameter
> > > > > > of
> > > > > emf.createEntityManager...
> > > > > >
> > > > > > - Arne
> > > > > >
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > > Gesendet: Sonntag, 6. Mai 2012 15:14
> > > > > > An: deltaspike-dev@incubator.apache.org
> > > > > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> > > > > >
> > > > > > How do you manage it from persistence.xml if you dont
> > > > > > repackage your archive as Mark said?
> > > > > >
> > > > > > Personally i agree ;)
> > > > > >
> > > > > > - Romain
> > > > > > Le 6 mai 2012 15:06, "Arne Limburg"
> > > > > > <ar...@openknowledge.de> a écrit :
> > > > > >
> > > > > > > OK,
> > > > > > > but do we really need a container-independent way for
> > > > JNDI-DataSources?
> > > > > > > What's the use case for it?
> > > > > > > The user always knows his container and thus his specific
> > > JNDI-name.
> > > > > > >
> > > > > > > I think we need an easy way for users to configure different
> > > > > > > JNDI-DataSources for different deployment scenarios, like
> > > > > > > - a JTA-datasource for my JBoss AS 7 in production
> > > > > > > - a Non-JTA-datasource from another JNDI-location for the
> > > > > > > Tomcat for testing
> > > > > > > - a RESOURCE_LOCAL EntityManager for local testing...
> > > > > > >
> > > > > > > We need to find an easy way for the users to configure the
> > > > > > > JNDI-location, but imho we don't need to handle different
> > > > > > > JNDI-locations
> > > > > > in our code?
> > > > > > >
> > > > > > > WDYT? Am I missing a use case?
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Arne
> > > > > > >
> > > > > > > -----Ursprüngliche Nachricht-----
> > > > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > > > > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > > > > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >
> > > > > > > ConfigurableDataSource doesnt solve it. If you build the emf
> > > > > > > from persistence info you manage it yourself. It should be
> > > > > > > IMO a compatibility mode and spec you be fixed.
> > > > > > >
> > > > > > > But well, the most important subjects are not here,
> > > > > > > pagination, dynamic dao etc are really more valuable.
> > > > > > >
> > > > > > > - Romain
> > > > > > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a
> > écrit :
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > The problem here is that this is NOT under our control -
> > > > > > > > this is not even CDI related!
> > > > > > > >
> > > > > > > > You need to _exactly_ specify the JNDI location in your
> > > > > > persistence.xml.
> > > > > > > > And this info get's parsed by JPA or the EE container at
> > > > > > > > deploy
> > > > time.
> > > > > > > >
> > > > > > > >
> > > > > > > > Maybe there's a trick with a PersistenceUnitInfo. But
> > > > > > > > since those are also managed by the server (and thus show
> > > > > > > > the same unspecified
> > > > > > > > behaviour) we imo cannot leverage those.
> > > > > > > >
> > > > > > > > LieGrue,
> > > > > > > > strub
> > > > > > > >
> > > > > > > >
> > > > > > > > >________________________________
> > > > > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > > > > > deltaspike-dev@incubator.apache.org
> > > > > > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > > > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >I understand. On another side how many differeny
> > > > > > > > >locations are
> > > > > there?
> > > > > > > > Isnt it manageable?
> > > > > > > > >- Romain
> > > > > > > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de>
> > > > > > > > >a écrit
> > > > :
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >>
> > > > > > > > >>PS: I _fully_ agree that this mess should best get fixed
> > > > > > > > >>in
> > > EE7.
> > > > > > > > >>But
> > > > > > > > sadly we also need to support older containers!
> > > > > > > > >>
> > > > > > > > >>I know about folks who have OWB and CODI running on old
> > > > > > > > >>WebSphere
> > > > > > > > >>6 and
> > > > > > > > 7 servers. And others who use OWB on WebLogic 10.3. And
> > > > > > > > those companies are big banks, stock exchanges and
> > > > > > > > insurrance companies
> > > > > > > > - they cannot easily upgrade to a new server...
> > > > > > > > >>
> > > > > > > > >>LieGrue,
> > > > > > > > >>strub
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>>________________________________
> > > > > > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > > > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>;
> > > > > > > > >>>deltaspike <
> > > > > > > > deltaspike-dev@incubator.apache.org>
> > > > > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > > > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>No, the container is NOT buggy, because it's simply NOT
> > > defined!
> > > > > > > > >>>That's the whole mess about JNDI...
> > > > > > > > >>>
> > > > > > > > >>>LieGrue,
> > > > > > > > >>>strub
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>>________________________________
> > > > > > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > > > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > > > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>So this container is buggy, report an issue ;)
> > > > > > > > >>>>Thinking of it this jndi path issue couldnt be
> > > > > > > > >>>>resolved by
> > > > > > > > configresolvers in ds?
> > > > > > > > >>>>- Romain
> > > > > > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg"
> > > > > > > > >>>><st...@yahoo.de> a
> > > > > écrit :
> > > > > > > > >>>>
> > > > > > > > >>>>yes, that crashes the container...
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>>>________________________________
> > > > > > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > > > > > deltaspike-dev@incubator.apache.org
> > > > > > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > > > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > > >>>>>>features
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>Mark, did you try providing a name starting with java:?
> > > > > > > > >>>>>>- Romain
> > > > > > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg"
> > > > > > > > >>>>>><st...@yahoo.de> a
> > > > > > écrit :
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > > > > > >>>>>>> <local-tx-datasource>
> > > > > > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > > > > > >>>>>>>
> > > > > > > > <connection-url>jdbc:postgresql://someserver:5432/someDb</
> > > > > > > > co
> > > > > > > > nn
> > > > > > > > ec
> > > > > > > > ti
> > > > > > > > on
> > > > > > > > -u
> > > > > > > > rl>
> > > > > > > > >>>>>>> <user-name>user</user-name>
> > > > > > > > >>>>>>> <password>pwd</password>
> > > > > > > > >>>>>>>
> > > > > > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > > > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>This will create the following JNDI location in
> > JBossAS5:
> > > > > > > > >>>>>>>java:/myDS
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > > > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY
> > > > > > > > >>>>>>>different in JBossAS6, AS7, Glassfish,
> > > > > > > > TomEE, etc
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>Thus: which JNDI location would you configure in
> > > > > > > > >>>>>>>your
> > > > > > > > persistence.xml?
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>That's the reason why we came up with the
> > > > > > ConfigurableDataSource.
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>Of course, we need to extend this concept and
> > > > > > > > >>>>>>>create a
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > > > > > ConfigurableDataSource, XaDataSource {}
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>See what I mean?
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>LieGrue,
> > > > > > > > >>>>>>>strub
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>----- Original Message -----
> > > > > > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > > > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark
> > > > > > > > >>>>>>>> Struberg <
> > > > > > > > struberg@yahoo.de>
> > > > > > > > >>>>>>>> Cc:
> > > > > > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > > > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > > >>>>>>>> features
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>>> In plain Tomcat or Jetty servers this needs
> > > > > > > > >>>>>>>>>> to be configured in a
> > > > > > > > container-specific way.
> > > > > > > > >>>>>>>>> The problem with the container specific stuff
> > > > > > > > >>>>>>>>> is that every
> > > > > > > > container
> > > > > > > > >>>>>>>> serves the xml configured datasource on a
> > > > > > > > >>>>>>>> different location in
> > > > > > > > JNDI! So you
> > > > > > > > >>>>>>>> cannot provide a container independent
> > > > > > > > >>>>>>>> implementation that way :/
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> The portable way would be to declare your
> > > > > > > > >>>>>>>> datasource properly via
> > > > > > > > >>>>>>>> @Resource(name="java:app/Foo",
> > > > > > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> Most servers can map those references with little
> > > > > > > > >>>>>>>> to no
> > > > > > config.
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> -David
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
AW: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Arne Limburg <ar...@openknowledge.de>.
Never mind ;-)
Maybe it is better to provide qualifiers for all the JPA properties? Like this:
public class MyJpaConfig {
@Produces
@NonJtaDataSource
@Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
public String getIntegrationTestDataSource() {
...
}
@Produces
@TransactionType
@Exclude(exceptIfProjectStage = ProjectStage.Development.class)
public String getDevelopmentTransactionType() {
...
}
@Produces
@JdbcUrl
@Exclude(exceptIfProjectStage = ProjectStage.Development.class)
public String getDevelopmentJdbcUrl() {
...
}
}
Then we can feed the createEntityManager method with this properties...
- Arne
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Sonntag, 6. Mai 2012 16:10
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Yep but an em needs an emf ;)
Le 6 mai 2012 16:05, "Arne Limburg" <ar...@openknowledge.de> a écrit :
> OK, I think, this is not correct since it expresses a dependency to an
> EntityManager and not to an EntityManagerFactory (in opposition to
> @PersistenceUnit).
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 16:00
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> features
>
> It tomee we create the entitymanagerfactory associated.
> Le 6 mai 2012 15:53, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > OK and the meaning of this annotation at class-level would be:
> > "a dependency on a container-managed entity manager and its
> > associated persistence context." That's perfectly the semantics we
> > need ;-)
> >
> > But what would a jee container do when he observes such annotation
> > at class-level? I can't read it from the spec...
> > I think, we have to try... Or does someone at this list know?
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 15:49
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module
> > features
> >
> > The container will scan persistencecontext annotation with no link
> > with cdi.
> > Le 6 mai 2012 15:46, "Arne Limburg" <ar...@openknowledge.de>
> > a écrit :
> >
> > > If so, what would be the semantic of such definition?
> > > Btw. that classes would only become CDI beans when the deployment
> > > is in the correct project stage. Otherwise we would veto them
> > > away, before they become beans...
> > > And, which part of the jee container would scan that class? My
> > > guess is, that it would be the responsibility of the CDI implementation.
> > > And
> > > - just a second guess - they ignore it...
> > >
> > > I'll take a look into the JPA spec to see what the official
> > > semantic of the usage I proposed would be. But, I am afraid that
> > > this is underspecified...
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 15:40
> > > An: deltaspike-dev@incubator.apache.org
> > > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
> > >
> > > Cdi is in jee so jee containers scans cdi beans and same for
> > > resources (@persistencontext).
> > > Le 6 mai 2012 15:36, "Arne Limburg"
> > > <ar...@openknowledge.de> a écrit :
> > >
> > > > If not, we can use other annotations, but I think jee containers
> > > > just scan EJBs...
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > Gesendet: Sonntag, 6. Mai 2012 15:28
> > > > An: deltaspike-dev@incubator.apache.org
> > > > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
> > > >
> > > > Not sure it works in a jee container.
> > > >
> > > > - Romain
> > > > Le 6 mai 2012 15:26, "Arne Limburg"
> > > > <ar...@openknowledge.de> a écrit :
> > > >
> > > > > You could configure your production jta-datasource in the
> > > > > persistence.xml and add the following bean to your test deployment:
> > > > >
> > > > > @Exclude(exceptIfProjectStage =
> > > > > ProjectStage.IntegrationTest.class)
> > > > > @PersistenceContext(unitName = "myPU", properties =
> > > > > @PersistenceProperty(name =
> > > > > "javax.persistence.nonJtaDataSource",
> > > > > value =
> > > > > "java:/comp/env/myDS"))
> > > > > public class MyIntegrationTestConfiguration { }
> > > > >
> > > > > For local testing, you could even switch off JNDI:
> > > > > @Exclude(exceptIfProjectStage =
> > > > > ProjectStage.Development.class) @PersistenceContext(unitName =
> > > > > "myPU", properties = {@PersistenceProperty(name =
> > > > > "javax.persistence.transactionType",
> > > > > value = "RESOURCE_LOCAL"),
> > > > >
> > > > > @PersistenceProperty(name =
> > > > > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"),
> > > > > ...}) public class MyDevelopmentConfiguration { }
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Romain,
> > > > > Noone needs to repackage his application, since we can put
> > > > > this properties into a map and use it as the second parameter
> > > > > of
> > > > emf.createEntityManager...
> > > > >
> > > > > - Arne
> > > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > Gesendet: Sonntag, 6. Mai 2012 15:14
> > > > > An: deltaspike-dev@incubator.apache.org
> > > > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> > > > >
> > > > > How do you manage it from persistence.xml if you dont
> > > > > repackage your archive as Mark said?
> > > > >
> > > > > Personally i agree ;)
> > > > >
> > > > > - Romain
> > > > > Le 6 mai 2012 15:06, "Arne Limburg"
> > > > > <ar...@openknowledge.de> a écrit :
> > > > >
> > > > > > OK,
> > > > > > but do we really need a container-independent way for
> > > JNDI-DataSources?
> > > > > > What's the use case for it?
> > > > > > The user always knows his container and thus his specific
> > JNDI-name.
> > > > > >
> > > > > > I think we need an easy way for users to configure different
> > > > > > JNDI-DataSources for different deployment scenarios, like
> > > > > > - a JTA-datasource for my JBoss AS 7 in production
> > > > > > - a Non-JTA-datasource from another JNDI-location for the
> > > > > > Tomcat for testing
> > > > > > - a RESOURCE_LOCAL EntityManager for local testing...
> > > > > >
> > > > > > We need to find an easy way for the users to configure the
> > > > > > JNDI-location, but imho we don't need to handle different
> > > > > > JNDI-locations
> > > > > in our code?
> > > > > >
> > > > > > WDYT? Am I missing a use case?
> > > > > >
> > > > > > Cheers,
> > > > > > Arne
> > > > > >
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > > > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > > > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >
> > > > > > ConfigurableDataSource doesnt solve it. If you build the emf
> > > > > > from persistence info you manage it yourself. It should be
> > > > > > IMO a compatibility mode and spec you be fixed.
> > > > > >
> > > > > > But well, the most important subjects are not here,
> > > > > > pagination, dynamic dao etc are really more valuable.
> > > > > >
> > > > > > - Romain
> > > > > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a
> écrit :
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The problem here is that this is NOT under our control -
> > > > > > > this is not even CDI related!
> > > > > > >
> > > > > > > You need to _exactly_ specify the JNDI location in your
> > > > > persistence.xml.
> > > > > > > And this info get's parsed by JPA or the EE container at
> > > > > > > deploy
> > > time.
> > > > > > >
> > > > > > >
> > > > > > > Maybe there's a trick with a PersistenceUnitInfo. But
> > > > > > > since those are also managed by the server (and thus show
> > > > > > > the same unspecified
> > > > > > > behaviour) we imo cannot leverage those.
> > > > > > >
> > > > > > > LieGrue,
> > > > > > > strub
> > > > > > >
> > > > > > >
> > > > > > > >________________________________
> > > > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > > > > deltaspike-dev@incubator.apache.org
> > > > > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > >
> > > > > > > >
> > > > > > > >I understand. On another side how many differeny
> > > > > > > >locations are
> > > > there?
> > > > > > > Isnt it manageable?
> > > > > > > >- Romain
> > > > > > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de>
> > > > > > > >a écrit
> > > :
> > > > > > > >
> > > > > > > >
> > > > > > > >>
> > > > > > > >>PS: I _fully_ agree that this mess should best get fixed
> > > > > > > >>in
> > EE7.
> > > > > > > >>But
> > > > > > > sadly we also need to support older containers!
> > > > > > > >>
> > > > > > > >>I know about folks who have OWB and CODI running on old
> > > > > > > >>WebSphere
> > > > > > > >>6 and
> > > > > > > 7 servers. And others who use OWB on WebLogic 10.3. And
> > > > > > > those companies are big banks, stock exchanges and
> > > > > > > insurrance companies
> > > > > > > - they cannot easily upgrade to a new server...
> > > > > > > >>
> > > > > > > >>LieGrue,
> > > > > > > >>strub
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>>________________________________
> > > > > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>;
> > > > > > > >>>deltaspike <
> > > > > > > deltaspike-dev@incubator.apache.org>
> > > > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>No, the container is NOT buggy, because it's simply NOT
> > defined!
> > > > > > > >>>That's the whole mess about JNDI...
> > > > > > > >>>
> > > > > > > >>>LieGrue,
> > > > > > > >>>strub
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>>________________________________
> > > > > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>So this container is buggy, report an issue ;)
> > > > > > > >>>>Thinking of it this jndi path issue couldnt be
> > > > > > > >>>>resolved by
> > > > > > > configresolvers in ds?
> > > > > > > >>>>- Romain
> > > > > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg"
> > > > > > > >>>><st...@yahoo.de> a
> > > > écrit :
> > > > > > > >>>>
> > > > > > > >>>>yes, that crashes the container...
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>>________________________________
> > > > > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > > > > deltaspike-dev@incubator.apache.org
> > > > > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > >>>>>>features
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>>Mark, did you try providing a name starting with java:?
> > > > > > > >>>>>>- Romain
> > > > > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg"
> > > > > > > >>>>>><st...@yahoo.de> a
> > > > > écrit :
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > > > > >>>>>>>
> > > > > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > > > > >>>>>>> <local-tx-datasource>
> > > > > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > > > > >>>>>>>
> > > > > > > <connection-url>jdbc:postgresql://someserver:5432/someDb</
> > > > > > > co
> > > > > > > nn
> > > > > > > ec
> > > > > > > ti
> > > > > > > on
> > > > > > > -u
> > > > > > > rl>
> > > > > > > >>>>>>> <user-name>user</user-name>
> > > > > > > >>>>>>> <password>pwd</password>
> > > > > > > >>>>>>>
> > > > > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>This will create the following JNDI location in
> JBossAS5:
> > > > > > > >>>>>>>java:/myDS
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY
> > > > > > > >>>>>>>different in JBossAS6, AS7, Glassfish,
> > > > > > > TomEE, etc
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>Thus: which JNDI location would you configure in
> > > > > > > >>>>>>>your
> > > > > > > persistence.xml?
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>That's the reason why we came up with the
> > > > > ConfigurableDataSource.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>Of course, we need to extend this concept and
> > > > > > > >>>>>>>create a
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > > > > ConfigurableDataSource, XaDataSource {}
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>See what I mean?
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>LieGrue,
> > > > > > > >>>>>>>strub
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>----- Original Message -----
> > > > > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark
> > > > > > > >>>>>>>> Struberg <
> > > > > > > struberg@yahoo.de>
> > > > > > > >>>>>>>> Cc:
> > > > > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > >>>>>>>> features
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>>> In plain Tomcat or Jetty servers this needs
> > > > > > > >>>>>>>>>> to be configured in a
> > > > > > > container-specific way.
> > > > > > > >>>>>>>>> The problem with the container specific stuff
> > > > > > > >>>>>>>>> is that every
> > > > > > > container
> > > > > > > >>>>>>>> serves the xml configured datasource on a
> > > > > > > >>>>>>>> different location in
> > > > > > > JNDI! So you
> > > > > > > >>>>>>>> cannot provide a container independent
> > > > > > > >>>>>>>> implementation that way :/
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> The portable way would be to declare your
> > > > > > > >>>>>>>> datasource properly via
> > > > > > > >>>>>>>> @Resource(name="java:app/Foo",
> > > > > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> Most servers can map those references with little
> > > > > > > >>>>>>>> to no
> > > > > config.
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> -David
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
http://docs.oracle.com/cd/B31017_01/web.1013/b28221/usclient005.htm it
explains this usage...IMO it doesnt change a lot the issue
Le 6 mai 2012 16:09, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
> Yep but an em needs an emf ;)
> Le 6 mai 2012 16:05, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
>> OK, I think, this is not correct since it expresses a dependency to an
>> EntityManager and not to an EntityManagerFactory (in opposition to
>> @PersistenceUnit).
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> Gesendet: Sonntag, 6. Mai 2012 16:00
>> An: deltaspike-dev@incubator.apache.org
>> Betreff: Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>>
>> It tomee we create the entitymanagerfactory associated.
>> Le 6 mai 2012 15:53, "Arne Limburg" <ar...@openknowledge.de> a
>> écrit :
>>
>> > OK and the meaning of this annotation at class-level would be:
>> > "a dependency on a container-managed entity manager and its associated
>> > persistence context." That's perfectly the semantics we need ;-)
>> >
>> > But what would a jee container do when he observes such annotation at
>> > class-level? I can't read it from the spec...
>> > I think, we have to try... Or does someone at this list know?
>> >
>> > -----Ursprüngliche Nachricht-----
>> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > Gesendet: Sonntag, 6. Mai 2012 15:49
>> > An: deltaspike-dev@incubator.apache.org
>> > Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>> >
>> > The container will scan persistencecontext annotation with no link
>> > with cdi.
>> > Le 6 mai 2012 15:46, "Arne Limburg" <ar...@openknowledge.de> a
>> > écrit :
>> >
>> > > If so, what would be the semantic of such definition?
>> > > Btw. that classes would only become CDI beans when the deployment is
>> > > in the correct project stage. Otherwise we would veto them away,
>> > > before they become beans...
>> > > And, which part of the jee container would scan that class? My guess
>> > > is, that it would be the responsibility of the CDI implementation.
>> > > And
>> > > - just a second guess - they ignore it...
>> > >
>> > > I'll take a look into the JPA spec to see what the official semantic
>> > > of the usage I proposed would be. But, I am afraid that this is
>> > > underspecified...
>> > >
>> > > -----Ursprüngliche Nachricht-----
>> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > > Gesendet: Sonntag, 6. Mai 2012 15:40
>> > > An: deltaspike-dev@incubator.apache.org
>> > > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>> > >
>> > > Cdi is in jee so jee containers scans cdi beans and same for
>> > > resources (@persistencontext).
>> > > Le 6 mai 2012 15:36, "Arne Limburg" <ar...@openknowledge.de>
>> > > a écrit :
>> > >
>> > > > If not, we can use other annotations, but I think jee containers
>> > > > just scan EJBs...
>> > > >
>> > > > -----Ursprüngliche Nachricht-----
>> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > > > Gesendet: Sonntag, 6. Mai 2012 15:28
>> > > > An: deltaspike-dev@incubator.apache.org
>> > > > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
>> > > >
>> > > > Not sure it works in a jee container.
>> > > >
>> > > > - Romain
>> > > > Le 6 mai 2012 15:26, "Arne Limburg"
>> > > > <ar...@openknowledge.de> a écrit :
>> > > >
>> > > > > You could configure your production jta-datasource in the
>> > > > > persistence.xml and add the following bean to your test
>> deployment:
>> > > > >
>> > > > > @Exclude(exceptIfProjectStage =
>> > > > > ProjectStage.IntegrationTest.class)
>> > > > > @PersistenceContext(unitName = "myPU", properties =
>> > > > > @PersistenceProperty(name =
>> > > > > "javax.persistence.nonJtaDataSource",
>> > > > > value =
>> > > > > "java:/comp/env/myDS"))
>> > > > > public class MyIntegrationTestConfiguration { }
>> > > > >
>> > > > > For local testing, you could even switch off JNDI:
>> > > > > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
>> > > > > @PersistenceContext(unitName = "myPU", properties =
>> > > > > {@PersistenceProperty(name =
>> > > > > "javax.persistence.transactionType",
>> > > > > value = "RESOURCE_LOCAL"),
>> > > > >
>> > > > > @PersistenceProperty(name =
>> > > > > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
>> > > > > public class MyDevelopmentConfiguration { }
>> > > > >
>> > > > > WDYT?
>> > > > >
>> > > > > Romain,
>> > > > > Noone needs to repackage his application, since we can put this
>> > > > > properties into a map and use it as the second parameter of
>> > > > emf.createEntityManager...
>> > > > >
>> > > > > - Arne
>> > > > >
>> > > > > -----Ursprüngliche Nachricht-----
>> > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > > > > Gesendet: Sonntag, 6. Mai 2012 15:14
>> > > > > An: deltaspike-dev@incubator.apache.org
>> > > > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
>> > > > >
>> > > > > How do you manage it from persistence.xml if you dont repackage
>> > > > > your archive as Mark said?
>> > > > >
>> > > > > Personally i agree ;)
>> > > > >
>> > > > > - Romain
>> > > > > Le 6 mai 2012 15:06, "Arne Limburg"
>> > > > > <ar...@openknowledge.de> a écrit :
>> > > > >
>> > > > > > OK,
>> > > > > > but do we really need a container-independent way for
>> > > JNDI-DataSources?
>> > > > > > What's the use case for it?
>> > > > > > The user always knows his container and thus his specific
>> > JNDI-name.
>> > > > > >
>> > > > > > I think we need an easy way for users to configure different
>> > > > > > JNDI-DataSources for different deployment scenarios, like
>> > > > > > - a JTA-datasource for my JBoss AS 7 in production
>> > > > > > - a Non-JTA-datasource from another JNDI-location for the
>> > > > > > Tomcat for testing
>> > > > > > - a RESOURCE_LOCAL EntityManager for local testing...
>> > > > > >
>> > > > > > We need to find an easy way for the users to configure the
>> > > > > > JNDI-location, but imho we don't need to handle different
>> > > > > > JNDI-locations
>> > > > > in our code?
>> > > > > >
>> > > > > > WDYT? Am I missing a use case?
>> > > > > >
>> > > > > > Cheers,
>> > > > > > Arne
>> > > > > >
>> > > > > > -----Ursprüngliche Nachricht-----
>> > > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > > > > > Gesendet: Sonntag, 6. Mai 2012 14:49
>> > > > > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
>> > > > > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
>> > > > > >
>> > > > > > ConfigurableDataSource doesnt solve it. If you build the emf
>> > > > > > from persistence info you manage it yourself. It should be IMO
>> > > > > > a compatibility mode and spec you be fixed.
>> > > > > >
>> > > > > > But well, the most important subjects are not here,
>> > > > > > pagination, dynamic dao etc are really more valuable.
>> > > > > >
>> > > > > > - Romain
>> > > > > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a
>> écrit :
>> > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > The problem here is that this is NOT under our control -
>> > > > > > > this is not even CDI related!
>> > > > > > >
>> > > > > > > You need to _exactly_ specify the JNDI location in your
>> > > > > persistence.xml.
>> > > > > > > And this info get's parsed by JPA or the EE container at
>> > > > > > > deploy
>> > > time.
>> > > > > > >
>> > > > > > >
>> > > > > > > Maybe there's a trick with a PersistenceUnitInfo. But since
>> > > > > > > those are also managed by the server (and thus show the same
>> > > > > > > unspecified
>> > > > > > > behaviour) we imo cannot leverage those.
>> > > > > > >
>> > > > > > > LieGrue,
>> > > > > > > strub
>> > > > > > >
>> > > > > > >
>> > > > > > > >________________________________
>> > > > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
>> > > > > > > >To: Mark Struberg <st...@yahoo.de>;
>> > > > > > > deltaspike-dev@incubator.apache.org
>> > > > > > > >Sent: Sunday, May 6, 2012 2:37 PM
>> > > > > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >I understand. On another side how many differeny locations
>> > > > > > > >are
>> > > > there?
>> > > > > > > Isnt it manageable?
>> > > > > > > >- Romain
>> > > > > > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a
>> > > > > > > >écrit
>> > > :
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >>
>> > > > > > > >>PS: I _fully_ agree that this mess should best get fixed
>> > > > > > > >>in
>> > EE7.
>> > > > > > > >>But
>> > > > > > > sadly we also need to support older containers!
>> > > > > > > >>
>> > > > > > > >>I know about folks who have OWB and CODI running on old
>> > > > > > > >>WebSphere
>> > > > > > > >>6 and
>> > > > > > > 7 servers. And others who use OWB on WebLogic 10.3. And
>> > > > > > > those companies are big banks, stock exchanges and
>> > > > > > > insurrance companies
>> > > > > > > - they cannot easily upgrade to a new server...
>> > > > > > > >>
>> > > > > > > >>LieGrue,
>> > > > > > > >>strub
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>
>> > > > > > > >>>________________________________
>> > > > > > > >>> From: Mark Struberg <st...@yahoo.de>
>> > > > > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>;
>> > > > > > > >>>deltaspike <
>> > > > > > > deltaspike-dev@incubator.apache.org>
>> > > > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
>> > > > > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>No, the container is NOT buggy, because it's simply NOT
>> > defined!
>> > > > > > > >>>That's the whole mess about JNDI...
>> > > > > > > >>>
>> > > > > > > >>>LieGrue,
>> > > > > > > >>>strub
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>>________________________________
>> > > > > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
>> > > > > > > >>>>To: Mark Struberg <st...@yahoo.de>
>> > > > > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
>> > > > > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>> > > > > > > >>>>
>> > > > > > > >>>>
>> > > > > > > >>>>So this container is buggy, report an issue ;) Thinking
>> > > > > > > >>>>of it this jndi path issue couldnt be resolved by
>> > > > > > > configresolvers in ds?
>> > > > > > > >>>>- Romain
>> > > > > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de>
>> > > > > > > >>>>a
>> > > > écrit :
>> > > > > > > >>>>
>> > > > > > > >>>>yes, that crashes the container...
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>>
>> > > > > > > >>>>>>________________________________
>> > > > > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
>> > > > > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
>> > > > > > > deltaspike-dev@incubator.apache.org
>> > > > > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
>> > > > > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>Mark, did you try providing a name starting with java:?
>> > > > > > > >>>>>>- Romain
>> > > > > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg"
>> > > > > > > >>>>>><st...@yahoo.de> a
>> > > > > écrit :
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>David, exactly this doesn't work out in practice!
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>look at jboss5 datasource xml as an example:
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
>> > > > > > > >>>>>>> <local-tx-datasource>
>> > > > > > > >>>>>>> <jndi-name>myDS</jndi-name>
>> > > > > > > >>>>>>>
>> > > > > > > <connection-url>jdbc:postgresql://someserver:5432/someDb</co
>> > > > > > > nn
>> > > > > > > ec
>> > > > > > > ti
>> > > > > > > on
>> > > > > > > -u
>> > > > > > > rl>
>> > > > > > > >>>>>>> <user-name>user</user-name>
>> > > > > > > >>>>>>> <password>pwd</password>
>> > > > > > > >>>>>>>
>> > > > > > > <driver-class>org.postgresql.Driver</driver-class>
>> > > > > > > >>>>>>> </local-tx-datasource> </datasources>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>This will create the following JNDI location in
>> JBossAS5:
>> > > > > > > >>>>>>>java:/myDS
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>NO comp, NO lang, NO other qualifier.
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>Configuring the same in Geronimo gives you
>> > > > > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY
>> > > > > > > >>>>>>>different in JBossAS6, AS7, Glassfish,
>> > > > > > > TomEE, etc
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>Thus: which JNDI location would you configure in your
>> > > > > > > persistence.xml?
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>That's the reason why we came up with the
>> > > > > ConfigurableDataSource.
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>Of course, we need to extend this concept and create
>> > > > > > > >>>>>>>a
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>public interface ConfigurableXaDataSource extends
>> > > > > > > ConfigurableDataSource, XaDataSource {}
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>See what I mean?
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>LieGrue,
>> > > > > > > >>>>>>>strub
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>>----- Original Message -----
>> > > > > > > >>>>>>>> From: David Blevins <da...@gmail.com>
>> > > > > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark
>> > > > > > > >>>>>>>> Struberg <
>> > > > > > > struberg@yahoo.de>
>> > > > > > > >>>>>>>> Cc:
>> > > > > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
>> > > > > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
>> > > > > > > >>>>>>>> features
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>>> In plain Tomcat or Jetty servers this needs to
>> > > > > > > >>>>>>>>>> be configured in a
>> > > > > > > container-specific way.
>> > > > > > > >>>>>>>>> The problem with the container specific stuff is
>> > > > > > > >>>>>>>>> that every
>> > > > > > > container
>> > > > > > > >>>>>>>> serves the xml configured datasource on a different
>> > > > > > > >>>>>>>> location in
>> > > > > > > JNDI! So you
>> > > > > > > >>>>>>>> cannot provide a container independent
>> > > > > > > >>>>>>>> implementation that way :/
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> The portable way would be to declare your
>> > > > > > > >>>>>>>> datasource properly via
>> > > > > > > >>>>>>>> @Resource(name="java:app/Foo",
>> > > > > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> Most servers can map those references with little
>> > > > > > > >>>>>>>> to no
>> > > > > config.
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>> -David
>> > > > > > > >>>>>>>>
>> > > > > > > >>>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>>>
>> > > > > > > >>>>
>> > > > > > > >>>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>>
>> > > > > > > >>
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Yep but an em needs an emf ;)
Le 6 mai 2012 16:05, "Arne Limburg" <ar...@openknowledge.de> a
écrit :
> OK, I think, this is not correct since it expresses a dependency to an
> EntityManager and not to an EntityManagerFactory (in opposition to
> @PersistenceUnit).
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 16:00
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> It tomee we create the entitymanagerfactory associated.
> Le 6 mai 2012 15:53, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > OK and the meaning of this annotation at class-level would be:
> > "a dependency on a container-managed entity manager and its associated
> > persistence context." That's perfectly the semantics we need ;-)
> >
> > But what would a jee container do when he observes such annotation at
> > class-level? I can't read it from the spec...
> > I think, we have to try... Or does someone at this list know?
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 15:49
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
> >
> > The container will scan persistencecontext annotation with no link
> > with cdi.
> > Le 6 mai 2012 15:46, "Arne Limburg" <ar...@openknowledge.de> a
> > écrit :
> >
> > > If so, what would be the semantic of such definition?
> > > Btw. that classes would only become CDI beans when the deployment is
> > > in the correct project stage. Otherwise we would veto them away,
> > > before they become beans...
> > > And, which part of the jee container would scan that class? My guess
> > > is, that it would be the responsibility of the CDI implementation.
> > > And
> > > - just a second guess - they ignore it...
> > >
> > > I'll take a look into the JPA spec to see what the official semantic
> > > of the usage I proposed would be. But, I am afraid that this is
> > > underspecified...
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 15:40
> > > An: deltaspike-dev@incubator.apache.org
> > > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
> > >
> > > Cdi is in jee so jee containers scans cdi beans and same for
> > > resources (@persistencontext).
> > > Le 6 mai 2012 15:36, "Arne Limburg" <ar...@openknowledge.de>
> > > a écrit :
> > >
> > > > If not, we can use other annotations, but I think jee containers
> > > > just scan EJBs...
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > Gesendet: Sonntag, 6. Mai 2012 15:28
> > > > An: deltaspike-dev@incubator.apache.org
> > > > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
> > > >
> > > > Not sure it works in a jee container.
> > > >
> > > > - Romain
> > > > Le 6 mai 2012 15:26, "Arne Limburg"
> > > > <ar...@openknowledge.de> a écrit :
> > > >
> > > > > You could configure your production jta-datasource in the
> > > > > persistence.xml and add the following bean to your test deployment:
> > > > >
> > > > > @Exclude(exceptIfProjectStage =
> > > > > ProjectStage.IntegrationTest.class)
> > > > > @PersistenceContext(unitName = "myPU", properties =
> > > > > @PersistenceProperty(name =
> > > > > "javax.persistence.nonJtaDataSource",
> > > > > value =
> > > > > "java:/comp/env/myDS"))
> > > > > public class MyIntegrationTestConfiguration { }
> > > > >
> > > > > For local testing, you could even switch off JNDI:
> > > > > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> > > > > @PersistenceContext(unitName = "myPU", properties =
> > > > > {@PersistenceProperty(name =
> > > > > "javax.persistence.transactionType",
> > > > > value = "RESOURCE_LOCAL"),
> > > > >
> > > > > @PersistenceProperty(name =
> > > > > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
> > > > > public class MyDevelopmentConfiguration { }
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Romain,
> > > > > Noone needs to repackage his application, since we can put this
> > > > > properties into a map and use it as the second parameter of
> > > > emf.createEntityManager...
> > > > >
> > > > > - Arne
> > > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > Gesendet: Sonntag, 6. Mai 2012 15:14
> > > > > An: deltaspike-dev@incubator.apache.org
> > > > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> > > > >
> > > > > How do you manage it from persistence.xml if you dont repackage
> > > > > your archive as Mark said?
> > > > >
> > > > > Personally i agree ;)
> > > > >
> > > > > - Romain
> > > > > Le 6 mai 2012 15:06, "Arne Limburg"
> > > > > <ar...@openknowledge.de> a écrit :
> > > > >
> > > > > > OK,
> > > > > > but do we really need a container-independent way for
> > > JNDI-DataSources?
> > > > > > What's the use case for it?
> > > > > > The user always knows his container and thus his specific
> > JNDI-name.
> > > > > >
> > > > > > I think we need an easy way for users to configure different
> > > > > > JNDI-DataSources for different deployment scenarios, like
> > > > > > - a JTA-datasource for my JBoss AS 7 in production
> > > > > > - a Non-JTA-datasource from another JNDI-location for the
> > > > > > Tomcat for testing
> > > > > > - a RESOURCE_LOCAL EntityManager for local testing...
> > > > > >
> > > > > > We need to find an easy way for the users to configure the
> > > > > > JNDI-location, but imho we don't need to handle different
> > > > > > JNDI-locations
> > > > > in our code?
> > > > > >
> > > > > > WDYT? Am I missing a use case?
> > > > > >
> > > > > > Cheers,
> > > > > > Arne
> > > > > >
> > > > > > -----Ursprüngliche Nachricht-----
> > > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > > > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > > > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >
> > > > > > ConfigurableDataSource doesnt solve it. If you build the emf
> > > > > > from persistence info you manage it yourself. It should be IMO
> > > > > > a compatibility mode and spec you be fixed.
> > > > > >
> > > > > > But well, the most important subjects are not here,
> > > > > > pagination, dynamic dao etc are really more valuable.
> > > > > >
> > > > > > - Romain
> > > > > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a
> écrit :
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The problem here is that this is NOT under our control -
> > > > > > > this is not even CDI related!
> > > > > > >
> > > > > > > You need to _exactly_ specify the JNDI location in your
> > > > > persistence.xml.
> > > > > > > And this info get's parsed by JPA or the EE container at
> > > > > > > deploy
> > > time.
> > > > > > >
> > > > > > >
> > > > > > > Maybe there's a trick with a PersistenceUnitInfo. But since
> > > > > > > those are also managed by the server (and thus show the same
> > > > > > > unspecified
> > > > > > > behaviour) we imo cannot leverage those.
> > > > > > >
> > > > > > > LieGrue,
> > > > > > > strub
> > > > > > >
> > > > > > >
> > > > > > > >________________________________
> > > > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > > > > deltaspike-dev@incubator.apache.org
> > > > > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > >
> > > > > > > >
> > > > > > > >I understand. On another side how many differeny locations
> > > > > > > >are
> > > > there?
> > > > > > > Isnt it manageable?
> > > > > > > >- Romain
> > > > > > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a
> > > > > > > >écrit
> > > :
> > > > > > > >
> > > > > > > >
> > > > > > > >>
> > > > > > > >>PS: I _fully_ agree that this mess should best get fixed
> > > > > > > >>in
> > EE7.
> > > > > > > >>But
> > > > > > > sadly we also need to support older containers!
> > > > > > > >>
> > > > > > > >>I know about folks who have OWB and CODI running on old
> > > > > > > >>WebSphere
> > > > > > > >>6 and
> > > > > > > 7 servers. And others who use OWB on WebLogic 10.3. And
> > > > > > > those companies are big banks, stock exchanges and
> > > > > > > insurrance companies
> > > > > > > - they cannot easily upgrade to a new server...
> > > > > > > >>
> > > > > > > >>LieGrue,
> > > > > > > >>strub
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>>________________________________
> > > > > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>;
> > > > > > > >>>deltaspike <
> > > > > > > deltaspike-dev@incubator.apache.org>
> > > > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>No, the container is NOT buggy, because it's simply NOT
> > defined!
> > > > > > > >>>That's the whole mess about JNDI...
> > > > > > > >>>
> > > > > > > >>>LieGrue,
> > > > > > > >>>strub
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>>________________________________
> > > > > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>So this container is buggy, report an issue ;) Thinking
> > > > > > > >>>>of it this jndi path issue couldnt be resolved by
> > > > > > > configresolvers in ds?
> > > > > > > >>>>- Romain
> > > > > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de>
> > > > > > > >>>>a
> > > > écrit :
> > > > > > > >>>>
> > > > > > > >>>>yes, that crashes the container...
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>>________________________________
> > > > > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > > > > deltaspike-dev@incubator.apache.org
> > > > > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>>Mark, did you try providing a name starting with java:?
> > > > > > > >>>>>>- Romain
> > > > > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg"
> > > > > > > >>>>>><st...@yahoo.de> a
> > > > > écrit :
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > > > > >>>>>>>
> > > > > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > > > > >>>>>>> <local-tx-datasource>
> > > > > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > > > > >>>>>>>
> > > > > > > <connection-url>jdbc:postgresql://someserver:5432/someDb</co
> > > > > > > nn
> > > > > > > ec
> > > > > > > ti
> > > > > > > on
> > > > > > > -u
> > > > > > > rl>
> > > > > > > >>>>>>> <user-name>user</user-name>
> > > > > > > >>>>>>> <password>pwd</password>
> > > > > > > >>>>>>>
> > > > > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>This will create the following JNDI location in
> JBossAS5:
> > > > > > > >>>>>>>java:/myDS
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY
> > > > > > > >>>>>>>different in JBossAS6, AS7, Glassfish,
> > > > > > > TomEE, etc
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>Thus: which JNDI location would you configure in your
> > > > > > > persistence.xml?
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>That's the reason why we came up with the
> > > > > ConfigurableDataSource.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>Of course, we need to extend this concept and create
> > > > > > > >>>>>>>a
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > > > > ConfigurableDataSource, XaDataSource {}
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>See what I mean?
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>LieGrue,
> > > > > > > >>>>>>>strub
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>----- Original Message -----
> > > > > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark
> > > > > > > >>>>>>>> Struberg <
> > > > > > > struberg@yahoo.de>
> > > > > > > >>>>>>>> Cc:
> > > > > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > > >>>>>>>> features
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>>> In plain Tomcat or Jetty servers this needs to
> > > > > > > >>>>>>>>>> be configured in a
> > > > > > > container-specific way.
> > > > > > > >>>>>>>>> The problem with the container specific stuff is
> > > > > > > >>>>>>>>> that every
> > > > > > > container
> > > > > > > >>>>>>>> serves the xml configured datasource on a different
> > > > > > > >>>>>>>> location in
> > > > > > > JNDI! So you
> > > > > > > >>>>>>>> cannot provide a container independent
> > > > > > > >>>>>>>> implementation that way :/
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> The portable way would be to declare your
> > > > > > > >>>>>>>> datasource properly via
> > > > > > > >>>>>>>> @Resource(name="java:app/Foo",
> > > > > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> Most servers can map those references with little
> > > > > > > >>>>>>>> to no
> > > > > config.
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> -David
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
AW: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Arne Limburg <ar...@openknowledge.de>.
OK, I think, this is not correct since it expresses a dependency to an EntityManager and not to an EntityManagerFactory (in opposition to @PersistenceUnit).
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Sonntag, 6. Mai 2012 16:00
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
It tomee we create the entitymanagerfactory associated.
Le 6 mai 2012 15:53, "Arne Limburg" <ar...@openknowledge.de> a écrit :
> OK and the meaning of this annotation at class-level would be:
> "a dependency on a container-managed entity manager and its associated
> persistence context." That's perfectly the semantics we need ;-)
>
> But what would a jee container do when he observes such annotation at
> class-level? I can't read it from the spec...
> I think, we have to try... Or does someone at this list know?
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 15:49
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> The container will scan persistencecontext annotation with no link
> with cdi.
> Le 6 mai 2012 15:46, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > If so, what would be the semantic of such definition?
> > Btw. that classes would only become CDI beans when the deployment is
> > in the correct project stage. Otherwise we would veto them away,
> > before they become beans...
> > And, which part of the jee container would scan that class? My guess
> > is, that it would be the responsibility of the CDI implementation.
> > And
> > - just a second guess - they ignore it...
> >
> > I'll take a look into the JPA spec to see what the official semantic
> > of the usage I proposed would be. But, I am afraid that this is
> > underspecified...
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 15:40
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
> >
> > Cdi is in jee so jee containers scans cdi beans and same for
> > resources (@persistencontext).
> > Le 6 mai 2012 15:36, "Arne Limburg" <ar...@openknowledge.de>
> > a écrit :
> >
> > > If not, we can use other annotations, but I think jee containers
> > > just scan EJBs...
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 15:28
> > > An: deltaspike-dev@incubator.apache.org
> > > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
> > >
> > > Not sure it works in a jee container.
> > >
> > > - Romain
> > > Le 6 mai 2012 15:26, "Arne Limburg"
> > > <ar...@openknowledge.de> a écrit :
> > >
> > > > You could configure your production jta-datasource in the
> > > > persistence.xml and add the following bean to your test deployment:
> > > >
> > > > @Exclude(exceptIfProjectStage =
> > > > ProjectStage.IntegrationTest.class)
> > > > @PersistenceContext(unitName = "myPU", properties =
> > > > @PersistenceProperty(name =
> > > > "javax.persistence.nonJtaDataSource",
> > > > value =
> > > > "java:/comp/env/myDS"))
> > > > public class MyIntegrationTestConfiguration { }
> > > >
> > > > For local testing, you could even switch off JNDI:
> > > > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> > > > @PersistenceContext(unitName = "myPU", properties =
> > > > {@PersistenceProperty(name =
> > > > "javax.persistence.transactionType",
> > > > value = "RESOURCE_LOCAL"),
> > > >
> > > > @PersistenceProperty(name =
> > > > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
> > > > public class MyDevelopmentConfiguration { }
> > > >
> > > > WDYT?
> > > >
> > > > Romain,
> > > > Noone needs to repackage his application, since we can put this
> > > > properties into a map and use it as the second parameter of
> > > emf.createEntityManager...
> > > >
> > > > - Arne
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > Gesendet: Sonntag, 6. Mai 2012 15:14
> > > > An: deltaspike-dev@incubator.apache.org
> > > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> > > >
> > > > How do you manage it from persistence.xml if you dont repackage
> > > > your archive as Mark said?
> > > >
> > > > Personally i agree ;)
> > > >
> > > > - Romain
> > > > Le 6 mai 2012 15:06, "Arne Limburg"
> > > > <ar...@openknowledge.de> a écrit :
> > > >
> > > > > OK,
> > > > > but do we really need a container-independent way for
> > JNDI-DataSources?
> > > > > What's the use case for it?
> > > > > The user always knows his container and thus his specific
> JNDI-name.
> > > > >
> > > > > I think we need an easy way for users to configure different
> > > > > JNDI-DataSources for different deployment scenarios, like
> > > > > - a JTA-datasource for my JBoss AS 7 in production
> > > > > - a Non-JTA-datasource from another JNDI-location for the
> > > > > Tomcat for testing
> > > > > - a RESOURCE_LOCAL EntityManager for local testing...
> > > > >
> > > > > We need to find an easy way for the users to configure the
> > > > > JNDI-location, but imho we don't need to handle different
> > > > > JNDI-locations
> > > > in our code?
> > > > >
> > > > > WDYT? Am I missing a use case?
> > > > >
> > > > > Cheers,
> > > > > Arne
> > > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > > > >
> > > > > ConfigurableDataSource doesnt solve it. If you build the emf
> > > > > from persistence info you manage it yourself. It should be IMO
> > > > > a compatibility mode and spec you be fixed.
> > > > >
> > > > > But well, the most important subjects are not here,
> > > > > pagination, dynamic dao etc are really more valuable.
> > > > >
> > > > > - Romain
> > > > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
> > > > >
> > > > > >
> > > > > >
> > > > > > The problem here is that this is NOT under our control -
> > > > > > this is not even CDI related!
> > > > > >
> > > > > > You need to _exactly_ specify the JNDI location in your
> > > > persistence.xml.
> > > > > > And this info get's parsed by JPA or the EE container at
> > > > > > deploy
> > time.
> > > > > >
> > > > > >
> > > > > > Maybe there's a trick with a PersistenceUnitInfo. But since
> > > > > > those are also managed by the server (and thus show the same
> > > > > > unspecified
> > > > > > behaviour) we imo cannot leverage those.
> > > > > >
> > > > > > LieGrue,
> > > > > > strub
> > > > > >
> > > > > >
> > > > > > >________________________________
> > > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > > > deltaspike-dev@incubator.apache.org
> > > > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >
> > > > > > >
> > > > > > >I understand. On another side how many differeny locations
> > > > > > >are
> > > there?
> > > > > > Isnt it manageable?
> > > > > > >- Romain
> > > > > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a
> > > > > > >écrit
> > :
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >>PS: I _fully_ agree that this mess should best get fixed
> > > > > > >>in
> EE7.
> > > > > > >>But
> > > > > > sadly we also need to support older containers!
> > > > > > >>
> > > > > > >>I know about folks who have OWB and CODI running on old
> > > > > > >>WebSphere
> > > > > > >>6 and
> > > > > > 7 servers. And others who use OWB on WebLogic 10.3. And
> > > > > > those companies are big banks, stock exchanges and
> > > > > > insurrance companies
> > > > > > - they cannot easily upgrade to a new server...
> > > > > > >>
> > > > > > >>LieGrue,
> > > > > > >>strub
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>>________________________________
> > > > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>;
> > > > > > >>>deltaspike <
> > > > > > deltaspike-dev@incubator.apache.org>
> > > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>No, the container is NOT buggy, because it's simply NOT
> defined!
> > > > > > >>>That's the whole mess about JNDI...
> > > > > > >>>
> > > > > > >>>LieGrue,
> > > > > > >>>strub
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>>________________________________
> > > > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>So this container is buggy, report an issue ;) Thinking
> > > > > > >>>>of it this jndi path issue couldnt be resolved by
> > > > > > configresolvers in ds?
> > > > > > >>>>- Romain
> > > > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de>
> > > > > > >>>>a
> > > écrit :
> > > > > > >>>>
> > > > > > >>>>yes, that crashes the container...
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>>________________________________
> > > > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > > > deltaspike-dev@incubator.apache.org
> > > > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>Mark, did you try providing a name starting with java:?
> > > > > > >>>>>>- Romain
> > > > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg"
> > > > > > >>>>>><st...@yahoo.de> a
> > > > écrit :
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > > > >>>>>>>
> > > > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > > > >>>>>>>
> > > > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > > > >>>>>>> <local-tx-datasource>
> > > > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > > > >>>>>>>
> > > > > > <connection-url>jdbc:postgresql://someserver:5432/someDb</co
> > > > > > nn
> > > > > > ec
> > > > > > ti
> > > > > > on
> > > > > > -u
> > > > > > rl>
> > > > > > >>>>>>> <user-name>user</user-name>
> > > > > > >>>>>>> <password>pwd</password>
> > > > > > >>>>>>>
> > > > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > > > >>>>>>>
> > > > > > >>>>>>>This will create the following JNDI location in JBossAS5:
> > > > > > >>>>>>>java:/myDS
> > > > > > >>>>>>>
> > > > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > > > >>>>>>>
> > > > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY
> > > > > > >>>>>>>different in JBossAS6, AS7, Glassfish,
> > > > > > TomEE, etc
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>Thus: which JNDI location would you configure in your
> > > > > > persistence.xml?
> > > > > > >>>>>>>
> > > > > > >>>>>>>That's the reason why we came up with the
> > > > ConfigurableDataSource.
> > > > > > >>>>>>>
> > > > > > >>>>>>>Of course, we need to extend this concept and create
> > > > > > >>>>>>>a
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > > > ConfigurableDataSource, XaDataSource {}
> > > > > > >>>>>>>
> > > > > > >>>>>>>See what I mean?
> > > > > > >>>>>>>
> > > > > > >>>>>>>LieGrue,
> > > > > > >>>>>>>strub
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>----- Original Message -----
> > > > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark
> > > > > > >>>>>>>> Struberg <
> > > > > > struberg@yahoo.de>
> > > > > > >>>>>>>> Cc:
> > > > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> > > > > > >>>>>>>> features
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>>> In plain Tomcat or Jetty servers this needs to
> > > > > > >>>>>>>>>> be configured in a
> > > > > > container-specific way.
> > > > > > >>>>>>>>> The problem with the container specific stuff is
> > > > > > >>>>>>>>> that every
> > > > > > container
> > > > > > >>>>>>>> serves the xml configured datasource on a different
> > > > > > >>>>>>>> location in
> > > > > > JNDI! So you
> > > > > > >>>>>>>> cannot provide a container independent
> > > > > > >>>>>>>> implementation that way :/
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> The portable way would be to declare your
> > > > > > >>>>>>>> datasource properly via
> > > > > > >>>>>>>> @Resource(name="java:app/Foo",
> > > > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Most servers can map those references with little
> > > > > > >>>>>>>> to no
> > > > config.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> -David
> > > > > > >>>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
It tomee we create the entitymanagerfactory associated.
Le 6 mai 2012 15:53, "Arne Limburg" <ar...@openknowledge.de> a
écrit :
> OK and the meaning of this annotation at class-level would be:
> "a dependency on a container-managed entity manager and its associated
> persistence context." That's perfectly the semantics we need ;-)
>
> But what would a jee container do when he observes such annotation at
> class-level? I can't read it from the spec...
> I think, we have to try... Or does someone at this list know?
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 15:49
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> The container will scan persistencecontext annotation with no link with
> cdi.
> Le 6 mai 2012 15:46, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > If so, what would be the semantic of such definition?
> > Btw. that classes would only become CDI beans when the deployment is
> > in the correct project stage. Otherwise we would veto them away,
> > before they become beans...
> > And, which part of the jee container would scan that class? My guess
> > is, that it would be the responsibility of the CDI implementation. And
> > - just a second guess - they ignore it...
> >
> > I'll take a look into the JPA spec to see what the official semantic
> > of the usage I proposed would be. But, I am afraid that this is
> > underspecified...
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 15:40
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
> >
> > Cdi is in jee so jee containers scans cdi beans and same for resources
> > (@persistencontext).
> > Le 6 mai 2012 15:36, "Arne Limburg" <ar...@openknowledge.de> a
> > écrit :
> >
> > > If not, we can use other annotations, but I think jee containers
> > > just scan EJBs...
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 15:28
> > > An: deltaspike-dev@incubator.apache.org
> > > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
> > >
> > > Not sure it works in a jee container.
> > >
> > > - Romain
> > > Le 6 mai 2012 15:26, "Arne Limburg" <ar...@openknowledge.de>
> > > a écrit :
> > >
> > > > You could configure your production jta-datasource in the
> > > > persistence.xml and add the following bean to your test deployment:
> > > >
> > > > @Exclude(exceptIfProjectStage =
> > > > ProjectStage.IntegrationTest.class)
> > > > @PersistenceContext(unitName = "myPU", properties =
> > > > @PersistenceProperty(name = "javax.persistence.nonJtaDataSource",
> > > > value =
> > > > "java:/comp/env/myDS"))
> > > > public class MyIntegrationTestConfiguration { }
> > > >
> > > > For local testing, you could even switch off JNDI:
> > > > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> > > > @PersistenceContext(unitName = "myPU", properties =
> > > > {@PersistenceProperty(name = "javax.persistence.transactionType",
> > > > value = "RESOURCE_LOCAL"),
> > > >
> > > > @PersistenceProperty(name =
> > > > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
> > > > public class MyDevelopmentConfiguration { }
> > > >
> > > > WDYT?
> > > >
> > > > Romain,
> > > > Noone needs to repackage his application, since we can put this
> > > > properties into a map and use it as the second parameter of
> > > emf.createEntityManager...
> > > >
> > > > - Arne
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > Gesendet: Sonntag, 6. Mai 2012 15:14
> > > > An: deltaspike-dev@incubator.apache.org
> > > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> > > >
> > > > How do you manage it from persistence.xml if you dont repackage
> > > > your archive as Mark said?
> > > >
> > > > Personally i agree ;)
> > > >
> > > > - Romain
> > > > Le 6 mai 2012 15:06, "Arne Limburg"
> > > > <ar...@openknowledge.de> a écrit :
> > > >
> > > > > OK,
> > > > > but do we really need a container-independent way for
> > JNDI-DataSources?
> > > > > What's the use case for it?
> > > > > The user always knows his container and thus his specific
> JNDI-name.
> > > > >
> > > > > I think we need an easy way for users to configure different
> > > > > JNDI-DataSources for different deployment scenarios, like
> > > > > - a JTA-datasource for my JBoss AS 7 in production
> > > > > - a Non-JTA-datasource from another JNDI-location for the Tomcat
> > > > > for testing
> > > > > - a RESOURCE_LOCAL EntityManager for local testing...
> > > > >
> > > > > We need to find an easy way for the users to configure the
> > > > > JNDI-location, but imho we don't need to handle different
> > > > > JNDI-locations
> > > > in our code?
> > > > >
> > > > > WDYT? Am I missing a use case?
> > > > >
> > > > > Cheers,
> > > > > Arne
> > > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > > > >
> > > > > ConfigurableDataSource doesnt solve it. If you build the emf
> > > > > from persistence info you manage it yourself. It should be IMO a
> > > > > compatibility mode and spec you be fixed.
> > > > >
> > > > > But well, the most important subjects are not here, pagination,
> > > > > dynamic dao etc are really more valuable.
> > > > >
> > > > > - Romain
> > > > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
> > > > >
> > > > > >
> > > > > >
> > > > > > The problem here is that this is NOT under our control - this
> > > > > > is not even CDI related!
> > > > > >
> > > > > > You need to _exactly_ specify the JNDI location in your
> > > > persistence.xml.
> > > > > > And this info get's parsed by JPA or the EE container at
> > > > > > deploy
> > time.
> > > > > >
> > > > > >
> > > > > > Maybe there's a trick with a PersistenceUnitInfo. But since
> > > > > > those are also managed by the server (and thus show the same
> > > > > > unspecified
> > > > > > behaviour) we imo cannot leverage those.
> > > > > >
> > > > > > LieGrue,
> > > > > > strub
> > > > > >
> > > > > >
> > > > > > >________________________________
> > > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > > > deltaspike-dev@incubator.apache.org
> > > > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >
> > > > > > >
> > > > > > >I understand. On another side how many differeny locations
> > > > > > >are
> > > there?
> > > > > > Isnt it manageable?
> > > > > > >- Romain
> > > > > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a
> > > > > > >écrit
> > :
> > > > > > >
> > > > > > >
> > > > > > >>
> > > > > > >>PS: I _fully_ agree that this mess should best get fixed in
> EE7.
> > > > > > >>But
> > > > > > sadly we also need to support older containers!
> > > > > > >>
> > > > > > >>I know about folks who have OWB and CODI running on old
> > > > > > >>WebSphere
> > > > > > >>6 and
> > > > > > 7 servers. And others who use OWB on WebLogic 10.3. And those
> > > > > > companies are big banks, stock exchanges and insurrance
> > > > > > companies
> > > > > > - they cannot easily upgrade to a new server...
> > > > > > >>
> > > > > > >>LieGrue,
> > > > > > >>strub
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>>________________________________
> > > > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike
> > > > > > >>><
> > > > > > deltaspike-dev@incubator.apache.org>
> > > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>No, the container is NOT buggy, because it's simply NOT
> defined!
> > > > > > >>>That's the whole mess about JNDI...
> > > > > > >>>
> > > > > > >>>LieGrue,
> > > > > > >>>strub
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>>________________________________
> > > > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>So this container is buggy, report an issue ;) Thinking of
> > > > > > >>>>it this jndi path issue couldnt be resolved by
> > > > > > configresolvers in ds?
> > > > > > >>>>- Romain
> > > > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a
> > > écrit :
> > > > > > >>>>
> > > > > > >>>>yes, that crashes the container...
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>>________________________________
> > > > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > > > deltaspike-dev@incubator.apache.org
> > > > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>Mark, did you try providing a name starting with java:?
> > > > > > >>>>>>- Romain
> > > > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de>
> > > > > > >>>>>>a
> > > > écrit :
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > > > >>>>>>>
> > > > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > > > >>>>>>>
> > > > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > > > >>>>>>> <local-tx-datasource>
> > > > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > > > >>>>>>>
> > > > > > <connection-url>jdbc:postgresql://someserver:5432/someDb</conn
> > > > > > ec
> > > > > > ti
> > > > > > on
> > > > > > -u
> > > > > > rl>
> > > > > > >>>>>>> <user-name>user</user-name>
> > > > > > >>>>>>> <password>pwd</password>
> > > > > > >>>>>>>
> > > > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > > > >>>>>>>
> > > > > > >>>>>>>This will create the following JNDI location in JBossAS5:
> > > > > > >>>>>>>java:/myDS
> > > > > > >>>>>>>
> > > > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > > > >>>>>>>
> > > > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY different
> > > > > > >>>>>>>in JBossAS6, AS7, Glassfish,
> > > > > > TomEE, etc
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>Thus: which JNDI location would you configure in your
> > > > > > persistence.xml?
> > > > > > >>>>>>>
> > > > > > >>>>>>>That's the reason why we came up with the
> > > > ConfigurableDataSource.
> > > > > > >>>>>>>
> > > > > > >>>>>>>Of course, we need to extend this concept and create a
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > > > ConfigurableDataSource, XaDataSource {}
> > > > > > >>>>>>>
> > > > > > >>>>>>>See what I mean?
> > > > > > >>>>>>>
> > > > > > >>>>>>>LieGrue,
> > > > > > >>>>>>>strub
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>>----- Original Message -----
> > > > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark
> > > > > > >>>>>>>> Struberg <
> > > > > > struberg@yahoo.de>
> > > > > > >>>>>>>> Cc:
> > > > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>>> In plain Tomcat or Jetty servers this needs to be
> > > > > > >>>>>>>>>> configured in a
> > > > > > container-specific way.
> > > > > > >>>>>>>>> The problem with the container specific stuff is
> > > > > > >>>>>>>>> that every
> > > > > > container
> > > > > > >>>>>>>> serves the xml configured datasource on a different
> > > > > > >>>>>>>> location in
> > > > > > JNDI! So you
> > > > > > >>>>>>>> cannot provide a container independent implementation
> > > > > > >>>>>>>> that way :/
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> The portable way would be to declare your datasource
> > > > > > >>>>>>>> properly via @Resource(name="java:app/Foo",
> > > > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Most servers can map those references with little to
> > > > > > >>>>>>>> no
> > > > config.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> -David
> > > > > > >>>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
AW: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Arne Limburg <ar...@openknowledge.de>.
OK and the meaning of this annotation at class-level would be:
"a dependency on a container-managed entity manager and its associated persistence context." That's perfectly the semantics we need ;-)
But what would a jee container do when he observes such annotation at class-level? I can't read it from the spec...
I think, we have to try... Or does someone at this list know?
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Sonntag, 6. Mai 2012 15:49
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
The container will scan persistencecontext annotation with no link with cdi.
Le 6 mai 2012 15:46, "Arne Limburg" <ar...@openknowledge.de> a écrit :
> If so, what would be the semantic of such definition?
> Btw. that classes would only become CDI beans when the deployment is
> in the correct project stage. Otherwise we would veto them away,
> before they become beans...
> And, which part of the jee container would scan that class? My guess
> is, that it would be the responsibility of the CDI implementation. And
> - just a second guess - they ignore it...
>
> I'll take a look into the JPA spec to see what the official semantic
> of the usage I proposed would be. But, I am afraid that this is
> underspecified...
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 15:40
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> Cdi is in jee so jee containers scans cdi beans and same for resources
> (@persistencontext).
> Le 6 mai 2012 15:36, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > If not, we can use other annotations, but I think jee containers
> > just scan EJBs...
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 15:28
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
> >
> > Not sure it works in a jee container.
> >
> > - Romain
> > Le 6 mai 2012 15:26, "Arne Limburg" <ar...@openknowledge.de>
> > a écrit :
> >
> > > You could configure your production jta-datasource in the
> > > persistence.xml and add the following bean to your test deployment:
> > >
> > > @Exclude(exceptIfProjectStage =
> > > ProjectStage.IntegrationTest.class)
> > > @PersistenceContext(unitName = "myPU", properties =
> > > @PersistenceProperty(name = "javax.persistence.nonJtaDataSource",
> > > value =
> > > "java:/comp/env/myDS"))
> > > public class MyIntegrationTestConfiguration { }
> > >
> > > For local testing, you could even switch off JNDI:
> > > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> > > @PersistenceContext(unitName = "myPU", properties =
> > > {@PersistenceProperty(name = "javax.persistence.transactionType",
> > > value = "RESOURCE_LOCAL"),
> > >
> > > @PersistenceProperty(name =
> > > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
> > > public class MyDevelopmentConfiguration { }
> > >
> > > WDYT?
> > >
> > > Romain,
> > > Noone needs to repackage his application, since we can put this
> > > properties into a map and use it as the second parameter of
> > emf.createEntityManager...
> > >
> > > - Arne
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 15:14
> > > An: deltaspike-dev@incubator.apache.org
> > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> > >
> > > How do you manage it from persistence.xml if you dont repackage
> > > your archive as Mark said?
> > >
> > > Personally i agree ;)
> > >
> > > - Romain
> > > Le 6 mai 2012 15:06, "Arne Limburg"
> > > <ar...@openknowledge.de> a écrit :
> > >
> > > > OK,
> > > > but do we really need a container-independent way for
> JNDI-DataSources?
> > > > What's the use case for it?
> > > > The user always knows his container and thus his specific JNDI-name.
> > > >
> > > > I think we need an easy way for users to configure different
> > > > JNDI-DataSources for different deployment scenarios, like
> > > > - a JTA-datasource for my JBoss AS 7 in production
> > > > - a Non-JTA-datasource from another JNDI-location for the Tomcat
> > > > for testing
> > > > - a RESOURCE_LOCAL EntityManager for local testing...
> > > >
> > > > We need to find an easy way for the users to configure the
> > > > JNDI-location, but imho we don't need to handle different
> > > > JNDI-locations
> > > in our code?
> > > >
> > > > WDYT? Am I missing a use case?
> > > >
> > > > Cheers,
> > > > Arne
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > > >
> > > > ConfigurableDataSource doesnt solve it. If you build the emf
> > > > from persistence info you manage it yourself. It should be IMO a
> > > > compatibility mode and spec you be fixed.
> > > >
> > > > But well, the most important subjects are not here, pagination,
> > > > dynamic dao etc are really more valuable.
> > > >
> > > > - Romain
> > > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
> > > >
> > > > >
> > > > >
> > > > > The problem here is that this is NOT under our control - this
> > > > > is not even CDI related!
> > > > >
> > > > > You need to _exactly_ specify the JNDI location in your
> > > persistence.xml.
> > > > > And this info get's parsed by JPA or the EE container at
> > > > > deploy
> time.
> > > > >
> > > > >
> > > > > Maybe there's a trick with a PersistenceUnitInfo. But since
> > > > > those are also managed by the server (and thus show the same
> > > > > unspecified
> > > > > behaviour) we imo cannot leverage those.
> > > > >
> > > > > LieGrue,
> > > > > strub
> > > > >
> > > > >
> > > > > >________________________________
> > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > > deltaspike-dev@incubator.apache.org
> > > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >
> > > > > >
> > > > > >I understand. On another side how many differeny locations
> > > > > >are
> > there?
> > > > > Isnt it manageable?
> > > > > >- Romain
> > > > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a
> > > > > >écrit
> :
> > > > > >
> > > > > >
> > > > > >>
> > > > > >>PS: I _fully_ agree that this mess should best get fixed in EE7.
> > > > > >>But
> > > > > sadly we also need to support older containers!
> > > > > >>
> > > > > >>I know about folks who have OWB and CODI running on old
> > > > > >>WebSphere
> > > > > >>6 and
> > > > > 7 servers. And others who use OWB on WebLogic 10.3. And those
> > > > > companies are big banks, stock exchanges and insurrance
> > > > > companies
> > > > > - they cannot easily upgrade to a new server...
> > > > > >>
> > > > > >>LieGrue,
> > > > > >>strub
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>>________________________________
> > > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike
> > > > > >>><
> > > > > deltaspike-dev@incubator.apache.org>
> > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>No, the container is NOT buggy, because it's simply NOT defined!
> > > > > >>>That's the whole mess about JNDI...
> > > > > >>>
> > > > > >>>LieGrue,
> > > > > >>>strub
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>>________________________________
> > > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>So this container is buggy, report an issue ;) Thinking of
> > > > > >>>>it this jndi path issue couldnt be resolved by
> > > > > configresolvers in ds?
> > > > > >>>>- Romain
> > > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a
> > écrit :
> > > > > >>>>
> > > > > >>>>yes, that crashes the container...
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>________________________________
> > > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > > deltaspike-dev@incubator.apache.org
> > > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>Mark, did you try providing a name starting with java:?
> > > > > >>>>>>- Romain
> > > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de>
> > > > > >>>>>>a
> > > écrit :
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > > >>>>>>>
> > > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > > >>>>>>>
> > > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > > >>>>>>> <local-tx-datasource>
> > > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > > >>>>>>>
> > > > > <connection-url>jdbc:postgresql://someserver:5432/someDb</conn
> > > > > ec
> > > > > ti
> > > > > on
> > > > > -u
> > > > > rl>
> > > > > >>>>>>> <user-name>user</user-name>
> > > > > >>>>>>> <password>pwd</password>
> > > > > >>>>>>>
> > > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > > >>>>>>>
> > > > > >>>>>>>This will create the following JNDI location in JBossAS5:
> > > > > >>>>>>>java:/myDS
> > > > > >>>>>>>
> > > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > > >>>>>>>
> > > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY different
> > > > > >>>>>>>in JBossAS6, AS7, Glassfish,
> > > > > TomEE, etc
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>Thus: which JNDI location would you configure in your
> > > > > persistence.xml?
> > > > > >>>>>>>
> > > > > >>>>>>>That's the reason why we came up with the
> > > ConfigurableDataSource.
> > > > > >>>>>>>
> > > > > >>>>>>>Of course, we need to extend this concept and create a
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > > ConfigurableDataSource, XaDataSource {}
> > > > > >>>>>>>
> > > > > >>>>>>>See what I mean?
> > > > > >>>>>>>
> > > > > >>>>>>>LieGrue,
> > > > > >>>>>>>strub
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>----- Original Message -----
> > > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark
> > > > > >>>>>>>> Struberg <
> > > > > struberg@yahoo.de>
> > > > > >>>>>>>> Cc:
> > > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>>>> In plain Tomcat or Jetty servers this needs to be
> > > > > >>>>>>>>>> configured in a
> > > > > container-specific way.
> > > > > >>>>>>>>> The problem with the container specific stuff is
> > > > > >>>>>>>>> that every
> > > > > container
> > > > > >>>>>>>> serves the xml configured datasource on a different
> > > > > >>>>>>>> location in
> > > > > JNDI! So you
> > > > > >>>>>>>> cannot provide a container independent implementation
> > > > > >>>>>>>> that way :/
> > > > > >>>>>>>>
> > > > > >>>>>>>> The portable way would be to declare your datasource
> > > > > >>>>>>>> properly via @Resource(name="java:app/Foo",
> > > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > > >>>>>>>>
> > > > > >>>>>>>> Most servers can map those references with little to
> > > > > >>>>>>>> no
> > > config.
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> -David
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
The container will scan persistencecontext annotation with no link with cdi.
Le 6 mai 2012 15:46, "Arne Limburg" <ar...@openknowledge.de> a
écrit :
> If so, what would be the semantic of such definition?
> Btw. that classes would only become CDI beans when the deployment is in
> the correct project stage. Otherwise we would veto them away, before they
> become beans...
> And, which part of the jee container would scan that class? My guess is,
> that it would be the responsibility of the CDI implementation. And - just a
> second guess - they ignore it...
>
> I'll take a look into the JPA spec to see what the official semantic of
> the usage I proposed would be. But, I am afraid that this is
> underspecified...
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 15:40
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> Cdi is in jee so jee containers scans cdi beans and same for resources
> (@persistencontext).
> Le 6 mai 2012 15:36, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > If not, we can use other annotations, but I think jee containers just
> > scan EJBs...
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 15:28
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
> >
> > Not sure it works in a jee container.
> >
> > - Romain
> > Le 6 mai 2012 15:26, "Arne Limburg" <ar...@openknowledge.de> a
> > écrit :
> >
> > > You could configure your production jta-datasource in the
> > > persistence.xml and add the following bean to your test deployment:
> > >
> > > @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> > > @PersistenceContext(unitName = "myPU", properties =
> > > @PersistenceProperty(name = "javax.persistence.nonJtaDataSource",
> > > value =
> > > "java:/comp/env/myDS"))
> > > public class MyIntegrationTestConfiguration { }
> > >
> > > For local testing, you could even switch off JNDI:
> > > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> > > @PersistenceContext(unitName = "myPU", properties =
> > > {@PersistenceProperty(name = "javax.persistence.transactionType",
> > > value = "RESOURCE_LOCAL"),
> > >
> > > @PersistenceProperty(name =
> > > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
> > > public class MyDevelopmentConfiguration { }
> > >
> > > WDYT?
> > >
> > > Romain,
> > > Noone needs to repackage his application, since we can put this
> > > properties into a map and use it as the second parameter of
> > emf.createEntityManager...
> > >
> > > - Arne
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 15:14
> > > An: deltaspike-dev@incubator.apache.org
> > > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> > >
> > > How do you manage it from persistence.xml if you dont repackage your
> > > archive as Mark said?
> > >
> > > Personally i agree ;)
> > >
> > > - Romain
> > > Le 6 mai 2012 15:06, "Arne Limburg" <ar...@openknowledge.de>
> > > a écrit :
> > >
> > > > OK,
> > > > but do we really need a container-independent way for
> JNDI-DataSources?
> > > > What's the use case for it?
> > > > The user always knows his container and thus his specific JNDI-name.
> > > >
> > > > I think we need an easy way for users to configure different
> > > > JNDI-DataSources for different deployment scenarios, like
> > > > - a JTA-datasource for my JBoss AS 7 in production
> > > > - a Non-JTA-datasource from another JNDI-location for the Tomcat
> > > > for testing
> > > > - a RESOURCE_LOCAL EntityManager for local testing...
> > > >
> > > > We need to find an easy way for the users to configure the
> > > > JNDI-location, but imho we don't need to handle different
> > > > JNDI-locations
> > > in our code?
> > > >
> > > > WDYT? Am I missing a use case?
> > > >
> > > > Cheers,
> > > > Arne
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > > >
> > > > ConfigurableDataSource doesnt solve it. If you build the emf from
> > > > persistence info you manage it yourself. It should be IMO a
> > > > compatibility mode and spec you be fixed.
> > > >
> > > > But well, the most important subjects are not here, pagination,
> > > > dynamic dao etc are really more valuable.
> > > >
> > > > - Romain
> > > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
> > > >
> > > > >
> > > > >
> > > > > The problem here is that this is NOT under our control - this is
> > > > > not even CDI related!
> > > > >
> > > > > You need to _exactly_ specify the JNDI location in your
> > > persistence.xml.
> > > > > And this info get's parsed by JPA or the EE container at deploy
> time.
> > > > >
> > > > >
> > > > > Maybe there's a trick with a PersistenceUnitInfo. But since
> > > > > those are also managed by the server (and thus show the same
> > > > > unspecified
> > > > > behaviour) we imo cannot leverage those.
> > > > >
> > > > > LieGrue,
> > > > > strub
> > > > >
> > > > >
> > > > > >________________________________
> > > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > > deltaspike-dev@incubator.apache.org
> > > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >
> > > > > >
> > > > > >I understand. On another side how many differeny locations are
> > there?
> > > > > Isnt it manageable?
> > > > > >- Romain
> > > > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit
> :
> > > > > >
> > > > > >
> > > > > >>
> > > > > >>PS: I _fully_ agree that this mess should best get fixed in EE7.
> > > > > >>But
> > > > > sadly we also need to support older containers!
> > > > > >>
> > > > > >>I know about folks who have OWB and CODI running on old
> > > > > >>WebSphere
> > > > > >>6 and
> > > > > 7 servers. And others who use OWB on WebLogic 10.3. And those
> > > > > companies are big banks, stock exchanges and insurrance
> > > > > companies
> > > > > - they cannot easily upgrade to a new server...
> > > > > >>
> > > > > >>LieGrue,
> > > > > >>strub
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>>________________________________
> > > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <
> > > > > deltaspike-dev@incubator.apache.org>
> > > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>No, the container is NOT buggy, because it's simply NOT defined!
> > > > > >>>That's the whole mess about JNDI...
> > > > > >>>
> > > > > >>>LieGrue,
> > > > > >>>strub
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>>>________________________________
> > > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>So this container is buggy, report an issue ;) Thinking of
> > > > > >>>>it this jndi path issue couldnt be resolved by
> > > > > configresolvers in ds?
> > > > > >>>>- Romain
> > > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a
> > écrit :
> > > > > >>>>
> > > > > >>>>yes, that crashes the container...
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>________________________________
> > > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > > deltaspike-dev@incubator.apache.org
> > > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>Mark, did you try providing a name starting with java:?
> > > > > >>>>>>- Romain
> > > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a
> > > écrit :
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > > >>>>>>>
> > > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > > >>>>>>>
> > > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > > >>>>>>> <local-tx-datasource>
> > > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > > >>>>>>>
> > > > > <connection-url>jdbc:postgresql://someserver:5432/someDb</connec
> > > > > ti
> > > > > on
> > > > > -u
> > > > > rl>
> > > > > >>>>>>> <user-name>user</user-name>
> > > > > >>>>>>> <password>pwd</password>
> > > > > >>>>>>>
> > > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > > >>>>>>>
> > > > > >>>>>>>This will create the following JNDI location in JBossAS5:
> > > > > >>>>>>>java:/myDS
> > > > > >>>>>>>
> > > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > > >>>>>>>
> > > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY different in
> > > > > >>>>>>>JBossAS6, AS7, Glassfish,
> > > > > TomEE, etc
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>Thus: which JNDI location would you configure in your
> > > > > persistence.xml?
> > > > > >>>>>>>
> > > > > >>>>>>>That's the reason why we came up with the
> > > ConfigurableDataSource.
> > > > > >>>>>>>
> > > > > >>>>>>>Of course, we need to extend this concept and create a
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > > ConfigurableDataSource, XaDataSource {}
> > > > > >>>>>>>
> > > > > >>>>>>>See what I mean?
> > > > > >>>>>>>
> > > > > >>>>>>>LieGrue,
> > > > > >>>>>>>strub
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>>----- Original Message -----
> > > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > > > >>>>>>>> <
> > > > > struberg@yahoo.de>
> > > > > >>>>>>>> Cc:
> > > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>>>> In plain Tomcat or
> > > > > >>>>>>>>>> Jetty servers this needs to be configured in a
> > > > > container-specific way.
> > > > > >>>>>>>>> The problem with the container specific stuff is that
> > > > > >>>>>>>>> every
> > > > > container
> > > > > >>>>>>>> serves the xml configured datasource on a different
> > > > > >>>>>>>> location in
> > > > > JNDI! So you
> > > > > >>>>>>>> cannot provide a container independent implementation
> > > > > >>>>>>>> that way :/
> > > > > >>>>>>>>
> > > > > >>>>>>>> The portable way would be to declare your datasource
> > > > > >>>>>>>> properly via @Resource(name="java:app/Foo",
> > > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > > >>>>>>>>
> > > > > >>>>>>>> Most servers can map those references with little to no
> > > config.
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> -David
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
AW: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Arne Limburg <ar...@openknowledge.de>.
If so, what would be the semantic of such definition?
Btw. that classes would only become CDI beans when the deployment is in the correct project stage. Otherwise we would veto them away, before they become beans...
And, which part of the jee container would scan that class? My guess is, that it would be the responsibility of the CDI implementation. And - just a second guess - they ignore it...
I'll take a look into the JPA spec to see what the official semantic of the usage I proposed would be. But, I am afraid that this is underspecified...
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Sonntag, 6. Mai 2012 15:40
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Cdi is in jee so jee containers scans cdi beans and same for resources (@persistencontext).
Le 6 mai 2012 15:36, "Arne Limburg" <ar...@openknowledge.de> a écrit :
> If not, we can use other annotations, but I think jee containers just
> scan EJBs...
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 15:28
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> Not sure it works in a jee container.
>
> - Romain
> Le 6 mai 2012 15:26, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > You could configure your production jta-datasource in the
> > persistence.xml and add the following bean to your test deployment:
> >
> > @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> > @PersistenceContext(unitName = "myPU", properties =
> > @PersistenceProperty(name = "javax.persistence.nonJtaDataSource",
> > value =
> > "java:/comp/env/myDS"))
> > public class MyIntegrationTestConfiguration { }
> >
> > For local testing, you could even switch off JNDI:
> > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> > @PersistenceContext(unitName = "myPU", properties =
> > {@PersistenceProperty(name = "javax.persistence.transactionType",
> > value = "RESOURCE_LOCAL"),
> >
> > @PersistenceProperty(name =
> > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
> > public class MyDevelopmentConfiguration { }
> >
> > WDYT?
> >
> > Romain,
> > Noone needs to repackage his application, since we can put this
> > properties into a map and use it as the second parameter of
> emf.createEntityManager...
> >
> > - Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 15:14
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> >
> > How do you manage it from persistence.xml if you dont repackage your
> > archive as Mark said?
> >
> > Personally i agree ;)
> >
> > - Romain
> > Le 6 mai 2012 15:06, "Arne Limburg" <ar...@openknowledge.de>
> > a écrit :
> >
> > > OK,
> > > but do we really need a container-independent way for JNDI-DataSources?
> > > What's the use case for it?
> > > The user always knows his container and thus his specific JNDI-name.
> > >
> > > I think we need an easy way for users to configure different
> > > JNDI-DataSources for different deployment scenarios, like
> > > - a JTA-datasource for my JBoss AS 7 in production
> > > - a Non-JTA-datasource from another JNDI-location for the Tomcat
> > > for testing
> > > - a RESOURCE_LOCAL EntityManager for local testing...
> > >
> > > We need to find an easy way for the users to configure the
> > > JNDI-location, but imho we don't need to handle different
> > > JNDI-locations
> > in our code?
> > >
> > > WDYT? Am I missing a use case?
> > >
> > > Cheers,
> > > Arne
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > >
> > > ConfigurableDataSource doesnt solve it. If you build the emf from
> > > persistence info you manage it yourself. It should be IMO a
> > > compatibility mode and spec you be fixed.
> > >
> > > But well, the most important subjects are not here, pagination,
> > > dynamic dao etc are really more valuable.
> > >
> > > - Romain
> > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
> > >
> > > >
> > > >
> > > > The problem here is that this is NOT under our control - this is
> > > > not even CDI related!
> > > >
> > > > You need to _exactly_ specify the JNDI location in your
> > persistence.xml.
> > > > And this info get's parsed by JPA or the EE container at deploy time.
> > > >
> > > >
> > > > Maybe there's a trick with a PersistenceUnitInfo. But since
> > > > those are also managed by the server (and thus show the same
> > > > unspecified
> > > > behaviour) we imo cannot leverage those.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > > >________________________________
> > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > deltaspike-dev@incubator.apache.org
> > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > >
> > > > >
> > > > >I understand. On another side how many differeny locations are
> there?
> > > > Isnt it manageable?
> > > > >- Romain
> > > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit :
> > > > >
> > > > >
> > > > >>
> > > > >>PS: I _fully_ agree that this mess should best get fixed in EE7.
> > > > >>But
> > > > sadly we also need to support older containers!
> > > > >>
> > > > >>I know about folks who have OWB and CODI running on old
> > > > >>WebSphere
> > > > >>6 and
> > > > 7 servers. And others who use OWB on WebLogic 10.3. And those
> > > > companies are big banks, stock exchanges and insurrance
> > > > companies
> > > > - they cannot easily upgrade to a new server...
> > > > >>
> > > > >>LieGrue,
> > > > >>strub
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>>________________________________
> > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <
> > > > deltaspike-dev@incubator.apache.org>
> > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>No, the container is NOT buggy, because it's simply NOT defined!
> > > > >>>That's the whole mess about JNDI...
> > > > >>>
> > > > >>>LieGrue,
> > > > >>>strub
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>________________________________
> > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > >>>>
> > > > >>>>
> > > > >>>>So this container is buggy, report an issue ;) Thinking of
> > > > >>>>it this jndi path issue couldnt be resolved by
> > > > configresolvers in ds?
> > > > >>>>- Romain
> > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a
> écrit :
> > > > >>>>
> > > > >>>>yes, that crashes the container...
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>________________________________
> > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > deltaspike-dev@incubator.apache.org
> > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>Mark, did you try providing a name starting with java:?
> > > > >>>>>>- Romain
> > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a
> > écrit :
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>>
> > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > >>>>>>>
> > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > >>>>>>>
> > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > >>>>>>> <local-tx-datasource>
> > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > >>>>>>>
> > > > <connection-url>jdbc:postgresql://someserver:5432/someDb</connec
> > > > ti
> > > > on
> > > > -u
> > > > rl>
> > > > >>>>>>> <user-name>user</user-name>
> > > > >>>>>>> <password>pwd</password>
> > > > >>>>>>>
> > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > >>>>>>>
> > > > >>>>>>>This will create the following JNDI location in JBossAS5:
> > > > >>>>>>>java:/myDS
> > > > >>>>>>>
> > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > >>>>>>>
> > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY different in
> > > > >>>>>>>JBossAS6, AS7, Glassfish,
> > > > TomEE, etc
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>Thus: which JNDI location would you configure in your
> > > > persistence.xml?
> > > > >>>>>>>
> > > > >>>>>>>That's the reason why we came up with the
> > ConfigurableDataSource.
> > > > >>>>>>>
> > > > >>>>>>>Of course, we need to extend this concept and create a
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > ConfigurableDataSource, XaDataSource {}
> > > > >>>>>>>
> > > > >>>>>>>See what I mean?
> > > > >>>>>>>
> > > > >>>>>>>LieGrue,
> > > > >>>>>>>strub
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>----- Original Message -----
> > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > > >>>>>>>> <
> > > > struberg@yahoo.de>
> > > > >>>>>>>> Cc:
> > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>>> In plain Tomcat or
> > > > >>>>>>>>>> Jetty servers this needs to be configured in a
> > > > container-specific way.
> > > > >>>>>>>>> The problem with the container specific stuff is that
> > > > >>>>>>>>> every
> > > > container
> > > > >>>>>>>> serves the xml configured datasource on a different
> > > > >>>>>>>> location in
> > > > JNDI! So you
> > > > >>>>>>>> cannot provide a container independent implementation
> > > > >>>>>>>> that way :/
> > > > >>>>>>>>
> > > > >>>>>>>> The portable way would be to declare your datasource
> > > > >>>>>>>> properly via @Resource(name="java:app/Foo",
> > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > >>>>>>>>
> > > > >>>>>>>> Most servers can map those references with little to no
> > config.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> -David
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Cdi is in jee so jee containers scans cdi beans and same for resources
(@persistencontext).
Le 6 mai 2012 15:36, "Arne Limburg" <ar...@openknowledge.de> a
écrit :
> If not, we can use other annotations, but I think jee containers just scan
> EJBs...
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 15:28
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
>
> Not sure it works in a jee container.
>
> - Romain
> Le 6 mai 2012 15:26, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > You could configure your production jta-datasource in the
> > persistence.xml and add the following bean to your test deployment:
> >
> > @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> > @PersistenceContext(unitName = "myPU", properties =
> > @PersistenceProperty(name = "javax.persistence.nonJtaDataSource",
> > value =
> > "java:/comp/env/myDS"))
> > public class MyIntegrationTestConfiguration { }
> >
> > For local testing, you could even switch off JNDI:
> > @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> > @PersistenceContext(unitName = "myPU", properties =
> > {@PersistenceProperty(name = "javax.persistence.transactionType",
> > value = "RESOURCE_LOCAL"),
> >
> > @PersistenceProperty(name =
> > "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
> > public class MyDevelopmentConfiguration { }
> >
> > WDYT?
> >
> > Romain,
> > Noone needs to repackage his application, since we can put this
> > properties into a map and use it as the second parameter of
> emf.createEntityManager...
> >
> > - Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 15:14
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
> >
> > How do you manage it from persistence.xml if you dont repackage your
> > archive as Mark said?
> >
> > Personally i agree ;)
> >
> > - Romain
> > Le 6 mai 2012 15:06, "Arne Limburg" <ar...@openknowledge.de> a
> > écrit :
> >
> > > OK,
> > > but do we really need a container-independent way for JNDI-DataSources?
> > > What's the use case for it?
> > > The user always knows his container and thus his specific JNDI-name.
> > >
> > > I think we need an easy way for users to configure different
> > > JNDI-DataSources for different deployment scenarios, like
> > > - a JTA-datasource for my JBoss AS 7 in production
> > > - a Non-JTA-datasource from another JNDI-location for the Tomcat for
> > > testing
> > > - a RESOURCE_LOCAL EntityManager for local testing...
> > >
> > > We need to find an easy way for the users to configure the
> > > JNDI-location, but imho we don't need to handle different
> > > JNDI-locations
> > in our code?
> > >
> > > WDYT? Am I missing a use case?
> > >
> > > Cheers,
> > > Arne
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Sonntag, 6. Mai 2012 14:49
> > > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> > >
> > > ConfigurableDataSource doesnt solve it. If you build the emf from
> > > persistence info you manage it yourself. It should be IMO a
> > > compatibility mode and spec you be fixed.
> > >
> > > But well, the most important subjects are not here, pagination,
> > > dynamic dao etc are really more valuable.
> > >
> > > - Romain
> > > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
> > >
> > > >
> > > >
> > > > The problem here is that this is NOT under our control - this is
> > > > not even CDI related!
> > > >
> > > > You need to _exactly_ specify the JNDI location in your
> > persistence.xml.
> > > > And this info get's parsed by JPA or the EE container at deploy time.
> > > >
> > > >
> > > > Maybe there's a trick with a PersistenceUnitInfo. But since those
> > > > are also managed by the server (and thus show the same unspecified
> > > > behaviour) we imo cannot leverage those.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > > >________________________________
> > > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > > >To: Mark Struberg <st...@yahoo.de>;
> > > > deltaspike-dev@incubator.apache.org
> > > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > >
> > > > >
> > > > >I understand. On another side how many differeny locations are
> there?
> > > > Isnt it manageable?
> > > > >- Romain
> > > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit :
> > > > >
> > > > >
> > > > >>
> > > > >>PS: I _fully_ agree that this mess should best get fixed in EE7.
> > > > >>But
> > > > sadly we also need to support older containers!
> > > > >>
> > > > >>I know about folks who have OWB and CODI running on old
> > > > >>WebSphere
> > > > >>6 and
> > > > 7 servers. And others who use OWB on WebLogic 10.3. And those
> > > > companies are big banks, stock exchanges and insurrance companies
> > > > - they cannot easily upgrade to a new server...
> > > > >>
> > > > >>LieGrue,
> > > > >>strub
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>>________________________________
> > > > >>> From: Mark Struberg <st...@yahoo.de>
> > > > >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <
> > > > deltaspike-dev@incubator.apache.org>
> > > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>No, the container is NOT buggy, because it's simply NOT defined!
> > > > >>>That's the whole mess about JNDI...
> > > > >>>
> > > > >>>LieGrue,
> > > > >>>strub
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>________________________________
> > > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > >>>>
> > > > >>>>
> > > > >>>>So this container is buggy, report an issue ;) Thinking of it
> > > > >>>>this jndi path issue couldnt be resolved by
> > > > configresolvers in ds?
> > > > >>>>- Romain
> > > > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a
> écrit :
> > > > >>>>
> > > > >>>>yes, that crashes the container...
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>________________________________
> > > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > > deltaspike-dev@incubator.apache.org
> > > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>Mark, did you try providing a name starting with java:?
> > > > >>>>>>- Romain
> > > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a
> > écrit :
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>>
> > > > >>>>>>>David, exactly this doesn't work out in practice!
> > > > >>>>>>>
> > > > >>>>>>>look at jboss5 datasource xml as an example:
> > > > >>>>>>>
> > > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > > >>>>>>> <local-tx-datasource>
> > > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > > >>>>>>>
> > > > <connection-url>jdbc:postgresql://someserver:5432/someDb</connecti
> > > > on
> > > > -u
> > > > rl>
> > > > >>>>>>> <user-name>user</user-name>
> > > > >>>>>>> <password>pwd</password>
> > > > >>>>>>>
> > > > <driver-class>org.postgresql.Driver</driver-class>
> > > > >>>>>>> </local-tx-datasource> </datasources>
> > > > >>>>>>>
> > > > >>>>>>>This will create the following JNDI location in JBossAS5:
> > > > >>>>>>>java:/myDS
> > > > >>>>>>>
> > > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > > >>>>>>>
> > > > >>>>>>>Configuring the same in Geronimo gives you
> > > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY different in
> > > > >>>>>>>JBossAS6, AS7, Glassfish,
> > > > TomEE, etc
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>Thus: which JNDI location would you configure in your
> > > > persistence.xml?
> > > > >>>>>>>
> > > > >>>>>>>That's the reason why we came up with the
> > ConfigurableDataSource.
> > > > >>>>>>>
> > > > >>>>>>>Of course, we need to extend this concept and create a
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > > ConfigurableDataSource, XaDataSource {}
> > > > >>>>>>>
> > > > >>>>>>>See what I mean?
> > > > >>>>>>>
> > > > >>>>>>>LieGrue,
> > > > >>>>>>>strub
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>----- Original Message -----
> > > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> > > > struberg@yahoo.de>
> > > > >>>>>>>> Cc:
> > > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>>> In plain Tomcat or
> > > > >>>>>>>>>> Jetty servers this needs to be configured in a
> > > > container-specific way.
> > > > >>>>>>>>> The problem with the container specific stuff is that
> > > > >>>>>>>>> every
> > > > container
> > > > >>>>>>>> serves the xml configured datasource on a different
> > > > >>>>>>>> location in
> > > > JNDI! So you
> > > > >>>>>>>> cannot provide a container independent implementation
> > > > >>>>>>>> that way :/
> > > > >>>>>>>>
> > > > >>>>>>>> The portable way would be to declare your datasource
> > > > >>>>>>>> properly via @Resource(name="java:app/Foo",
> > > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > > >>>>>>>>
> > > > >>>>>>>> Most servers can map those references with little to no
> > config.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> -David
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
AW: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Arne Limburg <ar...@openknowledge.de>.
If not, we can use other annotations, but I think jee containers just scan EJBs...
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Sonntag, 6. Mai 2012 15:28
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: AW: [DISCUSS] deltaspike-jpa module features
Not sure it works in a jee container.
- Romain
Le 6 mai 2012 15:26, "Arne Limburg" <ar...@openknowledge.de> a écrit :
> You could configure your production jta-datasource in the
> persistence.xml and add the following bean to your test deployment:
>
> @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> @PersistenceContext(unitName = "myPU", properties =
> @PersistenceProperty(name = "javax.persistence.nonJtaDataSource",
> value =
> "java:/comp/env/myDS"))
> public class MyIntegrationTestConfiguration { }
>
> For local testing, you could even switch off JNDI:
> @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> @PersistenceContext(unitName = "myPU", properties =
> {@PersistenceProperty(name = "javax.persistence.transactionType",
> value = "RESOURCE_LOCAL"),
>
> @PersistenceProperty(name =
> "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
> public class MyDevelopmentConfiguration { }
>
> WDYT?
>
> Romain,
> Noone needs to repackage his application, since we can put this
> properties into a map and use it as the second parameter of emf.createEntityManager...
>
> - Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 15:14
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
>
> How do you manage it from persistence.xml if you dont repackage your
> archive as Mark said?
>
> Personally i agree ;)
>
> - Romain
> Le 6 mai 2012 15:06, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > OK,
> > but do we really need a container-independent way for JNDI-DataSources?
> > What's the use case for it?
> > The user always knows his container and thus his specific JNDI-name.
> >
> > I think we need an easy way for users to configure different
> > JNDI-DataSources for different deployment scenarios, like
> > - a JTA-datasource for my JBoss AS 7 in production
> > - a Non-JTA-datasource from another JNDI-location for the Tomcat for
> > testing
> > - a RESOURCE_LOCAL EntityManager for local testing...
> >
> > We need to find an easy way for the users to configure the
> > JNDI-location, but imho we don't need to handle different
> > JNDI-locations
> in our code?
> >
> > WDYT? Am I missing a use case?
> >
> > Cheers,
> > Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 14:49
> > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> >
> > ConfigurableDataSource doesnt solve it. If you build the emf from
> > persistence info you manage it yourself. It should be IMO a
> > compatibility mode and spec you be fixed.
> >
> > But well, the most important subjects are not here, pagination,
> > dynamic dao etc are really more valuable.
> >
> > - Romain
> > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
> >
> > >
> > >
> > > The problem here is that this is NOT under our control - this is
> > > not even CDI related!
> > >
> > > You need to _exactly_ specify the JNDI location in your
> persistence.xml.
> > > And this info get's parsed by JPA or the EE container at deploy time.
> > >
> > >
> > > Maybe there's a trick with a PersistenceUnitInfo. But since those
> > > are also managed by the server (and thus show the same unspecified
> > > behaviour) we imo cannot leverage those.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > >________________________________
> > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > >To: Mark Struberg <st...@yahoo.de>;
> > > deltaspike-dev@incubator.apache.org
> > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > >
> > > >
> > > >I understand. On another side how many differeny locations are there?
> > > Isnt it manageable?
> > > >- Romain
> > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit :
> > > >
> > > >
> > > >>
> > > >>PS: I _fully_ agree that this mess should best get fixed in EE7.
> > > >>But
> > > sadly we also need to support older containers!
> > > >>
> > > >>I know about folks who have OWB and CODI running on old
> > > >>WebSphere
> > > >>6 and
> > > 7 servers. And others who use OWB on WebLogic 10.3. And those
> > > companies are big banks, stock exchanges and insurrance companies
> > > - they cannot easily upgrade to a new server...
> > > >>
> > > >>LieGrue,
> > > >>strub
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>>________________________________
> > > >>> From: Mark Struberg <st...@yahoo.de>
> > > >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <
> > > deltaspike-dev@incubator.apache.org>
> > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > >>>
> > > >>>
> > > >>>
> > > >>>No, the container is NOT buggy, because it's simply NOT defined!
> > > >>>That's the whole mess about JNDI...
> > > >>>
> > > >>>LieGrue,
> > > >>>strub
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>________________________________
> > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > >>>>
> > > >>>>
> > > >>>>So this container is buggy, report an issue ;) Thinking of it
> > > >>>>this jndi path issue couldnt be resolved by
> > > configresolvers in ds?
> > > >>>>- Romain
> > > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a écrit :
> > > >>>>
> > > >>>>yes, that crashes the container...
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>________________________________
> > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > deltaspike-dev@incubator.apache.org
> > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>Mark, did you try providing a name starting with java:?
> > > >>>>>>- Romain
> > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a
> écrit :
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>>David, exactly this doesn't work out in practice!
> > > >>>>>>>
> > > >>>>>>>look at jboss5 datasource xml as an example:
> > > >>>>>>>
> > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > >>>>>>> <local-tx-datasource>
> > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > >>>>>>>
> > > <connection-url>jdbc:postgresql://someserver:5432/someDb</connecti
> > > on
> > > -u
> > > rl>
> > > >>>>>>> <user-name>user</user-name>
> > > >>>>>>> <password>pwd</password>
> > > >>>>>>>
> > > <driver-class>org.postgresql.Driver</driver-class>
> > > >>>>>>> </local-tx-datasource> </datasources>
> > > >>>>>>>
> > > >>>>>>>This will create the following JNDI location in JBossAS5:
> > > >>>>>>>java:/myDS
> > > >>>>>>>
> > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > >>>>>>>
> > > >>>>>>>Configuring the same in Geronimo gives you
> > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY different in
> > > >>>>>>>JBossAS6, AS7, Glassfish,
> > > TomEE, etc
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>Thus: which JNDI location would you configure in your
> > > persistence.xml?
> > > >>>>>>>
> > > >>>>>>>That's the reason why we came up with the
> ConfigurableDataSource.
> > > >>>>>>>
> > > >>>>>>>Of course, we need to extend this concept and create a
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > ConfigurableDataSource, XaDataSource {}
> > > >>>>>>>
> > > >>>>>>>See what I mean?
> > > >>>>>>>
> > > >>>>>>>LieGrue,
> > > >>>>>>>strub
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>----- Original Message -----
> > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> > > struberg@yahoo.de>
> > > >>>>>>>> Cc:
> > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > >>>>>>>>
> > > >>>>>>>>>> In plain Tomcat or
> > > >>>>>>>>>> Jetty servers this needs to be configured in a
> > > container-specific way.
> > > >>>>>>>>> The problem with the container specific stuff is that
> > > >>>>>>>>> every
> > > container
> > > >>>>>>>> serves the xml configured datasource on a different
> > > >>>>>>>> location in
> > > JNDI! So you
> > > >>>>>>>> cannot provide a container independent implementation
> > > >>>>>>>> that way :/
> > > >>>>>>>>
> > > >>>>>>>> The portable way would be to declare your datasource
> > > >>>>>>>> properly via @Resource(name="java:app/Foo",
> > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > >>>>>>>>
> > > >>>>>>>> Most servers can map those references with little to no
> config.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> -David
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >
> > >
> >
>
Re: AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Not sure it works in a jee container.
- Romain
Le 6 mai 2012 15:26, "Arne Limburg" <ar...@openknowledge.de> a
écrit :
> You could configure your production jta-datasource in the persistence.xml
> and add the following bean to your test deployment:
>
> @Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
> @PersistenceContext(unitName = "myPU", properties =
> @PersistenceProperty(name = "javax.persistence.nonJtaDataSource", value =
> "java:/comp/env/myDS"))
> public class MyIntegrationTestConfiguration {
> }
>
> For local testing, you could even switch off JNDI:
> @Exclude(exceptIfProjectStage = ProjectStage.Development.class)
> @PersistenceContext(unitName = "myPU", properties =
> {@PersistenceProperty(name = "javax.persistence.transactionType", value =
> "RESOURCE_LOCAL"),
>
> @PersistenceProperty(name =
> "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
> public class MyDevelopmentConfiguration {
> }
>
> WDYT?
>
> Romain,
> Noone needs to repackage his application, since we can put this properties
> into a map and use it as the second parameter of emf.createEntityManager...
>
> - Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 15:14
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
>
> How do you manage it from persistence.xml if you dont repackage your
> archive as Mark said?
>
> Personally i agree ;)
>
> - Romain
> Le 6 mai 2012 15:06, "Arne Limburg" <ar...@openknowledge.de> a
> écrit :
>
> > OK,
> > but do we really need a container-independent way for JNDI-DataSources?
> > What's the use case for it?
> > The user always knows his container and thus his specific JNDI-name.
> >
> > I think we need an easy way for users to configure different
> > JNDI-DataSources for different deployment scenarios, like
> > - a JTA-datasource for my JBoss AS 7 in production
> > - a Non-JTA-datasource from another JNDI-location for the Tomcat for
> > testing
> > - a RESOURCE_LOCAL EntityManager for local testing...
> >
> > We need to find an easy way for the users to configure the
> > JNDI-location, but imho we don't need to handle different JNDI-locations
> in our code?
> >
> > WDYT? Am I missing a use case?
> >
> > Cheers,
> > Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 14:49
> > An: Mark Struberg; deltaspike-dev@incubator.apache.org
> > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> >
> > ConfigurableDataSource doesnt solve it. If you build the emf from
> > persistence info you manage it yourself. It should be IMO a
> > compatibility mode and spec you be fixed.
> >
> > But well, the most important subjects are not here, pagination,
> > dynamic dao etc are really more valuable.
> >
> > - Romain
> > Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
> >
> > >
> > >
> > > The problem here is that this is NOT under our control - this is not
> > > even CDI related!
> > >
> > > You need to _exactly_ specify the JNDI location in your
> persistence.xml.
> > > And this info get's parsed by JPA or the EE container at deploy time.
> > >
> > >
> > > Maybe there's a trick with a PersistenceUnitInfo. But since those
> > > are also managed by the server (and thus show the same unspecified
> > > behaviour) we imo cannot leverage those.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > >________________________________
> > > > From: Romain Manni-Bucau <rm...@gmail.com>
> > > >To: Mark Struberg <st...@yahoo.de>;
> > > deltaspike-dev@incubator.apache.org
> > > >Sent: Sunday, May 6, 2012 2:37 PM
> > > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > >
> > > >
> > > >I understand. On another side how many differeny locations are there?
> > > Isnt it manageable?
> > > >- Romain
> > > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit :
> > > >
> > > >
> > > >>
> > > >>PS: I _fully_ agree that this mess should best get fixed in EE7.
> > > >>But
> > > sadly we also need to support older containers!
> > > >>
> > > >>I know about folks who have OWB and CODI running on old WebSphere
> > > >>6 and
> > > 7 servers. And others who use OWB on WebLogic 10.3. And those
> > > companies are big banks, stock exchanges and insurrance companies -
> > > they cannot easily upgrade to a new server...
> > > >>
> > > >>LieGrue,
> > > >>strub
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>>________________________________
> > > >>> From: Mark Struberg <st...@yahoo.de>
> > > >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <
> > > deltaspike-dev@incubator.apache.org>
> > > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > >>>
> > > >>>
> > > >>>
> > > >>>No, the container is NOT buggy, because it's simply NOT defined!
> > > >>>That's the whole mess about JNDI...
> > > >>>
> > > >>>LieGrue,
> > > >>>strub
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>________________________________
> > > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > >>>>To: Mark Struberg <st...@yahoo.de>
> > > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > >>>>
> > > >>>>
> > > >>>>So this container is buggy, report an issue ;) Thinking of it
> > > >>>>this jndi path issue couldnt be resolved by
> > > configresolvers in ds?
> > > >>>>- Romain
> > > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a écrit :
> > > >>>>
> > > >>>>yes, that crashes the container...
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>________________________________
> > > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > > deltaspike-dev@incubator.apache.org
> > > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>Mark, did you try providing a name starting with java:?
> > > >>>>>>- Romain
> > > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a
> écrit :
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>
> > > >>>>>>>David, exactly this doesn't work out in practice!
> > > >>>>>>>
> > > >>>>>>>look at jboss5 datasource xml as an example:
> > > >>>>>>>
> > > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > > >>>>>>> <local-tx-datasource>
> > > >>>>>>> <jndi-name>myDS</jndi-name>
> > > >>>>>>>
> > > <connection-url>jdbc:postgresql://someserver:5432/someDb</connection
> > > -u
> > > rl>
> > > >>>>>>> <user-name>user</user-name>
> > > >>>>>>> <password>pwd</password>
> > > >>>>>>>
> > > <driver-class>org.postgresql.Driver</driver-class>
> > > >>>>>>> </local-tx-datasource> </datasources>
> > > >>>>>>>
> > > >>>>>>>This will create the following JNDI location in JBossAS5:
> > > >>>>>>>java:/myDS
> > > >>>>>>>
> > > >>>>>>>NO comp, NO lang, NO other qualifier.
> > > >>>>>>>
> > > >>>>>>>Configuring the same in Geronimo gives you
> > > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY different in
> > > >>>>>>>JBossAS6, AS7, Glassfish,
> > > TomEE, etc
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>Thus: which JNDI location would you configure in your
> > > persistence.xml?
> > > >>>>>>>
> > > >>>>>>>That's the reason why we came up with the
> ConfigurableDataSource.
> > > >>>>>>>
> > > >>>>>>>Of course, we need to extend this concept and create a
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>public interface ConfigurableXaDataSource extends
> > > ConfigurableDataSource, XaDataSource {}
> > > >>>>>>>
> > > >>>>>>>See what I mean?
> > > >>>>>>>
> > > >>>>>>>LieGrue,
> > > >>>>>>>strub
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>----- Original Message -----
> > > >>>>>>>> From: David Blevins <da...@gmail.com>
> > > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> > > struberg@yahoo.de>
> > > >>>>>>>> Cc:
> > > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > > >>>>>>>>
> > > >>>>>>>>>> In plain Tomcat or
> > > >>>>>>>>>> Jetty servers this needs to be configured in a
> > > container-specific way.
> > > >>>>>>>>> The problem with the container specific stuff is that
> > > >>>>>>>>> every
> > > container
> > > >>>>>>>> serves the xml configured datasource on a different
> > > >>>>>>>> location in
> > > JNDI! So you
> > > >>>>>>>> cannot provide a container independent implementation that
> > > >>>>>>>> way :/
> > > >>>>>>>>
> > > >>>>>>>> The portable way would be to declare your datasource
> > > >>>>>>>> properly via @Resource(name="java:app/Foo",
> > > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > > >>>>>>>>
> > > >>>>>>>> Most servers can map those references with little to no
> config.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> -David
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >
> > >
> >
>
AW: AW: [DISCUSS] deltaspike-jpa module features
Posted by Arne Limburg <ar...@openknowledge.de>.
You could configure your production jta-datasource in the persistence.xml and add the following bean to your test deployment:
@Exclude(exceptIfProjectStage = ProjectStage.IntegrationTest.class)
@PersistenceContext(unitName = "myPU", properties = @PersistenceProperty(name = "javax.persistence.nonJtaDataSource", value = "java:/comp/env/myDS"))
public class MyIntegrationTestConfiguration {
}
For local testing, you could even switch off JNDI:
@Exclude(exceptIfProjectStage = ProjectStage.Development.class)
@PersistenceContext(unitName = "myPU", properties = {@PersistenceProperty(name = "javax.persistence.transactionType", value = "RESOURCE_LOCAL"),
@PersistenceProperty(name = "javax.persistence.jdbc.url", value = "jdbc:h2:mem:myDB"), ...})
public class MyDevelopmentConfiguration {
}
WDYT?
Romain,
Noone needs to repackage his application, since we can put this properties into a map and use it as the second parameter of emf.createEntityManager...
- Arne
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Sonntag, 6. Mai 2012 15:14
An: deltaspike-dev@incubator.apache.org
Betreff: Re: AW: [DISCUSS] deltaspike-jpa module features
How do you manage it from persistence.xml if you dont repackage your archive as Mark said?
Personally i agree ;)
- Romain
Le 6 mai 2012 15:06, "Arne Limburg" <ar...@openknowledge.de> a écrit :
> OK,
> but do we really need a container-independent way for JNDI-DataSources?
> What's the use case for it?
> The user always knows his container and thus his specific JNDI-name.
>
> I think we need an easy way for users to configure different
> JNDI-DataSources for different deployment scenarios, like
> - a JTA-datasource for my JBoss AS 7 in production
> - a Non-JTA-datasource from another JNDI-location for the Tomcat for
> testing
> - a RESOURCE_LOCAL EntityManager for local testing...
>
> We need to find an easy way for the users to configure the
> JNDI-location, but imho we don't need to handle different JNDI-locations in our code?
>
> WDYT? Am I missing a use case?
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 14:49
> An: Mark Struberg; deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS] deltaspike-jpa module features
>
> ConfigurableDataSource doesnt solve it. If you build the emf from
> persistence info you manage it yourself. It should be IMO a
> compatibility mode and spec you be fixed.
>
> But well, the most important subjects are not here, pagination,
> dynamic dao etc are really more valuable.
>
> - Romain
> Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
>
> >
> >
> > The problem here is that this is NOT under our control - this is not
> > even CDI related!
> >
> > You need to _exactly_ specify the JNDI location in your persistence.xml.
> > And this info get's parsed by JPA or the EE container at deploy time.
> >
> >
> > Maybe there's a trick with a PersistenceUnitInfo. But since those
> > are also managed by the server (and thus show the same unspecified
> > behaviour) we imo cannot leverage those.
> >
> > LieGrue,
> > strub
> >
> >
> > >________________________________
> > > From: Romain Manni-Bucau <rm...@gmail.com>
> > >To: Mark Struberg <st...@yahoo.de>;
> > deltaspike-dev@incubator.apache.org
> > >Sent: Sunday, May 6, 2012 2:37 PM
> > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > >
> > >
> > >I understand. On another side how many differeny locations are there?
> > Isnt it manageable?
> > >- Romain
> > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit :
> > >
> > >
> > >>
> > >>PS: I _fully_ agree that this mess should best get fixed in EE7.
> > >>But
> > sadly we also need to support older containers!
> > >>
> > >>I know about folks who have OWB and CODI running on old WebSphere
> > >>6 and
> > 7 servers. And others who use OWB on WebLogic 10.3. And those
> > companies are big banks, stock exchanges and insurrance companies -
> > they cannot easily upgrade to a new server...
> > >>
> > >>LieGrue,
> > >>strub
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>>________________________________
> > >>> From: Mark Struberg <st...@yahoo.de>
> > >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <
> > deltaspike-dev@incubator.apache.org>
> > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > >>>
> > >>>
> > >>>
> > >>>No, the container is NOT buggy, because it's simply NOT defined!
> > >>>That's the whole mess about JNDI...
> > >>>
> > >>>LieGrue,
> > >>>strub
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>________________________________
> > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > >>>>To: Mark Struberg <st...@yahoo.de>
> > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > >>>>
> > >>>>
> > >>>>So this container is buggy, report an issue ;) Thinking of it
> > >>>>this jndi path issue couldnt be resolved by
> > configresolvers in ds?
> > >>>>- Romain
> > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a écrit :
> > >>>>
> > >>>>yes, that crashes the container...
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>________________________________
> > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > deltaspike-dev@incubator.apache.org
> > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > >>>>>>
> > >>>>>>
> > >>>>>>Mark, did you try providing a name starting with java:?
> > >>>>>>- Romain
> > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a écrit :
> > >>>>>>
> > >>>>>>
> > >>>>>>>
> > >>>>>>>David, exactly this doesn't work out in practice!
> > >>>>>>>
> > >>>>>>>look at jboss5 datasource xml as an example:
> > >>>>>>>
> > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > >>>>>>> <local-tx-datasource>
> > >>>>>>> <jndi-name>myDS</jndi-name>
> > >>>>>>>
> > <connection-url>jdbc:postgresql://someserver:5432/someDb</connection
> > -u
> > rl>
> > >>>>>>> <user-name>user</user-name>
> > >>>>>>> <password>pwd</password>
> > >>>>>>>
> > <driver-class>org.postgresql.Driver</driver-class>
> > >>>>>>> </local-tx-datasource> </datasources>
> > >>>>>>>
> > >>>>>>>This will create the following JNDI location in JBossAS5:
> > >>>>>>>java:/myDS
> > >>>>>>>
> > >>>>>>>NO comp, NO lang, NO other qualifier.
> > >>>>>>>
> > >>>>>>>Configuring the same in Geronimo gives you
> > >>>>>>>java:/comp/env/myDS and it's again COMPLETEY different in
> > >>>>>>>JBossAS6, AS7, Glassfish,
> > TomEE, etc
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>Thus: which JNDI location would you configure in your
> > persistence.xml?
> > >>>>>>>
> > >>>>>>>That's the reason why we came up with the ConfigurableDataSource.
> > >>>>>>>
> > >>>>>>>Of course, we need to extend this concept and create a
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>public interface ConfigurableXaDataSource extends
> > ConfigurableDataSource, XaDataSource {}
> > >>>>>>>
> > >>>>>>>See what I mean?
> > >>>>>>>
> > >>>>>>>LieGrue,
> > >>>>>>>strub
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>----- Original Message -----
> > >>>>>>>> From: David Blevins <da...@gmail.com>
> > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> > struberg@yahoo.de>
> > >>>>>>>> Cc:
> > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > >>>>>>>>
> > >>>>>>>>>> In plain Tomcat or
> > >>>>>>>>>> Jetty servers this needs to be configured in a
> > container-specific way.
> > >>>>>>>>> The problem with the container specific stuff is that
> > >>>>>>>>> every
> > container
> > >>>>>>>> serves the xml configured datasource on a different
> > >>>>>>>> location in
> > JNDI! So you
> > >>>>>>>> cannot provide a container independent implementation that
> > >>>>>>>> way :/
> > >>>>>>>>
> > >>>>>>>> The portable way would be to declare your datasource
> > >>>>>>>> properly via @Resource(name="java:app/Foo",
> > >>>>>>>> type=DataSource.class) or via <resource-ref> xml.
> > >>>>>>>>
> > >>>>>>>> Most servers can map those references with little to no config.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> -David
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > >
> >
>
Re: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
How do you manage it from persistence.xml if you dont repackage your
archive as Mark said?
Personally i agree ;)
- Romain
Le 6 mai 2012 15:06, "Arne Limburg" <ar...@openknowledge.de> a
écrit :
> OK,
> but do we really need a container-independent way for JNDI-DataSources?
> What's the use case for it?
> The user always knows his container and thus his specific JNDI-name.
>
> I think we need an easy way for users to configure different
> JNDI-DataSources for different deployment scenarios, like
> - a JTA-datasource for my JBoss AS 7 in production
> - a Non-JTA-datasource from another JNDI-location for the Tomcat for
> testing
> - a RESOURCE_LOCAL EntityManager for local testing...
>
> We need to find an easy way for the users to configure the JNDI-location,
> but imho we don't need to handle different JNDI-locations in our code?
>
> WDYT? Am I missing a use case?
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 14:49
> An: Mark Struberg; deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS] deltaspike-jpa module features
>
> ConfigurableDataSource doesnt solve it. If you build the emf from
> persistence info you manage it yourself. It should be IMO a compatibility
> mode and spec you be fixed.
>
> But well, the most important subjects are not here, pagination, dynamic
> dao etc are really more valuable.
>
> - Romain
> Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
>
> >
> >
> > The problem here is that this is NOT under our control - this is not
> > even CDI related!
> >
> > You need to _exactly_ specify the JNDI location in your persistence.xml.
> > And this info get's parsed by JPA or the EE container at deploy time.
> >
> >
> > Maybe there's a trick with a PersistenceUnitInfo. But since those are
> > also managed by the server (and thus show the same unspecified
> > behaviour) we imo cannot leverage those.
> >
> > LieGrue,
> > strub
> >
> >
> > >________________________________
> > > From: Romain Manni-Bucau <rm...@gmail.com>
> > >To: Mark Struberg <st...@yahoo.de>;
> > deltaspike-dev@incubator.apache.org
> > >Sent: Sunday, May 6, 2012 2:37 PM
> > >Subject: Re: [DISCUSS] deltaspike-jpa module features
> > >
> > >
> > >I understand. On another side how many differeny locations are there?
> > Isnt it manageable?
> > >- Romain
> > >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit :
> > >
> > >
> > >>
> > >>PS: I _fully_ agree that this mess should best get fixed in EE7. But
> > sadly we also need to support older containers!
> > >>
> > >>I know about folks who have OWB and CODI running on old WebSphere 6
> > >>and
> > 7 servers. And others who use OWB on WebLogic 10.3. And those
> > companies are big banks, stock exchanges and insurrance companies -
> > they cannot easily upgrade to a new server...
> > >>
> > >>LieGrue,
> > >>strub
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>>________________________________
> > >>> From: Mark Struberg <st...@yahoo.de>
> > >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <
> > deltaspike-dev@incubator.apache.org>
> > >>>Sent: Sunday, May 6, 2012 2:14 PM
> > >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > >>>
> > >>>
> > >>>
> > >>>No, the container is NOT buggy, because it's simply NOT defined!
> > >>>That's the whole mess about JNDI...
> > >>>
> > >>>LieGrue,
> > >>>strub
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>________________________________
> > >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > >>>>To: Mark Struberg <st...@yahoo.de>
> > >>>>Sent: Sunday, May 6, 2012 2:01 PM
> > >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > >>>>
> > >>>>
> > >>>>So this container is buggy, report an issue ;) Thinking of it this
> > >>>>jndi path issue couldnt be resolved by
> > configresolvers in ds?
> > >>>>- Romain
> > >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a écrit :
> > >>>>
> > >>>>yes, that crashes the container...
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>________________________________
> > >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> > >>>>>>To: Mark Struberg <st...@yahoo.de>;
> > deltaspike-dev@incubator.apache.org
> > >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> > >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> > >>>>>>
> > >>>>>>
> > >>>>>>Mark, did you try providing a name starting with java:?
> > >>>>>>- Romain
> > >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a écrit :
> > >>>>>>
> > >>>>>>
> > >>>>>>>
> > >>>>>>>David, exactly this doesn't work out in practice!
> > >>>>>>>
> > >>>>>>>look at jboss5 datasource xml as an example:
> > >>>>>>>
> > >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> > >>>>>>> <local-tx-datasource>
> > >>>>>>> <jndi-name>myDS</jndi-name>
> > >>>>>>>
> > <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-u
> > rl>
> > >>>>>>> <user-name>user</user-name>
> > >>>>>>> <password>pwd</password>
> > >>>>>>>
> > <driver-class>org.postgresql.Driver</driver-class>
> > >>>>>>> </local-tx-datasource>
> > >>>>>>></datasources>
> > >>>>>>>
> > >>>>>>>This will create the following JNDI location in JBossAS5:
> > >>>>>>>java:/myDS
> > >>>>>>>
> > >>>>>>>NO comp, NO lang, NO other qualifier.
> > >>>>>>>
> > >>>>>>>Configuring the same in Geronimo gives you java:/comp/env/myDS
> > >>>>>>>and it's again COMPLETEY different in JBossAS6, AS7, Glassfish,
> > TomEE, etc
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>Thus: which JNDI location would you configure in your
> > persistence.xml?
> > >>>>>>>
> > >>>>>>>That's the reason why we came up with the ConfigurableDataSource.
> > >>>>>>>
> > >>>>>>>Of course, we need to extend this concept and create a
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>public interface ConfigurableXaDataSource extends
> > ConfigurableDataSource, XaDataSource {}
> > >>>>>>>
> > >>>>>>>See what I mean?
> > >>>>>>>
> > >>>>>>>LieGrue,
> > >>>>>>>strub
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>----- Original Message -----
> > >>>>>>>> From: David Blevins <da...@gmail.com>
> > >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> > struberg@yahoo.de>
> > >>>>>>>> Cc:
> > >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> > >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> > >>>>>>>>
> > >>>>>>>>>> In plain Tomcat or
> > >>>>>>>>>> Jetty servers this needs to be configured in a
> > container-specific way.
> > >>>>>>>>> The problem with the container specific stuff is that every
> > container
> > >>>>>>>> serves the xml configured datasource on a different location
> > >>>>>>>> in
> > JNDI! So you
> > >>>>>>>> cannot provide a container independent implementation that
> > >>>>>>>> way :/
> > >>>>>>>>
> > >>>>>>>> The portable way would be to declare your datasource properly
> > >>>>>>>> via @Resource(name="java:app/Foo", type=DataSource.class) or
> > >>>>>>>> via <resource-ref> xml.
> > >>>>>>>>
> > >>>>>>>> Most servers can map those references with little to no config.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> -David
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > >
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
i still think that's possible but a bit tricky, EE7 can help it to be
easier.
- Romain
2012/5/7 Mark Struberg <st...@yahoo.de>
> DeltaSpike aims to be a solution for NOW. We cannot wait for a future spec
> change (which might or might NOT happen).
> Of course we can give them feedback and adopt our features accordingly
> (after the spec got implemented).
>
> But our main focus is certainly on EE6 containers and creating components
> which are useful for productive systems now and yet.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org
> > Cc:
> > Sent: Monday, May 7, 2012 12:10 AM
> > Subject: Re: [DISCUSS] deltaspike-jpa module features
> >
> >t he issue is at spec level, IMO DS shouldnt be a container too much
> > otherwise it will replace the specs so if you have such an issue update
> the
> > spec to make it easier if today it is not.
> >
> > - Romain
> >
> >
> > 2012/5/7 David Blevins <da...@gmail.com>
> >
> >>
> >> On May 6, 2012, at 2:58 PM, Mark Struberg wrote:
> >>
> >> > Well, I certainly agree that EE containers are actually much less
> >> compatible as lots of users think.
> >> >
> >> > But still there are use cases where you like to use different JNDI
> >> locations.
> >> >
> >> >
> >> > I e.g. know of a scenario in a big swiss bank which has tight
> security
> >> roles. And they have _explicitely_ configured their WebLogic to use
> >> different JNDI locations for DataSources (and they are also only
> available
> >> via doPrivileged() wrappers)
> >>
> >> I'm not sure I would know what to fix about Java EE based on the above
> >> description. The application choses 100% of their own JNDI names and
> those
> >> can be made portable. It's possible to use indirection and effectively
> >> "symlink". All of this can be done external to the application.
> >>
> >> How does that not cover the described scenario?
> >>
> >>
> >> -David
> >>
> >> > ----- Original Message -----
> >> >> From: Arne Limburg <ar...@openknowledge.de>
> >> >> To: "deltaspike-dev@incubator.apache.org" <
> >> deltaspike-dev@incubator.apache.org>; Mark Struberg
> > <st...@yahoo.de>
> >> >> Cc:
> >> >> Sent: Sunday, May 6, 2012 3:07 PM
> >> >> Subject: AW: [DISCUSS] deltaspike-jpa module features
> >> >>
> >> >> OK,
> >> >> but do we really need a container-independent way for
> > JNDI-DataSources?
> >> >> What's the use case for it?
> >> >> The user always knows his container and thus his specific
> > JNDI-name.
> >> >>
> >> >> I think we need an easy way for users to configure different
> >> JNDI-DataSources
> >> >> for different deployment scenarios, like
> >> >> - a JTA-datasource for my JBoss AS 7 in production
> >> >> - a Non-JTA-datasource from another JNDI-location for the Tomcat
> > for
> >> testing
> >> >> - a RESOURCE_LOCAL EntityManager for local testing...
> >> >>
> >> >> We need to find an easy way for the users to configure the
> >> JNDI-location, but
> >> >> imho we don't need to handle different JNDI-locations in our
> > code?
> >> >>
> >> >> WDYT? Am I missing a use case?
> >> >>
> >> >> Cheers,
> >> >> Arne
> >> >>
> >> >> -----Ursprüngliche Nachricht-----
> >> >> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> >> >> Gesendet: Sonntag, 6. Mai 2012 14:49
> >> >> An: Mark Struberg; deltaspike-dev@incubator.apache.org
> >> >> Betreff: Re: [DISCUSS] deltaspike-jpa module features
> >> >>
> >> >> ConfigurableDataSource doesnt solve it. If you build the emf from
> >> persistence
> >> >> info you manage it yourself. It should be IMO a compatibility mode
> > and
> >> spec you
> >> >> be fixed.
> >> >>
> >> >> But well, the most important subjects are not here, pagination,
> > dynamic
> >> dao etc
> >> >> are really more valuable.
> >> >>
> >> >> - Romain
> >> >> Le 6 mai 2012 14:44, "Mark Struberg"
> > <st...@yahoo.de> a écrit
> >> >> :
> >> >>
> >> >>>
> >> >>>
> >> >>> The problem here is that this is NOT under our control - this
> > is not
> >> >>> even CDI related!
> >> >>>
> >> >>> You need to _exactly_ specify the JNDI location in your
> >> persistence.xml.
> >> >>> And this info get's parsed by JPA or the EE container at
> > deploy time.
> >> >>>
> >> >>>
> >> >>> Maybe there's a trick with a PersistenceUnitInfo. But
> > since those are
> >> >>> also managed by the server (and thus show the same unspecified
> >> >>> behaviour) we imo cannot leverage those.
> >> >>>
> >> >>> LieGrue,
> >> >>> strub
> >> >>>
> >> >>>
> >> >>>> ________________________________
> >> >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> >> >>>> To: Mark Struberg <st...@yahoo.de>;
> >> >>> deltaspike-dev@incubator.apache.org
> >> >>>> Sent: Sunday, May 6, 2012 2:37 PM
> >> >>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >> >>>>
> >> >>>>
> >> >>>> I understand. On another side how many differeny locations
> > are there?
> >> >>> Isnt it manageable?
> >> >>>> - Romain
> >> >>>> Le 6 mai 2012 14:29, "Mark Struberg"
> >> >> <st...@yahoo.de> a écrit :
> >> >>>>
> >> >>>>
> >> >>>>>
> >> >>>>> PS: I _fully_ agree that this mess should best get
> > fixed in EE7.
> >> >> But
> >> >>> sadly we also need to support older containers!
> >> >>>>>
> >> >>>>> I know about folks who have OWB and CODI running on
> > old WebSphere 6
> >> >>
> >> >>>>> and
> >> >>> 7 servers. And others who use OWB on WebLogic 10.3. And those
> >> >>> companies are big banks, stock exchanges and insurrance
> > companies -
> >> >>> they cannot easily upgrade to a new server...
> >> >>>>>
> >> >>>>> LieGrue,
> >> >>>>> strub
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>> ________________________________
> >> >>>>>> From: Mark Struberg <st...@yahoo.de>
> >> >>>>>> To: Romain Manni-Bucau
> > <rm...@gmail.com>;
> >> >> deltaspike <
> >> >>> deltaspike-dev@incubator.apache.org>
> >> >>>>>> Sent: Sunday, May 6, 2012 2:14 PM
> >> >>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> > features
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> No, the container is NOT buggy, because it's
> > simply NOT
> >> >> defined!
> >> >>>>>> That's the whole mess about JNDI...
> >> >>>>>>
> >> >>>>>> LieGrue,
> >> >>>>>> strub
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> ________________________________
> >> >>>>>>> From: Romain Manni-Bucau
> > <rm...@gmail.com>
> >> >>>>>>> To: Mark Struberg <st...@yahoo.de>
> >> >>>>>>> Sent: Sunday, May 6, 2012 2:01 PM
> >> >>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> > features
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> So this container is buggy, report an issue ;)
> > Thinking of
> >> >> it this
> >> >>>>>>> jndi path issue couldnt be resolved by
> >> >>> configresolvers in ds?
> >> >>>>>>> - Romain
> >> >>>>>>> Le 6 mai 2012 13:58, "Mark Struberg"
> >> >> <st...@yahoo.de> a écrit :
> >> >>>>>>>
> >> >>>>>>> yes, that crashes the container...
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>> ________________________________
> >> >>>>>>>>> From: Romain Manni-Bucau
> >> >> <rm...@gmail.com>
> >> >>>>>>>>> To: Mark Struberg
> > <st...@yahoo.de>;
> >> >>> deltaspike-dev@incubator.apache.org
> >> >>>>>>>>> Sent: Sunday, May 6, 2012 1:52 PM
> >> >>>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa
> > module
> >> >> features
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> Mark, did you try providing a name
> > starting with
> >> >> java:?
> >> >>>>>>>>> - Romain
> >> >>>>>>>>> Le 6 mai 2012 13:49, "Mark
> > Struberg"
> >> >> <st...@yahoo.de> a écrit :
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>> David, exactly this doesn't
> > work out in
> >> >> practice!
> >> >>>>>>>>>>
> >> >>>>>>>>>> look at jboss5 datasource xml as
> > an example:
> >> >>>>>>>>>>
> >> >>>>>>>>>> <?xml version="1.0"
> >> >> encoding="UTF-8"?> <datasources>
> >> >>>>>>>>>>
> > <local-tx-datasource>
> >> >>>>>>>>>>
> >> >> <jndi-name>myDS</jndi-name>
> >> >>>>>>>>>>
> >> >>>
> >> >>
> > <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-u
> >> >>> rl>
> >> >>>>>>>>>>
> >> >> <user-name>user</user-name>
> >> >>>>>>>>>>
> >> >> <password>pwd</password>
> >> >>>>>>>>>>
> >> >>> <driver-class>org.postgresql.Driver</driver-class>
> >> >>>>>>>>>>
> > </local-tx-datasource>
> >> >>>>>>>>>> </datasources>
> >> >>>>>>>>>>
> >> >>>>>>>>>> This will create the following
> > JNDI location in
> >> >> JBossAS5:
> >> >>>>>>>>>> java:/myDS
> >> >>>>>>>>>>
> >> >>>>>>>>>> NO comp, NO lang, NO other
> > qualifier.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Configuring the same in Geronimo
> > gives you
> >> >> java:/comp/env/myDS
> >> >>>>>>>>>> and it's again COMPLETEY
> > different in
> >> >> JBossAS6, AS7, Glassfish,
> >> >>> TomEE, etc
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>> Thus: which JNDI location would
> > you configure
> >> >> in your
> >> >>> persistence.xml?
> >> >>>>>>>>>>
> >> >>>>>>>>>> That's the reason why we came
> > up with the
> >> >> ConfigurableDataSource.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Of course, we need to extend this
> > concept and
> >> >> create a
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>> public interface
> > ConfigurableXaDataSource
> >> >> extends
> >> >>> ConfigurableDataSource, XaDataSource {}
> >> >>>>>>>>>>
> >> >>>>>>>>>> See what I mean?
> >> >>>>>>>>>>
> >> >>>>>>>>>> LieGrue,
> >> >>>>>>>>>> strub
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>> ----- Original Message -----
> >> >>>>>>>>>>> From: David Blevins
> >> >> <da...@gmail.com>
> >> >>>>>>>>>>> To:
> > deltaspike-dev@incubator.apache.org;
> >> >> Mark Struberg <
> >> >>> struberg@yahoo.de>
> >> >>>>>>>>>>> Cc:
> >> >>>>>>>>>>> Sent: Sunday, May 6, 2012 1:25
> > PM
> >> >>>>>>>>>>> Subject: Re: [DISCUSS]
> > deltaspike-jpa
> >> >> module features
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> On May 6, 2012, at 2:37 AM,
> > Mark Struberg
> >> >> wrote:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>> In plain Tomcat or
> >> >>>>>>>>>>>>> Jetty servers this
> > needs to be
> >> >> configured in a
> >> >>> container-specific way.
> >> >>>>>>>>>>>> The problem with the
> > container
> >> >> specific stuff is that every
> >> >>> container
> >> >>>>>>>>>>> serves the xml configured
> > datasource on a
> >> >> different location
> >> >>>>>>>>>>> in
> >> >>> JNDI! So you
> >> >>>>>>>>>>> cannot provide a container
> > independent
> >> >> implementation that
> >> >>>>>>>>>>> way :/
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> The portable way would be to
> > declare your
> >> >> datasource properly
> >> >>>>>>>>>>> via
> >> >> @Resource(name="java:app/Foo", type=DataSource.class) or
> >> >>>>>>>>>>> via <resource-ref> xml.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Most servers can map those
> > references with
> >> >> little to no config.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> -David
> >> >>>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> >>
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
DeltaSpike aims to be a solution for NOW. We cannot wait for a future spec change (which might or might NOT happen).
Of course we can give them feedback and adopt our features accordingly (after the spec got implemented).
But our main focus is certainly on EE6 containers and creating components which are useful for productive systems now and yet.
LieGrue,
strub
----- Original Message -----
> From: Romain Manni-Bucau <rm...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Monday, May 7, 2012 12:10 AM
> Subject: Re: [DISCUSS] deltaspike-jpa module features
>
>t he issue is at spec level, IMO DS shouldnt be a container too much
> otherwise it will replace the specs so if you have such an issue update the
> spec to make it easier if today it is not.
>
> - Romain
>
>
> 2012/5/7 David Blevins <da...@gmail.com>
>
>>
>> On May 6, 2012, at 2:58 PM, Mark Struberg wrote:
>>
>> > Well, I certainly agree that EE containers are actually much less
>> compatible as lots of users think.
>> >
>> > But still there are use cases where you like to use different JNDI
>> locations.
>> >
>> >
>> > I e.g. know of a scenario in a big swiss bank which has tight security
>> roles. And they have _explicitely_ configured their WebLogic to use
>> different JNDI locations for DataSources (and they are also only available
>> via doPrivileged() wrappers)
>>
>> I'm not sure I would know what to fix about Java EE based on the above
>> description. The application choses 100% of their own JNDI names and those
>> can be made portable. It's possible to use indirection and effectively
>> "symlink". All of this can be done external to the application.
>>
>> How does that not cover the described scenario?
>>
>>
>> -David
>>
>> > ----- Original Message -----
>> >> From: Arne Limburg <ar...@openknowledge.de>
>> >> To: "deltaspike-dev@incubator.apache.org" <
>> deltaspike-dev@incubator.apache.org>; Mark Struberg
> <st...@yahoo.de>
>> >> Cc:
>> >> Sent: Sunday, May 6, 2012 3:07 PM
>> >> Subject: AW: [DISCUSS] deltaspike-jpa module features
>> >>
>> >> OK,
>> >> but do we really need a container-independent way for
> JNDI-DataSources?
>> >> What's the use case for it?
>> >> The user always knows his container and thus his specific
> JNDI-name.
>> >>
>> >> I think we need an easy way for users to configure different
>> JNDI-DataSources
>> >> for different deployment scenarios, like
>> >> - a JTA-datasource for my JBoss AS 7 in production
>> >> - a Non-JTA-datasource from another JNDI-location for the Tomcat
> for
>> testing
>> >> - a RESOURCE_LOCAL EntityManager for local testing...
>> >>
>> >> We need to find an easy way for the users to configure the
>> JNDI-location, but
>> >> imho we don't need to handle different JNDI-locations in our
> code?
>> >>
>> >> WDYT? Am I missing a use case?
>> >>
>> >> Cheers,
>> >> Arne
>> >>
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> >> Gesendet: Sonntag, 6. Mai 2012 14:49
>> >> An: Mark Struberg; deltaspike-dev@incubator.apache.org
>> >> Betreff: Re: [DISCUSS] deltaspike-jpa module features
>> >>
>> >> ConfigurableDataSource doesnt solve it. If you build the emf from
>> persistence
>> >> info you manage it yourself. It should be IMO a compatibility mode
> and
>> spec you
>> >> be fixed.
>> >>
>> >> But well, the most important subjects are not here, pagination,
> dynamic
>> dao etc
>> >> are really more valuable.
>> >>
>> >> - Romain
>> >> Le 6 mai 2012 14:44, "Mark Struberg"
> <st...@yahoo.de> a écrit
>> >> :
>> >>
>> >>>
>> >>>
>> >>> The problem here is that this is NOT under our control - this
> is not
>> >>> even CDI related!
>> >>>
>> >>> You need to _exactly_ specify the JNDI location in your
>> persistence.xml.
>> >>> And this info get's parsed by JPA or the EE container at
> deploy time.
>> >>>
>> >>>
>> >>> Maybe there's a trick with a PersistenceUnitInfo. But
> since those are
>> >>> also managed by the server (and thus show the same unspecified
>> >>> behaviour) we imo cannot leverage those.
>> >>>
>> >>> LieGrue,
>> >>> strub
>> >>>
>> >>>
>> >>>> ________________________________
>> >>>> From: Romain Manni-Bucau <rm...@gmail.com>
>> >>>> To: Mark Struberg <st...@yahoo.de>;
>> >>> deltaspike-dev@incubator.apache.org
>> >>>> Sent: Sunday, May 6, 2012 2:37 PM
>> >>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
>> >>>>
>> >>>>
>> >>>> I understand. On another side how many differeny locations
> are there?
>> >>> Isnt it manageable?
>> >>>> - Romain
>> >>>> Le 6 mai 2012 14:29, "Mark Struberg"
>> >> <st...@yahoo.de> a écrit :
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> PS: I _fully_ agree that this mess should best get
> fixed in EE7.
>> >> But
>> >>> sadly we also need to support older containers!
>> >>>>>
>> >>>>> I know about folks who have OWB and CODI running on
> old WebSphere 6
>> >>
>> >>>>> and
>> >>> 7 servers. And others who use OWB on WebLogic 10.3. And those
>> >>> companies are big banks, stock exchanges and insurrance
> companies -
>> >>> they cannot easily upgrade to a new server...
>> >>>>>
>> >>>>> LieGrue,
>> >>>>> strub
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>> ________________________________
>> >>>>>> From: Mark Struberg <st...@yahoo.de>
>> >>>>>> To: Romain Manni-Bucau
> <rm...@gmail.com>;
>> >> deltaspike <
>> >>> deltaspike-dev@incubator.apache.org>
>> >>>>>> Sent: Sunday, May 6, 2012 2:14 PM
>> >>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> features
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> No, the container is NOT buggy, because it's
> simply NOT
>> >> defined!
>> >>>>>> That's the whole mess about JNDI...
>> >>>>>>
>> >>>>>> LieGrue,
>> >>>>>> strub
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> ________________________________
>> >>>>>>> From: Romain Manni-Bucau
> <rm...@gmail.com>
>> >>>>>>> To: Mark Struberg <st...@yahoo.de>
>> >>>>>>> Sent: Sunday, May 6, 2012 2:01 PM
>> >>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> features
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> So this container is buggy, report an issue ;)
> Thinking of
>> >> it this
>> >>>>>>> jndi path issue couldnt be resolved by
>> >>> configresolvers in ds?
>> >>>>>>> - Romain
>> >>>>>>> Le 6 mai 2012 13:58, "Mark Struberg"
>> >> <st...@yahoo.de> a écrit :
>> >>>>>>>
>> >>>>>>> yes, that crashes the container...
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>> ________________________________
>> >>>>>>>>> From: Romain Manni-Bucau
>> >> <rm...@gmail.com>
>> >>>>>>>>> To: Mark Struberg
> <st...@yahoo.de>;
>> >>> deltaspike-dev@incubator.apache.org
>> >>>>>>>>> Sent: Sunday, May 6, 2012 1:52 PM
>> >>>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa
> module
>> >> features
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Mark, did you try providing a name
> starting with
>> >> java:?
>> >>>>>>>>> - Romain
>> >>>>>>>>> Le 6 mai 2012 13:49, "Mark
> Struberg"
>> >> <st...@yahoo.de> a écrit :
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> David, exactly this doesn't
> work out in
>> >> practice!
>> >>>>>>>>>>
>> >>>>>>>>>> look at jboss5 datasource xml as
> an example:
>> >>>>>>>>>>
>> >>>>>>>>>> <?xml version="1.0"
>> >> encoding="UTF-8"?> <datasources>
>> >>>>>>>>>>
> <local-tx-datasource>
>> >>>>>>>>>>
>> >> <jndi-name>myDS</jndi-name>
>> >>>>>>>>>>
>> >>>
>> >>
> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-u
>> >>> rl>
>> >>>>>>>>>>
>> >> <user-name>user</user-name>
>> >>>>>>>>>>
>> >> <password>pwd</password>
>> >>>>>>>>>>
>> >>> <driver-class>org.postgresql.Driver</driver-class>
>> >>>>>>>>>>
> </local-tx-datasource>
>> >>>>>>>>>> </datasources>
>> >>>>>>>>>>
>> >>>>>>>>>> This will create the following
> JNDI location in
>> >> JBossAS5:
>> >>>>>>>>>> java:/myDS
>> >>>>>>>>>>
>> >>>>>>>>>> NO comp, NO lang, NO other
> qualifier.
>> >>>>>>>>>>
>> >>>>>>>>>> Configuring the same in Geronimo
> gives you
>> >> java:/comp/env/myDS
>> >>>>>>>>>> and it's again COMPLETEY
> different in
>> >> JBossAS6, AS7, Glassfish,
>> >>> TomEE, etc
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> Thus: which JNDI location would
> you configure
>> >> in your
>> >>> persistence.xml?
>> >>>>>>>>>>
>> >>>>>>>>>> That's the reason why we came
> up with the
>> >> ConfigurableDataSource.
>> >>>>>>>>>>
>> >>>>>>>>>> Of course, we need to extend this
> concept and
>> >> create a
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> public interface
> ConfigurableXaDataSource
>> >> extends
>> >>> ConfigurableDataSource, XaDataSource {}
>> >>>>>>>>>>
>> >>>>>>>>>> See what I mean?
>> >>>>>>>>>>
>> >>>>>>>>>> LieGrue,
>> >>>>>>>>>> strub
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> ----- Original Message -----
>> >>>>>>>>>>> From: David Blevins
>> >> <da...@gmail.com>
>> >>>>>>>>>>> To:
> deltaspike-dev@incubator.apache.org;
>> >> Mark Struberg <
>> >>> struberg@yahoo.de>
>> >>>>>>>>>>> Cc:
>> >>>>>>>>>>> Sent: Sunday, May 6, 2012 1:25
> PM
>> >>>>>>>>>>> Subject: Re: [DISCUSS]
> deltaspike-jpa
>> >> module features
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> On May 6, 2012, at 2:37 AM,
> Mark Struberg
>> >> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>>> In plain Tomcat or
>> >>>>>>>>>>>>> Jetty servers this
> needs to be
>> >> configured in a
>> >>> container-specific way.
>> >>>>>>>>>>>> The problem with the
> container
>> >> specific stuff is that every
>> >>> container
>> >>>>>>>>>>> serves the xml configured
> datasource on a
>> >> different location
>> >>>>>>>>>>> in
>> >>> JNDI! So you
>> >>>>>>>>>>> cannot provide a container
> independent
>> >> implementation that
>> >>>>>>>>>>> way :/
>> >>>>>>>>>>>
>> >>>>>>>>>>> The portable way would be to
> declare your
>> >> datasource properly
>> >>>>>>>>>>> via
>> >> @Resource(name="java:app/Foo", type=DataSource.class) or
>> >>>>>>>>>>> via <resource-ref> xml.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Most servers can map those
> references with
>> >> little to no config.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> -David
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>>
>>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
the issue is at spec level, IMO DS shouldnt be a container too much
otherwise it will replace the specs so if you have such an issue update the
spec to make it easier if today it is not.
- Romain
2012/5/7 David Blevins <da...@gmail.com>
>
> On May 6, 2012, at 2:58 PM, Mark Struberg wrote:
>
> > Well, I certainly agree that EE containers are actually much less
> compatible as lots of users think.
> >
> > But still there are use cases where you like to use different JNDI
> locations.
> >
> >
> > I e.g. know of a scenario in a big swiss bank which has tight security
> roles. And they have _explicitely_ configured their WebLogic to use
> different JNDI locations for DataSources (and they are also only available
> via doPrivileged() wrappers)
>
> I'm not sure I would know what to fix about Java EE based on the above
> description. The application choses 100% of their own JNDI names and those
> can be made portable. It's possible to use indirection and effectively
> "symlink". All of this can be done external to the application.
>
> How does that not cover the described scenario?
>
>
> -David
>
> > ----- Original Message -----
> >> From: Arne Limburg <ar...@openknowledge.de>
> >> To: "deltaspike-dev@incubator.apache.org" <
> deltaspike-dev@incubator.apache.org>; Mark Struberg <st...@yahoo.de>
> >> Cc:
> >> Sent: Sunday, May 6, 2012 3:07 PM
> >> Subject: AW: [DISCUSS] deltaspike-jpa module features
> >>
> >> OK,
> >> but do we really need a container-independent way for JNDI-DataSources?
> >> What's the use case for it?
> >> The user always knows his container and thus his specific JNDI-name.
> >>
> >> I think we need an easy way for users to configure different
> JNDI-DataSources
> >> for different deployment scenarios, like
> >> - a JTA-datasource for my JBoss AS 7 in production
> >> - a Non-JTA-datasource from another JNDI-location for the Tomcat for
> testing
> >> - a RESOURCE_LOCAL EntityManager for local testing...
> >>
> >> We need to find an easy way for the users to configure the
> JNDI-location, but
> >> imho we don't need to handle different JNDI-locations in our code?
> >>
> >> WDYT? Am I missing a use case?
> >>
> >> Cheers,
> >> Arne
> >>
> >> -----Ursprüngliche Nachricht-----
> >> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> >> Gesendet: Sonntag, 6. Mai 2012 14:49
> >> An: Mark Struberg; deltaspike-dev@incubator.apache.org
> >> Betreff: Re: [DISCUSS] deltaspike-jpa module features
> >>
> >> ConfigurableDataSource doesnt solve it. If you build the emf from
> persistence
> >> info you manage it yourself. It should be IMO a compatibility mode and
> spec you
> >> be fixed.
> >>
> >> But well, the most important subjects are not here, pagination, dynamic
> dao etc
> >> are really more valuable.
> >>
> >> - Romain
> >> Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit
> >> :
> >>
> >>>
> >>>
> >>> The problem here is that this is NOT under our control - this is not
> >>> even CDI related!
> >>>
> >>> You need to _exactly_ specify the JNDI location in your
> persistence.xml.
> >>> And this info get's parsed by JPA or the EE container at deploy time.
> >>>
> >>>
> >>> Maybe there's a trick with a PersistenceUnitInfo. But since those are
> >>> also managed by the server (and thus show the same unspecified
> >>> behaviour) we imo cannot leverage those.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>> ________________________________
> >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> >>>> To: Mark Struberg <st...@yahoo.de>;
> >>> deltaspike-dev@incubator.apache.org
> >>>> Sent: Sunday, May 6, 2012 2:37 PM
> >>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>
> >>>>
> >>>> I understand. On another side how many differeny locations are there?
> >>> Isnt it manageable?
> >>>> - Romain
> >>>> Le 6 mai 2012 14:29, "Mark Struberg"
> >> <st...@yahoo.de> a écrit :
> >>>>
> >>>>
> >>>>>
> >>>>> PS: I _fully_ agree that this mess should best get fixed in EE7.
> >> But
> >>> sadly we also need to support older containers!
> >>>>>
> >>>>> I know about folks who have OWB and CODI running on old WebSphere 6
> >>
> >>>>> and
> >>> 7 servers. And others who use OWB on WebLogic 10.3. And those
> >>> companies are big banks, stock exchanges and insurrance companies -
> >>> they cannot easily upgrade to a new server...
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> ________________________________
> >>>>>> From: Mark Struberg <st...@yahoo.de>
> >>>>>> To: Romain Manni-Bucau <rm...@gmail.com>;
> >> deltaspike <
> >>> deltaspike-dev@incubator.apache.org>
> >>>>>> Sent: Sunday, May 6, 2012 2:14 PM
> >>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> No, the container is NOT buggy, because it's simply NOT
> >> defined!
> >>>>>> That's the whole mess about JNDI...
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> ________________________________
> >>>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> >>>>>>> To: Mark Struberg <st...@yahoo.de>
> >>>>>>> Sent: Sunday, May 6, 2012 2:01 PM
> >>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>>>>
> >>>>>>>
> >>>>>>> So this container is buggy, report an issue ;) Thinking of
> >> it this
> >>>>>>> jndi path issue couldnt be resolved by
> >>> configresolvers in ds?
> >>>>>>> - Romain
> >>>>>>> Le 6 mai 2012 13:58, "Mark Struberg"
> >> <st...@yahoo.de> a écrit :
> >>>>>>>
> >>>>>>> yes, that crashes the container...
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> ________________________________
> >>>>>>>>> From: Romain Manni-Bucau
> >> <rm...@gmail.com>
> >>>>>>>>> To: Mark Struberg <st...@yahoo.de>;
> >>> deltaspike-dev@incubator.apache.org
> >>>>>>>>> Sent: Sunday, May 6, 2012 1:52 PM
> >>>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
> >> features
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Mark, did you try providing a name starting with
> >> java:?
> >>>>>>>>> - Romain
> >>>>>>>>> Le 6 mai 2012 13:49, "Mark Struberg"
> >> <st...@yahoo.de> a écrit :
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> David, exactly this doesn't work out in
> >> practice!
> >>>>>>>>>>
> >>>>>>>>>> look at jboss5 datasource xml as an example:
> >>>>>>>>>>
> >>>>>>>>>> <?xml version="1.0"
> >> encoding="UTF-8"?> <datasources>
> >>>>>>>>>> <local-tx-datasource>
> >>>>>>>>>>
> >> <jndi-name>myDS</jndi-name>
> >>>>>>>>>>
> >>>
> >> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-u
> >>> rl>
> >>>>>>>>>>
> >> <user-name>user</user-name>
> >>>>>>>>>>
> >> <password>pwd</password>
> >>>>>>>>>>
> >>> <driver-class>org.postgresql.Driver</driver-class>
> >>>>>>>>>> </local-tx-datasource>
> >>>>>>>>>> </datasources>
> >>>>>>>>>>
> >>>>>>>>>> This will create the following JNDI location in
> >> JBossAS5:
> >>>>>>>>>> java:/myDS
> >>>>>>>>>>
> >>>>>>>>>> NO comp, NO lang, NO other qualifier.
> >>>>>>>>>>
> >>>>>>>>>> Configuring the same in Geronimo gives you
> >> java:/comp/env/myDS
> >>>>>>>>>> and it's again COMPLETEY different in
> >> JBossAS6, AS7, Glassfish,
> >>> TomEE, etc
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thus: which JNDI location would you configure
> >> in your
> >>> persistence.xml?
> >>>>>>>>>>
> >>>>>>>>>> That's the reason why we came up with the
> >> ConfigurableDataSource.
> >>>>>>>>>>
> >>>>>>>>>> Of course, we need to extend this concept and
> >> create a
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> public interface ConfigurableXaDataSource
> >> extends
> >>> ConfigurableDataSource, XaDataSource {}
> >>>>>>>>>>
> >>>>>>>>>> See what I mean?
> >>>>>>>>>>
> >>>>>>>>>> LieGrue,
> >>>>>>>>>> strub
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>> From: David Blevins
> >> <da...@gmail.com>
> >>>>>>>>>>> To: deltaspike-dev@incubator.apache.org;
> >> Mark Struberg <
> >>> struberg@yahoo.de>
> >>>>>>>>>>> Cc:
> >>>>>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> >>>>>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa
> >> module features
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg
> >> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>> In plain Tomcat or
> >>>>>>>>>>>>> Jetty servers this needs to be
> >> configured in a
> >>> container-specific way.
> >>>>>>>>>>>> The problem with the container
> >> specific stuff is that every
> >>> container
> >>>>>>>>>>> serves the xml configured datasource on a
> >> different location
> >>>>>>>>>>> in
> >>> JNDI! So you
> >>>>>>>>>>> cannot provide a container independent
> >> implementation that
> >>>>>>>>>>> way :/
> >>>>>>>>>>>
> >>>>>>>>>>> The portable way would be to declare your
> >> datasource properly
> >>>>>>>>>>> via
> >> @Resource(name="java:app/Foo", type=DataSource.class) or
> >>>>>>>>>>> via <resource-ref> xml.
> >>>>>>>>>>>
> >>>>>>>>>>> Most servers can map those references with
> >> little to no config.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> -David
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by David Blevins <da...@gmail.com>.
On May 6, 2012, at 2:58 PM, Mark Struberg wrote:
> Well, I certainly agree that EE containers are actually much less compatible as lots of users think.
>
> But still there are use cases where you like to use different JNDI locations.
>
>
> I e.g. know of a scenario in a big swiss bank which has tight security roles. And they have _explicitely_ configured their WebLogic to use different JNDI locations for DataSources (and they are also only available via doPrivileged() wrappers)
I'm not sure I would know what to fix about Java EE based on the above description. The application choses 100% of their own JNDI names and those can be made portable. It's possible to use indirection and effectively "symlink". All of this can be done external to the application.
How does that not cover the described scenario?
-David
> ----- Original Message -----
>> From: Arne Limburg <ar...@openknowledge.de>
>> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>; Mark Struberg <st...@yahoo.de>
>> Cc:
>> Sent: Sunday, May 6, 2012 3:07 PM
>> Subject: AW: [DISCUSS] deltaspike-jpa module features
>>
>> OK,
>> but do we really need a container-independent way for JNDI-DataSources?
>> What's the use case for it?
>> The user always knows his container and thus his specific JNDI-name.
>>
>> I think we need an easy way for users to configure different JNDI-DataSources
>> for different deployment scenarios, like
>> - a JTA-datasource for my JBoss AS 7 in production
>> - a Non-JTA-datasource from another JNDI-location for the Tomcat for testing
>> - a RESOURCE_LOCAL EntityManager for local testing...
>>
>> We need to find an easy way for the users to configure the JNDI-location, but
>> imho we don't need to handle different JNDI-locations in our code?
>>
>> WDYT? Am I missing a use case?
>>
>> Cheers,
>> Arne
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> Gesendet: Sonntag, 6. Mai 2012 14:49
>> An: Mark Struberg; deltaspike-dev@incubator.apache.org
>> Betreff: Re: [DISCUSS] deltaspike-jpa module features
>>
>> ConfigurableDataSource doesnt solve it. If you build the emf from persistence
>> info you manage it yourself. It should be IMO a compatibility mode and spec you
>> be fixed.
>>
>> But well, the most important subjects are not here, pagination, dynamic dao etc
>> are really more valuable.
>>
>> - Romain
>> Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit
>> :
>>
>>>
>>>
>>> The problem here is that this is NOT under our control - this is not
>>> even CDI related!
>>>
>>> You need to _exactly_ specify the JNDI location in your persistence.xml.
>>> And this info get's parsed by JPA or the EE container at deploy time.
>>>
>>>
>>> Maybe there's a trick with a PersistenceUnitInfo. But since those are
>>> also managed by the server (and thus show the same unspecified
>>> behaviour) we imo cannot leverage those.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>> ________________________________
>>>> From: Romain Manni-Bucau <rm...@gmail.com>
>>>> To: Mark Struberg <st...@yahoo.de>;
>>> deltaspike-dev@incubator.apache.org
>>>> Sent: Sunday, May 6, 2012 2:37 PM
>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>>
>>>>
>>>> I understand. On another side how many differeny locations are there?
>>> Isnt it manageable?
>>>> - Romain
>>>> Le 6 mai 2012 14:29, "Mark Struberg"
>> <st...@yahoo.de> a écrit :
>>>>
>>>>
>>>>>
>>>>> PS: I _fully_ agree that this mess should best get fixed in EE7.
>> But
>>> sadly we also need to support older containers!
>>>>>
>>>>> I know about folks who have OWB and CODI running on old WebSphere 6
>>
>>>>> and
>>> 7 servers. And others who use OWB on WebLogic 10.3. And those
>>> companies are big banks, stock exchanges and insurrance companies -
>>> they cannot easily upgrade to a new server...
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> ________________________________
>>>>>> From: Mark Struberg <st...@yahoo.de>
>>>>>> To: Romain Manni-Bucau <rm...@gmail.com>;
>> deltaspike <
>>> deltaspike-dev@incubator.apache.org>
>>>>>> Sent: Sunday, May 6, 2012 2:14 PM
>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>>>>
>>>>>>
>>>>>>
>>>>>> No, the container is NOT buggy, because it's simply NOT
>> defined!
>>>>>> That's the whole mess about JNDI...
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> ________________________________
>>>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
>>>>>>> To: Mark Struberg <st...@yahoo.de>
>>>>>>> Sent: Sunday, May 6, 2012 2:01 PM
>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>>>>>
>>>>>>>
>>>>>>> So this container is buggy, report an issue ;) Thinking of
>> it this
>>>>>>> jndi path issue couldnt be resolved by
>>> configresolvers in ds?
>>>>>>> - Romain
>>>>>>> Le 6 mai 2012 13:58, "Mark Struberg"
>> <st...@yahoo.de> a écrit :
>>>>>>>
>>>>>>> yes, that crashes the container...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> ________________________________
>>>>>>>>> From: Romain Manni-Bucau
>> <rm...@gmail.com>
>>>>>>>>> To: Mark Struberg <st...@yahoo.de>;
>>> deltaspike-dev@incubator.apache.org
>>>>>>>>> Sent: Sunday, May 6, 2012 1:52 PM
>>>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module
>> features
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mark, did you try providing a name starting with
>> java:?
>>>>>>>>> - Romain
>>>>>>>>> Le 6 mai 2012 13:49, "Mark Struberg"
>> <st...@yahoo.de> a écrit :
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> David, exactly this doesn't work out in
>> practice!
>>>>>>>>>>
>>>>>>>>>> look at jboss5 datasource xml as an example:
>>>>>>>>>>
>>>>>>>>>> <?xml version="1.0"
>> encoding="UTF-8"?> <datasources>
>>>>>>>>>> <local-tx-datasource>
>>>>>>>>>>
>> <jndi-name>myDS</jndi-name>
>>>>>>>>>>
>>>
>> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-u
>>> rl>
>>>>>>>>>>
>> <user-name>user</user-name>
>>>>>>>>>>
>> <password>pwd</password>
>>>>>>>>>>
>>> <driver-class>org.postgresql.Driver</driver-class>
>>>>>>>>>> </local-tx-datasource>
>>>>>>>>>> </datasources>
>>>>>>>>>>
>>>>>>>>>> This will create the following JNDI location in
>> JBossAS5:
>>>>>>>>>> java:/myDS
>>>>>>>>>>
>>>>>>>>>> NO comp, NO lang, NO other qualifier.
>>>>>>>>>>
>>>>>>>>>> Configuring the same in Geronimo gives you
>> java:/comp/env/myDS
>>>>>>>>>> and it's again COMPLETEY different in
>> JBossAS6, AS7, Glassfish,
>>> TomEE, etc
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thus: which JNDI location would you configure
>> in your
>>> persistence.xml?
>>>>>>>>>>
>>>>>>>>>> That's the reason why we came up with the
>> ConfigurableDataSource.
>>>>>>>>>>
>>>>>>>>>> Of course, we need to extend this concept and
>> create a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> public interface ConfigurableXaDataSource
>> extends
>>> ConfigurableDataSource, XaDataSource {}
>>>>>>>>>>
>>>>>>>>>> See what I mean?
>>>>>>>>>>
>>>>>>>>>> LieGrue,
>>>>>>>>>> strub
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: David Blevins
>> <da...@gmail.com>
>>>>>>>>>>> To: deltaspike-dev@incubator.apache.org;
>> Mark Struberg <
>>> struberg@yahoo.de>
>>>>>>>>>>> Cc:
>>>>>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
>>>>>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa
>> module features
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg
>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> In plain Tomcat or
>>>>>>>>>>>>> Jetty servers this needs to be
>> configured in a
>>> container-specific way.
>>>>>>>>>>>> The problem with the container
>> specific stuff is that every
>>> container
>>>>>>>>>>> serves the xml configured datasource on a
>> different location
>>>>>>>>>>> in
>>> JNDI! So you
>>>>>>>>>>> cannot provide a container independent
>> implementation that
>>>>>>>>>>> way :/
>>>>>>>>>>>
>>>>>>>>>>> The portable way would be to declare your
>> datasource properly
>>>>>>>>>>> via
>> @Resource(name="java:app/Foo", type=DataSource.class) or
>>>>>>>>>>> via <resource-ref> xml.
>>>>>>>>>>>
>>>>>>>>>>> Most servers can map those references with
>> little to no config.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -David
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
Re: AW: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
Well, I certainly agree that EE containers are actually much less compatible as lots of users think.
But still there are use cases where you like to use different JNDI locations.
I e.g. know of a scenario in a big swiss bank which has tight security roles. And they have _explicitely_ configured their WebLogic to use different JNDI locations for DataSources (and they are also only available via doPrivileged() wrappers)
LieGrue,
strub
----- Original Message -----
> From: Arne Limburg <ar...@openknowledge.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Sunday, May 6, 2012 3:07 PM
> Subject: AW: [DISCUSS] deltaspike-jpa module features
>
> OK,
> but do we really need a container-independent way for JNDI-DataSources?
> What's the use case for it?
> The user always knows his container and thus his specific JNDI-name.
>
> I think we need an easy way for users to configure different JNDI-DataSources
> for different deployment scenarios, like
> - a JTA-datasource for my JBoss AS 7 in production
> - a Non-JTA-datasource from another JNDI-location for the Tomcat for testing
> - a RESOURCE_LOCAL EntityManager for local testing...
>
> We need to find an easy way for the users to configure the JNDI-location, but
> imho we don't need to handle different JNDI-locations in our code?
>
> WDYT? Am I missing a use case?
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 14:49
> An: Mark Struberg; deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS] deltaspike-jpa module features
>
> ConfigurableDataSource doesnt solve it. If you build the emf from persistence
> info you manage it yourself. It should be IMO a compatibility mode and spec you
> be fixed.
>
> But well, the most important subjects are not here, pagination, dynamic dao etc
> are really more valuable.
>
> - Romain
> Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit
> :
>
>>
>>
>> The problem here is that this is NOT under our control - this is not
>> even CDI related!
>>
>> You need to _exactly_ specify the JNDI location in your persistence.xml.
>> And this info get's parsed by JPA or the EE container at deploy time.
>>
>>
>> Maybe there's a trick with a PersistenceUnitInfo. But since those are
>> also managed by the server (and thus show the same unspecified
>> behaviour) we imo cannot leverage those.
>>
>> LieGrue,
>> strub
>>
>>
>> >________________________________
>> > From: Romain Manni-Bucau <rm...@gmail.com>
>> >To: Mark Struberg <st...@yahoo.de>;
>> deltaspike-dev@incubator.apache.org
>> >Sent: Sunday, May 6, 2012 2:37 PM
>> >Subject: Re: [DISCUSS] deltaspike-jpa module features
>> >
>> >
>> >I understand. On another side how many differeny locations are there?
>> Isnt it manageable?
>> >- Romain
>> >Le 6 mai 2012 14:29, "Mark Struberg"
> <st...@yahoo.de> a écrit :
>> >
>> >
>> >>
>> >>PS: I _fully_ agree that this mess should best get fixed in EE7.
> But
>> sadly we also need to support older containers!
>> >>
>> >>I know about folks who have OWB and CODI running on old WebSphere 6
>
>> >>and
>> 7 servers. And others who use OWB on WebLogic 10.3. And those
>> companies are big banks, stock exchanges and insurrance companies -
>> they cannot easily upgrade to a new server...
>> >>
>> >>LieGrue,
>> >>strub
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>________________________________
>> >>> From: Mark Struberg <st...@yahoo.de>
>> >>>To: Romain Manni-Bucau <rm...@gmail.com>;
> deltaspike <
>> deltaspike-dev@incubator.apache.org>
>> >>>Sent: Sunday, May 6, 2012 2:14 PM
>> >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>> >>>
>> >>>
>> >>>
>> >>>No, the container is NOT buggy, because it's simply NOT
> defined!
>> >>>That's the whole mess about JNDI...
>> >>>
>> >>>LieGrue,
>> >>>strub
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>________________________________
>> >>>> From: Romain Manni-Bucau <rm...@gmail.com>
>> >>>>To: Mark Struberg <st...@yahoo.de>
>> >>>>Sent: Sunday, May 6, 2012 2:01 PM
>> >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>> >>>>
>> >>>>
>> >>>>So this container is buggy, report an issue ;) Thinking of
> it this
>> >>>>jndi path issue couldnt be resolved by
>> configresolvers in ds?
>> >>>>- Romain
>> >>>>Le 6 mai 2012 13:58, "Mark Struberg"
> <st...@yahoo.de> a écrit :
>> >>>>
>> >>>>yes, that crashes the container...
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>>________________________________
>> >>>>>> From: Romain Manni-Bucau
> <rm...@gmail.com>
>> >>>>>>To: Mark Struberg <st...@yahoo.de>;
>> deltaspike-dev@incubator.apache.org
>> >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
>> >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module
> features
>> >>>>>>
>> >>>>>>
>> >>>>>>Mark, did you try providing a name starting with
> java:?
>> >>>>>>- Romain
>> >>>>>>Le 6 mai 2012 13:49, "Mark Struberg"
> <st...@yahoo.de> a écrit :
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>>David, exactly this doesn't work out in
> practice!
>> >>>>>>>
>> >>>>>>>look at jboss5 datasource xml as an example:
>> >>>>>>>
>> >>>>>>><?xml version="1.0"
> encoding="UTF-8"?> <datasources>
>> >>>>>>> <local-tx-datasource>
>> >>>>>>>
> <jndi-name>myDS</jndi-name>
>> >>>>>>>
>>
> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-u
>> rl>
>> >>>>>>>
> <user-name>user</user-name>
>> >>>>>>>
> <password>pwd</password>
>> >>>>>>>
>> <driver-class>org.postgresql.Driver</driver-class>
>> >>>>>>> </local-tx-datasource>
>> >>>>>>></datasources>
>> >>>>>>>
>> >>>>>>>This will create the following JNDI location in
> JBossAS5:
>> >>>>>>>java:/myDS
>> >>>>>>>
>> >>>>>>>NO comp, NO lang, NO other qualifier.
>> >>>>>>>
>> >>>>>>>Configuring the same in Geronimo gives you
> java:/comp/env/myDS
>> >>>>>>>and it's again COMPLETEY different in
> JBossAS6, AS7, Glassfish,
>> TomEE, etc
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>Thus: which JNDI location would you configure
> in your
>> persistence.xml?
>> >>>>>>>
>> >>>>>>>That's the reason why we came up with the
> ConfigurableDataSource.
>> >>>>>>>
>> >>>>>>>Of course, we need to extend this concept and
> create a
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>public interface ConfigurableXaDataSource
> extends
>> ConfigurableDataSource, XaDataSource {}
>> >>>>>>>
>> >>>>>>>See what I mean?
>> >>>>>>>
>> >>>>>>>LieGrue,
>> >>>>>>>strub
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>----- Original Message -----
>> >>>>>>>> From: David Blevins
> <da...@gmail.com>
>> >>>>>>>> To: deltaspike-dev@incubator.apache.org;
> Mark Struberg <
>> struberg@yahoo.de>
>> >>>>>>>> Cc:
>> >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
>> >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa
> module features
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg
> wrote:
>> >>>>>>>>
>> >>>>>>>>>> In plain Tomcat or
>> >>>>>>>>>> Jetty servers this needs to be
> configured in a
>> container-specific way.
>> >>>>>>>>> The problem with the container
> specific stuff is that every
>> container
>> >>>>>>>> serves the xml configured datasource on a
> different location
>> >>>>>>>> in
>> JNDI! So you
>> >>>>>>>> cannot provide a container independent
> implementation that
>> >>>>>>>> way :/
>> >>>>>>>>
>> >>>>>>>> The portable way would be to declare your
> datasource properly
>> >>>>>>>> via
> @Resource(name="java:app/Foo", type=DataSource.class) or
>> >>>>>>>> via <resource-ref> xml.
>> >>>>>>>>
>> >>>>>>>> Most servers can map those references with
> little to no config.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> -David
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>
AW: [DISCUSS] deltaspike-jpa module features
Posted by Arne Limburg <ar...@openknowledge.de>.
OK,
but do we really need a container-independent way for JNDI-DataSources? What's the use case for it?
The user always knows his container and thus his specific JNDI-name.
I think we need an easy way for users to configure different JNDI-DataSources for different deployment scenarios, like
- a JTA-datasource for my JBoss AS 7 in production
- a Non-JTA-datasource from another JNDI-location for the Tomcat for testing
- a RESOURCE_LOCAL EntityManager for local testing...
We need to find an easy way for the users to configure the JNDI-location, but imho we don't need to handle different JNDI-locations in our code?
WDYT? Am I missing a use case?
Cheers,
Arne
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Sonntag, 6. Mai 2012 14:49
An: Mark Struberg; deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS] deltaspike-jpa module features
ConfigurableDataSource doesnt solve it. If you build the emf from persistence info you manage it yourself. It should be IMO a compatibility mode and spec you be fixed.
But well, the most important subjects are not here, pagination, dynamic dao etc are really more valuable.
- Romain
Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
>
>
> The problem here is that this is NOT under our control - this is not
> even CDI related!
>
> You need to _exactly_ specify the JNDI location in your persistence.xml.
> And this info get's parsed by JPA or the EE container at deploy time.
>
>
> Maybe there's a trick with a PersistenceUnitInfo. But since those are
> also managed by the server (and thus show the same unspecified
> behaviour) we imo cannot leverage those.
>
> LieGrue,
> strub
>
>
> >________________________________
> > From: Romain Manni-Bucau <rm...@gmail.com>
> >To: Mark Struberg <st...@yahoo.de>;
> deltaspike-dev@incubator.apache.org
> >Sent: Sunday, May 6, 2012 2:37 PM
> >Subject: Re: [DISCUSS] deltaspike-jpa module features
> >
> >
> >I understand. On another side how many differeny locations are there?
> Isnt it manageable?
> >- Romain
> >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit :
> >
> >
> >>
> >>PS: I _fully_ agree that this mess should best get fixed in EE7. But
> sadly we also need to support older containers!
> >>
> >>I know about folks who have OWB and CODI running on old WebSphere 6
> >>and
> 7 servers. And others who use OWB on WebLogic 10.3. And those
> companies are big banks, stock exchanges and insurrance companies -
> they cannot easily upgrade to a new server...
> >>
> >>LieGrue,
> >>strub
> >>
> >>
> >>
> >>
> >>
> >>>________________________________
> >>> From: Mark Struberg <st...@yahoo.de>
> >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <
> deltaspike-dev@incubator.apache.org>
> >>>Sent: Sunday, May 6, 2012 2:14 PM
> >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>
> >>>
> >>>
> >>>No, the container is NOT buggy, because it's simply NOT defined!
> >>>That's the whole mess about JNDI...
> >>>
> >>>LieGrue,
> >>>strub
> >>>
> >>>
> >>>
> >>>
> >>>>________________________________
> >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> >>>>To: Mark Struberg <st...@yahoo.de>
> >>>>Sent: Sunday, May 6, 2012 2:01 PM
> >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>
> >>>>
> >>>>So this container is buggy, report an issue ;) Thinking of it this
> >>>>jndi path issue couldnt be resolved by
> configresolvers in ds?
> >>>>- Romain
> >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a écrit :
> >>>>
> >>>>yes, that crashes the container...
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>________________________________
> >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> >>>>>>To: Mark Struberg <st...@yahoo.de>;
> deltaspike-dev@incubator.apache.org
> >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>>>
> >>>>>>
> >>>>>>Mark, did you try providing a name starting with java:?
> >>>>>>- Romain
> >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a écrit :
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>David, exactly this doesn't work out in practice!
> >>>>>>>
> >>>>>>>look at jboss5 datasource xml as an example:
> >>>>>>>
> >>>>>>><?xml version="1.0" encoding="UTF-8"?> <datasources>
> >>>>>>> <local-tx-datasource>
> >>>>>>> <jndi-name>myDS</jndi-name>
> >>>>>>>
> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-u
> rl>
> >>>>>>> <user-name>user</user-name>
> >>>>>>> <password>pwd</password>
> >>>>>>>
> <driver-class>org.postgresql.Driver</driver-class>
> >>>>>>> </local-tx-datasource>
> >>>>>>></datasources>
> >>>>>>>
> >>>>>>>This will create the following JNDI location in JBossAS5:
> >>>>>>>java:/myDS
> >>>>>>>
> >>>>>>>NO comp, NO lang, NO other qualifier.
> >>>>>>>
> >>>>>>>Configuring the same in Geronimo gives you java:/comp/env/myDS
> >>>>>>>and it's again COMPLETEY different in JBossAS6, AS7, Glassfish,
> TomEE, etc
> >>>>>>>
> >>>>>>>
> >>>>>>>Thus: which JNDI location would you configure in your
> persistence.xml?
> >>>>>>>
> >>>>>>>That's the reason why we came up with the ConfigurableDataSource.
> >>>>>>>
> >>>>>>>Of course, we need to extend this concept and create a
> >>>>>>>
> >>>>>>>
> >>>>>>>public interface ConfigurableXaDataSource extends
> ConfigurableDataSource, XaDataSource {}
> >>>>>>>
> >>>>>>>See what I mean?
> >>>>>>>
> >>>>>>>LieGrue,
> >>>>>>>strub
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>----- Original Message -----
> >>>>>>>> From: David Blevins <da...@gmail.com>
> >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> struberg@yahoo.de>
> >>>>>>>> Cc:
> >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> >>>>>>>>
> >>>>>>>>>> In plain Tomcat or
> >>>>>>>>>> Jetty servers this needs to be configured in a
> container-specific way.
> >>>>>>>>> The problem with the container specific stuff is that every
> container
> >>>>>>>> serves the xml configured datasource on a different location
> >>>>>>>> in
> JNDI! So you
> >>>>>>>> cannot provide a container independent implementation that
> >>>>>>>> way :/
> >>>>>>>>
> >>>>>>>> The portable way would be to declare your datasource properly
> >>>>>>>> via @Resource(name="java:app/Foo", type=DataSource.class) or
> >>>>>>>> via <resource-ref> xml.
> >>>>>>>>
> >>>>>>>> Most servers can map those references with little to no config.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -David
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
ConfigurableDataSource doesnt solve it. If you build the emf from
persistence info you manage it yourself. It should be IMO a compatibility
mode and spec you be fixed.
But well, the most important subjects are not here, pagination, dynamic dao
etc are really more valuable.
- Romain
Le 6 mai 2012 14:44, "Mark Struberg" <st...@yahoo.de> a écrit :
>
>
> The problem here is that this is NOT under our control - this is not even
> CDI related!
>
> You need to _exactly_ specify the JNDI location in your persistence.xml.
> And this info get's parsed by JPA or the EE container at deploy time.
>
>
> Maybe there's a trick with a PersistenceUnitInfo. But since those are also
> managed by the server (and thus show the same unspecified behaviour) we imo
> cannot leverage those.
>
> LieGrue,
> strub
>
>
> >________________________________
> > From: Romain Manni-Bucau <rm...@gmail.com>
> >To: Mark Struberg <st...@yahoo.de>;
> deltaspike-dev@incubator.apache.org
> >Sent: Sunday, May 6, 2012 2:37 PM
> >Subject: Re: [DISCUSS] deltaspike-jpa module features
> >
> >
> >I understand. On another side how many differeny locations are there?
> Isnt it manageable?
> >- Romain
> >Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit :
> >
> >
> >>
> >>PS: I _fully_ agree that this mess should best get fixed in EE7. But
> sadly we also need to support older containers!
> >>
> >>I know about folks who have OWB and CODI running on old WebSphere 6 and
> 7 servers. And others who use OWB on WebLogic 10.3. And those companies are
> big banks, stock exchanges and insurrance companies - they cannot easily
> upgrade to a new server...
> >>
> >>LieGrue,
> >>strub
> >>
> >>
> >>
> >>
> >>
> >>>________________________________
> >>> From: Mark Struberg <st...@yahoo.de>
> >>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <
> deltaspike-dev@incubator.apache.org>
> >>>Sent: Sunday, May 6, 2012 2:14 PM
> >>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>
> >>>
> >>>
> >>>No, the container is NOT buggy, because it's simply NOT defined!
> >>>That's the whole mess about JNDI...
> >>>
> >>>LieGrue,
> >>>strub
> >>>
> >>>
> >>>
> >>>
> >>>>________________________________
> >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> >>>>To: Mark Struberg <st...@yahoo.de>
> >>>>Sent: Sunday, May 6, 2012 2:01 PM
> >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>
> >>>>
> >>>>So this container is buggy, report an issue ;)
> >>>>Thinking of it this jndi path issue couldnt be resolved by
> configresolvers in ds?
> >>>>- Romain
> >>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a écrit :
> >>>>
> >>>>yes, that crashes the container...
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>________________________________
> >>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
> >>>>>>To: Mark Struberg <st...@yahoo.de>;
> deltaspike-dev@incubator.apache.org
> >>>>>>Sent: Sunday, May 6, 2012 1:52 PM
> >>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>>>
> >>>>>>
> >>>>>>Mark, did you try providing a name starting with java:?
> >>>>>>- Romain
> >>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a écrit :
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>David, exactly this doesn't work out in practice!
> >>>>>>>
> >>>>>>>look at jboss5 datasource xml as an example:
> >>>>>>>
> >>>>>>><?xml version="1.0" encoding="UTF-8"?>
> >>>>>>><datasources>
> >>>>>>> <local-tx-datasource>
> >>>>>>> <jndi-name>myDS</jndi-name>
> >>>>>>>
> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-url>
> >>>>>>> <user-name>user</user-name>
> >>>>>>> <password>pwd</password>
> >>>>>>>
> <driver-class>org.postgresql.Driver</driver-class>
> >>>>>>> </local-tx-datasource>
> >>>>>>></datasources>
> >>>>>>>
> >>>>>>>This will create the following JNDI location in JBossAS5: java:/myDS
> >>>>>>>
> >>>>>>>NO comp, NO lang, NO other qualifier.
> >>>>>>>
> >>>>>>>Configuring the same in Geronimo gives you java:/comp/env/myDS
> >>>>>>>and it's again COMPLETEY different in JBossAS6, AS7, Glassfish,
> TomEE, etc
> >>>>>>>
> >>>>>>>
> >>>>>>>Thus: which JNDI location would you configure in your
> persistence.xml?
> >>>>>>>
> >>>>>>>That's the reason why we came up with the ConfigurableDataSource.
> >>>>>>>
> >>>>>>>Of course, we need to extend this concept and create a
> >>>>>>>
> >>>>>>>
> >>>>>>>public interface ConfigurableXaDataSource extends
> ConfigurableDataSource, XaDataSource {}
> >>>>>>>
> >>>>>>>See what I mean?
> >>>>>>>
> >>>>>>>LieGrue,
> >>>>>>>strub
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>----- Original Message -----
> >>>>>>>> From: David Blevins <da...@gmail.com>
> >>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> struberg@yahoo.de>
> >>>>>>>> Cc:
> >>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> >>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> >>>>>>>>
> >>>>>>>>>> In plain Tomcat or
> >>>>>>>>>> Jetty servers this needs to be configured in a
> container-specific way.
> >>>>>>>>> The problem with the container specific stuff is that every
> container
> >>>>>>>> serves the xml configured datasource on a different location in
> JNDI! So you
> >>>>>>>> cannot provide a container independent implementation that way :/
> >>>>>>>>
> >>>>>>>> The portable way would be to declare your datasource properly via
> >>>>>>>> @Resource(name="java:app/Foo", type=DataSource.class) or via
> >>>>>>>> <resource-ref> xml.
> >>>>>>>>
> >>>>>>>> Most servers can map those references with little to no config.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -David
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
The problem here is that this is NOT under our control - this is not even CDI related!
You need to _exactly_ specify the JNDI location in your persistence.xml. And this info get's parsed by JPA or the EE container at deploy time.
Maybe there's a trick with a PersistenceUnitInfo. But since those are also managed by the server (and thus show the same unspecified behaviour) we imo cannot leverage those.
LieGrue,
strub
>________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
>To: Mark Struberg <st...@yahoo.de>; deltaspike-dev@incubator.apache.org
>Sent: Sunday, May 6, 2012 2:37 PM
>Subject: Re: [DISCUSS] deltaspike-jpa module features
>
>
>I understand. On another side how many differeny locations are there? Isnt it manageable?
>- Romain
>Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit :
>
>
>>
>>PS: I _fully_ agree that this mess should best get fixed in EE7. But sadly we also need to support older containers!
>>
>>I know about folks who have OWB and CODI running on old WebSphere 6 and 7 servers. And others who use OWB on WebLogic 10.3. And those companies are big banks, stock exchanges and insurrance companies - they cannot easily upgrade to a new server...
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>
>>>________________________________
>>> From: Mark Struberg <st...@yahoo.de>
>>>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <de...@incubator.apache.org>
>>>Sent: Sunday, May 6, 2012 2:14 PM
>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>
>>>
>>>
>>>No, the container is NOT buggy, because it's simply NOT defined!
>>>That's the whole mess about JNDI...
>>>
>>>LieGrue,
>>>strub
>>>
>>>
>>>
>>>
>>>>________________________________
>>>> From: Romain Manni-Bucau <rm...@gmail.com>
>>>>To: Mark Struberg <st...@yahoo.de>
>>>>Sent: Sunday, May 6, 2012 2:01 PM
>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>>
>>>>
>>>>So this container is buggy, report an issue ;)
>>>>Thinking of it this jndi path issue couldnt be resolved by configresolvers in ds?
>>>>- Romain
>>>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a écrit :
>>>>
>>>>yes, that crashes the container...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>________________________________
>>>>>> From: Romain Manni-Bucau <rm...@gmail.com>
>>>>>>To: Mark Struberg <st...@yahoo.de>; deltaspike-dev@incubator.apache.org
>>>>>>Sent: Sunday, May 6, 2012 1:52 PM
>>>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>>>>
>>>>>>
>>>>>>Mark, did you try providing a name starting with java:?
>>>>>>- Romain
>>>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a écrit :
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>David, exactly this doesn't work out in practice!
>>>>>>>
>>>>>>>look at jboss5 datasource xml as an example:
>>>>>>>
>>>>>>><?xml version="1.0" encoding="UTF-8"?>
>>>>>>><datasources>
>>>>>>> <local-tx-datasource>
>>>>>>> <jndi-name>myDS</jndi-name>
>>>>>>> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-url>
>>>>>>> <user-name>user</user-name>
>>>>>>> <password>pwd</password>
>>>>>>> <driver-class>org.postgresql.Driver</driver-class>
>>>>>>> </local-tx-datasource>
>>>>>>></datasources>
>>>>>>>
>>>>>>>This will create the following JNDI location in JBossAS5: java:/myDS
>>>>>>>
>>>>>>>NO comp, NO lang, NO other qualifier.
>>>>>>>
>>>>>>>Configuring the same in Geronimo gives you java:/comp/env/myDS
>>>>>>>and it's again COMPLETEY different in JBossAS6, AS7, Glassfish, TomEE, etc
>>>>>>>
>>>>>>>
>>>>>>>Thus: which JNDI location would you configure in your persistence.xml?
>>>>>>>
>>>>>>>That's the reason why we came up with the ConfigurableDataSource.
>>>>>>>
>>>>>>>Of course, we need to extend this concept and create a
>>>>>>>
>>>>>>>
>>>>>>>public interface ConfigurableXaDataSource extends ConfigurableDataSource, XaDataSource {}
>>>>>>>
>>>>>>>See what I mean?
>>>>>>>
>>>>>>>LieGrue,
>>>>>>>strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>----- Original Message -----
>>>>>>>> From: David Blevins <da...@gmail.com>
>>>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@yahoo.de>
>>>>>>>> Cc:
>>>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
>>>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>>>>>>
>>>>>>>>
>>>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
>>>>>>>>
>>>>>>>>>> In plain Tomcat or
>>>>>>>>>> Jetty servers this needs to be configured in a container-specific way.
>>>>>>>>> The problem with the container specific stuff is that every container
>>>>>>>> serves the xml configured datasource on a different location in JNDI! So you
>>>>>>>> cannot provide a container independent implementation that way :/
>>>>>>>>
>>>>>>>> The portable way would be to declare your datasource properly via
>>>>>>>> @Resource(name="java:app/Foo", type=DataSource.class) or via
>>>>>>>> <resource-ref> xml.
>>>>>>>>
>>>>>>>> Most servers can map those references with little to no config.
>>>>>>>>
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I understand. On another side how many differeny locations are there? Isnt
it manageable?
- Romain
Le 6 mai 2012 14:29, "Mark Struberg" <st...@yahoo.de> a écrit :
>
>
> PS: I _fully_ agree that this mess should best get fixed in EE7. But sadly
> we also need to support older containers!
>
> I know about folks who have OWB and CODI running on old WebSphere 6 and 7
> servers. And others who use OWB on WebLogic 10.3. And those companies are
> big banks, stock exchanges and insurrance companies - they cannot easily
> upgrade to a new server...
>
> LieGrue,
> strub
>
>
>
>
>
> >________________________________
> > From: Mark Struberg <st...@yahoo.de>
> >To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <
> deltaspike-dev@incubator.apache.org>
> >Sent: Sunday, May 6, 2012 2:14 PM
> >Subject: Re: [DISCUSS] deltaspike-jpa module features
> >
> >
> >
> >No, the container is NOT buggy, because it's simply NOT defined!
> >That's the whole mess about JNDI...
> >
> >LieGrue,
> >strub
> >
> >
> >
> >
> >>________________________________
> >> From: Romain Manni-Bucau <rm...@gmail.com>
> >>To: Mark Struberg <st...@yahoo.de>
> >>Sent: Sunday, May 6, 2012 2:01 PM
> >>Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>
> >>
> >>So this container is buggy, report an issue ;)
> >>Thinking of it this jndi path issue couldnt be resolved by
> configresolvers in ds?
> >>- Romain
> >>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a écrit :
> >>
> >>yes, that crashes the container...
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>________________________________
> >>>> From: Romain Manni-Bucau <rm...@gmail.com>
> >>>>To: Mark Struberg <st...@yahoo.de>;
> deltaspike-dev@incubator.apache.org
> >>>>Sent: Sunday, May 6, 2012 1:52 PM
> >>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>
> >>>>
> >>>>Mark, did you try providing a name starting with java:?
> >>>>- Romain
> >>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a écrit :
> >>>>
> >>>>
> >>>>>
> >>>>>David, exactly this doesn't work out in practice!
> >>>>>
> >>>>>look at jboss5 datasource xml as an example:
> >>>>>
> >>>>><?xml version="1.0" encoding="UTF-8"?>
> >>>>><datasources>
> >>>>> <local-tx-datasource>
> >>>>> <jndi-name>myDS</jndi-name>
> >>>>>
> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-url>
> >>>>> <user-name>user</user-name>
> >>>>> <password>pwd</password>
> >>>>>
> <driver-class>org.postgresql.Driver</driver-class>
> >>>>> </local-tx-datasource>
> >>>>></datasources>
> >>>>>
> >>>>>This will create the following JNDI location in JBossAS5: java:/myDS
> >>>>>
> >>>>>NO comp, NO lang, NO other qualifier.
> >>>>>
> >>>>>Configuring the same in Geronimo gives you java:/comp/env/myDS
> >>>>>and it's again COMPLETEY different in JBossAS6, AS7, Glassfish,
> TomEE, etc
> >>>>>
> >>>>>
> >>>>>Thus: which JNDI location would you configure in your persistence.xml?
> >>>>>
> >>>>>That's the reason why we came up with the ConfigurableDataSource.
> >>>>>
> >>>>>Of course, we need to extend this concept and create a
> >>>>>
> >>>>>
> >>>>>public interface ConfigurableXaDataSource extends
> ConfigurableDataSource, XaDataSource {}
> >>>>>
> >>>>>See what I mean?
> >>>>>
> >>>>>LieGrue,
> >>>>>strub
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>----- Original Message -----
> >>>>>> From: David Blevins <da...@gmail.com>
> >>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> struberg@yahoo.de>
> >>>>>> Cc:
> >>>>>> Sent: Sunday, May 6, 2012 1:25 PM
> >>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>>>>>
> >>>>>>
> >>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> >>>>>>
> >>>>>>>> In plain Tomcat or
> >>>>>>>> Jetty servers this needs to be configured in a
> container-specific way.
> >>>>>>> The problem with the container specific stuff is that every
> container
> >>>>>> serves the xml configured datasource on a different location in
> JNDI! So you
> >>>>>> cannot provide a container independent implementation that way :/
> >>>>>>
> >>>>>> The portable way would be to declare your datasource properly via
> >>>>>> @Resource(name="java:app/Foo", type=DataSource.class) or via
> >>>>>> <resource-ref> xml.
> >>>>>>
> >>>>>> Most servers can map those references with little to no config.
> >>>>>>
> >>>>>>
> >>>>>> -David
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
PS: I _fully_ agree that this mess should best get fixed in EE7. But sadly we also need to support older containers!
I know about folks who have OWB and CODI running on old WebSphere 6 and 7 servers. And others who use OWB on WebLogic 10.3. And those companies are big banks, stock exchanges and insurrance companies - they cannot easily upgrade to a new server...
LieGrue,
strub
>________________________________
> From: Mark Struberg <st...@yahoo.de>
>To: Romain Manni-Bucau <rm...@gmail.com>; deltaspike <de...@incubator.apache.org>
>Sent: Sunday, May 6, 2012 2:14 PM
>Subject: Re: [DISCUSS] deltaspike-jpa module features
>
>
>
>No, the container is NOT buggy, because it's simply NOT defined!
>That's the whole mess about JNDI...
>
>LieGrue,
>strub
>
>
>
>
>>________________________________
>> From: Romain Manni-Bucau <rm...@gmail.com>
>>To: Mark Struberg <st...@yahoo.de>
>>Sent: Sunday, May 6, 2012 2:01 PM
>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>>
>>
>>So this container is buggy, report an issue ;)
>>Thinking of it this jndi path issue couldnt be resolved by configresolvers in ds?
>>- Romain
>>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a écrit :
>>
>>yes, that crashes the container...
>>>
>>>
>>>
>>>
>>>
>>>>________________________________
>>>> From: Romain Manni-Bucau <rm...@gmail.com>
>>>>To: Mark Struberg <st...@yahoo.de>; deltaspike-dev@incubator.apache.org
>>>>Sent: Sunday, May 6, 2012 1:52 PM
>>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>>
>>>>
>>>>Mark, did you try providing a name starting with java:?
>>>>- Romain
>>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a écrit :
>>>>
>>>>
>>>>>
>>>>>David, exactly this doesn't work out in practice!
>>>>>
>>>>>look at jboss5 datasource xml as an example:
>>>>>
>>>>><?xml version="1.0" encoding="UTF-8"?>
>>>>><datasources>
>>>>> <local-tx-datasource>
>>>>> <jndi-name>myDS</jndi-name>
>>>>> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-url>
>>>>> <user-name>user</user-name>
>>>>> <password>pwd</password>
>>>>> <driver-class>org.postgresql.Driver</driver-class>
>>>>> </local-tx-datasource>
>>>>></datasources>
>>>>>
>>>>>This will create the following JNDI location in JBossAS5: java:/myDS
>>>>>
>>>>>NO comp, NO lang, NO other qualifier.
>>>>>
>>>>>Configuring the same in Geronimo gives you java:/comp/env/myDS
>>>>>and it's again COMPLETEY different in JBossAS6, AS7, Glassfish, TomEE, etc
>>>>>
>>>>>
>>>>>Thus: which JNDI location would you configure in your persistence.xml?
>>>>>
>>>>>That's the reason why we came up with the ConfigurableDataSource.
>>>>>
>>>>>Of course, we need to extend this concept and create a
>>>>>
>>>>>
>>>>>public interface ConfigurableXaDataSource extends ConfigurableDataSource, XaDataSource {}
>>>>>
>>>>>See what I mean?
>>>>>
>>>>>LieGrue,
>>>>>strub
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>----- Original Message -----
>>>>>> From: David Blevins <da...@gmail.com>
>>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@yahoo.de>
>>>>>> Cc:
>>>>>> Sent: Sunday, May 6, 2012 1:25 PM
>>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>>>>
>>>>>>
>>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
>>>>>>
>>>>>>>> In plain Tomcat or
>>>>>>>> Jetty servers this needs to be configured in a container-specific way.
>>>>>>> The problem with the container specific stuff is that every container
>>>>>> serves the xml configured datasource on a different location in JNDI! So you
>>>>>> cannot provide a container independent implementation that way :/
>>>>>>
>>>>>> The portable way would be to declare your datasource properly via
>>>>>> @Resource(name="java:app/Foo", type=DataSource.class) or via
>>>>>> <resource-ref> xml.
>>>>>>
>>>>>> Most servers can map those references with little to no config.
>>>>>>
>>>>>>
>>>>>> -David
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
No, the container is NOT buggy, because it's simply NOT defined!
That's the whole mess about JNDI...
LieGrue,
strub
>________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
>To: Mark Struberg <st...@yahoo.de>
>Sent: Sunday, May 6, 2012 2:01 PM
>Subject: Re: [DISCUSS] deltaspike-jpa module features
>
>
>So this container is buggy, report an issue ;)
>Thinking of it this jndi path issue couldnt be resolved by configresolvers in ds?
>- Romain
>Le 6 mai 2012 13:58, "Mark Struberg" <st...@yahoo.de> a écrit :
>
>yes, that crashes the container...
>>
>>
>>
>>
>>
>>>________________________________
>>> From: Romain Manni-Bucau <rm...@gmail.com>
>>>To: Mark Struberg <st...@yahoo.de>; deltaspike-dev@incubator.apache.org
>>>Sent: Sunday, May 6, 2012 1:52 PM
>>>Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>
>>>
>>>Mark, did you try providing a name starting with java:?
>>>- Romain
>>>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a écrit :
>>>
>>>
>>>>
>>>>David, exactly this doesn't work out in practice!
>>>>
>>>>look at jboss5 datasource xml as an example:
>>>>
>>>><?xml version="1.0" encoding="UTF-8"?>
>>>><datasources>
>>>> <local-tx-datasource>
>>>> <jndi-name>myDS</jndi-name>
>>>> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-url>
>>>> <user-name>user</user-name>
>>>> <password>pwd</password>
>>>> <driver-class>org.postgresql.Driver</driver-class>
>>>> </local-tx-datasource>
>>>></datasources>
>>>>
>>>>This will create the following JNDI location in JBossAS5: java:/myDS
>>>>
>>>>NO comp, NO lang, NO other qualifier.
>>>>
>>>>Configuring the same in Geronimo gives you java:/comp/env/myDS
>>>>and it's again COMPLETEY different in JBossAS6, AS7, Glassfish, TomEE, etc
>>>>
>>>>
>>>>Thus: which JNDI location would you configure in your persistence.xml?
>>>>
>>>>That's the reason why we came up with the ConfigurableDataSource.
>>>>
>>>>Of course, we need to extend this concept and create a
>>>>
>>>>
>>>>public interface ConfigurableXaDataSource extends ConfigurableDataSource, XaDataSource {}
>>>>
>>>>See what I mean?
>>>>
>>>>LieGrue,
>>>>strub
>>>>
>>>>
>>>>
>>>>
>>>>----- Original Message -----
>>>>> From: David Blevins <da...@gmail.com>
>>>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@yahoo.de>
>>>>> Cc:
>>>>> Sent: Sunday, May 6, 2012 1:25 PM
>>>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>>>
>>>>>
>>>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
>>>>>
>>>>>>> In plain Tomcat or
>>>>>>> Jetty servers this needs to be configured in a container-specific way.
>>>>>> The problem with the container specific stuff is that every container
>>>>> serves the xml configured datasource on a different location in JNDI! So you
>>>>> cannot provide a container independent implementation that way :/
>>>>>
>>>>> The portable way would be to declare your datasource properly via
>>>>> @Resource(name="java:app/Foo", type=DataSource.class) or via
>>>>> <resource-ref> xml.
>>>>>
>>>>> Most servers can map those references with little to no config.
>>>>>
>>>>>
>>>>> -David
>>>>>
>>>>
>>>
>>>
>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
yes, that crashes the container...
>________________________________
> From: Romain Manni-Bucau <rm...@gmail.com>
>To: Mark Struberg <st...@yahoo.de>; deltaspike-dev@incubator.apache.org
>Sent: Sunday, May 6, 2012 1:52 PM
>Subject: Re: [DISCUSS] deltaspike-jpa module features
>
>
>Mark, did you try providing a name starting with java:?
>- Romain
>Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a écrit :
>
>
>>
>>David, exactly this doesn't work out in practice!
>>
>>look at jboss5 datasource xml as an example:
>>
>><?xml version="1.0" encoding="UTF-8"?>
>><datasources>
>> <local-tx-datasource>
>> <jndi-name>myDS</jndi-name>
>> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-url>
>> <user-name>user</user-name>
>> <password>pwd</password>
>> <driver-class>org.postgresql.Driver</driver-class>
>> </local-tx-datasource>
>></datasources>
>>
>>This will create the following JNDI location in JBossAS5: java:/myDS
>>
>>NO comp, NO lang, NO other qualifier.
>>
>>Configuring the same in Geronimo gives you java:/comp/env/myDS
>>and it's again COMPLETEY different in JBossAS6, AS7, Glassfish, TomEE, etc
>>
>>
>>Thus: which JNDI location would you configure in your persistence.xml?
>>
>>That's the reason why we came up with the ConfigurableDataSource.
>>
>>Of course, we need to extend this concept and create a
>>
>>
>>public interface ConfigurableXaDataSource extends ConfigurableDataSource, XaDataSource {}
>>
>>See what I mean?
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>----- Original Message -----
>>> From: David Blevins <da...@gmail.com>
>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@yahoo.de>
>>> Cc:
>>> Sent: Sunday, May 6, 2012 1:25 PM
>>> Subject: Re: [DISCUSS] deltaspike-jpa module features
>>>
>>>
>>> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
>>>
>>>>> In plain Tomcat or
>>>>> Jetty servers this needs to be configured in a container-specific way.
>>>> The problem with the container specific stuff is that every container
>>> serves the xml configured datasource on a different location in JNDI! So you
>>> cannot provide a container independent implementation that way :/
>>>
>>> The portable way would be to declare your datasource properly via
>>> @Resource(name="java:app/Foo", type=DataSource.class) or via
>>> <resource-ref> xml.
>>>
>>> Most servers can map those references with little to no config.
>>>
>>>
>>> -David
>>>
>>
>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Mark, did you try providing a name starting with java:?
- Romain
Le 6 mai 2012 13:49, "Mark Struberg" <st...@yahoo.de> a écrit :
>
>
> David, exactly this doesn't work out in practice!
>
> look at jboss5 datasource xml as an example:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
> <local-tx-datasource>
> <jndi-name>myDS</jndi-name>
>
> <connection-url>jdbc:postgresql://someserver:5432/someDb</connection-url>
> <user-name>user</user-name>
> <password>pwd</password>
>
> <driver-class>org.postgresql.Driver</driver-class>
> </local-tx-datasource>
> </datasources>
>
> This will create the following JNDI location in JBossAS5: java:/myDS
>
> NO comp, NO lang, NO other qualifier.
>
> Configuring the same in Geronimo gives you java:/comp/env/myDS
> and it's again COMPLETEY different in JBossAS6, AS7, Glassfish, TomEE, etc
>
>
> Thus: which JNDI location would you configure in your persistence.xml?
>
> That's the reason why we came up with the ConfigurableDataSource.
>
> Of course, we need to extend this concept and create a
>
>
> public interface ConfigurableXaDataSource extends ConfigurableDataSource,
> XaDataSource {}
>
> See what I mean?
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: David Blevins <da...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org; Mark Struberg <
> struberg@yahoo.de>
> > Cc:
> > Sent: Sunday, May 6, 2012 1:25 PM
> > Subject: Re: [DISCUSS] deltaspike-jpa module features
> >
> >
> > On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
> >
> >>> In plain Tomcat or
> >>> Jetty servers this needs to be configured in a container-specific way.
> >> The problem with the container specific stuff is that every container
> > serves the xml configured datasource on a different location in JNDI! So
> you
> > cannot provide a container independent implementation that way :/
> >
> > The portable way would be to declare your datasource properly via
> > @Resource(name="java:app/Foo", type=DataSource.class) or via
> > <resource-ref> xml.
> >
> > Most servers can map those references with little to no config.
> >
> >
> > -David
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
David, exactly this doesn't work out in practice!
look at jboss5 datasource xml as an example:
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
<jndi-name>myDS</jndi-name>
<connection-url>jdbc:postgresql://someserver:5432/someDb</connection-url>
<user-name>user</user-name>
<password>pwd</password>
<driver-class>org.postgresql.Driver</driver-class>
</local-tx-datasource>
</datasources>
This will create the following JNDI location in JBossAS5: java:/myDS
NO comp, NO lang, NO other qualifier.
Configuring the same in Geronimo gives you java:/comp/env/myDS
and it's again COMPLETEY different in JBossAS6, AS7, Glassfish, TomEE, etc
Thus: which JNDI location would you configure in your persistence.xml?
That's the reason why we came up with the ConfigurableDataSource.
Of course, we need to extend this concept and create a
public interface ConfigurableXaDataSource extends ConfigurableDataSource, XaDataSource {}
See what I mean?
LieGrue,
strub
----- Original Message -----
> From: David Blevins <da...@gmail.com>
> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Sunday, May 6, 2012 1:25 PM
> Subject: Re: [DISCUSS] deltaspike-jpa module features
>
>
> On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
>
>>> In plain Tomcat or
>>> Jetty servers this needs to be configured in a container-specific way.
>> The problem with the container specific stuff is that every container
> serves the xml configured datasource on a different location in JNDI! So you
> cannot provide a container independent implementation that way :/
>
> The portable way would be to declare your datasource properly via
> @Resource(name="java:app/Foo", type=DataSource.class) or via
> <resource-ref> xml.
>
> Most servers can map those references with little to no config.
>
>
> -David
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by David Blevins <da...@gmail.com>.
On May 6, 2012, at 2:37 AM, Mark Struberg wrote:
>> In plain Tomcat or
>> Jetty servers this needs to be configured in a container-specific way.
> The problem with the container specific stuff is that every container serves the xml configured datasource on a different location in JNDI! So you cannot provide a container independent implementation that way :/
The portable way would be to declare your datasource properly via @Resource(name="java:app/Foo", type=DataSource.class) or via <resource-ref> xml.
Most servers can map those references with little to no config.
-David
Re: AW: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Mark,
I dont see why you find dsdef limited.
Le 6 mai 2012 11:38, "Mark Struberg" <st...@yahoo.de> a écrit :
> Hi Arne!
>
> For your 1. please see the 'PersistenceStrategy' trick we did in the CODI
> TransactionalInterceptor [1]. Our interceptor is basically a facade which
> delegates all the work to the injected @Dependent PersistenceStrategy. We
> would provide 2 different implementations: a resource local and a JTA based
> one.
>
>
> Just to stress that point again:
>
>
> > ConfigurableDataSource needs to be registered in JNDI. In
> Java-EE-Containers
> > this can be done with the @DataSourceDefinition annotation.
> Yes, but ONLY if you need just one single configuration!
>
>
> > In plain Tomcat or
> > Jetty servers this needs to be configured in a container-specific way.
> The problem with the container specific stuff is that every container
> serves the xml configured datasource on a different location in JNDI! So
> you cannot provide a container independent implementation that way :/
>
>
> Rest sounds good, I'll think about it the next days!
>
> LieGrue,
> strub
>
>
> [1]
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
>
>
>
> ----- Original Message -----
> > From: Arne Limburg <ar...@openknowledge.de>
> > To: "deltaspike-dev@incubator.apache.org" <
> deltaspike-dev@incubator.apache.org>
> > Cc:
> > Sent: Sunday, May 6, 2012 11:17 AM
> > Subject: AW: [DISCUSS] deltaspike-jpa module features
> >
> > Hi,
> > I think we have different dimensions here:
> > 1. Who manages the transaction: JTA vs. RESOURCE_LOCAL (which basically
> means,
> > should entityManager.joinTransaction() or
> entityManager.getTransaction().begin()
> > be used in an @Transactional interceptor)
> > 2. From where can the datasource be obtained: From JNDI or is it defined
> via the
> > persistence properties
> > The third (minor) dimension that applies only if the datasource comes
> from JNDI:
> > Is it a jta- or non-jta-datasource
> >
> > So the first dimension has to be respected when talking about
> > transaction-management
> > and the second, when talking about datasource-configuration.
> >
> > So, as I see, currently we are talking about the second:
> > Now the question is, how to configure the datasource in both scenarios.
> And both
> > can be done with the ConfigurableDataSource:
> > First scenario: The datasource is obtained from JNDI: Then the
> > ConfigurableDataSource needs to be registered in JNDI. In
> Java-EE-Containers
> > this can be done with the @DataSourceDefinition annotation. In plain
> Tomcat or
> > Jetty servers this needs to be configured in a container-specific way.
> > Second scenario: The datasource is configured via persistence
> properties. Then
> > the ConfigurableDataSource can be configured like described in the CoDI
> wiki.
> >
> > How can deltaspike help people here? First of all we provide the
> > ConfigurableDataSource and thus enable DataSource configuration via CDI.
> > In addition, if we provide some kind of EntityManagerProducer, we can
> override
> > the persistence.xml via the additional properties map, that can be
> handed over
> > to the createEntityManagerFactory and createEntityManager methods.
> > For JNDI, we can register a ConfigurableDataSource with the
> > @DataSourceDefinition under a deltaspike-specific name and then give this
> > datasource to JPA by setting the javax.persistence.jtaDataSource or
> > javax.persistence.nonJtaDataSource property in the map.
> > For non-JNDI we can change the javax.persistence.jdbc.driver property to
> point
> > to our ConfigurableDataSource.
> >
> > We even could provide a mechanism to change from JTA to RESOURCE_LOCAL
> (i.e. for
> > production vs. testing) by specifying the
> javax.persistence.transactionType
> > property.
> >
> > What do you think about this?
> >
> > Cheers,
> > Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Sonntag, 6. Mai 2012 08:09
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: [DISCUSS] deltaspike-jpa module features
> >
> > @Mark: today using your own datasource implementation with
> @datasourcedefinition
> > you answer your need. The drawback compared to producers is you need to
> test the
> > env where producers will have stereotypes but it does the job even for
> > complicated envrt.
> >
> > - Romain
> > Le 6 mai 2012 05:02, "Jason Porter" <li...@gmail.com> a
> > écrit :
> >
> >> Wasn't there another company, Software Mill?, which had some
> >> persistence stuff we liked during formation?
> >>
> >> Sent from my iPhone
> >>
> >> On May 5, 2012, at 16:14, Mark Struberg <st...@yahoo.de> wrote:
> >>
> >> > Yes, we should first concentrate on the other 2 things. We can try
> >> > to
> >> find an even better solution than the ConfigurableDataSource.
> >> >
> >> > But I fear the @DataSourceDefinition from EE6 is completely useless
> >> > for
> >> most real world apps.
> >> > The problem which I see with it that you can only have 1 of it per
> >> 'real' DataSource. Of course that would change if there would be a
> > way
> >> to create the 'real' DataSource via CDI producers.
> >> >
> >> > But I have no idea yet how to hand over a CDI produced DataSource to
> >> > a
> >> JPA.
> >> >
> >> >
> >> > LieGrue,
> >> > strub
> >> >
> >> >
> >> >
> >> > ----- Original Message -----
> >> >> From: Romain Manni-Bucau <rm...@gmail.com>
> >> >> To: deltaspike-dev@incubator.apache.org
> >> >> Cc:
> >> >> Sent: Saturday, May 5, 2012 11:29 PM
> >> >> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >> >>
> >> >> With my note on datasourcedefinition i wanted to avoid to add sthg
> > new.
> >> I'd
> >> >> prefer to fix existing API/specs.
> >> >>
> >> >> Adding sthg new simply creates another mess...no?
> >> >>
> >> >> - Romain
> >> >> Le 5 mai 2012 22:39, "Paul Dijou"
> > <pa...@gmail.com> a
> >> >> écrit :
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> Big +1 for all suggestions from Mark.
> >> >>>
> >> >>> Also +1 for some util classes for common operations like CRUD
> > and
> >> >>> pagination. Maybe inspiration from Seam Application Framework
> >> >>> (Home,
> >> Query,
> >> >>> Controller) in Seam 2 [1] or from DataValve [2].
> >> >>>
> >> >>> Regards,
> >> >>>
> >> >>> Paul.
> >> >>>
> >> >>> [1]
> >> >>>
> >> http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.
> >> html
> >> >>>
> >> >>> [2] http://www.andygibson.net/blog/projects/datavalve/
> >> >>>
> >> >>> 2012/5/5 Romain Manni-Bucau <rm...@gmail.com>
> >> >>>
> >> >>>> Maybe using a datasource bean managed by cdi as a jpa
> > datasource
> >> >> source
> >> >>> can
> >> >>>> be added to jpa or cdi (it is always a bit hard to decide
> > which
> >> >>>> specs qhould contain a new feature ;))?
> >> >>>> Le 5 mai 2012 00:55, "Romain Manni-Bucau"
> >> >> <rm...@gmail.com> a
> >> >>>> écrit :
> >> >>>>
> >> >>>>> Hi,
> >> >>>>>
> >> >>>>> isn't the ConfigurableDataSource in JEE6?
> >> >> (datasourceconfiguration by
> >> >>>>> annotation or in the web.xml)?
> >> >>>>>
> >> >>>>> a really really big +1 for a pagination solution
> > (typically a
> >> >> hades
> >> >>> light
> >> >>>>> is a must have!)
> >> >>>>>
> >> >>>>> - Romain
> >> >>>>>
> >> >>>>>
> >> >>>>> 2012/5/4 Gerhard Petracek
> > <ge...@gmail.com>
> >> >>>>>
> >> >>>>>> hi @ all,
> >> >>>>>>
> >> >>>>>> @ a)
> >> >>>>>> +1
> >> >>>>>>
> >> >>>>>> @ b)
> >> >>>>>> +1 for the basic concepts, however, @Transactional
> > and
> >> >>>> @TransactionScoped
> >> >>>>>> need to be refactored (i'm currently working
> > on it).
> >> >>>>>>
> >> >>>>>> furthermore, we should discuss a thin query layer
> > which
> >> >> supports e.g.
> >> >>>>>> pagination,... easily (we also need it for a
> > security-jpa
> >> >> module).
> >> >>>>>>
> >> >>>>>> regards,
> >> >>>>>> gerhard
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> 2012/5/4 Mark Struberg <st...@yahoo.de>
> >> >>>>>>
> >> >>>>>>> Hi!
> >> >>>>>>>
> >> >>>>>>> It's time to start the discussion about
> > our
> >> >> deltaspike-jpa module I
> >> >>>>>> think
> >> >>>>>>> ;)
> >> >>>>>>>
> >> >>>>>>> a.) where
> >> >>>>>>> I suggest that we create a ee-modules
> > project with
> >> >> submodules jsf,
> >> >>>> jpa,
> >> >>>>>>> etc
> >> >>>>>>>
> >> >>>>>>> b.) what
> >> >>>>>>> *) @Transactional
> >> >>>>>>> *) TransactionalInterceptor with
> >> >> SimplePersistenceStrategy,
> >> >>>>>>> JtaPersistenceStrategy
> >> >>>>>>> *) ConfigurableDataSource, evaluate if we
> > can make use
> >> >> of a special
> >> >>>>>>> PersistenceUnitInfo for JPA2 providers, but
> > would that
> >> >> work in EE
> >> >>>>>>> containers as well?
> >> >>>>>>>
> >> >>>>>>> Because I often get asked if we can add this:
> > I think we
> >> >> do _not_
> >> >>> need
> >> >>>>>> to
> >> >>>>>>> cover the (imo) broken Exception handling
> > stuff which
> >> >> spring
> >> >>>> introduced
> >> >>>>>> in
> >> >>>>>>> their transaction interceptor. An Exception is
> > an
> >> >> Exception is an
> >> >>>>>>> Exception! Logical return values and Business
> > results
> >> >> must get
> >> >>>>>> propagated
> >> >>>>>>> via standard java return values or content
> > holder
> >> >> objects.
> >> >>>>>>>
> >> >>>>>>> Oki the details:
> >> >>>>>>>
> >> >>>>>>> 1.) @Transational
> >> >>>>>>>
> >> >>>>>>> I suggest that we temporarily implement the
> >> >> javax.transaction.*
> >> >>> stuff
> >> >>>> of
> >> >>>>>>> the _new_ Transaction Specification in
> > DeltaSpike. We
> >> >> can take parts
> >> >>>>>> from
> >> >>>>>>> OpenEJB, some JBoss api stuff (as far as
> > covered by the
> >> >> grants) and
> >> >>>>>> various
> >> >>>>>>> geronimo spec jars [1]
> >> >>>>>>> Once the spec is finished, we will move all
> > the
> >> >> transaction-api.jar
> >> >>>>>> stuff
> >> >>>>>>> over to geronimo-specs [1]. Since this all is
> > ALv2 it
> >> >> will be no
> >> >>>> problem
> >> >>>>>>> for JBoss folks to also just take the code and
> > provide
> >> >> it in the
> >> >>>> JBossAS
> >> >>>>>>> project once we are finished.
> >> >>>>>>>
> >> >>>>>>> 2.) I like the way we implemented the
> >> >> TransactionalInterceptor in
> >> >>> CODI
> >> >>>>>>> [2]. Our interceptor basically does exactly
> > ...
> >> >> *nothing* ;)
> >> >>>>>>> All the work is done via an @Dependent
> >> >> PersistenceStrategy which
> >> >>> gets
> >> >>>>>>> injected into the interceptor. @Dependent
> > because then
> >> >> we don't get
> >> >>>> any
> >> >>>>>>> interceptor and it's really fast.
> >> >>>>>>> The BIG benefit of this little trick is that
> > we are
> >> >> able to provide
> >> >>>> and
> >> >>>>>>> use DIFFERENT PersistenceStrategies! A user
> > can use
> >> >> @Alternative,
> >> >>>>>>> @Specializes etc to define which
> > PersistenceStrategy he
> >> >> likes to use
> >> >>>> in
> >> >>>>>> his
> >> >>>>>>> project.
> >> >>>>>>>
> >> >>>>>>> By default I'd like to provide the
> > following
> >> >> PersistenceStrategies:
> >> >>>>>>> * SimplePersistenceStrategy: does just flush
> > on all
> >> >> involved
> >> >>>>>>> EntityManagers and afterwards a commit. Not
> > JTA
> >> >> transaction save,
> >> >>> but
> >> >>>>>> good
> >> >>>>>>> enough for most use cases
> >> >>>>>>> * JtaPersistenceStrategy: uses a JTA bound
> >> >> @UserTransaction to
> >> >>>> control
> >> >>>>>>> the EntitaManagers. This needs some
> > exploration how we
> >> >> can do it.
> >> >>>> David
> >> >>>>>>> Blevins and Arne Limburg are pretty good into
> > this
> >> >> stuff. I'm
> >> >>> dreaming
> >> >>>>>> of
> >> >>>>>>> kind of the features of EJB standard
> > transations, but
> >> >> NOT just for
> >> >>> an
> >> >>>>>> EJB
> >> >>>>>>> invocation, but @RequestScoped! The first
> > invocation
> >> >> starts the
> >> >>>>>>> UserTransaction, the @Disposes closes it. Just
> > an idea
> >> >> ...
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> 3.) ConfigurableDataSource
> >> >>>>>>> You all know the dilemma: you cannot make a
> > JNDI
> >> >> configuration in a
> >> >>>> way
> >> >>>>>>> that this stuff works with multiple EE servers
> > since the
> >> >> locations
> >> >>>> where
> >> >>>>>>> you have your DataSource configured will pop
> > up under
> >> >> different
> >> >>>>>> locations
> >> >>>>>>> in JNDI (based on which EE server/version you
> > take).
> >> >> Otoh I don't
> >> >>> like
> >> >>>>>> to
> >> >>>>>>> hardcode my credentials to the persistence.xml
> > neither.
> >> >>>>>>>
> >> >>>>>>> Thus we came up with the
> > ConfigurableDataSource [3]which
> >> >> just moves
> >> >>>> this
> >> >>>>>>> information to a CDI bean where you can use
> >> >>>>>>> @Exclude(ifNotInProjectStage...),
> > @Alternative,
> >> >> @Specializes and
> >> >>> even
> >> >>>>>>> programmatic lookup!. I call this
> > 'typesafe
> >> >> configuration'...
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> Oki, any other ideas?
> >> >>>>>>>
> >> >>>>>>> LieGrue,
> >> >>>>>>> strub
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> [1]
> >> >> http://repo1.maven.org/maven2/org/apache/geronimo/specs/
> >> >>>>>>>
> >> >>>>>>> [2]
> >> >>>>>>>
> >> >>>>>>
> >> >>>>
> >> >>>
> >> >>
> >> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modu
> >> les/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jp
> >> a/impl/transaction/TransactionalInterceptor.java
> >> >>>>>>>
> >> >>>>>>> [3]
> >> >>>>>>>
> >> >>>>>>
> >> >>>>
> >> >>>
> >> >>
> >> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDa
> >> taSource%28sincev1.0.2%29
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> >
>
Re: AW: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
Hi Arne!
For your 1. please see the 'PersistenceStrategy' trick we did in the CODI TransactionalInterceptor [1]. Our interceptor is basically a facade which delegates all the work to the injected @Dependent PersistenceStrategy. We would provide 2 different implementations: a resource local and a JTA based one.
Just to stress that point again:
> ConfigurableDataSource needs to be registered in JNDI. In Java-EE-Containers
> this can be done with the @DataSourceDefinition annotation.
Yes, but ONLY if you need just one single configuration!
> In plain Tomcat or
> Jetty servers this needs to be configured in a container-specific way.
The problem with the container specific stuff is that every container serves the xml configured datasource on a different location in JNDI! So you cannot provide a container independent implementation that way :/
Rest sounds good, I'll think about it the next days!
LieGrue,
strub
[1] https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
----- Original Message -----
> From: Arne Limburg <ar...@openknowledge.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> Cc:
> Sent: Sunday, May 6, 2012 11:17 AM
> Subject: AW: [DISCUSS] deltaspike-jpa module features
>
> Hi,
> I think we have different dimensions here:
> 1. Who manages the transaction: JTA vs. RESOURCE_LOCAL (which basically means,
> should entityManager.joinTransaction() or entityManager.getTransaction().begin()
> be used in an @Transactional interceptor)
> 2. From where can the datasource be obtained: From JNDI or is it defined via the
> persistence properties
> The third (minor) dimension that applies only if the datasource comes from JNDI:
> Is it a jta- or non-jta-datasource
>
> So the first dimension has to be respected when talking about
> transaction-management
> and the second, when talking about datasource-configuration.
>
> So, as I see, currently we are talking about the second:
> Now the question is, how to configure the datasource in both scenarios. And both
> can be done with the ConfigurableDataSource:
> First scenario: The datasource is obtained from JNDI: Then the
> ConfigurableDataSource needs to be registered in JNDI. In Java-EE-Containers
> this can be done with the @DataSourceDefinition annotation. In plain Tomcat or
> Jetty servers this needs to be configured in a container-specific way.
> Second scenario: The datasource is configured via persistence properties. Then
> the ConfigurableDataSource can be configured like described in the CoDI wiki.
>
> How can deltaspike help people here? First of all we provide the
> ConfigurableDataSource and thus enable DataSource configuration via CDI.
> In addition, if we provide some kind of EntityManagerProducer, we can override
> the persistence.xml via the additional properties map, that can be handed over
> to the createEntityManagerFactory and createEntityManager methods.
> For JNDI, we can register a ConfigurableDataSource with the
> @DataSourceDefinition under a deltaspike-specific name and then give this
> datasource to JPA by setting the javax.persistence.jtaDataSource or
> javax.persistence.nonJtaDataSource property in the map.
> For non-JNDI we can change the javax.persistence.jdbc.driver property to point
> to our ConfigurableDataSource.
>
> We even could provide a mechanism to change from JTA to RESOURCE_LOCAL (i.e. for
> production vs. testing) by specifying the javax.persistence.transactionType
> property.
>
> What do you think about this?
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Sonntag, 6. Mai 2012 08:09
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS] deltaspike-jpa module features
>
> @Mark: today using your own datasource implementation with @datasourcedefinition
> you answer your need. The drawback compared to producers is you need to test the
> env where producers will have stereotypes but it does the job even for
> complicated envrt.
>
> - Romain
> Le 6 mai 2012 05:02, "Jason Porter" <li...@gmail.com> a
> écrit :
>
>> Wasn't there another company, Software Mill?, which had some
>> persistence stuff we liked during formation?
>>
>> Sent from my iPhone
>>
>> On May 5, 2012, at 16:14, Mark Struberg <st...@yahoo.de> wrote:
>>
>> > Yes, we should first concentrate on the other 2 things. We can try
>> > to
>> find an even better solution than the ConfigurableDataSource.
>> >
>> > But I fear the @DataSourceDefinition from EE6 is completely useless
>> > for
>> most real world apps.
>> > The problem which I see with it that you can only have 1 of it per
>> 'real' DataSource. Of course that would change if there would be a
> way
>> to create the 'real' DataSource via CDI producers.
>> >
>> > But I have no idea yet how to hand over a CDI produced DataSource to
>> > a
>> JPA.
>> >
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> >
>> > ----- Original Message -----
>> >> From: Romain Manni-Bucau <rm...@gmail.com>
>> >> To: deltaspike-dev@incubator.apache.org
>> >> Cc:
>> >> Sent: Saturday, May 5, 2012 11:29 PM
>> >> Subject: Re: [DISCUSS] deltaspike-jpa module features
>> >>
>> >> With my note on datasourcedefinition i wanted to avoid to add sthg
> new.
>> I'd
>> >> prefer to fix existing API/specs.
>> >>
>> >> Adding sthg new simply creates another mess...no?
>> >>
>> >> - Romain
>> >> Le 5 mai 2012 22:39, "Paul Dijou"
> <pa...@gmail.com> a
>> >> écrit :
>> >>
>> >>> Hi,
>> >>>
>> >>> Big +1 for all suggestions from Mark.
>> >>>
>> >>> Also +1 for some util classes for common operations like CRUD
> and
>> >>> pagination. Maybe inspiration from Seam Application Framework
>> >>> (Home,
>> Query,
>> >>> Controller) in Seam 2 [1] or from DataValve [2].
>> >>>
>> >>> Regards,
>> >>>
>> >>> Paul.
>> >>>
>> >>> [1]
>> >>>
>> http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.
>> html
>> >>>
>> >>> [2] http://www.andygibson.net/blog/projects/datavalve/
>> >>>
>> >>> 2012/5/5 Romain Manni-Bucau <rm...@gmail.com>
>> >>>
>> >>>> Maybe using a datasource bean managed by cdi as a jpa
> datasource
>> >> source
>> >>> can
>> >>>> be added to jpa or cdi (it is always a bit hard to decide
> which
>> >>>> specs qhould contain a new feature ;))?
>> >>>> Le 5 mai 2012 00:55, "Romain Manni-Bucau"
>> >> <rm...@gmail.com> a
>> >>>> écrit :
>> >>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> isn't the ConfigurableDataSource in JEE6?
>> >> (datasourceconfiguration by
>> >>>>> annotation or in the web.xml)?
>> >>>>>
>> >>>>> a really really big +1 for a pagination solution
> (typically a
>> >> hades
>> >>> light
>> >>>>> is a must have!)
>> >>>>>
>> >>>>> - Romain
>> >>>>>
>> >>>>>
>> >>>>> 2012/5/4 Gerhard Petracek
> <ge...@gmail.com>
>> >>>>>
>> >>>>>> hi @ all,
>> >>>>>>
>> >>>>>> @ a)
>> >>>>>> +1
>> >>>>>>
>> >>>>>> @ b)
>> >>>>>> +1 for the basic concepts, however, @Transactional
> and
>> >>>> @TransactionScoped
>> >>>>>> need to be refactored (i'm currently working
> on it).
>> >>>>>>
>> >>>>>> furthermore, we should discuss a thin query layer
> which
>> >> supports e.g.
>> >>>>>> pagination,... easily (we also need it for a
> security-jpa
>> >> module).
>> >>>>>>
>> >>>>>> regards,
>> >>>>>> gerhard
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 2012/5/4 Mark Struberg <st...@yahoo.de>
>> >>>>>>
>> >>>>>>> Hi!
>> >>>>>>>
>> >>>>>>> It's time to start the discussion about
> our
>> >> deltaspike-jpa module I
>> >>>>>> think
>> >>>>>>> ;)
>> >>>>>>>
>> >>>>>>> a.) where
>> >>>>>>> I suggest that we create a ee-modules
> project with
>> >> submodules jsf,
>> >>>> jpa,
>> >>>>>>> etc
>> >>>>>>>
>> >>>>>>> b.) what
>> >>>>>>> *) @Transactional
>> >>>>>>> *) TransactionalInterceptor with
>> >> SimplePersistenceStrategy,
>> >>>>>>> JtaPersistenceStrategy
>> >>>>>>> *) ConfigurableDataSource, evaluate if we
> can make use
>> >> of a special
>> >>>>>>> PersistenceUnitInfo for JPA2 providers, but
> would that
>> >> work in EE
>> >>>>>>> containers as well?
>> >>>>>>>
>> >>>>>>> Because I often get asked if we can add this:
> I think we
>> >> do _not_
>> >>> need
>> >>>>>> to
>> >>>>>>> cover the (imo) broken Exception handling
> stuff which
>> >> spring
>> >>>> introduced
>> >>>>>> in
>> >>>>>>> their transaction interceptor. An Exception is
> an
>> >> Exception is an
>> >>>>>>> Exception! Logical return values and Business
> results
>> >> must get
>> >>>>>> propagated
>> >>>>>>> via standard java return values or content
> holder
>> >> objects.
>> >>>>>>>
>> >>>>>>> Oki the details:
>> >>>>>>>
>> >>>>>>> 1.) @Transational
>> >>>>>>>
>> >>>>>>> I suggest that we temporarily implement the
>> >> javax.transaction.*
>> >>> stuff
>> >>>> of
>> >>>>>>> the _new_ Transaction Specification in
> DeltaSpike. We
>> >> can take parts
>> >>>>>> from
>> >>>>>>> OpenEJB, some JBoss api stuff (as far as
> covered by the
>> >> grants) and
>> >>>>>> various
>> >>>>>>> geronimo spec jars [1]
>> >>>>>>> Once the spec is finished, we will move all
> the
>> >> transaction-api.jar
>> >>>>>> stuff
>> >>>>>>> over to geronimo-specs [1]. Since this all is
> ALv2 it
>> >> will be no
>> >>>> problem
>> >>>>>>> for JBoss folks to also just take the code and
> provide
>> >> it in the
>> >>>> JBossAS
>> >>>>>>> project once we are finished.
>> >>>>>>>
>> >>>>>>> 2.) I like the way we implemented the
>> >> TransactionalInterceptor in
>> >>> CODI
>> >>>>>>> [2]. Our interceptor basically does exactly
> ...
>> >> *nothing* ;)
>> >>>>>>> All the work is done via an @Dependent
>> >> PersistenceStrategy which
>> >>> gets
>> >>>>>>> injected into the interceptor. @Dependent
> because then
>> >> we don't get
>> >>>> any
>> >>>>>>> interceptor and it's really fast.
>> >>>>>>> The BIG benefit of this little trick is that
> we are
>> >> able to provide
>> >>>> and
>> >>>>>>> use DIFFERENT PersistenceStrategies! A user
> can use
>> >> @Alternative,
>> >>>>>>> @Specializes etc to define which
> PersistenceStrategy he
>> >> likes to use
>> >>>> in
>> >>>>>> his
>> >>>>>>> project.
>> >>>>>>>
>> >>>>>>> By default I'd like to provide the
> following
>> >> PersistenceStrategies:
>> >>>>>>> * SimplePersistenceStrategy: does just flush
> on all
>> >> involved
>> >>>>>>> EntityManagers and afterwards a commit. Not
> JTA
>> >> transaction save,
>> >>> but
>> >>>>>> good
>> >>>>>>> enough for most use cases
>> >>>>>>> * JtaPersistenceStrategy: uses a JTA bound
>> >> @UserTransaction to
>> >>>> control
>> >>>>>>> the EntitaManagers. This needs some
> exploration how we
>> >> can do it.
>> >>>> David
>> >>>>>>> Blevins and Arne Limburg are pretty good into
> this
>> >> stuff. I'm
>> >>> dreaming
>> >>>>>> of
>> >>>>>>> kind of the features of EJB standard
> transations, but
>> >> NOT just for
>> >>> an
>> >>>>>> EJB
>> >>>>>>> invocation, but @RequestScoped! The first
> invocation
>> >> starts the
>> >>>>>>> UserTransaction, the @Disposes closes it. Just
> an idea
>> >> ...
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 3.) ConfigurableDataSource
>> >>>>>>> You all know the dilemma: you cannot make a
> JNDI
>> >> configuration in a
>> >>>> way
>> >>>>>>> that this stuff works with multiple EE servers
> since the
>> >> locations
>> >>>> where
>> >>>>>>> you have your DataSource configured will pop
> up under
>> >> different
>> >>>>>> locations
>> >>>>>>> in JNDI (based on which EE server/version you
> take).
>> >> Otoh I don't
>> >>> like
>> >>>>>> to
>> >>>>>>> hardcode my credentials to the persistence.xml
> neither.
>> >>>>>>>
>> >>>>>>> Thus we came up with the
> ConfigurableDataSource [3]which
>> >> just moves
>> >>>> this
>> >>>>>>> information to a CDI bean where you can use
>> >>>>>>> @Exclude(ifNotInProjectStage...),
> @Alternative,
>> >> @Specializes and
>> >>> even
>> >>>>>>> programmatic lookup!. I call this
> 'typesafe
>> >> configuration'...
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Oki, any other ideas?
>> >>>>>>>
>> >>>>>>> LieGrue,
>> >>>>>>> strub
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> [1]
>> >> http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>> >>>>>>>
>> >>>>>>> [2]
>> >>>>>>>
>> >>>>>>
>> >>>>
>> >>>
>> >>
>> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modu
>> les/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jp
>> a/impl/transaction/TransactionalInterceptor.java
>> >>>>>>>
>> >>>>>>> [3]
>> >>>>>>>
>> >>>>>>
>> >>>>
>> >>>
>> >>
>> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDa
>> taSource%28sincev1.0.2%29
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>>
>
AW: [DISCUSS] deltaspike-jpa module features
Posted by Arne Limburg <ar...@openknowledge.de>.
Hi,
I think we have different dimensions here:
1. Who manages the transaction: JTA vs. RESOURCE_LOCAL (which basically means, should entityManager.joinTransaction() or entityManager.getTransaction().begin() be used in an @Transactional interceptor)
2. From where can the datasource be obtained: From JNDI or is it defined via the persistence properties
The third (minor) dimension that applies only if the datasource comes from JNDI: Is it a jta- or non-jta-datasource
So the first dimension has to be respected when talking about transaction-management
and the second, when talking about datasource-configuration.
So, as I see, currently we are talking about the second:
Now the question is, how to configure the datasource in both scenarios. And both can be done with the ConfigurableDataSource:
First scenario: The datasource is obtained from JNDI: Then the ConfigurableDataSource needs to be registered in JNDI. In Java-EE-Containers this can be done with the @DataSourceDefinition annotation. In plain Tomcat or Jetty servers this needs to be configured in a container-specific way.
Second scenario: The datasource is configured via persistence properties. Then the ConfigurableDataSource can be configured like described in the CoDI wiki.
How can deltaspike help people here? First of all we provide the ConfigurableDataSource and thus enable DataSource configuration via CDI.
In addition, if we provide some kind of EntityManagerProducer, we can override the persistence.xml via the additional properties map, that can be handed over to the createEntityManagerFactory and createEntityManager methods.
For JNDI, we can register a ConfigurableDataSource with the @DataSourceDefinition under a deltaspike-specific name and then give this datasource to JPA by setting the javax.persistence.jtaDataSource or javax.persistence.nonJtaDataSource property in the map.
For non-JNDI we can change the javax.persistence.jdbc.driver property to point to our ConfigurableDataSource.
We even could provide a mechanism to change from JTA to RESOURCE_LOCAL (i.e. for production vs. testing) by specifying the javax.persistence.transactionType property.
What do you think about this?
Cheers,
Arne
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Sonntag, 6. Mai 2012 08:09
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS] deltaspike-jpa module features
@Mark: today using your own datasource implementation with @datasourcedefinition you answer your need. The drawback compared to producers is you need to test the env where producers will have stereotypes but it does the job even for complicated envrt.
- Romain
Le 6 mai 2012 05:02, "Jason Porter" <li...@gmail.com> a écrit :
> Wasn't there another company, Software Mill?, which had some
> persistence stuff we liked during formation?
>
> Sent from my iPhone
>
> On May 5, 2012, at 16:14, Mark Struberg <st...@yahoo.de> wrote:
>
> > Yes, we should first concentrate on the other 2 things. We can try
> > to
> find an even better solution than the ConfigurableDataSource.
> >
> > But I fear the @DataSourceDefinition from EE6 is completely useless
> > for
> most real world apps.
> > The problem which I see with it that you can only have 1 of it per
> 'real' DataSource. Of course that would change if there would be a way
> to create the 'real' DataSource via CDI producers.
> >
> > But I have no idea yet how to hand over a CDI produced DataSource to
> > a
> JPA.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Romain Manni-Bucau <rm...@gmail.com>
> >> To: deltaspike-dev@incubator.apache.org
> >> Cc:
> >> Sent: Saturday, May 5, 2012 11:29 PM
> >> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>
> >> With my note on datasourcedefinition i wanted to avoid to add sthg new.
> I'd
> >> prefer to fix existing API/specs.
> >>
> >> Adding sthg new simply creates another mess...no?
> >>
> >> - Romain
> >> Le 5 mai 2012 22:39, "Paul Dijou" <pa...@gmail.com> a
> >> écrit :
> >>
> >>> Hi,
> >>>
> >>> Big +1 for all suggestions from Mark.
> >>>
> >>> Also +1 for some util classes for common operations like CRUD and
> >>> pagination. Maybe inspiration from Seam Application Framework
> >>> (Home,
> Query,
> >>> Controller) in Seam 2 [1] or from DataValve [2].
> >>>
> >>> Regards,
> >>>
> >>> Paul.
> >>>
> >>> [1]
> >>>
> http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.
> html
> >>>
> >>> [2] http://www.andygibson.net/blog/projects/datavalve/
> >>>
> >>> 2012/5/5 Romain Manni-Bucau <rm...@gmail.com>
> >>>
> >>>> Maybe using a datasource bean managed by cdi as a jpa datasource
> >> source
> >>> can
> >>>> be added to jpa or cdi (it is always a bit hard to decide which
> >>>> specs qhould contain a new feature ;))?
> >>>> Le 5 mai 2012 00:55, "Romain Manni-Bucau"
> >> <rm...@gmail.com> a
> >>>> écrit :
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> isn't the ConfigurableDataSource in JEE6?
> >> (datasourceconfiguration by
> >>>>> annotation or in the web.xml)?
> >>>>>
> >>>>> a really really big +1 for a pagination solution (typically a
> >> hades
> >>> light
> >>>>> is a must have!)
> >>>>>
> >>>>> - Romain
> >>>>>
> >>>>>
> >>>>> 2012/5/4 Gerhard Petracek <ge...@gmail.com>
> >>>>>
> >>>>>> hi @ all,
> >>>>>>
> >>>>>> @ a)
> >>>>>> +1
> >>>>>>
> >>>>>> @ b)
> >>>>>> +1 for the basic concepts, however, @Transactional and
> >>>> @TransactionScoped
> >>>>>> need to be refactored (i'm currently working on it).
> >>>>>>
> >>>>>> furthermore, we should discuss a thin query layer which
> >> supports e.g.
> >>>>>> pagination,... easily (we also need it for a security-jpa
> >> module).
> >>>>>>
> >>>>>> regards,
> >>>>>> gerhard
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2012/5/4 Mark Struberg <st...@yahoo.de>
> >>>>>>
> >>>>>>> Hi!
> >>>>>>>
> >>>>>>> It's time to start the discussion about our
> >> deltaspike-jpa module I
> >>>>>> think
> >>>>>>> ;)
> >>>>>>>
> >>>>>>> a.) where
> >>>>>>> I suggest that we create a ee-modules project with
> >> submodules jsf,
> >>>> jpa,
> >>>>>>> etc
> >>>>>>>
> >>>>>>> b.) what
> >>>>>>> *) @Transactional
> >>>>>>> *) TransactionalInterceptor with
> >> SimplePersistenceStrategy,
> >>>>>>> JtaPersistenceStrategy
> >>>>>>> *) ConfigurableDataSource, evaluate if we can make use
> >> of a special
> >>>>>>> PersistenceUnitInfo for JPA2 providers, but would that
> >> work in EE
> >>>>>>> containers as well?
> >>>>>>>
> >>>>>>> Because I often get asked if we can add this: I think we
> >> do _not_
> >>> need
> >>>>>> to
> >>>>>>> cover the (imo) broken Exception handling stuff which
> >> spring
> >>>> introduced
> >>>>>> in
> >>>>>>> their transaction interceptor. An Exception is an
> >> Exception is an
> >>>>>>> Exception! Logical return values and Business results
> >> must get
> >>>>>> propagated
> >>>>>>> via standard java return values or content holder
> >> objects.
> >>>>>>>
> >>>>>>> Oki the details:
> >>>>>>>
> >>>>>>> 1.) @Transational
> >>>>>>>
> >>>>>>> I suggest that we temporarily implement the
> >> javax.transaction.*
> >>> stuff
> >>>> of
> >>>>>>> the _new_ Transaction Specification in DeltaSpike. We
> >> can take parts
> >>>>>> from
> >>>>>>> OpenEJB, some JBoss api stuff (as far as covered by the
> >> grants) and
> >>>>>> various
> >>>>>>> geronimo spec jars [1]
> >>>>>>> Once the spec is finished, we will move all the
> >> transaction-api.jar
> >>>>>> stuff
> >>>>>>> over to geronimo-specs [1]. Since this all is ALv2 it
> >> will be no
> >>>> problem
> >>>>>>> for JBoss folks to also just take the code and provide
> >> it in the
> >>>> JBossAS
> >>>>>>> project once we are finished.
> >>>>>>>
> >>>>>>> 2.) I like the way we implemented the
> >> TransactionalInterceptor in
> >>> CODI
> >>>>>>> [2]. Our interceptor basically does exactly ...
> >> *nothing* ;)
> >>>>>>> All the work is done via an @Dependent
> >> PersistenceStrategy which
> >>> gets
> >>>>>>> injected into the interceptor. @Dependent because then
> >> we don't get
> >>>> any
> >>>>>>> interceptor and it's really fast.
> >>>>>>> The BIG benefit of this little trick is that we are
> >> able to provide
> >>>> and
> >>>>>>> use DIFFERENT PersistenceStrategies! A user can use
> >> @Alternative,
> >>>>>>> @Specializes etc to define which PersistenceStrategy he
> >> likes to use
> >>>> in
> >>>>>> his
> >>>>>>> project.
> >>>>>>>
> >>>>>>> By default I'd like to provide the following
> >> PersistenceStrategies:
> >>>>>>> * SimplePersistenceStrategy: does just flush on all
> >> involved
> >>>>>>> EntityManagers and afterwards a commit. Not JTA
> >> transaction save,
> >>> but
> >>>>>> good
> >>>>>>> enough for most use cases
> >>>>>>> * JtaPersistenceStrategy: uses a JTA bound
> >> @UserTransaction to
> >>>> control
> >>>>>>> the EntitaManagers. This needs some exploration how we
> >> can do it.
> >>>> David
> >>>>>>> Blevins and Arne Limburg are pretty good into this
> >> stuff. I'm
> >>> dreaming
> >>>>>> of
> >>>>>>> kind of the features of EJB standard transations, but
> >> NOT just for
> >>> an
> >>>>>> EJB
> >>>>>>> invocation, but @RequestScoped! The first invocation
> >> starts the
> >>>>>>> UserTransaction, the @Disposes closes it. Just an idea
> >> ...
> >>>>>>>
> >>>>>>>
> >>>>>>> 3.) ConfigurableDataSource
> >>>>>>> You all know the dilemma: you cannot make a JNDI
> >> configuration in a
> >>>> way
> >>>>>>> that this stuff works with multiple EE servers since the
> >> locations
> >>>> where
> >>>>>>> you have your DataSource configured will pop up under
> >> different
> >>>>>> locations
> >>>>>>> in JNDI (based on which EE server/version you take).
> >> Otoh I don't
> >>> like
> >>>>>> to
> >>>>>>> hardcode my credentials to the persistence.xml neither.
> >>>>>>>
> >>>>>>> Thus we came up with the ConfigurableDataSource [3]which
> >> just moves
> >>>> this
> >>>>>>> information to a CDI bean where you can use
> >>>>>>> @Exclude(ifNotInProjectStage...), @Alternative,
> >> @Specializes and
> >>> even
> >>>>>>> programmatic lookup!. I call this 'typesafe
> >> configuration'...
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Oki, any other ideas?
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>> [1]
> >> http://repo1.maven.org/maven2/org/apache/geronimo/specs/
> >>>>>>>
> >>>>>>> [2]
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modu
> les/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jp
> a/impl/transaction/TransactionalInterceptor.java
> >>>>>>>
> >>>>>>> [3]
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDa
> taSource%28sincev1.0.2%29
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
@Mark: today using your own datasource implementation with
@datasourcedefinition you answer your need. The drawback compared to
producers is you need to test the env where producers will have stereotypes
but it does the job even for complicated envrt.
- Romain
Le 6 mai 2012 05:02, "Jason Porter" <li...@gmail.com> a écrit :
> Wasn't there another company, Software Mill?, which had some persistence
> stuff we liked during formation?
>
> Sent from my iPhone
>
> On May 5, 2012, at 16:14, Mark Struberg <st...@yahoo.de> wrote:
>
> > Yes, we should first concentrate on the other 2 things. We can try to
> find an even better solution than the ConfigurableDataSource.
> >
> > But I fear the @DataSourceDefinition from EE6 is completely useless for
> most real world apps.
> > The problem which I see with it that you can only have 1 of it per
> 'real' DataSource. Of course that would change if there would be a way to
> create the 'real' DataSource via CDI producers.
> >
> > But I have no idea yet how to hand over a CDI produced DataSource to a
> JPA.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Romain Manni-Bucau <rm...@gmail.com>
> >> To: deltaspike-dev@incubator.apache.org
> >> Cc:
> >> Sent: Saturday, May 5, 2012 11:29 PM
> >> Subject: Re: [DISCUSS] deltaspike-jpa module features
> >>
> >> With my note on datasourcedefinition i wanted to avoid to add sthg new.
> I'd
> >> prefer to fix existing API/specs.
> >>
> >> Adding sthg new simply creates another mess...no?
> >>
> >> - Romain
> >> Le 5 mai 2012 22:39, "Paul Dijou" <pa...@gmail.com> a
> >> écrit :
> >>
> >>> Hi,
> >>>
> >>> Big +1 for all suggestions from Mark.
> >>>
> >>> Also +1 for some util classes for common operations like CRUD and
> >>> pagination. Maybe inspiration from Seam Application Framework (Home,
> Query,
> >>> Controller) in Seam 2 [1] or from DataValve [2].
> >>>
> >>> Regards,
> >>>
> >>> Paul.
> >>>
> >>> [1]
> >>>
> http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.html
> >>>
> >>> [2] http://www.andygibson.net/blog/projects/datavalve/
> >>>
> >>> 2012/5/5 Romain Manni-Bucau <rm...@gmail.com>
> >>>
> >>>> Maybe using a datasource bean managed by cdi as a jpa datasource
> >> source
> >>> can
> >>>> be added to jpa or cdi (it is always a bit hard to decide which specs
> >>>> qhould contain a new feature ;))?
> >>>> Le 5 mai 2012 00:55, "Romain Manni-Bucau"
> >> <rm...@gmail.com> a
> >>>> écrit :
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> isn't the ConfigurableDataSource in JEE6?
> >> (datasourceconfiguration by
> >>>>> annotation or in the web.xml)?
> >>>>>
> >>>>> a really really big +1 for a pagination solution (typically a
> >> hades
> >>> light
> >>>>> is a must have!)
> >>>>>
> >>>>> - Romain
> >>>>>
> >>>>>
> >>>>> 2012/5/4 Gerhard Petracek <ge...@gmail.com>
> >>>>>
> >>>>>> hi @ all,
> >>>>>>
> >>>>>> @ a)
> >>>>>> +1
> >>>>>>
> >>>>>> @ b)
> >>>>>> +1 for the basic concepts, however, @Transactional and
> >>>> @TransactionScoped
> >>>>>> need to be refactored (i'm currently working on it).
> >>>>>>
> >>>>>> furthermore, we should discuss a thin query layer which
> >> supports e.g.
> >>>>>> pagination,... easily (we also need it for a security-jpa
> >> module).
> >>>>>>
> >>>>>> regards,
> >>>>>> gerhard
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 2012/5/4 Mark Struberg <st...@yahoo.de>
> >>>>>>
> >>>>>>> Hi!
> >>>>>>>
> >>>>>>> It's time to start the discussion about our
> >> deltaspike-jpa module I
> >>>>>> think
> >>>>>>> ;)
> >>>>>>>
> >>>>>>> a.) where
> >>>>>>> I suggest that we create a ee-modules project with
> >> submodules jsf,
> >>>> jpa,
> >>>>>>> etc
> >>>>>>>
> >>>>>>> b.) what
> >>>>>>> *) @Transactional
> >>>>>>> *) TransactionalInterceptor with
> >> SimplePersistenceStrategy,
> >>>>>>> JtaPersistenceStrategy
> >>>>>>> *) ConfigurableDataSource, evaluate if we can make use
> >> of a special
> >>>>>>> PersistenceUnitInfo for JPA2 providers, but would that
> >> work in EE
> >>>>>>> containers as well?
> >>>>>>>
> >>>>>>> Because I often get asked if we can add this: I think we
> >> do _not_
> >>> need
> >>>>>> to
> >>>>>>> cover the (imo) broken Exception handling stuff which
> >> spring
> >>>> introduced
> >>>>>> in
> >>>>>>> their transaction interceptor. An Exception is an
> >> Exception is an
> >>>>>>> Exception! Logical return values and Business results
> >> must get
> >>>>>> propagated
> >>>>>>> via standard java return values or content holder
> >> objects.
> >>>>>>>
> >>>>>>> Oki the details:
> >>>>>>>
> >>>>>>> 1.) @Transational
> >>>>>>>
> >>>>>>> I suggest that we temporarily implement the
> >> javax.transaction.*
> >>> stuff
> >>>> of
> >>>>>>> the _new_ Transaction Specification in DeltaSpike. We
> >> can take parts
> >>>>>> from
> >>>>>>> OpenEJB, some JBoss api stuff (as far as covered by the
> >> grants) and
> >>>>>> various
> >>>>>>> geronimo spec jars [1]
> >>>>>>> Once the spec is finished, we will move all the
> >> transaction-api.jar
> >>>>>> stuff
> >>>>>>> over to geronimo-specs [1]. Since this all is ALv2 it
> >> will be no
> >>>> problem
> >>>>>>> for JBoss folks to also just take the code and provide
> >> it in the
> >>>> JBossAS
> >>>>>>> project once we are finished.
> >>>>>>>
> >>>>>>> 2.) I like the way we implemented the
> >> TransactionalInterceptor in
> >>> CODI
> >>>>>>> [2]. Our interceptor basically does exactly ...
> >> *nothing* ;)
> >>>>>>> All the work is done via an @Dependent
> >> PersistenceStrategy which
> >>> gets
> >>>>>>> injected into the interceptor. @Dependent because then
> >> we don't get
> >>>> any
> >>>>>>> interceptor and it's really fast.
> >>>>>>> The BIG benefit of this little trick is that we are
> >> able to provide
> >>>> and
> >>>>>>> use DIFFERENT PersistenceStrategies! A user can use
> >> @Alternative,
> >>>>>>> @Specializes etc to define which PersistenceStrategy he
> >> likes to use
> >>>> in
> >>>>>> his
> >>>>>>> project.
> >>>>>>>
> >>>>>>> By default I'd like to provide the following
> >> PersistenceStrategies:
> >>>>>>> * SimplePersistenceStrategy: does just flush on all
> >> involved
> >>>>>>> EntityManagers and afterwards a commit. Not JTA
> >> transaction save,
> >>> but
> >>>>>> good
> >>>>>>> enough for most use cases
> >>>>>>> * JtaPersistenceStrategy: uses a JTA bound
> >> @UserTransaction to
> >>>> control
> >>>>>>> the EntitaManagers. This needs some exploration how we
> >> can do it.
> >>>> David
> >>>>>>> Blevins and Arne Limburg are pretty good into this
> >> stuff. I'm
> >>> dreaming
> >>>>>> of
> >>>>>>> kind of the features of EJB standard transations, but
> >> NOT just for
> >>> an
> >>>>>> EJB
> >>>>>>> invocation, but @RequestScoped! The first invocation
> >> starts the
> >>>>>>> UserTransaction, the @Disposes closes it. Just an idea
> >> ...
> >>>>>>>
> >>>>>>>
> >>>>>>> 3.) ConfigurableDataSource
> >>>>>>> You all know the dilemma: you cannot make a JNDI
> >> configuration in a
> >>>> way
> >>>>>>> that this stuff works with multiple EE servers since the
> >> locations
> >>>> where
> >>>>>>> you have your DataSource configured will pop up under
> >> different
> >>>>>> locations
> >>>>>>> in JNDI (based on which EE server/version you take).
> >> Otoh I don't
> >>> like
> >>>>>> to
> >>>>>>> hardcode my credentials to the persistence.xml neither.
> >>>>>>>
> >>>>>>> Thus we came up with the ConfigurableDataSource [3]which
> >> just moves
> >>>> this
> >>>>>>> information to a CDI bean where you can use
> >>>>>>> @Exclude(ifNotInProjectStage...), @Alternative,
> >> @Specializes and
> >>> even
> >>>>>>> programmatic lookup!. I call this 'typesafe
> >> configuration'...
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Oki, any other ideas?
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>> [1]
> >> http://repo1.maven.org/maven2/org/apache/geronimo/specs/
> >>>>>>>
> >>>>>>> [2]
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
> >>>>>>>
> >>>>>>> [3]
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Jason Porter <li...@gmail.com>.
Wasn't there another company, Software Mill?, which had some persistence stuff we liked during formation?
Sent from my iPhone
On May 5, 2012, at 16:14, Mark Struberg <st...@yahoo.de> wrote:
> Yes, we should first concentrate on the other 2 things. We can try to find an even better solution than the ConfigurableDataSource.
>
> But I fear the @DataSourceDefinition from EE6 is completely useless for most real world apps.
> The problem which I see with it that you can only have 1 of it per 'real' DataSource. Of course that would change if there would be a way to create the 'real' DataSource via CDI producers.
>
> But I have no idea yet how to hand over a CDI produced DataSource to a JPA.
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Romain Manni-Bucau <rm...@gmail.com>
>> To: deltaspike-dev@incubator.apache.org
>> Cc:
>> Sent: Saturday, May 5, 2012 11:29 PM
>> Subject: Re: [DISCUSS] deltaspike-jpa module features
>>
>> With my note on datasourcedefinition i wanted to avoid to add sthg new. I'd
>> prefer to fix existing API/specs.
>>
>> Adding sthg new simply creates another mess...no?
>>
>> - Romain
>> Le 5 mai 2012 22:39, "Paul Dijou" <pa...@gmail.com> a
>> écrit :
>>
>>> Hi,
>>>
>>> Big +1 for all suggestions from Mark.
>>>
>>> Also +1 for some util classes for common operations like CRUD and
>>> pagination. Maybe inspiration from Seam Application Framework (Home, Query,
>>> Controller) in Seam 2 [1] or from DataValve [2].
>>>
>>> Regards,
>>>
>>> Paul.
>>>
>>> [1]
>>> http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.html
>>>
>>> [2] http://www.andygibson.net/blog/projects/datavalve/
>>>
>>> 2012/5/5 Romain Manni-Bucau <rm...@gmail.com>
>>>
>>>> Maybe using a datasource bean managed by cdi as a jpa datasource
>> source
>>> can
>>>> be added to jpa or cdi (it is always a bit hard to decide which specs
>>>> qhould contain a new feature ;))?
>>>> Le 5 mai 2012 00:55, "Romain Manni-Bucau"
>> <rm...@gmail.com> a
>>>> écrit :
>>>>
>>>>> Hi,
>>>>>
>>>>> isn't the ConfigurableDataSource in JEE6?
>> (datasourceconfiguration by
>>>>> annotation or in the web.xml)?
>>>>>
>>>>> a really really big +1 for a pagination solution (typically a
>> hades
>>> light
>>>>> is a must have!)
>>>>>
>>>>> - Romain
>>>>>
>>>>>
>>>>> 2012/5/4 Gerhard Petracek <ge...@gmail.com>
>>>>>
>>>>>> hi @ all,
>>>>>>
>>>>>> @ a)
>>>>>> +1
>>>>>>
>>>>>> @ b)
>>>>>> +1 for the basic concepts, however, @Transactional and
>>>> @TransactionScoped
>>>>>> need to be refactored (i'm currently working on it).
>>>>>>
>>>>>> furthermore, we should discuss a thin query layer which
>> supports e.g.
>>>>>> pagination,... easily (we also need it for a security-jpa
>> module).
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/5/4 Mark Struberg <st...@yahoo.de>
>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> It's time to start the discussion about our
>> deltaspike-jpa module I
>>>>>> think
>>>>>>> ;)
>>>>>>>
>>>>>>> a.) where
>>>>>>> I suggest that we create a ee-modules project with
>> submodules jsf,
>>>> jpa,
>>>>>>> etc
>>>>>>>
>>>>>>> b.) what
>>>>>>> *) @Transactional
>>>>>>> *) TransactionalInterceptor with
>> SimplePersistenceStrategy,
>>>>>>> JtaPersistenceStrategy
>>>>>>> *) ConfigurableDataSource, evaluate if we can make use
>> of a special
>>>>>>> PersistenceUnitInfo for JPA2 providers, but would that
>> work in EE
>>>>>>> containers as well?
>>>>>>>
>>>>>>> Because I often get asked if we can add this: I think we
>> do _not_
>>> need
>>>>>> to
>>>>>>> cover the (imo) broken Exception handling stuff which
>> spring
>>>> introduced
>>>>>> in
>>>>>>> their transaction interceptor. An Exception is an
>> Exception is an
>>>>>>> Exception! Logical return values and Business results
>> must get
>>>>>> propagated
>>>>>>> via standard java return values or content holder
>> objects.
>>>>>>>
>>>>>>> Oki the details:
>>>>>>>
>>>>>>> 1.) @Transational
>>>>>>>
>>>>>>> I suggest that we temporarily implement the
>> javax.transaction.*
>>> stuff
>>>> of
>>>>>>> the _new_ Transaction Specification in DeltaSpike. We
>> can take parts
>>>>>> from
>>>>>>> OpenEJB, some JBoss api stuff (as far as covered by the
>> grants) and
>>>>>> various
>>>>>>> geronimo spec jars [1]
>>>>>>> Once the spec is finished, we will move all the
>> transaction-api.jar
>>>>>> stuff
>>>>>>> over to geronimo-specs [1]. Since this all is ALv2 it
>> will be no
>>>> problem
>>>>>>> for JBoss folks to also just take the code and provide
>> it in the
>>>> JBossAS
>>>>>>> project once we are finished.
>>>>>>>
>>>>>>> 2.) I like the way we implemented the
>> TransactionalInterceptor in
>>> CODI
>>>>>>> [2]. Our interceptor basically does exactly ...
>> *nothing* ;)
>>>>>>> All the work is done via an @Dependent
>> PersistenceStrategy which
>>> gets
>>>>>>> injected into the interceptor. @Dependent because then
>> we don't get
>>>> any
>>>>>>> interceptor and it's really fast.
>>>>>>> The BIG benefit of this little trick is that we are
>> able to provide
>>>> and
>>>>>>> use DIFFERENT PersistenceStrategies! A user can use
>> @Alternative,
>>>>>>> @Specializes etc to define which PersistenceStrategy he
>> likes to use
>>>> in
>>>>>> his
>>>>>>> project.
>>>>>>>
>>>>>>> By default I'd like to provide the following
>> PersistenceStrategies:
>>>>>>> * SimplePersistenceStrategy: does just flush on all
>> involved
>>>>>>> EntityManagers and afterwards a commit. Not JTA
>> transaction save,
>>> but
>>>>>> good
>>>>>>> enough for most use cases
>>>>>>> * JtaPersistenceStrategy: uses a JTA bound
>> @UserTransaction to
>>>> control
>>>>>>> the EntitaManagers. This needs some exploration how we
>> can do it.
>>>> David
>>>>>>> Blevins and Arne Limburg are pretty good into this
>> stuff. I'm
>>> dreaming
>>>>>> of
>>>>>>> kind of the features of EJB standard transations, but
>> NOT just for
>>> an
>>>>>> EJB
>>>>>>> invocation, but @RequestScoped! The first invocation
>> starts the
>>>>>>> UserTransaction, the @Disposes closes it. Just an idea
>> ...
>>>>>>>
>>>>>>>
>>>>>>> 3.) ConfigurableDataSource
>>>>>>> You all know the dilemma: you cannot make a JNDI
>> configuration in a
>>>> way
>>>>>>> that this stuff works with multiple EE servers since the
>> locations
>>>> where
>>>>>>> you have your DataSource configured will pop up under
>> different
>>>>>> locations
>>>>>>> in JNDI (based on which EE server/version you take).
>> Otoh I don't
>>> like
>>>>>> to
>>>>>>> hardcode my credentials to the persistence.xml neither.
>>>>>>>
>>>>>>> Thus we came up with the ConfigurableDataSource [3]which
>> just moves
>>>> this
>>>>>>> information to a CDI bean where you can use
>>>>>>> @Exclude(ifNotInProjectStage...), @Alternative,
>> @Specializes and
>>> even
>>>>>>> programmatic lookup!. I call this 'typesafe
>> configuration'...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Oki, any other ideas?
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>> [1]
>> http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>>>>>>>
>>>>>>> [2]
>>>>>>>
>>>>>>
>>>>
>>>
>> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
>>>>>>>
>>>>>>> [3]
>>>>>>>
>>>>>>
>>>>
>>>
>> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Mark Struberg <st...@yahoo.de>.
Yes, we should first concentrate on the other 2 things. We can try to find an even better solution than the ConfigurableDataSource.
But I fear the @DataSourceDefinition from EE6 is completely useless for most real world apps.
The problem which I see with it that you can only have 1 of it per 'real' DataSource. Of course that would change if there would be a way to create the 'real' DataSource via CDI producers.
But I have no idea yet how to hand over a CDI produced DataSource to a JPA.
LieGrue,
strub
----- Original Message -----
> From: Romain Manni-Bucau <rm...@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc:
> Sent: Saturday, May 5, 2012 11:29 PM
> Subject: Re: [DISCUSS] deltaspike-jpa module features
>
> With my note on datasourcedefinition i wanted to avoid to add sthg new. I'd
> prefer to fix existing API/specs.
>
> Adding sthg new simply creates another mess...no?
>
> - Romain
> Le 5 mai 2012 22:39, "Paul Dijou" <pa...@gmail.com> a
> écrit :
>
>> Hi,
>>
>> Big +1 for all suggestions from Mark.
>>
>> Also +1 for some util classes for common operations like CRUD and
>> pagination. Maybe inspiration from Seam Application Framework (Home, Query,
>> Controller) in Seam 2 [1] or from DataValve [2].
>>
>> Regards,
>>
>> Paul.
>>
>> [1]
>> http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.html
>>
>> [2] http://www.andygibson.net/blog/projects/datavalve/
>>
>> 2012/5/5 Romain Manni-Bucau <rm...@gmail.com>
>>
>> > Maybe using a datasource bean managed by cdi as a jpa datasource
> source
>> can
>> > be added to jpa or cdi (it is always a bit hard to decide which specs
>> > qhould contain a new feature ;))?
>> > Le 5 mai 2012 00:55, "Romain Manni-Bucau"
> <rm...@gmail.com> a
>> > écrit :
>> >
>> > > Hi,
>> > >
>> > > isn't the ConfigurableDataSource in JEE6?
> (datasourceconfiguration by
>> > > annotation or in the web.xml)?
>> > >
>> > > a really really big +1 for a pagination solution (typically a
> hades
>> light
>> > > is a must have!)
>> > >
>> > > - Romain
>> > >
>> > >
>> > > 2012/5/4 Gerhard Petracek <ge...@gmail.com>
>> > >
>> > >> hi @ all,
>> > >>
>> > >> @ a)
>> > >> +1
>> > >>
>> > >> @ b)
>> > >> +1 for the basic concepts, however, @Transactional and
>> > @TransactionScoped
>> > >> need to be refactored (i'm currently working on it).
>> > >>
>> > >> furthermore, we should discuss a thin query layer which
> supports e.g.
>> > >> pagination,... easily (we also need it for a security-jpa
> module).
>> > >>
>> > >> regards,
>> > >> gerhard
>> > >>
>> > >>
>> > >>
>> > >> 2012/5/4 Mark Struberg <st...@yahoo.de>
>> > >>
>> > >> > Hi!
>> > >> >
>> > >> > It's time to start the discussion about our
> deltaspike-jpa module I
>> > >> think
>> > >> > ;)
>> > >> >
>> > >> > a.) where
>> > >> > I suggest that we create a ee-modules project with
> submodules jsf,
>> > jpa,
>> > >> > etc
>> > >> >
>> > >> > b.) what
>> > >> > *) @Transactional
>> > >> > *) TransactionalInterceptor with
> SimplePersistenceStrategy,
>> > >> > JtaPersistenceStrategy
>> > >> > *) ConfigurableDataSource, evaluate if we can make use
> of a special
>> > >> > PersistenceUnitInfo for JPA2 providers, but would that
> work in EE
>> > >> > containers as well?
>> > >> >
>> > >> > Because I often get asked if we can add this: I think we
> do _not_
>> need
>> > >> to
>> > >> > cover the (imo) broken Exception handling stuff which
> spring
>> > introduced
>> > >> in
>> > >> > their transaction interceptor. An Exception is an
> Exception is an
>> > >> > Exception! Logical return values and Business results
> must get
>> > >> propagated
>> > >> > via standard java return values or content holder
> objects.
>> > >> >
>> > >> > Oki the details:
>> > >> >
>> > >> > 1.) @Transational
>> > >> >
>> > >> > I suggest that we temporarily implement the
> javax.transaction.*
>> stuff
>> > of
>> > >> > the _new_ Transaction Specification in DeltaSpike. We
> can take parts
>> > >> from
>> > >> > OpenEJB, some JBoss api stuff (as far as covered by the
> grants) and
>> > >> various
>> > >> > geronimo spec jars [1]
>> > >> > Once the spec is finished, we will move all the
> transaction-api.jar
>> > >> stuff
>> > >> > over to geronimo-specs [1]. Since this all is ALv2 it
> will be no
>> > problem
>> > >> > for JBoss folks to also just take the code and provide
> it in the
>> > JBossAS
>> > >> > project once we are finished.
>> > >> >
>> > >> > 2.) I like the way we implemented the
> TransactionalInterceptor in
>> CODI
>> > >> > [2]. Our interceptor basically does exactly ...
> *nothing* ;)
>> > >> > All the work is done via an @Dependent
> PersistenceStrategy which
>> gets
>> > >> > injected into the interceptor. @Dependent because then
> we don't get
>> > any
>> > >> > interceptor and it's really fast.
>> > >> > The BIG benefit of this little trick is that we are
> able to provide
>> > and
>> > >> > use DIFFERENT PersistenceStrategies! A user can use
> @Alternative,
>> > >> > @Specializes etc to define which PersistenceStrategy he
> likes to use
>> > in
>> > >> his
>> > >> > project.
>> > >> >
>> > >> > By default I'd like to provide the following
> PersistenceStrategies:
>> > >> > * SimplePersistenceStrategy: does just flush on all
> involved
>> > >> > EntityManagers and afterwards a commit. Not JTA
> transaction save,
>> but
>> > >> good
>> > >> > enough for most use cases
>> > >> > * JtaPersistenceStrategy: uses a JTA bound
> @UserTransaction to
>> > control
>> > >> > the EntitaManagers. This needs some exploration how we
> can do it.
>> > David
>> > >> > Blevins and Arne Limburg are pretty good into this
> stuff. I'm
>> dreaming
>> > >> of
>> > >> > kind of the features of EJB standard transations, but
> NOT just for
>> an
>> > >> EJB
>> > >> > invocation, but @RequestScoped! The first invocation
> starts the
>> > >> > UserTransaction, the @Disposes closes it. Just an idea
> ...
>> > >> >
>> > >> >
>> > >> > 3.) ConfigurableDataSource
>> > >> > You all know the dilemma: you cannot make a JNDI
> configuration in a
>> > way
>> > >> > that this stuff works with multiple EE servers since the
> locations
>> > where
>> > >> > you have your DataSource configured will pop up under
> different
>> > >> locations
>> > >> > in JNDI (based on which EE server/version you take).
> Otoh I don't
>> like
>> > >> to
>> > >> > hardcode my credentials to the persistence.xml neither.
>> > >> >
>> > >> > Thus we came up with the ConfigurableDataSource [3]which
> just moves
>> > this
>> > >> > information to a CDI bean where you can use
>> > >> > @Exclude(ifNotInProjectStage...), @Alternative,
> @Specializes and
>> even
>> > >> > programmatic lookup!. I call this 'typesafe
> configuration'...
>> > >> >
>> > >> >
>> > >> >
>> > >> > Oki, any other ideas?
>> > >> >
>> > >> > LieGrue,
>> > >> > strub
>> > >> >
>> > >> >
>> > >> > [1]
> http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>> > >> >
>> > >> > [2]
>> > >> >
>> > >>
>> >
>>
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
>> > >> >
>> > >> > [3]
>> > >> >
>> > >>
>> >
>>
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
With my note on datasourcedefinition i wanted to avoid to add sthg new. I'd
prefer to fix existing API/specs.
Adding sthg new simply creates another mess...no?
- Romain
Le 5 mai 2012 22:39, "Paul Dijou" <pa...@gmail.com> a écrit :
> Hi,
>
> Big +1 for all suggestions from Mark.
>
> Also +1 for some util classes for common operations like CRUD and
> pagination. Maybe inspiration from Seam Application Framework (Home, Query,
> Controller) in Seam 2 [1] or from DataValve [2].
>
> Regards,
>
> Paul.
>
> [1]
> http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.html
>
> [2] http://www.andygibson.net/blog/projects/datavalve/
>
> 2012/5/5 Romain Manni-Bucau <rm...@gmail.com>
>
> > Maybe using a datasource bean managed by cdi as a jpa datasource source
> can
> > be added to jpa or cdi (it is always a bit hard to decide which specs
> > qhould contain a new feature ;))?
> > Le 5 mai 2012 00:55, "Romain Manni-Bucau" <rm...@gmail.com> a
> > écrit :
> >
> > > Hi,
> > >
> > > isn't the ConfigurableDataSource in JEE6? (datasourceconfiguration by
> > > annotation or in the web.xml)?
> > >
> > > a really really big +1 for a pagination solution (typically a hades
> light
> > > is a must have!)
> > >
> > > - Romain
> > >
> > >
> > > 2012/5/4 Gerhard Petracek <ge...@gmail.com>
> > >
> > >> hi @ all,
> > >>
> > >> @ a)
> > >> +1
> > >>
> > >> @ b)
> > >> +1 for the basic concepts, however, @Transactional and
> > @TransactionScoped
> > >> need to be refactored (i'm currently working on it).
> > >>
> > >> furthermore, we should discuss a thin query layer which supports e.g.
> > >> pagination,... easily (we also need it for a security-jpa module).
> > >>
> > >> regards,
> > >> gerhard
> > >>
> > >>
> > >>
> > >> 2012/5/4 Mark Struberg <st...@yahoo.de>
> > >>
> > >> > Hi!
> > >> >
> > >> > It's time to start the discussion about our deltaspike-jpa module I
> > >> think
> > >> > ;)
> > >> >
> > >> > a.) where
> > >> > I suggest that we create a ee-modules project with submodules jsf,
> > jpa,
> > >> > etc
> > >> >
> > >> > b.) what
> > >> > *) @Transactional
> > >> > *) TransactionalInterceptor with SimplePersistenceStrategy,
> > >> > JtaPersistenceStrategy
> > >> > *) ConfigurableDataSource, evaluate if we can make use of a special
> > >> > PersistenceUnitInfo for JPA2 providers, but would that work in EE
> > >> > containers as well?
> > >> >
> > >> > Because I often get asked if we can add this: I think we do _not_
> need
> > >> to
> > >> > cover the (imo) broken Exception handling stuff which spring
> > introduced
> > >> in
> > >> > their transaction interceptor. An Exception is an Exception is an
> > >> > Exception! Logical return values and Business results must get
> > >> propagated
> > >> > via standard java return values or content holder objects.
> > >> >
> > >> > Oki the details:
> > >> >
> > >> > 1.) @Transational
> > >> >
> > >> > I suggest that we temporarily implement the javax.transaction.*
> stuff
> > of
> > >> > the _new_ Transaction Specification in DeltaSpike. We can take parts
> > >> from
> > >> > OpenEJB, some JBoss api stuff (as far as covered by the grants) and
> > >> various
> > >> > geronimo spec jars [1]
> > >> > Once the spec is finished, we will move all the transaction-api.jar
> > >> stuff
> > >> > over to geronimo-specs [1]. Since this all is ALv2 it will be no
> > problem
> > >> > for JBoss folks to also just take the code and provide it in the
> > JBossAS
> > >> > project once we are finished.
> > >> >
> > >> > 2.) I like the way we implemented the TransactionalInterceptor in
> CODI
> > >> > [2]. Our interceptor basically does exactly ... *nothing* ;)
> > >> > All the work is done via an @Dependent PersistenceStrategy which
> gets
> > >> > injected into the interceptor. @Dependent because then we don't get
> > any
> > >> > interceptor and it's really fast.
> > >> > The BIG benefit of this little trick is that we are able to provide
> > and
> > >> > use DIFFERENT PersistenceStrategies! A user can use @Alternative,
> > >> > @Specializes etc to define which PersistenceStrategy he likes to use
> > in
> > >> his
> > >> > project.
> > >> >
> > >> > By default I'd like to provide the following PersistenceStrategies:
> > >> > * SimplePersistenceStrategy: does just flush on all involved
> > >> > EntityManagers and afterwards a commit. Not JTA transaction save,
> but
> > >> good
> > >> > enough for most use cases
> > >> > * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to
> > control
> > >> > the EntitaManagers. This needs some exploration how we can do it.
> > David
> > >> > Blevins and Arne Limburg are pretty good into this stuff. I'm
> dreaming
> > >> of
> > >> > kind of the features of EJB standard transations, but NOT just for
> an
> > >> EJB
> > >> > invocation, but @RequestScoped! The first invocation starts the
> > >> > UserTransaction, the @Disposes closes it. Just an idea ...
> > >> >
> > >> >
> > >> > 3.) ConfigurableDataSource
> > >> > You all know the dilemma: you cannot make a JNDI configuration in a
> > way
> > >> > that this stuff works with multiple EE servers since the locations
> > where
> > >> > you have your DataSource configured will pop up under different
> > >> locations
> > >> > in JNDI (based on which EE server/version you take). Otoh I don't
> like
> > >> to
> > >> > hardcode my credentials to the persistence.xml neither.
> > >> >
> > >> > Thus we came up with the ConfigurableDataSource [3]which just moves
> > this
> > >> > information to a CDI bean where you can use
> > >> > @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and
> even
> > >> > programmatic lookup!. I call this 'typesafe configuration'...
> > >> >
> > >> >
> > >> >
> > >> > Oki, any other ideas?
> > >> >
> > >> > LieGrue,
> > >> > strub
> > >> >
> > >> >
> > >> > [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
> > >> >
> > >> > [2]
> > >> >
> > >>
> >
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
> > >> >
> > >> > [3]
> > >> >
> > >>
> >
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
> > >> >
> > >>
> > >
> > >
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Paul Dijou <pa...@gmail.com>.
Hi,
Big +1 for all suggestions from Mark.
Also +1 for some util classes for common operations like CRUD and
pagination. Maybe inspiration from Seam Application Framework (Home, Query,
Controller) in Seam 2 [1] or from DataValve [2].
Regards,
Paul.
[1]
http://docs.jboss.org/seam/2.2.2.Final/reference/en-US/html/framework.html
[2] http://www.andygibson.net/blog/projects/datavalve/
2012/5/5 Romain Manni-Bucau <rm...@gmail.com>
> Maybe using a datasource bean managed by cdi as a jpa datasource source can
> be added to jpa or cdi (it is always a bit hard to decide which specs
> qhould contain a new feature ;))?
> Le 5 mai 2012 00:55, "Romain Manni-Bucau" <rm...@gmail.com> a
> écrit :
>
> > Hi,
> >
> > isn't the ConfigurableDataSource in JEE6? (datasourceconfiguration by
> > annotation or in the web.xml)?
> >
> > a really really big +1 for a pagination solution (typically a hades light
> > is a must have!)
> >
> > - Romain
> >
> >
> > 2012/5/4 Gerhard Petracek <ge...@gmail.com>
> >
> >> hi @ all,
> >>
> >> @ a)
> >> +1
> >>
> >> @ b)
> >> +1 for the basic concepts, however, @Transactional and
> @TransactionScoped
> >> need to be refactored (i'm currently working on it).
> >>
> >> furthermore, we should discuss a thin query layer which supports e.g.
> >> pagination,... easily (we also need it for a security-jpa module).
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2012/5/4 Mark Struberg <st...@yahoo.de>
> >>
> >> > Hi!
> >> >
> >> > It's time to start the discussion about our deltaspike-jpa module I
> >> think
> >> > ;)
> >> >
> >> > a.) where
> >> > I suggest that we create a ee-modules project with submodules jsf,
> jpa,
> >> > etc
> >> >
> >> > b.) what
> >> > *) @Transactional
> >> > *) TransactionalInterceptor with SimplePersistenceStrategy,
> >> > JtaPersistenceStrategy
> >> > *) ConfigurableDataSource, evaluate if we can make use of a special
> >> > PersistenceUnitInfo for JPA2 providers, but would that work in EE
> >> > containers as well?
> >> >
> >> > Because I often get asked if we can add this: I think we do _not_ need
> >> to
> >> > cover the (imo) broken Exception handling stuff which spring
> introduced
> >> in
> >> > their transaction interceptor. An Exception is an Exception is an
> >> > Exception! Logical return values and Business results must get
> >> propagated
> >> > via standard java return values or content holder objects.
> >> >
> >> > Oki the details:
> >> >
> >> > 1.) @Transational
> >> >
> >> > I suggest that we temporarily implement the javax.transaction.* stuff
> of
> >> > the _new_ Transaction Specification in DeltaSpike. We can take parts
> >> from
> >> > OpenEJB, some JBoss api stuff (as far as covered by the grants) and
> >> various
> >> > geronimo spec jars [1]
> >> > Once the spec is finished, we will move all the transaction-api.jar
> >> stuff
> >> > over to geronimo-specs [1]. Since this all is ALv2 it will be no
> problem
> >> > for JBoss folks to also just take the code and provide it in the
> JBossAS
> >> > project once we are finished.
> >> >
> >> > 2.) I like the way we implemented the TransactionalInterceptor in CODI
> >> > [2]. Our interceptor basically does exactly ... *nothing* ;)
> >> > All the work is done via an @Dependent PersistenceStrategy which gets
> >> > injected into the interceptor. @Dependent because then we don't get
> any
> >> > interceptor and it's really fast.
> >> > The BIG benefit of this little trick is that we are able to provide
> and
> >> > use DIFFERENT PersistenceStrategies! A user can use @Alternative,
> >> > @Specializes etc to define which PersistenceStrategy he likes to use
> in
> >> his
> >> > project.
> >> >
> >> > By default I'd like to provide the following PersistenceStrategies:
> >> > * SimplePersistenceStrategy: does just flush on all involved
> >> > EntityManagers and afterwards a commit. Not JTA transaction save, but
> >> good
> >> > enough for most use cases
> >> > * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to
> control
> >> > the EntitaManagers. This needs some exploration how we can do it.
> David
> >> > Blevins and Arne Limburg are pretty good into this stuff. I'm dreaming
> >> of
> >> > kind of the features of EJB standard transations, but NOT just for an
> >> EJB
> >> > invocation, but @RequestScoped! The first invocation starts the
> >> > UserTransaction, the @Disposes closes it. Just an idea ...
> >> >
> >> >
> >> > 3.) ConfigurableDataSource
> >> > You all know the dilemma: you cannot make a JNDI configuration in a
> way
> >> > that this stuff works with multiple EE servers since the locations
> where
> >> > you have your DataSource configured will pop up under different
> >> locations
> >> > in JNDI (based on which EE server/version you take). Otoh I don't like
> >> to
> >> > hardcode my credentials to the persistence.xml neither.
> >> >
> >> > Thus we came up with the ConfigurableDataSource [3]which just moves
> this
> >> > information to a CDI bean where you can use
> >> > @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even
> >> > programmatic lookup!. I call this 'typesafe configuration'...
> >> >
> >> >
> >> >
> >> > Oki, any other ideas?
> >> >
> >> > LieGrue,
> >> > strub
> >> >
> >> >
> >> > [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
> >> >
> >> > [2]
> >> >
> >>
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
> >> >
> >> > [3]
> >> >
> >>
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
> >> >
> >>
> >
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Maybe using a datasource bean managed by cdi as a jpa datasource source can
be added to jpa or cdi (it is always a bit hard to decide which specs
qhould contain a new feature ;))?
Le 5 mai 2012 00:55, "Romain Manni-Bucau" <rm...@gmail.com> a écrit :
> Hi,
>
> isn't the ConfigurableDataSource in JEE6? (datasourceconfiguration by
> annotation or in the web.xml)?
>
> a really really big +1 for a pagination solution (typically a hades light
> is a must have!)
>
> - Romain
>
>
> 2012/5/4 Gerhard Petracek <ge...@gmail.com>
>
>> hi @ all,
>>
>> @ a)
>> +1
>>
>> @ b)
>> +1 for the basic concepts, however, @Transactional and @TransactionScoped
>> need to be refactored (i'm currently working on it).
>>
>> furthermore, we should discuss a thin query layer which supports e.g.
>> pagination,... easily (we also need it for a security-jpa module).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2012/5/4 Mark Struberg <st...@yahoo.de>
>>
>> > Hi!
>> >
>> > It's time to start the discussion about our deltaspike-jpa module I
>> think
>> > ;)
>> >
>> > a.) where
>> > I suggest that we create a ee-modules project with submodules jsf, jpa,
>> > etc
>> >
>> > b.) what
>> > *) @Transactional
>> > *) TransactionalInterceptor with SimplePersistenceStrategy,
>> > JtaPersistenceStrategy
>> > *) ConfigurableDataSource, evaluate if we can make use of a special
>> > PersistenceUnitInfo for JPA2 providers, but would that work in EE
>> > containers as well?
>> >
>> > Because I often get asked if we can add this: I think we do _not_ need
>> to
>> > cover the (imo) broken Exception handling stuff which spring introduced
>> in
>> > their transaction interceptor. An Exception is an Exception is an
>> > Exception! Logical return values and Business results must get
>> propagated
>> > via standard java return values or content holder objects.
>> >
>> > Oki the details:
>> >
>> > 1.) @Transational
>> >
>> > I suggest that we temporarily implement the javax.transaction.* stuff of
>> > the _new_ Transaction Specification in DeltaSpike. We can take parts
>> from
>> > OpenEJB, some JBoss api stuff (as far as covered by the grants) and
>> various
>> > geronimo spec jars [1]
>> > Once the spec is finished, we will move all the transaction-api.jar
>> stuff
>> > over to geronimo-specs [1]. Since this all is ALv2 it will be no problem
>> > for JBoss folks to also just take the code and provide it in the JBossAS
>> > project once we are finished.
>> >
>> > 2.) I like the way we implemented the TransactionalInterceptor in CODI
>> > [2]. Our interceptor basically does exactly ... *nothing* ;)
>> > All the work is done via an @Dependent PersistenceStrategy which gets
>> > injected into the interceptor. @Dependent because then we don't get any
>> > interceptor and it's really fast.
>> > The BIG benefit of this little trick is that we are able to provide and
>> > use DIFFERENT PersistenceStrategies! A user can use @Alternative,
>> > @Specializes etc to define which PersistenceStrategy he likes to use in
>> his
>> > project.
>> >
>> > By default I'd like to provide the following PersistenceStrategies:
>> > * SimplePersistenceStrategy: does just flush on all involved
>> > EntityManagers and afterwards a commit. Not JTA transaction save, but
>> good
>> > enough for most use cases
>> > * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to control
>> > the EntitaManagers. This needs some exploration how we can do it. David
>> > Blevins and Arne Limburg are pretty good into this stuff. I'm dreaming
>> of
>> > kind of the features of EJB standard transations, but NOT just for an
>> EJB
>> > invocation, but @RequestScoped! The first invocation starts the
>> > UserTransaction, the @Disposes closes it. Just an idea ...
>> >
>> >
>> > 3.) ConfigurableDataSource
>> > You all know the dilemma: you cannot make a JNDI configuration in a way
>> > that this stuff works with multiple EE servers since the locations where
>> > you have your DataSource configured will pop up under different
>> locations
>> > in JNDI (based on which EE server/version you take). Otoh I don't like
>> to
>> > hardcode my credentials to the persistence.xml neither.
>> >
>> > Thus we came up with the ConfigurableDataSource [3]which just moves this
>> > information to a CDI bean where you can use
>> > @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even
>> > programmatic lookup!. I call this 'typesafe configuration'...
>> >
>> >
>> >
>> > Oki, any other ideas?
>> >
>> > LieGrue,
>> > strub
>> >
>> >
>> > [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>> >
>> > [2]
>> >
>> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
>> >
>> > [3]
>> >
>> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
>> >
>>
>
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
isn't the ConfigurableDataSource in JEE6? (datasourceconfiguration by
annotation or in the web.xml)?
a really really big +1 for a pagination solution (typically a hades light
is a must have!)
- Romain
2012/5/4 Gerhard Petracek <ge...@gmail.com>
> hi @ all,
>
> @ a)
> +1
>
> @ b)
> +1 for the basic concepts, however, @Transactional and @TransactionScoped
> need to be refactored (i'm currently working on it).
>
> furthermore, we should discuss a thin query layer which supports e.g.
> pagination,... easily (we also need it for a security-jpa module).
>
> regards,
> gerhard
>
>
>
> 2012/5/4 Mark Struberg <st...@yahoo.de>
>
> > Hi!
> >
> > It's time to start the discussion about our deltaspike-jpa module I think
> > ;)
> >
> > a.) where
> > I suggest that we create a ee-modules project with submodules jsf, jpa,
> > etc
> >
> > b.) what
> > *) @Transactional
> > *) TransactionalInterceptor with SimplePersistenceStrategy,
> > JtaPersistenceStrategy
> > *) ConfigurableDataSource, evaluate if we can make use of a special
> > PersistenceUnitInfo for JPA2 providers, but would that work in EE
> > containers as well?
> >
> > Because I often get asked if we can add this: I think we do _not_ need to
> > cover the (imo) broken Exception handling stuff which spring introduced
> in
> > their transaction interceptor. An Exception is an Exception is an
> > Exception! Logical return values and Business results must get propagated
> > via standard java return values or content holder objects.
> >
> > Oki the details:
> >
> > 1.) @Transational
> >
> > I suggest that we temporarily implement the javax.transaction.* stuff of
> > the _new_ Transaction Specification in DeltaSpike. We can take parts from
> > OpenEJB, some JBoss api stuff (as far as covered by the grants) and
> various
> > geronimo spec jars [1]
> > Once the spec is finished, we will move all the transaction-api.jar stuff
> > over to geronimo-specs [1]. Since this all is ALv2 it will be no problem
> > for JBoss folks to also just take the code and provide it in the JBossAS
> > project once we are finished.
> >
> > 2.) I like the way we implemented the TransactionalInterceptor in CODI
> > [2]. Our interceptor basically does exactly ... *nothing* ;)
> > All the work is done via an @Dependent PersistenceStrategy which gets
> > injected into the interceptor. @Dependent because then we don't get any
> > interceptor and it's really fast.
> > The BIG benefit of this little trick is that we are able to provide and
> > use DIFFERENT PersistenceStrategies! A user can use @Alternative,
> > @Specializes etc to define which PersistenceStrategy he likes to use in
> his
> > project.
> >
> > By default I'd like to provide the following PersistenceStrategies:
> > * SimplePersistenceStrategy: does just flush on all involved
> > EntityManagers and afterwards a commit. Not JTA transaction save, but
> good
> > enough for most use cases
> > * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to control
> > the EntitaManagers. This needs some exploration how we can do it. David
> > Blevins and Arne Limburg are pretty good into this stuff. I'm dreaming of
> > kind of the features of EJB standard transations, but NOT just for an EJB
> > invocation, but @RequestScoped! The first invocation starts the
> > UserTransaction, the @Disposes closes it. Just an idea ...
> >
> >
> > 3.) ConfigurableDataSource
> > You all know the dilemma: you cannot make a JNDI configuration in a way
> > that this stuff works with multiple EE servers since the locations where
> > you have your DataSource configured will pop up under different locations
> > in JNDI (based on which EE server/version you take). Otoh I don't like to
> > hardcode my credentials to the persistence.xml neither.
> >
> > Thus we came up with the ConfigurableDataSource [3]which just moves this
> > information to a CDI bean where you can use
> > @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even
> > programmatic lookup!. I call this 'typesafe configuration'...
> >
> >
> >
> > Oki, any other ideas?
> >
> > LieGrue,
> > strub
> >
> >
> > [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
> >
> > [2]
> >
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
> >
> > [3]
> >
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Gerhard Petracek <ge...@gmail.com>.
hi @ all,
@ a)
+1
@ b)
+1 for the basic concepts, however, @Transactional and @TransactionScoped
need to be refactored (i'm currently working on it).
furthermore, we should discuss a thin query layer which supports e.g.
pagination,... easily (we also need it for a security-jpa module).
regards,
gerhard
2012/5/4 Mark Struberg <st...@yahoo.de>
> Hi!
>
> It's time to start the discussion about our deltaspike-jpa module I think
> ;)
>
> a.) where
> I suggest that we create a ee-modules project with submodules jsf, jpa,
> etc
>
> b.) what
> *) @Transactional
> *) TransactionalInterceptor with SimplePersistenceStrategy,
> JtaPersistenceStrategy
> *) ConfigurableDataSource, evaluate if we can make use of a special
> PersistenceUnitInfo for JPA2 providers, but would that work in EE
> containers as well?
>
> Because I often get asked if we can add this: I think we do _not_ need to
> cover the (imo) broken Exception handling stuff which spring introduced in
> their transaction interceptor. An Exception is an Exception is an
> Exception! Logical return values and Business results must get propagated
> via standard java return values or content holder objects.
>
> Oki the details:
>
> 1.) @Transational
>
> I suggest that we temporarily implement the javax.transaction.* stuff of
> the _new_ Transaction Specification in DeltaSpike. We can take parts from
> OpenEJB, some JBoss api stuff (as far as covered by the grants) and various
> geronimo spec jars [1]
> Once the spec is finished, we will move all the transaction-api.jar stuff
> over to geronimo-specs [1]. Since this all is ALv2 it will be no problem
> for JBoss folks to also just take the code and provide it in the JBossAS
> project once we are finished.
>
> 2.) I like the way we implemented the TransactionalInterceptor in CODI
> [2]. Our interceptor basically does exactly ... *nothing* ;)
> All the work is done via an @Dependent PersistenceStrategy which gets
> injected into the interceptor. @Dependent because then we don't get any
> interceptor and it's really fast.
> The BIG benefit of this little trick is that we are able to provide and
> use DIFFERENT PersistenceStrategies! A user can use @Alternative,
> @Specializes etc to define which PersistenceStrategy he likes to use in his
> project.
>
> By default I'd like to provide the following PersistenceStrategies:
> * SimplePersistenceStrategy: does just flush on all involved
> EntityManagers and afterwards a commit. Not JTA transaction save, but good
> enough for most use cases
> * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to control
> the EntitaManagers. This needs some exploration how we can do it. David
> Blevins and Arne Limburg are pretty good into this stuff. I'm dreaming of
> kind of the features of EJB standard transations, but NOT just for an EJB
> invocation, but @RequestScoped! The first invocation starts the
> UserTransaction, the @Disposes closes it. Just an idea ...
>
>
> 3.) ConfigurableDataSource
> You all know the dilemma: you cannot make a JNDI configuration in a way
> that this stuff works with multiple EE servers since the locations where
> you have your DataSource configured will pop up under different locations
> in JNDI (based on which EE server/version you take). Otoh I don't like to
> hardcode my credentials to the persistence.xml neither.
>
> Thus we came up with the ConfigurableDataSource [3]which just moves this
> information to a CDI bean where you can use
> @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even
> programmatic lookup!. I call this 'typesafe configuration'...
>
>
>
> Oki, any other ideas?
>
> LieGrue,
> strub
>
>
> [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>
> [2]
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
>
> [3]
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Gerhard Petracek <ge...@gmail.com>.
hi @ all,
i've committed [1] a refactored version of @Transactional as well as
@TransactionScoped (for @Transactional).
i'll add some details to the documentation soon (we can't copy it, because
the new behaviour is a bit different (easier)).
furthermore, i've committed several tests (which represent different
constellations).
regards,
gerhard
[1] http://s.apache.org/wte
[2] https://issues.apache.org/jira/browse/DELTASPIKE-178
2012/5/8 Cody Lerum <co...@gmail.com>
> +1 for deferring the CRUD work until a later release. Let's get the
> basics right and out in the wild first.
>
> On Tue, May 8, 2012 at 5:58 AM, Pete Muir <pm...@redhat.com> wrote:
> > Following up on all emails sent so far on this thread:
> >
> > * I like Mark's priorities - @Transactional is definitely the item most
> requested
> > * I like the design of plugging in different persistence strategies
> > * Agreed that the standardised stuff for configuring datasources is a
> mess, we don't recommend it for use in JBoss, as we don't want to compile
> in this info. Instead we use a xml descriptor you can deploy, or a managed
> datasource configured via the management apis (scripted, HTTP, admin
> console etc.)
> > * The big issue we have with the Java EE programmatic data source
> definition stuff, is that this normally isn't "part of your app" but
> something you want to provide externally and reference via JNDI. It would
> have good if we had specified XML as well as annotations for this. I think
> this is coming in Java EE 7, and then will resolve a lot of this problem,
> for me. We might also want to make the configuration a bit simpler.
> > * Hopefully Stuart can provide some time on the transactions stuff
> > * I think that the CRUD stuff is good for a later phase, getting the
> basic stuff right first is better
> > * Agreed with Mark/Arne, there is no good way with the
> @DataSourceDefinition stuff to configure based on "project stage", and this
> is the critical problem, not the one about how to configure datasource
> across containers
> >
> > Answering David's questions
> >
> >> Q1. Alternatives and JavaEE Resource annotations. What happens if a
> CDI bean is annotated with "@Resource(name = "java:app/ds",
> lookup="java:app/prod/ds")", but has an alternate annotated with
> "@Resource(name = "java:app/ds", lookup="java:app/test/ds")?
> >>
> >> One would hope that either the main bean's JNDI entries *or* the
> alternate bean's JNDI entries will go into effect, not both. This isn't
> explicitly covered so I doubt will work. Something we might want to add at
> the spec level.
> >
> > It's not specified, and I don't think it works anywhere. We have raised
> this for Java EE 7, but received push back due to it coupling CDI too
> tightly into the Java EE core, which, as CDI isn't always on, is something
> the Java EE EG/spec leads want to avoid.
> >
> >>
> >> Q2. Extensions adding/removing beans. What happens if a CDI bean is
> annotated with "@Resource(name = "java:app/ds", lookup="java:app/prod/ds")"
> and is vetoed by an Extension?
> >>
> >> One would hope that the JNDI entries that would be added by the vetoed
> bean are also essentially vetoed and the bean does not have an impact on
> the JNDI namespace. Also not explicitly addressed and something we might
> want to tackle at the spec level.
> >
> > As above :-)
> >
> >
> > On 4 May 2012, at 20:56, Mark Struberg wrote:
> >
> >> Hi!
> >>
> >> It's time to start the discussion about our deltaspike-jpa module I
> think ;)
> >>
> >> a.) where
> >> I suggest that we create a ee-modules project with submodules jsf,
> jpa, etc
> >>
> >> b.) what
> >> *) @Transactional
> >> *) TransactionalInterceptor with SimplePersistenceStrategy,
> JtaPersistenceStrategy
> >> *) ConfigurableDataSource, evaluate if we can make use of a special
> PersistenceUnitInfo for JPA2 providers, but would that work in EE
> containers as well?
> >>
> >> Because I often get asked if we can add this: I think we do _not_ need
> to cover the (imo) broken Exception handling stuff which spring introduced
> in their transaction interceptor. An Exception is an Exception is an
> Exception! Logical return values and Business results must get propagated
> via standard java return values or content holder objects.
> >>
> >> Oki the details:
> >>
> >> 1.) @Transational
> >>
> >> I suggest that we temporarily implement the javax.transaction.* stuff
> of the _new_ Transaction Specification in DeltaSpike. We can take parts
> from OpenEJB, some JBoss api stuff (as far as covered by the grants) and
> various geronimo spec jars [1]
> >> Once the spec is finished, we will move all the transaction-api.jar
> stuff over to geronimo-specs [1]. Since this all is ALv2 it will be no
> problem for JBoss folks to also just take the code and provide it in the
> JBossAS project once we are finished.
> >>
> >> 2.) I like the way we implemented the TransactionalInterceptor in CODI
> [2]. Our interceptor basically does exactly ... *nothing* ;)
> >> All the work is done via an @Dependent PersistenceStrategy which gets
> injected into the interceptor. @Dependent because then we don't get any
> interceptor and it's really fast.
> >> The BIG benefit of this little trick is that we are able to provide
> and use DIFFERENT PersistenceStrategies! A user can use @Alternative,
> @Specializes etc to define which PersistenceStrategy he likes to use in his
> project.
> >>
> >> By default I'd like to provide the following PersistenceStrategies:
> >> * SimplePersistenceStrategy: does just flush on all involved
> EntityManagers and afterwards a commit. Not JTA transaction save, but good
> enough for most use cases
> >> * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to control
> the EntitaManagers. This needs some exploration how we can do it. David
> Blevins and Arne Limburg are pretty good into this stuff. I'm dreaming of
> kind of the features of EJB standard transations, but NOT just for an EJB
> invocation, but @RequestScoped! The first invocation starts the
> UserTransaction, the @Disposes closes it. Just an idea ...
> >>
> >>
> >> 3.) ConfigurableDataSource
> >> You all know the dilemma: you cannot make a JNDI configuration in a
> way that this stuff works with multiple EE servers since the locations
> where you have your DataSource configured will pop up under different
> locations in JNDI (based on which EE server/version you take). Otoh I don't
> like to hardcode my credentials to the persistence.xml neither.
> >>
> >> Thus we came up with the ConfigurableDataSource [3]which just moves
> this information to a CDI bean where you can use
> @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even
> programmatic lookup!. I call this 'typesafe configuration'...
> >>
> >>
> >>
> >> Oki, any other ideas?
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
> >>
> >> [2]
> https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
> >>
> >> [3]
> https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
> >
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Cody Lerum <co...@gmail.com>.
+1 for deferring the CRUD work until a later release. Let's get the
basics right and out in the wild first.
On Tue, May 8, 2012 at 5:58 AM, Pete Muir <pm...@redhat.com> wrote:
> Following up on all emails sent so far on this thread:
>
> * I like Mark's priorities - @Transactional is definitely the item most requested
> * I like the design of plugging in different persistence strategies
> * Agreed that the standardised stuff for configuring datasources is a mess, we don't recommend it for use in JBoss, as we don't want to compile in this info. Instead we use a xml descriptor you can deploy, or a managed datasource configured via the management apis (scripted, HTTP, admin console etc.)
> * The big issue we have with the Java EE programmatic data source definition stuff, is that this normally isn't "part of your app" but something you want to provide externally and reference via JNDI. It would have good if we had specified XML as well as annotations for this. I think this is coming in Java EE 7, and then will resolve a lot of this problem, for me. We might also want to make the configuration a bit simpler.
> * Hopefully Stuart can provide some time on the transactions stuff
> * I think that the CRUD stuff is good for a later phase, getting the basic stuff right first is better
> * Agreed with Mark/Arne, there is no good way with the @DataSourceDefinition stuff to configure based on "project stage", and this is the critical problem, not the one about how to configure datasource across containers
>
> Answering David's questions
>
>> Q1. Alternatives and JavaEE Resource annotations. What happens if a CDI bean is annotated with "@Resource(name = "java:app/ds", lookup="java:app/prod/ds")", but has an alternate annotated with "@Resource(name = "java:app/ds", lookup="java:app/test/ds")?
>>
>> One would hope that either the main bean's JNDI entries *or* the alternate bean's JNDI entries will go into effect, not both. This isn't explicitly covered so I doubt will work. Something we might want to add at the spec level.
>
> It's not specified, and I don't think it works anywhere. We have raised this for Java EE 7, but received push back due to it coupling CDI too tightly into the Java EE core, which, as CDI isn't always on, is something the Java EE EG/spec leads want to avoid.
>
>>
>> Q2. Extensions adding/removing beans. What happens if a CDI bean is annotated with "@Resource(name = "java:app/ds", lookup="java:app/prod/ds")" and is vetoed by an Extension?
>>
>> One would hope that the JNDI entries that would be added by the vetoed bean are also essentially vetoed and the bean does not have an impact on the JNDI namespace. Also not explicitly addressed and something we might want to tackle at the spec level.
>
> As above :-)
>
>
> On 4 May 2012, at 20:56, Mark Struberg wrote:
>
>> Hi!
>>
>> It's time to start the discussion about our deltaspike-jpa module I think ;)
>>
>> a.) where
>> I suggest that we create a ee-modules project with submodules jsf, jpa, etc
>>
>> b.) what
>> *) @Transactional
>> *) TransactionalInterceptor with SimplePersistenceStrategy, JtaPersistenceStrategy
>> *) ConfigurableDataSource, evaluate if we can make use of a special PersistenceUnitInfo for JPA2 providers, but would that work in EE containers as well?
>>
>> Because I often get asked if we can add this: I think we do _not_ need to cover the (imo) broken Exception handling stuff which spring introduced in their transaction interceptor. An Exception is an Exception is an Exception! Logical return values and Business results must get propagated via standard java return values or content holder objects.
>>
>> Oki the details:
>>
>> 1.) @Transational
>>
>> I suggest that we temporarily implement the javax.transaction.* stuff of the _new_ Transaction Specification in DeltaSpike. We can take parts from OpenEJB, some JBoss api stuff (as far as covered by the grants) and various geronimo spec jars [1]
>> Once the spec is finished, we will move all the transaction-api.jar stuff over to geronimo-specs [1]. Since this all is ALv2 it will be no problem for JBoss folks to also just take the code and provide it in the JBossAS project once we are finished.
>>
>> 2.) I like the way we implemented the TransactionalInterceptor in CODI [2]. Our interceptor basically does exactly ... *nothing* ;)
>> All the work is done via an @Dependent PersistenceStrategy which gets injected into the interceptor. @Dependent because then we don't get any interceptor and it's really fast.
>> The BIG benefit of this little trick is that we are able to provide and use DIFFERENT PersistenceStrategies! A user can use @Alternative, @Specializes etc to define which PersistenceStrategy he likes to use in his project.
>>
>> By default I'd like to provide the following PersistenceStrategies:
>> * SimplePersistenceStrategy: does just flush on all involved EntityManagers and afterwards a commit. Not JTA transaction save, but good enough for most use cases
>> * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to control the EntitaManagers. This needs some exploration how we can do it. David Blevins and Arne Limburg are pretty good into this stuff. I'm dreaming of kind of the features of EJB standard transations, but NOT just for an EJB invocation, but @RequestScoped! The first invocation starts the UserTransaction, the @Disposes closes it. Just an idea ...
>>
>>
>> 3.) ConfigurableDataSource
>> You all know the dilemma: you cannot make a JNDI configuration in a way that this stuff works with multiple EE servers since the locations where you have your DataSource configured will pop up under different locations in JNDI (based on which EE server/version you take). Otoh I don't like to hardcode my credentials to the persistence.xml neither.
>>
>> Thus we came up with the ConfigurableDataSource [3]which just moves this information to a CDI bean where you can use @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even programmatic lookup!. I call this 'typesafe configuration'...
>>
>>
>>
>> Oki, any other ideas?
>>
>> LieGrue,
>> strub
>>
>>
>> [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>>
>> [2] https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
>>
>> [3] https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29
>
Re: [DISCUSS] deltaspike-jpa module features
Posted by Pete Muir <pm...@redhat.com>.
Following up on all emails sent so far on this thread:
* I like Mark's priorities - @Transactional is definitely the item most requested
* I like the design of plugging in different persistence strategies
* Agreed that the standardised stuff for configuring datasources is a mess, we don't recommend it for use in JBoss, as we don't want to compile in this info. Instead we use a xml descriptor you can deploy, or a managed datasource configured via the management apis (scripted, HTTP, admin console etc.)
* The big issue we have with the Java EE programmatic data source definition stuff, is that this normally isn't "part of your app" but something you want to provide externally and reference via JNDI. It would have good if we had specified XML as well as annotations for this. I think this is coming in Java EE 7, and then will resolve a lot of this problem, for me. We might also want to make the configuration a bit simpler.
* Hopefully Stuart can provide some time on the transactions stuff
* I think that the CRUD stuff is good for a later phase, getting the basic stuff right first is better
* Agreed with Mark/Arne, there is no good way with the @DataSourceDefinition stuff to configure based on "project stage", and this is the critical problem, not the one about how to configure datasource across containers
Answering David's questions
> Q1. Alternatives and JavaEE Resource annotations. What happens if a CDI bean is annotated with "@Resource(name = "java:app/ds", lookup="java:app/prod/ds")", but has an alternate annotated with "@Resource(name = "java:app/ds", lookup="java:app/test/ds")?
>
> One would hope that either the main bean's JNDI entries *or* the alternate bean's JNDI entries will go into effect, not both. This isn't explicitly covered so I doubt will work. Something we might want to add at the spec level.
It's not specified, and I don't think it works anywhere. We have raised this for Java EE 7, but received push back due to it coupling CDI too tightly into the Java EE core, which, as CDI isn't always on, is something the Java EE EG/spec leads want to avoid.
>
> Q2. Extensions adding/removing beans. What happens if a CDI bean is annotated with "@Resource(name = "java:app/ds", lookup="java:app/prod/ds")" and is vetoed by an Extension?
>
> One would hope that the JNDI entries that would be added by the vetoed bean are also essentially vetoed and the bean does not have an impact on the JNDI namespace. Also not explicitly addressed and something we might want to tackle at the spec level.
As above :-)
On 4 May 2012, at 20:56, Mark Struberg wrote:
> Hi!
>
> It's time to start the discussion about our deltaspike-jpa module I think ;)
>
> a.) where
> I suggest that we create a ee-modules project with submodules jsf, jpa, etc
>
> b.) what
> *) @Transactional
> *) TransactionalInterceptor with SimplePersistenceStrategy, JtaPersistenceStrategy
> *) ConfigurableDataSource, evaluate if we can make use of a special PersistenceUnitInfo for JPA2 providers, but would that work in EE containers as well?
>
> Because I often get asked if we can add this: I think we do _not_ need to cover the (imo) broken Exception handling stuff which spring introduced in their transaction interceptor. An Exception is an Exception is an Exception! Logical return values and Business results must get propagated via standard java return values or content holder objects.
>
> Oki the details:
>
> 1.) @Transational
>
> I suggest that we temporarily implement the javax.transaction.* stuff of the _new_ Transaction Specification in DeltaSpike. We can take parts from OpenEJB, some JBoss api stuff (as far as covered by the grants) and various geronimo spec jars [1]
> Once the spec is finished, we will move all the transaction-api.jar stuff over to geronimo-specs [1]. Since this all is ALv2 it will be no problem for JBoss folks to also just take the code and provide it in the JBossAS project once we are finished.
>
> 2.) I like the way we implemented the TransactionalInterceptor in CODI [2]. Our interceptor basically does exactly ... *nothing* ;)
> All the work is done via an @Dependent PersistenceStrategy which gets injected into the interceptor. @Dependent because then we don't get any interceptor and it's really fast.
> The BIG benefit of this little trick is that we are able to provide and use DIFFERENT PersistenceStrategies! A user can use @Alternative, @Specializes etc to define which PersistenceStrategy he likes to use in his project.
>
> By default I'd like to provide the following PersistenceStrategies:
> * SimplePersistenceStrategy: does just flush on all involved EntityManagers and afterwards a commit. Not JTA transaction save, but good enough for most use cases
> * JtaPersistenceStrategy: uses a JTA bound @UserTransaction to control the EntitaManagers. This needs some exploration how we can do it. David Blevins and Arne Limburg are pretty good into this stuff. I'm dreaming of kind of the features of EJB standard transations, but NOT just for an EJB invocation, but @RequestScoped! The first invocation starts the UserTransaction, the @Disposes closes it. Just an idea ...
>
>
> 3.) ConfigurableDataSource
> You all know the dilemma: you cannot make a JNDI configuration in a way that this stuff works with multiple EE servers since the locations where you have your DataSource configured will pop up under different locations in JNDI (based on which EE server/version you take). Otoh I don't like to hardcode my credentials to the persistence.xml neither.
>
> Thus we came up with the ConfigurableDataSource [3]which just moves this information to a CDI bean where you can use @Exclude(ifNotInProjectStage...), @Alternative, @Specializes and even programmatic lookup!. I call this 'typesafe configuration'...
>
>
>
> Oki, any other ideas?
>
> LieGrue,
> strub
>
>
> [1] http://repo1.maven.org/maven2/org/apache/geronimo/specs/
>
> [2] https://svn.apache.org/repos/asf/myfaces/extensions/cdi/trunk/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/transaction/TransactionalInterceptor.java
>
> [3] https://cwiki.apache.org/EXTCDI/jpa-usage.html#JPAUsage-ConfigurableDataSource%28sincev1.0.2%29