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]
