Here you go:
https://github.com/berniegp/test-wicket-cdi
On 04/01/2013 5:13 PM, Romain Manni-Bucau wrote:
Share it on github if possible
Le 4 janv. 2013 20:49, "Bertrand Guay-Paquet" <ber...@step.polymtl.ca> a
écrit :
Hi,
Howard: I already had a look at these messages and others from the Wicket
mailing list. They were indeed helpful in getting me to where I am now.
From what I understand, Harald is right and wicket-cdi is not specific to
Weld. @RequestScoped, @SessionScoped and @ApplicationScoped all work fine
in my limited tests. However, I'm not able to get @ConversionScoped working
with the owb seam connector (seam-conversation-owb) for an unknown reason;
but this is not related to my prior questions.
Romain: Where should I send a small sample app which demonstrates the
issue?
Also, am I "swimming against the current" by trying to use cdi instead of
jndi lookups for connecting my EJB tier to the web tier (Wicket)? I
currently, have jndi lookups working correctly and wanted to benefit from
the cdi goodies but I'm starting to think it's not worth the trouble right
now.
Regards,
Bertrand
On 04/01/2013 2:13 PM, Romain Manni-Bucau wrote:
if you have a sample i'll will give it a try this week end but looking
quickly not sure it is implemented to be portable
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.**com/<http://rmannibucau.wordpress.com/>
LinkedIn:
http://fr.linkedin.com/in/**rmannibucau<http://fr.linkedin.com/in/rmannibucau>
Github: https://github.com/rmannibucau
2013/1/4 Harald Wellmann <hwellmann...@gmail.com>:
I don't think that's the point.
wicket-cdi [1] only depends on the CDI API, not on Weld. The Seam
dependency
is optional in fact. So it should work with OWB (but I haven't tried).
The message means that DetachEventEmitter is being considered as an
injection target but does not have a default constructor.
The question is why this class is considered at all.
I suppose you have a WAR with a WEB-INF/beans.xml descriptor to enable
CDI
and wicket-cdi in WEB-INF/lib/
It might be that OpenWebBeans scans all JARs in WEB-INF/lib even if the
individual libs don't contain a beans.xml marker (and wicket-cdi has no
beans.xml, nor is it a CDI extension).
(I remember a discussion about Bean Deployment Archives being handled
differently in Weld and OWB and people arguing the CDI 1.0 spec to be
somewhat broken in this respect.)
[1]
http://search.maven.org/**remotecontent?filepath=org/**
apache/wicket/wicket-cdi/6.1.**1/wicket-cdi-6.1.1.pom<http://search.maven.org/remotecontent?filepath=org/apache/wicket/wicket-cdi/6.1.1/wicket-cdi-6.1.1.pom>
Best regards,
Harald
Am 04.01.2013 19:33, schrieb Romain Manni-Bucau:
wicket-cdi is for weld not for cdi if it is the one i'm thinking
about. So this is not portable
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.**com/<http://rmannibucau.wordpress.com/>
LinkedIn:
http://fr.linkedin.com/in/**rmannibucau<http://fr.linkedin.com/in/rmannibucau>
Github: https://github.com/rmannibucau
2013/1/4 Bertrand Guay-Paquet <ber...@step.polymtl.ca>:
Hello,
When running Wicket with its wicket-cdi module which provides CDI
injection
of Wicket components, I get a ton of info/warnings of this sort:
org.apache.webbeans.component.**creation.**
AnnotatedTypeBeanCreatorImpl
defineConstructor
INFO: No suitable constructor found for injection target class : [class
org.apache.wicket.cdi.**DetachEventEmitter]. produce() method does not
work!
I'm new to CDI so I searched online but couldn't find out what these
mean...
Are they problematic? What do they mean? Apparently, wicket + weld
doesn't
produce these messages.
Regards,
Bertrand
