[wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Scott Marlow
Hi,

Lincoln was just asking why WildFly 8 doesn't yet have a
java:comp/DefaultDataSource that is talked about in EE.5.20 and [1].

Lincoln created WFLY-2027 for the JPA part of EE.5.20 (if we add support
for a default datasource in WildFly 8.)

I'm kind of caught on this requirement, since we already have a JPA
level default datasource setting (for JPA container deployment).  I need
to know if we are going to add a default datasource
(java:comp/DefaultDataSource) setting to WildFly, so I can align with that.

Steve Ebersole, already offered to add a Hibernate ORM way [2] for this
(defaultDatasource) change to not break OGM, which we would need to use
in WildFly 8 (or WF 9) and JipiJapa.  Since we are talking about going
to Beta with WildFly 8, I assume this change is too late, but then
again, it sounds like its expected for EE 7 ;)

Scott

[1] https://blogs.oracle.com/arungupta/entry/default_datasource_in_java_ee

[2] https://gist.github.com/scottmarlow/6497927
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Max Rydahl Andersen-2
I just got hit by this missing when trying to write a portable version of kitchensink for a J1 talk :/

Any chance on getting a patch that would enable it ? :)

/max

On Mon, Sep 09, 2013 at 12:23:51PM -0400, Scott Marlow wrote:

>Hi,
>
>Lincoln was just asking why WildFly 8 doesn't yet have a
>java:comp/DefaultDataSource that is talked about in EE.5.20 and [1].
>
>Lincoln created WFLY-2027 for the JPA part of EE.5.20 (if we add support
>for a default datasource in WildFly 8.)
>
>I'm kind of caught on this requirement, since we already have a JPA
>level default datasource setting (for JPA container deployment).  I need
>to know if we are going to add a default datasource
>(java:comp/DefaultDataSource) setting to WildFly, so I can align with that.
>
>Steve Ebersole, already offered to add a Hibernate ORM way [2] for this
>(defaultDatasource) change to not break OGM, which we would need to use
>in WildFly 8 (or WF 9) and JipiJapa.  Since we are talking about going
>to Beta with WildFly 8, I assume this change is too late, but then
>again, it sounds like its expected for EE 7 ;)
>
>Scott
>
>[1] https://blogs.oracle.com/arungupta/entry/default_datasource_in_java_ee
>
>[2] https://gist.github.com/scottmarlow/6497927
>_______________________________________________
>wildfly-dev mailing list
>[hidden email]
>https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Scott Marlow
Workaround might be to use the JPA subsystem configuration for the J1 talk.

In standalone.xml, use:

<jpa default-datasource="java:jboss/datasources/ExampleDS"
default-extended-persistence-inheritance="DEEP"/>

On 09/13/2013 06:33 AM, Max Rydahl Andersen wrote:

> I just got hit by this missing when trying to write a portable version
> of kitchensink for a J1 talk :/
>
> Any chance on getting a patch that would enable it ? :)
>
> /max
>
> On Mon, Sep 09, 2013 at 12:23:51PM -0400, Scott Marlow wrote:
>> Hi,
>>
>> Lincoln was just asking why WildFly 8 doesn't yet have a
>> java:comp/DefaultDataSource that is talked about in EE.5.20 and [1].
>>
>> Lincoln created WFLY-2027 for the JPA part of EE.5.20 (if we add support
>> for a default datasource in WildFly 8.)
>>
>> I'm kind of caught on this requirement, since we already have a JPA
>> level default datasource setting (for JPA container deployment).  I need
>> to know if we are going to add a default datasource
>> (java:comp/DefaultDataSource) setting to WildFly, so I can align with
>> that.
>>
>> Steve Ebersole, already offered to add a Hibernate ORM way [2] for this
>> (defaultDatasource) change to not break OGM, which we would need to use
>> in WildFly 8 (or WF 9) and JipiJapa.  Since we are talking about going
>> to Beta with WildFly 8, I assume this change is too late, but then
>> again, it sounds like its expected for EE 7 ;)
>>
>> Scott
>>
>> [1]
>> https://blogs.oracle.com/arungupta/entry/default_datasource_in_java_ee
>>
>> [2] https://gist.github.com/scottmarlow/6497927
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Jaikiran Pai
In reply to this post by Scott Marlow
On Monday 09 September 2013 09:53 PM, Scott Marlow wrote:

> Hi,
>
> Lincoln was just asking why WildFly 8 doesn't yet have a
> java:comp/DefaultDataSource that is talked about in EE.5.20 and [1].
>
> Lincoln created WFLY-2027 for the JPA part of EE.5.20 (if we add support
> for a default datasource in WildFly 8.)
>
> I'm kind of caught on this requirement, since we already have a JPA
> level default datasource setting (for JPA container deployment).  I need
> to know if we are going to add a default datasource
> (java:comp/DefaultDataSource) setting to WildFly, so I can align with that.
I think we should add support for java:comp/DefaultDataSource since it's
required by spec. Furthermore, this isn't essentially just JPA thing
since such and injected/lookedup datasource could even be used in a
non-JPA application.

