Using bndtools 2.0 and creating project as per latest Brindy Github version, Vaadin starts up and all works well when I create run bnd that pulls in dependencies based on felix http jetty and felix scr.
But if I try to run with org.eclipse.equinox.http.jetty etc. the servlet does not seem to be registered and vaadin fails to start.
When debugging into the code all of the ds component factory bits work OK but the servlet does not recognise the alias.
I am trying to get this to run before attempting to alter it for vaadin 7.
Any suggestions where the problem might be?
It is now working..I had not entered org.eclipse.equinox.cm as a dependency.
Using these bundles provided the working result, with just one problem.
org.apache.felix.webconsole resulted in error
2013-02-12 12:20:14.441:WARN:/:ERROR: org.apache.felix.webconsole.internal.servlet.OsgiManager: Failed to instantiate plugin org.apache.felix.webconsole.internal.deppack.DepPackServlet
Caused by:
java.lang.ClassNotFoundException: org.osgi.service.deploymentadmin.DeploymentException
id State Bundle
0 ACTIVE org.eclipse.osgi_3.7.2.v20120110-1415
1 ACTIVE com.vaadin_6.8.0
2 ACTIVE javax.servlet_3.0.0.v201112011016
3 ACTIVE org.eclipse.equinox.cm_1.0.400.v20120522-1841
4 ACTIVE org.eclipse.equinox.ds_1.4.0.v20120522-1841
5 ACTIVE org.eclipse.equinox.http.jetty_3.0.0.v20120522-1841
6 ACTIVE org.eclipse.equinox.http.servlet_1.1.300.v20120522-1841
7 ACTIVE org.eclipse.equinox.util_1.0.300.v20110502
8 ACTIVE org.eclipse.jetty.continuation_8.1.3.v20120522
9 ACTIVE org.eclipse.jetty.http_8.1.3.v20120522
10 ACTIVE org.eclipse.jetty.io_8.1.3.v20120522
11 ACTIVE org.eclipse.jetty.security_8.1.3.v20120522
12 ACTIVE org.eclipse.jetty.server_8.1.3.v20120522
13 ACTIVE org.eclipse.jetty.servlet_8.1.3.v20120522
14 ACTIVE org.eclipse.jetty.util_8.1.3.v20120522
15 ACTIVE org.eclipse.osgi.services_3.3.100.v20120522-1822
16 ACTIVE org.vaadin.osgi_0.0.0
17 ACTIVE org.vaadin.osgi.staticres_0.0.0
18 ACTIVE org.vaadin.guessit_0.0.0
19 ACTIVE org.vaadin.guessit-support_0.0.0
20 ACTIVE org.apache.felix.webconsole_3.1.8
Related
whenever I start up my integration tests (#SpringBootTest) and the application context is started, it also runs through the entire vaadin start up routine. this can take a few moments (~ 2 mins currently) until "Vaadin application has been deployed and started to the context path "/"." is displayed.
for some of my ITs I don't need vaadin, because I just test some other interfaces and I wonder if I can prevent vaadin to boot during selected tests?
You have to exclude the following auto configurations of Vaadin:
VaadinScopeConfig
SpringSecurityAutoConfiguration
SpringBootAutoConfiguration
All three are located at com.vaadin.flow.spring.
I'm trying to migrate web applications from JBoss to Spring Boot, but have some unexplained issue with VERY slow startup time.
Even simple application from Spring Boot guides - "Handling Form Submission" (packaged as a fat JAR, using Java 1.8) starts on some computers in 3 sec, but on others in 30 sec. and this is gets worse for bigger web apps (WAR-packaged with JSF, Hibernate, etc) - startup time is 13 sec vs 1500 sec (115 times more!).
Similar apps starts under JBoss or Liberty app servers starts fast everywhere.
Not sure if this is security settings, network, firewall or anti-virus tools.
Looking at the log file, it seems like application spends a lot of time on scanning JARs for TLD files and "reflection" scanning.
Strange, but this is not the issue for apps running in JBoss or Liberty - not sure if same scanning happens there.
As far as I understand, this is done per Servlet specs, but is there any way to skip scanning some JARs?
Where to add catalina.properties file in Spring Boot app, packaged as WAR, as suggested by the message?
Here are examples of log messages:
org.apache.jasper.servlet.TldScanner : No TLD files were found in [jar:file:/C:/Development/workspace-Cloud/PrimeFacesDemoSBwar/target/primefacesdemoSB.war!/WEB-INF/lib/primefaces-5.3.jar]. Consider adding the JAR to the tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in CATALINA_BASE/conf/catalina.properties file.
...
org.reflections.Reflections : Reflections took 79406 ms to scan 7 urls, producing 972 keys and 4573 values
I want to use glassfish 3.1.2.2 with OSGI for my development purposes. I installed OSGI Future pack over web administration console and restarted glassfish. After server restarting the web console stopped to work and shows me only a blank page without any errors. I looked in a log file and found there exception described bellow.
I had a number of questions:
How to replace start level of this bundle and which level it is necessary to set?
How to get access to Apache Felix's shell?
Whether it is possible to marry glassfish and karaf?
[org.glassfish.main.admingui.glassfish-osgi-console-plugin(Glassfish OSGI Console Plugin):3.1.2.1-SNAPSHOT]
com.sun.enterprise.module.ResolveError: Failed to start Bundle Id [263] State [RESOLVED] [org.glassfish.main.admingui.glassfish-osgi-console-plugin(Glassfish OSGI Console Plugin):3.1.2.1-SNAPSHOT]
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:177)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)
at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:124)
at com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:111)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:135)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at com.sun.enterprise.v3.server.ClassLoaderHierarchyImpl.createApplicationParentCL(ClassLoaderHierarchyImpl.java:200)
at org.glassfish.deployment.common.DeploymentContextImpl.createClassLoader(DeploymentContextImpl.java:216)
at org.glassfish.deployment.common.DeploymentContextImpl.createDeploymentClassLoader(DeploymentContextImpl.java:199)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:346)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:210)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:108)
Caused by: org.osgi.framework.BundleException: Cannot start bundle org.glassfish.main.admingui.glassfish-osgi-console-plugin [263] because its start level is 2, which is greater than the framework's start level of 1.
at org.apache.felix.framework.Felix.startBundle(Felix.java:1807)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:169)
... 12 more
This is a well known issue [1] and it has been fixed in GlassFish trunk. A work around is available for 3.1.x release as well.
[1] http://java.net/jira/browse/GLASSFISH-18880
I am using STS with tomcat 6 but I am not able to add tomcat 7. I have tried to remove all servers and add them again but still the problem persists. It says
cannot create a server of the selected type
What can be the cause?
we have a WAR packaged web application which works on a development machine. It consists of Java EE 5 + Seam 2.2.1 + Hibernate 3.3.1. It uses an Oracle 10g XE database and runs on the latest Tomcat 6 using JDK 1.6.0_24. The system is a 64bit Windows 7 Pro and uses Firefox 6.
Now, we tried to migrate the application to Oracle WebLogic 10.3.5. We followed the Seam manual for specifying the datasource, deploying the JSF lib and configuring the necessary xml-Files. In parallel to that, we verified that a newly seam-gen generated application using the same datasource and having the xml files configured as stated works fine.
But if we try our own application on WebLogic, allthough the deployment works fine, when trying to open the web application in the browser, it shows that endless redirection occured. We don't see any stacktrace or log error, even when configuring log4j in WebLogic. When analyzing the request with Firebug, we see the get request to "login.seam" and then 20 times a get request for "error.seam" (or "debug.seam when setting debug mode) with the response "302 Moved Temporarily".
I worked on that all week now, trying to compare all configurations and couldn't solve it - so I hope to get any ideas what could cause that problem and how to solve it!
I could pin down the problem to starting a transaction on the JTA persistence context.
I still don't understand why I didn't see any log message or stacktrace and why this also happens on the debug/error page (that's why the endless redirect occured).
I ended up using RESOURCE_LOCAL so far, but I'm not sure if this is the right thing to do.
The alternative is disabling the seam transaction setting, but then it didn't work together with the development build which still runs on Tomcat.