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() { LookupProxyFactory factory = new LookupProxyFactory( 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
On Thu, Jul 29, 2010 at 10:18 PM, James Carman wrote: > 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
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 wrote: > On Thu, Jul 29, 2010 at 9:54 PM, Erik Brakkee wrote: > >> 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 9:54 PM, Erik Brakkee wrote: > 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
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 Mon, Apr 12, 2010 at 12:12 AM, James Carman wrote: > I would imagine that most implementations would cache their injectors > (it's part of the Bean) > > > 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
I would imagine that most implementations would cache their injectors (it's part of the Bean) On Sun, Apr 11, 2010 at 4:30 PM, Erik Brakkee 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
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
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 wrote: > On Mon, Apr 5, 2010 at 11:58 PM, James Carman > wrote: > >> >> 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 Mon, Apr 5, 2010 at 11:58 PM, James Carman wrote: > > 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
On Mon, Apr 5, 2010 at 5:27 PM, Erik Brakkee 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
On Mon, Apr 5, 2010 at 10:37 PM, James Carman wrote: > 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
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 wrote: > On Mon, Apr 5, 2010 at 9:54 PM, James Carman > wrote: > >> 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 9:54 PM, James Carman wrote: > 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
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 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 NonContextual > weldComponentInstantiationListener; > > /** > * Constructor > */ > public WicketApplication() { > // Empty. > } > > �...@override > protected void init() { > BeanManager mgr = BeanManagerLookup.getBeanManager(); > System.out.println("BeanManager '" + mgr + "'"); > this.weldComponentInstantiationListener = new > NonContextual(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
> > 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 NonContextual weldComponentInstantiationListener; /** * Constructor */ public WicketApplication() { // Empty. } @Override protected void init() { BeanManager mgr = BeanManagerLookup.getBeanManager(); System.out.println("BeanManager '" + mgr + "'"); this.weldComponentInstantiationListener = new NonContextual(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
On Wed, Mar 31, 2010 at 5:05 AM, Iskandar Salim wrote: > > > > 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
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 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 > 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 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 @@ >> >> >> >> >> >> >> >> + >> >> + >> >> + >> >> + JBoss Repo >> >> + http://repository.jboss.com/maven2 >> >> + >> >> + >> >> + >> >> + geronimo-snapshots >> >> + Apache Nexus Snapshots >> >> + >> >> https://repository.apache.org/content/groups/snapshots-group >> >> + >> >> + true >> >> + >> >> + >> >> + >> >> + >> >> + >> >> >> >> \ No newline at end of file >> >> Index: owb/pom.xml >> >> === >> >> --- owb/pom.xml (revision 78) >> >> +++ owb/pom.xml (working copy) >> >> @@ -16,11 +16,12 @@ >> >> wicket-cdi >> >> ${project.version} >> >> >> >> - >> >> - org.apache.openwebbeans >> >> - openwebbeans-impl >> >> - 1.0.0-SNAPSHOT >> >> - >> >> + >> >> + org.apache.openwebbeans >> >> + openwebbeans-impl >> >> + 1.0.0-M4 >> >> + >> >> + >> >> >> >> org.apache.geronimo.specs >> >> geronimo-jcdi_1.0_spec >> >> Index: owb-example/pom.xml >> >> === >> >> --- owb-example/pom.xml (revision 78) >> >> +++ owb-example/pom.xml (working copy) >> >> @@ -62,15 +62,11 @@ >> >> wicket-cdi-owb >> >> ${project.version} >> >> >> >> - >> >> - org.apache.openwebbeans >> >> - openwebbeans-web >> >> - 1.0.0-SNAPSHOT >> >> - >> >> + >> >> >> >> org.apache.openwebbeans >> >> openwebbeans-spi >> >> - 1.0.0-SNAPSHOT >> >> + 1.0.0-M4 >> >> >> >> >> >> org.apache.geronimo.specs >> >> == END OF PATCH ABOVE >> >> >> >> On 30 March 2010 12:09, James Carman >> >> 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: >> >> > >> >> >> Oliv
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
On Tue, Mar 30, 2010 at 10:21 AM, Olivier Bourgeois 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
2010/3/30 Cemal Bayramoglu > 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
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 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 @@ > >> > >> > >> > >> + > >> + > >> + > >> +JBoss Repo > >> +http://repository.jboss.com/maven2 > >> + > >> + > >> + > >> + geronimo-snapshots > >> + Apache Nexus Snapshots > >> + > >> https://repository.apache.org/content/groups/snapshots-group > >> + > >> + true > >> + > >> + > >> + > >> + > >> + > >> > >> \ No newline at end of file > >> Index: owb/pom.xml > >> === > >> --- owb/pom.xml (revision 78) > >> +++ owb/pom.xml (working copy) > >> @@ -16,11 +16,12 @@ > >> wicket-cdi > >> ${project.version} > >> > >> - > >> -org.apache.openwebbeans > >> -openwebbeans-impl > >> -1.0.0-SNAPSHOT > >> - > >> + > >> +org.apache.openwebbeans > >> +openwebbeans-impl > >> +1.0.0-M4 > >> + > >> + > >> > >> org.apache.geronimo.specs > >> geronimo-jcdi_1.0_spec > >> Index: owb-example/pom.xml > >> === > >> --- owb-example/pom.xml (revision 78) > >> +++ owb-example/pom.xml (working copy) > >> @@ -62,15 +62,11 @@ > >> wicket-cdi-owb > >> ${project.version} > >> > >> - > >> -org.apache.openwebbeans > >> -openwebbeans-web > >> -1.0.0-SNAPSHOT > >> - > >> + > >> > >> org.apache.openwebbeans > >> openwebbeans-spi > >> -1.0.0-SNAPSHOT > >> +1.0.0-M4 > >> > >> > >> org.apache.geronimo.specs > >> == END OF PATCH ABOVE > >> > >> On 30 March 2010 12:09, James Carman > 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/
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 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 @@ >> >> >> >> + >> + >> + >> + JBoss Repo >> + http://repository.jboss.com/maven2 >> + >> + >> + >> + geronimo-snapshots >> + Apache Nexus Snapshots >> + >> https://repository.apache.org/content/groups/snapshots-group >> + >> + true >> + >> + >> + >> + >> + >> >> \ No newline at end of file >> Index: owb/pom.xml >> === >> --- owb/pom.xml (revision 78) >> +++ owb/pom.xml (working copy) >> @@ -16,11 +16,12 @@ >> wicket-cdi >> ${project.version} >> >> - >> - org.apache.openwebbeans >> - openwebbeans-impl >> - 1.0.0-SNAPSHOT >> - >> + >> + org.apache.openwebbeans >> + openwebbeans-impl >> + 1.0.0-M4 >> + >> + >> >> org.apache.geronimo.specs >> geronimo-jcdi_1.0_spec >> Index: owb-example/pom.xml >> === >> --- owb-example/pom.xml (revision 78) >> +++ owb-example/pom.xml (working copy) >> @@ -62,15 +62,11 @@ >> wicket-cdi-owb >> ${project.version} >> >> - >> - org.apache.openwebbeans >> - openwebbeans-web >> - 1.0.0-SNAPSHOT >> - >> + >> >> org.apache.openwebbeans >> openwebbeans-spi >> - 1.0.0-SNAPSHOT >> + 1.0.0-M4 >> >> >> org.apache.geronimo.specs >> == END OF PATCH ABOVE >> >> On 30 March 2010 12:09, James Carman 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 >> >> 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. O
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 @@ > > > > + > + > + > +JBoss Repo > +http://repository.jboss.com/maven2 > + > + > + > + geronimo-snapshots > + Apache Nexus Snapshots > + > https://repository.apache.org/content/groups/snapshots-group > + > + true > + > + > + > + > + > > \ No newline at end of file > Index: owb/pom.xml > === > --- owb/pom.xml (revision 78) > +++ owb/pom.xml (working copy) > @@ -16,11 +16,12 @@ > wicket-cdi > ${project.version} > > - > -org.apache.openwebbeans > -openwebbeans-impl > -1.0.0-SNAPSHOT > - > + > +org.apache.openwebbeans > +openwebbeans-impl > +1.0.0-M4 > + > + > > org.apache.geronimo.specs > geronimo-jcdi_1.0_spec > Index: owb-example/pom.xml > === > --- owb-example/pom.xml (revision 78) > +++ owb-example/pom.xml (working copy) > @@ -62,15 +62,11 @@ > wicket-cdi-owb > ${project.version} > > - > -org.apache.openwebbeans > -openwebbeans-web > -1.0.0-SNAPSHOT > - > + > > org.apache.openwebbeans > openwebbeans-spi > -1.0.0-SNAPSHOT > +1.0.0-M4 > > > org.apache.geronimo.specs > == END OF PATCH ABOVE > > On 30 March 2010 12:09, James Carman 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 > >> 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.
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 @@ + + + +JBoss Repo +http://repository.jboss.com/maven2 + + + + geronimo-snapshots + Apache Nexus Snapshots + https://repository.apache.org/content/groups/snapshots-group + + true + + + + + \ No newline at end of file Index: owb/pom.xml === --- owb/pom.xml (revision 78) +++ owb/pom.xml (working copy) @@ -16,11 +16,12 @@ wicket-cdi ${project.version} - -org.apache.openwebbeans -openwebbeans-impl -1.0.0-SNAPSHOT - + +org.apache.openwebbeans +openwebbeans-impl +1.0.0-M4 + + org.apache.geronimo.specs geronimo-jcdi_1.0_spec Index: owb-example/pom.xml === --- owb-example/pom.xml (revision 78) +++ owb-example/pom.xml (working copy) @@ -62,15 +62,11 @@ wicket-cdi-owb ${project.version} - -org.apache.openwebbeans -openwebbeans-web -1.0.0-SNAPSHOT - + org.apache.openwebbeans openwebbeans-spi -1.0.0-SNAPSHOT +1.0.0-M4 org.apache.geronimo.specs == END OF PATCH ABOVE On 30 March 2010 12:09, James Carman 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 >> 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 >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket
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 > 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
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 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
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
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
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
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
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
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 wrote: > 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 >> lo
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 > curren
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
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
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: 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"> WicketTest Faces Servlet javax.faces.webapp.FacesServlet 1 Faces Servlet /faces/* *.faces wicket example org.apache.wicket.protocol.http.WicketFilter applicationClassName com.example.wicket.ExampleApplication wicket example /* 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 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 Model(this.getHello(; } private String getHello() { return (null != util) ? util.getEntity() : "No Util Class"; } } HomePage.html: http://www.w3.org/TR/html4/loose.dtd";> http://wicket.apache.org";> Insert wicket title here Yo! jsf.xhtml (in context root): http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml"; xmlns:h="http://java.sun.com/jsf/html";> Insert jsf title here #{controller.hello} 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 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 b
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
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
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 > > > > > >