As for aligning this with the JPA datasource setting, I don't fully
understand the context. From what I understand, these two are different
things.

-Jaikiran

>
> Steve Ebersole, already offered to add a Hibernate ORM way [2] for this
> (defaultDatasource) change to not break OGM, which we would need to use
> in WildFly 8 (or WF 9) and JipiJapa.  Since we are talking about going
> to Beta with WildFly 8, I assume this change is too late, but then
> again, it sounds like its expected for EE 7 ;)
>
> Scott
>
> [1] https://blogs.oracle.com/arungupta/entry/default_datasource_in_java_ee
>
> [2] https://gist.github.com/scottmarlow/6497927
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Jesper Pedersen
On 09/23/2013 11:01 AM, Jaikiran Pai wrote:
> On Monday 09 September 2013 09:53 PM, Scott Marlow wrote:
>> I'm kind of caught on this requirement, since we already have a JPA
>> level default datasource setting (for JPA container deployment).  I need
>> to know if we are going to add a default datasource
>> (java:comp/DefaultDataSource) setting to WildFly, so I can align with that.
> I think we should add support for java:comp/DefaultDataSource since it's
> required by spec. Furthermore, this isn't essentially just JPA thing
> since such and injected/lookedup datasource could even be used in a
> non-JPA application.

I think the best solution is to add an element in the :ee: subsystem
that points to a JNDI name defined in the :datasources: subsystem.

We shouldn't make it a mandatory element though, since WildFly doesn't
require a datasource to operate.

Best regards,
  Jesper

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

David Lloyd-2
On 09/23/2013 10:04 AM, Jesper Pedersen wrote:

> On 09/23/2013 11:01 AM, Jaikiran Pai wrote:
>> On Monday 09 September 2013 09:53 PM, Scott Marlow wrote:
>>> I'm kind of caught on this requirement, since we already have a JPA
>>> level default datasource setting (for JPA container deployment).  I need
>>> to know if we are going to add a default datasource
>>> (java:comp/DefaultDataSource) setting to WildFly, so I can align with that.
>> I think we should add support for java:comp/DefaultDataSource since it's
>> required by spec. Furthermore, this isn't essentially just JPA thing
>> since such and injected/lookedup datasource could even be used in a
>> non-JPA application.
>
> I think the best solution is to add an element in the :ee: subsystem
> that points to a JNDI name defined in the :datasources: subsystem.
>
> We shouldn't make it a mandatory element though, since WildFly doesn't
> require a datasource to operate.

I updated the WFLY-2027 JIRA - I recall that it should be possible to
configure this just by adding a single element to the naming subsystem
(even though the context is EE-specific).

https://issues.jboss.org/browse/WFLY-2027#comment-12806620
--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Jaikiran Pai
In reply to this post by Jesper Pedersen
On Monday 23 September 2013 08:34 PM, Jesper Pedersen wrote:

> On 09/23/2013 11:01 AM, Jaikiran Pai wrote:
>> On Monday 09 September 2013 09:53 PM, Scott Marlow wrote:
>>> I'm kind of caught on this requirement, since we already have a JPA
>>> level default datasource setting (for JPA container deployment).  I need
>>> to know if we are going to add a default datasource
>>> (java:comp/DefaultDataSource) setting to WildFly, so I can align with that.
>> I think we should add support for java:comp/DefaultDataSource since it's
>> required by spec. Furthermore, this isn't essentially just JPA thing
>> since such and injected/lookedup datasource could even be used in a
>> non-JPA application.
> I think the best solution is to add an element in the :ee: subsystem
> that points to a JNDI name defined in the :datasources: subsystem.
I don't think we need any configuration in this case since the spec
states that the product vendor just make available a pre-configured
datasource (which we already do) under that JNDI name (right now we do
in under a JBoss specific JNDI name). So I think it can be as simple as
a linkref kind of thing within the code where we point
java:comp/DefaultDataSource to the H2 datasource's JNDI name, without
any additional configurations.

Of course (like the spec states) the user can always override this by
configuring a datasource of their own and then using:

@Resource(name="java:comp/DefaultDataSource",
lookup="jndi-name-of-their-new-datasource")

-Jaikiran

>
> We shouldn't make it a mandatory element though, since WildFly doesn't
> require a datasource to operate.
>
> Best regards,
>    Jesper
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Jesper Pedersen
On 09/23/2013 11:14 AM, Jaikiran Pai wrote:

>> I think the best solution is to add an element in the :ee: subsystem
>> that points to a JNDI name defined in the :datasources: subsystem.
> I don't think we need any configuration in this case since the spec
> states that the product vendor just make available a pre-configured
> datasource (which we already do) under that JNDI name (right now we do
> in under a JBoss specific JNDI name). So I think it can be as simple as
> a linkref kind of thing within the code where we point
> java:comp/DefaultDataSource to the H2 datasource's JNDI name, without
> any additional configurations.
>

Lets not go down the "DefaultDS" road again, especially since we bundle H2.

And, we don't provide a default one - we have an ExampleDS, which is
completely different.

The configuration should be external, and not in code - so adding the
linkref in the :naming: subsystem sounds good to me.

Best regards,
  Jesper

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Jeff Mesnil
In reply to this post by Jaikiran Pai

On 23 Sep 2013, at 17:14, Jaikiran Pai <[hidden email]> wrote:

> On Monday 23 September 2013 08:34 PM, Jesper Pedersen wrote:
>> On 09/23/2013 11:01 AM, Jaikiran Pai wrote:
>>> On Monday 09 September 2013 09:53 PM, Scott Marlow wrote:
>>>> I'm kind of caught on this requirement, since we already have a JPA
>>>> level default datasource setting (for JPA container deployment).  I need
>>>> to know if we are going to add a default datasource
>>>> (java:comp/DefaultDataSource) setting to WildFly, so I can align with that.
>>> I think we should add support for java:comp/DefaultDataSource since it's
>>> required by spec. Furthermore, this isn't essentially just JPA thing
>>> since such and injected/lookedup datasource could even be used in a
>>> non-JPA application.
>> I think the best solution is to add an element in the :ee: subsystem
>> that points to a JNDI name defined in the :datasources: subsystem.
> I don't think we need any configuration in this case since the spec
> states that the product vendor just make available a pre-configured
> datasource (which we already do) under that JNDI name (right now we do
> in under a JBoss specific JNDI name). So I think it can be as simple as
> a linkref kind of thing within the code where we point

fwiw, the EE spec also mandates that a default JMS connection factory must be available to deployments at "java:comp/DefaultJMSConnectionFactory".

I added in the messaging subsystem a DeploymentUnitProcessor[1] that create binding configurations for our JMS ConnectionFactory defined in the profile at "java:jboss/DefaultJMSConnectionFactory"
to make it available under the standard   "java:comp/DefaultJMSConnectionFactory"

jeff

[1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/org/jboss/as/messaging/deployment/MessagingJndiBindingProcessor.java

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

David Lloyd-2
On 09/23/2013 10:31 AM, Jeff Mesnil wrote:

>
> On 23 Sep 2013, at 17:14, Jaikiran Pai <[hidden email]> wrote:
>
>> On Monday 23 September 2013 08:34 PM, Jesper Pedersen wrote:
>>> On 09/23/2013 11:01 AM, Jaikiran Pai wrote:
>>>> On Monday 09 September 2013 09:53 PM, Scott Marlow wrote:
>>>>> I'm kind of caught on this requirement, since we already have a JPA
>>>>> level default datasource setting (for JPA container deployment).  I need
>>>>> to know if we are going to add a default datasource
>>>>> (java:comp/DefaultDataSource) setting to WildFly, so I can align with that.
>>>> I think we should add support for java:comp/DefaultDataSource since it's
>>>> required by spec. Furthermore, this isn't essentially just JPA thing
>>>> since such and injected/lookedup datasource could even be used in a
>>>> non-JPA application.
>>> I think the best solution is to add an element in the :ee: subsystem
>>> that points to a JNDI name defined in the :datasources: subsystem.
>> I don't think we need any configuration in this case since the spec
>> states that the product vendor just make available a pre-configured
>> datasource (which we already do) under that JNDI name (right now we do
>> in under a JBoss specific JNDI name). So I think it can be as simple as
>> a linkref kind of thing within the code where we point
>
> fwiw, the EE spec also mandates that a default JMS connection factory must be available to deployments at "java:comp/DefaultJMSConnectionFactory".
>
> I added in the messaging subsystem a DeploymentUnitProcessor[1] that create binding configurations for our JMS ConnectionFactory defined in the profile at "java:jboss/DefaultJMSConnectionFactory"
> to make it available under the standard   "java:comp/DefaultJMSConnectionFactory"

It might have been better to do this in configuration as well.  I think
in general we should avoid making automatic bindings that cannot be
disabled; and if they *can* be disabled it is better to do it in a
uniform way (i.e. use the naming subsystem) instead of having a zillion
disable-xyz config attributes.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Jeff Mesnil

On 23 Sep 2013, at 17:38, "David M. Lloyd" <[hidden email]> wrote:

> On 09/23/2013 10:31 AM, Jeff Mesnil wrote:
>>
>> On 23 Sep 2013, at 17:14, Jaikiran Pai <[hidden email]> wrote:
>>
>>> On Monday 23 September 2013 08:34 PM, Jesper Pedersen wrote:
>>>> On 09/23/2013 11:01 AM, Jaikiran Pai wrote:
>>>>> On Monday 09 September 2013 09:53 PM, Scott Marlow wrote:
>>>>>> I'm kind of caught on this requirement, since we already have a JPA
>>>>>> level default datasource setting (for JPA container deployment).  I need
>>>>>> to know if we are going to add a default datasource
>>>>>> (java:comp/DefaultDataSource) setting to WildFly, so I can align with that.
>>>>> I think we should add support for java:comp/DefaultDataSource since it's
>>>>> required by spec. Furthermore, this isn't essentially just JPA thing
>>>>> since such and injected/lookedup datasource could even be used in a
>>>>> non-JPA application.
>>>> I think the best solution is to add an element in the :ee: subsystem
>>>> that points to a JNDI name defined in the :datasources: subsystem.
>>> I don't think we need any configuration in this case since the spec
>>> states that the product vendor just make available a pre-configured
>>> datasource (which we already do) under that JNDI name (right now we do
>>> in under a JBoss specific JNDI name). So I think it can be as simple as
>>> a linkref kind of thing within the code where we point
>>
>> fwiw, the EE spec also mandates that a default JMS connection factory must be available to deployments at "java:comp/DefaultJMSConnectionFactory".
>>
>> I added in the messaging subsystem a DeploymentUnitProcessor[1] that create binding configurations for our JMS ConnectionFactory defined in the profile at "java:jboss/DefaultJMSConnectionFactory"
>> to make it available under the standard   "java:comp/DefaultJMSConnectionFactory"
>
> It might have been better to do this in configuration as well.  I think
> in general we should avoid making automatic bindings that cannot be
> disabled; and if they *can* be disabled it is better to do it in a
> uniform way (i.e. use the naming subsystem) instead of having a zillion
> disable-xyz config attributes.

I'm not sure to have understood you correctly but I'm not able to add a java:comp entry in the naming subsystem:

[standalone@localhost:9990 /] /subsystem=naming/binding="java:comp/DefaultJMSConnectionFactory":add(binding-type=lookup, lookup=java:jboss/DefaultJMSConnectionFactory)
{
    "outcome" => "failed",
    "failure-description" => "JBAS011864: Invaliding binding name java:comp/DefaultJMSConnectionFactory, name must start with one of [java:global, java:jboss, java:/]",
    "rolled-back" => true
}

That's why I added the DeploymentUnitProcessor to the messaging subsystem, to be able to add this lookup to the deployed component namespace.

But if there is a simpler/cleaner way to do it, I can change this.

jeff

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Eduardo Martins-2
Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...

IMHO default EE resources should be defined in the related subsystem configuration, otherwise the EE subsystem config will always be changing. In this case there should a configuration in the Datasources subsystem such as:

<subsystem xmlns="urn:jboss:domain:datasources:2.0">
       <datasources>
        <default-datasource jndi-name="java:jboss/datasources/ExampleDS" />  
                <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
                        ...
                </datasource>
        ...
       </datasources>
</subsystem>

For an easier/faster logic to find the default resource, and since we don't officially support linkref on jndi, the subsystem management op that adds the default resource (in this case default-datasource) should create a binder service pointing to a *fixed* jndi name (let's says java:jboss/ee/default/datasource) and inject it with the target resource (in this case the jndi name java:jboss/datasources/ExampleDS).

Then the subsystem should provide a DUP that for EE modules do the required default bindings, in this case java:comp/DefaultDataSource and/or java:module/DefaultDataSource

The subsystem then also needs to take care of the default mapping to the *fixed* jndi name from @Resource injection, this can be accomplished by adding a EEResourceReferenceProcessor to the EEResourceReferenceProcessorRegistry present in DU attachment with key org.jboss.as.ee.component.Attachments.RESOURCE_REFERENCE_PROCESSOR_REGISTRY

--E
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

David Lloyd-2
On 09/24/2013 05:14 AM, Eduardo Martins wrote:

> Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...
>
> IMHO default EE resources should be defined in the related subsystem configuration, otherwise the EE subsystem config will always be changing. In this case there should a configuration in the Datasources subsystem such as:
>
> <subsystem xmlns="urn:jboss:domain:datasources:2.0">
>         <datasources>
>         <default-datasource jndi-name="java:jboss/datasources/ExampleDS" />
> <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
> ...
>        </datasource>
>           ...
>         </datasources>
> </subsystem>
>
> For an easier/faster logic to find the default resource, and since we don't officially support linkref on jndi, the subsystem management op that adds the default resource (in this case default-datasource) should create a binder service pointing to a *fixed* jndi name (let's says java:jboss/ee/default/datasource) and inject it with the target resource (in this case the jndi name java:jboss/datasources/ExampleDS).
>
> Then the subsystem should provide a DUP that for EE modules do the required default bindings, in this case java:comp/DefaultDataSource and/or java:module/DefaultDataSource
>
> The subsystem then also needs to take care of the default mapping to the *fixed* jndi name from @Resource injection, this can be accomplished by adding a EEResourceReferenceProcessor to the EEResourceReferenceProcessorRegistry present in DU attachment with key org.jboss.as.ee.component.Attachments.RESOURCE_REFERENCE_PROCESSOR_REGISTRY

