Missing com.vaadin.data

[jakubklimek]

When replacing RUIAN dpu (no additional/new dependencies)

[tomas-knap]

That also happens to me yesterday on master branch, when trying to use master branch on localhost.

in the log:

2014-01-24 10:02:24,923 [http-bio-8080-exec-756] WARN c.c.m.x.o.commons.app.module.DPUModuleManipulator - Failed to load bunle during replace. cz.cuni.mff.xrg.odcs.commons.app.module.ModuleException: org.osgi.framework.BundleException: The bundle "cz.cuni.mff.xrg.odcs.Extractor_ruian_1.0.0 [26]" could not be resolved. Reason: Missing Constraint: Import-Package: com.vaadin.data; version="[7.1.10,8.0.0)" at cz.cuni.mff.xrg.odcs.commons.app.module.osgi.BundleContainer.loadClass(BundleContainer.java:131) ~[commons-app-1.0.0.jar:na] at cz.cuni.mff.xrg.odcs.commons.app.module.osgi.OSGIModuleFacade.update(OSGIModuleFacade.java:209) ~[commons-app-1.0.0.jar:na] at cz.cuni.mff.xrg.odcs.commons.app.module.DPUModuleManipulator.replace(DPUModuleManipulator.java:310) ~[commons-app-1.0.0.jar:na] at cz.cuni.mff.xrg.odcs.frontend.gui.views.dpu.DPUPresenterImpl.copyToTarget(DPUPresenterImpl.java:217) [DPUPresenterImpl.class:na] at cz.cuni.mff.xrg.odcs.frontend.gui.views.dpu.DPUPresenterImpl.dpuUploaded(DPUPresenterImpl.java:197) [DPUPresenterImpl.class:na] at cz.cuni.mff.xrg.odcs.frontend.gui.views.dpu.DPUPresenterImpl.dpuUploadedEventHandler(DPUPresenterImpl.java:258) [DPUPresenterImpl.class:na] at cz.cuni.mff.xrg.odcs.frontend.gui.views.dpu.DPUViewImpl$15.uploadSucceeded(DPUViewImpl.java:640) [DPUViewImpl$15.class:na] at cz.cuni.mff.xrg.odcs.frontend.gui.AuthAwareUploadSucceededWrapper.uploadSucceeded(AuthAwareUploadSucceededWrapper.java:44) [AuthAwareUploadSucceededWrapper.class:na] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40] at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40] at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:508) [vaadin-server-7.1.8.jar:7.1.8] at com.vaadin.event.EventRouter.fireEvent(EventRouter.java:167) [vaadin-server-7.1.8.jar:7.1.8] at com.vaadin.server.AbstractClientConnector.fireEvent(AbstractClientConnector.java:969) [vaadin-server-7.1.8.jar:7.1.8] at com.vaadin.ui.Upload.fireUploadSuccess(Upload.java:811) [vaadin-server-7.1.8.jar:7.1.8] at com.vaadin.ui.Upload$1.streamingFinished(Upload.java:1070) [vaadin-server-7.1.8.jar:7.1.8] at com.vaadin.server.communication.FileUploadHandler.streamToReceiver(FileUploadHandler.java:567) [vaadin-server-7.1.8.jar:7.1.8] at com.vaadin.server.communication.FileUploadHandler.handleFileUploadValidationAndData(FileUploadHandler.java:432) [vaadin-server-7.1.8.jar:7.1.8] at com.vaadin.server.communication.FileUploadHandler.doHandleSimpleMultipartFileUpload(FileUploadHandler.java:395) [vaadin-server-7.1.8.jar:7.1.8] at com.vaadin.server.communication.FileUploadHandler.handleRequest(FileUploadHandler.java:280) [vaadin-server-7.1.8.jar:7.1.8] at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1371) [vaadin-server-7.1.8.jar:7.1.8] at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:238) [vaadin-server-7.1.8.jar:7.1.8] at cz.cuni.mff.xrg.odcs.frontend.ODCSApplicationServlet.service(ODCSApplicationServlet.java:67) [ODCSApplicationServlet.class:na] at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) [servlet-api.jar:na] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) [catalina.jar:7.0.33] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) [catalina.jar:7.0.33] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) [catalina.jar:7.0.33] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) [catalina.jar:7.0.33] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) [catalina.jar:7.0.33] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) [catalina.jar:7.0.33] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) [catalina.jar:7.0.33] at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:931) [catalina.jar:7.0.33] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) [catalina.jar:7.0.33] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) [catalina.jar:7.0.33] at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) [tomcat-coyote.jar:7.0.33] at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) [tomcat-coyote.jar:7.0.33] at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) [tomcat-coyote.jar:7.0.33] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_40] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_40] at java.lang.Thread.run(Thread.java:724) [na:1.7.0_40] Caused by: org.osgi.framework.BundleException: The bundle "cz.cuni.mff.xrg.odcs.Extractor_ruian_1.0.0 [26]" could not be resolved. Reason: Missing Constraint: Import-Package: com.vaadin.data; version="[7.1.10,8.0.0)" at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1332) ~[org.eclipse.osgi-3.9.0.v20130305-2200.jar:na] at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1316) ~[org.eclipse.osgi-3.9.0.v20130305-2200.jar:na] at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323) ~[org.eclipse.osgi-3.9.0.v20130305-2200.jar:na] at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300) ~[org.eclipse.osgi-3.9.0.v20130305-2200.jar:na] at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:292) ~[org.eclipse.osgi-3.9.0.v20130305-2200.jar:na] at cz.cuni.mff.xrg.odcs.commons.app.module.osgi.BundleContainer.loadClass(BundleContainer.java:128) ~[commons-app-1.0.0.jar:na] ... 40 common frames omitted 2014-01-24 10:02:24,932 [http-bio-8080-exec-756] DEBUG org.eclipse.persistence.logging.sql - 2014-01-24 10:02:24.932--ServerSession(1176131117)--Connection(1497035875)--Thread(Thread[http-bio-8080-exec-756,5,main])--SELECT ID, config_valid, description, jar_description, jar_directory, jar_name, name, configuration, visibility, TYPE, use_dpu_description, user_id, parent_id FROM dpu_template WHERE (ID = ?)

