I'm new to wicket and just recently started to use it for a new web
app for one of our projects. Today I came across a similar issue like
described in WICKET-4785, a ClassNotFoundException during deserialization of a
page. The interesting part about this in my mind is, that the
mentioned missing class was missing for a good reason: I simply
refactored a bit and renamed the class, redeployed and restarted my
Tomcat. This looks like a normal use case to me, but is something I
didn't thought of when I've read through the docs because.
My deployment is very simple: I check out a SVN working copy with a
pre-configured tag containing the whole application once and
afterwards just need to merge/update and stop/start the web
server/app.
How is deployment supposed to work in Wicket after I have refactored
or otherwise changed my classes regarding cached and serialized pages?
Is there anything I need to tell wicket to clear its caches on each
deployment or ignore those or whatever? Am I forced to not delete once
deployed classes for a fair period of time? That would be a litte
nightmare... Or is there any other issue I ran into I should have
avoided?
Obviously others do deploy their Wicket apps as well, so I hope you
have some input on how to avoid the problem I've ran into. Thanks!
The important parts of the stacktrace:
java.lang.ClassNotFoundException: de.am_soft.util.frontend.wicket.markup.link.LogoutLink
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.apache.wicket.application.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108)
at org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream.resolveClass(JavaSerializer.java:218)
at java.io.ObjectInputStream.[...]
at org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:122)
at org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:396)
at org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:135)
at org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:203)
at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:360)
at org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:107)
I posted this question on the Wicket users list as well, but didn't get much response yet, although I thought this is an easy question...
Wicket is a stateful web framework that stores page instances to facilitate a tight user interaction between browser and server. This means serializing the component hierarchy of each page so a user can interact with the component hierarchy, modify it (replacing panels for example) and expect the client and server to be in sync.
When you refactor your classes such as renaming a link class, the deserializer can't find that class and you get this ClassNotFoundException. To mitigate this you:
a. need to start a new session in your browser so that Wicket doesn't tie your browser to the server state with the old classes (throw the jsessionid cookie away), or
b. construct a new page instance inside your session (remove the ?0 or ?1231 parameter in the URL in your browser), or
c. clear all session data on the server
Related
GWT's servlet implementation has onBefore/onAfterDeserialization which would give me a hook with which to start and stop transactions without doing anything fancy, however those methods don't allow me to properly check for error conditions after the service method got invoked, I just have access to the serialized return value, not directly to any exception that might have been thrown, so deciding whether to roll back or not is not possible that way without rewriting parts the GWT servlet.
I was thinking about using aspectj's compile-time weaving. However, this does not work with Netbeans' compile-on-save feature because the module needs to be recompiled using the aspectj compiler.
How about LTW (load-time-weaving)? Is there any way (or example) to add LTW to the webapp container without using the Spring framework?
I was also thinking about using AOP based on Java dynamic proxies, ie. to put a proxy in front of the servlet. Again, the question arises how to tell the Jetty WebApp container to load the proxy instead of the original servlet.
Or is there any ready-to-use solution out there already?
I think you could overwrite a combination of
public String processCall(RPCRequest rpcRequest) from RemoteServiceServlet and RPC.invokeAndEncodeResponse to do what you want.
Not ideal, as you need to copy/paste a few lines of code, but they really are only a few.
I myself hit the same problems as I needed some customizations, and relevant methods didn't had the access modifier that I needed, so I ended up copy/pasting some portions.
I can't comment on the rest of your question, but I don't expect to find any ready-to-use solutions, as GWT-RPC doesn't seem to have any new fans out there; just people maintaining legacy systems. Therefore, I expect that you either don't find anything or find solutions that are no longer maintained.
I'm in the process of exposing some of the data generated in one OSGi bundle with a REST interface so it can be consumed with typical http requests afterwards by anyone. To do this I'm using a combination of apache-cxf, JAX-RS and Jetty (for testing purposes mostly).
My whole application is distributed in two ways:
Core: Runs a set of minimal bundles as an OSGi framework.
Full: Core + plus a set of plugins to be used within Eclipse, in a graphical way, to put it that way.
While in the Core launch configuration I can make this work without any problems, have a look at the MANIFEST:
Require-Bundle: cxf-dosgi-ri-singlebundle-distribution;bundle-version="1.3.1",org.eclipse.core.runtime, org.eclipse.osgi.services;bundle-version="3.3.0", org.mortbay.jetty.server;bundle-version="6.1.23", org.mortbay.jetty.util;bundle-version="6.1.23"
When I try to launch the Full distribution, jetty server does not seem to start and thus, the RESTful service is not working properly. Full distribution comes with a lot more plugins, mostly related with wizards, perspectives and so on. Root of this problem is somehow related with the cxf-dosgi-ri-singlebundle-distribution bundle, and can be tackled by "forcing" auto-start of this bundle to true, instead of default (check image below):
While this is OK, my question is ...why is this happening? And second and most important, I distribute the Full distribution via an update site, so users can download it, open perspective and start using it, that said, will this affect the final distribution? Is there a way I can control this auto-start=true for the apache-cxf bundle in the update site?
Hope I can make myself clear...
Thanks!
I don't like answering my own questions, but since I'm getting no feedback and maybe someone else has the same problem...here it goes
I decided to change the whole design of my restful bundle, by not using apache-cxf, since it is really not needed. All I need to do what I want is the embedded Jetty server and javax for dealing with HttpRequests and HttpResponses. Thus, I get rid of dependecies with third party libraries, leveraging the launching problems at the same time.
Got the ideas from these official sites in Eclipe:
Embedding an HTTP server in Equinox
Writing a bundle-based server application
Besides, a more hands-on tutorials can be also found here:
OSGi as a Web Server application
Extending Eclipse: displaying HTML content from a bundled archive
Special thanks to both authors for the enlightenment :).
I find no documentation on how to update objects vaadin asynchronously. Can anyone help me? What I need is to render a table and then update the values of a column with a call rather slow, and so I want to make it asynchronous ..
This has been discussed a lot on this thread on the Vaadin forum. You might want to read it, it contains a lot of useful information.
Just do the updates in another thread. UI modifications from background threads must be synchronized to application object. Add icepush, refresher or proggresbar to get changes from server to client.
As far as I know Vaadin provides two add-ons for solving this problem: ServerPush and DontPush. Both add-ons can be imported via maven and both support WebSockets as well as fallback solutions for browsers without WebSocket support. Although ServerPush provides seemingly more features than DontPush, it is lower rated than DontPush, probably because it is more complicated.
For pushing updates to the client DontPush provides a very simple solution that does not require any changes to the web application. Only the servlet-class in web.xml needs to be replaced by org.vaadin.dontpush.server.impl.jetty.DontPushServlet and the widget set has to be updated afterwards via mvn vaadin:update-widgetset. That's all. Any changes on the server will be automatically pushed to the client. I successfully tested this add-on with Chrome 14. Unfortunately, I could not get it working with Firefox 7.
According to the web page of ServerPush the ServerPush add-on should provide this functionality, too. However, I could not figure out how to setup ServerPush to be working with jetty. Moreover, it seems to be more complicated in use. It requires several changes to the web.xml as well as additional configuration files for the atmosphere server.
In contrast to DontPush ServerPush provides also an explicit pushing mechanism which allows to update the GUI manually by calling the push() method of a certain pusher component which needs to be added to the main window beforehand. However, I also failed to get this working.
Hey guys. We're using OSGi services in an Eclipse RCP application. To track them, we're using the org.osgi.util.tracker.ServiceTracker class. A sample code from the application looks like
mailServiceTracker = new ServiceTracker(context, MailService.class.getName(), null);
mailServiceTracker.open();
MailService service = (MailService) mailServiceTracker.getService();
Now my problem is that the getService() method frequently returns null when I created a new service. The code works very well for services that are existing for a long time in the application, but each time I create a new service, I have to do many things until the service is finally found and tracked. I regularly try for example
'Clean...' in Eclipse
'Refresh' all projects in Eclipse
Rebuild the project on the command line
Sometimes those things help, and sometimes they don't. Does anyone have experiences with those trackers and can tell me how to avoid this behavior and how to get the services tracked immediately upon creation?
Thanks
The problem is that the services you want may not have been created yet (especially in an bundle activator, as some bundles may not yet have started). If you still want to use the service tracker, you will need to provide a ServiceTrackerCustomizer, and keep track (sorry, no pun intended) of the services as they come and go.
Or, you could just switch over to Declarative Services that handle this for you.
There is nothing wrong with using ServiceTrackers other than the fact that it's a fairly low-level way of tracking services. Whilst I agree that declarative services are a nice mechanism, simply dismissing ServiceTrackers because of "all sorts of issues" sounds like bad advice.
Back to the question.
As soon as a service tracker is created and opened, it gives you access to all services that match the filter condition you specified upon creation. There is no delay there. The only thing I can think about is that somehow your bundles are not correctly resolved, so services that are registered from a bundle A are simply not visible to a bundle B using a ServiceTracker. To check this, first locate the bundle that exports the package containing the service interface, and then make sure both A and B are actually wired to it.
Explaining the update/refresh mechanism in OSGi a bit more:
Whenever you update something in OSGi, it's a two step process.
Let's assume you update a bundle that contains a new version of an exported package. Let's also assume there is some consumer that imports it. As long as you only update the bundle but not explicitly refresh the wiring (of which import links to which export) the consumer will still be wired to the old version of the package. As soon as you do a package refresh (something you can do in OSGi via the PackageAdmin service) your consumer will be resolved again and will be wired to the new version.
The reason this is decoupled is that you might want to do updates of several bundles and not "refresh" after each one but instead defer such a refresh until all of them are updated.
It's quite possible that this is the effect you're seeing. Initially you only do an update, and only after the refresh will the tracker actually see the new version of the service.
Not being flippant at all, don't use service trackers. They appear to make your life simple, but there are all sort of issues with them. I'd recommend that you look into using Declarative Services instead. The support for DS in Eclipse has been very good from 3.5 onward.
You might want to check out this book and the associated presentations for more information on why using Service Trackers is a bad idea.
http://equinoxosgi.org/
I've recently adopted the GWT framework and I've run into trouble.
I'm creating a simple web-app which provides an input textarea and a list where the written articles are listed, a guestbook application if you will.
Now the problem is that I can't figure out how to maintain the list in a servletContext() - a global list. I can store data in a single session, but that wont do any good, since the point is that users have to look at the same list, not an individual one.
With Java servlets I'm used to storing objects in the ServletContext() which is globally available, but for the love of me I can't figure out how to do this with GWT.
Does anyone know how I can achieve this?
Thank alot!
Pretty straightforward -
Write a GWT RPC service as explained here - http://code.google.com/webtoolkit/doc/latest/DevGuideServerCommunication.html
The class that you write is just a normal java servlet. So you can invoke do the following to get the ServletContext
ServletContext servletContext = getServletContext();
Having said that, you are better off storing the data to a database. ServletContext will not persist the data, it will be lost the moment you restart your server.