Edmond, Please when you assembly the package for the new CDI version, use scope provided for javax.* and org.jboss.* dependencies. I'm fixing the plumbing of my project and several undesired packages are being assembled because of current wicket-cdi. Thank you for your efforts!
- Diogo On Thu, Dec 5, 2013 at 6:09 PM, Emond Papegaaij <[email protected]> wrote: > The new module should be fully functional, including all scopes. The > performance should be much better than with the old module, due to > InjectionTarget caching. The biggest changes are in conversation > propagation. If you do not use the conversation scope, the transition to > the new module should be very smooth. > > Best regards, > Emond > Op 5 dec. 2013 20:24 schreef "Diogo Casado" <[email protected]>: > >> Thanks Emond, >> >> I will watch the progress and report back. >> For now.. I'm ignoring the warnings and using a snapshot from glassfish. >> I'm using CDI just for EntityManager injection..and it's just >> RequestScoped. >> So.. from what I saw in the current version, the biggest problem would >> be if it was context oriented. >> >> Regards, >> Diogo C. >> >> >> On Wed, Dec 4, 2013 at 7:01 PM, Emond Papegaaij >> <[email protected]> wrote: >> > Hi Diogo, >> > >> > Please note that wicket-cdi-1.1 is still experimental. I do have high >> > confidence it will work fine, but it has not been tested extensively. The >> > API is mostly compatible with the current wicket-cdi module. One of the >> > changes is that the constructor of the CdiConfiguration no longer takes a >> > BeanManager. CDI 1.1 has several portable ways of looking up this >> > BeanManager. A fallback is added (see CdiConfiguration), in case your >> > environment does not provide any of the portable lookup methods, but >> > Glassfish should. Also, it is no longer possible to disable injection of >> > various Wicket classes. Components, behaviors, sessions and the >> application >> > are always injected. >> > >> > A major difference in behavior is the way conversations are propagated. >> The >> > current cdi module uses non-portable code (which only works with Weld) to >> > propagate the conversation. wicket-cdi-1.1 always propagates the >> > conversation via the url (with the cid query-parameter), which is >> portable >> > across all CDI 1.1 providers. >> > >> > As Martin mentioned, wicket-cdi-1.1 requires a recent version of Weld (if >> > used with Weld). Weld 2.1.1 (which has not yet been released) has some >> > fixes regarding warning floods ( >> https://issues.jboss.org/browse/WELD-1547). >> > Until then, you either have to ignore the warnings or lower the logging >> > level. >> > >> > To use wicket-cdi-1.1, once wicket 6.13 is released, add the following >> > dependency: >> > <dependency> >> > <groupId>org.apache.wicket</groupId> >> > <artifactId>wicket-cdi-1.1</artifactId> >> > <version>0.2</version> >> > </dependency> >> > >> > Until then, you can test with 0.2-SNAPSHOT. You can find the details for >> > the snapshot repository on our download page. >> > >> > If you find any issues with wicket-cdi-1.1, please file JIRA issues and >> > assign them to me. >> > >> > Best regards, >> > Emond Papegaaij >> > >> > >> > On Wed, Dec 4, 2013 at 7:02 PM, Diogo Casado <[email protected]> >> wrote: >> > >> >> It looks like it is running with glassfish4 snapshot 4.1 b4m1. >> >> They use the latest version of weld on it. >> >> Well.. I will continue this way.. >> >> Do you have an idea on when we will have v6.13 with cdi1.1? >> >> Thank you very much. >> >> >> >> On Wed, Dec 4, 2013 at 2:07 PM, Martin Grigorov <[email protected]> >> >> wrote: >> >> > Hi, >> >> > >> >> > I am not very into CDI business but here are some solutions: >> >> > - upgrade Weld to 2.1.0 in Glassfish 4, if this is possible. The >> >> exception >> >> > is caused by a bug in Weld 2.0.x >> >> > - use Wicket 6.9.0. This will work unless you use @Inject in anonymous >> >> > Wicket components. I personally never thought about this pattern >> before >> >> > Wicket 6.9.1. I guess you don't use it too >> >> > - Wicket 6.13.0 will bring wicket-cdi-1.1 module. But again it will >> work >> >> > only if you use it with Weld 2.1.x >> >> > >> >> > >> >> > On Wed, Dec 4, 2013 at 5:01 PM, Diogo Casado <[email protected]> >> >> wrote: >> >> > >> >> >> Hello guys.. >> >> >> >> >> >> I'm setting up a Glassfish4 environment with wicket 6.12.0 and I >> >> >> previously started using cdi to inject entity managers. >> >> >> On Tomee, cdi was working but I decided that this particular >> >> >> application will need a more robust JavaEE server (specially because >> >> >> of OpenJPA slow pace). >> >> >> >> >> >> Anyway.. I'm getting warnings everywhere and specially this exception >> >> >> that just broke the app: >> >> >> WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl] class >> >> >> com....LoginPage$1 cannot be a non-static inner class >> >> >> >> >> >> The offending class is basically a anonymous Form.. I conclude that >> >> >> any anonymous class would cause this. >> >> >> >> >> >> Found this ticket: https://issues.apache.org/jira/browse/WICKET-5264 >> >> >> I guess it happened before and was fixed in v6.9.0 but I'm still >> >> >> facing this issue with v6.12.0. >> >> >> >> >> >> So basically.. what's the best option: >> >> >> - Apply some fix to this situation; >> >> >> - Stick with a JavaEE6 with Glassfish3 while using v6.x + cdi and in >> >> >> near future go for JavaEE7 Glassfish4 + Wicket v7.x & cdi 1.1 (when >> >> >> ready) >> >> >> - Should I forget cdi =\ >> >> >> >> >> >> I appreciate guidance. >> >> >> >> >> >> Thanks. >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: [email protected] >> >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
