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:[email protected]] Gesendet: Sonntag, 6. Mai 2012 15:40 An: [email protected] 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" <[email protected]> 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:[email protected]] > Gesendet: Sonntag, 6. Mai 2012 15:28 > An: [email protected] > 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" <[email protected]> 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:[email protected]] > > Gesendet: Sonntag, 6. Mai 2012 15:14 > > An: [email protected] > > 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" <[email protected]> > > 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:[email protected]] > > > Gesendet: Sonntag, 6. Mai 2012 14:49 > > > An: Mark Struberg; [email protected] > > > 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" <[email protected]> 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 <[email protected]> > > > > >To: Mark Struberg <[email protected]>; > > > > [email protected] > > > > >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" <[email protected]> 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 <[email protected]> > > > > >>>To: Romain Manni-Bucau <[email protected]>; deltaspike < > > > > [email protected]> > > > > >>>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 <[email protected]> > > > > >>>>To: Mark Struberg <[email protected]> > > > > >>>>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" <[email protected]> a > écrit : > > > > >>>> > > > > >>>>yes, that crashes the container... > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>>________________________________ > > > > >>>>>> From: Romain Manni-Bucau <[email protected]> > > > > >>>>>>To: Mark Struberg <[email protected]>; > > > > [email protected] > > > > >>>>>>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" <[email protected]> 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 <[email protected]> > > > > >>>>>>>> To: [email protected]; Mark Struberg > > > > >>>>>>>> < > > > > [email protected]> > > > > >>>>>>>> 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 > > > > >>>>>>>> > > > > >>>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > > > > > > > > > > >
