... and I forgot to mention, we now should merge those three different ways of publishing the Servlets to one. Right now there is the BundleTracker (manifest) registering it, there is the ServiceTracker (aka blueprint) registering it, and this might be the tricky one again when trying to find a common solution. And there is the FactoryServiceTracker approach I talked of before.
regards, Achim 2012/12/8 Achim Nierbeck <bcanh...@googlemail.com> > 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/> > -- 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