I don't know, I guess I'm running out of opinion on this.

Here's a list of options:

1) Enhance naming subsystem to be able to bind java:comp, java:module,
java:app names, and put config in that subsystem (modify JMS and other
subsystems with implicit bindings to do the same)
2) Enhance datasources subsystem to include a default datasource
attribute (== XML element) which, when present, will set up implicit
bindings for java:comp (and make sure that the config looks/acts
similarly between JMS, DS, and any other subsystem with implicit bindings)
3) Decide it's all the EE subsystem and put implicit bindings in there

Decision time: GO!
--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Eduardo Martins-2
I guess 2) is what I wrote about and have been doing lately. The whole functionality is easy to deactivate too, just remove such xml element and the DUPs that do the bindings and/or sets up resource injection are also not used.

--E

On Sep 24, 2013, at 3:12 PM, "David M. Lloyd" <[hidden email]> wrote:

> On 09/24/2013 05:14 AM, Eduardo Martins wrote:
>> Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...
>>
>> IMHO default EE resources should be defined in the related subsystem configuration, otherwise the EE subsystem config will always be changing. In this case there should a configuration in the Datasources subsystem such as:
>>
>> <subsystem xmlns="urn:jboss:domain:datasources:2.0">
>>        <datasources>
>>         <default-datasource jndi-name="java:jboss/datasources/ExampleDS" />
>> <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
>> ...
>>        </datasource>
>>         ...
>>        </datasources>
>> </subsystem>
>>
>> For an easier/faster logic to find the default resource, and since we don't officially support linkref on jndi, the subsystem management op that adds the default resource (in this case default-datasource) should create a binder service pointing to a *fixed* jndi name (let's says java:jboss/ee/default/datasource) and inject it with the target resource (in this case the jndi name java:jboss/datasources/ExampleDS).
>>
>> Then the subsystem should provide a DUP that for EE modules do the required default bindings, in this case java:comp/DefaultDataSource and/or java:module/DefaultDataSource
>>
>> The subsystem then also needs to take care of the default mapping to the *fixed* jndi name from @Resource injection, this can be accomplished by adding a EEResourceReferenceProcessor to the EEResourceReferenceProcessorRegistry present in DU attachment with key org.jboss.as.ee.component.Attachments.RESOURCE_REFERENCE_PROCESSOR_REGISTRY
>
> I don't know, I guess I'm running out of opinion on this.
>
> Here's a list of options:
>
> 1) Enhance naming subsystem to be able to bind java:comp, java:module,
> java:app names, and put config in that subsystem (modify JMS and other
> subsystems with implicit bindings to do the same)
> 2) Enhance datasources subsystem to include a default datasource
> attribute (== XML element) which, when present, will set up implicit
> bindings for java:comp (and make sure that the config looks/acts
> similarly between JMS, DS, and any other subsystem with implicit bindings)
> 3) Decide it's all the EE subsystem and put implicit bindings in there
>
> Decision time: GO!
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Tomaž Cerar-2
In reply to this post by David Lloyd-2
I would go with 3)
given that this is EE related thing and other subsystems can also work/operate in non-EE scenarios.



On Tue, Sep 24, 2013 at 4:12 PM, David M. Lloyd <[hidden email]> wrote:
On 09/24/2013 05:14 AM, Eduardo Martins wrote:
> Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...
>
> IMHO default EE resources should be defined in the related subsystem configuration, otherwise the EE subsystem config will always be changing. In this case there should a configuration in the Datasources subsystem such as:
>
> <subsystem xmlns="urn:jboss:domain:datasources:2.0">
>         <datasources>
>                       <default-datasource jndi-name="java:jboss/datasources/ExampleDS" />
>               <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
>                       ...
>               </datasource>
>               ...
>         </datasources>
> </subsystem>
>
> For an easier/faster logic to find the default resource, and since we don't officially support linkref on jndi, the subsystem management op that adds the default resource (in this case default-datasource) should create a binder service pointing to a *fixed* jndi name (let's says java:jboss/ee/default/datasource) and inject it with the target resource (in this case the jndi name java:jboss/datasources/ExampleDS).
>
> Then the subsystem should provide a DUP that for EE modules do the required default bindings, in this case java:comp/DefaultDataSource and/or java:module/DefaultDataSource
>
> The subsystem then also needs to take care of the default mapping to the *fixed* jndi name from @Resource injection, this can be accomplished by adding a EEResourceReferenceProcessor to the EEResourceReferenceProcessorRegistry present in DU attachment with key org.jboss.as.ee.component.Attachments.RESOURCE_REFERENCE_PROCESSOR_REGISTRY

