On Wed, Mar 11, 2009 at 20:30, David Jencks <david_jen...@yahoo.com> wrote:
> > On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote: > > On Wed, Mar 11, 2009 at 1:29 PM, David Jencks <david_jen...@yahoo.com> >> wrote: >> >>> >>> On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: >>> >>> Hi, >>>> >>>> So let's agree to disagree for now. This may be related to my personal >>>> way >>>> of comparing stuff which is pretty much limited to: >>>> 1. understand what the requirements are. >>>> 2. understand how the technologies support these requirements. I do not >>>> need all the bells and whistles that a technology offers to fulfill the >>>> requirements. Moreover comparing stuff based on technology >>>> differentiators >>>> not clearly linked to the requirements is pointless. >>>> 3. assess best way forward based on above scoring. >>>> >>>> Key steps are 1 and 2 where stuff offering all the bells and whistles >>>> may >>>> well be scored as good as other stuff (I clearly do not support >>>> over-bloated >>>> stuff...). >>>> >>>> Obviously, I am keen to be proven wrong and adjust accordingly. So far, >>>> I >>>> am still saying that the main challenge is to properly tune >>>> export/import of >>>> dependency declarations. For me, the technology is not the core issue >>>> and >>>> switching is not going to resolve problems. >>>> >>> >>> I agree. I doubt Guillaume has seen your additions to classloading in >>> trunk >>> which allow you to not export packages from a classloader. I haven't >>> tried >>> to prove it mathematically but I think that with this feature the >>> classloading models for geronimo and osgi are equivalent in that you can >>> express the same ability to access classes with either of them. Of >>> course, >>> the notation you use to express this and the specific information >>> included >>> in the configuration is different. >>> >>> I think I probably have the most experience with classloading problems in >>> geronimo and the only real problem that arises is loading a jar in two >>> different classloaders. This can be solved by a classloader-per-jar >>> model >>> which offers no theoretical problems to set up in geronimo but >>> practically >>> would take a lot of work (and maven projects to build a plugin per jar). >>> So >>> I think we'll have to see what kind of problems we get with trying to >>> actually use OSGI. >>> >> >> Right but that's an important problem which we run into all the time >> in Geronimo (same jar loaded by two different classloaders). And the >> solution to this problem is to create another >> configuration/classloader and make that the parent of the two. This is >> a pretty 'static' solution while osgi offers 'dynamic' solution where >> it figures out at runtime which packages to wire together. So >> Geronimo's and osgi's classloading models might be equivalent ONLY IF >> we support classloader-per-jar model. Hiding classes/packages in a >> classloader is not enough. >> > > Our classloading system does support classloader-per-jar right now, but we > haven't set up enough classloaders to act that way, and I'm hoping that osgi > will provide the same features with less work. From a conceptual point of > view I don't see why osgi would be any more or less dynamic than geronimo. > The classes are coming out of some versioned jar and IMNSHO you are > unlikely to want to allow the resolution method to pick anything other than > the version of the jar for you. If you leave out the version in the > dependency geronimo will pick one for you... I'm not sure what the > equivalent osgi configuration would be. > > Basically it seems to me that osgi has the same problem as geronimo here, > that you have to include some really intrusive metadata in every jar to > specify the classloading behavior. Osgi has merely brainwashed everyone > into thinking that its metadata is desirable since its part of the manifest > whereas geronimo has some weird binary goo that no one is familiar with. > Maven does the same thing, packing the pom into every jar it builds (plus > supplying it alongside in the repository) > > So, everyone has the same problem -- you need a bunch of classloader > metadata associated with the artifacts you want to use -- and pretty much > agrees on the content, although each solution emphasizes different things. > IMO no one has a good solution yet. For instance AFAICT the felix bundle > maven plugin is typically used to effectively convert the maven artifact > dependencies to equivalent package import/export specifications. > FWIW, the bundle plugin does not really use maven dependencies. What happens is that the code that goes inside the osgi bundle is introspected to find all the list of all packages that are needed. This list is then converted into the OSGi manifest import along with any additional constraints or modification of those default constrainst. At some point (not sure if this has been done yet), maven optional dependencies should be used to specify optional package imports, but even if you miss a dependency or add some that are not really needed, it won't really affect the osgi metadata generated. > > <rant coherency="questionable"> > To me it seems like there are two opposing forces at work here. On the one > hand you want your code to be able to run in a variety of environments. On > the other hand you want to be able to know and specify stuff about the > environment. The environment basically boils down to a graph of a bunch of > jars. (with osgi, the classes you specifiy in import/export requirements > are in fact coming from some jar, somewhere). So how are you going to > specify that graph? How are you going to make it flexible? What's the > boundary between your app and the outside world? > > Maven and geronimo deal with this by having your app specify the jars it > wants and by allowing some way to substitute jars (artifact-aliases in > geronimo, exclusions in maven). osgi lets you specify the jars you want > (require-bundle.... I don't know if there's any way of overriding this like > in geronimo and maven) or by import/export specifications. As far as I know > in osgi to control what you get with import/export specifications you have > to control what jars are known to the osgi implementation. Maven and > geronimo are unfortunately tieing your app to particlar implementations but > let you specify that implementation easily. Osgi is not forcing you to > specify which implementation you want but is saying that specifying it is > someone else's problem. > > Think of what happens when you assemble a geronimo custom server. You > specify the particular "app" plugins you want (say your app deployed with > jetty and cxf and myfaces and a db pool and amq config) and geronimo uses > the dependency information to pull in everything else you need for a > complete server. If you want a different db pool you use artifact aliases > to get that one instead. Geronimo and maven are asymmetric in that there is > one "primary" dependency specified in the plugin itself (say the db pool you > want) but you can override it somehow. I don't know how to specify stuff > like this conveniently in osgi. (I'm aware that I'm mixing up classloading > and service dependencies here but think I still have a point even if not > very well expressed) > </rant> > > thanks > david jencks > >> >> >> Jarek >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
