Brix and OSGi
richard...@gmail.com
Patrick Angeles
I there any interest or planned effort to make Brix run on OSGi?
Patrick Angeles | VP Technology
Direct:707.603.2821 | Fax:800.366.2303 | Support:800.819.0325
Inertia - Powering the Wine REvolution | www.inertiabev.com
Igor Vaynberg
problem being wicket's need to serialize page hierarchies for later
use. the components come from different bundles and when wicket tries
to deserialize them it has a problem because it cannot load the right
classes because it has no visibility to the outside world. as far as i
understand it, and my understanding of it is not very deep, this is a
general problem with osgi and serialization. until there is a clean
way to solve it we cannot fully utilize that platform.
-igor
On Tue, Nov 11, 2008 at 11:25 AM, <richard...@gmail.com> wrote:
>
David Leangen
The pax-wicket guys have found a pretty good, but still incomplete
solution. Essentially, it notes the id of a serialzed class, then
loads it from the proper bundle's classloader upon deserialization.
It works now in most situations, but probably would not be acceptable
in a heavy-duty production environment. For instance, for some reason,
proxyied classes cannot be serialized.
http://www.ops4j.org/projects/pax/wicket/
They people there are pretty good, so if you make some noise, likely
they will move things forward more.
I have been using wicket now with osgi for a few years, and after
surmounting a few bumps along the way, am generally happy.
Cheers,
=david
Igor Vaynberg
imports and all that stuff that you need to do to make it work. thats
too bad. i havent been following osgi closely to be familar with all
the problems. you would think there would be something like
OsgiObjectInput/OutputStream that is provided by the platform to
handle this sort of thing.
-igor
David Leangen
Note: reposted to ops4j to get their input. This thread is about the
state of Wicket+OSGi, specifically regarding classloaders. I have
stated my opinion, but thought it would be a good idea to include the
core developers working on this project.
> even that solution is technically a "hack" correct? that and dynamic
> imports and all that stuff that you need to do to make it work.
Yes and no.
The idea seems ok, but the developers haven't yet fully followed up on
it, so the result is that the current state of the code is a hack
(IMHO), but with a little work, it could be turned into a correct
solution. Just as an example, currently proxied classes cannot be
serialized. One can work around this, but it's a bit of a PITA.
Another example is that if two bundles provide a class of the same
name, there is currently (AFAIU) no way of determing which bundle
should handle the serialization for that class.
If enough people show their interest, maybe this could be moved up on
the priority list. :-)
They are committed to pax-wicket, but I think their team is very busy
right now, so it's just question of priorities.
> thats too bad. i havent been following osgi closely to be familar
> with all
> the problems. you would think there would be something like
> OsgiObjectInput/OutputStream that is provided by the platform to
> handle this sort of thing.
Hopefully that will come soon. I tend to agree with you, so hopefully
if ops4j doesn't fix this soon, maybe somebody else will. (I wish I
had the time...)
Like you point out, the ideal thing would be to have a generalized
solution that would work with any Wicket+OSGi setup, IMO...
Cheers,
=dml
David Leangen
Niclas Hedhman
>> thats too bad. i havent been following osgi closely to be familar
>> with all
>> the problems. you would think there would be something like
>> OsgiObjectInput/OutputStream that is provided by the platform to
>> handle this sort of thing.
This is actually a good idea. With dedicated Object streams, we can
annotate the package meta data, and possibly lookup a classloader via
the Package Admin Service.
But there is also a RFP in OSGi Alliance around serialization, written
by Paremus, the only people with a solid solution. Should check on the
status of that RFP.
Could we be informed of the background to this discussion?
Cheers
Niclas
David Leangen
> Could we be informed of the background to this discussion?
There is not really any background. Somebody was just asking a
question about Wicket+OSGi, and this topic came up. I don't think that
the Brix or Wicket people have any plans to pursue this.
I just wanted to hook everybody up, since this topic is related to
both Wicket and ops4j.
Cheers,
=dml
Igor Vaynberg
> Could we be informed of the background to this discussion?
when starting brix we considered using osgi. brix is heavy on plugins
so a platform like osgi would be a perfect choice. however, since brix
is built on top of wicket we did not go with osgi because we did not
have time to deal with serialization issues that were sure to arise.
insteadm we rolled our own simple extension point registry. thats
really all there is to it.
-igor
>
>
> Cheers
> Niclas
>
> >
>
Richard Allen
We have web applications that we plan to migrate from Struts 1.x to
Wicket. We also plan to create a new web application, which will be a
wiki with special features. One of our existing applications, which
the wiki will need to be integrated with, is similar to a document
management system. Therefore, I want to create an application along
the lines of a content management system, that includes (redefines the
architecture of our existing) document management and a wiki as a kind
of web content management. The document management and the wiki have
some of the same special requirements (features).
Our existing web applications are modularized using Struts 1.x
modules, where each module is built into it's own WAR, and then, as
part of the build, some (partially custom) Maven magic merges all the
module WARs and web.xml files into a single WAR file. The solution is
far from ideal, however, it does provide some nice decoupling of the
modules, which makes maintenance, reuse, and refactoring easier. Using
OSGi in the context of a web application shows some promise to better
modularize our web applications. The best support I've seen for this
so far is Spring Dynamic Modules for OSGi.
Ideally, I would like to avoid merging WAR balls, and instead have a
separate OSGi bundle for each module, complete with it's own resources
(HTML, CSS, JavaScript, Java, and maybe web.xml configuration), which
can be deployed to an OSGi container, and can be referenced by other
dependent modules, or reference modules that it depends on.
I would like to build this content management system on a JCR, like
Jackrabbit. Using an open source implementation built on top of a JCR
would give me a head start, and that's where Brix comes in. I've also
been looking at Sling, which uses OSGi. There is no existing
integration between Wicket and Sling, but I've seen talk around it.
I'm new to both frameworks, so integrating the two could be a
challenge to me, but a challenge I'm willing to take on if it's the
best solution. There are features from both Sling and Brix that I like
-- the way Sling makes RESTifying your content easy, and the use of
Wicket, WYSIWYG editing, plugins, tiles, publishing workflow, and JCR
workspaces in Brix.
I've seen the Pax Wicket project, but have not experimented with it
yet. Our primary goal is to create the application, but my secondary
goal is to use Wicket and OSGi to improve the modularity and
maintainability of all our applications.
My organization is willing to contribute back to the open source
community, but, of course, our primary goal is satisfying our
customers. We have to decide how much effort we can expend. I feel
confident that, done right, Wicket and OSGi (using Spring Dynamic
Modules) would make a great base architecture for our web applications.
Igor Vaynberg
a great architecture for webapps, especially with wicket which makes
it easy to load resources like images and css from classpath. and let
me echo your concerns for satisfying your customers first, this is
exactly why we did not go with osgi although we wouldve liked to. we
simply did not have the time to deal with serialization problems. if
someone was to figure them out properly i would be happy to refactor
brix into bundles, and use osgi+wicket in general...
-igor
Patrick Angeles
- Package each module as a jar.
- Each module would then have a war (which internally is little more than a web.xml), mostly for use during development. You can avoid creating an actual maven module just for the war if you use an embedded servlet container like Jetty for development.
- You would also have a master war file which includes all the module jars, which you would deploy to production.