Hey Brian, On Tue, Jul 26, 2011 at 23:32, Brian Topping <[email protected]> wrote: > > This afternoon, I believe I have the final bits committed to Brix for the > OSGi imports and exports. It turned out to be far more complicated than I > had imagined since Jackrabbit and Lucene are not built as bundles yet. This > meant a lot of messy embedding to get things to work. Fortunately, someone > on the team had already spent effort localizing Jackrabbit to a single > module, so I was able to leverage that work. > > That work is visible at > https://github.com/brix-cms/brix-cms/commit/821307696771299410d3de5a68e36f36ab424c73and > it's following commit where there are some cleanups (commented out stuff > removed for easier reading). > > Regarding what Brix needs to use Pax Wicket, some idea of the basic > architecture might help. As it stands, Brix master is a monolithic webapp > broken down into about eight different Maven modules. Brix plugins are > additional Maven modules -- essentially Wicket components with additional > metadata that makes them renderable from data in a JCR (i.e. Jackrabbit) > tree. In this manner, web content can be stored in the JCR tree, but that > content can be augmented by Wicket components that provide dynamic > functionality. > > This works spectacularly well for sites where the dynamic components in the > site are relatively stable, since the content can be changed at will by > content owners, mix and matched with dynamic components, and developers are > not bothered with constantly building new versions and redeploying the > server. In practice though, the components need to be tweaked pretty > regularly, leading to a lot of extra overhead for small sites that wish to > have high uptime. By this I mean that the sites need to be replicated and > the servers redeployed one-by-one behind a load balancer. > > On the other hand, if components could be intelligently redeployed as > services within an OSGi container, restarting should be a thing of the past, > and smaller sites can dramatically reduce complexity by sticking with a > single server that is directly connected to the internet. A lot of other > features are also possible. So that should frame the needs of the project > from the technical side. > > From a scheduling side, time is kind of tight to get this done. We're > starting new projects with Brix and of course want to use these projects to > add robustness to the public implementation. That being said, I'm > comfortable that there's going to be far less risk moving forward now that > the bundles have been defined, since major changes to module contracts are a > lot of work to carry over to external projects. Whether or not the > container can load or unload components at runtime is something that can be > kicked down the road a bit (although I'm also excited to toy with it asap!) >
Understandable :-) I've scaned the changeset and the Brix code but TBH while I understand what it should do I'll need a little bit more time to understand the how in detail. I'm not quite sure right now what you like to achieve. Am I right assuming that you want to do something like: Brix provides a(n) (I)BrixPlugin Interface with methods such as "Component giveMeTheLogicToThisJCRNode(node)". Clients implement them and export them with some additional parameters as OSGi services. Brix has a ServiceTracker listening for all available services and call them all? In this case I'm not quite sure where annotations come into play. Do you want to provide a "plain" OSGi solution for the core or base it on e.g. Blueprint? > A few points of note on the API: > > 1. It would be great if PW could act as a catalyst for adoption of JSR-330. > Harald's work also used this and lacking any impossible technical hurdles, > we ought to use it for future compatibility. > Basically PW does not care much about the annotation. The only thing I want to avoid here is to replicate all the Proxy and lookup code already done by e.g. Aries. I have to take a look if I can embed some components here... 2. IRequestCodingStrategy has been replaced by IRequestHandler. It's not > terribly difficult to translate between them, but will likely result in a > code base branch for PW. > > I don't think these are at all insurmountable. > > With some pointers to a working sample app that exercises some or all of > the PW use cases, I may be able to grok what's going on in there and help > with a branch. > You're right. There seams to be no IRequestCodingStrategy any longer in the Wicket master. Before this can be changed PW have to be splitted into the following projects: wicket-bundle-parent as osginized wicket (removed from service) pw-api pw-14-impl pw-15-impl pw-spring pw-aries pw-osgi (to come) pw-geronimo (to come) For this special case I think we may like to remove the RequestTarget from the PageMounter and MountPointInfo interface. That way the simple Bookmarkable usecase will run on both implementations. If you need to use the more advanced use cases you can use interfaces extending PageMounter in pw-14-impl and pw-15-impl. A sample using the current way will come quite soon. I'll update you once it is finished. Still, technically it is quite simple: When an application starts we also start a ServiceTracker [1] which adds/removes mount points as they come/go. We'll have to have two different implementations in pw-14-impl and pw-15-impl. Any additional hand on this, (ASAP I've splitted the projects) will be very welcomed :-). [1] https://github.com/ops4j/org.ops4j.pax.wicket/blob/master/service/src/main/java/org/ops4j/pax/wicket/internal/PageMounterTracker.java > > Yes, I apologize that I may have written in a way that was hard to > interpret. I completely appreciate that there are likely to be a large > number of missing use cases as well as that wicketstuff-osgi is missing a > lot of features and may have significant structural problems that are mostly > resolved by PW. But to my point earlier, getting something running such > that the bundle dependencies can be exercised and everything is in > approximately the right place would help with immediate development. > > In other words, immediate forward motion is a primary concern for current > stakeholders, even if I have to circle around and do it all again later > (it's a good learning experience, for sure...) > No problem with that. As long as we do not start to reinvent the wheel once the boundaries are reached I'm absolutely fine with that. > Ok, I'll try to dig into your work. I did read some of the quickstart and > it's a little hard to read for native english speakers. I'd be happy to > help with edits in that regard. :-) > Well, the feedback I've got so far was: Correct English but very, very plain :-) Well, this was somehow planed; nevertheless I'm very conscious about the fact that I wont get the next Shakespear of technical writing so every help from native English speakers is VERY welcomed! > > I'm very agnostic to how the problem is solved, I just need to get it done. > wicketstuff-osgi also has the advantage that I have commit access there, so > changes that are needed can be very easily implemented. I'm not religious > about anything, but I am "lazy" and take the path of least resistance in all > cases. :-) > OH, about the commit access... You might want to read http://team.ops4j.org/wiki/display/ops4j/Principles+of+Open+Participation+Software :-). OPS4J is a no-barrier-community. Register for team.ops4j.org and you should be able to edit any part of the Wiki. We have some trouble by now to integrate this with github by now, but by providing a pull-request or posting your username you get push access to all OPS4J repos (almost) immediately (btw, I've added you to the commiter list for the OPS4J repos). OK, to nail this down a bit. From my current point of view you need the following features in the following priority: wicket 1.5 jsr-330 plain osgi-injection One question now is: would it be useful already to have 0.9 with support for wicket-1.5 and 0.10 with jsr330 and plain osgi injection or is it required to have everything at once? I've given the roadmap another look. Basically I can schedule almost anything from 0.8 to some later release and start with the splitting around KW 32. WDYT? Kind regards, Andreas > > > Cheers, B > > > > 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 > > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > >
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
