Hi Scott, I like this new approach, I think I now understand your point of the Application shouldn't be a singleton :) Regarding the Blueprint approach. Well everything is already there :) take a look at [1], it's a FactoryServiceTracker which does pretty much the same as your suggested fix for the manifest-approach. Basically we already have everything at hand, we just need another sample for doing it the more sophisticated way.
I added you to the dev-team, so welcome aboard :) regards, Achim [1] - https://github.com/sgp/org.ops4j.pax.vaadin/blob/master/pax-vaadin-service/src/main/java/org/ops4j/pax/vaadin/internal/extender/ApplicationFactoryServiceTracker.java 2012/12/7 Scott Parkerson <sc...@parkerson.net> > On Dec 7, 2012, at 12:55 PM, Scott Parkerson <sc...@parkerson.net> wrote: > > [This is in response to a private email to Achim; I'm going to continue > the conversation on the OPS4J general list. --sgp] > > On Fri, Dec 7, 2012 at 11:07 AM, Achim Nierbeck > <bcanh...@googlemail.com>wrote: > >> >> Regarding the Singleton approach, I'm not quite sure we are inline here. >> Pax for Vaadin only registers a Servlet as a HttpService, Pax Web does the >> connection to the Jetty HTTPServer world. Your suggestion would imply any >> HTTPService implementation isn't multi-user capable, cause all are >> Singletons. >> > > The problem is specific to the way Vaadin requires that a new instance of > the Application object has to be created for and stored with the session > that comes through the servlet engine. Otherwise you have the problem that > was described in PAXVAADIN-6, where you can load one of the samples, do > some stuff with it, and then move to another browser or computer and load > the sample and see the *exact* same application state! > > > I've made another attempt at fixing PAXVAADIN-6 in my fork on Github[1]. > > While this gets rid of the issue that Matt B. was talking about in > PAXVAADIN-6, it's not really "clean" in that the blueprint version requires > instantiating the Application instance only to get the class and stuff it > into the wrapped AbstractApplicationServlet to use to create new instances > of itself. It's not clear to me how you would then be able to use Blueprint > to do DI on things inside your main Application instance (say, to pass in a > reference to a business service or DAO method you might want to use). Not > sure how to proceed in a way that suits both the "bundle manifest" _and_ > Blueprint/Spring DM methodologies. > > Regards, > Scott Parkerson > > [1] > https://github.com/sgp/org.ops4j.pax.vaadin/commit/dd54bccfa0f53fbaa1be5d8349896ec4c810f72c > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