[tomas-knap]

Could be cause by older version of vaadin on the server. Btw. why is the range of versions not .e.g. 7.0.0 - 8.0.0.?

[tomas-knap]

I mean by older version exported by frontend

[tomas-knap]

there is verson 7.1.8 exported

[tomas-knap]

To discuss: Can we have some tolerance? E.g if the version changes from 7.1.X to 7.1.Y, it is a minor change and there is typically no need to rebuild all DPUs compatible with 7.1.X

[skodapetr]

Well there is some tolerance .. as can been seen from the picture the DPU use 7.1.10 - 8.0.0. ... the problem is that the DPU has newer version then ODCS - which can happen only if the ODCS has not been redeployed as the Vaadin version is taken from ODCS.

In the opposite situation it should work fine, we can update the ODCS .. and the DPUs will still work (as it can use Vaddin version used in compilation time up to version 8.0.0).

But if the DPU will be updated faster hen the ODCS this problem appears.

Such behaviour may be required .. as with the new version new functionality can appear .. but the old will be first mark as deprecated and then sometime removed, probably with some greater version change .. so imho as it's not so bad.

We can declare .. DPU requires Vaadin 7.0.0. - 8.0.0 but, this can be a little risky as we do not know if the DPUs will really works.

---

One solution can be .. let dpu use such range .. and add additional information about Vaadin version into the DPU's manifest. It can be read on import and we may warn the user .. that the DPU's Vaadin version is new, or much older .. and it may not work properly. But honestly I have no idea what happen in case of different version .. probably it may rise ClassNotFound or NoSuchMehod error .. which then require that our application (frontend) catches not only Exceptions but also .. and best .. Throwable

[tomas-knap]

Well, can we extend the error message? If the version required by the DPU is more then version exported by the app, we can write: "The application is using older version of Vaadin then the DPU requires. Please contact administrator to update the Vaadin version on the server"

Alternatively, we can write: "Update you DPU, it is using old version of Vaadin not supported by the application"

And we can add this note only for Vaadin packeges, or in general.

But I am putting that as fw.