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 semwal : > i think its better to do timerpushbehavior.stop() instead of > component.remove(behavior) > inside uninstallNode(component,node) but it might require other changes too .. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[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 continue polling the server. I've tried pushService.uninstallNode(), but I always end up with an exception of the following kind: Caused by: java.lang.IllegalStateException: Behavior must be added to component before its id can be generated. Behavior: org.wicketstuff.push.timer.TimerPushBehavior@3522971b, Component: org.apache.wicket.Behaviors@6d96e397 at org.apache.wicket.Behaviors.getBehaviorId(Behaviors.java:252) ~[wicket-core-1.5.1.jar:1.5.1] at org.apache.wicket.Component.getBehaviorId(Component.java:4413) ~[wicket-core-1.5.1.jar:1.5.1] at org.apache.wicket.Component.urlFor(Component.java:3290) ~[wicket-core-1.5.1.jar:1.5.1] at org.apache.wicket.behavior.AbstractAjaxBehavior.getCallbackUrl(AbstractAjaxBehavior.java:89) ~[wicket-core-1.5.1.jar:1.5.1] at org.apache.wicket.ajax.AbstractAjaxTimerBehavior.getCallbackScript(AbstractAjaxTimerBehavior.java:125) ~[wicket-core-1.5.1.jar:1.5.1] at org.apache.wicket.ajax.AbstractAjaxTimerBehavior.getJsTimeoutCall(AbstractAjaxTimerBehavior.java:118) ~[wicket-core-1.5.1.jar:1.5.1] It seems that uninstallNode() only removes the behaviour but does not stop the timer. Any hints welcome... Best regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 Wicket matures or just shifts its priorities a little from hacking to documenting all its goodies ;-) Some points after a very quick first look and comparison: - Pax Wicket head does not compile (https://ops4j1.jira.com/browse/PAXWICKET-164) - Pax Wicket is based on Wicket 1.4.17, wicket-osgi on 1.5-SNAPSHOT - Wicket 1.4.17 uses DynamicImport-Package: * - are you sure Pax Wicket would work without that? - The official Wicket 1.5 artifacts are not OSGi friendly, so if you upgrade Pax Wicket to 1.5, you'd have to use wicket-bundle from Wicketstuff, just like wicket-osgi. (Of course, I'd much prefer the Wicket core project to provide properly osgified artifacts without split packages and dynamic imports so we could scrap wicket-bundle...) Cheers, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 Eclipse.
In the blog you cited, this line looks suspicious to me:
@ContextConfiguration(locations =
{"classpath:WEB-INF/applicationContext.xml"})
If you have a default Maven project structure, then WEB-INF is under
src/main/webapp, and this is not on the test classpath for Surefire.
Regards,
Harald
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
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 called twice each time I start the server. This causes the debug bar contributors to register twice. My web.xml contains only Wicket and only once. Roughly the same code did not behave like this when I used an embedded jetty server and no EJBs or EAR (single WAR). I'm trying to set up an environment to step inside Glassfish and see why the filter is initialized twice. In the meantime, I ask has anybody seen this double-init behavior before? Yes, I've seen this on Glassfish 3.0, and the problem was reported as fixed: http://java.net/jira/browse/GLASSFISH-11979 Maybe there's a regression? Regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 Servicemix and Apache Aries use this convention, while Apache Commons sticks with the old names. Having this naming scheme and the one Bruno suggested in parallel would help to distinguish OSGi bundles from plain old JARs. Then again, that would mean you'd have to rename artifacts, once you osgify them. Regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 by the application. Otherwise, for the injection stuff, the WAB only needs to import the service interface packages, but not the implementation packages or bundles. in our case (the case attached to WICKET-3737 is a stripped down version), we have one 'web bundle', which hosts the Wicket application; individual bundles provide pages and their mount points (in the example case, bundles provide some panels). Yes, I had a look at that example - it's a rather advanced scenario and far more than what I'm currently aiming at with wicket-osgi. The first major goal I would like to achieve is support for the following scenario: - OSGi Web Container and Web Application Bundles according to OSGi Enterprise Spec 4.2. - Wicket is deployed as a plain old OSGi bundle. - One or more WABs are deployed as separate bundles. Each WAB provides a Web Application according to the Servlet Spec. The WABs are completely isolated from each other, just like plain old WARs. I don't think that your scenario with other bundles contributing new pages or resources to a running web application is currently covered by the OSGi Enterprise Spec. A WAB is always a single bundle, which may of course import packages and use services from other bundles, but for anything related to the Web Context Path, there is a one-to-one relation between context paths and bundles. At least that's my understanding, but I'm not in any of the Java EE or OSGi expert groups... Of course you can attach OSGi fragments to your WAB as bundle host, but an independent bundle registering services that contribute to a web context owned by some other bundle is currently out of scope, I'd say. Mind you, I'm not saying that your scenario doesn't make sense or cannot be done, but it sounds like the second or third step to me. Do you have examples of any OSGi Web containers supports your flavour of multi-bundle WABs? So far, I've looked at Pax Web, Eclipse Gemini Web and Glassfish, and my impression is they all follow the rule "one web context, one bundle". In cases like that, there is no single class loader which knows all classes, so you need one bundle with a DynamicImport-Package: *. I'd say your assumption is right, but your conclusion is not... Let's say your WAB retrieves WebPages from the service registry and mounts them. To do so, it only needs to load the WebPage base class from Wicket, but not the implementation class from some other bundle. In this situation, page deserialization will fail, because neither the Wicket bundle class loader nor your WAB nor the ThreadContextClassLoader can load the class from the contributor bundle. But even then, there are other and better solutions than DynamicImport-Package, which I think is something like an emergency amputation when you have to save your application's life and need to use some third-party lib that simply doesn't play by OSGi rules. > To reduce the number of bundle refreshes we delegate this job to a tiny 'class resolver bundle', which exposes an IClassResolver instance as OSGi service. And this class resolver bundle still uses dynamic imports, right? I'd suggest one of the following options: 1) Your contributor bundles provide an IContributor service for an interface exported by your WAB. Your WAB tracks all implementations, builds a composite ClassResolver from all their classloaders and registers the ClassResolver with Wicket. 2) Extender Pattern: You define a special manifest header that all your contributors need to include, then your WAB tracks bundle events, identifies its contributors from the manifest header and builds a composite ClassResolver as in 1). In any case, I would leave wicket-bundle and wicket-osgi out of the game. There may be more than one WAB, each with a number of contributor bundles, and the Wicket bundle cannot decide how to match them up. While generating JDK / CGLib proxies, you need a class loader which can access all proxied classes, one way to solve this is a minor change to the IClassResolver interface to get access to the almightly class loader. I have added a method getClassLoader(), which is used in the DefaultClassResolver to load classes. This simple change will save some code duplication in OSGi compatible classResolvers. What's your use case for these proxies? Do you create them at application level, or is this something that Spring DM does at framework level. - Another difference is how OSGi services are used; we are using Spring DM, which creates one applicationContext per bundle. Fields annotated with @SpringBean will be injected with beans (imported OSGi reference is also a bean) from the applic
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 its code. Actually, I'm no longer sure it is needed at all... The OsgiClassResolver uses the bundle class loader of the WAB, accessed via the current Application class. The DefaultClassResolver uses the ThreadContextClassLoader, or its own classloader as a fallback. I'd noticed before that my sample works on Jetty even without the OsgiClassResolver, and the same is true on GlassFish 3.1. Sahoo from the GlassFish team pointed out to me that any Servlet container is required to set the TCCL to the application classloader (see Servlet Spec 3.0, section 10.7.2) for loading resources and for any application callbacks. If everyone agrees that this covers all use cases where Wicket needs to load stuff from user bundles, then I think it's safe to scrap the OsgiClassResolver and let the unmodified DefaultClassResolver do the job. Could you also document the new module on wicketstuff wiki? https://github.com/wicketstuff/core/wiki Sure - that's the next thing on my list... I'm also planning to add some Surefire tests based on Pax Exam. Cheers, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 in web.xml. - OsgiClassResolver supports Wicket page deserialization. - OsgiComponentInjector lets you inject OSGi services into WIcket components by annotating fields with JSR-330 @Inject. - wicket-bundle, the all-in-one OSGi-compliant packaging of Wicket, now has a revised manifest without dynamic imports. - wicket-ioc-bundle (sibling of wicket-bundle) does the same for wicket-ioc, which is required by wicket-osgi. - wicket-osgi-test-web and wicket-osgi-test-service are two simple test bundles for testing the glue code in an OSGi web container (Pax Web). The sample uses Aries Blueprint to interact with the service registry, but of course you can also use Declarative Services or a BundleActivator. - To run the sample webapp: cd wicketstuff-core/jdk-1.5-parent/wicket-osgi-parent cd wicket-osgi-test-web mvn install pax:run Open http://localhost:8080/library in your browser. - To use wicket-osgi in your own projects, have a look at web.xml and LibraryApplication.java in wicket-osgi-test-web, and at the Javadoc in wicket-osgi. All of this is anything but final... Have a look at the code, give it a try and let me know that you think. Thanks, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/wicket-bundle-parent module that would be ideal. I can't tell if it should be integrated into the existing wicket-bundle or beside it as a new module (You can decide). Thanks for inviting me to commit. I think a new module wicket-osgi is required at least for the dependency injection stuff, because that depends on wicket-ioc. Only the configuration for the manifest minus DynamicImport-Package should go into wicket-bundle. If you need commit access just post to the dev list with your github username and we can add you. Will do so. My username is hwellmann. Once your changes are committed into wicketstuff the jenkins server (it polls github @hourly) will build them into wicketstuff-core 1.5-SNAPSHOT jars and other osgi users could run it and their feedback could be captured as project issues. Would it be possible to have a wicket-bundle-example project that is configured to launch itself using osgi to exercise the capabilities of the module? Maybe the maven-pax-plugin be used to accomplish this? I think since most wicket users don't seem to use osgi (me included) if an example could be created that anyone could run the amount of feedback would be greater. Yeah, I know - dealing with all the environment setup is really the hardest part and will probably take longer than writing the glue code itself, so my intention was just to publish some ideas and work in progress to get some early feedback and make sure I'm not on the wrong track. Maven and Pax are great for batch builds and integration tests for OSGi projects, but IMHO Eclipse PDE is much easier for developing and debugging. Unfortunately, the two approaches don't integrate very well. Anyway, I'm going to set up another example project which should be as self-contained as possible, leaving out all the JPA/JTA stuff which is not really relevant for the Wicket-OSGi integration (but then again, the larger goal is of course to create some kind of lightweight OSGi Enterprise software stack with persistence, transactions and Wicket on top.) Regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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. The IClassResolver using the client bundle class loader works as expected. OSGi service injection into Wicket components along the lines of wicket-spring is also working, as long as the required services are unique. All the details are explained in a Wiki page [1], and the glue code can be browsed online [2], or you can clone my sample repository from Google Code. Any feedback welcome! [1] http://code.google.com/p/osgi-enterprise/wiki/WicketAndOsgi [2] http://code.google.com/p/osgi-enterprise/source/browse/?name=0.1.0#hg%2Faries-pde%2Fcom.googlecode.osgienterprise.wicket.osgi%2Fsrc%2Fcom%2Fgooglecode%2Fosgienterprise%2Fwicket Regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 someone taking the time to build a generic serialization mechanism for osgi. wicket's serialization is pluggable so it can be hooked into that. 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. Thanks, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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.
given Wicket lives in bundle W
we have a component bundle C which provides component CommentPanel and imports W
we have an application bundle P which provides page PostPage and imports W and C
someone does
class PostPage extends page { PostPage() { add(new CommentPanel("c")); }}
so PostPage has a reference to class CommentPanel from C
wicket serializes PostPage.
now wicket deserializes PostPage from disk. W classloader now needs to
load PostPage and CommentPanel, but it sees neither of those because
it doesnt import them.
You're right, W's classloader cannot see the class from P or C. But the
thing is, when Wicket deserializes the page, it could use a derived
ObjectInputStream and override resolveClass() to use the class resolver
registered by the application.
This resolver wraps the bundle class loader P of the application, which
is able to load both PostPage and CommentPanel.
Regards,
Harald
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
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 to @Inject OSGi services into Wicket components using an IComponentInstantiationListener - is there a ready-to-go extension I could use? Yes. See how wicket-spring and wicket-guice use wicket-ioc There is also wicket-javaee at https://github.com/wicketstuff/core/tree/master/jdk-1.6-parent/javaee-inject-parent Yeah I know, but Spring is not OSGi. what do you mean ? you re-wrote wicket-spting ? why ? No of course I didn't. I adapted wicket-spring to use the standard @Inject annotation instead of @SpringBean. I never use @Autowired or other non-standard annotations when I can avoid it. also there is wicket-seam at github which integrates with CDI Seam is not CDI. wicket-seam has too many transitive dependencies on stuff I don't need. I'm using a modified version of org.wamblee.cdi - see http://apache-wicket.1842946.n4.nabble.com/Wicket-and-JEE6-td1893912i40.html Regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and OSGi
Am 22.06.2011 20:23, schrieb Igor Vaynberg: On Wed, Jun 22, 2011 at 10:57 AM, Harald Wellmann 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 artifact include a Dynamic-Import: * header? This should only be used as a last resort... because the OSGI spec does not handle serialization. wicket serializes a page that has a reference to component from bundle B later, wicket deserializes the page, it needs to deserialize component that came from bundle B so it needs access to the classloader from bundle B. 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. If C is not a component class but the type of a field in a component injected from the service layer (just like an EJB, but in this case it's an OSGi service obtained from the service registry), then you can replace the object by a reference, e.g. a service filter, on serialization and reinject the object on deserialization - isn't that just what wicket-ioc is doing? Regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 into Wicket components using an IComponentInstantiationListener - is there a ready-to-go extension I could use? 3) If not, would it be a good idea to create a wicket-osgi extension as part of Wicket or Wicketstuff? Regarding 1), I would assume that wrapping the bundle class loader of the user's application in an IClassResolver and registering it in Application.init() would do the trick, or doesn't it? As for 2) and 3), I wrote similar bridges both for CDI and Spring, building on wicket-ioc, so I do have an idea of what it takes, but of course I don't want to reinvent the wheel. Best regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 the same page class, the component
tree is correct:
tester.startPage(appl.getHomePage());
tester.assertRenderedPage(LoginPage.class);
FormTester formTester = tester.newFormTester("loginPanel:logInForm");
formTester.setValue("username", LOGIN);
formTester.setValue("password", PASSWORD);
formTester.submit();
tester.assertRenderedPage(IndexPage.class);
tester.debugComponentTrees(); // some components are missing
tester.startPage(IndexPage.class);
tester.debugComponentTrees(); // this is now the expected tree
In particular, the difference between the two component trees is that a list
view in the first tree is missing all list items.
I don't really understand what's going on here, so any hints would be very
helpful. (I'm using Wicket 1.4.10.)
Best regards,
Harald
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
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 hold in all cases. I ran into this issue after upgrading my Glassfish app server from 3.0.1 to 3.1-b12, containing a newer release of Weld which causes the problem to appear. After this upgrade, my log was full of warnings of the following type: WARN o.apache.catalina.connector.Request - PWC4011: Unable to set request character encoding to UTF-8 from context /xxx, because request parameters have already been read, or ServletRequest.getReader() has already been called Setting a couple of breakpoints revealed that Weld registers a ServletRequestListener and calls request.getParameter() in that listener. By specification, this listener gets called before all servlet filters, including WicketFilter, and again by specification, the invocation of servlet.request.setCharacterEncoding() from WicketFilter has no effect, since a request parameter has already been read by the WeldListener. So it there are other parts of Wicket relying on the request character encoding to be non-null, then this looks like a bug to me. Otherwise, if Wicket handles a null character encoding gracefully, then checkCharacterEncoding() is redundant, because it cannot be guaranteed to have any effect. Regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 seems to imply the WicketTester does support it by default,
but I don't see how...
Best regards,
Harald
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
AW: Editable localized messages
Hmm, yes, but then I'd have to add lots of tiny components to my pages. One of the main points of is to avoid just that, isn't it? Regards, Harald Von: Igor Vaynberg [igor.vaynb...@gmail.com] or rather create a component and use that instead of wicket:message -igor On Wed, Jul 14, 2010 at 5:21 AM, Martin Grigorov wrote: > Check org.apache.wicket.markup.resolver.WicketMessageResolver > This is the default handler for and it is registered in > org.apache.wicket.Application.internalInit() > > See whether you can extend it. > The idea is to generate super.onComponentTagBody() > > On Wed, 2010-07-14 at 13:54 +0200, Harald Wellmann wrote: >> The combination of 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 dynamic string, you need to know its key. Now it would be even >> cooler if you could simply click on a rendered string to open an edit form >> for the correct key. >> >> E.g. when a page is in edit mode (as indicated by a request parameter or an >> authentication role), is rendered not just as text but as a >> link. Clicking the link generates a request including the message key so you >> can open an edit form for the key. >> >> I'm not sure where to hook into Wicket's default behaviour to implement this >> kind of logic or if there are better approaches - any suggestions welcome. >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Editable localized messages
The combination of 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 dynamic string, you need to know its key. Now it would be even cooler if you could simply click on a rendered string to open an edit form for the correct key. E.g. when a page is in edit mode (as indicated by a request parameter or an authentication role), is rendered not just as text but as a link. Clicking the link generates a request including the message key so you can open an edit form for the key. I'm not sure where to hook into Wicket's default behaviour to implement this kind of logic or if there are better approaches - any suggestions welcome. Best regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 Von: jcar...@carmanconsulting.com [jcar...@carmanconsulting.com] im Auftrag von James Carman [ja...@carmanconsulting.com] Gesendet: Samstag, 10. Juli 2010 12:35 An: users@wicket.apache.org; korbinian.ba...@whiskyworld.de Betreff: Re: Serialization of injected EJBs Here's some work I did. See if it works for you: http://svn.carmanconsulting.com/public/wicket-cdi/trunk/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AW: AW: Serialization of injected EJBs
Ok, just wanted to make sure before duplicating any work. Anyway, using wicket-ioc and looking at wicket-guice, I implemented a small lib (two classes, actually) performing CDI injection on Wicket components, wrapping the reference returned from the CDI BeanManager in a proxy that is serializable and re-injects all injection points using the BeanManager on deserialization. This was indeed just a few hours' work ;-) BUT I currently only handle the most frequent case @Inject private Foo foo; Only field injection, no method, constructor or parameter injection, no qualifiers or stereotypes. Getting all that right, including test cases, would easily take a week or two, and the hardest part would not be the implementation itself but understanding all the details of the CDI spec and fighting with problems in the app server. (And I still think this serialization issue is really a bug in Glassfish.) At any rate, I'd be happy to share my code - would it make sense to create a small subproject wicket-cdi, either in wicket or in wicketstuff? I think this topic is of suffciently general interest, or at least will be, when more projects move to Java EE 6. Regards, Harald Von: Igor Vaynberg [igor.vaynb...@gmail.com] Gesendet: Freitag, 9. Juli 2010 20:03 An: users@wicket.apache.org Betreff: Re: AW: Serialization of injected EJBs no, the module is for seam 2.1 which does not use weld. -igor On Fri, Jul 9, 2010 at 10:55 AM, Harald Wellmann 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@wicket.apache.org > Betreff: Re: AW: Serialization of injected EJBs > > well, i recently wrote a wicket-ioc module for seam and it took me a > couple of hours :) > > -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 injected EJBs well, i recently wrote a wicket-ioc module for seam and it took me a couple of hours :) -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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: kbs [mailto:kbs_kulbhus...@yahoo.com] Gesendet: Freitag, 9. Juli 2010 09:17 An: users@wicket.apache.org Betreff: Re: AW: Serialization of injected EJBs I am not sure if this is related but AFAIR we faced a similar problem with GlassFish V2.1 and determined the root cause of this to https://issues.apache.org/jira/browse/WICKET-2416 The exception stack trace may be different in V3 so I am not sure if it is same issue. Regards, Kulbhushan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AW: AW: Serialization of injected EJBs
Ok, I see what you mean and I think that would work. Only I'm not so sure about the "couple of hours" (have you looked at CDI BeanManager...?) and with that approach, I would end up having 3 proxies between my Wicket component and my EJB. Anyway, this is probably faster to implement than waiting for a solution from Glassfish... Best regards, Harald -Ursprüngliche Nachricht- Von: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Gesendet: Donnerstag, 8. Juli 2010 21:45 An: users@wicket.apache.org Betreff: Re: AW: Serialization of injected EJBs hrm, if thats the case you can 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 wrote: > 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 simple test case, independent > of Wicket. This looks like the problem fixed in > https://jira.jboss.org/browse/JASSIST-97, though I'm not fully sure that this > is exactly the same issue. > > Anyway, I patched my Glassfish version with the most recent release of > Javassist containing the bugfix. With this fix, I already get a > NotSerializableException from Wicket when the current page is about to be > moved to the page store: > > protected java.lang.reflect.InvocationHandler java.lang.reflect.Proxy.h > [class=com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate] <- > field that is not serializable > > It seems that the stateless session bean implementation is wrapped in at > least two proxies, one generated by Glassfish (for getting the session bean > into the CDI context, equivalent to @EJB injection) and another one, > generated by Weld using Javassist, filling the @Inject injection point in my > Wicket component. The outer proxy is ok with the newer Javassist version, but > the inner proxy simply is not serializable because of > EJBLocalObjectInvocationHandlerDelegate. > > Using @EJB instead of @Inject, I just get the inner proxy, with the same > problem caused by EJBLocalObjectInvocationHandlerDelegate. > > So my impression is that Glassfish simply breaks the contract of my > serializable session bean interface. On the other hand, I wouldn't be > surprised if there was a paragraph somewhere in the Java EE specs stating > that EJBs shall not be serialized by the application (i.e. Wicket) because > the container takes care of passivation anyway... > > Has anybody tried Wicket+CDI+EJB on other app servers? (There aren't so many > supporting Java EE 6) > > Regards, > Harald > > > > Von: Igor Vaynberg [igor.vaynb...@gmail.com] > Gesendet: Donnerstag, 8. Juli 2010 17:54 > An: users@wicket.apache.org > Betreff: Re: AW: Serialization of injected EJBs > > im not sure if this is in a CDI spec or not, but afaik Weld will > return serializable proxies when you manually inject objects. so that > should work out of the box. > > -igor > > > - > 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 simple test case, independent of Wicket. This looks like the problem fixed in https://jira.jboss.org/browse/JASSIST-97, though I'm not fully sure that this is exactly the same issue. Anyway, I patched my Glassfish version with the most recent release of Javassist containing the bugfix. With this fix, I already get a NotSerializableException from Wicket when the current page is about to be moved to the page store: protected java.lang.reflect.InvocationHandler java.lang.reflect.Proxy.h [class=com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate] <- field that is not serializable It seems that the stateless session bean implementation is wrapped in at least two proxies, one generated by Glassfish (for getting the session bean into the CDI context, equivalent to @EJB injection) and another one, generated by Weld using Javassist, filling the @Inject injection point in my Wicket component. The outer proxy is ok with the newer Javassist version, but the inner proxy simply is not serializable because of EJBLocalObjectInvocationHandlerDelegate. Using @EJB instead of @Inject, I just get the inner proxy, with the same problem caused by EJBLocalObjectInvocationHandlerDelegate. So my impression is that Glassfish simply breaks the contract of my serializable session bean interface. On the other hand, I wouldn't be surprised if there was a paragraph somewhere in the Java EE specs stating that EJBs shall not be serialized by the application (i.e. Wicket) because the container takes care of passivation anyway... Has anybody tried Wicket+CDI+EJB on other app servers? (There aren't so many supporting Java EE 6) Regards, Harald Von: Igor Vaynberg [igor.vaynb...@gmail.com] Gesendet: Donnerstag, 8. Juli 2010 17:54 An: users@wicket.apache.org Betreff: Re: AW: Serialization of injected EJBs im not sure if this is in a CDI spec or not, but afaik Weld will return serializable proxies when you manually inject objects. so that should work out of the box. -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AW: AW: Serialization of injected EJBs
Yes, @EJB is still available, and it is still required in some cases. But the general approach to injection has changed with CDI. See http://seamframework.org/Community/InjectingWithEJBOrInject for a discussion. My original question is about how to use Wicket with CDI (injecting EJBs and other beans), and your suggestion is not to use CDI, which does not really solve the problem... By the way, the nice thing about @Inject is that you no longer have to use JNDI lookups or bean names in @EJB annotations. And the specific problem is NOT that @Inject does not not work for EJBs, but the injected proxies fail to serialize properly. If I understand the javaee-inject implementation correctly, it takes care not to serialize proxies but replaces them by references on serialization, looking up the same reference again on deserialization. I suppose my problem would be solved if the CDI InjectionTarget were using this approach, but this is a CDI implementation detail and out of my control. Anybody else out there using Wicket+CDI+EJB? Have you come across similar problems? Best regards, Harald -Ursprüngliche Nachricht- Von: Major Péter [mailto:majorpe...@sch.bme.hu] Gesendet: Mittwoch, 7. Juli 2010 19:43 An: users@wicket.apache.org Betreff: Re: AW: Serialization of injected EJBs Nope, it does not support CDI. AFAIK @EJB is not deprecated or old-style, and it's still available in Java EE 6. The thread was about injecting EJB's and JavaEE Inject does exactly 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. > > Regards, > > Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 18:37 An: users@wicket.apache.org Betreff: Re: Serialization of injected EJBs I'm using the lib in production with GlassFish v3 and for developing with GlassFish 3.0.1, and haven't seen this exception so far for my EJB's. Something is weird with your EJB... Could you check the javaee-inject-examples (1.4.10-SNAPSHOT) project with the same container? Thanks, Peter - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AW: AW: Serialization of injected EJBs
Hmmm, has anybody tried this on Glassfish? The exception I currently get is: org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException: Unable to serialize class: com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate protected java.lang.reflect.InvocationHandler java.lang.reflect.Proxy.h [class=com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate] <- field that is not serializable So it seems it's not the proxy itself that cannot be serialized but some delegate generated by Glassfish which is not serializable (even though my implementation class is). Regards, Harald -Ursprüngliche Nachricht- Von: Major Péter [mailto:majorpe...@sch.bme.hu] Gesendet: Mittwoch, 7. Juli 2010 17:12 An: users@wicket.apache.org Betreff: Re: AW: Serialization of injected EJBs JavaEE Inject generates a serializable proxy, so the injected 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 proxies. > > Regards, > > Harald > > -Ursprüngliche Nachricht- > Von: Major Péter [mailto:majorpe...@sch.bme.hu] > 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 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 that Wicket cannot serialize the page containing the >> given component. I'm not sure whether or not it is legal by the EJB 3.1 spec >> to have the proxy being not serializable when the underlying class is. Just >> assuming for the moment this is not a bug in Glassfish, what would be the >> best way of dealing with this in Wicket? >> >> Detaching the EJBs on serialization and re-injecting them on deserialization >> might work, but I'm not sure how to do this, and of course I would like that >> to happen behind the scenes, without having to provide event handlers in >> each and every component with injected EJBs. >> >> By the way, I'm using a ComponentInstantiationListener from >> https://wamblee.org/viewvc/wicket-cdi/ to deal with CDI, but the same issue >> occurs with old style @EJB injection as well. >> >> Any ideas? >> >> Best regards, >> >> Harald - 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
AW: Serialization of injected EJBs
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 proxies. Regards, Harald -Ursprüngliche Nachricht- Von: Major Péter [mailto:majorpe...@sch.bme.hu] 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 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 that Wicket cannot serialize the page containing the given > component. I'm not sure whether or not it is legal by the EJB 3.1 spec to > have the proxy being not serializable when the underlying class is. Just > assuming for the moment this is not a bug in Glassfish, what would be the > best way of dealing with this in Wicket? > > Detaching the EJBs on serialization and re-injecting them on deserialization > might work, but I'm not sure how to do this, and of course I would like that > to happen behind the scenes, without having to provide event handlers in each > and every component with injected EJBs. > > By the way, I'm using a ComponentInstantiationListener from > https://wamblee.org/viewvc/wicket-cdi/ to deal with CDI, but the same issue > occurs with old style @EJB injection as well. > > Any ideas? > > Best regards, > > Harald - 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
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 that Wicket cannot serialize the page containing the given component. I'm not sure whether or not it is legal by the EJB 3.1 spec to have the proxy being not serializable when the underlying class is. Just assuming for the moment this is not a bug in Glassfish, what would be the best way of dealing with this in Wicket? Detaching the EJBs on serialization and re-injecting them on deserialization might work, but I'm not sure how to do this, and of course I would like that to happen behind the scenes, without having to provide event handlers in each and every component with injected EJBs. By the way, I'm using a ComponentInstantiationListener from https://wamblee.org/viewvc/wicket-cdi/ to deal with CDI, but the same issue occurs with old style @EJB injection as well. Any ideas? Best regards, Harald - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
