users@javaee-spec.java.net

[javaee-spec users] Re: [jsr342-experts] platform default DataSource and JMS ConnectionFactory

From: Jason Porter <lightguard.jp_at_gmail.com>
Date: Wed, 14 Mar 2012 18:38:36 -0600

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.

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.

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