Unable to pick up custom camel converter - apache-camel

I've created a new converter with the following structure:
package com.mycompany;
#Converter
public final class MyCustomConverter {
#Converter
public static TypeB convert(TypeA typeA) {
// do the conversion
}
}
I've also created in my src/main/java/resources folder the following package, META-INF.services.org.apache.camel and within that a TypeConverter file which just says:
com.mycompany
Within my route from TypeA I have got:
<convertBodyTo type="com.mycompany.TypeB" />
Yet my tests constantly fail to pick up the file and thus cannot find the converter, with the exception being:
Caused by: org.apache.camel.NoTypeConversionAvailableException: No
type converter available to convert from type: com.mycompany.TypeA to
the required type: com.mycompany.TypeB with value TypeA[value1="blah"]
Am I meant to do something else to get my test to pick up the TypeConverter file? Surely putting it in that resources folder with the exact structure adds it to the classpath and so it would be accessible.

Its recommended in the TypeConverter file to list the FQN of all the type conveters, eg
com.mycompany
Should be
com.mycompany.MyCustomConverter
This is also what we say on this page: http://camel.apache.org/type-converter.html
And could you check inside the generated JAR file of yours, that the META-INF/services/org/apache/camel directory is there, and that the TypeConverter file is present (and it is not in some directory like META-INF/org.apache.camel).
Also what is the runtime environment you use? Do you run Camel standalone, Tomcat, OSGi or something else?

Related

What are the EJB Remote Interfaces in the project when createEJBStubs.bat is run?

I understand that createEJBstubs are necessary to create the stubs whenever it is accessed externally via. An Java Client (http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/rejb_3stubscmd2.html?lang=ko). And also, that the stubs that are created will be for the EJB3 interfaces that are available within the module. But how do they detect if a given interface/bean is of type EJB 3 and not 2.*. From the issue the I have faced below, it is not clear to me as to how this detection is done. Please help me to understand this so that I can resolve the issue that I am facing (below)-
DETAILED EXPLANATION OF MY ISSUE:
When I run createEJBStubs.bat C:\1\DEN\proj\target\proj.jar -updatefile C:\1\DEN\proj\target\proj.jar -verbose
I get the following error -
CNTR9241I: The C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar Java archive (JAR) file has no level 3.0 enterprise beans with remote interfaces.
And when I run the same command using -verbose option, I get the following error -
createWarProcessingRootDir: enter
Root directory for war processing: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622
War explosion root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls
War primary input root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\primary
War primary classpath root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\primary\classPth
War primary workspace root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\primary\wrkSpace
War alternate workspace root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\alternate\wrkSpace
War alternate output file: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\alternateOutputWar.war
War embedded in ear root: C:\Users\w723521\AppData\Local\Temp\_tempWar_1096410607889881622\warExpls\embInEar
createWarProcessingRootDir: exit
Dumping input parameters:
parameter 1 = C:\1\DEN\proj\target\proj-5.DEV-SNA
PSHOT.jar
parameter 2 = -updatefile
parameter 3 = C:\1\DEN\proj\target\proj-5.DEV-SNA
PSHOT.jar
parameter 4 = -trace
Processing the C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar input file.
checkEJBVersion - jar name is C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar
The output file name is C:\Users\w723521\AppData\Local\Temp\ejb3093395338317385883.jar
copyArchiveEntriesAndStubs(null,C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar,C:\Users\w723521\AppData\Local\Temp\ejb3093395338317385883.jar,false)
Main output archive file (no pre-existing stubs) is C:\Users\w723521\AppData\Local\Temp\ejb3093395338317385883.jar
Preexisting stubs archive file is ejb5694574801473018226.jar
Writing non-stub entry MANIFEST.MF
Writing non-stub entry TestLocal.class
Writing non-stub entry TestRemote.class
Classloader updated for -cp null
Classloader updated for jar C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar
getMetaData - entry
metadataComplete setting is false
findRemoteInterfaces
List of interfaces are: null
Number of pre-existing stubs = 0
CNTR9241I: The C:\1\DEN\proj\target\proj-5.DEV-SNAPSHOT.jar Java archive (JAR) file has no level 3.0 enterprise beans with remote interfaces.
Starting process of deleting workspace files...
Done with process of deleting workspace files...
Command Successful
I am not able to understand why it says that no local and remote interfaces are of EJB3 even though the bean classes created using EJB3 annotations
#Remote
public interface TestRemote {
public void test();
}
#Remote
public interface TestRemote {
public void test();
}
How does the script detect if a given interface is EJB3 or not? (based on the output that I have obtained it is not as clear as I expected it to be)
proj-5.DEV-SNAPSHOT.jar would need to somehow specify both an EJB and its remote interface. For example, if ejb-jar.xml is used, a <session> with a <remote>pkg.TestRemote</remote>. For another example, if some class in the JAR is annotated with #Stateless and #Remote(TestRemote.class).

