David H Nebinger 8 Years Ago The trick with serving the resources, of course, is that they do not always come from the Vaadin jar files.If you use an add-on you have to recompile the widgetset so you get a new set of JS files; those won't be in the Vaadin jars. If you create a custom Vaadin theme, well those also won't be in the Vaadin jars. It may be worthwhile to still put these resources under /html/VAADIN so they can be updated as necessary.I do like the approach as it continues the "shared environment" model for Vaadin 7. Please sign in to reply. Reply as... Cancel Sampsa Sohlman David H Nebinger 8 Years Ago The resources part I'm not happy yet. For solution, I would like to see simple as deploying those as new OSGi components. May be to do widgetset compilation during the deployment and undeployment? Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago You can't confuse the standalone model that James and Vaadin had demoed for portlets with a shared OSGi container.In the standalone model you can use addons and themes and, when you build your project you compile the widgetset and themes so they are part of your deployment artifact.In the shared model, however, addons and themes are global. A portlet plugin with a need for an addon can deploy it and compile the widgetset all outside of building your portlet deployment artifact.Compiling the widgetset in the shared model requires access to all of the add ons so the complete widgetset can be compiled.This is completely outside of the build process for your Vaadin 7 plugin. It's not even part of the deployment artifact.No, I think you're still going to need to use the standard /html/VAADIN path for all of the static resources.Good news, though! The Vaadin 7 Control Panel which helps you manage your shared V7 environment under Liferay 6 will support L7 when it's available. I'll have to integrate support for the OSGi container, but I would expect that it should be just as easy to manage the shared resources under L7 as it is under L6 Please sign in to reply. Reply as... Cancel Sampsa Sohlman David H Nebinger 8 Years Ago Hi David,OSGi the application should be splitted to multiple modules. Vaadin OSGi app can also at UI level have many modules, so when you deploy new module you get new view to your portlet(s). So application architecture has more options. For portal, I think shared model is better than bundling all to the same plugin. Goal of the OSGi is to have smaller plugins, but more of them and more reuse.About the widgetset compilation and thirdpty Vaadin components, I'm wondering, how many of these Vaadin components will have OSGi manifest entries. That might be something that might limit their usage or may be it could be instructed how convert those to OSGi components? At Liferay 7 we will not have /html/VAADIN folder anymore as do not bundle Vaadin anymore, so somekind of way to serve resources those has to be done and I believe that will still have big room for Vaadin control panel Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago I'm not sure how many addons will be OSGi-ready. I'm planning on testing whether they are available via the Liferay ROOT class loader somehow.Liferay 7 might not have /html/VAADIN folder, but the V7CP will be able to create and populate it. Having it there as part of an initial deploy was merely a shortcut for leveraging Vaadin 6.8, it wasn't the only way of populating the folder (as has been shown by the various Vaadin control panels for V6 and V7).I just don't know that it would be necessary to compile the widgetset into an OSGi bundle when it should be just fine to serve resources from the existing /html/VAADIN directory in the shared model.Anyway it's certainly a fun time to be working with V7 in L7! Please sign in to reply. Reply as... Cancel Sampsa Sohlman David H Nebinger 8 Years Ago I think many of the addon's needs to be repackaged with OSGI manifest as developer have never heard of OSGi.I'm thinking different options for resource sharing. May be some kind of DS component model where you could plug in and serve newly compiled resources instead of default ones etc. .. I'm still thinking.So have you created already first version of your Vaadin control panel for Liferay 7? Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago So have you created already first version of your Vaadin control panel for Liferay 7?No, LR might be at a good milestone but the maven artifacts to build for L7 have been giving me fits... Please sign in to reply. Reply as... Cancel
Sampsa Sohlman David H Nebinger 8 Years Ago The resources part I'm not happy yet. For solution, I would like to see simple as deploying those as new OSGi components. May be to do widgetset compilation during the deployment and undeployment? Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago You can't confuse the standalone model that James and Vaadin had demoed for portlets with a shared OSGi container.In the standalone model you can use addons and themes and, when you build your project you compile the widgetset and themes so they are part of your deployment artifact.In the shared model, however, addons and themes are global. A portlet plugin with a need for an addon can deploy it and compile the widgetset all outside of building your portlet deployment artifact.Compiling the widgetset in the shared model requires access to all of the add ons so the complete widgetset can be compiled.This is completely outside of the build process for your Vaadin 7 plugin. It's not even part of the deployment artifact.No, I think you're still going to need to use the standard /html/VAADIN path for all of the static resources.Good news, though! The Vaadin 7 Control Panel which helps you manage your shared V7 environment under Liferay 6 will support L7 when it's available. I'll have to integrate support for the OSGi container, but I would expect that it should be just as easy to manage the shared resources under L7 as it is under L6 Please sign in to reply. Reply as... Cancel Sampsa Sohlman David H Nebinger 8 Years Ago Hi David,OSGi the application should be splitted to multiple modules. Vaadin OSGi app can also at UI level have many modules, so when you deploy new module you get new view to your portlet(s). So application architecture has more options. For portal, I think shared model is better than bundling all to the same plugin. Goal of the OSGi is to have smaller plugins, but more of them and more reuse.About the widgetset compilation and thirdpty Vaadin components, I'm wondering, how many of these Vaadin components will have OSGi manifest entries. That might be something that might limit their usage or may be it could be instructed how convert those to OSGi components? At Liferay 7 we will not have /html/VAADIN folder anymore as do not bundle Vaadin anymore, so somekind of way to serve resources those has to be done and I believe that will still have big room for Vaadin control panel Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago I'm not sure how many addons will be OSGi-ready. I'm planning on testing whether they are available via the Liferay ROOT class loader somehow.Liferay 7 might not have /html/VAADIN folder, but the V7CP will be able to create and populate it. Having it there as part of an initial deploy was merely a shortcut for leveraging Vaadin 6.8, it wasn't the only way of populating the folder (as has been shown by the various Vaadin control panels for V6 and V7).I just don't know that it would be necessary to compile the widgetset into an OSGi bundle when it should be just fine to serve resources from the existing /html/VAADIN directory in the shared model.Anyway it's certainly a fun time to be working with V7 in L7! Please sign in to reply. Reply as... Cancel Sampsa Sohlman David H Nebinger 8 Years Ago I think many of the addon's needs to be repackaged with OSGI manifest as developer have never heard of OSGi.I'm thinking different options for resource sharing. May be some kind of DS component model where you could plug in and serve newly compiled resources instead of default ones etc. .. I'm still thinking.So have you created already first version of your Vaadin control panel for Liferay 7? Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago So have you created already first version of your Vaadin control panel for Liferay 7?No, LR might be at a good milestone but the maven artifacts to build for L7 have been giving me fits... Please sign in to reply. Reply as... Cancel
David H Nebinger Sampsa Sohlman 8 Years Ago You can't confuse the standalone model that James and Vaadin had demoed for portlets with a shared OSGi container.In the standalone model you can use addons and themes and, when you build your project you compile the widgetset and themes so they are part of your deployment artifact.In the shared model, however, addons and themes are global. A portlet plugin with a need for an addon can deploy it and compile the widgetset all outside of building your portlet deployment artifact.Compiling the widgetset in the shared model requires access to all of the add ons so the complete widgetset can be compiled.This is completely outside of the build process for your Vaadin 7 plugin. It's not even part of the deployment artifact.No, I think you're still going to need to use the standard /html/VAADIN path for all of the static resources.Good news, though! The Vaadin 7 Control Panel which helps you manage your shared V7 environment under Liferay 6 will support L7 when it's available. I'll have to integrate support for the OSGi container, but I would expect that it should be just as easy to manage the shared resources under L7 as it is under L6 Please sign in to reply. Reply as... Cancel Sampsa Sohlman David H Nebinger 8 Years Ago Hi David,OSGi the application should be splitted to multiple modules. Vaadin OSGi app can also at UI level have many modules, so when you deploy new module you get new view to your portlet(s). So application architecture has more options. For portal, I think shared model is better than bundling all to the same plugin. Goal of the OSGi is to have smaller plugins, but more of them and more reuse.About the widgetset compilation and thirdpty Vaadin components, I'm wondering, how many of these Vaadin components will have OSGi manifest entries. That might be something that might limit their usage or may be it could be instructed how convert those to OSGi components? At Liferay 7 we will not have /html/VAADIN folder anymore as do not bundle Vaadin anymore, so somekind of way to serve resources those has to be done and I believe that will still have big room for Vaadin control panel Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago I'm not sure how many addons will be OSGi-ready. I'm planning on testing whether they are available via the Liferay ROOT class loader somehow.Liferay 7 might not have /html/VAADIN folder, but the V7CP will be able to create and populate it. Having it there as part of an initial deploy was merely a shortcut for leveraging Vaadin 6.8, it wasn't the only way of populating the folder (as has been shown by the various Vaadin control panels for V6 and V7).I just don't know that it would be necessary to compile the widgetset into an OSGi bundle when it should be just fine to serve resources from the existing /html/VAADIN directory in the shared model.Anyway it's certainly a fun time to be working with V7 in L7! Please sign in to reply. Reply as... Cancel Sampsa Sohlman David H Nebinger 8 Years Ago I think many of the addon's needs to be repackaged with OSGI manifest as developer have never heard of OSGi.I'm thinking different options for resource sharing. May be some kind of DS component model where you could plug in and serve newly compiled resources instead of default ones etc. .. I'm still thinking.So have you created already first version of your Vaadin control panel for Liferay 7? Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago So have you created already first version of your Vaadin control panel for Liferay 7?No, LR might be at a good milestone but the maven artifacts to build for L7 have been giving me fits... Please sign in to reply. Reply as... Cancel
Sampsa Sohlman David H Nebinger 8 Years Ago Hi David,OSGi the application should be splitted to multiple modules. Vaadin OSGi app can also at UI level have many modules, so when you deploy new module you get new view to your portlet(s). So application architecture has more options. For portal, I think shared model is better than bundling all to the same plugin. Goal of the OSGi is to have smaller plugins, but more of them and more reuse.About the widgetset compilation and thirdpty Vaadin components, I'm wondering, how many of these Vaadin components will have OSGi manifest entries. That might be something that might limit their usage or may be it could be instructed how convert those to OSGi components? At Liferay 7 we will not have /html/VAADIN folder anymore as do not bundle Vaadin anymore, so somekind of way to serve resources those has to be done and I believe that will still have big room for Vaadin control panel Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago I'm not sure how many addons will be OSGi-ready. I'm planning on testing whether they are available via the Liferay ROOT class loader somehow.Liferay 7 might not have /html/VAADIN folder, but the V7CP will be able to create and populate it. Having it there as part of an initial deploy was merely a shortcut for leveraging Vaadin 6.8, it wasn't the only way of populating the folder (as has been shown by the various Vaadin control panels for V6 and V7).I just don't know that it would be necessary to compile the widgetset into an OSGi bundle when it should be just fine to serve resources from the existing /html/VAADIN directory in the shared model.Anyway it's certainly a fun time to be working with V7 in L7! Please sign in to reply. Reply as... Cancel Sampsa Sohlman David H Nebinger 8 Years Ago I think many of the addon's needs to be repackaged with OSGI manifest as developer have never heard of OSGi.I'm thinking different options for resource sharing. May be some kind of DS component model where you could plug in and serve newly compiled resources instead of default ones etc. .. I'm still thinking.So have you created already first version of your Vaadin control panel for Liferay 7? Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago So have you created already first version of your Vaadin control panel for Liferay 7?No, LR might be at a good milestone but the maven artifacts to build for L7 have been giving me fits... Please sign in to reply. Reply as... Cancel
David H Nebinger Sampsa Sohlman 8 Years Ago I'm not sure how many addons will be OSGi-ready. I'm planning on testing whether they are available via the Liferay ROOT class loader somehow.Liferay 7 might not have /html/VAADIN folder, but the V7CP will be able to create and populate it. Having it there as part of an initial deploy was merely a shortcut for leveraging Vaadin 6.8, it wasn't the only way of populating the folder (as has been shown by the various Vaadin control panels for V6 and V7).I just don't know that it would be necessary to compile the widgetset into an OSGi bundle when it should be just fine to serve resources from the existing /html/VAADIN directory in the shared model.Anyway it's certainly a fun time to be working with V7 in L7! Please sign in to reply. Reply as... Cancel Sampsa Sohlman David H Nebinger 8 Years Ago I think many of the addon's needs to be repackaged with OSGI manifest as developer have never heard of OSGi.I'm thinking different options for resource sharing. May be some kind of DS component model where you could plug in and serve newly compiled resources instead of default ones etc. .. I'm still thinking.So have you created already first version of your Vaadin control panel for Liferay 7? Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago So have you created already first version of your Vaadin control panel for Liferay 7?No, LR might be at a good milestone but the maven artifacts to build for L7 have been giving me fits... Please sign in to reply. Reply as... Cancel
Sampsa Sohlman David H Nebinger 8 Years Ago I think many of the addon's needs to be repackaged with OSGI manifest as developer have never heard of OSGi.I'm thinking different options for resource sharing. May be some kind of DS component model where you could plug in and serve newly compiled resources instead of default ones etc. .. I'm still thinking.So have you created already first version of your Vaadin control panel for Liferay 7? Please sign in to reply. Reply as... Cancel David H Nebinger Sampsa Sohlman 8 Years Ago So have you created already first version of your Vaadin control panel for Liferay 7?No, LR might be at a good milestone but the maven artifacts to build for L7 have been giving me fits... Please sign in to reply. Reply as... Cancel
David H Nebinger Sampsa Sohlman 8 Years Ago So have you created already first version of your Vaadin control panel for Liferay 7?No, LR might be at a good milestone but the maven artifacts to build for L7 have been giving me fits... Please sign in to reply. Reply as... Cancel
Alex Weirig 8 Years Ago Hi Sampsa,shouldn't the VaadinOsgiServlet actually be part of the Vaadin package? As far as I've seen, it's hard to do anything Vaadin+OSGi development without such a servlet handling the static content (theme, widgetset etc).One could possibly use the OSGi ConfigurationAdmin service to configure the servlet?What do you think?Alex Please sign in to reply. Reply as... Cancel
Tomasz Czerwonka 7 Years Ago Thanks for the OSGI examples on git hub!Is there a way for adding vaadin-spring and spring beans in OSGI modules. I've been looking for answers in the Internet but no results. It would be great to use @Service, @Component from Spring 4. Please sign in to reply. Reply as... Cancel Sampsa Sohlman Tomasz Czerwonka 7 Years Ago Hi, take a look newer version https://github.com/sammso/com.vaadin.liferay .. I just updated it couple days back Please sign in to reply. Reply as... Cancel Tomasz Czerwonka Sampsa Sohlman 7 Years Ago Thanks for quick reply... yes I've already seen your project on github I'am already using it. I've added as a quick solution to my portletInclude-Resource:\\ @vaadin-spring-${vaadin.spring.version}.jarI also create applicationContext.xml in my resource/WEB-INF directory.Then I've created HelloWorld component with @SpringComponent annotation and try to use it in MyPortletUI class.Portlet is installed correctly with message STARTED vaadin-sample-portlet_0.1.0 [525]But I think the Spring Context is not initialized correctly so I've received NPE on accessing component in my UI class. Please sign in to reply. Reply as... Cancel
Sampsa Sohlman Tomasz Czerwonka 7 Years Ago Hi, take a look newer version https://github.com/sammso/com.vaadin.liferay .. I just updated it couple days back Please sign in to reply. Reply as... Cancel Tomasz Czerwonka Sampsa Sohlman 7 Years Ago Thanks for quick reply... yes I've already seen your project on github I'am already using it. I've added as a quick solution to my portletInclude-Resource:\\ @vaadin-spring-${vaadin.spring.version}.jarI also create applicationContext.xml in my resource/WEB-INF directory.Then I've created HelloWorld component with @SpringComponent annotation and try to use it in MyPortletUI class.Portlet is installed correctly with message STARTED vaadin-sample-portlet_0.1.0 [525]But I think the Spring Context is not initialized correctly so I've received NPE on accessing component in my UI class. Please sign in to reply. Reply as... Cancel
Tomasz Czerwonka Sampsa Sohlman 7 Years Ago Thanks for quick reply... yes I've already seen your project on github I'am already using it. I've added as a quick solution to my portletInclude-Resource:\\ @vaadin-spring-${vaadin.spring.version}.jarI also create applicationContext.xml in my resource/WEB-INF directory.Then I've created HelloWorld component with @SpringComponent annotation and try to use it in MyPortletUI class.Portlet is installed correctly with message STARTED vaadin-sample-portlet_0.1.0 [525]But I think the Spring Context is not initialized correctly so I've received NPE on accessing component in my UI class. Please sign in to reply. Reply as... Cancel
David Zhang 6 Years Ago Hi Sampsa,Is Vaadin7 portlets are supported in DXP as WABs without any OSGi components?or it must use OSGI instead of portlet ? Please sign in to reply. Reply as... Cancel Alex Weirig David Zhang 6 Years Ago Hi David,with Vaadin 8 beta 1 writing OSGi portlets becomes extremely easy.All it takes is adding 2 Java annotations to your UI class.You can then use OSGi DS to have services injected into your portlet.Again this is Vaadin 8 not Vaadin 7.I don't know about WABs so I can't confirm ... but on the other hand are you sure you want to continue using WABs if all it takes is just deploying a tiny jar file?Alex Please sign in to reply. Reply as... Cancel
Alex Weirig David Zhang 6 Years Ago Hi David,with Vaadin 8 beta 1 writing OSGi portlets becomes extremely easy.All it takes is adding 2 Java annotations to your UI class.You can then use OSGi DS to have services injected into your portlet.Again this is Vaadin 8 not Vaadin 7.I don't know about WABs so I can't confirm ... but on the other hand are you sure you want to continue using WABs if all it takes is just deploying a tiny jar file?Alex Please sign in to reply. Reply as... Cancel
jose tomas 6 Years Ago Hello, I hope you are wellI followed his tutorial, however I got an error trying to display the portlet:17:35:10,672 ERROR [http-nio-8080-exec-6][PortletServlet:109] javax.portlet.PortletException: com.vaadin.server.ServiceException: com.vaadin.server.ServiceException: com.liferay.vaadin.poc.ui.PortletUI could not be loadedjavax.portlet.PortletException: com.vaadin.server.ServiceException: com.vaadin.server.ServiceException: com.liferay.vaadin.poc.ui.PortletUI could not be loaded at com.vaadin.server.VaadinPortlet.handleRequest(VaadinPortlet.java:551) at com.vaadin.server.VaadinPortlet.doDispatch(VaadinPortlet.java:619) at javax.portlet.GenericPortlet.render(GenericPortlet.java:262) at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:103) at com.liferay.portlet.ScriptDataPortletFilter.doFilter(ScriptDataPortletFilter.java:57) at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:100) at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64) at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:105) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.eclipse.equinox.http.servlet.internal.registration.EndpointRegistration.service(EndpointRegistration.java:153) at org.eclipse.equinox.http.servlet.internal.servlet.ResponseStateHandler.processRequest(ResponseStateHandler.java:62) at org.eclipse.equinox.http.servlet.internal.context.DispatchTargets.doDispatch(DispatchTargets.java:117) at org.eclipse.equinox.http.servlet.internal.servlet.RequestDispatcherAdaptor.include(RequestDispatcherAdaptor.java:48) at com.liferay.portlet.InvokerPortletImpl.invoke(InvokerPortletImpl.java:530) at com.liferay.portlet.InvokerPortletImpl.invokeRender(InvokerPortletImpl.java:605) at com.liferay.portlet.InvokerPortletImpl.render(InvokerPortletImpl.java:391) at com.liferay.portal.monitoring.internal.portlet.MonitoringInvokerPortlet.render(MonitoringInvokerPortlet.java:261) at org.apache.jsp.html.portal.render_005fportlet_jsp._jspService(render_005fportlet_jsp.java:1539) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at com.liferay.portal.servlet.DirectRequestDispatcher.include(DirectRequestDispatcher.java:64) at com.liferay.portal.servlet.ClassLoaderRequestDispatcherWrapper.doDispatch(ClassLoaderRequestDispatcherWrapper.java:78) at com.liferay.portal.servlet.ClassLoaderRequestDispatcherWrapper.include(ClassLoaderRequestDispatcherWrapper.java:53) at com.liferay.portlet.PortletContainerImpl._render(PortletContainerImpl.java:671) at com.liferay.portlet.PortletContainerImpl.render(PortletContainerImpl.java:145) at com.liferay.portlet.SecurityPortletContainerWrapper.render(SecurityPortletContainerWrapper.java:126) at com.liferay.portlet.RestrictPortletContainerWrapper.render(RestrictPortletContainerWrapper.java:126) at com.liferay.portal.kernel.portlet.PortletContainerUtil.render(PortletContainerUtil.java:155) at com.liferay.portal.layoutconfiguration.util.PortletRenderer._render(PortletRenderer.java:126) at com.liferay.portal.layoutconfiguration.util.PortletRenderer.render(PortletRenderer.java:73) at com.liferay.portal.layoutconfiguration.util.RuntimePageImpl.doProcessTemplate(RuntimePageImpl.java:444) at com.liferay.portal.layoutconfiguration.util.RuntimePageImpl.doDispatch(RuntimePageImpl.java:286) at com.liferay.portal.layoutconfiguration.util.RuntimePageImpl.processTemplate(RuntimePageImpl.java:113) at com.liferay.portal.layoutconfiguration.util.RuntimePageImpl.processTemplate(RuntimePageImpl.java:125) at com.liferay.portal.kernel.layoutconfiguration.util.RuntimePageUtil.processTemplate(RuntimePageUtil.java:70) at org.apache.jsp.html.portal.layout.view.portlet_jsp._jspService(portlet_jsp.java:747) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at com.liferay.portal.servlet.DirectRequestDispatcher.include(DirectRequestDispatcher.java:64) at com.liferay.portal.servlet.ClassLoaderRequestDispatcherWrapper.doDispatch(ClassLoaderRequestDispatcherWrapper.java:78) at com.liferay.portal.servlet.ClassLoaderRequestDispatcherWrapper.include(ClassLoaderRequestDispatcherWrapper.java:53) at com.liferay.portal.model.impl.LayoutTypeControllerImpl.includeLayoutContent(LayoutTypeControllerImpl.java:168) at com.liferay.portal.model.impl.LayoutImpl.includeLayoutContent(LayoutImpl.java:875) at com.liferay.portal.action.LayoutAction.processLayout(LayoutAction.java:339) at com.liferay.portal.action.LayoutAction.doExecute(LayoutAction.java:178) at com.liferay.portal.action.LayoutAction.execute(LayoutAction.java:75) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228) at com.liferay.portal.struts.PortalRequestProcessor.process(PortalRequestProcessor.java:170) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449) at javax.servlet.http.HttpServlet.service(HttpServlet.java:622) at com.liferay.portal.servlet.MainServlet.callParentService(MainServlet.java:603) at com.liferay.portal.servlet.MainServlet.service(MainServlet.java:580) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:119) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.monitoring.internal.servlet.filter.MonitoringFilter.processFilter(MonitoringFilter.java:180) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.uploadservletrequest.UploadServletRequestFilter.processFilter(UploadServletRequestFilter.java:93) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.secure.SecureFilter.processFilter(SecureFilter.java:310) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.jsoncontenttype.JSONContentTypeFilter.processFilter(JSONContentTypeFilter.java:42) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:99) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:720) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:466) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:391) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:318) at com.liferay.portal.servlet.FriendlyURLServlet.service(FriendlyURLServlet.java:169) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:119) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.monitoring.internal.servlet.filter.MonitoringFilter.processFilter(MonitoringFilter.java:180) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:188) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:96) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.uploadservletrequest.UploadServletRequestFilter.processFilter(UploadServletRequestFilter.java:93) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.strip.StripFilter.processFilter(StripFilter.java:338) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.gzip.GZipFilter.processFilter(GZipFilter.java:125) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.secure.SecureFilter.processFilter(SecureFilter.java:310) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.i18n.I18nFilter.processFilter(I18nFilter.java:338) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.jsoncontenttype.JSONContentTypeFilter.processFilter(JSONContentTypeFilter.java:42) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.autologin.AutoLoginFilter.processFilter(AutoLoginFilter.java:268) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.sharepoint.SharepointFilter.processFilter(SharepointFilter.java:88) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.BaseFilter.processFilter(BaseFilter.java:142) at com.liferay.portal.servlet.filters.virtualhost.VirtualHostFilter.processFilter(VirtualHostFilter.java:257) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:188) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:96) at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176) at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145) at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92) at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:394) at com.liferay.portal.servlet.filters.urlrewrite.UrlRewriteFilter.processFilter(UrlRewriteFilter.java:65) at com.liferay.portal.kernel.servlet.BaseFilter.doFilter(BaseFilter.java:48) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:207) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:112) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:168) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:96) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:168) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:96) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:188) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:96) at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:99) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745)Caused by: com.vaadin.server.ServiceException: com.vaadin.server.ServiceException: com.liferay.vaadin.poc.ui.PortletUI could not be loaded at com.vaadin.server.VaadinService.handleExceptionDuringRequest(VaadinService.java:1516) at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1476) at com.vaadin.server.VaadinPortlet.handleRequest(VaadinPortlet.java:548) ... 182 moreCaused by: com.vaadin.server.ServiceException: com.liferay.vaadin.poc.ui.PortletUI could not be loaded at com.vaadin.server.ServletPortletHelper.verifyUIClass(ServletPortletHelper.java:79) at com.vaadin.server.ServletPortletHelper.initDefaultUIProvider(ServletPortletHelper.java:159) at com.vaadin.server.VaadinService.createAndRegisterSession(VaadinService.java:821) at com.vaadin.server.VaadinService.doFindOrCreateVaadinSession(VaadinService.java:774) at com.vaadin.server.VaadinService.findOrCreateVaadinSession(VaadinService.java:714) at com.vaadin.server.VaadinService.findVaadinSession(VaadinService.java:572) at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1458) ... 183 moreCaused by: java.lang.ClassNotFoundException: com.liferay.vaadin.poc.ui.PortletUI at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at com.vaadin.server.ServletPortletHelper.verifyUIClass(ServletPortletHelper.java:71) ... 189 moreAm I doing something wrong? Could you please help me?regards. Please sign in to reply. Reply as... Cancel
Chris Börgermann 6 Years Ago Hi Sampsa,thanks for you efforts! Your compatibility pack works flawlessly with Vaadin 8.0.6.My only problem is, that I cannot inject my own OSGI Services. "Portal" works as expected. I implemented http://proliferay.com/writing-your-first-osgi-service-in-liferay-7/an can use this Service in my JSF Portlet using BundleContext bundleContext = FrameworkUtil.getBundle(javax.portlet.faces.GenericFacesPortlet.class).getBundleContext(); ServiceReference ref = bundleContext.getServiceReference(Calculator.class.getName()); _calculator = (Calculator)bundleContext.getService(ref);But if I try to inject my Calculator Service with @Reference or by using the FrameworkUtil, the Vaadin portlet does not start anymore. Do you (or anyone else reading this post) have any idea why?Best,Chris Please sign in to reply. Reply as... Cancel Ricardo Legorreta Chris Börgermann 5 Years Ago Hi Sampsa,Is has been a while we don't write. Thats because we have a great success using Vaadin 8.3 with Liferay DXP with no problem until today. In part thanks to you, so thanks a lot.Problem: we migrate some JavaScriptComponents like the d3Gauge.js with no problem. The problem is when we want to use ckeditor.js (bigger library with many .css and .js files). In the web app we don't have problems but in an OSGi we load the ckeditor.js file and in the browser console we receive an error 404 for the config.js file (even if it is included in th @JavaScript annotation). Of course the ckeditor component is not shown.I have tried many different approaches with no success for the last two days.Any idea what I´m doing wrong? Please sign in to reply. Reply as... Cancel
Ricardo Legorreta Chris Börgermann 5 Years Ago Hi Sampsa,Is has been a while we don't write. Thats because we have a great success using Vaadin 8.3 with Liferay DXP with no problem until today. In part thanks to you, so thanks a lot.Problem: we migrate some JavaScriptComponents like the d3Gauge.js with no problem. The problem is when we want to use ckeditor.js (bigger library with many .css and .js files). In the web app we don't have problems but in an OSGi we load the ckeditor.js file and in the browser console we receive an error 404 for the config.js file (even if it is included in th @JavaScript annotation). Of course the ckeditor component is not shown.I have tried many different approaches with no success for the last two days.Any idea what I´m doing wrong? Please sign in to reply. Reply as... Cancel