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]
