Extend wicket instrumentation to handle JSR 330

[kariem]

We want to port an existing code base largely using Wicket to Seam. The problem is that we do not want to replace the current DI mechanisms (mostly Spring's @Autowired and JSR 250's @Resource) with @In when JSRs 299 and 330 implementations are just around the corner.

For the time being, we plan to use @Inject in new or changed wicket components and retain existing DI instructions in the untouched code base. There are some alternatives we could follow

• Improve the current instrumentation by extending the org.jboss.seam.wicket.WicketComponent implementation so that the above annotations are processed in addition to @In.


• Use a current Weld version with Seam 3 beta and implement the appropriate SPI interfaces.


• Try to use @Configurable with compile-time weaving

At the current time we cannot really make a good decision on what route to pursue, but I hope somebody here can give either some insight or a recommendation. Instrumentation does not seem to be updated regularily, what makes us think that efforts in this area might not be welcome or useful. Seam 3 has not been released, so we are not sure about the Weld integration nor it's production-readiness as soon as it is released.

As most documentation is targeted towards EJB/JSF, I have to say that we are using WAR-only deployment (no embedded EJB) and Wicket.

Thank you in advance,

Kariem

[cpopetz]

The Weld releases (JSR-299 reference implementation, upon which Seam 3 will be based) has support for contextual injection of jsr-299 components into wicket components, as well as support for the jsr-299 conversation context in Wicket. This is done without instrumentation, as weld uses proxies at injection points.

-Clint

[kariem]

Thank you for the reply, Clint. As you are also in the list of authors of the JavassistInstrumentor used in the current seam-wicket version to support the integration of Wicket 1.3.x, I appreciate your recommendation very much.

I know that Seam 3 will be based on CDI and that Weld 1.0 already supports Wicket and JSR 330.

What I don't know is whether it is a good idea to submit a patch to support Wicket 1.4 in Seam 2.2 and extend the instrumentation in a way that handles @Inject similar to @In, or wait for Seam 3 to be released.

Currently I am using a build based on the 2.2 branch which works for me. Do you think I should be submitting a patch or wait for Seam 3? Any other options?

Thank you,

Kariem

[cpopetz]

Submitting a patch to support wicket 1.4 is fine, though it looks like a one line fix. As far as supporting @Inject in the 2.2 branch, that's not possible because the semantics of @Inject are so different from @In, and just making the former act like the latter in seam 2.2 really only saves you a find-and-replace, at a cost of much confusion to users.

[kariem]

First of all, thank you for the reply. Unfortunately, I believe my questions have not been answered. I do not want to repeat myself, but I will try to elaborate.

The main question is, should we try to provide patches for Seam 2.2 or wait for Seam 3 to be released, or use a stable Seam 3 build? Very important for this is the timeline for Seam 3 and when we can expect a stable version.

The details below

Submitting a patch to support wicket 1.4 is fine, though it looks like a one line fix.

This is true, the changes are not very difficult: I changed three lines in SeamWebApplication. However, I think this patch cannot be put into Seam 2.2, as it changes the library dependency from Wicket 1.3 to Wicket 1.4 which show API incompatibilities. Hence, the explicit question of putting this change in, which could break quite a few applications in 2.2.1 or 2.2.2 that do not expect dependency changes. From what I understand, this should go in 2.3. But as I am not that familiar, I posted this question here.

As far as supporting @Inject in the 2.2 branch, that's not possible because the semantics of @Inject are so different from @In, and just making the former act like the latter in seam 2.2 really only saves you a find-and-replace, at a cost of much confusion to users.

For my use case, it is only necessary to implement the field-level type-based semantics of @Inject. I would not try to make @Inject act like @In, because I have different requirements. The lookup would go through the Seam context, but also use a Spring application context.

The current wicket code base being migrated (see the opening sentence of the first post) code uses @SpringBean which has similar semantics to what @In should do. This is the only area where find and replace would be reasonable and for our use case this would be a huge benefit. As @SpringBean is one of the recommended ways and to what I have seen a popular way of using Spring together with Wicket, I think this integration could benefit some Wicket/Spring users wanting to migrate to Seam.

Thank you

Kariem

[cpopetz]

I would accept a patch to make the 2.2 branch use wicket 1.4. Although your use case for wanting to use @Inject in Seam 2.X is understandable, it's certainly not something that is general enough to be applied to a Seam 2.x release. My suggestion would be for you to develop with a local build of 2.x until Seam3 is available, or to move to Weld if you don't already have dependencies on Seam. I can't speak to the releae schedule of Seam3, though those inside RedHat might be able to do so.

[kariem]

Great response, Clint. Thank you very much for the recommendation. I will certainly follow it.

I will add the patch to JBSEAM-3421 as soon as I have verified it with my test application.

If we could receive some input from Redhat on the release schedule, I could make a decision on additional contributions from the project I am currently working on.

As you said (and I agree), my use case is not really applicable for Seam 2.x, but the first plan was to extend JavassistInstrumentor and the Maven Mojo to support custom WicketComponent/WicketHandler class names. This would allow for generic extensions to the injection mechanism. I can certainly put some effort into this and provide a working example.

Thank you very much, I will put an update here soon

Kariem

[kariem]

I have just added the previously mentioned patch to JBSEAM-3421. This has been tested in my setup, where I could not find any errors related to this change.

I have also added a feature request to open the instrumentation mechanisms currently provided in the seam-wicket integration: JBSEAM-4545. Corresponding patches for the seam-wicket integration and the maven instrumentation mojo are attached.

[kariem]

I have provided the discussed patches a few months ago. Do you have any hints on how we should continue? Will they be accepted for any upcoming 2.2?

I have also seen that weld-wicket will be moved to seam-wicket and JSR-299 support should be a part of that (SEAMWICKET-5). I would really like to use Seam with a current version of wicket. Is there any way I could contribute to the current efforts? Any open tasks nobody wants to do?