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 <[email protected]> > > 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 <[email protected]> > >> To: "[email protected]" < > [email protected]>; Mark Struberg <[email protected]> > >> 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:[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 > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >> > >
