> > AFAIK to the OSGi HttpService one can only register a > servlet.LiftServlet class is A HttpServlet but I don;t think that this > would help you much as critical operations are done in the LiftFilter > class. >
This is correct OSGi does not support the newest servlet spec and filters are not supported at this time. This is why I was wondering about a mediator style pattern as I am thinking that each bundle would need a servlet that could perform the features / services provided by the filter. (I may be way off base here however) > If and only if each registered servlet is loaded by a separate class- > loader (unrelated in the delegation chain) that should be possible > otherwise because Lift is using Scala objects such as LiftRules there > are no boundaries so there can not be separate LiftRules etc.AFAIK > each OSGi bundle is loaded by its own classloader. Am I wrong ? > Each bundle has its own classloader and this is, From what I understand how you can enable and disable bundles and run multiple versions of the same bundle simultaneously. > > One thought though .. you mentioned that you'd want to use different > context /profile, /blog etc. For that you don't actually need > different LiftServlet .. just a single Lift servlet registered to the > ROOT "/" context and let Lift manage the other paths /profile, / > blog, ... etc. > > The problem with my system is that profile is registered as a context root, blog however is not. It is registered as a service to the profile. The profile uses url patterns similar to /profile/<username>/service or /profile/private/service. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
