Serialization of injected EJBs

I'm using Wicket on Glassfish v3, injecting stateless session beans (using the no-interface view) into my Wicket components. For a component member @Inject private Foo foo; Glassfish generates a proxy which is not serializable, even though my class Foo is. Now the problem is

AW: Serialization of injected EJBs

] Gesendet: Mittwoch, 7. Juli 2010 16:51 An: users@wicket.apache.org Betreff: Re: Serialization of injected EJBs Hi, you could try to use: http://wicketstuff.org/confluence/display/STUFFWIKI/JavaEE+Inject Regards, Peter 2010-07-07 16:42 keltezéssel, Harald Wellmann írta: I'm using Wicket

AW: AW: Serialization of injected EJBs

references could be stored into session without problem. Peter 2010-07-07 17:07 keltezéssel, Harald Wellmann írta: Is there any evidence that javaee-inject would solve the problem? The question is not how to inject the EJBs (this works fine with the wicket-cdi lib), but how to serialize the injected

AW: Serialization of injected EJBs

Does javaee-inject support CDI at all? I cannot find any @Inject annotations in the examples you mentioned, they all seem to be in Java EE 5 style, not Java EE 6. Regards, Harald Von: Major Péter [majorpe...@sch.bme.hu] Gesendet: Mittwoch, 7. Juli 2010

AW: AW: Serialization of injected EJBs

that. You can always use lookups for your beans/CDI stuff... Regards, Peter 2010-07-07 19:34 keltezéssel, Harald Wellmann írta: Does javaee-inject support CDI at all? I cannot find any @Inject annotations in the examples you mentioned, they all seem to be in Java EE 5 style, not Java EE 6

AW: AW: Serialization of injected EJBs

In theory, yes... The proxies returned by Weld 1.0.1.SP3 (the version used in Glassfish 3.0.1) are serializable, but after serializing and deserializing the proxy, the method handler is broken and you get a null pointer exception when invoking any method of the proxy. i verified this in a

AW: AW: Serialization of injected EJBs

always use wicket-ioc module to build the proxy yourself just like we do for spring and guice, it should only be a couple of hours effort. -igor On Thu, Jul 8, 2010 at 10:34 AM, Harald Wellmann harald.wellm...@multi-m.de wrote: In theory, yes... The proxies returned by Weld 1.0.1.SP3 (the version

AW: AW: Serialization of injected EJBs

Thanks for pointing this out, however, I think it's a related but different issue. I did not notice any classloader problems in my case, and anyway, we deploy our entire application (web pages, EJBs and entity classes) in a single WAR. Regards, Harald -Ursprüngliche Nachricht- Von:

AW: AW: Serialization of injected EJBs

And Seam uses CDI/Weld, right? So your module might solve my problems... Is it public? Regards, Harald Von: Igor Vaynberg [igor.vaynb...@gmail.com] Gesendet: Freitag, 9. Juli 2010 18:06 An: users@wicket.apache.org Betreff: Re: AW: Serialization of

AW: AW: Serialization of injected EJBs

AM, Harald Wellmann harald.wellm...@multi-m.de wrote: And Seam uses CDI/Weld, right? So your module might solve my problems... Is it public? Regards, Harald Von: Igor Vaynberg [igor.vaynb...@gmail.com] Gesendet: Freitag, 9. Juli 2010 18:06 An: users

AW: Serialization of injected EJBs

Thanks, I'd seen that before. This code handles CDI injection in Wicket components (which was not the problem as such) and the conversation scope (which I haven't used so far) but as far as I can see it does not address any serialization issues with the injected references. Regards, Harald

Editable localized messages

The combination of wicket:message and custom IStringResourceLoader is really cool for building internationalized applications. We currently use a combination of static strings from property files and dynamic strings stored in a database table loaded via an IStringResourceLoader. To edit a

AW: Editable localized messages

you can extend it. The idea is to generate a href=... super.onComponentTagBody() /a On Wed, 2010-07-14 at 13:54 +0200, Harald Wellmann wrote: The combination of wicket:message and custom IStringResourceLoader is really cool for building internationalized applications. We currently use

Browser Back Button and WicketTester

Does WicketTester emulate the browser back button? E.g. tester.submitForm(myform); tester.goBack(); tester.submitForm(myform); // assert correct solution of double submit problem The Javadoc comment for WicketTester.NonPageCachingDummyWebApplication mentions the back button and

Is WicketFilter.checkCharacterEncoding() safe?

I'm not sure if this is severe or not, but I think there's a gap in the implicit assumptions underlying WicketFilter.checkCharacterEncoding(): It seems the author's intention was to guarantee a postcondition of servletRequest.getCharacterEncoding() != null, but this postcondition does not

Page Navigation in WicketTester

Using WicketTester, is it required to initialize each page under Test with tester.startPage()? I'm currently starting at a LoginPage and submit a form on that page to go to an IndexPage. Now the component tree of that page does not have the expected structure. After calling startPage() for

Wicket and OSGi