I don't know, I guess I'm running out of opinion on this.

Here's a list of options:

1) Enhance naming subsystem to be able to bind java:comp, java:module,
java:app names, and put config in that subsystem (modify JMS and other
subsystems with implicit bindings to do the same)
2) Enhance datasources subsystem to include a default datasource
attribute (== XML element) which, when present, will set up implicit
bindings for java:comp (and make sure that the config looks/acts
similarly between JMS, DS, and any other subsystem with implicit bindings)
3) Decide it's all the EE subsystem and put implicit bindings in there

Decision time: GO!
--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Stuart Douglas
In reply to this post by David Lloyd-2
I think option 1, enhance the naming subsystem bindings. I think it would be confusing to have two different places to define bindings.

Sent from my iPhone

On 24/09/2013, at 15:12, "David M. Lloyd" <[hidden email]> wrote:

> On 09/24/2013 05:14 AM, Eduardo Martins wrote:
>> Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...
>>
>> IMHO default EE resources should be defined in the related subsystem configuration, otherwise the EE subsystem config will always be changing. In this case there should a configuration in the Datasources subsystem such as:
>>
>> <subsystem xmlns="urn:jboss:domain:datasources:2.0">
>>        <datasources>
>>                <default-datasource jndi-name="java:jboss/datasources/ExampleDS" />
>>        <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
>>            ...
>>            </datasource>
>>             ...
>>        </datasources>
>> </subsystem>
>>
>> For an easier/faster logic to find the default resource, and since we don't officially support linkref on jndi, the subsystem management op that adds the default resource (in this case default-datasource) should create a binder service pointing to a *fixed* jndi name (let's says java:jboss/ee/default/datasource) and inject it with the target resource (in this case the jndi name java:jboss/datasources/ExampleDS).
>>
>> Then the subsystem should provide a DUP that for EE modules do the required default bindings, in this case java:comp/DefaultDataSource and/or java:module/DefaultDataSource
>>
>> The subsystem then also needs to take care of the default mapping to the *fixed* jndi name from @Resource injection, this can be accomplished by adding a EEResourceReferenceProcessor to the EEResourceReferenceProcessorRegistry present in DU attachment with key org.jboss.as.ee.component.Attachments.RESOURCE_REFERENCE_PROCESSOR_REGISTRY
>
> I don't know, I guess I'm running out of opinion on this.
>
> Here's a list of options:
>
> 1) Enhance naming subsystem to be able to bind java:comp, java:module,
> java:app names, and put config in that subsystem (modify JMS and other
> subsystems with implicit bindings to do the same)
> 2) Enhance datasources subsystem to include a default datasource
> attribute (== XML element) which, when present, will set up implicit
> bindings for java:comp (and make sure that the config looks/acts
> similarly between JMS, DS, and any other subsystem with implicit bindings)
> 3) Decide it's all the EE subsystem and put implicit bindings in there
>
> Decision time: GO!
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Eduardo Martins-2
In reply to this post by Tomaž Cerar-2
Yes, thinking a bit more about it, that probably looks better at user eyes, easier to config, and changes after all only come whenever there is a new EE spec. Trouble could come if there is the needed to depend on classes on other subsystems but this is purely just a matter of taking what's in a jndi name and put it elsewhere on java:comp or java:module.

On Sep 24, 2013, at 3:35 PM, Tomaž Cerar <[hidden email]> wrote:

> I would go with 3)
> given that this is EE related thing and other subsystems can also work/operate in non-EE scenarios.
>
>
>
> On Tue, Sep 24, 2013 at 4:12 PM, David M. Lloyd <[hidden email]> wrote:
> On 09/24/2013 05:14 AM, Eduardo Martins wrote:
> > Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...
> >
> > IMHO default EE resources should be defined in the related subsystem configuration, otherwise the EE subsystem config will always be changing. In this case there should a configuration in the Datasources subsystem such as:
> >
> > <subsystem xmlns="urn:jboss:domain:datasources:2.0">
> >         <datasources>
> >                       <default-datasource jndi-name="java:jboss/datasources/ExampleDS" />
> >               <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
> >                       ...
> >               </datasource>
> >               ...
> >         </datasources>
> > </subsystem>
> >
> > For an easier/faster logic to find the default resource, and since we don't officially support linkref on jndi, the subsystem management op that adds the default resource (in this case default-datasource) should create a binder service pointing to a *fixed* jndi name (let's says java:jboss/ee/default/datasource) and inject it with the target resource (in this case the jndi name java:jboss/datasources/ExampleDS).
> >
> > Then the subsystem should provide a DUP that for EE modules do the required default bindings, in this case java:comp/DefaultDataSource and/or java:module/DefaultDataSource
> >
> > The subsystem then also needs to take care of the default mapping to the *fixed* jndi name from @Resource injection, this can be accomplished by adding a EEResourceReferenceProcessor to the EEResourceReferenceProcessorRegistry present in DU attachment with key org.jboss.as.ee.component.Attachments.RESOURCE_REFERENCE_PROCESSOR_REGISTRY
>
> I don't know, I guess I'm running out of opinion on this.
>
> Here's a list of options:
>
> 1) Enhance naming subsystem to be able to bind java:comp, java:module,
> java:app names, and put config in that subsystem (modify JMS and other
> subsystems with implicit bindings to do the same)
> 2) Enhance datasources subsystem to include a default datasource
> attribute (== XML element) which, when present, will set up implicit
> bindings for java:comp (and make sure that the config looks/acts
> similarly between JMS, DS, and any other subsystem with implicit bindings)
> 3) Decide it's all the EE subsystem and put implicit bindings in there
>
> Decision time: GO!
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Brian Stansberry
In reply to this post by David Lloyd-2
3) is confusing. If it's naming binding stuff, putting it in naming or
in the relevant subsystem seems more intuitive.

