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]
