matchOnUriPrefix=true does not seem to be working - wildfly

I am using:
wildlfy 10.1.0 final
Camel 2.19.1
Camel Java DSL RouteBuilder
In my RouteBuilder.configure I have the following from:
from("undertow:http://localhost:" + portNum + "/DataplatformESB/v3?matchOnUriPrefix=true&httpMethodRestrict=post,get,put,options,patch,delete")
When I test to "localhost:8080/DataplatformESB/v3" with GET, PUT, or PATCH, they all work fine. But when I test to "localhost:8080/DataplatformESB/v3/anythingelse" I'll get a 404 (page not found) in return. In the Wildfly log it stats: "Matched prefix path /DataplatformESB for path /DataplatformESB/v3/anythingelse". So for me it looks like the "matchOnUriPrefix=true" is not working.
I have already tested with from("restlet:http://localhost:" + portNum + "/DataplatformESB/v3?matchOnUriPrefix=true&httpMethodRestrict=post,get,put,options,patch,delete"), but that does not work as well.
I have also tried it with the restConfiguration and .componentProperty("matchOnUriPrefix", "true") but also no luck.
Does anyone has an idea why the matchOnUriPrefix=true does not seem to work for me?

I have done some further research and found out the folliwing:
I got the undertow test project from https://github.com/apache/camel/tree/master/components/camel-undertow/src/test/java/org/apache/camel/component/undertow/UndertowPrefixMatchingTest.java and run/tested in it in my NetBeans.
The code is:
from("undertow:http://localhost:{{port}}/bar?matchOnUriPrefix=true")
.transform(bodyAs(String.class).append(" Matching prefix"))
.to("mock:bar");
This runs fine and returns OK when the URL starts with the prefix: "bar". So "bar/foo" returns OK as well.
But when I paste this code into the Wildfly Camel Rest Swagger example (there is no Wildfly Camel Rest example) from the website https://github.com/wildfly-extras/wildfly-camel-examples/tree/master/camel-rest-swagger, then I only get an OK when testing with "bar" as path.
Using "bar/foo" result in a 404 return code.
Im still using Wildfly 10.1 final and Camel 2.19.1.
So what is causing the difference in output? What do I have to change in Wildfly to get it working?
Is the option matchOnUriPrefix default disabled/ignored on Wildfly?

When using the Wildfly-Camel 2.18.3 on the Wildlfly installation it seems to work.
It looks like the default value for matchOnUriPrefix is changed or the handling of this property.
In that case it seems to me that this introduced the bug as described above.

Related

How to set SameSite LAX using JBOSS 7.4