Why does Jasypt try to decrypt Camel Property Placeholders, regardless of the ENC( prefix?

In my Blueprint application deployed in JBoss Fuse 6.1.0-379, I want to secure the password I use for creating a database connection. I read this article and added <enc:property-placeholder> to the blueprint configuration. However my blueprint configuration has many property placeholders, and it seems that the Jasypt Placeholder Resolver is trying to decrypt all the placeholders I define in my Camel Context. When the Blueprint Context starts up, I get the following exception:
11:59:51,233 | ERROR | t-379-dmz/deploy | BlueprintCamelContext | 151 - org.apache.camel.camel-blueprint - 2.12.0.redhat-610379 | Error occurred during starting Camel: CamelContext(camel-5) due Failed to create route route7: Route(route7)[[From[{{uri}}]] -> [Log[logging]]] because of Failed to resolve endpoint: {{uri}} due to: org.jasypt.exceptions.EncryptionOperationNotPossibleException
org.apache.camel.FailedToCreateRouteException: Failed to create route route7: Route(route7)[[From[{{uri}}]] -> [Log[logging]]] because of Failed to resolve endpoint: {{uri}} due to: org.jasypt.exceptions.EncryptionOperationNotPossibleException
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:182)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:778)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:1955)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1705)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1579)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1547)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.blueprint.BlueprintCamelContext.start(BlueprintCamelContext.java:177)[151:org.apache.camel.camel-blueprint:2.12.0.redhat-610379]
at org.apache.camel.blueprint.BlueprintCamelContext.maybeStart(BlueprintCamelContext.java:209)[151:org.apache.camel.camel-blueprint:2.12.0.redhat-610379]
at org.apache.camel.blueprint.BlueprintCamelContext.serviceChanged(BlueprintCamelContext.java:147)[151:org.apache.camel.camel-blueprint:2.12.0.redhat-610379]
at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:934)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:795)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:544)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4666)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.Felix.registerService(Felix.java:3674)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:347)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:448)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:383)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:270)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:233)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[11:org.apache.aries.util:1.0.1.redhat-610379]
at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[11:org.apache.aries.util:1.0.1.redhat-610379]
at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[11:org.apache.aries.util:1.0.1.redhat-610379]
at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[11:org.apache.aries.util:1.0.1.redhat-610379]
at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[11:org.apache.aries.util:1.0.1.redhat-610379]
at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:696)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:484)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4650)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.Felix$4.run(Felix.java:2123)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.Felix.runInContext(Felix.java:2147)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2121)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1247)[7:org.apache.felix.fileinstall:3.3.11.redhat-610379]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1219)[7:org.apache.felix.fileinstall:3.3.11.redhat-610379]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1208)[7:org.apache.felix.fileinstall:3.3.11.redhat-610379]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:503)[7:org.apache.felix.fileinstall:3.3.11.redhat-610379]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:291)[7:org.apache.felix.fileinstall:3.3.11.redhat-610379]
Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: {{uri}} due to: org.jasypt.exceptions.EncryptionOperationNotPossibleException
at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:480)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.util.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:71)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.model.RouteDefinition.resolveEndpoint(RouteDefinition.java:192)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:106)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:112)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.model.FromDefinition.resolveEndpoint(FromDefinition.java:72)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.impl.DefaultRouteContext.getEndpoint(DefaultRouteContext.java:88)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:890)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:177)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
... 38 more
Caused by: org.apache.camel.RuntimeCamelException: org.jasypt.exceptions.EncryptionOperationNotPossibleException
at org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1363)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.util.ObjectHelper.invokeMethod(ObjectHelper.java:1005)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.blueprint.BlueprintPropertiesParser.parseProperty(BlueprintPropertiesParser.java:137)[151:org.apache.camel.camel-blueprint:2.12.0.redhat-610379]
at org.apache.camel.component.properties.DefaultPropertiesParser.createPlaceholderPart(DefaultPropertiesParser.java:201)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.component.properties.DefaultPropertiesParser.doParseUri(DefaultPropertiesParser.java:105)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.component.properties.DefaultPropertiesParser.parseUri(DefaultPropertiesParser.java:51)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:160)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:119)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.impl.DefaultCamelContext.resolvePropertyPlaceholders(DefaultCamelContext.java:1155)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:478)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
... 46 more
Caused by: org.jasypt.exceptions.EncryptionOperationNotPossibleException
at org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918)
at org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725)
at org.apache.karaf.jaas.jasypt.handler.EncryptablePropertyPlaceholder.getProperty(EncryptablePropertyPlaceholder.java:38)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_25]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_25]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_25]
at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_25]
at org.apache.camel.util.ObjectHelper.invokeMethod(ObjectHelper.java:1001)[143:org.apache.camel.camel-core:2.12.0.redhat-610379]
... 54 more
I created a test bundle with a Blueprint Context which contains only one placeholder property defined in the Camel Context, without using the encrypted ENC() placeholder syntax. I just added <enc:property-placeholder> and the bundle failed to start with same exception (org.jasypt.exceptions.EncryptionOperationNotPossibleException).
Is this desired behavior?
My Blueprint configuration:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
xmlns:enc="http://karaf.apache.org/xmlns/jasypt/v1.0.0"
xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0">
<cm:property-placeholder persistent-id="encrypt.config" update-strategy="reload" >
<cm:default-properties>
<cm:property name="uri" value="timer://foo?fixedRate=true&period=6000"/>
</cm:default-properties>
</cm:property-placeholder>
<enc:property-placeholder>
<enc:encryptor class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
<property name="config">
<bean class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
<property name="algorithm" value="PBEWithMD5AndDES" />
<property name="password" value="password" />
</bean>
</property>
</enc:encryptor>
</enc:property-placeholder>
<camelContext xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://camel.apache.org/schema/blueprint"
xsi:schemaLocation="http://camel.apache.org/schema/blueprint">
<route>
<from uri="{{uri}}"/>
<log message="logging" loggingLevel="INFO" id="logBeforeService"></log>
</route>
</camelContext>
</blueprint>
EDIT: Response from RedHat Support
So this is a known issue, and theres a couple of Jira issues for it (here and here), and it appears as if the issue has been resolved in newer versions of Camel. I have tested with version 2.12.0.redhat-611412, provided by the patch named jboss-fuse-6.1.0.redhat-379-r1p3, and the exception is no longer being thrown.
Regardless of what I have said previously, im quite happy with this implementation. I would want an exception to be thrown if it couldnt decrypt a value which was actaully encrypted, and that is exactly what happens. I modified the encrypted value to ENC(invalid_and_should_throw_exception), and an exception was thrown exactly like I would expect it to.
Caused by: org.jasypt.exceptions.EncryptionOperationNotPossibleException
EDIT: A more concise Answer
Camel-Blueprint behaves differently to Camel-Core, in regards to the way that it resolves property placeholder values. Camel-Core requires the developer to define a Camel Property Placeholder Resolver, which resolves properties in the Camel Context, for the camel property syntax [1]. Obviously the reasoning behind this is to avoid conflicts between the spring property syntax [2] and the Camel Simple Expression Language syntax [3]. The developer has the choice to optionally bridge the Spring Property Placeholder Resolver with Camel by adding extra configuration.
[1 - Camel Property Syntax]
{{org.my.prop}}
[2 - Spring Property Syntax]
${org.my.prop}
[3 - Simple Expression Language Syntax]
${exchange.body}
In Camel-Blueprint, the bridging between the Blueprint Property Placeholder Resolvers and the Camel Context happens automatically. When a Blueprint Camel Context is created, the Blueprint Bundle Context is injected into it. With the Blueprint Bundle Context, Camel pulls all of the beans out of it and determines if they are assignable to the Apache Aries implementation AbstractPropertyPlaceholder. With each instance of the Property Placeholder Resolvers you have defined, Camel is then capable of calling the resolveProperty method on them, without having to parse the property syntax defined by each of the resolvers.
Because the Jasypt Property Placeholder Resolver expects the placeholder syntax [4], it just ignores everything which dosent match this syntax. Because Camel-Blueprint by-passes that validation which ensures the property syntax, we end up in a scenario where Camel is telling the Jasypt Placeholder Resolver to decrypt every property that we attempt to use in our Camel Context. This of course will throw an exception, because you’re trying to decrypt a property which hasn’t been encrypted.
[4 - Jasypt Blueprint Property Syntax]
ENC(encrypted.value)
Solutions:
Create a class which implements the Jasypt StringEncryptor and holds the StandardPBEStringEncryptor as an attribute. The implemented encrypt and decrypt methods call the encrypt and decrypt methods of the StandardPBEStringEncryptor, but catch any exceptions that are thrown.
This is the solution I gave in my original answer.
This is dangerous, if an encrypted value can’t be decrypted that shouldn’t be ignored. The bundle should not start up, to prevent e.g. your database account from getting locked.
Decrypt values manually before passing them to the Placeholder Resolver.
You could create a configuration service, where you compaile all your configuration from your various sources, decrypt all the encrypted values manually, then expose the properties as an OSGi service to be shared accross bundles.
I’ve gone off this design, it’s basically re-implementing the ConfigurationAdmin service which is provided natively by Karaf (with the addition of decryption which Karaf doesn’t provide), it’s just not as good as the one Karaf provides as it is not capable of detecting when application configuration has changed.
Decrypt values at runtime.
Not a fan of this either, requires your application to be aware of which application properties are expected to be encrypted.
I have raised a support ticket with Redhat through our support contract, I'll keep you updated if anything comes of it.
Original Answer:
I think I figured this one out. According to the camel documentation, in blueprint camel is capable of detecting that a blueprint placeholder resolver is present, and attempts to use that to resolve its properties.
The problem with this is that it does not care what the placeholder prefix and suffix is, it just goes ahead and uses it regarless. The Jasypt placeholder resolver has been desgined so that it is only even invoked if the placeholder prefix is "ENC(" and the suffix is ")", remember Camel dosent care about this. Camel passes its unresolved properties to the Jasypt property resolver, which of course attempts to decrypt them. Because they are not encrypted, an exception is thrown.
To get around this, I have created a custom encryptor which implements the Jasypt StringEncryptor. The custom encryptor contains an instance of the StandardPBEStingEncryptor, and uses that to do the actual encryption/ decryption. The key difference is that Exceptions are caught and ignored, so if an Exception is thrown trying to decrypt a camel property which isnt encrypted, then it is ignored and the application continues as normal.
The Java Class:
package uk.co.test;
import org.jasypt.encryption.StringEncryptor;
import org.jasypt.encryption.pbe.StandardPBEStringEncryptor;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class CustomEncryptor implements StringEncryptor {
private StandardPBEStringEncryptor encryptor;
private static final Logger LOG = LoggerFactory.getLogger(CustomEncryptor.class);
public CustomEncryptor(String password) {
encryptor = new StandardPBEStringEncryptor();
encryptor.setPassword(password);
}
#Override
public String decrypt(String value) {
String ret = null;
try {
ret = encryptor.decrypt(value);
} catch (Exception e) {
LOG.error("Failed to decrypt value.");
}
return ret;
}
#Override
public String encrypt(String value) {
String ret = null;
try {
ret = encryptor.encrypt(value);
} catch (Exception e) {
LOG.error("Failed to encrypt value.");
}
return ret;
}
public StandardPBEStringEncryptor getEncryptor() {
return encryptor;
}
public void setEncryptor(StandardPBEStringEncryptor encryptor) {
this.encryptor = encryptor;
}
}
The Blueprint configuration:
<enc:property-placeholder>
<enc:encryptor class="uk.co.test.CustomEncryptor">
<argument value="myPass" />
</enc:encryptor>
</enc:property-placeholder>

