Hi reto, thanks for taking the time and having a look at it and pointing out these things.
It's a while ago since I worked on it and I didn't realize the code is not yet fully cleaned up yet. However I am mostly interested if there are any conceptual problems with the solution. As I tried to lay out, the code allows to register SSPs in a different way (specifically with a bundle classloader). However it also requires the user to declare not very obvious manual or dynamic OSGI package imports when building his project in order for this to work correctly. Therefore I fear the solution will be there for 'experts' that know about it only, although I tried to document it. So my questions are mainly: - Do we want to solve the problem in this way? (Do you have an idea about a better solution?) - Given we go for (conceptually) this solution, do you see how to improve the implementation? I'm also glad when you point out the small unfinished things in the code for when I revisit it. Daniel On 22 May 2012 15:41, Reto Bachmann-Gmür <[email protected]> wrote: > Something else: > > In script-enines we have > > <!-- TODO: this dependency is problematic--> > <dependency> > <groupId>org.apache.felix</groupId> > <artifactId>org.apache.felix.framework</artifactId> > <version>3.2.0</version> > </dependency> > > But this doesn't seem to be actually used, there is only a commented out > felix specific part in TrackingCompiler. > > Cheers, > Reto > > On Tue, May 22, 2012 at 3:31 PM, Reto Bachmann-Gmür > <[email protected]>wrote: > > > Hi Daniel > > > > I've noticed the nranch is not compiling because of missing submiodule of > > scala-scripting. Should I copy the missing folder over from trunk? > > > > Cheers, > > Reto > > > > > > On Wed, May 2, 2012 at 1:48 PM, Daniel Spicar <[email protected]> > wrote: > > > >> Hi clerezza-devs, > >> > >> I would like to ask for a review of the code for this issue. It is > located > >> in issues/CLEREZZA-617. It is not very easy to understand this > problem. I > >> think there is a good log of what has been going on in the JIRA issue > >> comments [1]. When you install the code from the issue there will also > be > >> additional platform documentation available that explains the new > options. > >> > >> Thanks, > >> Daniel > >> > >> [1] https://issues.apache.org/jira/browse/CLEREZZA-617 > >> > >> On 18 January 2012 18:51, Daniel Spicar <[email protected]> wrote: > >> > >> > I committed some code to issue/CLEREZZA-617 that can solve this issue. > >> > However the solution is not ideal. > >> > > >> > A recap: The problem is generally speaking, that currently, we get > >> > dependencies from the scripting-engine bundle on other bundles that > are > >> > imported in SSP templates. That happens especially when using > >> > WebRenderingService (a way to create OSGi services that can be bound > and > >> > used in SSPs). The dependency that is created causes script-engine to > >> > restart when the webrendering service is changed. This in turn causes > >> all > >> > other bundles that depend on script-engine to restart as well, even > >> though > >> > most of these restarts are unnecessary. One symptom of this happening > >> is, > >> > that the scala console restarts and is broken afterwards. But also it > >> can > >> > cause significant downtime in production systems with many registered > >> SSPs. > >> > > >> > The solution so far: > >> > > >> > 1. I created a new method on ScalaServerPagesService to register SSPs > >> > with. The new method takes a classloader as an argument. The idea is > >> that a > >> > bundle registering its SSP also supplies its classloader which will > >> then be > >> > used to load the compiled SSP and thus only creating dependencies from > >> the > >> > registering bundle on whatever its SSP imports. > >> > > >> >> > >> > 2. in order for a bundle that registers an SSP with its own > classloader > >> to > >> > be able to resolve other packages in the OSGi environment, it needs to > >> be > >> > compiled with dynamic imports enabled or its runtime package > >> dependencies > >> > declared manually. The easiest way is to declare dynamic imports, e.g > a > >> > maven bundle plugin instruction to do so is: > >> > ... > >> > <build> > >> > <plugins> > >> > <plugin> > >> > <groupId>org.apache.felix</groupId> > >> > <artifactId>maven-bundle-plugin</artifactId> > >> > <configuration> > >> > <instructions> > >> > <DynamicImport-Package>*</DynamicImport-Package> > >> > </instructions> > >> > </configuration> > >> > </plugin> > >> > </plugins> > >> > > >> > The issues with this solution: > >> > > >> > about 1: The class loader can theoretically be detected automatically. > >> But > >> > the only approach I found is a platform dependent hack, see [1]. The > >> > current solution avoids this dependency. > >> > The current solution does not mess with backwards compatibility but in > >> > order to make use of the new interface quite some background knowledge > >> is > >> > needed (It's not easy to know what the use of it is). > >> > > >> > about 2: I asked on the felix mailing list if there is a programmatic > >> > solution. It seems there is none (sorry can't give you a link to the > >> > mailing listarchive because of the blackout day). This dynamic import > >> > declaration is the responsibility of somebody registering an SSP. But > >> is it > >> > not necessarily obvious to a user that he needs to do that. Of course > >> > documentation can help. But the core issue is hard enough to > understand. > >> > > >> > In summary: the issue can be avoided but it requires the user to be > >> aware > >> > of the problem. An automatic solution does not seem to be possible > with > >> the > >> > approach I took. However we have people that want a solution and this > is > >> > one. Given that I improve documentation about this issue I wonder if > the > >> > the solution is acceptable to be committed with the described > >> limitations. > >> > Alternatively I would be open to other approaches. > >> > > >> > > >> > [1] > >> > > >> > http://download.eclipse.org/jetty/stable-7/xref/org/eclipse/jetty/osgi/boot/utils/internal/DefaultBundleClassLoaderHelper.html > >> > > >> > > > > >
