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</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 <[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 > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > > > > >
