Jason Porter wrote on 03/14/2012 05:38 PM:
> On Mar 14, 2012, at 17:55, Bill Shannon<bill.shannon_at_oracle.com> wrote:
>
>> Jason Porter wrote on 03/12/12 11:54:
>>> I like the idea of #3 and use one of the new JNDI locations defined in Java EE
>>> 6, module perhaps so other apps in the same EAR could share the datasource.
>>
>> Most of our existing pre-defined names are in the java:comp namespace,
>> mostly because they were defined before we had the additional namespaces.
>> For consistency, we would probably do the same for a default datasource,
>> even though the "scope" of the datasource is global and could be used
>> by any component in any module in any application.
>
> Is there anything that says they have be global? If I were to define a datasource in a war or ear, I would expect it to only really be available in that module. If you wanted a global datasource, then define that globally however the server does that.
You're confusing the ability to define a DataSource resource, which
we added in Java EE 6 with the @DataSourceDefinition annotation, with
this new feature where the app server pre-defines a name for the default
DataSource. If you're defining the DataSource yourself, you can put it
in whatever namespace scope is appropriate.
> That may well be an inconsistency we inherit from older versions and usage though. Non global datasources would be nice during development.
>
>>> As we'll more than likely have an XML counterpart for this, might I recommend
>>> having one file for all this configuration stuff? We already have ejb.xml,
>>> application.xml, beans.xml (yes, I know this is as much of a marker file for the
>>> archives as anything else), web.xml, faces-config.xml, persistence.xml and
>>> possibly one or two I've forgotten. I also understand some of these are optional
>>> now like web.xml or faces-config.xml. Moving towards a unification of
>>> configuration files which would allow configuration of all (most only possible?)
>>> of these would be a great help for new developers.
>>
>> The proposal here doesn't require an XML counterpart. It defines a new
>> name that the app server always provides. The application doesn't have
>> to do anything for the name to appear. Use of the name would use the
>> existing mechanisms in the existing deployment descriptors.
>
> I thought there was always an XML equivalent for anything you could do with annotations.
There is, but this isn't something new you can do with annotations.
This is a new JNDI name that you can use with the existing annotations.
>> Unification of configuration files is an interesting issue, but unrelated
>> to this proposal.
>
> Is it something the EG would be willing to explore this as separate thread / issue?
Various people have had ideas about this, but honestly I don't think this
is one of the biggest problems we're facing, and our plate is already
pretty full.