Java Slack API: use of jetty libraries - jetty

I'm following this Java example to post a message to a slack channel chat.postMessage/code. It uses these 3 lines referencing SlackAppServer:
import com.slack.api.bolt.jetty.SlackAppServer;
var server = new SlackAppServer(app);
server.start();
2 questions in regards to the use of SlackAppServer and com.slack.api.bolt.jetty:
Is the use SlackAppServer absolutely necessary for posting a message to a Slack channel using Java bolt libraries?
Library com.slack.api bolt-jetty makes use of the first 3 jetty libraries below that in turn rely on 3 more jetty libraries and on command "mvn spring-boot:run" produce the error below. Maven dependency tree doesn't show any overlapping libraries, but seems some type of incompatibility/conflict is taking place. Anyone else have seen this or similar errors?
jetty-servlet, jetty-server, jetty-webapp
jetty-alpn-server, http2-server, jetty-alpn-conscrypt-server
The errror:
Caused by: java.lang.IllegalAccessError: failed to access class org.eclipse.jetty.util.ArrayTernaryTrie from
class org.eclipse.jetty.http.PathMap (org.eclipse.jetty.util.ArrayTernaryTrie and org.eclipse.jetty.http.PathMap are in unnamed module of loader 'app')
at org.eclipse.jetty.http.PathMap.<init>(PathMap.java:96)
at org.eclipse.jetty.http.PathMap.<init>(PathMap.java:117)
at org.eclipse.jetty.http.PathMap.<init>(PathMap.java:107)
at org.eclipse.jetty.security.ConstraintSecurityHandler.<init>(ConstraintSecurityHandler.java:68)
... 25 more

Related

How to configure OpenTelemetry agent for an Akka application

I am trying to export metrics and traces from my Akka app written in Scala using OpenTelemetry agent with the purpose of consuming the data in OpenSearch.
Technology stack for my application:
Akka - 2.6.*
RabbitMQ (amqp client 5.12.*)
PostgreSQL (jdbc 42.2.*)
I've added OpenTelemetry instrumentation runtime dependency to build.sbt:
val runtimeDependencies: Seq[ModuleID] = Seq(
"io.opentelemetry.instrumentation" % "opentelemetry-instrumentation-api" % otelInstrumentationVersion % "runtime"
)
...
libraryDependencies ++= compileDependencies ++ testDependencies ++ runtimeDependencies,
I am passing OpenTelemetry configurations in a properties file:
export JAVA_OPTS="... \
-javaagent:lib/opentelemetry/opentelemetry-javaagent-all-v1.6.0.jar \
-Dotel.javaagent.configuration-file=lib/opentelemetry/otel.properties"
The only other related piece in my code is the properties file:
otel.service.name=my-app
otel.traces.exporter=jaeger
otel.propagators=jaeger
I do receive some traces in OpenSearch, but they are disparate and unrelated whereas I would expect them to be linked. For example a message is received on RabbitMQ topic, it makes it's way into an actor, the latter eventually issues a SQL query. As a result I could see for each execution how much time did each step take.
This is an approximate view that I get in OpenSearch:
I would love to be able to follow documentation, but I find that OpenTelemetry's configuration guide is scarce at this point.
Update:
Not sure whether this is relevant, but I get a warning on datapreper:
2021-09-29T16:50:50,861 [raw-pipeline-prepper-worker-5-thread-1] WARN com.amazon.dataprepper.plugins.prepper.oteltrace.OTelTraceRawPrepper - Missing trace group for SpanId: 922097e31cf96c72
Ok so I got around by running across this issue and then reading about how to surpress specific instrumentations.
So to reduce clutter in tracing dashboard, one would add something as following to the properties file (or equivalent via environment variables):
otel.instrumentation.rabbitmq.enabled=false
otel.instrumentation.grpc.enabled=false
Note that I removed the two cluttering instrumentation libraries peculiar for my use case. For another application one wold choose other libraries from link # 2 above. In this way the spans that you as application developer declare will become roots.

DryIoc with MediatR: IAsyncRequestHandler Resolve exception

DryIoc can't seem to Resolve a IAsyncRequestHandler.It throws"An exception of type 'DryIoc.ContainerException' occurred in DryIoc.dll but was not handled in user code Additional information: Unable to resolve MediatR.IRequestHandler.
Where no service registrations found
and number of Rules.FallbackContainers: 0
and number of Rules.UnknownServiceResolvers: 0"which is weird because it should be resolving a IAsyncRequestHandler.Another weird thing is that the code runs well on Net.Fiddle (check here)
I'm using VS 2015 Update 3 in Windows 10 Home, MediatR 3.0.0, DryIoc.dll 2.10.0, .Net framework 4.5 (also tried with 4.6.1).Am I registering it in a wrong way? This should be straightforward.Related: What is the best way to register all handlers?

