[jboss-as7-dev] 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
>>>> jboss-as7-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat