Basically yes, I agree, it is better to avoid encoded values in a String (cleaner, easier to understand and to check in the code). But such a configuration seems as cumbersome as the one I suggested as a workaround (and that is already possible now without any HiveMind change). What I like with the encoded args is that it can be done with no more lines in the config file (I don't like to use _too much_ xml...) In addition, we should feel concerned about backward compatibility for configuration files; that might make the task harder.
Maybe a nice addition to HiveMind would be to have a service (or simple helper class?) that can "decode" a string according to a specific schema and return the actual parameters? Is it worth it? Now on second thought, I wonder, maybe the original workaround idea is not so bad; just need to use a contribution to a configuration-point to setup the model arguments: - each customizable model has exactly one configuration-point - each service that uses this model defines a contribution to it NB: maybe the contribution can be optional if the model can provide suitable defaults. About defaults, a specific contribution (eg, pointing to no service?) could provide specific defaults to be used when no contribution is being made for a given service using that model. Finally, I think I could live with that ;-) at least for some time (it will still be time to refactor if HiveMind is enhanced wrt to this issue). Cheers -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Saturday, November 27, 2004 9:20 AM To: [email protected] Subject: RE: Thoughts about service models What if we change the descriptor file to allow "parameters" to service models... <service-point id="blah"> <service-model id="xpooled"> <max>10</max> <min>5</min> </service-model> </service-point> And, when you declare a service model contribution, you can specify its parameters schema? I don't like "encoding" parameters into one attribute value, but maybe that's just me. This method is cleaner and easier to document (hivedoc) IMHO. Just a thought. -----Original Message----- From: Jean-Francois Poilpret [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 7:15 PM To: [email protected] Subject: Thoughts about service models Dear all, In the past weeks, I have accumulated thoughts about potential new service models that could be useful in HiveMind. I would like to share my thoughts with you and possibly discuss if those models make sense, as well as discuss possible implementation issues. Some of these models come from an actual need that I have, for some others these are just ideas. 1. prototype This has already been discussed. Actually I am not convinced about the interest of such a model, if I understood it clearly. Actually, there is one unclear thing for me: - is a new instance created for each method call to the service? - is a new instance created when "looking up" the registry? (this would be quite limited because it would require systematic lookup to work as expected) 2. user This is one model would be useful in one of my projects. The idea is that each connected user has her own instance of the service. The instance is created on first call from a new connected user, ant later reused on each call from the same user. Existing instances could be "auto-garbaged" after, for example, some amount of time without any call (should be configurable). This model requires extra work to store the current user in a ThreadLocal or somewhere. This is easily done in a Servlet Container with a specific Filter that gets the current user/principal from the user. I started working on that as part of a more general "Security module" (providing authorization checks). Possibly, it could be interesting to define an additional interface that can be implemented by the actual service implementation, enabling the instance to be notified before it is garbaged. 3. session The principle for this model looks quite like the "user" model. The idea is to have an instance for each active session (session in the sense of HttpSession). The (sometimes subtle) difference with the "user" model is that one user can have several sessions (either because he is connected twice to the Web Server through 2 browser windows, or because you allow several persons to log in to the system with the same login at the same time). In this case, garbage collection of instances could be "triggered" by the events related to HttpSession. 4. short-lived I had this idea when thinking about integration of batch services (launched by quartz jobs or some other scheduler mechanism) in HiveMind. A service that is dedicated to batch processing is basically a singleton. But generally, such a service may consume many resources (memory in particular) that might not be recovered (memory leaks or other problem?) when the batch is finished. In this case, it could be useful to auto-garbage this service (the implementation instance) after some configurable timeout. Please note that we could partly have this behavior by using a "prototype" model (but with a timeout value fixed to 0, ie immediate garbage after use). Actually, I am not convinced of the interest of such a model, some feedback? 5. custom-pooled (or xpooled?) This model we already discussed a few weeks ago. The idea was to have a "real" pool of instances, with configurable params such as min, max, increment, timeout... The reason was to reduce the resource-consumption induced by HiveMind pooled model after a heavy load (hundreds of threads because hundreds of simultaneous users); in such case, the HiveMind pooled model retains hundreds of service instances (even if the load has gone back to normal). A few other notes: For some of these models, it should be possible to implement them directly based on HiveMind extensibility features for ServiceModels, without any change to HiveMind itself. However, for some models (in particular the "xpooled" model), there is the need to specify arguments to the model in the <implementation> tag itself. I already discussed that before (maybe I should put a JIRA evolution request as well): I had the thought that we could use the same way that is used for the configuration of translators, eg: <invoke-factory model="xpooled,min=0,max=10"> ... Of course, we have other options (but they make the life of end-developers harder) to provide those parameters to the ServiceModel, for instance, by defining a configuration-point that includes the service-id using the xpooled model with the additional parameters. But the implementation of the service model would be a bit more complex, I think (maybe not so complex with the new Map facilities for configuration-points, but unfortunately I base my developments on HiveMind 1.0 until 1.1 is officially released), and the configuration of the pool settings for the end developer is more cumbersome, compare: <contribution configuration-id="xpooled-config"> <service id="MyService" min="0" max="10"/> </contribution> <invoke-factory model="xpooled"> ... with the previous suggestion. Comments or hints on this point? Cheers Jean-Francois --------------------------------------------------------------------- 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]