Exception using weld CDI with Jetty: Singleton not set for STATIC_INSTANCE

I am trying to configure Jetty with JSF and Weld CDI. After following this manual, I stumble upon the following stacktrace:
Caused by: java.lang.IllegalStateException: Singleton not set for STATIC_INSTANCE => []
at org.jboss.weld.bootstrap.api.helpers.RegistrySingletonProvider$RegistrySingleton.get(RegistrySingletonProvider.java:28)
at org.jboss.weld.Container.instance(Container.java:55)
at org.jboss.weld.SimpleCDI.<init>(SimpleCDI.java:77)
at org.jboss.weld.environment.WeldProvider$EnvironmentCDI.<init>(WeldProvider.java:45)
at org.jboss.weld.environment.WeldProvider.getCDI(WeldProvider.java:61)
at javax.enterprise.inject.spi.CDI.current(CDI.java:60)
at org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:94)
at org.jboss.weld.servlet.api.helpers.ForwardingServletListener.contextInitialized(ForwardingServletListener.java:34)
at org.jboss.weld.environment.servlet.EnhancedListener.onStartup(EnhancedListener.java:65)
at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(ContainerInitializer.java:140)
at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:63)
... 50 more
Does someone see what is going wrong here?
This error appears if you forget the beans.xml file or, as in my case, you have put it in the wrong place. Your beans.xml can have only the root element but must exist.
For a Maven project remember that:
context.xml shoud stay in src/main/webapp/META-INF/
beans.xml should stay in src/main/resources/META-INF/
I had this problem when I moved an application developed using Glassfish (that doesn't need these files) to Tomcat 7.
The problem is that you're using both weld-servlet and weld-servlet-core in your pom. This is causing duplicate class entries as weld-servlet is an aggregate of weld-servlet-core. Removing the weld-servlet-core dependency fixed the singleton not set error.
Now, when I did that, I received errors about JSF but that may be other configuration issues.

Using Metro in place of Weblogic Webservices Stack

I am attempting to use Metro web services in place of the default Weblogic webservices stack contained in weblogic.jar.
The problem comes when trying to get WebLogic to use the metro stack before its own.
The steps I have taken so far is to reference the webservices-rt.jar in the project. So far I am getting this error while deploying the ear file....
Caused By: java.lang.LinkageError: loader constraint violation: when resolving field "DATETIME" the class loader (instance of weblogic/utils/classloaders/ChangeAwareClassLoader) of the referring class, javax/xml/datatype/DatatypeConstants, and the class loader (instance of ) for the field's resolved type, javax/xml/namespace/QName, have different Class objects for that type
UPDATES:
Most Recent Error is: "class javax.xml.namespace.QName has neither #WebSerivce nor #WebServiceProvider" Strange that it is looking for #Webservice on a QName object:
Contents of Application-Weblogic.xml
<wls:prefer-application-packages>
<wls:package-name>com.ctc.</wls:package-name>
<wls:package-name>com.sun.xml.</wls:package-name>
<wls:package-name>com.sun.istack.</wls:package-name>
<wls:package-name>com.sun.msv.datatype.</wls:package-name>
<wls:package-name>com.sun.msv.driver.</wls:package-name>
<wls:package-name>com.sun.msv.grammar.</wls:package-name>
<wls:package-name>com.sun.msv.reader.</wls:package-name>
<wls:package-name>com.sun.msv.relaxns.</wls:package-name>
<wls:package-name>com.sun.msv.scanner.</wls:package-name>
<wls:package-name>com.sun.msv.util.</wls:package-name>
<wls:package-name>com.sun.msv.verifier.</wls:package-name>
<wls:package-name>com.sun.msv.writer.</wls:package-name>
<wls:package-name>com.sun.org.apache.xml.internal.</wls:package-name>
<wls:package-name>com.sun.wsit.</wls:package-name>
<wls:package-name>javax.jws.</wls:package-name>
<wls:package-name>javax.xml.bind.</wls:package-name>
<wls:package-name>javax.xml.soap.</wls:package-name>
<wls:package-name>javax.xml.stream.</wls:package-name>
<wls:package-name>javax.xml.ws.</wls:package-name>
<wls:package-name>javax.xml.activation.</wls:package-name>
<wls:package-name>javax.xml.annotation.</wls:package-name>
<wls:package-name>javax.xml.mail.</wls:package-name>
<wls:package-name>javax.xml.security.</wls:package-name>
<wls:package-name>javax.xml.registry.</wls:package-name>
<wls:package-name>javax.xml.rpc.</wls:package-name>
<wls:package-name>javax.xml.crypto.</wls:package-name>
<wls:package-name>javanet.staxutils.</wls:package-name>
<wls:package-name>jp.gr.xml.</wls:package-name>
<wls:package-name>org.codehaus.stax2.</wls:package-name>
<wls:package-name>org.glassfish.gmbal.</wls:package-name>
<wls:package-name>org.iso_relax.</wls:package-name>
<wls:package-name>org.jcp.xml.dsig.</wls:package-name>
<wls:package-name>org.jvnet.</wls:package-name>
<wls:package-name>org.relaxng.</wls:package-name>
<wls:package-name>antlr.</wls:package-name>
<wls:package-name>org.apache.commons.lang.</wls:package-name>
</wls:prefer-application-packages>
Take a look at using the FilteringClassLoader which is configured in weblogic-application.xml deployment descriptor. You can instruct WebLogic to load classes from the application in favor of the libraries that are included with WebLogic. The descriptor element is and you specify the Java packages you want to load from the application.
If you are using WebLogic 10.3.4 you can use the ClassLoader Analysis to analyze the packages that are in conflict.
Check out my presentation here: SlideShare.net and my demo of the CAT here: YouTube

LinkageError: loader constraints violated when linking javax/xml/namespace/QName in Websphere6.1 using resteasy

I am getting this error when making a web services call. I couldn't figure out a workround for this. ANy help is greatly appreciated.
related library I have is:
axis-1.3.jar
axis-jaxrpc-1.3.jar
axis-saaj-1.3.jar
axis-wsdl4j-1.5.1.jar
jaxb-api-2.1.jar
jaxb-impl-2.1.8.jar
jaxen-1.1-beta-9.jar
jaxrs-api-1.0-beta-9.jar
In websphere 61 admin setting is the following:
Enterprise Application
-> WAR Classloader Mode : PARENT_LAST
* Web Module :
-> ClassLoader Mode : application_FIRST
Caused by: java.lang.LinkageError: loader constraints violated when linking javax/xml/namespace/QName class
at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.(RuntimeBuiltinLeafInfoImpl.java:224)
at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.(RuntimeTypeInfoSetImpl.java:61)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:127)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:79)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.(ModelBuilder.java:152)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.(RuntimeModelBuilder.java:87)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:432)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.(JAXBContextImpl.java:297)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:211)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:372)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at org.jboss.resteasy.plugins.providers.jaxb.JAXBContextWrapper.(JAXBContextWrapper.java:74)
at org.jboss.resteasy.plugins.providers.jaxb.JAXBContextWrapper.(JAXBContextWrapper.java:99)
at org.jboss.resteasy.plugins.providers.jaxb.XmlJAXBContextFinder.createContextObject(XmlJAXBContextFinder.java:48)
at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBContextFinder.createContext(AbstractJAXBContextFinder.java:114)
at org.jboss.resteasy.plugins.providers.jaxb.XmlJAXBContextFinder.findCachedContext(XmlJAXBContextFinder.java:39)
at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBProvider.findJAXBContext(AbstractJAXBProvider.java:49)
at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBProvider.getMarshaller(AbstractJAXBProvider.java:112)
at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBProvider.writeTo(AbstractJAXBProvider.java:88)
at org.jboss.resteasy.client.core.MessageBodyParameterMarshaller$ClientRequestEntity.(MessageBodyParameterMarshaller.java:88)
at org.jboss.resteasy.client.core.MessageBodyParameterMarshaller.buildRequest(MessageBodyParameterMarshaller.java:51)
at org.jboss.resteasy.client.core.ClientInvoker.invoke(ClientInvoker.java:197)
at org.jboss.resteasy.client.core.ClientProxy.invoke(ClientProxy.java:46)
at $Proxy51.updateAccount(Unknown Source)
at com.amg.brides.wedsimple.client.WedSimpleClientImpl.updateAccount(WedSimpleClientImpl.java:72)
at com.amg.brides.wedsimple.web.WedSimpleUpdateAccountEvent.invokeClient(WedSimpleUpdateAccountEvent.java:24)
at com.amg.brides.wedsimple.web.AbstractWedSimpleAccountEvent.execute(AbstractWedSimpleAccountEvent.java:35)
at com.amg.brides.util.WebEventProcessor.processEvents(WebEventProcessor.java:29)
The basic problem is that you're loading one or more class files related to xml from an incorrect jar. Your application server does not permit you to change these libraries, because it has already loaded most of the parser from a different implementation. I tried to inspect the content of the jar files looking for javax/xml/namespace but stopped halfway. If you find it there's a good chance you can get one without the offending classes. People have been known to manually remove such files from external jars.
You can probably turn on som vm options to log classloading while the container is running. This is the java -verbose:class option.
I'm sorry I cant pinpoint the exact problem ;)
Possible solution (worked for me)
In Websphere 7 I have the same problem with axis 1.3 and 1.4
I have resolved removing QName.class from axis-jaxrpc-1.3.jar in WEB_INF\lib
This because QName.class was already present in other jar file.