El Lun 27 Dic 2004 18:37, Howard Lewis Ship escribió: > <interceptor-set> +1
> prototype service model (create a new instance for each method invocation) +0 Can't see a use case for this. I mean... a case which can't be solved in some better way. > Enumerate services. Ability to list the full ids of all HiveMind > services. Rod (Johnson) thinks this is necessary to properly > integrate with Spring. +1 We've faced the problem of needing to know service-points when implementing configurable/dynamic behaviour and security administration UI. For some cases we solved it using contributions listing ServicePoint objects but that's far from ideal... There's also the need to list a certain set of service-points / configurations matching an expression... maybe this could be another translator which uses an expression to return all matching service-points. > Hydra - allow a single service implementation to be shared by multiple > service points. Not sure what this would look like! It's just that, > occasionally, it would be nice for one piece of logic to have more > than one "face". This may get deferred out to 1.2. I think this get solved with the DelegatorFactory we've implemented... again, where should I post this code so it can be examined? Also I think a little set of service-point manipulation factories should be in place... this would include the above DelegatorFactory, right now it comes to my mind a MultipleDispatcherFactory and there should be other primitives like these. > Serializable Services --- the service proxy should be > Serializable/Externalizable. A placeholder object should be written > out. On de-serialize, the placeholder should locate a Registry > (inside a well known ThreadLocal) and replace itself. This isn't for > serializaing services, per-se, but to allow data objects that contain > references to services to be serialized. This comes up a lot in web > applications, where objects end up in the HttpSession. We currently have a simple implementation of this (which we could also share somewhere) that works for stateless services and which for getting really nice would need a special handling in BuilderFactory and such when creating proxies for Serializable or serialization-protocol-compliant services. > Dynamic locale. Should be possible to change the Locale (on a > thread-specific basis) and have messages automatically change over to > the selected Locale. Currently, Locale is fixed at Registry build > time ... it should be maleable at runtime. We've done this having a LocaleContext threaded service-point where we propagate locale information from the client (currently webapps). Ugliness of this is that this LocaleContext (along with our SecurityContext) needs to be propagated before *every* invocation.... I think this kind of thing drives us towards the implementation of the Session service model mentioned in some thread before. ---- We're really willing to return back something to the community in the form of some contributed code or colaboration in development, but so far it looks like there's no interest on these considering the poor response we had, I'm wondering why is that. For example, we're needing right away the JMX support which Achim is/has developed, and though I have asked to see/try/use/colaborate with his implementation I had no response nor access to the code, this ended up in us developing our very own version instead of all of us working together in getting a unique and better one. Regards. -- Pablo I. Lalloni <[EMAIL PROTECTED]> Teléfono +54 (11) 4347-3177 Proyecto Pampa Dirección Informática Tributaria AFIP --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