camel ftp route and file type converters

I am struggling with type conversion in my camel route for handling ftp files. My route looks like this (in Spring DSL):
<route id="processIncomingFtpFile" errorHandlerRef="parkingCitErrHandler">
<from uri="{{ftp.parkingcit.input.path}}"/>
<bean ref="ftpZipFileHandler"/>
<unmarshal ref="bindyCsvFormat"/>
<bean ref="parkingTicketsHandler"/>
<split>
<simple>${body}</simple>
<marshal ref="jaxbFormatter"/>
<convertBodyTo type="java.io.File"/>
<to uri="{{ftp.parkingcit.output.path}}"/>
</split>
</route>
And my handler signature looks like this:
public File handleIncomingFile(File incomingfile)...
However, this yields the following type conversion problem:
org.apache.camel.InvalidPayloadException: No body available of type: java.io.File but has value: RemoteFile[test.zip] of type: org.apache.camel.component.file.remote.RemoteFile on: test.zip. Caused by: No type converter available to convert from type: org.apache.camel.component.file.remote.RemoteFile to the required type: java.io.File with value RemoteFile[test.zip]. Exchange[test.zip]. Caused by: [org.apache.camel.NoTypeConversionAvailableException - No type converter available to convert from type: org.apache.camel.component.file.remote.RemoteFile to the required type: java.io.File with value RemoteFile[test.zip]]
My question is: should I be able to handle my ftp file in-memory, without explicitly telling camel to write it to disk, with type converters doing the work automagically behind the scenes for me? Or is what I am trying to do senseless, given that my handler wants a java.io.File as its input parameter, i.e. I must write the data to disk for this to work?
java.io.File is for file systems, and not for FTP files.
You would need to change the type in your bean method signature to either Camel's GenericFile or the actual type which is from the commons-net FTP client library that Camel uses.
hmm, I would recommend to work with a local file (I always do that with the ftp endpoint). There is an option in the ftp endpoint called localWorkDirectory that lets you define a directory to download the file ( typically, /tmp ) before further processing. The idea is to avoid any error due to network issue or being disconnected during process
Can you try it It's easy enough (just add &localWorkDirectory =mydir in the uri ) and it will dl the file for you
see https://camel.apache.org/ftp2.html.
Just make sure you have write right on the directory, of course