We are currently using JBOSS 7.4 for functional testing. I've read on the documentation that undertow version is 2.2.5
and according to the undertow blog
that to configure the samesite cookie on a webapp, I have to added an undertow-handlers.conf file (located in the WEB-INF folder) which contains only the following line:
path(/)->samesite-cookie(mode=Lax)
but this is not working (I'll update with stacktrace later)
I tried different syntaxes but I still cannot start Jboss :
path(/)->samesite-cookie(mode=Lax, cookie-pattern=*) ---> PatternSyntaxException: Dangling meta character '*' near index 0
path(/)->samesite-cookie(mode="Lax", cookie-pattern="*") --->
Caused by: java.lang.IllegalArgumentException: UT000045: Error parsing predicated handler string no handler named samesite-cookie known handlers are [disallowed-methods, allowed-methods, buffer-request, jdbc-access-log, http-continue-accept, secure-cookie, access-log, mark-secure, response-rate-limit, canonical-path, response-code, disable-cache, ssl-headers, trace, blocking, url-decoding, error-file, access-control, redirect, set, ip-access-control, request-limit, resource, compress, restart, clear, byte-range, eager-form-parser, done, rewrite, forwarded, stuck-thread-detector, reverse-proxy, jvm-route, learning-push, dump-request, proxy-peer-address, resolve-local-name, header, store-response, path-separator, resolve-peer-name]:
path(/)->samesite-cookie(mode=\"Lax\", cookie-pattern=\"*\")
^"}}
Any help will be greatly appreciated as none of the above is working.
Thank you.

JMeter variable Encoding is not correct

I'm using Jmeter 5.3 on Windows 10. I'm facing with the following problem:
I set the HTTP request to content encoding: UTF-8. In the response I saw it as I wanted.
"name": "Győr, autóbusz-állomás",
I tried to extract the response with JSON Extractor, but my assertion is failed and in the debug sampler the extracted name look like:
origin.name=Gy�r, aut�busz-�llom�s
How could I extract the variable in UTF-8 to use it in my assertion?
Thank you in advice,
I had the same problem. It was resolved with setting in HTTP Request "UTF-8" value on field "Content encoding".
Without it in my request was "???" symbols.
I cannot reproduce your issue:
Double check file.encoding System property value using the Debug Sampler, you should have UTF-8
If you don't - try launching JMeter as:
jmeter -Dfile.encoding=UTF-8
if it helps - add file.encoding=UTF-8 line to system.properties file (lives in "bin" folder of your JMeter installation, JMeter restart will be required to pick the property up.
More information:
Guide to Character Encoding
Apache JMeter Properties Customization Guide
Try to resolve with:
Go to jmeter.properties file
Add property: sampleresult.default.encoding=UTF-8
Restart jmeter & enjoy
Good luck!

How can I find out what is causing a certain URL to be resolved to a synthetic resources?

On my Adobe CQ 5 (CQ 5.6) installation, for some reason, there's a URL (http://localhost:4503/services) that is getting resolved to a synthetic resource:
This is causing CQ to show the following page, rather than a 404 Page Not Found page:
What is causing this behavior?
You get Forbidden error not because of the strange type of the /services, but because you didn't add any extension (you'll get the same result requesting /content/geometrixx). Let's try to add some extension: .html doesn't really work, but .infinity.tidy.json results in interesting discovery:
{
"tagfilter": {
"sling:resourceType": "/services/tagfilter.servlet",
"servletClass": "com.adobe.cq.social.commons.impl.servlets.TagFilterServlet",
"sling:resourceSuperType": "sling/bundle/resource",
"servletName": "com.adobe.cq.social.commons.impl.servlets.TagFilterServlet"
},
"tagfilter.servlet": {
"sling:resourceType": "/services/tagfilter.servlet",
"servletClass": "com.adobe.cq.social.commons.impl.servlets.TagFilterServlet",
"sling:resourceSuperType": "sling/bundle/resource",
"servletName": "com.adobe.cq.social.commons.impl.servlets.TagFilterServlet"
},
...
It seems that /services is a virtual (or, well, synthetic) path, a parent for servlets. In fact, you can't bind servlet to any path, the most popular choice is /bin prefix, however /services is possible as well. You'll find a list of all such paths in Apache Sling Servlet/Script Resolver and Error Handler OSGi configuration.

Lift Mailer error: gnu.mail.handler.TextPlain cannot be cast to javax.activation.DataContentHandler

Using the following code:
sendMail(From(Props.get("email")), Subject("Test Email"), To("email#address"),
PlainMailBodyType("test email body"));
And in Boot.scala:
System.setProperty("mail.smtp.starttls.enable","false");
System.setProperty("mail.smtp.host", host)
System.setProperty("mail.smtp.auth", "true")
Mailer.authenticator = Full(new Authenticator {
override def getPasswordAuthentication = new PasswordAuthentication(user, password)
})
I get the following error:
2011-05-23 18:49:02,868 ERROR [pool-3-thread-4] n.l.u.MailerImpl [Logging.scala:239] Couldn't send mail
java.lang.ClassCastException: gnu.mail.handler.TextPlain cannot be cast to javax.activation.DataContentHandler
at javax.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:596) ~[activation-1.1.jar:1.1]
at javax.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:550) ~[activation-1.1.jar:1.1]
at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:611) ~[activation-1.1.jar:1.1]
at javax.activation.DataHandler.writeTo(DataHandler.java:315) ~[activation-1.1.jar:1.1]
at javax.mail.internet.MimeUtility.getEncoding(MimeUtility.java:261) ~[mail-1.4.1.jar:1.4.1]
at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1321) ~[mail-1.4.1.jar:1.4.1]
at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2074) ~[mail-1.4.1.jar:1.4.1]
at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2042) ~[mail-1.4.1.jar:1.4.1]
at javax.mail.Transport.send(Transport.java:117) ~[mail-1.4.1.jar:1.4.1]
at net.liftweb.util.MailerImpl$$anon$1$$anonfun$$init$$1.apply(Mailer.scala:176) ~[lift-util_2.8.1-2.3.jar:2.3]
This code works on one box and not on another. Any ideas?
Alternative solution if you want to use the Jetty package that comes with your Linux distro.
The problem only seems to occur with the GNU implementation of JavaMail. If you can use the Sun implementation instead, it works fine, or at least it did for me.
Adding Sun's javamail:
I took activation-1.1.jar and mail-1.4.1.jar that sbt had placed under the lib_managed/ folder of my Lift project, and placed them under /usr/share/jetty/lib/ on the server.
Removing GNU javamail:
Unfortunately, commenting out the gnumail.jar from /etc/jetty/start.config wasn't enough to get rid of gnumail. Jetty somehow still found the gnumail.jar and now mails just crashed in a different way. To get things to work smoothly I had to uninstall libgnumail-java and therefore also libjetty-extra which depends on it (I'm using Ubuntu). If you need libjetty-extra you'll need a different way to ensure Jetty won't see gnumail.jar.
Apparently it is an issue in versions of Jetty < 6.1.25.
http://olex.openlogic.com/packages/jetty/6.1.25 Something wrong with activation dependency.
Switching to the latest version of jetty (7.3) fixed it!

wsdl xmlns problems with NetBeans and wsimport

Our application provides a SOAP API. Our wsdl starting lines are something like
<wsdl:definitions name='ControlDServices' ... xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' ...
This usually works OK, but a customer complained that when they try to use our SOAP API in NetBeans with the wsdl we provide they got this error:
Web Service can not be created by JAXWS:wsimport utility.
Reason: invalid extension element: "soap:body" (in namespace "http://schemas.xmlsoap.org/wsdl/soap/")
This can be easily recreated by running:
wsimport -d . -extension -Xnocompile -keep -s . -verbose <our wsdl file>
wihch yield the error:
[ERROR] invalid extension element: "soap:body" (in namespace "http://schemas.xmlsoap.org/wsdl/soap/")
unknown location
Our support discovered that changing the xmlns:soap definition to use http://www.w3.org/2001/12/soap-envelope/ solves the problem, but this requires a change in our product, and also contradict most of the places I see on the web where a wsdl:definitions file is defined. Besides, that URI seems to belong to soap-envelop and not to wsdl, and is also for a specific date, and not a general URI.
Is there a way to solve the NetBeans / wsimport problem without changing our wsdl, e.g. by changing parameters? If no, and a change is needed, is it wise to change it to http://www.w3.org/2001/12/soap-envelope/, or should we use something else?
Thanks
splintor
It looks like they don't support SOAP 1.1, only SOAP 1.2.