datasource/connection-url reference to interfaces/ports

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

datasource/connection-url reference to interfaces/ports

Scott Stark
The datasource/connection-url property in the domain model is outside of
the interfaces and socket-binding-group usage. The current
datasource_1_0.xsd does not have a reference to sockets or interfaces.
We also don't seem to be setting jboss.server.* system properties that
could be used to create a configuration fragment like:


<datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="true"
use-java-context="true" pool-name="H2DS">
<connection-url>jdbc:mysql://${jboss.server.default.interface}:${jboss.server.socket-binding-group.mysql}/database</connection-url>
<driver>mysql</driver>
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
</datasource>

What is the plan to allow jca connection factories to integrate into the
interfaces/ports part of the domain model?

This came up as we add support for mysql in the openshift express
cartridge, and modification of the connection-url for the host the
server is running on requires changes in two parts of the standalone.xml
configuration rather than one.

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

Re: datasource/connection-url reference to interfaces/ports

Jaikiran Pai
I might be wrong, but isn't the socket-binding elements within the
standalone/domain xml meant to be only for the sockets opened within the
JBoss AS process and not for sockets opened by external processes (like
databases)?

-Jaikiran

On Tuesday 19 July 2011 02:01 AM, Scott Stark wrote:

> The datasource/connection-url property in the domain model is outside of
> the interfaces and socket-binding-group usage. The current
> datasource_1_0.xsd does not have a reference to sockets or interfaces.
> We also don't seem to be setting jboss.server.* system properties that
> could be used to create a configuration fragment like:
>
>
> <datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="true"
> use-java-context="true" pool-name="H2DS">
> <connection-url>jdbc:mysql://${jboss.server.default.interface}:${jboss.server.socket-binding-group.mysql}/database</connection-url>
> <driver>mysql</driver>
> <security>
> <user-name>sa</user-name>
> <password>sa</password>
> </security>
> </datasource>
>
> What is the plan to allow jca connection factories to integrate into the
> interfaces/ports part of the domain model?
>
> This came up as we add support for mysql in the openshift express
> cartridge, and modification of the connection-url for the host the
> server is running on requires changes in two parts of the standalone.xml
> configuration rather than one.
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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

Re: datasource/connection-url reference to interfaces/ports

Jesper Pedersen
In reply to this post by Scott Stark
On Monday, July 18, 2011 04:31:35 PM Scott Stark wrote:
> The datasource/connection-url property in the domain model is outside of
> the interfaces and socket-binding-group usage. The current
> datasource_1_0.xsd does not have a reference to sockets or interfaces.

No, as you know the connection url is built differently for each database, so
we would have to put in markers to substitute values.

> We also don't seem to be setting jboss.server.* system properties that
> could be used to create a configuration fragment like:
>
> <datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="true"
> use-java-context="true" pool-name="H2DS">
> <connection-url>jdbc:mysql://${jboss.server.default.interface}:${jboss.serv
> er.socket-binding-group.mysql}/database</connection-url>
> <driver>mysql</driver>
> <security>
> <user-name>sa</user-name>
> <password>sa</password>
> </security>
> </datasource>
>
> What is the plan to allow jca connection factories to integrate into the
> interfaces/ports part of the domain model?
>
> This came up as we add support for mysql in the openshift express
> cartridge, and modification of the connection-url for the host the
> server is running on requires changes in two parts of the standalone.xml
> configuration rather than one.

System property substitution works on all elements/attributes in the
datasource definition. So I think it is a matter of finding out which
elements/attributes we want to expose as system properties in the domain
model.

Maybe even define them as system properties in the first place and then use
those values in the various subsystems. Others can comment on that idea.

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

Re: datasource/connection-url reference to interfaces/ports

Scott Stark
In reply to this post by Jaikiran Pai
Possibly, but it is just metadata that can be used to capture resource
usage. In this particular usecase, the server's interfaces due dictate
what values other jca services are listening on. In the future if we get
into n-tier deployments that would not be the case, but then you still
need an inventory of what the point to point connection endpoints are.
The admin needs some way to define tier interfaces, and configure the
connections between them. I would think we would do this via the
interfaces and socket-binding-group metadata.


On 7/19/11 6:32 AM, Jaikiran Pai wrote:
> I might be wrong, but isn't the socket-binding elements within the
> standalone/domain xml meant to be only for the sockets opened within the
> JBoss AS process and not for sockets opened by external processes (like
> databases)?
>
> -Jaikiran
>

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

