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 jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev