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/... 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/sr... > > [2] > https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/... > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

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/... >> >> 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/sr... >>> >>> [2] >>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/... >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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-apply..., > > 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/... >>>> >>>> >>>> >>>> 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/sr... >>>>> >>>>> >>>>> >>>>> [2] >>>>> https://github.com/scottmarlow/wildfly/tree/nosql-dev9/nosql/mongodb/src/... >>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>