I have a simple Camel Route which processes the incoming Http request and then routes to other Http consumers based on the Resource path. Everything works fine but I hit the java.net.URISyntaxException: Illegal character in path when used a space in the path.
Other special characters seem to work fine.
I am building a RESTful APIs and currently using the browser to test my APIs.
Here is the Spring DSL of my route:
<route id="API">
<from uri="jetty:http://0.0.0.0/api?matchOnUriPrefix=true"/>
<bean ref="basicAuthBean"/>
<choice>
<when>
<simple>${in.header.CamelHttpPath} contains 'blah1'</simple>
<to uri="http://localhost:10001/api?bridgeEndpoint=true&throwExceptionOnFailure=false"/>
</when>
<when>
<simple>${in.header.CamelHttpPath} contains 'blah2'</simple>
<to uri="http://localhost:10002/api?bridgeEndpoint=true&throwExceptionOnFailure=false"/>
</when>
</choice>
</route>
I enabled trace on the Camel Context and found that the CamelHttpPath had already replaced the escape character "%20" with a space. I also saw that there was CamelHttpUri which had not escaped the special character.
As a hack in my Spring DSL I added the following before the choice element:
<setHeader headerName="CamelHttpPath">
<simple>${in.header.CamelHttpUri}</simple>
</setHeader>
This solved my problem but I am pretty sure there is a better way to do this. Did I miss setting some properties or is my route DSL not accurate?
Also, what is the difference between the CamelHttpPath and CamelHttpUri?
I should also mention that I am using the Camel Context in Apache ServiceMix 4.4.2 and the Camel Version used is 2.8.5.
Thanks in advance for the help!
I think we have fixed this in later Camel releases due to be released like Camel 2.10.4 etc. I remember working on that space fix.
https://issues.apache.org/jira/browse/CAMEL-5504
As Camel 2.8.x is no longer supported you would need to patch the issue yourself.
Or upgrade to ServiceMix 4.5.0 which includes Camel 2.10.3.
Related
Default action is defined as below in struts.xml.
Fortify scan complains about "*" matching saying -
"Using wildcards (*) in Struts 2 action names allows evaluation of action names as OGNL expressions effectively allowing an attacker to modify system variables like Session or execute arbitrary commands on the server."
<action name="*" class="XXXX.XXXXX.XXXX.GenericAction">
<result>{1}.jsp</result>
<interceptor-ref name="defaultStacki18n" />
</action>
How to resolve this issue?
This was resolved in Struts 2.3.14.3 (see https://struts.apache.org/docs/s2-015.html).
The solution is to upgrade and fix your whitelisting.
Slightly related: pasting that into Google returned this on the first page of results; sometimes just searching the web will answer your questions.
Does anyone know what the "strict" parameter does when injecting a service in Symfony ?
For example:
<service ...>
<argument type="service" id="whatever" strict=false />
</service>
Thank you!
I did some research and it's a leftover from Symfony 2.8 as this comment suggests:
Note: The $strict parameter is deprecated since version 2.8 and will be removed in 3.0.
Since 3.0 the parameter doesn't exist as well as the deprecation warning but classes YamlFileLoader and XmlFileLoader still read it even though the Reference class takes only two arguments.
So, this parameter does nothing :).
I need to allow deployers to specify the path for our Tomcat webapp log4j2 RollingFileLogger. I'd like to use JNDI but can use a plain -D param if I had to. This apache page seems to explain things pretty well.
Only problem is it doesn't work. I will admit to not being particularly experienced in JNDI, but I can't even get a simple JVM param to work. Reading about Property Substitution I got the impression I cannot just put the $${jndi:xxxx} in the filename attribute and that I should use a ${xxx} Property substitution instead. Unfortunately while that property substituion works fine no lookup jndi or env ever resolves.
log4j2.xml:
<Properties>
<Property name="filename">$${jndi:logPath/directory}/ief.log</Property>
</Properties>
....
<RollingFile name="RollingFileLogger" fileName="${filename}" immediateFlush="false" append="true"
Result:
2014-09-16 14:44:46,284 ERROR Unable to create file ${jndi:logPath/directory}/ief.log java.io.IOException: The filename, directory name, or volume label syntax is incorrect
As you can see the property is substituted but the lookup is not done. I am unsure what the context.xml entry should look like. But my best guess is:
<Resource name="logPath"
auth="Container"
directory="/tmp" />
I am using log4j version 2.0 but am fairly certain this is my misunderstanding not a bug. Any help clearing up what I'm doing wrong would be greatly appreciated.
I never found a JNDI browser that would work in Tomcat 7. But it did turn out to be a stupid problem. I defined this as a RESOURCE instead of an ENVIRONMENT. Just for the record the context.xml should look like:
<Environment name="logPath"
auth="Container"
type="java.lang.String"
value="/tmp" />
And log4j2 lookup is then:
<Property name="logName">$${jndi:logPath}/iefrest.log</Property>
<Property name="patternName">$${jndi:logPath}/iefrest</Property>
...
<RollingFile name="RollingFileLogger" fileName="${logName}" immediateFlush="false" append="true"
filePattern="${patternName}-%d{yyyyMMdd-HH}.log.gz">
It is worth noting that the "java:comp/env" (which is clearly documented but misleading to people that don't have a deep knowledge of JNDI - like me) actually maps to the Environment XML element and does not imply a prefix to the name attribute.
From a Log4J2 prespective it is also interesting that the filename attribute is taken EXACTLY as provided. Specifically you cannot say filename="${logName}.log". This will not parse into the desired results. However expected concatenation DOES take place on the filepattern attribute. Inconsistent but not unmanageable.
If you specify $${jndi:logPath/directory}, the lookup will add the prefix java:comp/env/, so the full value that it will look up is java:comp/env/logPath/directory. (This prefix is not added if your jndi lookup key already contains a ':' character.) Perhaps you can use a JNDI browser to see if this gives you the expected value.
Any errors that occur during this lookup will be logged to the status logger at WARN level. Status logs appear in the console. You can enable status logs by specifying <Configuration status="trace" ... in your log4j2.xml configuration file.
I'm using the text parameter to get multi line parameters, and write them to file.
If I use the rebuild, the text parameter is loaded as a single line string (where newline is removed).
Does anyone have an idea on how to fix this? I guess the rebuild plugin is the problem...
The multi-line text parameter seems to be rather buggy. One workaround you may consider is to substitute newlines with some custom escape system and then convert the escape sequences back to newlines inside your build.
A more advanced solution would be to modify the plugin itself to convert the escape sequences into newlines and use that modified plugin in your Jenkins. I've done that sort of thing for Claim Plugin to display failed matrix jobs which it did not do on its own. If you decide to take this route I can walk you through the main steps.
I have just enhanced the plugin to add TextParameterValue.jelly
That works fine, since text and textarea are not that different except new lines just use StringParameterValue.jelly as template and use <f:textarea name="value" value="${it.value}" /> instead of <f:textbox name="value" value="${it.value}" />
I tried to use option in iis7 Enforce lowercase URLs, but when i enabled it all images that had *.JPG extension (uppercase) stopped server. in prev version of iis it was ok when using upper and lower cases, it returned same source
may i fix it? or should i create rule for each extension like (jpeg, jpg, gif...)
I was just reading an article on writing rules, from Scott Gu
Tips/Trick: Fix Common SEO Problems Using the URL Rewrite Extension
He talks about the issue of excluding static files (.jpeg, .jpg, .gif, etc.) from the lowercase rewrite, and shows how you can add conditions to exclude files. Another article is where I found the condition for excluding more than just Scott's example
Mike's Umbraco blog - URL Rewriting and SEO
He adds the condition:
<add input="{URL}" pattern="^.*\.(axd|css|js|jpg|jpeg|png|gif)$" negate="true" ignoreCase="true" />
I hope this helps you in future rewrites.