Regarding OSGi Integration

Hi,

did you look at Pax Wicket (https://github.com/ops4j/org.ops4j.pax.wicket) ? It currently gets a rewamp and is in active development again.

Just to not reinvent the wheel.

Toni

Yes, I did. The problem with Pax Wicket, as with most other Pax projects, but even more so, is its lack of usable documentation. I don't even see what problem(s) Pax Wicket is trying to solve.

There's a nice post on Readme Driven Development in the Github blog.

wicket-osgi has its Readme in the Wicketstuff wiki, some more ideas are in the last few messages in this mailinglist thread: http://apache-wicket.1842946.n4.nabble.com/Wicket-and-OSGi-tc3617698.html

Sometimes, it's useful to have more than one wheel. Especially when you don't know what the other wheel is made of and how far it can travel. Or when building your own wheel is faster than trying to understand the mechanics of some other wheel without user guide.

Cheers, Harald

Hello Harald,

You're right. Pax-Wicket had the lack of a readme (still it would have been easy to jump into the dev list and say hello :)). I hope I've removed the readme problem at least (http://ops4j1.jira.com/wiki/display/paxwicket/Pax+Wicket and https://github.com/ops4j/org.ops4j.pax.wicket). The documentation we'll be increased during the 0.8.0 release within the next 2-3 weeks.

I'm not with you about the wheel thing. At least not because I was able to run your example in less than 5 minutes in pax-wicket. I'm following you on various lists (aries, wicket) and in fact you're facing the same issues we've already solved in pax-wicket. Well, it is your decision if you want to develop another framework, but most problems in the wicket-osgi integration ARE already solved in pax-wicket. In addition there where lots of changes to pax-wicket during the last months making it ways easier to use.

Maybe it's only me, but I think that we will be able to provide much more value to the entire community if we could bundle our forces among one project.

I'll be available on the pax as well as the wicket IRC about 1300 GMT. Feel free to ping me there ("pieber" is my username) if you like to discuss about the options, targets and possibilities.

Kind regards, Andreas

Andreas,

I'm a few weeks late on this discussion (didn't know it was here). I'd advance that it's good to have a fresh perspective on these problems. Pax Wicket looked to be defunct for the three years leading up to the 0.6.0 release a couple of months ago (and the flurry of new releases since Harald picked up the ball). 0.7.0 seems rather coincidental with Harald's work. Thus, as an open-minded user looking for the most viable solution, I'm not convinced about the future of Pax Wicket.

Please don't misinterpret this, but I typically avoid getting on mailing lists to wake slumbering incumbents if that just results in a burst of effort to maintain presence. If a team is really using a product and it means something to them that others can use it too, releases and documentation is the best way to engage the user base, even if they are slow and steady. In my previous attempts as to use Pax Wicket, it never caught on with me for the same reasons Harald has pointed out.

More recently, there has been an uptick of OSGi discussion on the Wicket user lists. If Pax Wicket was a viable option, I would have expected someone who was using it successfully to chime in with that information. As that never happened, what should interested parties expect? With open source, there's safety in numbers!

As a user, I see a README.md on https://github.com/ops4j/org.ops4j.pax.wicket, but if I follow those instructions, my browser comes up with a connection refused. I'm not so ignorant as to not know why, but a quickstart should do exactly that.

If the right thing to do is to "bundle our forces among one project", what is there to say that the right thing to do is not to bundle those forces on what has been contributed to Wicketstuff?

I hope you can interpret these comments with the intent they are written. I personally would like to see no need for this kind of specialized work on Wicket 2.0 -- I'd like to see OSGi work natively (if only as an option) from the core wicket distribution. Folks may reference the experience with portlets, with is appropriate, but it doesn't trump both OSGi and Wicket being an important part of all our futures, something I think anyone interested in these projects will agree on.

So how about it? Could we move Pax Wicket to Wicketstuff?

Cheers, Brian

Hey Brian,

Sorry for the real long mail but I try to answer all your ideas and thoughts as detailed as possible. I hope that I could at least explain/lighten some of your fears and concerns.

On Mon, Jul 25, 2011 at 14:16, topping < reply@reply.github.com>wrote:

I'm a few weeks late on this discussion (didn't know it was here). I'd advance that it's good to have a fresh perspective on these problems. Pax Wicket looked to be defunct for the three years leading up to the 0.6.0 release a couple of months ago (and the flurry of new releases since Harald picked up the ball). 0.7.0 seems rather coincidental with Harald's work. Thus, as an open-minded user looking for the most viable solution, I'm not convinced about the future of Pax Wicket.

