Re: Wicket and JEE6
It appears that I ran into an existing Glassfish V3 issue. The same issue occurs with passivation of regular EJBs that have an entitymanager injected. See https://glassfish.dev.java.net/issues/show_bug.cgi?id=11356
Re: Wicket and JEE6
I have found an elegant solution to the serialization problem.
Basically, in the ComponentInstantiationListener that perform injection, I
am also attaching a new InjectionBehavior. The injection behavior has a
private transient boolean field indicating whether injections are up to
date. Upon serialization/deserialization of a component, this field is reset
to false because it is transient. As a result, I can detect in the
beforeRender() method of the behavior whether I need to do injection.
The code of the component instantiationlistener is now as follows:
@Override
public void onInstantiation(Component aComponent) {
injector.inject(aComponent);
aComponent.add(new InjectionBehavior());
}
With the InjectionBahavior defined as follows:
public class InjectionBehavior extends AbstractBehavior {
private transient boolean injectionUptodate;
public InjectionBehavior() {
injectionUptodate = true;
}
@Override
public void beforeRender(Component aComponent) {
if (!injectionUptodate) {
InjectorBuilder.getInjector().inject(aComponent);
injectionUptodate = true;
}
}
}
This solution prevents unnecessary injection. This is required because
injection is expensive. For a simple class with only one injection I
measured only 1400 injections per second (I understand the weld project is
working on improving performance at the moment).
Another part of the solution is to be able to deal with detachable models
that need to keep a reference to an entity manager. The problem is that
these detachable models are also serialized/deserialized. For this I am
using a similar trick now to create a dynamic proxy of an entity manager
that delegates to a dynamically looked up version of the entity manager. The
lookup is done by creating a dummy object with a @persistenceContet in it
and using CDI to inject/obtain the entity manager. Here similarly, the
lookup caches the entity manager as a transient reference so it knows when
to recompute the entity manager.
The object that does this lookup is in fact a managed bean with a producer
method annoted with @Produces @ApplicationDatabase and @PersistenceContext:
public class EntityManagerLookup implements Lookup {
private static class EmHolder {
@PersistenceContext
private EntityManager em;
public EntityManager getEm() {
return em;
}
}
private transient EntityManager em;
@Override
public Object lookup() throws Exception {
if (em == null) {
EmHolder holder = new EmHolder();
InjectorBuilder.getInjector().inject(holder);
em = holder.getEm();
}
return em;
}
@Produces
@ApplicationDatabase
@PersistenceContext
public EntityManager getDefaultEntityManager() {
LookupProxyFactoryEntityManager factory = new
LookupProxyFactoryEntityManager(
EntityManager.class, new EntityManagerLookup());
return factory.getProxy();
}
}
Using this method, I can inject this serialization-safe entitymanager into
any object using
@Inject @ApplicationDatabase EntityManager entityManager;
So, in fact, I have a two-part solution. First of all it is robust in the
sense that @PersistenceContext still works. Second, I can also use a custom
injection to obtain serialization safe entity managers. When the entity
manager is obtained using the custom method however, problems can still
exist with for instance application scoped objects which also appear to be
serialized (this is in fact wrong as the objects will no longer be
application scoped because several copies are created).
A consequence of this solution is that all injected dependencies should be
declared as transient because this is more efficient.
The code for this can be found at http://utils.wamblee.org (wicket/inject,
support/inject, and support/cdi).
Re: Wicket and JEE6
I have done a lot of experimentation at the moment and I am using CDI dependency injection now for a simple wicket project. It is based on the code at utils.wamblee.org (wicket/inject). The issue I am running into is the following. I am creating a detachable entity object which is simply a detachable model that safes the primary key in onDetach() + sets the object to null. It loads the object from persistent storage using entityManager.find(class, key) in the get() method (if not yet initialized). The detachable model is constructed using an entity manager obtained using CDI. However, in the following scenario, things go wrong: (1) edit an entity in a form, (2) click ok, (3) browser back. What happens is that I get a NullPointerException in EntityManagerWrapper on line 314 on glassfish v3. What is actually happening here is that the detachable model is being serialized but the EntityManagerWrapper (the contextual that delegates to the actual entitymanager to use) has transient fields which become null after deserialization. The EntityManagerWrapper is declared Serializable but in fact it isn't. Now, I have to do two things. First I have to report an issue on glassfish v3. I think the entity manager wrapper should be truly serializable and not just declared serializable. Second, I need to work around this problem. The solution I am thinking of is to use a simple utility that provides a truly serializable entity manager that delegates to an entity manager obtained using CDI. That would solve the problem with the detachable. However, there is one more issue which is the injection setup in the application. I still need the injection at component instantiation to allow use of injected objects in the constructor. But I still have a question whether it would be required to also use a IComponentOnBeforeRenderListener to do an additional injection in the onBeforeRender() method. The only reason I would need to do this is when pages in wicket are serialized as well. Do I need to take page serialization into account? Is there also a callback in wicket to listen for component serialization and deserialization?
Re: Wicket and JEE6
On Thu, Jul 29, 2010 at 9:54 PM, Erik Brakkee erik.brak...@gmail.comwrote: Is there also a callback in wicket to listen for component serialization and deserialization? Googling for this it also seems possible to use an aspectj pointcut to do injection at deserialization.
Re: Wicket and JEE6
The problem with using the AspectJ-injected references occurs when you pass your reference to another class (such as a model, for instance). That class may not be instrumented via AspectJ to handle the serialization/deserialization properly for that reference. So, it will fail. On Thu, Jul 29, 2010 at 4:14 PM, Erik Brakkee erik.brak...@gmail.com wrote: On Thu, Jul 29, 2010 at 9:54 PM, Erik Brakkee erik.brak...@gmail.comwrote: Is there also a callback in wicket to listen for component serialization and deserialization? Googling for this it also seems possible to use an aspectj pointcut to do injection at deserialization. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
On Thu, Jul 29, 2010 at 10:18 PM, James Carman ja...@carmanconsulting.comwrote: The problem with using the AspectJ-injected references occurs when you pass your reference to another class (such as a model, for instance). That class may not be instrumented via AspectJ to handle the serialization/deserialization properly for that reference. So, it will fail. I also think it is a dodgy approach with aspect J and that it's best to avoid it. Also, because it involves additional configuration and more complexity. The simplest solution appears to be to inject using the onBeforeRender listener. The disadvantage is however that I will be doing this injection too many times (every construction and onBeforeRender).
Re: Wicket and JEE6
On Mon, Apr 12, 2010 at 12:12 AM, James Carman jcar...@carmanconsulting.com wrote: I would imagine that most implementations would cache their injectors (it's part of the BeanT) I was triggered by the remark in the WeldCOmponentInstantiationListener which says 'TODO Cache the NonContextual' Also, the NonContextual implementation itself mentions this 'Store the injection target. The CDI spec doesn't require an implementation to cache it, so we do' Therefore, it is probably safer to do the caching ourselves hen to rely on caching by the beanmanager.
Re: Wicket and JEE6
Just have a look at https://wamblee.org/svn/public/wicket-cdi The main thing I did was to make the injection and caching stuff completely independent of wicket and I made some arrangements to still allow unit tests where you can inject different things from the defaults. In particular, I think you can incorporate the InjectorCache in your design and it would also be good to make the injection support independent of wicket. Basically, the org.wamblee.cdi package tries to provide a simple and efficient injection api (bean manager api is too general and too verbose for most purposes)
Re: Wicket and JEE6
I would imagine that most implementations would cache their injectors (it's part of the BeanT) On Sun, Apr 11, 2010 at 4:30 PM, Erik Brakkee erik.brak...@gmail.com wrote: Just have a look at https://wamblee.org/svn/public/wicket-cdi The main thing I did was to make the injection and caching stuff completely independent of wicket and I made some arrangements to still allow unit tests where you can inject different things from the defaults. In particular, I think you can incorporate the InjectorCache in your design and it would also be good to make the injection support independent of wicket. Basically, the org.wamblee.cdi package tries to provide a simple and efficient injection api (bean manager api is too general and too verbose for most purposes) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
On Mon, Apr 5, 2010 at 11:58 PM, James Carman jcar...@carmanconsulting.comwrote: What I'll do is set it up in wicketstuff. That way others can contribute/maintain it too. I've got permission already, so I can put it up there sometime this evening. Do you have a location already for the source? I still think that wicket core would be a better place since wicket-spring and wicket-guice are also already there. Meanwhile I also did some refactoring already and implemented caching Not much is left of the original code, but I think it is simpler the way I have it now. A side effect is that I also have a simple Injector class that can be used to perform injection into any class. Almost all code I have a is wicket-independent and the ComponentInstantiationListener is basically a one-liner now.
Re: Wicket and JEE6
My implementation is available at: http://svn.carmanconsulting.com/public/wicket-cdi/trunk/ The CdiPlugin class has an inject() method that can be used to inject anything, also. On Sat, Apr 10, 2010 at 5:11 PM, Erik Brakkee erik.brak...@gmail.com wrote: On Mon, Apr 5, 2010 at 11:58 PM, James Carman jcar...@carmanconsulting.comwrote: What I'll do is set it up in wicketstuff. That way others can contribute/maintain it too. I've got permission already, so I can put it up there sometime this evening. Do you have a location already for the source? I still think that wicket core would be a better place since wicket-spring and wicket-guice are also already there. Meanwhile I also did some refactoring already and implemented caching Not much is left of the original code, but I think it is simpler the way I have it now. A side effect is that I also have a simple Injector class that can be used to perform injection into any class. Almost all code I have a is wicket-independent and the ComponentInstantiationListener is basically a one-liner now. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
On Wed, Mar 31, 2010 at 5:05 AM, Iskandar Salim locrianm...@gmail.comwrote: Olivier Bourgeois-2 wrote: ... everything is simple unmanaged POJOs except for your classes extending WebPage which are managed Not to be picky but a minor correction :) everything is simple unmanaged POJOs except for your classes extending [Component] which are managed I wonder what the use would be for the request, session, and conversation scopes in wicket since these are already managed expiicitly in wicket. At least, I wouldn't see a great need for such scopemanagement by the container. It would be nice however if CDI could be used to inject EJBs, resources, and OSGI services into pages. -- View this message in context: http://old.nabble.com/Wicket-and-JEE6-tp28045129p28091022.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
I wonder what the use would be for the request, session, and conversation
scopes in wicket since these are already managed expiicitly in wicket. At
least, I wouldn't see a great need for such scopemanagement by the
container. It would be nice however if CDI could be used to inject EJBs,
resources, and OSGI services into pages.
Sorry for the mail bombing but just got @EJB injection to work based on the
weld-wicket integration. With this setup the only thing I am missing is
probably the long-lived convesations support, but that is not essential for
me. Essential is the link to ejbs and container resources and the converged
container support in Java EE6 which will simplify a lot.
The main trick is to register only the component instantiation listener from
weld-wicket in the application class.
class WicketApplication extends WebApplication {
private NonContextualWeldComponentInstantiationListener
weldComponentInstantiationListener;
/**
* Constructor
*/
public WicketApplication() {
// Empty.
}
@Override
protected void init() {
BeanManager mgr = BeanManagerLookup.getBeanManager();
System.out.println(BeanManager ' + mgr + ');
this.weldComponentInstantiationListener = new
NonContextualWeldComponentInstantiationListener(BeanManagerLookup.getBeanManager(),
WeldComponentInstantiationListener.class);
addComponentInstantiationListener(weldComponentInstantiationListener.newInstance().produce().inject().get());
}
...
}
Next is simply the use of @EJB in a regular page object.
This works without having to patch the application server.
Re: Wicket and JEE6
Did you not look at what I put together? I've already got all the
injection stuff (and conversations) working and I've got example
applications illustrating it.
On Mon, Apr 5, 2010 at 3:47 PM, Erik Brakkee erik.brak...@gmail.com wrote:
I wonder what the use would be for the request, session, and conversation
scopes in wicket since these are already managed expiicitly in wicket. At
least, I wouldn't see a great need for such scopemanagement by the
container. It would be nice however if CDI could be used to inject EJBs,
resources, and OSGI services into pages.
Sorry for the mail bombing but just got @EJB injection to work based on the
weld-wicket integration. With this setup the only thing I am missing is
probably the long-lived convesations support, but that is not essential for
me. Essential is the link to ejbs and container resources and the converged
container support in Java EE6 which will simplify a lot.
The main trick is to register only the component instantiation listener from
weld-wicket in the application class.
class WicketApplication extends WebApplication {
private NonContextualWeldComponentInstantiationListener
weldComponentInstantiationListener;
/**
* Constructor
*/
public WicketApplication() {
// Empty.
}
�...@override
protected void init() {
BeanManager mgr = BeanManagerLookup.getBeanManager();
System.out.println(BeanManager ' + mgr + ');
this.weldComponentInstantiationListener = new
NonContextualWeldComponentInstantiationListener(BeanManagerLookup.getBeanManager(),
WeldComponentInstantiationListener.class);
addComponentInstantiationListener(weldComponentInstantiationListener.newInstance().produce().inject().get());
}
...
}
Next is simply the use of @EJB in a regular page object.
This works without having to patch the application server.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
On Mon, Apr 5, 2010 at 9:54 PM, James Carman jcar...@carmanconsulting.comwrote: Did you not look at what I put together? I've already got all the injection stuff (and conversations) working and I've got example applications illustrating it. I tried to look at it but couldn't access the subversion repo because of timeouts. Atter looking at the code of weld-wicket and seeing that it was just a small amount of code, it was relatively easy to figure out what is was doing and disable the long-lived conversations support. The URL I am trying is: http://svn.carmanconsulting.com/public/wicket-cdi/trunk Can you make sure the URL is working again? I will then have a look at it. The aim would be for an implementation that is completely independent of weld, i.e. does not use any weld core classes and only uses standard CDI APIs and wicket APIs. (to avoid the problem of having to patch the application server).
Re: Wicket and JEE6
It's apparently down again. That's what I get for hosting my server at my in-law's house. Cheaper isn't necessarily better. If you want, I can email you the code. On Mon, Apr 5, 2010 at 4:32 PM, Erik Brakkee erik.brak...@gmail.com wrote: On Mon, Apr 5, 2010 at 9:54 PM, James Carman jcar...@carmanconsulting.comwrote: Did you not look at what I put together? I've already got all the injection stuff (and conversations) working and I've got example applications illustrating it. I tried to look at it but couldn't access the subversion repo because of timeouts. Atter looking at the code of weld-wicket and seeing that it was just a small amount of code, it was relatively easy to figure out what is was doing and disable the long-lived conversations support. The URL I am trying is: http://svn.carmanconsulting.com/public/wicket-cdi/trunk Can you make sure the URL is working again? I will then have a look at it. The aim would be for an implementation that is completely independent of weld, i.e. does not use any weld core classes and only uses standard CDI APIs and wicket APIs. (to avoid the problem of having to patch the application server). - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
On Mon, Apr 5, 2010 at 10:37 PM, James Carman jcar...@carmanconsulting.comwrote: It's apparently down again. That's what I get for hosting my server at my in-law's house. Cheaper isn't necessarily better. If you want, I can email you the code. You can mail the code to me. If it's not too much code, you can also mail it to the list I guess. I think in general, the code should become part of a wicket-cdi project just like wicket-spring and wicket-guice already are. I think the wicket community is probably a better place to maintain this then the weld project. This is because the code could use internal wicket APIs which are more prone to change than the CDI APIs which is a standard. So we would catch problems in the implementation much earlier. It feels a bit like stealing but I am in any case really grateful for the work done by the weld project. This is surely going to save a lot of people some time because standard Java EE capabilities can be used in wicket.
Re: Wicket and JEE6
On Mon, Apr 5, 2010 at 5:27 PM, Erik Brakkee erik.brak...@gmail.com wrote: I think in general, the code should become part of a wicket-cdi project just like wicket-spring and wicket-guice already are. I think the wicket community is probably a better place to maintain this then the weld project. This is because the code could use internal wicket APIs which are more prone to change than the CDI APIs which is a standard. So we would catch problems in the implementation much earlier. It feels a bit like stealing but I am in any case really grateful for the work done by the weld project. This is surely going to save a lot of people some time because standard Java EE capabilities can be used in wicket. What I'll do is set it up in wicketstuff. That way others can contribute/maintain it too. I've got permission already, so I can put it up there sometime this evening. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
Ok, I think I've got the conversation stuff working properly. My
current example is a version of the numberguess game which makes the
Game bean a @ConversationScoped object. It's not a good example of
a conversation per se, but I'd like to beef up the example
application to show off more of what CDI can do in the near future.
Please feel free to check it out. If there is enough interest, I'll
just move this stuff into wicketstuff SVN (and change the package
names), so other folks can contribute.
On Tue, Mar 30, 2010 at 8:54 AM, James Carman
jcar...@carmanconsulting.com wrote:
I think everything I've done is checked in currently. I'll take a look at
your patches later and see how things shake out. One thing I noticed was
that my beans weren't being picked up from my local project if I didn't
include a src/main/resources/META-INF/beans.xml file in there. I guess the
classpath scanning looks for all of those resources and scans those
locations only or something. Again, thanks for taking a look at what I put
together. I plan on doing the conversation stuff very soon, so stay tuned.
On Tue, Mar 30, 2010 at 7:43 AM, Cemal Bayramoglu
jweekend_for...@cabouge.com wrote:
James,
I'm pretty sure mvn test ran successfully on all your projects once
I patched the POMs.
I ran some (maybe not all) of the demo apps too.
Send me your patches if you like too (they must not have been deployed
yet on Sunday) and I may be able to take another look this evening or
tomorrow PM.
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
On 30 March 2010 12:30, James Carman jcar...@carmanconsulting.com wrote:
I was using M4 of OWB, but I had to patch it. Are you sure it works for
you? I was getting a NPE.
On Tue, Mar 30, 2010 at 7:22 AM, Cemal Bayramoglu
jweekend_for...@cabouge.com wrote:
James,
See the patch below; please double-check but it should be still valid
if you haven't updated your POMs since Sunday AM your time.
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
== PATCH STARTS BELOW =
Index: pom.xml
===
--- pom.xml (revision 78)
+++ pom.xml (working copy)
@@ -36,4 +36,22 @@
/plugin
/plugins
/build
+
+ repositories
+ repository
+ idJBoss Repo/id
+ urlhttp://repository.jboss.com/maven2/url
+ /repository
+
+ repository
+ idgeronimo-snapshots/id
+ nameApache Nexus Snapshots/name
+
urlhttps://repository.apache.org/content/groups/snapshots-group/url
+ snapshots
+ enabledtrue/enabled
+ /snapshots
+ /repository
+
+ /repositories
+
/project
\ No newline at end of file
Index: owb/pom.xml
===
--- owb/pom.xml (revision 78)
+++ owb/pom.xml (working copy)
@@ -16,11 +16,12 @@
artifactIdwicket-cdi/artifactId
version${project.version}/version
/dependency
- dependency
- groupIdorg.apache.openwebbeans/groupId
- artifactIdopenwebbeans-impl/artifactId
- version1.0.0-SNAPSHOT/version
- /dependency
+dependency
+ groupIdorg.apache.openwebbeans/groupId
+ artifactIdopenwebbeans-impl/artifactId
+ version1.0.0-M4/version
+/dependency
+
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-jcdi_1.0_spec/artifactId
Index: owb-example/pom.xml
===
--- owb-example/pom.xml (revision 78)
+++ owb-example/pom.xml (working copy)
@@ -62,15 +62,11 @@
artifactIdwicket-cdi-owb/artifactId
version${project.version}/version
/dependency
- dependency
- groupIdorg.apache.openwebbeans/groupId
- artifactIdopenwebbeans-web/artifactId
- version1.0.0-SNAPSHOT/version
- /dependency
+
dependency
groupIdorg.apache.openwebbeans/groupId
artifactIdopenwebbeans-spi/artifactId
- version1.0.0-SNAPSHOT/version
+ version1.0.0-M4/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
== END OF PATCH ABOVE
On 30 March 2010 12:09, James Carman jcar...@carmanconsulting.com
wrote:
Cemal,
Please feel free to send me a patch if anything looks crazy. I have
had
a
heck of a time getting all this stuff working. It's a delicate
balance
(like herding cats)! :) The OWB folks have checked in
Re: Wicket and JEE6
I do also think that it's because Wicket is not a managed framework : everything is simple unmanaged POJOs except for your classes extending WebPage which are managed. I've juste had a quick look at JSF 2.0 and never worked with it - but I worked with Wicket - so I did not expected Wicket JEE6 integration to be a drop in replacement for JSF. I do think Wicket is an alternative framework for JEE6, not a replacement of the reference framework. On one hand JSF2 assumes that you are running a JEE6 AS, so it is tightly integrated with CDI, and you got all the cool stuff like injection, scopes, bean validation, etc. On the other hand, Wicket doesn't assume anything except a web container implementing the servlet spec, so it can't have all the cool stuff of CDI because it's not built around CDI. I think the next step to make Wicket JEE6 integration going further is to provide some Maven quickstart archetypes, the Weld team is looking for contributors : http://in.relation.to/Bloggers/WeldArchetypesInTheSpotlight Now that I have something working, and when I will have some spare time, my next step is to create an archetype for Glassfish. And if some people on this list have some time, their help is of course welcome :)
Re: Wicket and JEE6
Olivier, I got Jame's stuff [1] up and running (thanks James) with just a few small changes to the POMs - maybe he has stuff already in his local Maven repo that is no longer on the main public repos) working with little effort. If you'd like to make (and maintain ;-) an archetype out of those (based on Apache implementations), or a Galssfish based one, we would be happy to include those on our LegUp page [2][3]. Regards - Cemal jWeekend OO Java Technologies, Wicket Consulting, Development, Training http://jWeekend.com [1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk [2] http://jweekend.com/dev/LegUp [3] http://code.google.com/p/legup/ On 30 March 2010 10:24, Olivier Bourgeois olivier.bourgeois@gmail.com wrote: I do also think that it's because Wicket is not a managed framework : everything is simple unmanaged POJOs except for your classes extending WebPage which are managed. I've juste had a quick look at JSF 2.0 and never worked with it - but I worked with Wicket - so I did not expected Wicket JEE6 integration to be a drop in replacement for JSF. I do think Wicket is an alternative framework for JEE6, not a replacement of the reference framework. On one hand JSF2 assumes that you are running a JEE6 AS, so it is tightly integrated with CDI, and you got all the cool stuff like injection, scopes, bean validation, etc. On the other hand, Wicket doesn't assume anything except a web container implementing the servlet spec, so it can't have all the cool stuff of CDI because it's not built around CDI. I think the next step to make Wicket JEE6 integration going further is to provide some Maven quickstart archetypes, the Weld team is looking for contributors : http://in.relation.to/Bloggers/WeldArchetypesInTheSpotlight Now that I have something working, and when I will have some spare time, my next step is to create an archetype for Glassfish. And if some people on this list have some time, their help is of course welcome :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
Cemal, Please feel free to send me a patch if anything looks crazy. I have had a heck of a time getting all this stuff working. It's a delicate balance (like herding cats)! :) The OWB folks have checked in my patch to fix one of the issues, but we're still hammering out another. Thanks, James On Tue, Mar 30, 2010 at 7:05 AM, Cemal Bayramoglu jweekend_for...@cabouge.com wrote: Olivier, I got Jame's stuff [1] up and running (thanks James) with just a few small changes to the POMs - maybe he has stuff already in his local Maven repo that is no longer on the main public repos) working with little effort. If you'd like to make (and maintain ;-) an archetype out of those (based on Apache implementations), or a Galssfish based one, we would be happy to include those on our LegUp page [2][3]. Regards - Cemal jWeekend OO Java Technologies, Wicket Consulting, Development, Training http://jWeekend.com [1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk [2] http://jweekend.com/dev/LegUp [3] http://code.google.com/p/legup/ On 30 March 2010 10:24, Olivier Bourgeois olivier.bourgeois@gmail.com wrote: I do also think that it's because Wicket is not a managed framework : everything is simple unmanaged POJOs except for your classes extending WebPage which are managed. I've juste had a quick look at JSF 2.0 and never worked with it - but I worked with Wicket - so I did not expected Wicket JEE6 integration to be a drop in replacement for JSF. I do think Wicket is an alternative framework for JEE6, not a replacement of the reference framework. On one hand JSF2 assumes that you are running a JEE6 AS, so it is tightly integrated with CDI, and you got all the cool stuff like injection, scopes, bean validation, etc. On the other hand, Wicket doesn't assume anything except a web container implementing the servlet spec, so it can't have all the cool stuff of CDI because it's not built around CDI. I think the next step to make Wicket JEE6 integration going further is to provide some Maven quickstart archetypes, the Weld team is looking for contributors : http://in.relation.to/Bloggers/WeldArchetypesInTheSpotlight Now that I have something working, and when I will have some spare time, my next step is to create an archetype for Glassfish. And if some people on this list have some time, their help is of course welcome :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
James,
See the patch below; please double-check but it should be still valid
if you haven't updated your POMs since Sunday AM your time.
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
== PATCH STARTS BELOW =
Index: pom.xml
===
--- pom.xml (revision 78)
+++ pom.xml (working copy)
@@ -36,4 +36,22 @@
/plugin
/plugins
/build
+
+ repositories
+repository
+idJBoss Repo/id
+urlhttp://repository.jboss.com/maven2/url
+/repository
+
+ repository
+ idgeronimo-snapshots/id
+ nameApache Nexus Snapshots/name
+
urlhttps://repository.apache.org/content/groups/snapshots-group/url
+ snapshots
+ enabledtrue/enabled
+ /snapshots
+ /repository
+
+/repositories
+
/project
\ No newline at end of file
Index: owb/pom.xml
===
--- owb/pom.xml (revision 78)
+++ owb/pom.xml (working copy)
@@ -16,11 +16,12 @@
artifactIdwicket-cdi/artifactId
version${project.version}/version
/dependency
-dependency
-groupIdorg.apache.openwebbeans/groupId
-artifactIdopenwebbeans-impl/artifactId
-version1.0.0-SNAPSHOT/version
-/dependency
+dependency
+groupIdorg.apache.openwebbeans/groupId
+artifactIdopenwebbeans-impl/artifactId
+version1.0.0-M4/version
+/dependency
+
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-jcdi_1.0_spec/artifactId
Index: owb-example/pom.xml
===
--- owb-example/pom.xml (revision 78)
+++ owb-example/pom.xml (working copy)
@@ -62,15 +62,11 @@
artifactIdwicket-cdi-owb/artifactId
version${project.version}/version
/dependency
-dependency
-groupIdorg.apache.openwebbeans/groupId
-artifactIdopenwebbeans-web/artifactId
-version1.0.0-SNAPSHOT/version
-/dependency
+
dependency
groupIdorg.apache.openwebbeans/groupId
artifactIdopenwebbeans-spi/artifactId
-version1.0.0-SNAPSHOT/version
+version1.0.0-M4/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
== END OF PATCH ABOVE
On 30 March 2010 12:09, James Carman jcar...@carmanconsulting.com wrote:
Cemal,
Please feel free to send me a patch if anything looks crazy. I have had a
heck of a time getting all this stuff working. It's a delicate balance
(like herding cats)! :) The OWB folks have checked in my patch to fix one
of the issues, but we're still hammering out another.
Thanks,
James
On Tue, Mar 30, 2010 at 7:05 AM, Cemal Bayramoglu
jweekend_for...@cabouge.com wrote:
Olivier,
I got Jame's stuff [1] up and running (thanks James) with just a few
small changes to the POMs - maybe he has stuff already in his local
Maven repo that is no longer on the main public repos) working with
little effort.
If you'd like to make (and maintain ;-) an archetype out of those
(based on Apache implementations), or a Galssfish based one, we would
be happy to include those on our LegUp page [2][3].
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
[1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
[2] http://jweekend.com/dev/LegUp
[3] http://code.google.com/p/legup/
On 30 March 2010 10:24, Olivier Bourgeois
olivier.bourgeois@gmail.com wrote:
I do also think that it's because Wicket is not a managed framework :
everything is simple unmanaged POJOs except for your classes extending
WebPage which are managed. I've juste had a quick look at JSF 2.0 and
never worked with it - but I worked with Wicket - so I did not expected
Wicket JEE6 integration to be a drop in replacement for JSF. I do think
Wicket is an alternative framework for JEE6, not a replacement of the
reference framework.
On one hand JSF2 assumes that you are running a JEE6 AS, so it is tightly
integrated with CDI, and you got all the cool stuff like injection,
scopes,
bean validation, etc. On the other hand, Wicket doesn't assume anything
except a web container implementing the servlet spec, so it can't have
all
the cool stuff of CDI because it's not built around CDI.
I think the next step to make Wicket JEE6 integration going further is to
provide some Maven quickstart archetypes, the Weld team is looking for
contributors :
http://in.relation.to/Bloggers/WeldArchetypesInTheSpotlight
Now that I have something working, and when I will have some
Re: Wicket and JEE6
I was using M4 of OWB, but I had to patch it. Are you sure it works for
you? I was getting a NPE.
On Tue, Mar 30, 2010 at 7:22 AM, Cemal Bayramoglu
jweekend_for...@cabouge.com wrote:
James,
See the patch below; please double-check but it should be still valid
if you haven't updated your POMs since Sunday AM your time.
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
== PATCH STARTS BELOW =
Index: pom.xml
===
--- pom.xml (revision 78)
+++ pom.xml (working copy)
@@ -36,4 +36,22 @@
/plugin
/plugins
/build
+
+ repositories
+repository
+idJBoss Repo/id
+urlhttp://repository.jboss.com/maven2/url
+/repository
+
+ repository
+ idgeronimo-snapshots/id
+ nameApache Nexus Snapshots/name
+
urlhttps://repository.apache.org/content/groups/snapshots-group/url
+ snapshots
+ enabledtrue/enabled
+ /snapshots
+ /repository
+
+/repositories
+
/project
\ No newline at end of file
Index: owb/pom.xml
===
--- owb/pom.xml (revision 78)
+++ owb/pom.xml (working copy)
@@ -16,11 +16,12 @@
artifactIdwicket-cdi/artifactId
version${project.version}/version
/dependency
-dependency
-groupIdorg.apache.openwebbeans/groupId
-artifactIdopenwebbeans-impl/artifactId
-version1.0.0-SNAPSHOT/version
-/dependency
+dependency
+groupIdorg.apache.openwebbeans/groupId
+artifactIdopenwebbeans-impl/artifactId
+version1.0.0-M4/version
+/dependency
+
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-jcdi_1.0_spec/artifactId
Index: owb-example/pom.xml
===
--- owb-example/pom.xml (revision 78)
+++ owb-example/pom.xml (working copy)
@@ -62,15 +62,11 @@
artifactIdwicket-cdi-owb/artifactId
version${project.version}/version
/dependency
-dependency
-groupIdorg.apache.openwebbeans/groupId
-artifactIdopenwebbeans-web/artifactId
-version1.0.0-SNAPSHOT/version
-/dependency
+
dependency
groupIdorg.apache.openwebbeans/groupId
artifactIdopenwebbeans-spi/artifactId
-version1.0.0-SNAPSHOT/version
+version1.0.0-M4/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
== END OF PATCH ABOVE
On 30 March 2010 12:09, James Carman jcar...@carmanconsulting.com wrote:
Cemal,
Please feel free to send me a patch if anything looks crazy. I have had
a
heck of a time getting all this stuff working. It's a delicate balance
(like herding cats)! :) The OWB folks have checked in my patch to fix
one
of the issues, but we're still hammering out another.
Thanks,
James
On Tue, Mar 30, 2010 at 7:05 AM, Cemal Bayramoglu
jweekend_for...@cabouge.com wrote:
Olivier,
I got Jame's stuff [1] up and running (thanks James) with just a few
small changes to the POMs - maybe he has stuff already in his local
Maven repo that is no longer on the main public repos) working with
little effort.
If you'd like to make (and maintain ;-) an archetype out of those
(based on Apache implementations), or a Galssfish based one, we would
be happy to include those on our LegUp page [2][3].
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
[1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
[2] http://jweekend.com/dev/LegUp
[3] http://code.google.com/p/legup/
On 30 March 2010 10:24, Olivier Bourgeois
olivier.bourgeois@gmail.com wrote:
I do also think that it's because Wicket is not a managed framework :
everything is simple unmanaged POJOs except for your classes extending
WebPage which are managed. I've juste had a quick look at JSF 2.0
and
never worked with it - but I worked with Wicket - so I did not
expected
Wicket JEE6 integration to be a drop in replacement for JSF. I do
think
Wicket is an alternative framework for JEE6, not a replacement of the
reference framework.
On one hand JSF2 assumes that you are running a JEE6 AS, so it is
tightly
integrated with CDI, and you got all the cool stuff like injection,
scopes,
bean validation, etc. On the other hand, Wicket doesn't assume
anything
except a web container implementing the servlet spec, so it can't have
all
the cool stuff of CDI because it's
Re: Wicket and JEE6
James,
I'm pretty sure mvn test ran successfully on all your projects once
I patched the POMs.
I ran some (maybe not all) of the demo apps too.
Send me your patches if you like too (they must not have been deployed
yet on Sunday) and I may be able to take another look this evening or
tomorrow PM.
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
On 30 March 2010 12:30, James Carman jcar...@carmanconsulting.com wrote:
I was using M4 of OWB, but I had to patch it. Are you sure it works for
you? I was getting a NPE.
On Tue, Mar 30, 2010 at 7:22 AM, Cemal Bayramoglu
jweekend_for...@cabouge.com wrote:
James,
See the patch below; please double-check but it should be still valid
if you haven't updated your POMs since Sunday AM your time.
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
== PATCH STARTS BELOW =
Index: pom.xml
===
--- pom.xml (revision 78)
+++ pom.xml (working copy)
@@ -36,4 +36,22 @@
/plugin
/plugins
/build
+
+ repositories
+ repository
+ idJBoss Repo/id
+ urlhttp://repository.jboss.com/maven2/url
+ /repository
+
+ repository
+ idgeronimo-snapshots/id
+ nameApache Nexus Snapshots/name
+
urlhttps://repository.apache.org/content/groups/snapshots-group/url
+ snapshots
+ enabledtrue/enabled
+ /snapshots
+ /repository
+
+ /repositories
+
/project
\ No newline at end of file
Index: owb/pom.xml
===
--- owb/pom.xml (revision 78)
+++ owb/pom.xml (working copy)
@@ -16,11 +16,12 @@
artifactIdwicket-cdi/artifactId
version${project.version}/version
/dependency
- dependency
- groupIdorg.apache.openwebbeans/groupId
- artifactIdopenwebbeans-impl/artifactId
- version1.0.0-SNAPSHOT/version
- /dependency
+dependency
+ groupIdorg.apache.openwebbeans/groupId
+ artifactIdopenwebbeans-impl/artifactId
+ version1.0.0-M4/version
+/dependency
+
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-jcdi_1.0_spec/artifactId
Index: owb-example/pom.xml
===
--- owb-example/pom.xml (revision 78)
+++ owb-example/pom.xml (working copy)
@@ -62,15 +62,11 @@
artifactIdwicket-cdi-owb/artifactId
version${project.version}/version
/dependency
- dependency
- groupIdorg.apache.openwebbeans/groupId
- artifactIdopenwebbeans-web/artifactId
- version1.0.0-SNAPSHOT/version
- /dependency
+
dependency
groupIdorg.apache.openwebbeans/groupId
artifactIdopenwebbeans-spi/artifactId
- version1.0.0-SNAPSHOT/version
+ version1.0.0-M4/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
== END OF PATCH ABOVE
On 30 March 2010 12:09, James Carman jcar...@carmanconsulting.com wrote:
Cemal,
Please feel free to send me a patch if anything looks crazy. I have had
a
heck of a time getting all this stuff working. It's a delicate balance
(like herding cats)! :) The OWB folks have checked in my patch to fix
one
of the issues, but we're still hammering out another.
Thanks,
James
On Tue, Mar 30, 2010 at 7:05 AM, Cemal Bayramoglu
jweekend_for...@cabouge.com wrote:
Olivier,
I got Jame's stuff [1] up and running (thanks James) with just a few
small changes to the POMs - maybe he has stuff already in his local
Maven repo that is no longer on the main public repos) working with
little effort.
If you'd like to make (and maintain ;-) an archetype out of those
(based on Apache implementations), or a Galssfish based one, we would
be happy to include those on our LegUp page [2][3].
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
[1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk
[2] http://jweekend.com/dev/LegUp
[3] http://code.google.com/p/legup/
On 30 March 2010 10:24, Olivier Bourgeois
olivier.bourgeois@gmail.com wrote:
I do also think that it's because Wicket is not a managed framework :
everything is simple unmanaged POJOs except for your classes extending
WebPage which are managed. I've juste had a quick look at JSF 2.0
and
never worked with it - but I worked with Wicket - so I did not
expected
Wicket JEE6 integration to be a drop in
Re: Wicket and JEE6
I think everything I've done is checked in currently. I'll take a look at
your patches later and see how things shake out. One thing I noticed was
that my beans weren't being picked up from my local project if I didn't
include a src/main/resources/META-INF/beans.xml file in there. I guess the
classpath scanning looks for all of those resources and scans those
locations only or something. Again, thanks for taking a look at what I put
together. I plan on doing the conversation stuff very soon, so stay tuned.
On Tue, Mar 30, 2010 at 7:43 AM, Cemal Bayramoglu
jweekend_for...@cabouge.com wrote:
James,
I'm pretty sure mvn test ran successfully on all your projects once
I patched the POMs.
I ran some (maybe not all) of the demo apps too.
Send me your patches if you like too (they must not have been deployed
yet on Sunday) and I may be able to take another look this evening or
tomorrow PM.
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
On 30 March 2010 12:30, James Carman jcar...@carmanconsulting.com wrote:
I was using M4 of OWB, but I had to patch it. Are you sure it works for
you? I was getting a NPE.
On Tue, Mar 30, 2010 at 7:22 AM, Cemal Bayramoglu
jweekend_for...@cabouge.com wrote:
James,
See the patch below; please double-check but it should be still valid
if you haven't updated your POMs since Sunday AM your time.
Regards - Cemal
jWeekend
OO Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com
== PATCH STARTS BELOW =
Index: pom.xml
===
--- pom.xml (revision 78)
+++ pom.xml (working copy)
@@ -36,4 +36,22 @@
/plugin
/plugins
/build
+
+ repositories
+repository
+idJBoss Repo/id
+urlhttp://repository.jboss.com/maven2/url
+/repository
+
+ repository
+ idgeronimo-snapshots/id
+ nameApache Nexus Snapshots/name
+
urlhttps://repository.apache.org/content/groups/snapshots-group/url
+ snapshots
+ enabledtrue/enabled
+ /snapshots
+ /repository
+
+/repositories
+
/project
\ No newline at end of file
Index: owb/pom.xml
===
--- owb/pom.xml (revision 78)
+++ owb/pom.xml (working copy)
@@ -16,11 +16,12 @@
artifactIdwicket-cdi/artifactId
version${project.version}/version
/dependency
-dependency
-groupIdorg.apache.openwebbeans/groupId
-artifactIdopenwebbeans-impl/artifactId
-version1.0.0-SNAPSHOT/version
-/dependency
+dependency
+groupIdorg.apache.openwebbeans/groupId
+artifactIdopenwebbeans-impl/artifactId
+version1.0.0-M4/version
+/dependency
+
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-jcdi_1.0_spec/artifactId
Index: owb-example/pom.xml
===
--- owb-example/pom.xml (revision 78)
+++ owb-example/pom.xml (working copy)
@@ -62,15 +62,11 @@
artifactIdwicket-cdi-owb/artifactId
version${project.version}/version
/dependency
-dependency
-groupIdorg.apache.openwebbeans/groupId
-artifactIdopenwebbeans-web/artifactId
-version1.0.0-SNAPSHOT/version
-/dependency
+
dependency
groupIdorg.apache.openwebbeans/groupId
artifactIdopenwebbeans-spi/artifactId
-version1.0.0-SNAPSHOT/version
+version1.0.0-M4/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
== END OF PATCH ABOVE
On 30 March 2010 12:09, James Carman jcar...@carmanconsulting.com
wrote:
Cemal,
Please feel free to send me a patch if anything looks crazy. I have
had
a
heck of a time getting all this stuff working. It's a delicate
balance
(like herding cats)! :) The OWB folks have checked in my patch to fix
one
of the issues, but we're still hammering out another.
Thanks,
James
On Tue, Mar 30, 2010 at 7:05 AM, Cemal Bayramoglu
jweekend_for...@cabouge.com wrote:
Olivier,
I got Jame's stuff [1] up and running (thanks James) with just a few
small changes to the POMs - maybe he has stuff already in his local
Maven repo that is no longer on the main public repos) working with
little effort.
If you'd like to make (and maintain ;-) an archetype out of those
(based on Apache implementations), or a Galssfish based one, we
would
Re: Wicket and JEE6
2010/3/30 Cemal Bayramoglu jweekend_for...@cabouge.com Olivier, I got Jame's stuff [1] up and running (thanks James) with just a few small changes to the POMs - maybe he has stuff already in his local Maven repo that is no longer on the main public repos) working with little effort. If you'd like to make (and maintain ;-) an archetype out of those (based on Apache implementations), or a Galssfish based one, we would be happy to include those on our LegUp page [2][3]. Regards - Cemal jWeekend OO Java Technologies, Wicket Consulting, Development, Training http://jWeekend.com [1] http://svn.carmanconsulting.com/public/wicket-cdi/trunk [2] http://jweekend.com/dev/LegUp [3] http://code.google.com/p/legup/ Cemal, thanks for the offer I'll keep this in mind. James, you need an empty beans.xml file to let Weld know what to scan, this is explained much further in this blog entry : http://relation.to/Bloggers/WhyIsBeansxmlRequiredInCDI And if you plan to build a Weld extension, you must know that you have to create a file named : META-INF/services/javax.enterprise.inject.spi.Extension containing the full qualified name of your class implementing Extension.
Re: Wicket and JEE6
On Tue, Mar 30, 2010 at 10:21 AM, Olivier Bourgeois olivier.bourgeois@gmail.com wrote: James, you need an empty beans.xml file to let Weld know what to scan, this is explained much further in this blog entry : http://relation.to/Bloggers/WhyIsBeansxmlRequiredInCDI Yeah, I guess I figured that out the hard way! :) I believe OWB works the same way. I found a JIRA issue or something that clued me in. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
Olivier Bourgeois-2 wrote: ... everything is simple unmanaged POJOs except for your classes extending WebPage which are managed Not to be picky but a minor correction :) everything is simple unmanaged POJOs except for your classes extending [Component] which are managed -- View this message in context: http://old.nabble.com/Wicket-and-JEE6-tp28045129p28091022.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket and JEE6
Ericksen, Mark W (IS) wrote:
java.lang.NoSuchMethodError:
org.jboss.weld.Container.services()Lorg/jboss/weld/bootstrap/api/Service
Registry;
You need to update your weld-integration.jar (and maybe weld-osgi.jar) files
in ${glassfish_install_dir}/glassfish/modules
Get weld-integration.jar here
http://download.java.net/maven/glassfish/org/glassfish/web/weld-integration/
here/ The 3.0.1-b10 version works for me.
and weld-osgi.jar
http://repo2.maven.org/maven2/org/jboss/weld/weld-osgi-bundle/ here
--
View this message in context:
http://old.nabble.com/Wicket-and-JEE6-tp28045129p28065312.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
Hi, Wicket has very good support in Weld, but to make it work I had to update the weld-integration.jar, otherwise the sample Numberguess application is looking for an unexisting method in the 1.0.0 Weld API : this is your problem. If you don't want to do it by hand like suggested by Iskandar, you can download one of the Glassfish nightly builds, this is what I have done. The latest builds are integrating Weld 1.0.1-final and the problem vanishes. If you want, I can provide you the maven profile to make the sample work nicely when you hit the run button in Netbeans, because there is another problem with the samples : the maven profile is not including the slf4j libraries, so there is an error in Glassfish when you run the sample. I assume this may be your next problem :) Also, you may run into trouble with the JPA2 code generation if you are using maven. But if you are using Eclipse annotation preprocessor to generate the metadata, you won't have the problem. -- Olivier
RE: Wicket and JEE6
Thanks Olivier, Iskandar, and James! After getting Weld integration to work with the weld-wicket jar I realized that the integration is limited to classes that subclass from WebPage (or Page I suppose) to work within a request cycle. I cannot inject a DAO into a session or a singleton into an application class for example. In a JSF2 project there is no limitations. Plus the ability to annotate scope would be nice. This makes me wonder what the future holds for Wicket and JEE6. Is there work being done to fully integrate Wicket with JEE6's newly defined set of supported JSRs? It would be nice to see a comparison chart of JEE6 features and Wicket's current and expected future support for such features. I've been searching for something like this but haven't found anything. I'd love to see Wicket fully support JEE6 and become a drop in replacement for JSF2. This doesn't seem to be the case just yet. If I'm wrong be sure to let me know! -Mark -Original Message- From: Olivier Bourgeois [mailto:olivier.bourgeois@gmail.com] Sent: Monday, March 29, 2010 2:45 AM To: users@wicket.apache.org Subject: Re: Wicket and JEE6 Hi, Wicket has very good support in Weld, but to make it work I had to update the weld-integration.jar, otherwise the sample Numberguess application is looking for an unexisting method in the 1.0.0 Weld API : this is your problem. If you don't want to do it by hand like suggested by Iskandar, you can download one of the Glassfish nightly builds, this is what I have done. The latest builds are integrating Weld 1.0.1-final and the problem vanishes. If you want, I can provide you the maven profile to make the sample work nicely when you hit the run button in Netbeans, because there is another problem with the samples : the maven profile is not including the slf4j libraries, so there is an error in Glassfish when you run the sample. I assume this may be your next problem :) Also, you may run into trouble with the JPA2 code generation if you are using maven. But if you are using Eclipse annotation preprocessor to generate the metadata, you won't have the problem. -- Olivier - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
The problem you're going to face is that Wicket is an unmanaged framework. Meaning that something else doesn't create stuff for you. You create your Links, Labels, TextFields, etc. So, the container can't really do the injection. Now, what we could come up with would be an aspect that does the dirty work for you, but that would mean that you have to introduce AspectJ into your build (not a big deal). It would be interesting to see how this works. By the way, with my stuff, you can just do AbstractCdiPlugin.get().inject(whateverObject) and it will do the injection for you. So, you can put that in your session class' constructor, for instance. For the application, you can use the plugin's inject() method inside your init() method (you have to instantiate and install it there anyway). On Mon, Mar 29, 2010 at 1:23 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Thanks Olivier, Iskandar, and James! After getting Weld integration to work with the weld-wicket jar I realized that the integration is limited to classes that subclass from WebPage (or Page I suppose) to work within a request cycle. I cannot inject a DAO into a session or a singleton into an application class for example. In a JSF2 project there is no limitations. Plus the ability to annotate scope would be nice. This makes me wonder what the future holds for Wicket and JEE6. Is there work being done to fully integrate Wicket with JEE6's newly defined set of supported JSRs? It would be nice to see a comparison chart of JEE6 features and Wicket's current and expected future support for such features. I've been searching for something like this but haven't found anything. I'd love to see Wicket fully support JEE6 and become a drop in replacement for JSF2. This doesn't seem to be the case just yet. If I'm wrong be sure to let me know! -Mark -Original Message- From: Olivier Bourgeois [mailto:olivier.bourgeois@gmail.com] Sent: Monday, March 29, 2010 2:45 AM To: users@wicket.apache.org Subject: Re: Wicket and JEE6 Hi, Wicket has very good support in Weld, but to make it work I had to update the weld-integration.jar, otherwise the sample Numberguess application is looking for an unexisting method in the 1.0.0 Weld API : this is your problem. If you don't want to do it by hand like suggested by Iskandar, you can download one of the Glassfish nightly builds, this is what I have done. The latest builds are integrating Weld 1.0.1-final and the problem vanishes. If you want, I can provide you the maven profile to make the sample work nicely when you hit the run button in Netbeans, because there is another problem with the samples : the maven profile is not including the slf4j libraries, so there is an error in Glassfish when you run the sample. I assume this may be your next problem :) Also, you may run into trouble with the JPA2 code generation if you are using maven. But if you are using Eclipse annotation preprocessor to generate the metadata, you won't have the problem. -- Olivier - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
Ok, I've got the OWB examples working now with my local patched version of OWB (patches submitted to JIRA). Also, note I've renamed the library to wicket-cdi: http://svn.carmanconsulting.com/public/wicket-cdi/trunk On Sat, Mar 27, 2010 at 1:39 AM, James Carman jcar...@carmanconsulting.comwrote: I've got a working example with Weld. Check http://svn.carmanconsulting.com/public/wicket-candi/trunk There's a weld-example subdirectory in there. Currently, I don't have the conversation stuff working, but the injections appear to be working. Unfortunately, the implementation doesn't work with OWB. :( I'll see what's causing it and see if we can get them both working. Good luck. On Fri, Mar 26, 2010 at 6:35 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Thanks Josh. With your idea in mind I dug deeper into what Weld's support for Wicket is/was. In the Weld download is a jar called weld-wicket.jar that has a WeldApplication class for doing what you suggest. However following the instruction for using their integration code only got me an error when including their jar in my project. java.lang.NoSuchMethodError: org.jboss.weld.Container.services()Lorg/jboss/weld/bootstrap/api/Service Registry; So I included the weld-wicket code in my simple project to see what was going on. Their integration solution provides a new RequestCycle class called WeldRequestCycle. In this class they attempt to preserve a long running conversation through weld/wicket trickery. There's a line of code in a few places that causes a runtime exception that stops the request cycle. ConversationContext conversationContext = Container.instance().services().get(ContextLifecycle.class).getConversat ionContext(); These are Weld classes, but stepping through the debugger shows it goes go back through the Wicket filter. Therefore I don't know who is at fault here. Maybe something in Wicket changed that is causing Weld to croak or Weld in Glassfish is the culprit. Either way I really don't care about long running conversation support at this point so I removed the class and any dependency on it in my modified version of the weld-wicket code base. With that exception out of the way and changing my application to subclass from WeldApplication, I have simple injection working with Weld. Yippee! I'll cross my fingers there are no other side effects. Problem is now what? I guess I can post this with the Seam/Weld team and hope someone updates the Weld-Wicket integration. Or I can hope someone from the Wicket team will take a look and see if it's something in the latest version of Wicket that caused this to break and could do a patch. Anyone? :) -Mark -Original Message- From: Josh Chappelle [mailto:jchappe...@4redi.com] Sent: Friday, March 26, 2010 2:59 PM To: users@wicket.apache.org Subject: RE: Wicket and JEE6 Mark, Try taking a look at the addComponentInstantiationListener method on the Application class. It takes one parameter of type IComponentInstantiationListener and that interface has one method which is onInstantiation(Component component). Every time a component gets instantiated it will be handed to this listener so maybe you can write your own dependency injection code there. I would think that is what the WeldApplication is doing under the covers but since it isn't working for you then you may have more luck just writing it yourself. The other trick is to making this work is obtaining a reference to your weld context. I use Spring so I'm not familiar with what it takes with Weld. I hope this helps. Thanks, Josh -Original Message- From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com] Sent: Friday, March 26, 2010 11:52 AM To: users@wicket.apache.org Subject: Wicket and JEE6 Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am
Re: Wicket and JEE6
Weld has wicket support built-in I believe. On Fri, Mar 26, 2010 at 12:52 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark
RE: Wicket and JEE6
Weld claims support, I don't know about built-in. When I use @Inject in a Wicket WebPage subclass the objects are null. Like I mentioned below, I added weld-wicket.jar and subclassed the WeldApplication and the injected objects in the Wicket WebPage subclass are still null. This was from following this example: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/viewlayers.html If you track down the example code it seems that the examples from JBoss are using older versions of Wicket and Weld/Seam so I don't know if something has broken in either project, wicket or weld. Injection worked like a charm in a JSF2 controller class so I don't know what going wrong or what supporting jar is missing. Any additional help is greatly appreciated! -Mark -Original Message- From: James Carman [mailto:jcar...@carmanconsulting.com] Sent: Friday, March 26, 2010 10:52 AM To: users@wicket.apache.org Subject: Re: Wicket and JEE6 Weld has wicket support built-in I believe. On Fri, Mar 26, 2010 at 12:52 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
I started a JSR-299 integration project a while back, but at the time there was no portable way (across vendors) to get to the stuff you needed to inject into your components. I believe that's been fixed in the latest API, but I haven't had a chance to dig in and verify that and then use it. My guess is that there's really not that much to it (my code was pretty small). On Fri, Mar 26, 2010 at 1:35 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Weld claims support, I don't know about built-in. When I use @Inject in a Wicket WebPage subclass the objects are null. Like I mentioned below, I added weld-wicket.jar and subclassed the WeldApplication and the injected objects in the Wicket WebPage subclass are still null. This was from following this example: http://docs.jboss.org/weld/reference/1.0.0/en-US/html/viewlayers.html If you track down the example code it seems that the examples from JBoss are using older versions of Wicket and Weld/Seam so I don't know if something has broken in either project, wicket or weld. Injection worked like a charm in a JSF2 controller class so I don't know what going wrong or what supporting jar is missing. Any additional help is greatly appreciated! -Mark -Original Message- From: James Carman [mailto:jcar...@carmanconsulting.com] Sent: Friday, March 26, 2010 10:52 AM To: users@wicket.apache.org Subject: Re: Wicket and JEE6 Weld has wicket support built-in I believe. On Fri, Mar 26, 2010 at 12:52 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket and JEE6
Warning: Long Response with sample code to illustrate issue.
I ran the following code in Glassfish v3 with the following jars:
portlet-api_2.0_spec-1.0.jar (someone is relying on this??)
slf4j-api-1.4.2.jar
slf4j-jdk14-1.4.2.jar
wicket-1.4.7.jar
Be sure to add an empty beans.xml to the WEB-INF folder.
After starting up Glassfish, type the following in the browser
(WicketTest is the name of my project, yours may vary):
localhost:8080/WicketTest/
The output it: No Util Class
localhost:8080/WicketTest/jsf.faces
The output is: Hello World!
Code follows
web.xml:
?xml version=1.0 encoding=UTF-8?
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; id=WebApp_ID
version=2.5
display-nameWicketTest/display-name
servlet
servlet-nameFaces Servlet/servlet-name
servlet-classjavax.faces.webapp.FacesServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern/faces/*/url-pattern
url-pattern*.faces/url-pattern
/servlet-mapping
filter
filter-namewicket example/filter-name
filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class
init-param
param-nameapplicationClassName/param-name
param-valuecom.example.wicket.ExampleApplication/param-value
/init-param
/filter
filter-mapping
filter-namewicket example/filter-name
url-pattern/*/url-pattern
/filter-mapping
/web-app
EntityUtil.java:
package com.example.wicket;
public class EntityUtil {
public String getEntity() {
return Hello World!;
}
}
ExampleApplication.java:
package com.example.wicket;
import org.apache.wicket.Page;
import org.apache.wicket.protocol.http.WebApplication;
public class ExampleApplication extends WebApplication {
@Override
public Class? extends Page getHomePage() {
return HomePage.class;
}
}
HomePage.java:
package com.example.wicket;
import javax.inject.Inject;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.model.Model;
public class HomePage extends WebPage {
@Inject private EntityUtil util;
public HomePage() {
super();
add(new Label(hello, new ModelString(this.getHello(;
}
private String getHello() { return (null != util) ? util.getEntity()
: No Util Class; }
}
HomePage.html:
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html xmlns:wicket=http://wicket.apache.org;
head
meta http-equiv=Content-Type content=text/html;
charset=ISO-8859-1
titleInsert wicket title here/title
/head
body
span wicket:id=helloYo!/span
/body
/html
jsf.xhtml (in context root):
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
h:head
titleInsert jsf title here/title
/h:head
h:body
span#{controller.hello}/span
/h:body
/html
Controller.java:
package com.example.wicket;
import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;
import javax.inject.Named;
@Named @RequestScoped
public class Controller {
@Inject private EntityUtil util;
public String getHello() { return (null != util) ? util.getEntity()
: No Util Class; }
}
-Original Message-
From: James Carman [mailto:jcar...@carmanconsulting.com]
Sent: Friday, March 26, 2010 11:36 AM
To: users@wicket.apache.org
Subject: Re: Wicket and JEE6
I started a JSR-299 integration project a while back, but at the time
there
was no portable way (across vendors) to get to the stuff you needed to
inject into your components. I believe that's been fixed in the latest
API,
but I haven't had a chance to dig in and verify that and then use it.
My
guess is that there's really not that much to it (my code was pretty
small).
On Fri, Mar 26, 2010 at 1:35 PM, Ericksen, Mark W (IS)
mark.erick...@ngc.com wrote:
Weld claims support, I don't know about built-in.
When I use @Inject in a Wicket WebPage subclass the objects are null.
Like I mentioned below, I added weld-wicket.jar and subclassed the
WeldApplication and the injected objects in the Wicket WebPage
subclass
are still null.
This was from following this example:
http://docs.jboss.org/weld/reference/1.0.0/en-US/html/viewlayers.html
If you track down the example code it seems that the examples from
JBoss
are using older versions of Wicket and Weld/Seam so I don't know if
something has broken in either project, wicket or weld.
Injection worked like a charm in a JSF2 controller class so I don't
know
what going wrong
RE: Wicket and JEE6
Mark, Try taking a look at the addComponentInstantiationListener method on the Application class. It takes one parameter of type IComponentInstantiationListener and that interface has one method which is onInstantiation(Component component). Every time a component gets instantiated it will be handed to this listener so maybe you can write your own dependency injection code there. I would think that is what the WeldApplication is doing under the covers but since it isn't working for you then you may have more luck just writing it yourself. The other trick is to making this work is obtaining a reference to your weld context. I use Spring so I'm not familiar with what it takes with Weld. I hope this helps. Thanks, Josh -Original Message- From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com] Sent: Friday, March 26, 2010 11:52 AM To: users@wicket.apache.org Subject: Wicket and JEE6 Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket and JEE6
Thanks Josh. With your idea in mind I dug deeper into what Weld's support for Wicket is/was. In the Weld download is a jar called weld-wicket.jar that has a WeldApplication class for doing what you suggest. However following the instruction for using their integration code only got me an error when including their jar in my project. java.lang.NoSuchMethodError: org.jboss.weld.Container.services()Lorg/jboss/weld/bootstrap/api/Service Registry; So I included the weld-wicket code in my simple project to see what was going on. Their integration solution provides a new RequestCycle class called WeldRequestCycle. In this class they attempt to preserve a long running conversation through weld/wicket trickery. There's a line of code in a few places that causes a runtime exception that stops the request cycle. ConversationContext conversationContext = Container.instance().services().get(ContextLifecycle.class).getConversat ionContext(); These are Weld classes, but stepping through the debugger shows it goes go back through the Wicket filter. Therefore I don't know who is at fault here. Maybe something in Wicket changed that is causing Weld to croak or Weld in Glassfish is the culprit. Either way I really don't care about long running conversation support at this point so I removed the class and any dependency on it in my modified version of the weld-wicket code base. With that exception out of the way and changing my application to subclass from WeldApplication, I have simple injection working with Weld. Yippee! I'll cross my fingers there are no other side effects. Problem is now what? I guess I can post this with the Seam/Weld team and hope someone updates the Weld-Wicket integration. Or I can hope someone from the Wicket team will take a look and see if it's something in the latest version of Wicket that caused this to break and could do a patch. Anyone? :) -Mark -Original Message- From: Josh Chappelle [mailto:jchappe...@4redi.com] Sent: Friday, March 26, 2010 2:59 PM To: users@wicket.apache.org Subject: RE: Wicket and JEE6 Mark, Try taking a look at the addComponentInstantiationListener method on the Application class. It takes one parameter of type IComponentInstantiationListener and that interface has one method which is onInstantiation(Component component). Every time a component gets instantiated it will be handed to this listener so maybe you can write your own dependency injection code there. I would think that is what the WeldApplication is doing under the covers but since it isn't working for you then you may have more luck just writing it yourself. The other trick is to making this work is obtaining a reference to your weld context. I use Spring so I'm not familiar with what it takes with Weld. I hope this helps. Thanks, Josh -Original Message- From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com] Sent: Friday, March 26, 2010 11:52 AM To: users@wicket.apache.org Subject: Wicket and JEE6 Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JEE6
I've got a working example with Weld. Check out: http://svn.carmanconsulting.com/public/wicket-candi/trunk There's a weld-example subdirectory in there. Currently, I don't have the conversation stuff working, but the injections appear to be working. Unfortunately, the implementation doesn't work with OWB. :( I'll see what's causing it and see if we can get them both working. Good luck. On Fri, Mar 26, 2010 at 6:35 PM, Ericksen, Mark W (IS) mark.erick...@ngc.com wrote: Thanks Josh. With your idea in mind I dug deeper into what Weld's support for Wicket is/was. In the Weld download is a jar called weld-wicket.jar that has a WeldApplication class for doing what you suggest. However following the instruction for using their integration code only got me an error when including their jar in my project. java.lang.NoSuchMethodError: org.jboss.weld.Container.services()Lorg/jboss/weld/bootstrap/api/Service Registry; So I included the weld-wicket code in my simple project to see what was going on. Their integration solution provides a new RequestCycle class called WeldRequestCycle. In this class they attempt to preserve a long running conversation through weld/wicket trickery. There's a line of code in a few places that causes a runtime exception that stops the request cycle. ConversationContext conversationContext = Container.instance().services().get(ContextLifecycle.class).getConversat ionContext(); These are Weld classes, but stepping through the debugger shows it goes go back through the Wicket filter. Therefore I don't know who is at fault here. Maybe something in Wicket changed that is causing Weld to croak or Weld in Glassfish is the culprit. Either way I really don't care about long running conversation support at this point so I removed the class and any dependency on it in my modified version of the weld-wicket code base. With that exception out of the way and changing my application to subclass from WeldApplication, I have simple injection working with Weld. Yippee! I'll cross my fingers there are no other side effects. Problem is now what? I guess I can post this with the Seam/Weld team and hope someone updates the Weld-Wicket integration. Or I can hope someone from the Wicket team will take a look and see if it's something in the latest version of Wicket that caused this to break and could do a patch. Anyone? :) -Mark -Original Message- From: Josh Chappelle [mailto:jchappe...@4redi.com] Sent: Friday, March 26, 2010 2:59 PM To: users@wicket.apache.org Subject: RE: Wicket and JEE6 Mark, Try taking a look at the addComponentInstantiationListener method on the Application class. It takes one parameter of type IComponentInstantiationListener and that interface has one method which is onInstantiation(Component component). Every time a component gets instantiated it will be handed to this listener so maybe you can write your own dependency injection code there. I would think that is what the WeldApplication is doing under the covers but since it isn't working for you then you may have more luck just writing it yourself. The other trick is to making this work is obtaining a reference to your weld context. I use Spring so I'm not familiar with what it takes with Weld. I hope this helps. Thanks, Josh -Original Message- From: Ericksen, Mark W (IS) [mailto:mark.erick...@ngc.com] Sent: Friday, March 26, 2010 11:52 AM To: users@wicket.apache.org Subject: Wicket and JEE6 Hi, I'm building a new java project using all JEE6 technologies. That means I'm using JPA, CDI, and JSF2 for example. Each layer came together great with fully annotated classes until I got to the JSF2 layer which drove me crazy because JSF wants to mess with HTML element ids and names. In looking for alternative view layers I came across Wicket. The technology seems great in terms of its philosophy to keep presentation code separate, except I'm not finding much information about its support for JEE6 technologies. In particular searches for support for CDI (aka WebBeans, aka Weld) only got me to an old example in the Seam project. I cannot find any current references to using Weld within a Wicket project where I can use annotations such as @Inject, @Named, @ApplicationScoped, etc. So my very first question for this list of experts is this: Is there currently any support for Weld in Wicket? Downloading the Weld project from JBoss, I included the weld-wicket.jar into my project and my application is subclassed from WeldApplication. No such luck. Any class injected using @Inject is still null. I am using GlassFish v3 which has all the JEE6 goodies included. Developing with Eclipse. Any help is *greatly* appreciated! -Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail
