(XA)Datasources subresources and use cases

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

(XA)Datasources subresources and use cases

Stefano Maestri
Hi all,

I've recently worked on adding subresources for configuration properties
to resource-adapters and now I'm working on datasources and xa-datasources.
While a pure subresources approach is working out of the box for RAs,
since add operations work only on DMR and services and runtime metadata
information are created during rar deployment, it's not the same for
(xa)DS. Here add operation effectively deploy the datasources, so adding
properties as subresources comes after effective deployment.
IOW the subresources can't be used during runtime creation of a
datasource, but only during parsing. Having connection-properties and
xa-datasource-properties as subresources should make easier and more
standard to add/remove them.

Since currently we are supporting datasource creation from console and
cli and since I think it's a wanted feature I have a proposal to make it
possible also with subresources.

Basically the idea is to use the current enable/disable status to make
possible to edit a datasource. Datasource are always created disabled
(boolean parameter enable will be removed from add operation), and
permit to add/remove subresource in this status. Then console/cli have
to enable the datasource making it available and registered in jndi.
It's not possible to edit a datasource enabled, it must be disabled
first. Of course this approach could be extended not only to
subresources, but also to all editable field that currently require a
server reload.

comments or problem you can see in this approach?

regards
S.
_______________________________________________
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: (XA)Datasources subresources and use cases

Stefano Maestri
I was forgetting:
of course parser will take care of all the steps
     parse->create ds disabled->add subresources->enable ds
making it invisible to users.

regards
S.
On 10/20/2011 01:47 PM, Stefano Maestri wrote:

> Hi all,
>
> I've recently worked on adding subresources for configuration properties
> to resource-adapters and now I'm working on datasources and xa-datasources.
> While a pure subresources approach is working out of the box for RAs,
> since add operations work only on DMR and services and runtime metadata
> information are created during rar deployment, it's not the same for
> (xa)DS. Here add operation effectively deploy the datasources, so adding
> properties as subresources comes after effective deployment.
> IOW the subresources can't be used during runtime creation of a
> datasource, but only during parsing. Having connection-properties and
> xa-datasource-properties as subresources should make easier and more
> standard to add/remove them.
>
> Since currently we are supporting datasource creation from console and
> cli and since I think it's a wanted feature I have a proposal to make it
> possible also with subresources.
>
> Basically the idea is to use the current enable/disable status to make
> possible to edit a datasource. Datasource are always created disabled
> (boolean parameter enable will be removed from add operation), and
> permit to add/remove subresource in this status. Then console/cli have
> to enable the datasource making it available and registered in jndi.
> It's not possible to edit a datasource enabled, it must be disabled
> first. Of course this approach could be extended not only to
> subresources, but also to all editable field that currently require a
> server reload.
>
> comments or problem you can see in this approach?
>
> regards
> S.
> _______________________________________________
> 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: (XA)Datasources subresources and use cases

Heiko Braun
In reply to this post by Stefano Maestri


+1

On Oct 20, 2011, at 1:47 PM, Stefano Maestri wrote:

> Hi all,
>
> I've recently worked on adding subresources for configuration properties
> to resource-adapters and now I'm working on datasources and xa-datasources.
> While a pure subresources approach is working out of the box for RAs,
> since add operations work only on DMR and services and runtime metadata
> information are created during rar deployment, it's not the same for
> (xa)DS. Here add operation effectively deploy the datasources, so adding
> properties as subresources comes after effective deployment.
> IOW the subresources can't be used during runtime creation of a
> datasource, but only during parsing. Having connection-properties and
> xa-datasource-properties as subresources should make easier and more
> standard to add/remove them.
>
> Since currently we are supporting datasource creation from console and
> cli and since I think it's a wanted feature I have a proposal to make it
> possible also with subresources.
>
> Basically the idea is to use the current enable/disable status to make
> possible to edit a datasource. Datasource are always created disabled
> (boolean parameter enable will be removed from add operation), and
> permit to add/remove subresource in this status. Then console/cli have
> to enable the datasource making it available and registered in jndi.
> It's not possible to edit a datasource enabled, it must be disabled
> first. Of course this approach could be extended not only to
> subresources, but also to all editable field that currently require a
> server reload.
>
> comments or problem you can see in this approach?
>
> regards
> S.
> _______________________________________________
> 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: (XA)Datasources subresources and use cases

Brian Stansberry
In reply to this post by Stefano Maestri
This sounds fine.

On 10/20/11 6:53 AM, Stefano Maestri wrote:

> I was forgetting:
> of course parser will take care of all the steps
>       parse->create ds disabled->add subresources->enable ds
> making it invisible to users.
>
> regards
> S.
> On 10/20/2011 01:47 PM, Stefano Maestri wrote:
>> Hi all,
>>
>> I've recently worked on adding subresources for configuration properties
>> to resource-adapters and now I'm working on datasources and xa-datasources.
>> While a pure subresources approach is working out of the box for RAs,
>> since add operations work only on DMR and services and runtime metadata
>> information are created during rar deployment, it's not the same for
>> (xa)DS. Here add operation effectively deploy the datasources, so adding
>> properties as subresources comes after effective deployment.
>> IOW the subresources can't be used during runtime creation of a
>> datasource, but only during parsing. Having connection-properties and
>> xa-datasource-properties as subresources should make easier and more
>> standard to add/remove them.
>>
>> Since currently we are supporting datasource creation from console and
>> cli and since I think it's a wanted feature I have a proposal to make it
>> possible also with subresources.
>>
>> Basically the idea is to use the current enable/disable status to make
>> possible to edit a datasource. Datasource are always created disabled
>> (boolean parameter enable will be removed from add operation), and
>> permit to add/remove subresource in this status. Then console/cli have
>> to enable the datasource making it available and registered in jndi.
>> It's not possible to edit a datasource enabled, it must be disabled
>> first. Of course this approach could be extended not only to
>> subresources, but also to all editable field that currently require a
>> server reload.
>>
>> comments or problem you can see in this approach?
>>
>> regards
>> S.
>> _______________________________________________
>> 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