OK, a little bit about the history here (Please see [1] for reference of what I write here). You're right. PAX-WICKET wasn't really supported for quite a long time. Still it wasn't defunct at any rate. Thanks to David Leangen it was always compatible to the latest Wicket version (although there where no releases). So as I picked up PAX-WICKET by the end of last year it was still fully functional with the latest Wicket version. Still it gathered some dust over the years and was far way from being usable since you no longer want to use plain OSGi tools in your application. Before going on here, just a little bit of why I'm doing this:

I had several applications based on spring-dm running with the help of PAX-WEB on Karaf. Since I had the need to move to Blueprint and wanted to move away from the "one-fat-war-approach" I needed some "middle-layer" and PAX-WICKET looks perfectly for this need...

So, as you can see at the history I started a big cleanup of the source code and started to learn how PAX-WICKET works. In addition I've added Spring-DM support with 0.6.0 and various other basics (Filter, InjectionHolder, ... [2]) to make the current solutions work with PAX-WICKET (such as [3]). Based on this is was possible to port the current apps on PAX-WICKET; so there is already software out there running on PAX-WICKET (and the switch was done in about one day which was quite impressive :)). Please note that this all took place BEFORE Harald started his work. If you take a look at the complete releases [4] you see that all of them had one goal which was completed with the release; so no coincident here too with Haralds work. For the reason of the multible minor releases after 0.7: since we've started to use PAX-WICKET 0.7 in our production systems the number of problems in real system we found increased --> the number of release; so no coincident here too.

BUT what is definitely true: I planed to shout out loud about the new PAX-WICKET with 0.7.0 when at least blueprint and spring-dm where finished; Harald forced me to rework the roadmap and do various restorations of the documentation about two weeks before I planned to do them...

So far about the history; about the current situation: PAX-WICKET is actively used in the OpenEngSB [2] which is used in various industry projects by now in the field. All of them are based on PAX-WICKET and all of them work quite well. So, while there might not be many companies using PAX-WICKET already there are already several developers working with it in the field and it does what it should do... In addition there is a roadmap for PAX-WICKET [5] and as you see on [1] again work is actually done. So there will be active development on PAX-WICKET for the next years since I don't think it will leave the production environments that fast again...

For the future, you've asked about: Lukasz and I started to work on [6] the last days which will bring a new (osgi)webconsole based on PAX-WICKET into Karaf. That way it way it will be included in one of the most used OSGi servers (servers, not runtimes) and reach several thousand people. So again, I don't think that PAX-WICKET will go down again that fast :)

Please don't misinterpret this, but I typically avoid getting on mailing lists to wake slumbering incumbents if that just results in a burst of effort to maintain presence. If a team is really using a product and it means something to them that others can use it too, releases and documentation is the best way to engage the user base, even if they are slow and steady. In my previous attempts as to use Pax Wicket, it never caught on with me for the same reasons Harald has pointed out.

Again here, if you take a look at [1] PAX-WICKET really wasn't supported. But with the beginning of this year the steady stream of commits started again (and not only by me (although mostly)). It's a real bunch of work to convince people taking a look at a project they once thought dead (as you point out) although there where many changes in the meantime and active support again. @Documentation: Starting with 0.8.0 I droped the entire documentation and started to write the entire thing from ground again as you can see at [7]. Although there is some again in place there is still some work to do. By end of August the documentation will be finished again and 0.8.0 will be available. Still the most basic tasks are already documented and should give (together with the linked samples) a good entry into the project.

More recently, there has been an uptick of OSGi discussion on the Wicket user lists. If Pax Wicket was a viable option, I would have expected someone who was using it successfully to chime in with that information. As that never happened, what should interested parties expect? With open source, there's safety in numbers!