Re: datasource/connection-url reference to interfaces/ports

Scott Stark
In reply to this post by Jesper Pedersen
So combining Jaikiran's and Jesper's posts, the connection-url is
different from the existing interface/socket binding group usage in that
there may not be a service in the server which is providing the socket
binding. This is a possibly external/remote endpoint that still should
be captured in the domain metadata as I would want a comprehensive view
of the endpoints in use in the domain.

Right now it sounds like how I can capture this would be to define
system properties and then reference them in the connection-url.

On 7/19/11 10:24 AM, Jesper Pedersen wrote:

> On Monday, July 18, 2011 04:31:35 PM Scott Stark wrote:
>> The datasource/connection-url property in the domain model is outside of
>> the interfaces and socket-binding-group usage. The current
>> datasource_1_0.xsd does not have a reference to sockets or interfaces.
> No, as you know the connection url is built differently for each database, so
> we would have to put in markers to substitute values.
>
>> We also don't seem to be setting jboss.server.* system properties that
>> could be used to create a configuration fragment like:
>>
>> <datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="true"
>> use-java-context="true" pool-name="H2DS">
>> <connection-url>jdbc:mysql://${jboss.server.default.interface}:${jboss.serv
>> er.socket-binding-group.mysql}/database</connection-url>
>> <driver>mysql</driver>
>> <security>
>> <user-name>sa</user-name>
>> <password>sa</password>
>> </security>
>> </datasource>
>>
>> What is the plan to allow jca connection factories to integrate into the
>> interfaces/ports part of the domain model?
>>
>> This came up as we add support for mysql in the openshift express
>> cartridge, and modification of the connection-url for the host the
>> server is running on requires changes in two parts of the standalone.xml
>> configuration rather than one.
> System property substitution works on all elements/attributes in the
> datasource definition. So I think it is a matter of finding out which
> elements/attributes we want to expose as system properties in the domain
> model.
>
> Maybe even define them as system properties in the first place and then use
> those values in the various subsystems. Others can comment on that idea.
>
> Best regards,
>   Jesper
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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

Re: datasource/connection-url reference to interfaces/ports

Emanuel Muckenhuber

I think that's a valid point. Having a comprehensive view and consistent
configuration mechanism for ports was the underlying use-case and
motivation behind the socket-bindings.

Although i agree that what we have does not really seem to good fit for
describing something like datasource connection. If this is something we
would like to do, we can perhaps look into extending the socket-binding
concepts?

On 07/19/2011 08:28 PM, Scott Stark wrote:

> So combining Jaikiran's and Jesper's posts, the connection-url is
> different from the existing interface/socket binding group usage in that
> there may not be a service in the server which is providing the socket
> binding. This is a possibly external/remote endpoint that still should
> be captured in the domain metadata as I would want a comprehensive view
> of the endpoints in use in the domain.
>
> Right now it sounds like how I can capture this would be to define
> system properties and then reference them in the connection-url.
>
> On 7/19/11 10:24 AM, Jesper Pedersen wrote:
>> On Monday, July 18, 2011 04:31:35 PM Scott Stark wrote:
>>> The datasource/connection-url property in the domain model is outside of
>>> the interfaces and socket-binding-group usage. The current
>>> datasource_1_0.xsd does not have a reference to sockets or interfaces.
>> No, as you know the connection url is built differently for each database, so
>> we would have to put in markers to substitute values.
>>
>>> We also don't seem to be setting jboss.server.* system properties that
>>> could be used to create a configuration fragment like:
>>>
>>> <datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="true"
>>> use-java-context="true" pool-name="H2DS">
>>> <connection-url>jdbc:mysql://${jboss.server.default.interface}:${jboss.serv
>>> er.socket-binding-group.mysql}/database</connection-url>
>>> <driver>mysql</driver>
>>> <security>
>>> <user-name>sa</user-name>
>>> <password>sa</password>
>>> </security>
>>> </datasource>
>>>
>>> What is the plan to allow jca connection factories to integrate into the
>>> interfaces/ports part of the domain model?
>>>
>>> This came up as we add support for mysql in the openshift express
>>> cartridge, and modification of the connection-url for the host the
>>> server is running on requires changes in two parts of the standalone.xml
>>> configuration rather than one.
>> System property substitution works on all elements/attributes in the
>> datasource definition. So I think it is a matter of finding out which
>> elements/attributes we want to expose as system properties in the domain
>> model.
>>
>> Maybe even define them as system properties in the first place and then use
>> those values in the various subsystems. Others can comment on that idea.
>>
>> Best regards,
>>    Jesper
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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

Re: datasource/connection-url reference to interfaces/ports

Brian Stansberry
A tricky thing to deal with is interfaces and socket bindings are
actually on-demand services. They aren't resolved until they are
demanded. Nothing in this connection-url scenario would demand the
socket binding, so it won't be resolved, and until it's resolved no
system property could be set.

That could be handled by adding an "auto-start" attribute on the
socket-binding config. Not particularly intuitive though.

Another thing to deal with is interface resolution. With the exception
of the "<loopback address="127.0.0.4"/> criteria Scott added, resolving
an interface means finding a NIC on the machine that matches the
criteria. If that can't be done, it's an error condition. To avoid that
there would need to be some new criteria added (e.g.
<remote-inet-address value="10.0.0.53"/>) or an attribute added to the
existing inet-address criteria (e.g. <inet-address value="10.0.0.53"
local="false"/>.

A minor issue relates to changing the configuration of a socket binding.
Basically, we try and track whether you've used a particular
SocketBinding service to open a socket; if not we let you change the
binding config without requiring a server restart or reload. This
connection-url stuff won't use the SocketBinding service to create a
socket, so the binding will be editable at runtime with no
reload/restart required. But there's no dependency relationship between
the binding and the datasource, so that change is not going to be
reflected in the datasource. This is just an example of the general
problem with using system properties as an injection mechanism.

I don't think this last point is a blocker, it just requires documentation.

On 7/20/11 6:36 AM, Emanuel Muckenhuber wrote:

>
> I think that's a valid point. Having a comprehensive view and consistent
> configuration mechanism for ports was the underlying use-case and
> motivation behind the socket-bindings.
>
> Although i agree that what we have does not really seem to good fit for
> describing something like datasource connection. If this is something we
> would like to do, we can perhaps look into extending the socket-binding
> concepts?
>
> On 07/19/2011 08:28 PM, Scott Stark wrote:
>> So combining Jaikiran's and Jesper's posts, the connection-url is
>> different from the existing interface/socket binding group usage in that
>> there may not be a service in the server which is providing the socket
>> binding. This is a possibly external/remote endpoint that still should
>> be captured in the domain metadata as I would want a comprehensive view
>> of the endpoints in use in the domain.
>>
>> Right now it sounds like how I can capture this would be to define
>> system properties and then reference them in the connection-url.
>>
>> On 7/19/11 10:24 AM, Jesper Pedersen wrote:
>>> On Monday, July 18, 2011 04:31:35 PM Scott Stark wrote:
>>>> The datasource/connection-url property in the domain model is outside of
>>>> the interfaces and socket-binding-group usage. The current
>>>> datasource_1_0.xsd does not have a reference to sockets or interfaces.
>>> No, as you know the connection url is built differently for each database, so
>>> we would have to put in markers to substitute values.
>>>
>>>> We also don't seem to be setting jboss.server.* system properties that
>>>> could be used to create a configuration fragment like:
>>>>
>>>> <datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="true"
>>>> use-java-context="true" pool-name="H2DS">
>>>> <connection-url>jdbc:mysql://${jboss.server.default.interface}:${jboss.serv
>>>> er.socket-binding-group.mysql}/database</connection-url>
>>>> <driver>mysql</driver>
>>>> <security>
>>>> <user-name>sa</user-name>
>>>> <password>sa</password>
>>>> </security>
>>>> </datasource>
>>>>
>>>> What is the plan to allow jca connection factories to integrate into the
>>>> interfaces/ports part of the domain model?
>>>>
>>>> This came up as we add support for mysql in the openshift express
>>>> cartridge, and modification of the connection-url for the host the
>>>> server is running on requires changes in two parts of the standalone.xml
>>>> configuration rather than one.
>>> System property substitution works on all elements/attributes in the
>>> datasource definition. So I think it is a matter of finding out which
>>> elements/attributes we want to expose as system properties in the domain
>>> model.
>>>
>>> Maybe even define them as system properties in the first place and then use
>>> those values in the various subsystems. Others can comment on that idea.
>>>
>>> Best regards,
>>>     Jesper
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


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

Re: datasource/connection-url reference to interfaces/ports

Brian Stansberry
I've opened two JIRAs related to this:

https://issues.jboss.org/browse/AS7-1614
https://issues.jboss.org/browse/AS7-1615

On 7/20/11 12:28 PM, Brian Stansberry wrote:

> A tricky thing to deal with is interfaces and socket bindings are
> actually on-demand services. They aren't resolved until they are
> demanded. Nothing in this connection-url scenario would demand the
> socket binding, so it won't be resolved, and until it's resolved no
> system property could be set.
>
> That could be handled by adding an "auto-start" attribute on the
> socket-binding config. Not particularly intuitive though.
>
> Another thing to deal with is interface resolution. With the exception
> of the "<loopback address="127.0.0.4"/>  criteria Scott added, resolving
> an interface means finding a NIC on the machine that matches the
> criteria. If that can't be done, it's an error condition. To avoid that
> there would need to be some new criteria added (e.g.
> <remote-inet-address value="10.0.0.53"/>) or an attribute added to the
> existing inet-address criteria (e.g.<inet-address value="10.0.0.53"
> local="false"/>.
>
> A minor issue relates to changing the configuration of a socket binding.
> Basically, we try and track whether you've used a particular
> SocketBinding service to open a socket; if not we let you change the
> binding config without requiring a server restart or reload. This
> connection-url stuff won't use the SocketBinding service to create a
> socket, so the binding will be editable at runtime with no
> reload/restart required. But there's no dependency relationship between
> the binding and the datasource, so that change is not going to be
> reflected in the datasource. This is just an example of the general
> problem with using system properties as an injection mechanism.
>
> I don't think this last point is a blocker, it just requires documentation.
>
> On 7/20/11 6:36 AM, Emanuel Muckenhuber wrote:
>>
>> I think that's a valid point. Having a comprehensive view and consistent
>> configuration mechanism for ports was the underlying use-case and
>> motivation behind the socket-bindings.
>>
>> Although i agree that what we have does not really seem to good fit for
>> describing something like datasource connection. If this is something we
>> would like to do, we can perhaps look into extending the socket-binding
>> concepts?
>>
>> On 07/19/2011 08:28 PM, Scott Stark wrote:
>>> So combining Jaikiran's and Jesper's posts, the connection-url is
>>> different from the existing interface/socket binding group usage in that
>>> there may not be a service in the server which is providing the socket
>>> binding. This is a possibly external/remote endpoint that still should
>>> be captured in the domain metadata as I would want a comprehensive view
>>> of the endpoints in use in the domain.
>>>
>>> Right now it sounds like how I can capture this would be to define
>>> system properties and then reference them in the connection-url.
>>>
>>> On 7/19/11 10:24 AM, Jesper Pedersen wrote:
>>>> On Monday, July 18, 2011 04:31:35 PM Scott Stark wrote:
>>>>> The datasource/connection-url property in the domain model is outside of
>>>>> the interfaces and socket-binding-group usage. The current
>>>>> datasource_1_0.xsd does not have a reference to sockets or interfaces.
>>>> No, as you know the connection url is built differently for each database, so
>>>> we would have to put in markers to substitute values.
>>>>
>>>>> We also don't seem to be setting jboss.server.* system properties that
>>>>> could be used to create a configuration fragment like:
>>>>>
>>>>> <datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="true"
>>>>> use-java-context="true" pool-name="H2DS">
>>>>> <connection-url>jdbc:mysql://${jboss.server.default.interface}:${jboss.serv
>>>>> er.socket-binding-group.mysql}/database</connection-url>
>>>>> <driver>mysql</driver>
>>>>> <security>
>>>>> <user-name>sa</user-name>
>>>>> <password>sa</password>
>>>>> </security>
>>>>> </datasource>
>>>>>
>>>>> What is the plan to allow jca connection factories to integrate into the
>>>>> interfaces/ports part of the domain model?
>>>>>
>>>>> This came up as we add support for mysql in the openshift express
>>>>> cartridge, and modification of the connection-url for the host the
>>>>> server is running on requires changes in two parts of the standalone.xml
>>>>> configuration rather than one.
>>>> System property substitution works on all elements/attributes in the
>>>> datasource definition. So I think it is a matter of finding out which
>>>> elements/attributes we want to expose as system properties in the domain
>>>> model.
>>>>
>>>> Maybe even define them as system properties in the first place and then use
>>>> those values in the various subsystems. Others can comment on that idea.
>>>>
>>>> Best regards,
>>>>      Jesper
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


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