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