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]
