Thanks for your thoughts. I too am on a tight schedule but I will see what I can do.
A third problem is even after one rips apart the code adding the Factory and some sort of listener definition and registration mechanism (on a per namespace basis?) one still has to get the patch included in the build.
A last problem is that if one defines the listeners in the Domain.xml file (maybe as part of the factory definition), the Configuration object is not currently available everywhere in the code where a NamespaceAccessTokenImpl is created.
My current particular need is to be able to notify zero or more applications when a new baseline is created. Running applications would receive the notification and request the updated files. When an application starts, it simply reads the 'head' configuration. I am thinking of using JavaGroups as the notification mechanism since we use it elsewhere in our code.
Richard
Peter Paulus wrote:
on 7/8/03 17:19, Richard Emberson at [EMAIL PROTECTED] wrote:
Hello Richard, In our project we're using the interceptors; our time is to limited to do anything else.
I have been looking at an alternative approach though. The crux is with the interface 'NamespaceAccessToken' and implementation 'NamespaceAccessTokenImpl'.
The 'NamespaceAccessToken' interface allows you to retrieve implementations for various parts of the system. By supplying an alternate 'NamespaceAccessTokenImpl' (e.g. 'OurNamespaceAccessTokenImpl') you can handout different implementations for the functional subareas (Structure, Content, Security and so on). For the areas you do not want to change, you can redirect to the original 'NamespaceAccessTokenImpl'.
So 'OurNamespaceAccessTokenImpl' hands out an 'OurStructureImpl' on getStructure(), where it currently hands out an 'StructureImpl'.
Next, for all interface methods on the 'Structure' interfaces you notify listeners, and the redirect to the original 'StructureImpl'. This gives you a 'functional closure' before and/or after the redirect to the original implementation.
What I haven't figured out yet is: 1. When and how can you supply 'OurNamespaceAccessTokenImpl'. There doesn't seem to be a factory for that. So I guess you'd have to modify EmbeddedDomain.java or Domain.java, accessNamespace().
I find Slide a bit of a strange design in this aspect. They went the long mile on providing an interface for major subsystems in order to vary implementations. But there is no way, as far as I know, to configure these alternate implementations.
2. When and how to add listeners to your implementations. A very coarse, (non-preferred) solutions could be a 'SlideStructureListenerRegistry' with 3 static methods 'registerListener()', notifyListeners(), deregisterListener() and so on.
I'm very interested in how you will solve these 2 issues. Can you keep me informed?
With kind regards, Peter Paulus
Many configuration management system allow one to register with the server for events, such as change notification. Is this apart of Slide (I could not find it)? Has anyone done something like this with Slide and wish to share their thoughts? I could not find notifications in the WebDAV or DeltaV rfc's, does that mean that no one is doing change notification in their WebDAV systems?
So, if Slide does not have a notification capability, should it? How should it be implemented? I am leaning towards an Interceptor that used broadcasts notification via an interface (the implementation of the interface depends upon your particular needs). Of course this only works for content. I do not think Slide has any hooks for non-content based operations, such as adding a user or changing a permission ... right? So, how to implement a notification cabability for these?
Thanks
Richard (I know cross-posting is a sin, but, heck, I am a sinner which means I am allowed to.)
--------------------------------------------------------------------- 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]
