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="")...
Related
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).
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>
We are migrating out project from java 6 to java 8, and as part of the migration we are upgrading weblogic server from 11g R1 to 12c R2.
There are some weblogic libraries missing in the new release, that our project seems to depend on. In particular, these libraries are
modules\com.oracle.ws.orawsdl_1.4.0.0.jar
modules\com.oracle.ws.http_client_1.4.0.0.jar
They are defined in the PRE_CLASSPATH variable on setDomainEnv.sh of the previous weblogic installation. I don't know what their purpose is and where they are used (is there some trick to track their usage in the project source?), and they can't be found with the new installation.
I tried to search them as such starting from the Oracle_home directory
find . -type f -iname "*orawsdl*"
./oracle_common/modules/com.oracle.webservices.orawsdl-api.jar
./oracle_common/plugins/maven/com/oracle/fmwshare/com.oracle.webservices.orawsdl-api/12.2.1/com.oracle.webservices.orawsdl-api-12.2.1.location
./oracle_common/plugins/maven/com/oracle/fmwshare/com.oracle.webservices.orawsdl-api/12.2.1/com.oracle.webservices.orawsdl-api-12.2.1.pom
./oracle_common/plugins/maven/com/oracle/fmwshare/oracle.webservices.orawsdl/12.2.1/oracle.webservices.orawsdl-12.2.1.pom
./oracle_common/plugins/maven/com/oracle/fmwshare/orawsdl/12.2.1/orawsdl-12.2.1.pom
./inventory/featuresets/resources/modules/orawsdl_12.2.1.2.0.jar
./inventory/featuresets/orawsdl_12.2.1.2.0.xml
./inventory/refcounts/featuresets/orawsdl_12.2.1.2.0.ref
./inventory/refcounts/components/oracle.webservices.orawsdl_12.2.1.2.0.ref
find . -type f -iname "*http_client*"
./oracle_common/http_client_12.jar
./oracle_common/modules/com.oracle.http_client.http_client.jar
./oracle_common/ccr/lib/http_client_12.jar
./oracle_common/ccr/lib/http_client_11116.jar
./oracle_common/plugins/maven/com/oracle/fmwshare/oracle.http_client/12.2.1/oracle.http_client-12.2.1.pom
./oracle_common/plugins/maven/com/oracle/fmwshare/com.oracle.http_client.http_client/12.2.1/com.oracle.http_client.http_client-12.2.1.pom
./oracle_common/plugins/maven/com/oracle/fmwshare/com.oracle.http_client.http_client/12.2.1/com.oracle.http_client.http_client-12.2.1.location
./oracle_common/http_client_11116.jar
./inventory/refcounts/components/oracle.http_client_12.2.1.2.0.ref
./oui/modules/http_client.jar
Nothing refers to the same package, but is some of these proper alternative?
Also, when I try to deploy to the new server installation, I get the following error.
java.lang.ClassNotFoundException: org.apache.commons.pool2.BasePooledObjectFactory
After dropping the apache commons-pool lib in weblogic classpath (Which was never needed in the previous installation), I get a different error
Unable to find policy: "usernamedigest.xml", please make sure to use dynamic wsdl when initializing the service stub
Important note
Deploy succeeds if I define metadata-complete=true to all web.xml files, but I'm sure this is not clever, as it may bypass some important configuration I'm not aware of. So how do I troubleshoot the cause of this problem?
I think it has something to do with how weblogic tries to take control of the web services it should not. In the project axis is used as the web service implementation. In the succeeded deployment (old weblogic, and new weblogic with metadata-complete=true set), only one web service is shown in under Web Services section of the deployment overview.
However, with the failed deployment (the userdigest.xml error) all web services are shown under this tab, as if weblogic tries to take control of them due to some annotation scanning, I guess.
Here is the error message from log file
<24.7.2017, 11:16:55,876 ap. EEST> <Error> <HTTP> <BEA-101216> <Servlet: "fi.sysopen.hekopassi.vrk.tv.TV_DATA2HekopassiImpl" failed to preload on startup in Web application: "/hekopassi".
javax.xml.ws.WebServiceException: Unable to find policy: "usernamedigest.xml", please make sure to use dynamic wsdl when initializing the service stub
at weblogic.wsee.jaxws.WLSTubelineAssemblerFactory$WLSTubelineAssemblerImpl.createServer(WLSTubelineAssemblerFactory.java:374)
at com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:193)
at weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory$WLSEndpointImpl.<init>(WLSContainer.java:774)
at weblogic.wsee.jaxws.WLSContainer$WLSEndpointFactory.create(WLSContainer.java:725)
at com.sun.xml.ws.server.EndpointFactory.create(EndpointFactory.java:332)
Truncated. see log file for complete stacktrace
Caused By: Unable to find policy: "usernamedigest.xml", please make sure to use dynamic wsdl when initializing the service stub
at weblogic.wsee.policy.runtime.PolicyServer.loadPolicy(PolicyServer.java:183)
at weblogic.wsee.policy.runtime.PolicyServer.getPolicy(PolicyServer.java:118)
at weblogic.wsee.policy.deployment.PolicyRef.getPolicy(PolicyRef.java:216)
at weblogic.wsee.policy.deployment.PolicyReferenceWsdlExtension.getEffectivePolicy(PolicyReferenceWsdlExtension.java:129)
at weblogic.wsee.policy.deployment.WsdlPolicySubject.getEffectivePolicyFromWsdlExtensible(WsdlPolicySubject.java:489)
Truncated. see log file for complete stacktrace
>
INFO [OpenFrame] FrontEnd logging service shutdown completed
INFO [OpenFrame] FrontEnd logging service shutdown completed
INFO [OpenFrame] BackEnd Log4 Logging service is going down!
INFO [OpenFrame] BackEnd Logging service shutdown completed
<24.7.2017, 11:17:01,540 ap. EEST> <Error> <Deployer> <BEA-149231> <Unable to set the activation state to true for the application "hekopassi".
weblogic.application.ModuleException: Unable to find policy: "usernamedigest.xml", please make sure to use dynamic wsdl when initializing the service stub
at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:140)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:233)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:228)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
Truncated. see log file for complete stacktrace
Caused By: Unable to find policy: "usernamedigest.xml", please make sure to use dynamic wsdl when initializing the service stub
at weblogic.wsee.policy.runtime.PolicyServer.loadPolicy(PolicyServer.java:183)
at weblogic.wsee.policy.runtime.PolicyServer.getPolicy(PolicyServer.java:118)
at weblogic.wsee.policy.deployment.PolicyRef.getPolicy(PolicyRef.java:216)
at weblogic.wsee.policy.deployment.PolicyReferenceWsdlExtension.getEffectivePolicy(PolicyReferenceWsdlExtension.java:129)
at weblogic.wsee.policy.deployment.WsdlPolicySubject.getEffectivePolicyFromWsdlExtensible(WsdlPolicySubject.java:489)
Truncated. see log file for complete 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
During development the REST service (Spring Boot 1.1.18) all seems to went fine, but as we executed different performance and load test the service stopped to response with following error:
org.apache.tomcat.util.net.NioEndpoint log -
java.lang.NoClassDefFoundError: org/apache/tomcat/util/ExceptionUtils
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:711) ~[tomcat-embed-core-7.0.55.jar!/:7.0.55]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1736) [tomcat-embed-core-7.0.55.jar!/:7.0.55]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1695) [tomcat-embed-core-7.0.55.jar!/:7.0.55]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_55]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-7.0.55.jar!/:7.0.55]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_55]
The tests covers this workflow:
1) login
2) get information from database
3) parse information from a file (resided on the service host)
step 2) and 3) are repeated 2000 times with 5 running threads
The service didn't crash totally, it is still reachable via JMX, but doesn't respond on HTTP - requests.
I'm searching for a reason, but with no luck.
UPDATE:
I added JAVA_OPTS for heap, stack tuning and permanent generation size and now the service is stable and performs much better.
-Xmx768m -Xms512m -Xss4m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:MaxPermSize=128m -XX:PermSize=128m
That's great, but why?
UPDATE:
Nothing help's, the error still remains, also with Sprint Boot 1.2.0
have you ever run "gradle clean" or "mvn clean" in the source code directory, which could remove the fat jar generated by spring boot, it should be the root cause for the exception. Since the running jvm cannot find the class file which is removed.
If you repackage the fat spring-boot JAR file, the positions of beginnings of subjars change. It happens when you change something in properties file/xml in your fat-jar. You do it when you edit sometething in the configuration file with mc (mcedit) application. Put your configuration files outside the fat jar.