I'm currently trying to build an OSGi Enterprise stack using Wicket and Apache Aries, and I have a couple of questions and suggestions: 1) Why does the official Wicket artifact include a Dynamic-Import: * header? This should only be used as a last resort... 2) I'd like to @Inject OSGi services

Re: Wicket and OSGi

Am 22.06.2011 20:23, schrieb Igor Vaynberg: On Wed, Jun 22, 2011 at 10:57 AM, Harald Wellmann harald.wellm...@gmx.de wrote: I'm currently trying to build an OSGi Enterprise stack using Wicket and Apache Aries, and I have a couple of questions and suggestions: 1) Why does the official Wicket

Re: Wicket and OSGi

Am 22.06.2011 20:18, schrieb Martin Grigorov: 1) Why does the official Wicket artifact include a Dynamic-Import: * header? This should only be used as a last resort... https://issues.apache.org/jira/browse/WICKET-3737 Thanks, there's a lot of useful information in that ticket. 2) I'd like

Re: Wicket and OSGi

Am 22.06.2011 22:00, schrieb Igor Vaynberg: If the page class in bundle A directly references the component class C from bundle B (and not just an interface or base class of B from another bundle X), then the bundle class loader of A can load class C by delegation. not sure if that is true.

Re: Wicket and OSGi

Am 23.06.2011 18:48, schrieb Igor Vaynberg: there is a jira issue with a patch. That's probably the one that Martin mentioned: https://issues.apache.org/jira/browse/WICKET-3737 unfortunately someone has to build the classloader that can see all bundles. what is really needed here is

Re: Wicket and OSGi

Am 23.06.2011 19:11, schrieb Harald Wellmann: I'll take a look at the patches, play around with the code and find out if I'm one the wrong track or not... If I end up with anything interesting enough, I'll get back or attach another patch. Ok, here is my first shot at a solution

Re: Wicket and OSGi

Hi Mike, Am 26.06.2011 05:06, schrieb Michael O'Cleirigh: Hi Harald, Thanks for taking the time to implement your solution to the OSGi problem. If you could create a patch (or fork and then pull request; or commit directly) into the

Re: Wicket and OSGi

There is now a new module wicket-osgi in wicketstuff/core at Github with some glue code to adapt Wicket to OSGi house rules. Summary: - wicket-osgi supports bootstrapping a WicketApplication from the OSGi service registry, matching a property value specified as a WicketFilter init parameter

Re: Wicket and OSGi

Am 27.06.2011 22:13, schrieb Martin Grigorov: I also reviewed the code - good job! Thanks :-) I saw that you basically copy/pasted DefaultClassResolver to OsgiClassResolver with minor modifications. I think it will be better if we make DCR easier to extend so there is no need to copy/paste

Re: Wicket and OSGi

Am 28.06.2011 10:08, schrieb Daniël van 't Ooster: - This implementation assumes the web bundle knows about all bundles providing services; wicket-osgi currently assumes that the web application bundle (WAB) explicitly imports all packages or bundles which contribute Wicket components used

Re: WicketStuff artifacts naming strategy

For Maven OSGi bundle artifacts, there is a quasi-convention to have artifactId = Bundle-Symbolic name, so you would have groupId: org.wicketstuff artifactId: org.wicketstuff.foo.bar version: 1.5 Bundle-Symbolic-Name: org.wicketstuff.foo.bar JAR name: org.wicketstuff.foo.bar-1.5.jar Apache

Re: WicketFilter.init() called twice with Glassfish

Am 01.07.2011 18:30, schrieb Bertrand Guay-Paquet: Hello, I am deploying a Wicket 1.5 application inside an EAR on Glassfish 3.1. I noticed that the debug bar was doubled at the top of the browser window (2 full debug bars). After investigation, the problem is that WicketFIlter.init() is being

Re: Wicket/Spring/Junit/Maven - Don't understand what's going on.

Without a stacktrace or more details about your setup, I can only guess... Most likely it's not a Wicket problem. I'd say your applicationContext.xml is in the wrong place where Maven can't see it, and Eclipse just happens to see it because m2eclipse cannot map Maven classpaths 1:1 to

Re: Wicket and OSGi

Hi Andreas, thanks for providing the pointers and the brand new intro in the Pax Wicket wiki. This is now at least something to get started, and I'm beginning to see that there is some overlap with wicket-osgi or even the chance of wicket-osgi becoming obsolete in the near future as Pax

[wicketstuff-push] How to disconnect cleanly?

I'm experimenting with wicketstuff-push-timer, and I wonder if there's a way to cleanly uninstall a node. Use case: The server pushes a number of progress events during a long running action. When the action is finished, no more events will be sent, so there is no point for the browser to

Re: [wicketstuff-push] How to disconnect cleanly?

I'm currently doing timer.stop() in my application code before calling uninstallNode(), but that requires copying code from the private method TimerPushService._findPushBehavior(). So it seems the API could do with a couple of extensions for this case... Best regards, Harald 2011/10/11 vineet