What does 1) really mean in terms of config? Something generic? Or
something quite specific that results in the appropriate bindings?
Generic makes me nervous as it opens up a whole new broad feature with
many possible ways it could be broken.

I like 1) better than 2) if my concern above can be addressed.

On 9/24/13 9:12 AM, David M. Lloyd wrote:

> On 09/24/2013 05:14 AM, Eduardo Martins wrote:
>> Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...
>>
>> IMHO default EE resources should be defined in the related subsystem configuration, otherwise the EE subsystem config will always be changing. In this case there should a configuration in the Datasources subsystem such as:
>>
>> <subsystem xmlns="urn:jboss:domain:datasources:2.0">
>>          <datasources>
>>           <default-datasource jndi-name="java:jboss/datasources/ExampleDS" />
>> <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
>> ...
>>        </datasource>
>>           ...
>>          </datasources>
>> </subsystem>
>>
>> For an easier/faster logic to find the default resource, and since we don't officially support linkref on jndi, the subsystem management op that adds the default resource (in this case default-datasource) should create a binder service pointing to a *fixed* jndi name (let's says java:jboss/ee/default/datasource) and inject it with the target resource (in this case the jndi name java:jboss/datasources/ExampleDS).
>>
>> Then the subsystem should provide a DUP that for EE modules do the required default bindings, in this case java:comp/DefaultDataSource and/or java:module/DefaultDataSource
>>
>> The subsystem then also needs to take care of the default mapping to the *fixed* jndi name from @Resource injection, this can be accomplished by adding a EEResourceReferenceProcessor to the EEResourceReferenceProcessorRegistry present in DU attachment with key org.jboss.as.ee.component.Attachments.RESOURCE_REFERENCE_PROCESSOR_REGISTRY
>
> I don't know, I guess I'm running out of opinion on this.
>
> Here's a list of options:
>
> 1) Enhance naming subsystem to be able to bind java:comp, java:module,
> java:app names, and put config in that subsystem (modify JMS and other
> subsystems with implicit bindings to do the same)
> 2) Enhance datasources subsystem to include a default datasource
> attribute (== XML element) which, when present, will set up implicit
> bindings for java:comp (and make sure that the config looks/acts
> similarly between JMS, DS, and any other subsystem with implicit bindings)
> 3) Decide it's all the EE subsystem and put implicit bindings in there
>
> Decision time: GO!
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

David Lloyd-2
I think it means the config will continue to work just as it does,
except Jeff's error message won't happen anymore.  Bindings in
non-global namespaces would materialize in every instance of that namespace.

On 09/24/2013 09:50 AM, Brian Stansberry wrote:

