adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime

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

adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime

Scott Marlow
Hi,

We will soon add several (nested) NoSQL configuration settings.  Before
we do that, I would like some feedback on the current NoSQL subsystem
code that reads connection settings.

Any major corrections that you can suggest for the NoSQL subsystem code
[1][2]?  Especially, the
MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
methods.

Should we continue to read all of the configuration settings from one
AddStepHandler or should we do that differently (perhaps with separate
AbstractAddStepHandler's)?

Thanks,
Scott

[1]
https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra

[2]
https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime

Brian Stansberry
Can a new profile be added post-boot without requiring a reload to take
effect? If yes, the add handler for the profile resource should do the
service installation for that profile. It shouldn't count on the parent
to do it, as the parent logic will only execute during boot.

BTW, if post-boot profile adds/removes don't require reload, then [1]
should not be inside the "if
(mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block? Same
question applies for the cassandra add handler.

[1]
https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124

On 5/26/16 3:02 PM, Scott Marlow wrote:

> Hi,
>
> We will soon add several (nested) NoSQL configuration settings.  Before
> we do that, I would like some feedback on the current NoSQL subsystem
> code that reads connection settings.
>
> Any major corrections that you can suggest for the NoSQL subsystem code
> [1][2]?  Especially, the
> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
> methods.
>
> Should we continue to read all of the configuration settings from one
> AddStepHandler or should we do that differently (perhaps with separate
> AbstractAddStepHandler's)?
>
> Thanks,
> Scott
>
> [1]
> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>
> [2]
> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


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

Re: adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime

Scott Marlow


On 05/27/2016 09:33 AM, Brian Stansberry wrote:
> Can a new profile be added post-boot without requiring a reload to take
> effect? If yes, the add handler for the profile resource should do the
> service installation for that profile. It shouldn't count on the parent
> to do it, as the parent logic will only execute during boot.

I like the idea of adding a new profile post-boot, without requiring a
reload of all of the profiles defined by the MongoDB/Cassandra subsystem.

Currently, the standalone*.xml might contain:

<subsystem xmlns="urn:jboss:domain:mongodb:1.0">
   <mongo name="default" id="mongodbtestprofile"
jndi-name="java:jboss/mongodb/test" database="mongotestdb">
     <host name="default" outbound-socket-binding-ref="mongotesthost"/>
   </mongo>
   <mongo name="default2" id="mongodbdiary"
jndi-name="java:jboss/mongodb/diary" database="diarydb">
     <host name="default" outbound-socket-binding-ref="mongotesthost"/>
   </mongo>
</subsystem>

If the user wants to add an additional profile to the mongodb subsystem,
I think it would be worth us making the code changes to allow that.
Will be great to add a new "otherDB", without stopping the existing
database profiles.

For supporting "remove" of an existing profile, I think that we will
need dependencies added on the underlying
MongoDriverService/CassandraDriverService, will be very worthwhile to
have that as well!  Great feedback! :-)

>
> BTW, if post-boot profile adds/removes don't require reload, then [1]
> should not be inside the "if
> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block?

Makes sense, looks like we need a remove handler also for the profile
resource.

> Same
> question applies for the cassandra add handler.

We should change the cassandra add handler also.

Thanks again,
Scott

>
> [1]
> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124
>
> On 5/26/16 3:02 PM, Scott Marlow wrote:
>> Hi,
>>
>> We will soon add several (nested) NoSQL configuration settings.  Before
>> we do that, I would like some feedback on the current NoSQL subsystem
>> code that reads connection settings.
>>
>> Any major corrections that you can suggest for the NoSQL subsystem code
>> [1][2]?  Especially, the
>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
>> methods.
>>
>> Should we continue to read all of the configuration settings from one
>> AddStepHandler or should we do that differently (perhaps with separate
>> AbstractAddStepHandler's)?
>>
>> Thanks,
>> Scott
>>
>> [1]
>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>>
>> [2]
>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime

Scott Marlow


On 05/27/2016 10:19 AM, Scott Marlow wrote:

>
>
> On 05/27/2016 09:33 AM, Brian Stansberry wrote:
>> Can a new profile be added post-boot without requiring a reload to take
>> effect? If yes, the add handler for the profile resource should do the
>> service installation for that profile. It shouldn't count on the parent
>> to do it, as the parent logic will only execute during boot.
>
> I like the idea of adding a new profile post-boot, without requiring a
> reload of all of the profiles defined by the MongoDB/Cassandra subsystem.

I need to back up on my response.  What does it mean for adding a new
profile without requiring a reload?  Does that require a hot change to
the NoSQL profile service without undeploying the application?

>
> Currently, the standalone*.xml might contain:
>
> <subsystem xmlns="urn:jboss:domain:mongodb:1.0">
>    <mongo name="default" id="mongodbtestprofile"
> jndi-name="java:jboss/mongodb/test" database="mongotestdb">
>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>    </mongo>
>    <mongo name="default2" id="mongodbdiary"
> jndi-name="java:jboss/mongodb/diary" database="diarydb">
>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>    </mongo>
> </subsystem>
>
> If the user wants to add an additional profile to the mongodb subsystem,
> I think it would be worth us making the code changes to allow that.
> Will be great to add a new "otherDB", without stopping the existing
> database profiles.
>
> For supporting "remove" of an existing profile, I think that we will
> need dependencies added on the underlying
> MongoDriverService/CassandraDriverService, will be very worthwhile to
> have that as well!  Great feedback! :-)
>
>>
>> BTW, if post-boot profile adds/removes don't require reload, then [1]
>> should not be inside the "if
>> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block?
>
> Makes sense, looks like we need a remove handler also for the profile
> resource.
>
>> Same
>> question applies for the cassandra add handler.
>
> We should change the cassandra add handler also.
>
> Thanks again,
> Scott
>
>>
>> [1]
>> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124
>>
>> On 5/26/16 3:02 PM, Scott Marlow wrote:
>>> Hi,
>>>
>>> We will soon add several (nested) NoSQL configuration settings.  Before
>>> we do that, I would like some feedback on the current NoSQL subsystem
>>> code that reads connection settings.
>>>
>>> Any major corrections that you can suggest for the NoSQL subsystem code
>>> [1][2]?  Especially, the
>>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
>>> methods.
>>>
>>> Should we continue to read all of the configuration settings from one
>>> AddStepHandler or should we do that differently (perhaps with separate
>>> AbstractAddStepHandler's)?
>>>
>>> Thanks,
>>> Scott
>>>
>>> [1]
>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>>>
>>> [2]
>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime

Scott Marlow

On 05/31/2016 04:48 PM, Scott Marlow wrote:

>
>
> On 05/27/2016 10:19 AM, Scott Marlow wrote:
>>
>>
>> On 05/27/2016 09:33 AM, Brian Stansberry wrote:
>>> Can a new profile be added post-boot without requiring a reload to take
>>> effect? If yes, the add handler for the profile resource should do the
>>> service installation for that profile. It shouldn't count on the parent
>>> to do it, as the parent logic will only execute during boot.
>>
>> I like the idea of adding a new profile post-boot, without requiring a
>> reload of all of the profiles defined by the MongoDB/Cassandra subsystem.
>
> I need to back up on my response.  What does it mean for adding a new
> profile without requiring a reload?  Does that require a hot change to
> the NoSQL profile service without undeploying the application?

After refreshing on
https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-applyingruntimeupdates,
I think currently, we should specify that a reload (all-services) is
needed when adding/removing profiles.

>
>>
>> Currently, the standalone*.xml might contain:
>>
>> <subsystem xmlns="urn:jboss:domain:mongodb:1.0">
>>    <mongo name="default" id="mongodbtestprofile"
>> jndi-name="java:jboss/mongodb/test" database="mongotestdb">
>>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>>    </mongo>
>>    <mongo name="default2" id="mongodbdiary"
>> jndi-name="java:jboss/mongodb/diary" database="diarydb">
>>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>>    </mongo>
>> </subsystem>
>>
>> If the user wants to add an additional profile to the mongodb subsystem,
>> I think it would be worth us making the code changes to allow that.
>> Will be great to add a new "otherDB", without stopping the existing
>> database profiles.
>>
>> For supporting "remove" of an existing profile, I think that we will
>> need dependencies added on the underlying
>> MongoDriverService/CassandraDriverService, will be very worthwhile to
>> have that as well!  Great feedback! :-)
>>
>>>
>>> BTW, if post-boot profile adds/removes don't require reload, then [1]
>>> should not be inside the "if
>>> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block?
>>
>> Makes sense, looks like we need a remove handler also for the profile
>> resource.
>>
>>> Same
>>> question applies for the cassandra add handler.
>>
>> We should change the cassandra add handler also.
>>
>> Thanks again,
>> Scott
>>
>>>
>>> [1]
>>> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124
>>>
>>> On 5/26/16 3:02 PM, Scott Marlow wrote:
>>>> Hi,
>>>>
>>>> We will soon add several (nested) NoSQL configuration settings.  Before
>>>> we do that, I would like some feedback on the current NoSQL subsystem
>>>> code that reads connection settings.
>>>>
>>>> Any major corrections that you can suggest for the NoSQL subsystem code
>>>> [1][2]?  Especially, the
>>>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
>>>> methods.
>>>>
>>>> Should we continue to read all of the configuration settings from one
>>>> AddStepHandler or should we do that differently (perhaps with separate
>>>> AbstractAddStepHandler's)?
>>>>
>>>> Thanks,
>>>> Scott
>>>>
>>>> [1]
>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>>>>
>>>> [2]
>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime

Brian Stansberry
On 5/31/16 6:04 PM, Scott Marlow wrote:

>
> On 05/31/2016 04:48 PM, Scott Marlow wrote:
>>
>>
>> On 05/27/2016 10:19 AM, Scott Marlow wrote:
>>>
>>>
>>> On 05/27/2016 09:33 AM, Brian Stansberry wrote:
>>>> Can a new profile be added post-boot without requiring a reload to take
>>>> effect? If yes, the add handler for the profile resource should do the
>>>> service installation for that profile. It shouldn't count on the parent
>>>> to do it, as the parent logic will only execute during boot.
>>>
>>> I like the idea of adding a new profile post-boot, without requiring a
>>> reload of all of the profiles defined by the MongoDB/Cassandra
>>> subsystem.
>>
>> I need to back up on my response.  What does it mean for adding a new
>> profile without requiring a reload?  Does that require a hot change to
>> the NoSQL profile service without undeploying the application?
>
> After refreshing on
> https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-applyingruntimeupdates,
> I think currently, we should specify that a reload (all-services) is
> needed when adding/removing profiles.
>

Ok.

I was on vacation, so sorry for no reply.

I don't fully understand what these services are doing, so my only
comment is that it's ok (and common) to require a reload for a remove
but not for an add. A removal can disrupt other services while an add
often doesn't.

>>
>>>
>>> Currently, the standalone*.xml might contain:
>>>
>>> <subsystem xmlns="urn:jboss:domain:mongodb:1.0">
>>>    <mongo name="default" id="mongodbtestprofile"
>>> jndi-name="java:jboss/mongodb/test" database="mongotestdb">
>>>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>>>    </mongo>
>>>    <mongo name="default2" id="mongodbdiary"
>>> jndi-name="java:jboss/mongodb/diary" database="diarydb">
>>>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>>>    </mongo>
>>> </subsystem>
>>>
>>> If the user wants to add an additional profile to the mongodb subsystem,
>>> I think it would be worth us making the code changes to allow that.
>>> Will be great to add a new "otherDB", without stopping the existing
>>> database profiles.
>>>
>>> For supporting "remove" of an existing profile, I think that we will
>>> need dependencies added on the underlying
>>> MongoDriverService/CassandraDriverService, will be very worthwhile to
>>> have that as well!  Great feedback! :-)
>>>
>>>>
>>>> BTW, if post-boot profile adds/removes don't require reload, then [1]
>>>> should not be inside the "if
>>>> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block?
>>>
>>> Makes sense, looks like we need a remove handler also for the profile
>>> resource.
>>>
>>>> Same
>>>> question applies for the cassandra add handler.
>>>
>>> We should change the cassandra add handler also.
>>>
>>> Thanks again,
>>> Scott
>>>
>>>>
>>>> [1]
>>>> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124
>>>>
>>>>
>>>> On 5/26/16 3:02 PM, Scott Marlow wrote:
>>>>> Hi,
>>>>>
>>>>> We will soon add several (nested) NoSQL configuration settings.
>>>>> Before
>>>>> we do that, I would like some feedback on the current NoSQL subsystem
>>>>> code that reads connection settings.
>>>>>
>>>>> Any major corrections that you can suggest for the NoSQL subsystem
>>>>> code
>>>>> [1][2]?  Especially, the
>>>>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
>>>>>
>>>>> methods.
>>>>>
>>>>> Should we continue to read all of the configuration settings from one
>>>>> AddStepHandler or should we do that differently (perhaps with separate
>>>>> AbstractAddStepHandler's)?
>>>>>
>>>>> Thanks,
>>>>> Scott
>>>>>
>>>>> [1]
>>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>>>>>
>>>>>
>>>>> [2]
>>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>


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

Re: adding several more NoSQL specific connection attributes and sucking less in MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime

Scott Marlow


On 06/06/2016 03:26 PM, Brian Stansberry wrote:

> On 5/31/16 6:04 PM, Scott Marlow wrote:
>>
>> On 05/31/2016 04:48 PM, Scott Marlow wrote:
>>>
>>>
>>> On 05/27/2016 10:19 AM, Scott Marlow wrote:
>>>>
>>>>
>>>> On 05/27/2016 09:33 AM, Brian Stansberry wrote:
>>>>> Can a new profile be added post-boot without requiring a reload to
>>>>> take
>>>>> effect? If yes, the add handler for the profile resource should do the
>>>>> service installation for that profile. It shouldn't count on the
>>>>> parent
>>>>> to do it, as the parent logic will only execute during boot.
>>>>
>>>> I like the idea of adding a new profile post-boot, without requiring a
>>>> reload of all of the profiles defined by the MongoDB/Cassandra
>>>> subsystem.
>>>
>>> I need to back up on my response.  What does it mean for adding a new
>>> profile without requiring a reload?  Does that require a hot change to
>>> the NoSQL profile service without undeploying the application?
>>
>> After refreshing on
>> https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-applyingruntimeupdates,
>>
>> I think currently, we should specify that a reload (all-services) is
>> needed when adding/removing profiles.
>>
>
> Ok.
>
> I was on vacation, so sorry for no reply.

Welcome back! :-)

>
> I don't fully understand what these services are doing, so my only
> comment is that it's ok (and common) to require a reload for a remove
> but not for an add. A removal can disrupt other services while an add
> often doesn't.

I think that should also be true for the NoSQL integration.  So, we
should probably handle both add/remove at the "profile" level, so that
add does not require a reload.  Some more details are below about what
should be going on internally with these services...

For the example below, "mongodbtestprofile" represents a connection
profile that applications can @Inject/@Resource into an application
MongoClient/MongoDatabase variable.  The application may use the
MongoClient/MongoDatabase to read/write the MongoDB database as
represented by the "mongodbtestprofile" hostname/port/other settings.

There could be zero to many, different application deployments that are
using "mongodbtestprofile".  A removal of the internal service
representing "mongodbtestprofile", would *disrupt* the deployments that
are using "mongodbtestprofile".  The deployments do not yet have
dependencies set on the "mongodbtestprofile" internal service but I
think they will need to (currently on the TODO list).

Adding a new NoSQL profile, would likely be done before some new
application(s) are deployed that will use the added profile.

There are differences between the different NoSQL profiles that we will
support, which is why we will have a subsystem per NoSQL database type
(MongoDB/Cassandra/Neo4J initially).  For example, the Neo4J Driver
class is thread safe and can be expected to be shared by multiple
deployments, however the Neo4J Session is not expected to be shared.  In
contrast, MongoDB allows the MongoClient/MongoDatabase class instances
to be shared by multiple threads.

Hibernate OGM will also use the NoSQL profiles as well.

>
>>>
>>>>
>>>> Currently, the standalone*.xml might contain:
>>>>
>>>> <subsystem xmlns="urn:jboss:domain:mongodb:1.0">
>>>>    <mongo name="default" id="mongodbtestprofile"
>>>> jndi-name="java:jboss/mongodb/test" database="mongotestdb">
>>>>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>>>>    </mongo>
>>>>    <mongo name="default2" id="mongodbdiary"
>>>> jndi-name="java:jboss/mongodb/diary" database="diarydb">
>>>>      <host name="default" outbound-socket-binding-ref="mongotesthost"/>
>>>>    </mongo>
>>>> </subsystem>
>>>>
>>>> If the user wants to add an additional profile to the mongodb
>>>> subsystem,
>>>> I think it would be worth us making the code changes to allow that.
>>>> Will be great to add a new "otherDB", without stopping the existing
>>>> database profiles.
>>>>
>>>> For supporting "remove" of an existing profile, I think that we will
>>>> need dependencies added on the underlying
>>>> MongoDriverService/CassandraDriverService, will be very worthwhile to
>>>> have that as well!  Great feedback! :-)
>>>>
>>>>>
>>>>> BTW, if post-boot profile adds/removes don't require reload, then [1]
>>>>> should not be inside the "if
>>>>> (mongoSubsystem.hasDefined(CommonAttributes.PROFILE)) {" block?
>>>>
>>>> Makes sense, looks like we need a remove handler also for the profile
>>>> resource.
>>>>
>>>>> Same
>>>>> question applies for the cassandra add handler.
>>>>
>>>> We should change the cassandra add handler also.
>>>>
>>>> Thanks again,
>>>> Scott
>>>>
>>>>>
>>>>> [1]
>>>>> https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb/MongoDriverSubsystemAdd.java#L124
>>>>>
>>>>>
>>>>>
>>>>> On 5/26/16 3:02 PM, Scott Marlow wrote:
>>>>>> Hi,
>>>>>>
>>>>>> We will soon add several (nested) NoSQL configuration settings.
>>>>>> Before
>>>>>> we do that, I would like some feedback on the current NoSQL subsystem
>>>>>> code that reads connection settings.
>>>>>>
>>>>>> Any major corrections that you can suggest for the NoSQL subsystem
>>>>>> code
>>>>>> [1][2]?  Especially, the
>>>>>> MongoDriverSubsystemAdd.performBoottime/CassandraDriverSubsystemAdd.performBoottime
>>>>>>
>>>>>>
>>>>>> methods.
>>>>>>
>>>>>> Should we continue to read all of the configuration settings from one
>>>>>> AddStepHandler or should we do that differently (perhaps with
>>>>>> separate
>>>>>> AbstractAddStepHandler's)?
>>>>>>
>>>>>> Thanks,
>>>>>> Scott
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/cassandra/src/main/java/org/wildfly/extension/nosql/subsystem/cassandra
>>>>>>
>>>>>>
>>>>>>
>>>>>> [2]
>>>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/main/java/org/wildfly/extension/nosql/subsystem/mongodb
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev