OK, sorry for the delay but long mails typically imply some work at least :)
On Tue, Jul 5, 2011 at 10:11 PM, Harald Wellmann <harald.wellm...@gmx.de> wrote: > Well, it's the second impression really... The first was a homepage > containing cryptic release notes and nothing resembling a mission statement > or a Getting Started guide. > > In a discussion on the Wicket users list about a different approach I'd > started a while ago, Andreas provided links to some introductory notes he'd > just created, so I thought I'd just give it a try. > > - Cloned the git repo, ran mvn install. Compiler error. (due to a bug in JDK > 1.6.0_24, but this is latest official one on Ubuntu :-( You're right; PAXWICKET-164 describes the problem already and I'll try to provide a workaround as one the first things for 0.8.0 > - I used Eclipse to compile the project and then ran mvn pax:provision. > > - The sample started with a bunch of DEBUG messages and finally presented a > Gogo shell prompt. Now Gogo is just about the ugliest thing I've seen ever > since vi. No help and absolutely no usable documentation on its official > homepage. I tried "help", "exit", "close", "stop", "^D", no success. With > ^C, I got back to my bash, but then I could restart the sample, apparent due > to a socket timeout or a background process still running... > > - After some trial and error and some dim remembrance of Pax Runner, O found > out that "stop 0" would let me terminate Gogo cleanly, and even better, > pax:provision -Dframework=equinox would run the whole thing in Equinox. Much > better! Well, gogo & pax-construct. Sorry somehow I didn't want to provide a gogo/construct instruction here. Since it is not required to run the examples. Though at least some help may not be wrong. What would you've expected. I've created PAXWEB-189 to discuss and layout the documentation restructuring. Feel free to add all ideas to this issue. For the logging output and the framework: well was enough by now for me. What do you expect? Start the samples by default with equinox and logging set to warn? (would be quite simple to archive) > > - Why does it take what felt like half a minute for the framework to shut > down? Good question. This does not happen in Karaf. I've created PAXWICKET-190 to track this problem. > - I opened the samples in my browser, and they all looked ok, but I was > really more interested in the inner workings, so I took a look at the source > code: > > - Little or no Javadoc in internal packages, somewhat more but not enough in > the API package. True; With PAXWICKET-183 I'll revisit each class again and add explanation of the usage and the concepts directly in jdoc... > - Separation of concerns is one of the OSGi mantras, but here we have a > mixture of unrelated things in one project. Supporting both Spring DM and > Aries Blueprint for dependency injection within the same bundle is not my > idea of modular design. True, in addition the API package should be separated from the implementation (at least the wicket part to allow upgrading quite easy). The wicket libs also need to be splitted from the pax-wicket package to allow the user to use the wicket version he wants to use (in a specific range [1.4,1.5)). Again: I took over the project and had bigger issues at hand than splitting the package structure... Nevertheless, the splitting was already one of my main targets for 0.8.0 and is reflected in PAXWICKET-112 and PAXWICKET-184. > Spring DM is obsolete and has been superseded by > Eclipse Gemini. True; still Gemini requires the users (typically) to change at least some imports/namespaces. And there are still projects out there based on spring-dm (like some of my old where). Providing an easy entry point for those projects before move them to Gemini (or the blueprint standard directly) should help here (as it helped me). So, while I'm with you (see paragraph above) that the spring-dm bundle should be moved outside I don't think it's a bad idea to have it... > Is there a hard dependency on Aries Blueprint or can you > work with other compliant Blueprint implementations? Yes there are; The problem is that the namespace handling requires some deeper integration with aries (as well it will have for gemini). While this means you will not be able to use the pax-wicket namespace support for blueprint the blueprint injection framework provided in pax-wicket will still work. Still I think it will be a good idea to also add support for Gemini (PAXWICKET-188). > - As a consequence, there are lots of optional package imports in the > manifest, which is usually a symptom of a lack of modularity, and also > dangerous, because an OSGi framework is free not to wire an optional import, > even when a matching package is available. > > - I think both Spring support and Blueprint support should be refactored > into separate bundles. Well, you're stating the obvious. And still; it was something which was not bothering me during the cleanup and extension of the old pax-wicket through pax-wicket-0.6 and 0.7. Everything at it's time... Now that things are really working (and I have valuable integration tests showing this on on some of my larger projects) I'm brave enough to start the internal refactoring (and splitting) of this framework... > - Oh no, @PaxWicketBean - yet another injection annotation... > Why not simply use JSR-330 @Inject plus optional @Qualifiers? This would > give users the freedom to reuse their page or componenent bundles in plain > old WARs with CDI or Spring injection. True; for the first inclusion of the injection framework I wanted something as similar as possible to wickets SpringBean annotation. Now that I know how this should look like and work for spring and blueprint we can replace it with the JSR-330 annotation. Though @Inject and @Qualifiers wont be enough. We'll also require @Named (you cant inject by type from a blueprint context; only by name) and @Scope (although in a spring-context (which I can autodetect) you may like to inject plain osgi services or from a blueprint context in the same bundle (spring & blueprint can live side-by-side)... Still I think this is a good idea and should be quite easy: PAXWICKET-186. > - Does Pax Wicket let you inject plain old services at all? Without Spring > DM, Blueprint or any other extension of OSGi core? Since I had no use-case for this I had completely forgotten about this feature :). Still in the current architecture (https://github.com/ops4j/org.ops4j.pax.wicket/blob/master/service/src/main/java/org/ops4j/pax/wicket/internal/injection/BundleAnalysingComponentInstantiationListener.java) nothing more than one Enum and one class (InjectionProvider) would be required to realize this (PAXWICKET-187). > - At first, I didn't realize that Pax Wicket wraps all of Wicket in its own > bundle - I was fooled by the fact that vanilla Wicket is also provisioned to > the sample runtime. > So the good news is that you don't depend on the broken > manifest of the official artifact, but in general I don't think it's a good > idea to wrap your dependencies instead of importing them. Yep; as said; since I got it I'd changed nothing on the structure. This will be done with PAXWICKET-184. > - From the intro: > "Develop the easiest possible solution to integrate wicket with OSGi" > > Well, I challenge you on that: wicket-osgi has 5 or 6 tiny classes which are > sufficient to support WABs with Wicket and OSGi service injection via > @Inject. Sure, Pax Wicket can do a lot more - but I was just looking for a > meal, and I didn't want to buy the restaurant... Basically true. But some points here 1) Size does not matter in this case IMHO. "Easiness" from a user point of view is not described at the size of a bundle but rather at how easy it is to use and if it gets into your way. 2) You may be able to do simple WAB and @Inject support but this is not the entire thing. But I think it is typical not enough. If you implement your wicket app you also have a spring or (want) a blueprint context. You need to inject this directly into your pages; you don't want the hassle with serialization; you want to split your pages and many more things. Well, typical WAB users may not know that they want this, but once they had the option they'll definitely use it 3) You're right currently wicket-osgi consists only of 5-6 small classes. Still if you follow the requirements on the mail thread on the wicket user list closely you know that this is not enough. To support the entire serialization and injection stuff throughout multiple bundles you'll end up with something REALLY similar to pax-wicket. And I don't think that this is worth re-inventing the wheel (although the existing wheel needs some fine-tuning). > - I'm not sure, but it seems Pax Wicket lets you install pages and > components as separate bundles and mount them into the web context of your > running application - if this is true, It is true; this is one of the core features of pax-wicket. Separate your classes in content into as many bundles as you like (even make it private), export them cleanly as OSGi services (or directly via bundles if you prefer) and import/aggregate them. The core features for aggregation are ContentSource/Aggregation Point and the PageFactory. > then I think that's really the > biggest value in this project and it would be nice to have a Wiki page > explaining the mechanics and giving some pointers into the sample code. Definitely true; Some of this points are already discussed here (http://ops4j1.jira.com/wiki/display/paxwicket/Core+Concepts). Still, those are much to lengthy and does not include all of the new features of 0.7.0 making working with those concepts much easier... I propose to layout the documentation first (gathering our thoughts at PAXWICKET-189) and I can rewrite the entire documentation than in one weekend... OK, long mail - long reply :) Thank you nevertheless for the detailed report and I hope I was able to answer at least some of your questions/tackle some of your problems. In addition I tried to structure the roadmap for pax-wicket 0.8.0 according to the (as I have to agree important points) mentioned in this mail. If you point your browser to http://ops4j1.jira.com/secure/VersionBoard.jspa?type=VB&selectedProjectId=10030&selectedBoardId=10681&colPage=1 you'll see the roadmap in the structure I think we should work on it. After you log-in you should also be able to move issue up or down to define their order. Feel free to add issues; add your comments to some or re-prioritize them. Kind regards, Andreas > > Best regards, > Harald > > > > > > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
