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 <[email protected]> > To: [email protected] > 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 <[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 >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>>> >> >>> >> >> >> >> >
