I get the error below when I startup Karaf. A colleague of mine has the exact same features, bundles, etc. but does not get the error. We both use Windows 10 and Karaf 4.0.7.
If fact he just compressed his Karaf folder and gave it to me. So our Karaf installations are identical. Now I am trying to get it working on my machine.
So how could it not work on my local machine?
I don't know Karaf well, so I have no idea how to troubleshoot further. What could be the reason?
Could it be that some jar file in my local Maven repo is missing
(which my co-worker has but I don't have)? I heard this is where Karaf is looking for some components.
data-access (2381)
------------------
Status: Failure
Blueprint
10/15/19 4:51 PM
Exception:
null
java.util.concurrent.TimeoutException
at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:371)
at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Missing dependencies:
(&(osgi.unit.name=ybkDS)(objectClass=javax.persistence.EntityManager)) (&(osgi.unit.name=ybDS)(objectClass=javax.persistence.EntityManagerFactory))
In fact when I startup Karaf I first get this for a few mins and then I get the error I posted above.
karaf#root()> bundle:diag
Bundle 53
---------
Status: Installed
Unsatisfied Requirements:
data-access (2384)
------------------
Status: GracePeriod
Blueprint
10/15/19 6:36 PM
Missing dependencies:
(&(osgi.unit.name=ybDS)(objectClass=javax.persistence.EntityManagerFactory)) (&(osgi.unit.name=ybkDS)(objectClass=javax.persistence.EntityManager))
website-performance (2385)
--------------------------
Status: GracePeriod
Blueprint
10/15/19 6:36 PM
Missing dependencies:
(&(osgi.unit.name=ybDS)(objectClass=javax.persistence.EntityManagerFactory)) (&(osgi.unit.name=ybkDS)(objectClass=javax.persistence.EntityManager))
What is it looking for that I don't have?
You have a dependency to OSGi services for EntityManager and EntityManagerFactory both with property osgi.unit.name=ybkDS. These services are not coming up. You can first observe this in diag. After 5 minutes the blueprint container gives up to wait for these services and logs an error.
So you have to debug why these services are not coming up. Can you provide more information on how you instantiate the EntityManager?
I guess you are using Apache Aries JPA and maybe ops4j pax-jdbc.
In this case you to check that the DataSource comes up (should also be an OSGi service) and that you have installed the correct jpa impl (like hibernate).
It would also help if you could upload the log (especially everything from aries and pax-jdbc).
Related
i'm currently upgrading from Wildfly 20 to Wildfly 26. The standalone.xml doesn't start, because of an Injection of MetricRegistry and the newly missing microprofile.metrics-smallrye-extension (already described under: MicroProfile Metrics do not show custom metrics on Wildfly 25).
But if i start the standalone-microprofile.xml or add the extensions (see CLI-commands below), i ran into the same error.
Maybe the Keycloak-Integration-Workaround is conflicting. The Wildfly-internal OIDC adapter is actualy not working in bearer-only-mode. So i installed the current keycloak-client (keycloak-oidc-wildfly-adapter-16.1.1) an the workaround (see as last code-template).
2022-02-21 12:44:09,176 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."xyz.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."xyz.war".WeldStartService: Failed to start service
at org.jboss.msc#1.4.13.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
at org.jboss.msc#1.4.13.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads#2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads#2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.jboss.weld.exceptions.DeploymentException: SRMET00013: Description is different from the description in previous usage
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:38)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:510)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:93)
at org.jboss.as.weld#26.0.1.Final//org.jboss.as.weld.WeldStartService.start(WeldStartService.java:98)
at org.jboss.msc#1.4.13.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc#1.4.13.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
... 6 more
Caused by: java.lang.IllegalStateException: SRMET00013: Description is different from the description in previous usage
at io.smallrye.metrics//io.smallrye.metrics.MetricsRegistryImpl.verifyMetadataEquality(MetricsRegistryImpl.java:188)
at io.smallrye.metrics//io.smallrye.metrics.MetricsRegistryImpl.get(MetricsRegistryImpl.java:459)
at io.smallrye.metrics//io.smallrye.metrics.MetricsRegistryImpl.get(MetricsRegistryImpl.java:402)
at io.smallrye.metrics//io.smallrye.metrics.MetricsRegistryImpl.timer(MetricsRegistryImpl.java:371)
at io.smallrye.metrics//io.smallrye.metrics.setup.MetricsMetadata.registerMetrics(MetricsMetadata.java:111)
at io.smallrye.metrics//io.smallrye.metrics.setup.MetricCdiInjectionExtension.registerMetrics(MetricCdiInjectionExtension.java:186)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.injection.MethodInvocationStrategy$SpecialParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:187)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:123)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
at javax.enterprise.api//javax.enterprise.inject.spi.ObserverMethod.notify(ObserverMethod.java:124)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.util.Observers.notify(Observers.java:166)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:285)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
at org.jboss.weld.core#3.1.8.Final//org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35)
CLI-Commands to extend the standalone.xml
wildfly/bin/jboss-cli.sh -c "/extension=org.wildfly.extension.microprofile.metrics-smallrye:add()"
wildfly/bin/jboss-cli.sh -c "/subsystem=microprofile-metrics-smallrye:add()"
wildfly/bin/jboss-cli.sh -c "/extension=org.wildfly.extension.microprofile.fault-tolerance-smallrye:add()"
wildfly/bin/jboss-cli.sh -c "/subsystem=microprofile-fault-tolerance-smallrye:add()"
OIDC-Workaround (installation of keycloak client)
embed-server --server-config=${server.config:standalone.xml}
batch
/subsystem=undertow/application-security-domain=other:undefine-attribute(name=security-domain)
/subsystem=undertow/application-security-domain=other:write-attribute(name=http-authentication-factory,value=keycloak-http-authentication)
run-batch
/subsystem=ejb3/application-security-domain=other:write-attribute(name=security-domain,value=KeycloakDomain)
reload
Oh i spend a couple of hours to get rid of this problem.. but only minutes after writing this post, i found the "bad guy".
The Microprofile Version 3.3 (on Wildfly 20) ignored annotations (like #Timed) at interface-methods. The new Version 4.1 (Wildfly 26) regards them..
pretty easy, afterwards :)
marginal note:
If you have more than one WAR deployed on your Wildfly and one of them is using the public API of an other one, then you'll run into problems with hot-deployments.
I assume, in my case it occurs because i have placed the Timed-annotation at the implementation-class and not at the interface, that is used as ResteasyClient-proxy. Every time i deploy the depending WAR after the rest-api-defining WAR, i got an exception: no metric mapped.
A redeployment of the rest-api-defining WAR fixes this issue :)
The /metrics endpoint is queried using an anonymous user usually(prometheus scraper), this means you may have to enable the MONITOR role to include all. That way the anonymous access to /metrics will be able to read the additional thread data.
^^The security impact of this config I'm not sure of.
in my case was that I had duplicated the name with other method in #Timed(name="")...
we have a Kafka Connect project where we rely on a library which fetches data from gitlab. This library depends on Jersey. Kafka also uses Jersey. When starting our connector, we receive a class cast error that appears to be caused by jersey having some kind of global discovery pattern that clashes when both server and client are in the same classpath.
org.gitlab4j.api.GitLabApiException: org.glassfish.jersey.server.wadl.internal.WadlAutoDiscoverable cannot be cast to org.glassfish.jersey.internal.spi.AutoDiscoverable
at org.gitlab4j.api.AbstractApi.handle(AbstractApi.java:615)
at org.gitlab4j.api.AbstractApi.get(AbstractApi.java:193)
at poc.connector.gitlab.api.ExtendedIssuesApi.getIssues(GitlabExtendedApi.scala:34)
at poc.connector.gitlab.GitLabSourceTask.poll(GitLabSourceTask.scala:49)
at org.apache.kafka.connect.runtime.WorkerSourceTask.poll(WorkerSourceTask.java:244)
at org.apache.kafka.connect.runtime.WorkerSourceTask.execute(WorkerSourceTask.java:220)
at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:175)
at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:219)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassCastException: org.glassfish.jersey.server.wadl.internal.WadlAutoDiscoverable cannot be cast to org.glassfish.jersey.internal.spi.AutoDiscoverable
at java.util.TreeMap.compare(TreeMap.java:1295)
at java.util.TreeMap.put(TreeMap.java:538)
at java.util.TreeSet.add(TreeSet.java:255)
at java.util.AbstractCollection.addAll(AbstractCollection.java:344)
at java.util.TreeSet.addAll(TreeSet.java:312)
at org.glassfish.jersey.model.internal.CommonConfig.configureAutoDiscoverableProviders(CommonConfig.java:599)
at org.glassfish.jersey.client.ClientConfig$State.configureAutoDiscoverableProviders(ClientConfig.java:403)
at org.glassfish.jersey.client.ClientConfig$State.initRuntime(ClientConfig.java:450)
at org.glassfish.jersey.internal.util.collection.Values$LazyValueImpl.get(Values.java:341)
at org.glassfish.jersey.client.ClientConfig.getRuntime(ClientConfig.java:826)
at org.glassfish.jersey.client.ClientRequest.getConfiguration(ClientRequest.java:285)
at org.glassfish.jersey.client.JerseyInvocation.validateHttpMethodAndEntity(JerseyInvocation.java:143)
at org.glassfish.jersey.client.JerseyInvocation.<init>(JerseyInvocation.java:112)
at org.glassfish.jersey.client.JerseyInvocation.<init>(JerseyInvocation.java:108)
at org.glassfish.jersey.client.JerseyInvocation.<init>(JerseyInvocation.java:99)
at org.glassfish.jersey.client.JerseyInvocation$Builder.method(JerseyInvocation.java:419)
at org.glassfish.jersey.client.JerseyInvocation$Builder.get(JerseyInvocation.java:319)
at org.gitlab4j.api.GitLabApiClient.get(GitLabApiClient.java:382)
at org.gitlab4j.api.GitLabApiClient.get(GitLabApiClient.java:370)
at org.gitlab4j.api.AbstractApi.get(AbstractApi.java:191)
... 11 more
$ #inside of the plugin path of kafka connect:
$ find ./ | grep jersey | grep server Di 26 Feb 2019 15:46:41 CET
./schema-registry/jersey-server-2.27.jar
./confluent-kafka-mqtt/jersey-server-2.27.jar
./kafka/jersey-server-2.27.jar
./rest-utils/jersey-server-2.27.jar
How would we go about configuring our code to avoid the issue that somewhere in the process of our connect application, the wrong class is used? Or how do we avoid the cast error in the context of AutoDiscoverable implementations?
We had a similar issue in one of our Kafka Connect connectors, which we solved by shading org.glassfish in our connector.
We package our connector as a "uber JAR" and place it in a path configured using the plugin.path setting.
See also the Confluent docs for Kafka Connect about this topic. There it is stated that
... a plugin should never contain any libraries that are provided by Kafka Connect's runtime.
We chose to shade instead, you might also be able to solve this by not packaging Jersey in your connector.
I just add exactly the same issue. Developing a kafka source connector for gitlab using gitlab4j.
I fixed it by adding the following dependencies to exclude section of assemby and shade plugins:
<exclude>org.glassfish.jersey.inject</exclude>
<exclude>org.glassfish.jersey.core</exclude>
<exclude>org.glassfish.jersey.connectors</exclude>
I was able to develop two applications (One application used Hibernate and other application used CXF web service followed by this tutorial) separately and deploy to the FUSE 6.3.0 with out any issue.
But my problem arises when I try to install hibernate in FUSE where FUSE has already installed CXF application which I developed. I try to execute following command to install hibernate.
fabric:profile-edit --bundle mvn:org.hibernate/hibernate-core/4.2.22.Final-redhat-1 jboss-fuse-full
If I do not have CXF application installed in the FUSE then no exception thrown from FUSE but when I have CXF application deployed in FUSE it gives following exception.
Exception in thread "SpringOsgiExtenderThread-2" org.apache.camel.RuntimeCamelException: org.apache.camel.FailedToCreateRouteException: Failed to create route cxf: Route(cxf)[[From[cxf:bean:serviceEndpoint]] -> [RecipientLis... because of Failed to resolve endpoint: cxf://bean:serviceEndpoint due to: No component found with scheme: cxf
at org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1690)
at org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:138)
at org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:340)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:96)
at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:334)
at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:954)
at org.springframework.osgi.context.support.AbstractOsgiBundleApplicationContext.finishRefresh(AbstractOsgiBundleApplicationContext.java:235)
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:358)
at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320)
at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:132)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.camel.FailedToCreateRouteException: Failed to create route cxf: Route(cxf)[[From[cxf:bean:serviceEndpoint]] -> [RecipientLis... because of Failed to resolve endpoint: cxf://bean:serviceEndpoint due to: No component found with scheme: cxf
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:201)
at org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:974)
at org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:3301)
at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3024)
at org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:175)
at org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2854)
at org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2850)
at org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2873)
at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2850)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2819)
at org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:275)
at org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:136)
... 10 more
Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: cxf://bean:serviceEndpoint due to: No component found with scheme: cxf
at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:594)
at org.apache.camel.util.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:79)
at org.apache.camel.model.RouteDefinition.resolveEndpoint(RouteDefinition.java:211)
at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:107)
at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:113)
at org.apache.camel.model.FromDefinition.resolveEndpoint(FromDefinition.java:69)
at org.apache.camel.impl.DefaultRouteContext.getEndpoint(DefaultRouteContext.java:89)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1052)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:196)
... 22 more
Does any one experienced this kind of issue before and able to resolve it. Please be kind enough to share your experience to resolve this issue.
I also had same kind of issue when I try to install CXF with ActiveMQ.I was able to resolve it by uninstalling the already installed CXF project and then install the ActiveMQ.
Make sure that you have installed the required dependencies for the Hibernate correctly. After verifying that you have installed required dependencies you can reinstall application/
So in your case, you can first uninstall CXF project first and then install Hibernate(Note that you may required to install all the dependencies required).Then retry to install the CXF project.
You can use following command to uninstall existing project
uninstall <processID> eg-: uninstall 418
I’d just downloaded latest Liferay 7 Tomcat bundle
liferay-ce-portal-tomcat-7.0-ga3-20160804222206210
Extracted it and stared from liferay-ce-portal-7.0-ga3\tomcat-8.0.32\bin\startup.bat. Server started successfully and first screen opened on browser. Then I provided basic configurations and database (MySQL Server 5.6) details etc. and re-stared server as instructed. But now whenever I’m starting the server, throwing following exception and server is not starting. Can anyone help me to identify the issue please?
10:23:40,085 INFO [localhost-startStop-1][BaseDB:501] Database does not support case sensitive queries
You must first upgrade to Liferay Portal 7002
10:23:40,097 ERROR [localhost-startStop-1][MainServlet:237] java.lang.RuntimeException: You must first upgrade to Liferay Portal 7002
java.lang.RuntimeException: You must first upgrade to Liferay Portal 7002
at com.liferay.portal.tools.DBUpgrader.checkRequiredBuildNumber(DBUpgrader.java:86)
at com.liferay.portal.events.StartupAction.doRun(StartupAction.java:190)
at com.liferay.portal.events.StartupAction.run(StartupAction.java:85)
at com.liferay.portal.servlet.MainServlet.processStartupEvents(MainServlet.java:1290)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:234)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1238)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1151)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1038)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4997)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5289)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:585)
at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1794)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Stopping the server due to unexpected startup errors
You seem to have pointed Liferay to a database with existing data. In that case you'll have to run the upgrade routines before starting Liferay. This is a separate tool starting with version 7.0 - it used to be bundled within the server in prior versions. The documentation should contain all required information.
Answering your comment: The line
10:23:40,097 ERROR [localhost-startStop-1][MainServlet:237] java.lang.RuntimeException:
You must first upgrade to Liferay Portal 7002
clearly indicates that Liferay found the tables and data structure from a previous version in the database that you're pointing to. Note that a portal-ext.properties file will also be picked up if it's in the current user's home directory - that might override the settings that you expect to set in the installation's private portal-ext.properties or portal-setup-wizard.properties.
In addition, I do recommend to explicitly use a mysql-driver version matching your mysql-server version. Otherwise Liferay will download a driver from the maven repositories and it might not match 100%. I've seen problems arise from that.
10:23:40,085 INFO [localhost-startStop-1][BaseDB:501] Database does not support case sensitive queries You must first upgrade to Liferay Portal 7002
Did you tried this previous advise from your stacktrace ?
I am installing solr on WAS 8.5.5 with IBM jdk 7.
I deployed the solr as a war and added solr.data.dir and solr.solr.home to custom properties.
Upon accessing the url: http://localhost:9080/solr,
I see the below error on the browser:
Error 500: javax.servlet.ServletException: Filter [SolrRequestFilter]: org.apache.solr.servlet.SolrDispatchFilter was found, but is missing another required class
And the following error in the logs:
SRVE0293E: [Servlet Error]-[com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor]: java.lang.NoClassDefFoundError: org.apache.solr.servlet.SolrDispatchFilter (initialization failure) at java.lang.J9VMInternals.initialize(J9VMInternals.java:176) at java.lang.J9VMInternals.newInstanceImpl(Native Method) at java.lang.Class.newInstance(Class.java:1600) at java.beans.Beans.instantiate(Beans.java:241) at java.beans.Beans.instantiate(Beans.java:89) at com.ibm.ws.webcontainer.filter.WebAppFilterManager._loadFilter(WebAppFilterManager.java:533) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.loadFilter(WebAppFilterManager.java:475) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterInstanceWrapper(WebAppFilterManager.java:308) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterChain(WebAppFilterManager.java:380) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:892) at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1025).....
The lib folder of WEB-INF do contain the solr dependencies
Any Help from anybody ?
After scratching my head for 48 hours, finally able to make SOLR up and running on WebSphere.
Looks like the whole fundamental is to understand the class loading strategy on WAS8, and hence choosing the right strategy.
Have enumerated the different steps for solr deployment on WAS 8
Solr Deployment on WebSphere 8.5.5