I agree. I probably will go with the MCR approach instead. I may create a new ClosedServiceGroup which when initially created, has a default MCR that doesn't accept any EPRs. Applications should extend this class and explicitly add their own MCRs. This way, service groups can be dynamically created and controlled, without it accidentally picking up EPRs it shouldn't hold.
-----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 07, 2007 12:08 PM To: [email protected] Subject: RE: servicegroup membership rules Yes, that sounds pretty simple - I factored out the isMatch() logic so people could do this, I certainly don't see any harm in it. Adding new MCRs might be a bit cleaner and easier to modify in the future, but that's rather subjective. Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 03/07/2007 02:58:25 PM: > Sorry for the confusion, Dan:) I agree that #2 should not be called > except my Muse's persistence layer. > > I actually meant that I should override #4, which is the isMatch(EPR) > method. This way, if someone calls addEntry() to add an EPR directly > to the service group, or if Muse calls resourceAdded() after it adds a > resource instance to the ResourceManager, the isMatch() method is the > central filtering point. > > Do you think this is a good idea? If I do override isMatch(), then I > don't have a reference to the resource like in resourceAdded(), so I > am using similar code to what you have below to parse the address string. > > > -----Original Message----- > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 07, 2007 7:52 AM > To: [email protected] > Subject: RE: servicegroup membership rules > > I agree that #2 should be private, but we needed it to implement WS-SG > persistence. Oh well. > > I think I may have misunderstood what you're trying to do - I thought > you just wanted to create one instance of each resource type, add it > to the service group, and then ignore any other resources that were > created through the lifetime of the application (as part of your > implementation). > The code I sent allows you to do this. > > If you want some more complex filtering, then yes, maybe a different > implementation of MembershipContentRule would be better. The call to > Resource.getContextPath() in my code is what gives you the context path. > > If you want to get the context path from an EPR, with no Resource > object available, try this: > > String address = epr.getAddress().toString(); int index = > address.lastIndexOf('/'); String contextPath = > address.substring(index); > > > I discourage you from overridding #2, as that's just for adding > ServiceGroupEntry resources, mostly by the persistence mechanism. The > resourceAdded() override will work if you use the code below. Or you > can add new MCRs. > > Dan > > > > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 03/06/2007 > 08:33:43 PM: > > > Thanks Dan, > > I was initially confused by the methods in SimpleServiceGroup. > > Looking at the actual source code, I see: > > > > 1) addEntry(EPR,Element,Date) applies rule filtering > > 2) addEntry(EPR,WsResource) doesn't do any filtering > > 3) resourceAdded(EPR,Resource) applies rule filtering. > > 4) isMatch(EPR) does the real filtering logic > > > > I think #2 should be a non-public method, otherwise you could call > > it to add EPRs and bypass the rules. I assume #1 should only be > > called if we directly add an EPR to the service group, and #3 should > > only called as a listener method to the ResourceManager. > > > > So ultimately, I need to override #2. But given just an EPR, how do > > I > > > get the context name of the resource, which may not have been > > instantiated yet? > > > > I am trying to find a way where an application can dynamically > > created > > > service groups, and add membership rules and EPRs to each group. > > Each > > > group can have its own rules to filter specific EPRs. With the > > current APIs, I think I may end up having to create a custom > > MembershipContentRule class, instead of overriding > > SimpleServiceGroup, > > > since the rules can be set at runtime. > > > > > > > > -----Original Message----- > > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 06, 2007 6:27 AM > > To: [email protected] > > Subject: RE: servicegroup membership rules > > > > Okay, I think I know how you can do this. What you're doing isn't > > really part of a public interface for service group modification, so > > I > > > think this solution is acceptable. > > > > You are creating one instance of each resource type (the singletons) > > that you want to stay in the service group. Any future instances > > should be ignored. So, you should extend the default ServiceGroup > > implementation > > (SimpleServiceGroup) like so: > > > > > > public class SingletonServiceGroup extends SimpleServiceGroup { > > private Set _knownResourceTypes = new HashSet(); > > > > public void resourceAdded(EndpointReference epr, Resource > > resource) // override > > { > > String contextPath = resource.getContextPath(); > > > > if (!_knownResourceTypes.contains(contextPath)) > > { > > _knownResourceTypes.add(contextPath); > > super.resourceAdded(epr, resource); > > } > > } > > } > > > > You can complete the change by updating muse.xml to reference your > > new > > > class instead of SimpleServiceGroup. > > > > Since the singletons are created at application startup, this will > > always add the first instance to the SG while ignoring all others. > > What do you think? > > > > Dan > > > > > > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 03/05/2007 > > 02:22:15 AM: > > > > > Hi Dan, > > > Yes, I am trying to do a simple filter on the resouce context path > > > as specified in the muse.xml. Basically, I have a ServiceGroup > > > that > > > > should hold references to a fixed set of singleton resources that > > > will > > > > > be loaded at app startup. During the life of the app, new > > > resource instances can be created dynamically. But, I don't want > > > the ServiceGroup to accept and hold references to those dynamic > resources. > > > > > > The singleton and non-singleton resources may have similar > > > properties, > > > > > so having the ServiceGroup filter only on property names might not > > > work for me. I'm trying to use muse.xml's configuration-based > > > filtering approach, instead of having do it programatically and > > > hard-code the resource names/contextpaths to filter on. > > > > > > Also, it would be good to have some basic membership rule handler > > > class that can be specified in the muse.xml file for the > ServiceGroup. > > > > > The handler should read a list of rule implementation classes > > > either > > > > from the muse.xml or ServiceGroup's RMD file. This will allow > > > people to easily add new rule classes to config files, instead of > > > needing to programmatically add them. I can implement this > > > feature on my end, but I thought it would be good if Muse could > > > leverage this for > > everyone. > > > > > > > > > > > > -----Original Message----- > > > From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, March 04, 2007 10:56 AM > > > To: [email protected] > > > Subject: Re: servicegroup membership rules > > > > > > The filtering based on property definitions that exist in the WSRP > > > doc > > > > > is based on the WSSG spec (it's not something specific to Muse). I > > > imagine the authors were trying to emulate something like the WSDM > > > capability URIs as a means of determining what a resource was > > > capable of. What do you mean by "resource name"? The > > > <context-path/>? Let me know, perhaps I can suggest an alternative. > > > > > > Dan > > > > > > > > > > > > "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on > > > 03/02/2007 > > > 06:30:03 PM: > > > > > > > In my muse.xml, I have a set of resources that the app will > > > > initially load. I also have a ServiceGroup that will be loaded, > > > > and > > > > > > will used to hold references to the other resources. I would > > > > like > > > > > to set membership rules on my ServiceGroup so that it only holds > > > > references to certain resource types, based on the resource names. > > > > But, the current design/implementation of MembershipContentRule > > > > seems to filter > > > > > > > resources based on their property names, which doesn't seem > > > > useful > > > > > to me. Is there a simple way to non-programmatically set a rule > > > > to filter by resource name? If I have to do this > > > > programmatically, how > > > > > > would I do this? Just extend and override > > > > SimpleMembershipContentRule.isMatch(EPR)? > > > > > > > > > > > > > ------------------------------------------------------------------ > > > -- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > ------------------------------------------------------------------ > > > -- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