> 3) is confusing. If it's naming binding stuff, putting it in naming or
> in the relevant subsystem seems more intuitive.
>
> What does 1) really mean in terms of config? Something generic? Or
> something quite specific that results in the appropriate bindings?
> Generic makes me nervous as it opens up a whole new broad feature with
> many possible ways it could be broken.
>
> I like 1) better than 2) if my concern above can be addressed.
>
> On 9/24/13 9:12 AM, David M. Lloyd wrote:
>> On 09/24/2013 05:14 AM, Eduardo Martins wrote:
>>> Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...
>>>
>>> IMHO default EE resources should be defined in the related subsystem configuration, otherwise the EE subsystem config will always be changing. In this case there should a configuration in the Datasources subsystem such as:
>>>
>>> <subsystem xmlns="urn:jboss:domain:datasources:2.0">
>>>           <datasources>
>>>           <default-datasource jndi-name="java:jboss/datasources/ExampleDS" />
>>> <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
>>> ...
>>>        </datasource>
>>>             ...
>>>           </datasources>
>>> </subsystem>
>>>
>>> For an easier/faster logic to find the default resource, and since we don't officially support linkref on jndi, the subsystem management op that adds the default resource (in this case default-datasource) should create a binder service pointing to a *fixed* jndi name (let's says java:jboss/ee/default/datasource) and inject it with the target resource (in this case the jndi name java:jboss/datasources/ExampleDS).
>>>
>>> Then the subsystem should provide a DUP that for EE modules do the required default bindings, in this case java:comp/DefaultDataSource and/or java:module/DefaultDataSource
>>>
>>> The subsystem then also needs to take care of the default mapping to the *fixed* jndi name from @Resource injection, this can be accomplished by adding a EEResourceReferenceProcessor to the EEResourceReferenceProcessorRegistry present in DU attachment with key org.jboss.as.ee.component.Attachments.RESOURCE_REFERENCE_PROCESSOR_REGISTRY
>>
>> I don't know, I guess I'm running out of opinion on this.
>>
>> Here's a list of options:
>>
>> 1) Enhance naming subsystem to be able to bind java:comp, java:module,
>> java:app names, and put config in that subsystem (modify JMS and other
>> subsystems with implicit bindings to do the same)
>> 2) Enhance datasources subsystem to include a default datasource
>> attribute (== XML element) which, when present, will set up implicit
>> bindings for java:comp (and make sure that the config looks/acts
>> similarly between JMS, DS, and any other subsystem with implicit bindings)
>> 3) Decide it's all the EE subsystem and put implicit bindings in there
>>
>> Decision time: GO!
>>
>
>


--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] EE level java:comp/DefaultDataSource for WildFly 8...

Brian Stansberry
Ok, so that's a generic feature.  Seems like a scary generic capability
to me, but I'm not as familiar as you guys are with how these namespaces
work.

On 9/24/13 9:54 AM, David M. Lloyd wrote:

> I think it means the config will continue to work just as it does,
> except Jeff's error message won't happen anymore.  Bindings in
> non-global namespaces would materialize in every instance of that namespace.
>
> On 09/24/2013 09:50 AM, Brian Stansberry wrote:
>> 3) is confusing. If it's naming binding stuff, putting it in naming or
>> in the relevant subsystem seems more intuitive.
>>
>> What does 1) really mean in terms of config? Something generic? Or
>> something quite specific that results in the appropriate bindings?
>> Generic makes me nervous as it opens up a whole new broad feature with
>> many possible ways it could be broken.
>>
>> I like 1) better than 2) if my concern above can be addressed.
>>
>> On 9/24/13 9:12 AM, David M. Lloyd wrote:
>>> On 09/24/2013 05:14 AM, Eduardo Martins wrote:
>>>> Maybe we should create a doc with a reference design, since there are several default EE resources among our subsystems...
>>>>
>>>> IMHO default EE resources should be defined in the related subsystem configuration, otherwise the EE subsystem config will always be changing. In this case there should a configuration in the Datasources subsystem such as:
>>>>
>>>> <subsystem xmlns="urn:jboss:domain:datasources:2.0">
>>>>            <datasources>
>>>>             <default-datasource jndi-name="java:jboss/datasources/ExampleDS" />
>>>> <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
>>>> ...
>>>>        </datasource>
>>>>             ...
>>>>            </datasources>
>>>> </subsystem>
>>>>
>>>> For an easier/faster logic to find the default resource, and since we don't officially support linkref on jndi, the subsystem management op that adds the default resource (in this case default-datasource) should create a binder service pointing to a *fixed* jndi name (let's says java:jboss/ee/default/datasource) and inject it with the target resource (in this case the jndi name java:jboss/datasources/ExampleDS).
>>>>
>>>> Then the subsystem should provide a DUP that for EE modules do the required default bindings, in this case java:comp/DefaultDataSource and/or java:module/DefaultDataSource
>>>>
>>>> The subsystem then also needs to take care of the default mapping to the *fixed* jndi name from @Resource injection, this can be accomplished by adding a EEResourceReferenceProcessor to the EEResourceReferenceProcessorRegistry present in DU attachment with key org.jboss.as.ee.component.Attachments.RESOURCE_REFERENCE_PROCESSOR_REGISTRY
>>>
>>> I don't know, I guess I'm running out of opinion on this.
>>>
>>> Here's a list of options:
>>>
>>> 1) Enhance naming subsystem to be able to bind java:comp, java:module,
>>> java:app names, and put config in that subsystem (modify JMS and other
>>> subsystems with implicit bindings to do the same)
>>> 2) Enhance datasources subsystem to include a default datasource
>>> attribute (== XML element) which, when present, will set up implicit
>>> bindings for java:comp (and make sure that the config looks/acts
>>> similarly between JMS, DS, and any other subsystem with implicit bindings)
>>> 3) Decide it's all the EE subsystem and put implicit bindings in there
>>>
>>> Decision time: GO!
>>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12