Again, the project WAS dead for a long time. Which means, except from the OpenEngSB team and people around there nobody had used pax-wicket for a long time. Still it was successfully used by several people (also in production; you see this if you dig a little bit in the ops4j archives). But none of them is following on the Wicket lists... Nevermind, see it as a new project based on a stable and long existing core.

As a user, I see a README.md on https://github.com/ops4j/org.ops4j.pax.wicket, but if I follow those instructions, my browser comes up with a connection refused. I'm not so ignorant as to not know why, but a quickstart should do exactly that.

Terrible sorry for that. The problem is that github always brings you to the master showing now pardon if you forget to update a line. For 0.8.0 I've completely restructured the examples. The README in the master is corrected now. If you do not like such surprises please rely on a released version, e.g. [8]. Nevertheless, based on the current roadmap I think the readme should be stable now for at least the next 2-3 releases.

If the right thing to do is to "bundle our forces among one project", what is there to say that the right thing to do is not to bundle those forces on what has been contributed to Wicketstuff?

Nothing against that. In fact there is only one reason I think the one in Wicketstuff is not the right one: While PAX-WICKET is quite old the core is really stable. Don't missunderstand me, but during all my refactorings I barely touched the core code which handles the delegating classloading and serializing. This code had been seen and tested by various developers at OPS4J right now and is still almost the same as in the beginning. The reason is simple: Wicket requires some tweaks to run in an OSGi engine as you expected. The current solution at Wicketstuff does not handle those sitations in any way. Which means that the entire (already stable) delegating classloading and injection part of PAX-WICKET would have to be rewritten. And the reason I jumped up was that I don't think that there is any sense in rewriting the core things in another project again.

I hope you can interpret these comments with the intent they are written. I personally would like to see no need for this kind of specialized work on Wicket 2.0 -- I'd like to see OSGi work natively (if only as an option) from the core wicket distribution. Folks may reference the experience with portlets, with is appropriate, but it doesn't trump both OSGi and Wicket being an important part of all our futures, something I think anyone interested in these projects will agree on.

Definitely. We all agree on this and we all hope that! Believe me. BUT I'm afraid this is a little bit of a chicken-and-egg problem. I think the roadmap here would rather look like:

1) Provide a fully functional project integrating wicket with osgi. 2) Make it possible to simply plug the framework into wicket without the need of re-writing some wicket classes (which is currently required). 3) Merge the osgi-modules into wicket.

If you think it is possible otherwise feel free to light the way :)

So how about it? Could we move Pax Wicket to Wicketstuff?

OK, this is an entire different issue. At least in theory this wouldn't be a problem. Because of the Apache2 License it wouldn't be any problem to fork and continue the work there. While there is one big advantage (higher visibility to the user community) it has several drawbacks from my point of view:

1) PAX-WICKET has a fast evolving feature set independent of Wicket right now. Therefore it makes sense to be able to release the software independent of Wicket 2) The OPS4J community provides the better infrastructure with a fully featured JIRA and CONFLUENCE and not only the github wiki and issue tracker.

So I personally would rather prefer the way proposed above: finish the features; make it fully includeable into wicket; merge it into wicket if wished.

What do you think? Feedback is always warmly welcomed!

Kind regards, Andreas

Cheers, Brian

[1] https://github.com/ops4j/org.ops4j.pax.wicket/network [2] http://team.ops4j.org/wiki/display/paxwicket/2011/06/09/Pax+Wicket+0.6.0+Released [3] http://openengsb.org/ [4] http://team.ops4j.org/wiki/label/pax-wicket [5] http://team.ops4j.org/browse/PAXWICKET#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel [6] https://issues.apache.org/jira/browse/KARAF-727 [7] http://team.ops4j.org/wiki/display/paxwicket/Pax+Wicket [8] https://github.com/ops4j/org.ops4j.pax.wicket/tree/wicket-0.7.2

Reply to this email directly or view it on GitHub: https://github.com/wicketstuff/core/issues/46#issuecomment-1645251

Andreas, thanks for your thoughtful and comprehensive reply. It's much appreciated.

As David will tell you (possibly with a chuckle), I have a deep interest in OSGi on Wicket, but have been constantly distracted for the last six months. I believe that the answer for Brix CMS (http://brixcms.org) is to directly or indirectly base Brix plugins on OSGi so they can be loaded and unloaded at will. I've been struggling to find time to get this done, but am getting started again on it.

Prior to Harald's or your work, it seemed like if OSGi support would have to be cooked from scratch for Wicket, it would be best to do it for 1.5. I finished most of the work (with Igor finishing the parts that were out of my league) to start the 1.3 series of Brix on 1.5 last month sometime. So while the delay in 1.5 support for PW makes great sense, it's a bit delayed from my perspective (no sense doing this work twice).

One of the challenges around OSGi is there are so many helpful solutions out there, some of which are not the best choice for new projects. Many of them are competing and many are complimentary. It's not always clear how they fit together, or sometimes if they are even still relevant. PW may be the "Victorinox of Wicket under OSGi", but if I can't figure out which blades to use and which ones to ignore (as in the parts that are used for deprecated environments) and do so in bounded time, I'm kind of back to square one. And like any open source dependency, one can't set expectations where one cannot make substantive contributions.

While I would hope to find that the sample app would present current best practices (and presume it will since the project is seeing a lot of investment), I'm still blocked on the 1.5 issue.

Harald's work is very concise and it sounds like you've reviewed it. While it may be "missing a lot of the blades", it has a great foundation, and I can start with it now.

As for the path to getting this integrated into Wicket, one of the things that I've seen time and again in Wicket is a resistance to complexity in the core. It's both why we have such a great framework and why getting OSGi in there may be a challenge. I don't know what the answer to this is, "one step at a time" is the best one I have for now. I'd like to believe Brix is a pretty good proof-of-concept for doing such an integration.

I don't know if that background is helpful. I think I would use PW if 0.10.0 was out, and if I was a little further on the learning curve, would help try to make it a reality so we could all use it. And if the conversion over to PW makes sense at a later time, I'm all for it as well.

This discussion is very vital, please don't hesitate to ask if there's anything I can offer.

best, Brian

Hey Brian,

On Mon, Jul 25, 2011 at 20:34, topping < reply@reply.github.com>wrote:

Andreas, thanks for your thoughtful and comprehensive reply. It's much appreciated.

As David will tell you (possibly with a chuckle), I have a deep interest in OSGi on Wicket, but have been constantly distracted for the last six months. I believe that the answer for Brix CMS (http://brixcms.org) is to directly or indirectly base Brix plugins on OSGi so they can be loaded and unloaded at will. I've been struggling to find time to get this done, but am getting started again on it.

Prior to Harald's or your work, it seemed like if OSGi support would have to be cooked from scratch for Wicket, it would be best to do it for 1.5. I finished most of the work (with Igor finishing the parts that were out of my league) to start the 1.3 series of Brix on 1.5 last month sometime. So while the delay in 1.5 support for PW makes great sense, it's a bit delayed from my perspective (no sense doing this work twice).

That's definitely a reason. As I set the priorities I expected that most projects are still running on 1.4. The first releases of PW where build with the idea to port your existing apps as easy as possible to PW. For example: For the OpenEngSB we didn't need much more than the following commits and about one day of work to port the entire project (OK, a little bit more, but those where the core-changes):

https://github.com/openengsb/openengsb/commit/2fac26a12c0778260599c7d2bf4ee4695f9164ac https://github.com/openengsb/openengsb/commit/586683821853fa6f5a1cd8b55be48080361639e4 https://github.com/openengsb/openengsb/commit/65920630a26cbd0e4a41a9e9a74c9c7630024eb4 https://github.com/openengsb/openengsb/commit/3ecec0b247ed3b890dabe93b8f00837c86f7f998

I'm not deep into Brix, but the question is: what exactly do you need. I layed the roadmap as I thought it useful for users. If users step up and say that they require feature X before feature Y I've no problem to change the way. The only thing which needs to be finished first is the 0.8 release, because it contains the entire lot of samples and API changes (the last one for a longer time I hope). After that (mid to end of August) we can change the road as required. If you could point me at the relevant parts of Brix (or explain them to me) and show me how you intend to make this work we can adapt the order of the issues to your need. BTW, I've registered for the Brix mailing-list. We can continue this discussion there, on the Wicket or on the OPS4J lists as you like.

One of the challenges around OSGi is there are so many helpful solutions out there, some of which are not the best choice for new projects. Many of them are competing and many are complimentary. It's not always clear how they fit together, or sometimes if they are even still relevant. PW may be the "Victorinox of Wicket under OSGi", but if I can't figure out which blades to use and which ones to ignore (as in the parts that are used for deprecated environments) and do so in bounded time, I'm kind of back to square one. And like any open source dependency, one can't set expectations where one cannot make substantive contributions.

I've worked hard on this and the next (and hopefully almost final version of the PW API) is much clearer and easier to understand as you might like to convince yourself (JDoc will be completed soon too):

https://github.com/ops4j/org.ops4j.pax.wicket/tree/master/service/src/main/java/org/ops4j/pax/wicket/api

While I would hope to find that the sample app would present current best practices (and presume it will since the project is seeing a lot of investment), I'm still blocked on the 1.5 issue.

Harald's work is very concise and it sounds like you've reviewed it. While it may be "missing a lot of the blades", it has a great foundation, and I can start with it now.

This is not so completely true. With Haralds approach you might do some minor use cases, BUT there are various problems. For example: Pages/Components could not be loaded via services; injection is only based on OSGi services; internal Pages/Components could not be used. Serialisation over bundle level is not solved. Serialisation of Bundle/Application references are not solved. It does not run on plain OSGi HTTP services. Please don't get me wrong. This is NOT against Haralds work. In neither way! He did a great job in getting a minimal working solution up and running. The only thing I'm talking about is that this wont be enough to get any real application up and running where Components, Services, Injection and Serialisation is splitted over multible bundles. If you like to do such things you'll need something very similar to the PW core (and this is the entire thing I'm talking about all the way :-)).

For the examples: This is one of the big goals for 0.8. By now I extend the examples almost every day. Examples for Components in various bundles will come by tomorrow or latest Thursday. Examples (and the documentation) are available already for getting the things up and for injection. While everything else is also running already I plan to finish all samples by end of next week. Still, the quickstart guide (those things I think are most interesting for most users) is already finished: http://team.ops4j.org/wiki/display/paxwicket/Quickstart. Feedback is very welcomed here. All samples and explanations work with the latest master (guaranteed by pax-exam integration tests).

As for the path to getting this integrated into Wicket, one of the things that I've seen time and again in Wicket is a resistance to complexity in the core. It's both why we have such a great framework and why getting OSGi in there may be a challenge. I don't know what the answer to this is, "one step at a time" is the best one I have for now. I'd like to believe Brix is a pretty good proof-of-concept for doing such an integration.

I don't know if that background is helpful. I think I would use PW if 0.10.0 was out, and if I was a little further on the learning curve, would help try to make it a reality so we could all use it. And if the conversion over to PW makes sense at a later time, I'm all for it as well.

It's definitely not too early. I push PW 0.8 with all available free-time trying to make the road clear to move in every direction required. If we start talking about this now it is quite possible that a try to port Brix based on PW 0.9 is already possible. I'm completely with you that more more then "my own" proof-of-concepts and use cases are required to bring PW to a broader base of users. So it would be very appreciated if we could continue the conversions although PW 0.8 might not be a perfect fit for Brix.

This discussion is very vital, please don't hesitate to ask if there's anything I can offer.

I think I did so already and hope for further responses ;-)

Kind regards, Andreas

best, Brian

Reply to this email directly or view it on GitHub: https://github.com/wicketstuff/core/issues/46#issuecomment-1647933

Hi Andreas, let's continue this on the Ops4J list so other PW users can benefit from it. I guess that's the general list, but we can move it if it's not. Will respond there!

There is only a general list :-) so this is a perfect match. Thank you very much!

Kind regards, Andreas On Jul 26, 2011 10:02 PM, "topping" < reply@reply.github.com> wrote:

Hi Andreas, let's continue this on the Ops4J list so other PW users can benefit from it. I guess that's the general list, but we can move it if it's not. Will respond there!

Reply to this email directly or view it on GitHub: https://github.com/wicketstuff/core/issues/46#issuecomment-1657384

wicketstuff / core

Regarding OSGi Integration #46