How to activate datanucleus java-type extensions for JPA?

I have a simple JPA #Entity that has a property of type
java.util.Locale.
When I try and persist this, I get the following error:
java.lang.IllegalArgumentException: locale: java.util.Locale is not a supported property type.
at com.google.appengine.api.datastore.DataTypeUtils.checkSupportedSingleValue( DataTypeUtils.java:174)
...
In the appengine SDK (1.3.1), datanucleus-core-1.1.5.jar contains
plugin.xml which contains the following type conversion "extension":
<java-type name="java.util.Locale" persistent="true" embedded="true"
string-converter="org.datanucleus.store.types.LocaleStringConverter"/>
How do I "activate" this type converter in my #Entity class?
This seems to be a significant limitation of Google's use of datanucleus. See the following (2nd last heading):
http://datanucleus.blogspot.com/2010/01/gaej-and-jdojpa.html

problem with loading a jar file which has dependency to another jar file

I have a problem while loading my jar file at run time.
My hotel.jar is loaded and a method of it (makeReservation) is invoked using the following code:
File file = new File("c:/ComponentFiles/hotel.jar");
URL jarfile = new URL("jar", "", "file:" + file.getAbsolutePath() + "!/");
URLClassLoader cl = URLClassLoader.newInstance(new URL[]{jarfile});
Class componentClass = cl.loadClass("HotelPackage.HotelMgt");
Object componentObject = componentClass.newInstance();
Method setMethod = componentClass.getDeclaredMethod("makeReservation", null);
setMethod.invoke(componentObject, null);
The problem is in the class HotelPackage.HotelMgt of my jar file , I have a class variable of another class (HotelPackage.Hotel) which is in another jar file.
I tried to open and load the other jar file with the same code as above but I receive the exception that cannot find the class def.:
Exception in thread "main" java.lang.NoClassDefFoundError: BeanPackage/Hotel
what is the solution?
You can specify dependencies between JARs by defining the Class-Path property in the JARs' manifest files. Then the JVM will load the dependency JARs automatically as needed.
More information is here: http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html
Thanks, but I found another solution that really works. Since I know whole the component series that are going to work with each other, I load them all with one class loader instance (array of URLs). then the classloader itself manages the dependencies.

Resources