11:23 a.m.
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
5:33 a.m.
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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
7:30 a.m.
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
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:01 a.m.
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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:04 a.m.
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
10:11 a.m.
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
10:14 a.m.
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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:19 a.m.
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
10:31 a.m.
On 23 Sep 2013, at 17:14, Jaikiran Pai <jpai(a)redhat.com> 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/or...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
10:38 a.m.
On 09/23/2013 10:31 AM, Jeff Mesnil wrote:
On 23 Sep 2013, at 17:14, Jaikiran Pai <jpai(a)redhat.com> 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
2:37 a.m.
On 23 Sep 2013, at 17:38, "David M. Lloyd" <david.lloyd(a)redhat.com>
wrote:
On 09/23/2013 10:31 AM, Jeff Mesnil wrote:
>
> On 23 Sep 2013, at 17:14, Jaikiran Pai <jpai(a)redhat.com> 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/
5:14 a.m.
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
9:12 a.m.
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
9:28 a.m.
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" <david.lloyd(a)redhat.com>
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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:35 a.m.
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 <david.lloyd(a)redhat.com>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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:42 a.m.
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 <tomaz.cerar(a)gmail.com> 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 <david.lloyd(a)redhat.com> 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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:41 a.m.
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" <david.lloyd(a)redhat.com> 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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:50 a.m.
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
9:54 a.m.
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
10 a.m.
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
1:03 p.m.
+1
There are two other concerns I have with 3):
1) EE binds are done at java:comp or java:module, depending on module/component. Generic
blind binding in every instance of a namespace may not be an option for the EE default
bindings.
2) Overridden of defaults through jboss app and jboss component xml descriptors, something
I have planned for EE Concurrency default binds, may be much more complex to achieve.
I still like the feature, but think it will not help that much for handling EE default
bindings.
--E
On Sep 24, 2013, at 4:00 PM, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
1:11 p.m.
Should be "There are two other concerns I have with 1):".
--E
On Sep 24, 2013, at 7:03 PM, Eduardo Martins <emartins(a)redhat.com> wrote:
+1
There are two other concerns I have with 3):
1) EE binds are done at java:comp or java:module, depending on module/component. Generic
blind binding in every instance of a namespace may not be an option for the EE default
bindings.
2) Overridden of defaults through jboss app and jboss component xml descriptors,
something I have planned for EE Concurrency default binds, may be much more complex to
achieve.
I still like the feature, but think it will not help that much for handling EE default
bindings.
--E
On Sep 24, 2013, at 4:00 PM, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
> 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
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
1:27 p.m.
On 09/24/2013 01:03 PM, Eduardo Martins wrote:
+1
There are two other concerns I have with 3):
1) EE binds are done at java:comp or java:module, depending on module/component. Generic
blind binding in every instance of a namespace may not be an option for the EE default
bindings.
I believe this statement to be patently false. The only case this might
be true is WARs - but in a WAR, java:comp is just an alias for
java:module so the same logic will always work in either case. Now it
may in fact be possible to create a conflicting binding, but that's a
different problem.
2) Overridden of defaults through jboss app and jboss component xml
descriptors, something I have planned for EE Concurrency default binds, may be much more
complex to achieve.
Let's just take one step at a time OK? :-)
I still like the feature, but think it will not help that much for
handling EE default bindings.
--E
On Sep 24, 2013, at 4:00 PM, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
> 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
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML
2:13 p.m.
On Sep 24, 2013, at 7:27 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
On 09/24/2013 01:03 PM, Eduardo Martins wrote:
> +1
>
> There are two other concerns I have with 3):
>
> 1) EE binds are done at java:comp or java:module, depending on module/component.
Generic blind binding in every instance of a namespace may not be an option for the EE
default bindings.
I believe this statement to be patently false. The only case this might
be true is WARs - but in a WAR, java:comp is just an alias for
java:module so the same logic will always work in either case. Now it
may in fact be possible to create a conflicting binding, but that's a
different problem.
I wonder what in my statement is false :-)
Anyway, such conflict is why I said the generic blind bind may not be an option, since for
components where java:comp is not the same as java:module we should not bind at
java:module too. Obviously one could ask what would be the chance of we ever need to care
about it...
> 2) Overridden of defaults through jboss app and jboss component xml descriptors,
something I have planned for EE Concurrency default binds, may be much more complex to
achieve.
Let's just take one step at a time OK? :-)
I think we should cover all features we plan to have related with this change, otherwise
we may end up changing configs in multiple subsystems, which bring new schemas,
transformers, test code etc.
--E
11:15 a.m.
Forget these 2 concerns, there is a way to easily get around both. Personally I think I we
could go with 1) or 3) since that allows a single logic to be applied to all. 1) has the
advantage of not needing any change in subsystem configs (just the impl in naming
changes), while 3) has the advantage of not opening the door to wild hacks.
Time for a final decision?
--E
On Sep 24, 2013, at 8:13 PM, Eduardo Martins <emartins(a)redhat.com> wrote:
On Sep 24, 2013, at 7:27 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
> On 09/24/2013 01:03 PM, Eduardo Martins wrote:
>> +1
>>
>> There are two other concerns I have with 3):
>>
>> 1) EE binds are done at java:comp or java:module, depending on module/component.
Generic blind binding in every instance of a namespace may not be an option for the EE
default bindings.
>
> I believe this statement to be patently false. The only case this might
> be true is WARs - but in a WAR, java:comp is just an alias for
> java:module so the same logic will always work in either case. Now it
> may in fact be possible to create a conflicting binding, but that's a
> different problem.
I wonder what in my statement is false :-)
Anyway, such conflict is why I said the generic blind bind may not be an option, since
for components where java:comp is not the same as java:module we should not bind at
java:module too. Obviously one could ask what would be the chance of we ever need to care
about it...
>
>> 2) Overridden of defaults through jboss app and jboss component xml descriptors,
something I have planned for EE Concurrency default binds, may be much more complex to
achieve.
>
> Let's just take one step at a time OK? :-)
I think we should cover all features we plan to have related with this change, otherwise
we may end up changing configs in multiple subsystems, which bring new schemas,
transformers, test code etc.
--E
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
8:50 a.m.
I think the biggest risk is that those namespaces are reserved. For that reason, we
ourselves would never include a configuration for anything non standard. We could restrict
the possible bind locations though, or perhaps log a warning. Although that seems to make
the feature seem like a hack.
The more I think about it the more I think option two is better; however, we don't
have to use implicit bindings. We could just add the following optional element to the EE
subsystem:
<default-bindings datasource="java:jboss/blah"
jms-conenction-factory=""/>
On Sep 24, 2013, at 10:00 AM, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
12:19 p.m.
On Sep 25, 2013, at 8:50 AM, Jason Greene <jason.greene(a)redhat.com> wrote:
I think the biggest risk is that those namespaces are reserved. For
that reason, we ourselves would never include a configuration for anything non standard.
We could restrict the possible bind locations though, or perhaps log a warning. Although
that seems to make the feature seem like a hack.
The more I think about it the more I think option two is better; however, we don't
have to use implicit bindings. We could just add the following optional element to the EE
subsystem:
<default-bindings datasource="java:jboss/blah"
jms-conenction-factory=""/>
s/two/three
On Sep 24, 2013, at 10:00 AM, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
> 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
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
1:47 p.m.
I created https://issues.jboss.org/browse/WFLY-2158 to track this, and linked the existent
issue for the default datasource, but one question, are we targeting this for BETA1? If
not perhaps I could do branches for 1) and 3) so everyone could review something concrete,
or note something that is missing in this discussion.
--E
On Sep 25, 2013, at 6:35 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
On Wed, Sep 25, 2013 at 7:19 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
s/two/three
so 3 it is :)
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
6:46 a.m.
FYI submitted PR with option 3). Note that this PR handles all 6 default resources I am
aware at Java EE 7.
https://github.com/wildfly/wildfly/pull/5176
--E
On Sep 25, 2013, at 7:47 PM, Eduardo Martins <emartins(a)redhat.com> wrote:
I created https://issues.jboss.org/browse/WFLY-2158 to track this,
and linked the existent issue for the default datasource, but one question, are we
targeting this for BETA1? If not perhaps I could do branches for 1) and 3) so everyone
could review something concrete, or note something that is missing in this discussion.
--E
On Sep 25, 2013, at 6:35 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
>
> On Wed, Sep 25, 2013 at 7:19 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
> s/two/three
>
> so 3 it is :)
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:03 a.m.
It's naming, but wrt another spec in EE, so I think it makes sense that whatever is
configurable wrt EE spec integration is promoted by the EE subsystem. Still I understand
that such functionality could be reused for something else if we add an option to rebind
anything into java:comp or java:module, if it goes to naming subsystem.
--E
On Sep 24, 2013, at 3:50 PM, Brian Stansberry <brian.stansberry(a)redhat.com> 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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3858
days inactive
3879
days old
30 comments
11 participants
participants (11)
-
Brian Stansberry -
David M. Lloyd -
Eduardo Martins -
Jaikiran Pai -
Jason Greene -
Jeff Mesnil -
Jesper Pedersen -
Max Rydahl Andersen -
Scott Marlow -
Stuart Douglas -
Tomaž Cerar