[jira] [Updated] (CAMEL-7849) Encrypted properties outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Summary: Encrypted properties outside   (was: Encrypted 
properties inside and outside )

> Encrypted properties outside 
> ---
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
> Fix For: 2.14.3, 2.15.2, 2.16.0
>
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following Camel Spring DSL snippet decrypts the 
> property value inside  via {{key}} but does 
> not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, first I remove all of the above. 
> Then I add jasypt dependencies to pom.xml:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> And add the following to Camel Spring DSL:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> This is the only solution that I could discover. Using 
> BridgePropertyPlaceholder 
> didn't work.  must be used inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Decrypting properties via Jasypt outside of

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Summary: Decrypting properties via Jasypt outside of   (was: 
Encrypted properties via Jasypt outside )

> Decrypting properties via Jasypt outside of 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
> Fix For: 2.14.3, 2.15.2, 2.16.0
>
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following Camel Spring DSL snippet decrypts the 
> property value inside  via {{key}} but does 
> not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, first I remove all of the above. 
> Then I add jasypt dependencies to pom.xml:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> And add the following to Camel Spring DSL:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> This is the only solution that I could discover. Using 
> BridgePropertyPlaceholder 
> didn't work.  must be used inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties via Jasypt outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Summary: Encrypted properties via Jasypt outside   (was: 
Encrypted properties outside )

> Encrypted properties via Jasypt outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
> Fix For: 2.14.3, 2.15.2, 2.16.0
>
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following Camel Spring DSL snippet decrypts the 
> property value inside  via {{key}} but does 
> not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, first I remove all of the above. 
> Then I add jasypt dependencies to pom.xml:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> And add the following to Camel Spring DSL:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> This is the only solution that I could discover. Using 
> BridgePropertyPlaceholder 
> didn't work.  must be used inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14487727#comment-14487727
 ] 

Camel Guy commented on CAMEL-7849:
--

That's great news. How long until 2.15.2 is released?

> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
> Fix For: 2.14.3, 2.15.2, 2.16.0
>
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following Camel Spring DSL snippet decrypts the 
> property value inside  via {{key}} but does 
> not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, first I remove all of the above. 
> Then I add jasypt dependencies to pom.xml:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> And add the following to Camel Spring DSL:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> This is the only solution that I could discover. Using 
> BridgePropertyPlaceholder 
> didn't work.  must be used inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8588:
-
Comment: was deleted

(was: Thanks for your help. Stupid me, I didn't try an uppercase L. And I don't 
have to use out any more either. After 18 months of Cameling, I still don't 
understand MEP.)

> REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
> 
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
>
> There doesn't seem to be a way to use the REST DSL in a provider-agnostic way 
> in order to produce a redirect. 
> Setting the location header generates a warning sent to the console:
> {noformat}
> Addition of the standard header "location" is not allowed. Please use the 
> equivalent property in the Restlet API.{noformat}
> Very small example: http://pastebin.com/Zaq7p0Us
> Also see linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14393540#comment-14393540
 ] 

Camel Guy commented on CAMEL-8588:
--

Thanks for your help. Stupid me, I didn't try an uppercase L. And I don't have 
to use out any more either. After 18 months of Cameling, I still don't 
understand MEP.

> REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
> 
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
>
> There doesn't seem to be a way to use the REST DSL in a provider-agnostic way 
> in order to produce a redirect. 
> Setting the location header generates a warning sent to the console:
> {noformat}
> Addition of the standard header "location" is not allowed. Please use the 
> equivalent property in the Restlet API.{noformat}
> Very small example: http://pastebin.com/Zaq7p0Us
> Also see linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14393541#comment-14393541
 ] 

Camel Guy commented on CAMEL-8588:
--

Thanks for your help. Stupid me, I didn't try an uppercase L. And I don't have 
to use out any more either. After 18 months of Cameling, I still don't 
understand MEP.

> REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
> 
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
>
> There doesn't seem to be a way to use the REST DSL in a provider-agnostic way 
> in order to produce a redirect. 
> Setting the location header generates a warning sent to the console:
> {noformat}
> Addition of the standard header "location" is not allowed. Please use the 
> equivalent property in the Restlet API.{noformat}
> Very small example: http://pastebin.com/Zaq7p0Us
> Also see linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14392879#comment-14392879
 ] 

Camel Guy commented on CAMEL-8588:
--

Regarding the MEP, it took me an hour to figure out that I should use 
exchange.out. 

headers.'Content-Type' =

Had no effect.

> REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
> 
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
>
> There doesn't seem to be a way to use the REST DSL in a provider-agnostic way 
> in order to produce a redirect. 
> Setting the location header generates a warning sent to the console:
> {noformat}
> Addition of the standard header "location" is not allowed. Please use the 
> equivalent property in the Restlet API.{noformat}
> Very small example: http://pastebin.com/Zaq7p0Us
> Also see linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8588:
-
Description: 
There doesn't seem to be a way to use the REST DSL in a provider-agnostic way 
in order to produce a redirect. 

Setting the location header generates a warning sent to the console:
{noformat}
Addition of the standard header "location" is not allowed. Please use the 
equivalent property in the Restlet API.{noformat}

Very small example: http://pastebin.com/Zaq7p0Us

Also see linked JIRA.

  was:
There doesn't seem to be a way to use the REST DSL in a provider-agnostic way 
in order to produce a redirect. 

Setting the location header generates a warning sent to the console.

Addition of the standard header "location" is not allowed. Please use the 
equivalent property in the Restlet API.

Very small example: http://pastebin.com/Zaq7p0Us

Also see linked JIRA.


> REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
> 
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
>
> There doesn't seem to be a way to use the REST DSL in a provider-agnostic way 
> in order to produce a redirect. 
> Setting the location header generates a warning sent to the console:
> {noformat}
> Addition of the standard header "location" is not allowed. Please use the 
> equivalent property in the Restlet API.{noformat}
> Very small example: http://pastebin.com/Zaq7p0Us
> Also see linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8588:
-
Description: 
There doesn't seem to be a way to use the REST DSL in a provider-agnostic way 
in order to produce a redirect. 

Setting the location header generates a warning sent to the console.

Addition of the standard header "location" is not allowed. Please use the 
equivalent property in the Restlet API.

Very small example: http://pastebin.com/Zaq7p0Us

Also see linked JIRA.

  was:
There doesn't seem to be a way to use the REST DSL properly to produce a 
redirect. Setting the location header generates an error.

Example: http://pastebin.com/Zaq7p0Us

Also see linked JIRA.


> REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
> 
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
>
> There doesn't seem to be a way to use the REST DSL in a provider-agnostic way 
> in order to produce a redirect. 
> Setting the location header generates a warning sent to the console.
> Addition of the standard header "location" is not allowed. Please use the 
> equivalent property in the Restlet API.
> Very small example: http://pastebin.com/Zaq7p0Us
> Also see linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8588:
-
Description: 
There doesn't seem to be a way to use the REST DSL properly to produce a 
redirect. Setting the location header generates an error.

Example: http://pastebin.com/Zaq7p0Us

Also see linked JIRA.

  was:
There doesn't seem to be a way to use the REST DSL 'properly' to produce a 
redirect. Setting the location header generates an error.

Example: http://pastebin.com/Zaq7p0Us

Also see linked JIRA.


> REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
> 
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
>
> There doesn't seem to be a way to use the REST DSL properly to produce a 
> redirect. Setting the location header generates an error.
> Example: http://pastebin.com/Zaq7p0Us
> Also see linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8588) REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8588:
-
Priority: Minor  (was: Major)
 Summary: REST DSL with camel-restlet: Status 302 (redirect) and the 
'location' header  (was: REST DSL with camel-restlet - 302/location header)

> REST DSL with camel-restlet: Status 302 (redirect) and the 'location' header
> 
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
>
> There doesn't seem to be a way to use the REST DSL 'properly' to produce a 
> redirect. Setting the location header generates an error.
> Example: http://pastebin.com/Zaq7p0Us
> Also see linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8588) REST DSL with camel-restlet - 302/location header

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8588:
-
Description: 
There doesn't seem to be a way to use the REST DSL 'properly' to produce a 
redirect. Setting the location header generates an error.

Example: http://pastebin.com/Zaq7p0Us

Also see linked JIRA.

  was:
There doesn't seem to be a way to use the REST DSL 'properly' to produce a 
redirect. Setting the location header generates an error.

Example will be provided shortly.

Also see linked JIRA.


> REST DSL with camel-restlet - 302/location header
> -
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>
> There doesn't seem to be a way to use the REST DSL 'properly' to produce a 
> redirect. Setting the location header generates an error.
> Example: http://pastebin.com/Zaq7p0Us
> Also see linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8588) REST DSL with camel-restlet - 302/location header

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8588:
-
Description: 
There doesn't seem to be a way to use the REST DSL 'properly' to produce a 
redirect. Setting the location header generates an error.

Example will be provided shortly.

Also see linked JIRA.

  was:
There doesn't seem to be a way to use the REST DSL 'properly' to produce a 
redirect. Setting the location header generates an error.

Example will be provided shortly.

See linked JIRA.


> REST DSL with camel-restlet - 302/location header
> -
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>
> There doesn't seem to be a way to use the REST DSL 'properly' to produce a 
> redirect. Setting the location header generates an error.
> Example will be provided shortly.
> Also see linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8588) REST DSL with camel-restlet - 302/location header

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8588:
-
  Description: 
There doesn't seem to be a way to use the REST DSL 'properly' to produce a 
redirect. Setting the location header generates an error.

Example will be provided shortly.

See linked JIRA.

  was:
The restlet consumer does not send back custom headers, such as Location, Foo, 
Bar or what end user may have added as headers.

For example Location would be needed if you set the status code to 302 for a 
redirect etc.

See nabble
http://camel.465427.n5.nabble.com/Camel-Restlet-and-HTTP-302-tp5741853.html

Affects Version/s: (was: 2.12.1)
   (was: 2.11.2)
   2.15.0
Fix Version/s: (was: 2.12.2)
   (was: 2.13.0)

> REST DSL with camel-restlet - 302/location header
> -
>
> Key: CAMEL-8588
> URL: https://issues.apache.org/jira/browse/CAMEL-8588
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-restlet
>Affects Versions: 2.15.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>
> There doesn't seem to be a way to use the REST DSL 'properly' to produce a 
> redirect. Setting the location header generates an error.
> Example will be provided shortly.
> See linked JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-8588) REST DSL with camel-restlet - 302/location header

[Camel Guy (JIRA)]

Camel Guy created CAMEL-8588:


 Summary: REST DSL with camel-restlet - 302/location header
 Key: CAMEL-8588
 URL: https://issues.apache.org/jira/browse/CAMEL-8588
 Project: Camel
  Issue Type: Improvement
  Components: camel-restlet
Affects Versions: 2.11.2, 2.12.1
Reporter: Camel Guy
Assignee: Claus Ibsen
 Fix For: 2.12.2, 2.13.0


The restlet consumer does not send back custom headers, such as Location, Foo, 
Bar or what end user may have added as headers.

For example Location would be needed if you set the status code to 302 for a 
redirect etc.

See nabble
http://camel.465427.n5.nabble.com/Camel-Restlet-and-HTTP-302-tp5741853.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242051#comment-14242051
 ] 

Camel Guy commented on CAMEL-7849:
--

Was not using OSGI container.

> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following Camel Spring DSL snippet decrypts the 
> property value inside  via {{key}} but does 
> not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, first I remove all of the above. 
> Then I add jasypt dependencies to pom.xml:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> And add the following to Camel Spring DSL:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> This is the only solution that I could discover. Using 
> BridgePropertyPlaceholder 
> didn't work.  must be used inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14230480#comment-14230480
 ] 

Camel Guy edited comment on CAMEL-8077 at 12/1/14 9:19 PM:
---

You or someone else actually fixed the problem on 2.14.1-SNAPSHOT. Thank you!


was (Author: camelguy):
You or someone else actually fixed the problem on 2.14.1-SNAPSHOT.

> NullPointerException in getRouteDefinition before context is started
> 
>
> Key: CAMEL-8077
> URL: https://issues.apache.org/jira/browse/CAMEL-8077
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.14.1, 2.15.0
>
>
> Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.
> I am extending CamelSpringTestSupport with:
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
> In a @Before method I call context.getRouteDefintion("some.id")
> It throws a NullPointerException:
> org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)
> If I put context.start() at the top of the @Before method, it works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14230480#comment-14230480
 ] 

Camel Guy edited comment on CAMEL-8077 at 12/1/14 9:20 PM:
---

You or someone else fixed the problem on 2.14.1-SNAPSHOT, which I confirmed. 
Thank you!


was (Author: camelguy):
You or someone else actually fixed the problem on 2.14.1-SNAPSHOT. Thank you!

> NullPointerException in getRouteDefinition before context is started
> 
>
> Key: CAMEL-8077
> URL: https://issues.apache.org/jira/browse/CAMEL-8077
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.14.1, 2.15.0
>
>
> Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.
> I am extending CamelSpringTestSupport with:
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
> In a @Before method I call context.getRouteDefintion("some.id")
> It throws a NullPointerException:
> org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)
> If I put context.start() at the top of the @Before method, it works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14230480#comment-14230480
 ] 

Camel Guy commented on CAMEL-8077:
--

You or someone else actually fixed the problem on 2.14.1-SNAPSHOT.

> NullPointerException in getRouteDefinition before context is started
> 
>
> Key: CAMEL-8077
> URL: https://issues.apache.org/jira/browse/CAMEL-8077
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.14.1, 2.15.0
>
>
> Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.
> I am extending CamelSpringTestSupport with:
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
> In a @Before method I call context.getRouteDefintion("some.id")
> It throws a NullPointerException:
> org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)
> If I put context.start() at the top of the @Before method, it works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229140#comment-14229140
 ] 

Camel Guy edited comment on CAMEL-8077 at 11/30/14 4:00 PM:


For all routes? This exception doesn't occur in 2.13. The route with the id 
it's looking for exists. Code works as-is if I call context.start() (or 
downgrade to 2.13 but I need the CamelFreemarkerDataModel feature).


was (Author: camelguy):
For all routes? This exception doesn't occur in 2.13.

> NullPointerException in getRouteDefinition before context is started
> 
>
> Key: CAMEL-8077
> URL: https://issues.apache.org/jira/browse/CAMEL-8077
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.14.1, 2.15.0
>
>
> Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.
> I am extending CamelSpringTestSupport with:
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
> In a @Before method I call context.getRouteDefintion("some.id")
> It throws a NullPointerException:
> org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)
> If I put context.start() at the top of the @Before method, it works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy reopened CAMEL-8077:
--

> NullPointerException in getRouteDefinition before context is started
> 
>
> Key: CAMEL-8077
> URL: https://issues.apache.org/jira/browse/CAMEL-8077
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.14.1, 2.15.0
>
>
> Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.
> I am extending CamelSpringTestSupport with:
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
> In a @Before method I call context.getRouteDefintion("some.id")
> It throws a NullPointerException:
> org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)
> If I put context.start() at the top of the @Before method, it works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229140#comment-14229140
 ] 

Camel Guy commented on CAMEL-8077:
--

For all routes? This exception doesn't occur in 2.13.

> NullPointerException in getRouteDefinition before context is started
> 
>
> Key: CAMEL-8077
> URL: https://issues.apache.org/jira/browse/CAMEL-8077
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.0
>Reporter: Camel Guy
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.14.1, 2.15.0
>
>
> Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.
> I am extending CamelSpringTestSupport with:
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
> In a @Before method I call context.getRouteDefintion("some.id")
> It throws a NullPointerException:
> org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)
> If I put context.start() at the top of the @Before method, it works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223256#comment-14223256
 ] 

Camel Guy edited comment on CAMEL-8077 at 11/24/14 7:33 PM:


Yes, I am using 2.14.1-SNAPSHOT.

route.getId() returns null when the context has not started.

{noformat}
public synchronized RouteDefinition getRouteDefinition(String id) {
for (RouteDefinition route : routeDefinitions) {
if (route.getId().equals(id)) {
return route;
}
}
return null;
}
{noformat}

There was a time when I could get one route via getRouteDefinition by id 
successfully but not another. getRouteDefinition(A) = successful but 
getRouteDefinition(B) = exception. The difference is that route B is declared 
in camel-context.xml after route A.

However, after adding  and , getRouteDefinition(A) 
failed too. The route I'm trying to grab is in the main context file, not in 
the imported one.

It appears that camel-context.xml is loaded in a background thread and has a 
race condition with my methods. I have the same problem with @Test methods. I 
tried sleeping for, say, a minute in @Begin but that doesn't fix the problem. I 
also moved the @Begin code to the @Test method and put a sleep there. That 
doesn't work either. The only fix is to call context.start().

In camel-context.xml most routes do not specify an id attribute.

Here's my test.java

{noformat}
package my.test;

import org.apache.camel.EndpointInject;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.builder.AdviceWithRouteBuilder;
import org.apache.camel.component.mock.MockEndpoint;
import org.apache.camel.model.ModelCamelContext;
import org.apache.camel.model.RouteDefinition;
import org.apache.camel.test.spring.CamelSpringTestSupport;
import org.springframework.context.support.AbstractXmlApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.junit.Before;
import org.junit.Test;

public final class OneJDBCErrorTest extends CamelSpringTestSupport {
protected AbstractXmlApplicationContext createApplicationContext() {
return new 
ClassPathXmlApplicationContext("META-INF/spring/camel-context.xml");
}

@EndpointInject(uri="direct:Start")
private ProducerTemplate start;

@EndpointInject(uri="mock:Test:JDBC:TotalExceptions")
private MockEndpoint mockTotalExceptions;

@EndpointInject(uri="mock:Test:JDBC:Failed")
private MockEndpoint mockJdbcFailed;

@Override
public boolean isUseAdviceWith() {
return true;
}

@Before
final public void jdbcError() throws Exception {
context.start(); // bug in 2.14 - this is needed

ModelCamelContext model = (ModelCamelContext) context;

RouteDefinition jdbc = model.getRouteDefinition("SQL:JDBC");

jdbc.adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {

weaveById("test:SQL:JDBC:NextError").before().to("mock:Test:JDBC:TotalExceptions");
}
}
);
}

@Test
final public void oneFailure() throws Exception {
mockTotalExceptions.expectedMessageCount(4);
mockJdbcFailed.expectedMessageCount(0);

context.start();
start.sendBody("");

mockTotalExceptions.assertIsSatisfied();
mockJdbcFailed.assertIsSatisfied();

context.stop();
}
}
{noformat}



was (Author: camelguy):
Yes, I am using 2.14.1-SNAPSHOT.

route.getId() returns null when the context has not started.

{noformat}
public synchronized RouteDefinition getRouteDefinition(String id) {
for (RouteDefinition route : routeDefinitions) {
if (route.getId().equals(id)) {
return route;
}
}
return null;
}
{noformat}

There was a time when I could get one route via getRouteDefinition by id 
successfully but not another. getRouteDefinition(A) = successful but 
getRouteDefinition(B) = exception. The difference is that route B is declared 
in camel-context.xml after route A.

However, after adding  and , getRouteDefinition(A) 
failed too. The route I'm trying to grab is in the main context file, not in 
the imported one.

It appears that camel-context.xml is loaded in a background thread and has a 
race condition with my methods. I have the same problem with @Test methods. I 
tried sleeping for, say, a minute in @Begin but that doesn't fix the problem. 
The only fix is to call context.start().

In camel-context.xml most routes do not specify an id attribute.

Here's my test.java

{noformat}
package my.test

[jira] [Comment Edited] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223256#comment-14223256
 ] 

Camel Guy edited comment on CAMEL-8077 at 11/24/14 6:57 PM:


Yes, I am using 2.14.1-SNAPSHOT.

route.getId() returns null when the context has not started.

{noformat}
public synchronized RouteDefinition getRouteDefinition(String id) {
for (RouteDefinition route : routeDefinitions) {
if (route.getId().equals(id)) {
return route;
}
}
return null;
}
{noformat}

There was a time when I could get one route via getRouteDefinition by id 
successfully but not another. getRouteDefinition(A) = successful but 
getRouteDefinition(B) = exception. The difference is that route B is declared 
in camel-context.xml after route A.

However, after adding  and , getRouteDefinition(A) 
failed too. The route I'm trying to grab is in the main context file, not in 
the imported one.

It appears that camel-context.xml is loaded in a background thread and has a 
race condition with my methods. I have the same problem with @Test methods. I 
tried sleeping for, say, a minute in @Begin but that doesn't fix the problem. 
The only fix is to call context.start().

In camel-context.xml most routes do not specify an id attribute.

Here's my test.java

{noformat}
package my.test;

import org.apache.camel.EndpointInject;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.builder.AdviceWithRouteBuilder;
import org.apache.camel.component.mock.MockEndpoint;
import org.apache.camel.model.ModelCamelContext;
import org.apache.camel.model.RouteDefinition;
import org.apache.camel.test.spring.CamelSpringTestSupport;
import org.springframework.context.support.AbstractXmlApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.junit.Before;
import org.junit.Test;

public final class OneJDBCErrorTest extends CamelSpringTestSupport {
protected AbstractXmlApplicationContext createApplicationContext() {
return new 
ClassPathXmlApplicationContext("META-INF/spring/camel-context.xml");
}

@EndpointInject(uri="direct:Start")
private ProducerTemplate start;

@EndpointInject(uri="mock:Test:JDBC:TotalExceptions")
private MockEndpoint mockTotalExceptions;

@EndpointInject(uri="mock:Test:JDBC:Failed")
private MockEndpoint mockJdbcFailed;

@Override
public boolean isUseAdviceWith() {
return true;
}

@Before
final public void jdbcError() throws Exception {
context.start(); // bug in 2.14 - this is needed

ModelCamelContext model = (ModelCamelContext) context;

RouteDefinition jdbc = model.getRouteDefinition("SQL:JDBC");

jdbc.adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {

weaveById("test:SQL:JDBC:NextError").before().to("mock:Test:JDBC:TotalExceptions");
}
}
);
}

@Test
final public void oneFailure() throws Exception {
mockTotalExceptions.expectedMessageCount(4);
mockJdbcFailed.expectedMessageCount(0);

context.start();
start.sendBody("");

mockTotalExceptions.assertIsSatisfied();
mockJdbcFailed.assertIsSatisfied();

context.stop();
}
}
{noformat}



was (Author: camelguy):
Yes, I am using 2.14.1-SNAPSHOT.

route.getId() returns null when the context has not started.

{noformat}
public synchronized RouteDefinition getRouteDefinition(String id) {
for (RouteDefinition route : routeDefinitions) {
if (route.getId().equals(id)) {
return route;
}
}
return null;
}
{noformat}

There was a time when I could get one route via getRouteDefinition by id 
successfully but not another. getRouteDefinition(A) = successful but 
getRouteDefinition(B) = exception. The difference is that route B is declared 
in camel-context.xml after route A.

However, after adding  and , getRouteDefinition(A) 
failed too. The route I'm trying to grab is in the main context file, not in 
the imported one.

It appears that camel-context.xml is loaded in a background thread and has a 
race condition with my methods. I have the same problem with @Test methods. I 
tried sleeping for, say, a minute in @Begin and @Test and that doesn't fix the 
problem. The only fix is to call context.start().

Here's my test.java

{noformat}
package my.test;

import org.apache.camel.EndpointInject;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.builder.AdviceWithRouteBuilder;
import org.apa

[jira] [Comment Edited] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223256#comment-14223256
 ] 

Camel Guy edited comment on CAMEL-8077 at 11/24/14 6:34 PM:


Yes, I am using 2.14.1-SNAPSHOT.

route.getId() returns null when the context has not started.

{noformat}
public synchronized RouteDefinition getRouteDefinition(String id) {
for (RouteDefinition route : routeDefinitions) {
if (route.getId().equals(id)) {
return route;
}
}
return null;
}
{noformat}

There was a time when I could get one route via getRouteDefinition by id 
successfully but not another. getRouteDefinition(A) = successful but 
getRouteDefinition(B) = exception. The difference is that route B is declared 
in camel-context.xml after route A.

However, after adding  and , getRouteDefinition(A) 
failed too. The route I'm trying to grab is in the main context file, not in 
the imported one.

It appears that camel-context.xml is loaded in a background thread and has a 
race condition with my methods. I have the same problem with @Test methods. I 
tried sleeping for, say, a minute in @Begin and @Test and that doesn't fix the 
problem. The only fix is to call context.start().

Here's my test.java

{noformat}
package my.test;

import org.apache.camel.EndpointInject;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.builder.AdviceWithRouteBuilder;
import org.apache.camel.component.mock.MockEndpoint;
import org.apache.camel.model.ModelCamelContext;
import org.apache.camel.model.RouteDefinition;
import org.apache.camel.test.spring.CamelSpringTestSupport;
import org.springframework.context.support.AbstractXmlApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.junit.Before;
import org.junit.Test;

public final class OneJDBCErrorTest extends CamelSpringTestSupport {
protected AbstractXmlApplicationContext createApplicationContext() {
return new 
ClassPathXmlApplicationContext("META-INF/spring/camel-context.xml");
}

@EndpointInject(uri="direct:Start")
private ProducerTemplate start;

@EndpointInject(uri="mock:Test:JDBC:TotalExceptions")
private MockEndpoint mockTotalExceptions;

@EndpointInject(uri="mock:Test:JDBC:Failed")
private MockEndpoint mockJdbcFailed;

@Override
public boolean isUseAdviceWith() {
return true;
}

@Before
final public void jdbcError() throws Exception {
context.start(); // bug in 2.14 - this is needed

ModelCamelContext model = (ModelCamelContext) context;

RouteDefinition jdbc = model.getRouteDefinition("SQL:JDBC");

jdbc.adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {

weaveById("test:SQL:JDBC:NextError").before().to("mock:Test:JDBC:TotalExceptions");
}
}
);
}

@Test
final public void oneFailure() throws Exception {
mockTotalExceptions.expectedMessageCount(4);
mockJdbcFailed.expectedMessageCount(0);

context.start();
start.sendBody("");

mockTotalExceptions.assertIsSatisfied();
mockJdbcFailed.assertIsSatisfied();

context.stop();
}
}
{noformat}



was (Author: camelguy):
Yes, I am using 2.14.1-SNAPSHOT.

route.getId() returns null when the context has not started. There was a time 
when I could get one route by id successfully but not another, with no clear 
difference between the two.

{noformat}
public synchronized RouteDefinition getRouteDefinition(String id) {
for (RouteDefinition route : routeDefinitions) {
if (route.getId().equals(id)) {
return route;
}
}
return null;
}
{noformat}

However, after adding  and , that failed too. The 
route I'm trying to grab is in the main context file, not in the imported one.

It appears that camel-context.xml is loaded in a background thread and has a 
race condition with my @Before methods. I have the same problem with @Test 
methods. I tried sleeping for, say, a minute in @Begin and @Test and that 
doesn't fix the problem. The only fix is to call context.start().

Here's my test.java

{noformat}
package my.test;

import org.apache.camel.EndpointInject;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.builder.AdviceWithRouteBuilder;
import org.apache.camel.component.mock.MockEndpoint;
import org.apache.camel.model.ModelCamelContext;
import org.apache.camel.model.RouteDefinition;
import org.apache.camel.test.spring.CamelSpringTestSupport;
import 

[jira] [Commented] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223256#comment-14223256
 ] 

Camel Guy commented on CAMEL-8077:
--

Yes, I am using 2.14.1-SNAPSHOT.

route.getId() returns null when the context has not started. There was a time 
when I could get one route by id successfully but not another, with no clear 
difference between the two.

{noformat}
public synchronized RouteDefinition getRouteDefinition(String id) {
for (RouteDefinition route : routeDefinitions) {
if (route.getId().equals(id)) {
return route;
}
}
return null;
}
{noformat}

However, after adding  and , that failed too. The 
route I'm trying to grab is in the main context file, not in the imported one.

It appears that camel-context.xml is loaded in a background thread and has a 
race condition with my @Before methods. I have the same problem with @Test 
methods. I tried sleeping for, say, a minute in @Begin and @Test and that 
doesn't fix the problem. The only fix is to call context.start().

Here's my test.java

{noformat}
package my.test;

import org.apache.camel.EndpointInject;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.builder.AdviceWithRouteBuilder;
import org.apache.camel.component.mock.MockEndpoint;
import org.apache.camel.model.ModelCamelContext;
import org.apache.camel.model.RouteDefinition;
import org.apache.camel.test.spring.CamelSpringTestSupport;
import org.springframework.context.support.AbstractXmlApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.junit.Before;
import org.junit.Test;

public final class OneJDBCErrorTest extends CamelSpringTestSupport {
protected AbstractXmlApplicationContext createApplicationContext() {
return new 
ClassPathXmlApplicationContext("META-INF/spring/camel-context.xml");
}

@EndpointInject(uri="direct:Start")
private ProducerTemplate start;

@EndpointInject(uri="mock:Test:JDBC:TotalExceptions")
private MockEndpoint mockTotalExceptions;

@EndpointInject(uri="mock:Test:JDBC:Failed")
private MockEndpoint mockJdbcFailed;

@Override
public boolean isUseAdviceWith() {
return true;
}

@Before
final public void jdbcError() throws Exception {
context.start(); // bug in 2.14 - this is needed

ModelCamelContext model = (ModelCamelContext) context;

RouteDefinition jdbc = model.getRouteDefinition("SQL:JDBC");

jdbc.adviceWith(context, new AdviceWithRouteBuilder() {
@Override
public void configure() throws Exception {

weaveById("test:SQL:JDBC:NextError").before().to("mock:Test:JDBC:TotalExceptions");
}
}
);
}

@Test
final public void oneFailure() throws Exception {
mockTotalExceptions.expectedMessageCount(4);
mockJdbcFailed.expectedMessageCount(0);

context.start();
start.sendBody("");

mockTotalExceptions.assertIsSatisfied();
mockJdbcFailed.assertIsSatisfied();

context.stop();
}
}
{noformat}


> NullPointerException in getRouteDefinition before context is started
> 
>
> Key: CAMEL-8077
> URL: https://issues.apache.org/jira/browse/CAMEL-8077
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.1
>Reporter: Camel Guy
>
> Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.
> I am extending CamelSpringTestSupport with:
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
> In a @Before method I call context.getRouteDefintion("some.id")
> It throws a NullPointerException:
> org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)
> If I put context.start() at the top of the @Before method, it works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8077:
-
Description: 
Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.

I am extending CamelSpringTestSupport with:

@Override
public boolean isUseAdviceWith() {
return true;
}

In a @Before method I call context.getRouteDefintion("some.id")

It throws a NullPointerException:

org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)

If I put context.start() at the top of the @Before method, it works.



  was:
Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.

I am extending CamelSpringTestSupport with:

@Override
public boolean isUseAdviceWith() {
return true;
}

In a @Before method I call context.getRouteDefintion("some.id")

It throws an exception:

org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)

If I put context.start() at the top of the @Before method, it works.




> NullPointerException in getRouteDefinition before context is started
> 
>
> Key: CAMEL-8077
> URL: https://issues.apache.org/jira/browse/CAMEL-8077
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.1
>Reporter: Camel Guy
>
> Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.
> I am extending CamelSpringTestSupport with:
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
> In a @Before method I call context.getRouteDefintion("some.id")
> It throws a NullPointerException:
> org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)
> If I put context.start() at the top of the @Before method, it works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8077:
-
Description: 
Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.

I am extending CamelSpringTestSupport with:

@Override
public boolean isUseAdviceWith() {
return true;
}

In a @Before method I call context.getRouteDefintion("some.id")

It throws an exception:

org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)

If I put context.start() at the top of the @Before method, it works.



  was:
Not sure if this occurs in 2.14.0.

I am extending CamelSpringTestSupport with:

@Override
public boolean isUseAdviceWith() {
return true;
}

In a @Before method I call context.getRouteDefintion("some.id")

It throws an exception:

org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)

If I put context.start() at the top of the @Before method, it works.

Does not occur in 2.13.3


> NullPointerException in getRouteDefinition before context is started
> 
>
> Key: CAMEL-8077
> URL: https://issues.apache.org/jira/browse/CAMEL-8077
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.1
>Reporter: Camel Guy
>
> Not sure if this occurs in 2.14.0. Does not occur in 2.13.3.
> I am extending CamelSpringTestSupport with:
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
> In a @Before method I call context.getRouteDefintion("some.id")
> It throws an exception:
> org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)
> If I put context.start() at the top of the @Before method, it works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-8077:
-
Description: 
Not sure if this occurs in 2.14.0.

I am extending CamelSpringTestSupport with:

@Override
public boolean isUseAdviceWith() {
return true;
}

In a @Before method I call context.getRouteDefintion("some.id")

It throws an exception:

org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)

If I put context.start() at the top of the @Before method, it works.

Does not occur in 2.13.3

  was:
Not sure if this occurs in 2.14.0.

I am extending CamelSpringTestSupport with:

@Override
public boolean isUseAdviceWith() {
return true;
}

In a @Before method I call context.getRouteDefintion("some.id")

It throws an exception:

org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)

If I put context.start() at the top of the @Before method, it works.


> NullPointerException in getRouteDefinition before context is started
> 
>
> Key: CAMEL-8077
> URL: https://issues.apache.org/jira/browse/CAMEL-8077
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.1
>Reporter: Camel Guy
>
> Not sure if this occurs in 2.14.0.
> I am extending CamelSpringTestSupport with:
> @Override
> public boolean isUseAdviceWith() {
> return true;
> }
> In a @Before method I call context.getRouteDefintion("some.id")
> It throws an exception:
> org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)
> If I put context.start() at the top of the @Before method, it works.
> Does not occur in 2.13.3



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-8077) NullPointerException in getRouteDefinition before context is started

[Camel Guy (JIRA)]

Camel Guy created CAMEL-8077:


 Summary: NullPointerException in getRouteDefinition before context 
is started
 Key: CAMEL-8077
 URL: https://issues.apache.org/jira/browse/CAMEL-8077
 Project: Camel
  Issue Type: Bug
  Components: camel-core
Affects Versions: 2.14.1
Reporter: Camel Guy


Not sure if this occurs in 2.14.0.

I am extending CamelSpringTestSupport with:

@Override
public boolean isUseAdviceWith() {
return true;
}

In a @Before method I call context.getRouteDefintion("some.id")

It throws an exception:

org.apache.camel.impl.DefaultCamelContext.getRouteDefinition(DefaultCamelContext.java:1464)

If I put context.start() at the top of the @Before method, it works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7904) JDBC and SQL components: Setting the PostgreSQL schema search path

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7904:
-
Component/s: camel-core
Description: 
For PostgreSQL it is common to run two commands in a single transaction in 
order to set the schema search path:

set search_path to foo, public;
select 5;

Due to connection pooling it is desirable to combine both statements in a 
single operation.

These types of queries don't work with the JDBC and SQL components because they 
return the result set for the first command (set search_path), which is always 
empty.

The easiest solution would be an option to skip the first N result sets. 
However, if any of those result sets reported an error, an exception should be 
thrown.

  was:
For PostgreSQL it is common to run two commands in a single transaction in 
order to set the schema search path:

set search_path to foo, public;
select 5;

Due to connection pooling it is desirable to combine both statements in a 
single operation.

These types of queries don't work with the JDBC component because it only 
returns the result set for the first command (set search_path), which is always 
empty.

The easiest solution would be an option to skip the first N result sets. 
However, if any of those result sets reported an error, an exception should be 
thrown.

Summary: JDBC and SQL components: Setting the PostgreSQL schema search 
path  (was: JDBC component: Setting the PostgreSQL schema search path)

> JDBC and SQL components: Setting the PostgreSQL schema search path
> --
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core
>Affects Versions: 2.13.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the JDBC and SQL components because 
> they return the result set for the first command (set search_path), which is 
> always empty.
> The easiest solution would be an option to skip the first N result sets. 
> However, if any of those result sets reported an error, an exception should 
> be thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-7904) JDBC component: Setting the PostgreSQL schema search path

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218116#comment-14218116
 ] 

Camel Guy edited comment on CAMEL-7904 at 11/19/14 5:58 PM:


The main problem is that PostgreSQL doesn't let you specify the schema on the 
connection properties.

Please see:

http://postgresql.nabble.com/Search-path-in-connection-string-td5718440.html

Even the beta 9.4 JDBC driver will not have this capability. Therefore, I think 
using Postgres with a connection pool is just a headache, especially since my 
app determines the database name, schema, etc. at run time. I use recipientList 
and dynamically generate the "to" jdbc: url. 

I guess for now, I'd better turn off connection pooling.


was (Author: camelguy):
The main problem is that PostgreSQL doesn't let you specify the schema on the 
connection properties.

Please see:

http://postgresql.nabble.com/Search-path-in-connection-string-td5718440.html

The beta 9.4 driver will not add this feature. Therefore, I think using 
Postgres with a connection pool is just a headache, especially since my app 
determines the database name, schema, etc. at run time. I use recipientList and 
dynamically generate the "to" jdbc: url. 

I guess for now, I'd better turn off connection pooling.

> JDBC component: Setting the PostgreSQL schema search path
> -
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.13.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the JDBC component because it only 
> returns the result set for the first command (set search_path), which is 
> always empty.
> The easiest solution would be an option to skip the first N result sets. 
> However, if any of those result sets reported an error, an exception should 
> be thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7904) JDBC component: Setting the PostgreSQL schema search path

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7904:
-
  Description: 
For PostgreSQL it is common to run two commands in a single transaction in 
order to set the schema search path:

set search_path to foo, public;
select 5;

Due to connection pooling it is desirable to combine both statements in a 
single operation.

These types of queries don't work with the JDBC component because it only 
returns the result set for the first command (set search_path), which is always 
empty.

The easiest solution would be an option to skip the first N result sets. 
However, if any of those result sets reported an error, an exception should be 
thrown.

  was:
For PostgreSQL it is common to run two commands in a single transaction in 
order to set the schema search path:

set search_path to foo, public;
select 5;

Due to connection pooling it is desirable to combine both statements in a 
single operation.

These types of queries don't work with the jdbc component because it only 
returns the result set for the first command (set search_path), which is always 
empty.

Easiest solution is to provide a uri option to return the last result set 
instead of the first one. This solution would be preferable to me and would be 
compatible with streaming. 

A more complete solution would be an option to return all of the result sets.

Affects Version/s: (was: 2.14.0)
   2.13.0
  Summary: JDBC component: Setting the PostgreSQL schema search 
path  (was: JDBC component: Support for multiple resultSets)

> JDBC component: Setting the PostgreSQL schema search path
> -
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.13.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the JDBC component because it only 
> returns the result set for the first command (set search_path), which is 
> always empty.
> The easiest solution would be an option to skip the first N result sets. 
> However, if any of those result sets reported an error, an exception should 
> be thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-7904) JDBC component: Setting the PostgreSQL schema search path

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218116#comment-14218116
 ] 

Camel Guy edited comment on CAMEL-7904 at 11/19/14 4:51 PM:


The main problem is that PostgreSQL doesn't let you specify the schema on the 
connection properties.

Please see:

http://postgresql.nabble.com/Search-path-in-connection-string-td5718440.html

The beta 9.4 driver will not add this feature. Therefore, I think using 
Postgres with a connection pool is just a headache, especially since my app 
determines the database name, schema, etc. at run time. I use recipientList and 
dynamically generate the "to" jdbc: url. 

I guess for now, I'd better turn off connection pooling.


was (Author: camelguy):
The main problem is that PostgreSQL doesn't let you specify the schema on the 
connection properties.

Please see:

http://postgresql.nabble.com/Search-path-in-connection-string-td5718440.html

The beta 9.4 driver will not add this feature. Therefore, I think using 
Postgres with a connection pool is just a headache, especially since my app 
determines the database name, schema, etc. at run time. I use recipientList and 
dynamically generate the "to" jdbc: url. 

I need to be able to run a command on the connection (set search path) and then 
run another SQL statement, guaranteeing that I am using the same connection for 
both statements despite the fact that under the covers a connection pool is 
being used. I guess for now, I'd better turn off connection pooling.

> JDBC component: Setting the PostgreSQL schema search path
> -
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.13.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the JDBC component because it only 
> returns the result set for the first command (set search_path), which is 
> always empty.
> The easiest solution would be an option to skip the first N result sets. 
> However, if any of those result sets reported an error, an exception should 
> be thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-7904) JDBC component: Setting the PostgreSQL schema search path

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169599#comment-14169599
 ] 

Camel Guy edited comment on CAMEL-7904 at 11/19/14 4:49 PM:


I went through the Statement JDBC interface and it appears that there is no way 
to know how many ResultSets will be returned. You have to process each 
ResultSet until there are no more. So the JDBC component can not simply return 
the "last" ResultSet. Instead, it needs to be told how many result sets to 
ignore.


was (Author: camelguy):
I just went through the Statement JDBC interface and it appears that there is 
no way to know how many ResultSets will be returned. You have to process each 
ResultSet until there are no more. So the JDBC component can not simply return 
the "last" ResultSet. Instead, it needs to be told how many result sets to 
ignore.

> JDBC component: Setting the PostgreSQL schema search path
> -
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.13.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the JDBC component because it only 
> returns the result set for the first command (set search_path), which is 
> always empty.
> The easiest solution would be an option to skip the first N result sets. 
> However, if any of those result sets reported an error, an exception should 
> be thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-7904) JDBC component: Setting the PostgreSQL schema search path

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218116#comment-14218116
 ] 

Camel Guy edited comment on CAMEL-7904 at 11/19/14 4:50 PM:


The main problem is that PostgreSQL doesn't let you specify the schema on the 
connection properties.

Please see:

http://postgresql.nabble.com/Search-path-in-connection-string-td5718440.html

The beta 9.4 driver will not add this feature. Therefore, I think using 
Postgres with a connection pool is just a headache, especially since my app 
determines the database name, schema, etc. at run time. I use recipientList and 
dynamically generate the "to" jdbc: url. 

I need to be able to run a command on the connection (set search path) and then 
run another SQL statement, guaranteeing that I am using the same connection for 
both statements despite the fact that under the covers a connection pool is 
being used. I guess for now, I'd better turn off connection pooling.


was (Author: camelguy):
The main problem is that PostgreSQL doesn't let you specify the schema on the 
connection properties.

Please see:

http://postgresql.nabble.com/Search-path-in-connection-string-td5718440.html

The beta 9.4 driver will not add this feature. Therefore, I think using 
Postgres with a connection pool is just a headache, especially since my app 
determines the database name, schema, etc. at run time. I use recipientList and 
dynamically generate the "to" jdbc: url. 

I need to be able to run a command on the connection (set search path) and then 
run another SQL statement, guaranteeing that I am using the same connection for 
both statements despite the fact that under the covers a connection pool is 
being used.

> JDBC component: Setting the PostgreSQL schema search path
> -
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.13.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the JDBC component because it only 
> returns the result set for the first command (set search_path), which is 
> always empty.
> The easiest solution would be an option to skip the first N result sets. 
> However, if any of those result sets reported an error, an exception should 
> be thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-7904) JDBC component: Setting the PostgreSQL schema search path

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169599#comment-14169599
 ] 

Camel Guy edited comment on CAMEL-7904 at 11/19/14 4:49 PM:


I just went through the Statement JDBC interface and it appears that there is 
no way to know how many ResultSets will be returned. You have to process each 
ResultSet until there are no more. So the JDBC component can not simply return 
the "last" ResultSet. Instead, it needs to be told how many result sets to 
ignore.


was (Author: camelguy):
I just went through the Statement JDBC interface and it appears that there is 
no way to know how many ResultSets will be returned. You have to process each 
ResultSet until there are no more. So my first suggestion won't work.

> JDBC component: Setting the PostgreSQL schema search path
> -
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.13.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the JDBC component because it only 
> returns the result set for the first command (set search_path), which is 
> always empty.
> The easiest solution would be an option to skip the first N result sets. 
> However, if any of those result sets reported an error, an exception should 
> be thrown.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-7904) JDBC component: Support for multiple resultSets

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218116#comment-14218116
 ] 

Camel Guy edited comment on CAMEL-7904 at 11/19/14 4:46 PM:


The main problem is that PostgreSQL doesn't let you specify the schema on the 
connection properties.

Please see:

http://postgresql.nabble.com/Search-path-in-connection-string-td5718440.html

The beta 9.4 driver will not add this feature. Therefore, I think using 
Postgres with a connection pool is just a headache, especially since my app 
determines the database name, schema, etc. at run time. I use recipientList and 
dynamically generate the "to" jdbc: url. 

I need to be able to run a command on the connection (set search path) and then 
run another SQL statement, guaranteeing that I am using the same connection for 
both statements despite the fact that under the covers a connection pool is 
being used.


was (Author: camelguy):
The main problem is that PostgreSQL doesn't let you specify the schema on the 
connection properties.

Please see:

http://postgresql.nabble.com/Search-path-in-connection-string-td5718440.html

The beta 9.4 driver will not add this feature. Therefore, I think using 
Postgres with a connection pool is just a headache, especially since my app 
determines the database name, schema, etc. at run time. I use recipientList and 
dynamically generate the "to" jdbc: url.

> JDBC component: Support for multiple resultSets
> ---
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.14.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the jdbc component because it only 
> returns the result set for the first command (set search_path), which is 
> always empty.
> Easiest solution is to provide a uri option to return the last result set 
> instead of the first one. This solution would be preferable to me and would 
> be compatible with streaming. 
> A more complete solution would be an option to return all of the result sets.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7904) JDBC component: Support for multiple resultSets

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218116#comment-14218116
 ] 

Camel Guy commented on CAMEL-7904:
--

The main problem is that PostgreSQL doesn't let you specify the schema on the 
connection properties.

Please see:

http://postgresql.nabble.com/Search-path-in-connection-string-td5718440.html

The beta 9.4 driver will not add this feature. Therefore, I think using 
Postgres with a connection pool is just a headache, especially since my app 
determines the database name, schema, etc. at run time. I use recipientList and 
dynamically generate the "to" jdbc: url.

> JDBC component: Support for multiple resultSets
> ---
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.14.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the jdbc component because it only 
> returns the result set for the first command (set search_path), which is 
> always empty.
> Easiest solution is to provide a uri option to return the last result set 
> instead of the first one. This solution would be preferable to me and would 
> be compatible with streaming. 
> A more complete solution would be an option to return all of the result sets.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-8052) New:

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218104#comment-14218104
 ] 

Camel Guy commented on CAMEL-8052:
--

Awesome! Thanks!

> New: 
> ---
>
> Key: CAMEL-8052
> URL: https://issues.apache.org/jira/browse/CAMEL-8052
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-spring
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
> Fix For: 2.15.0
>
>
>  would have the same attributes and behavior of 
> , except it works on properties instead of headers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-8052) New:

[Camel Guy (JIRA)]

Camel Guy created CAMEL-8052:


 Summary: New: 
 Key: CAMEL-8052
 URL: https://issues.apache.org/jira/browse/CAMEL-8052
 Project: Camel
  Issue Type: New Feature
  Components: camel-spring
Reporter: Camel Guy
Priority: Minor


 would have the same attributes and behavior of 
, except it works on properties instead of headers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7803) DefaultJdbcPrepareStatementStrategy Iterator fails on null value inserts

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205354#comment-14205354
 ] 

Camel Guy commented on CAMEL-7803:
--

I appreciate that this is fixed. I spent the past 48 hours trying to figure 
this out. Eventually I found this JIRA and switched to 2.14.1-SNAPSHOT. When 
will 2.14.1 be released? I'm OK but I thought I would add my two cents about 
the severity of this problem especially for newbies. This was a killer as the 
error message implies that it's user error.

> DefaultJdbcPrepareStatementStrategy Iterator fails on null value inserts
> 
>
> Key: CAMEL-7803
> URL: https://issues.apache.org/jira/browse/CAMEL-7803
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jdbc
>Affects Versions: 2.13.2
>Reporter: Nathan Wray
>Assignee: Willem Jiang
> Fix For: 2.12.5, 2.13.3, 2.14.1, 2.15.0
>
> Attachments: 7803-patch.txt
>
>
> The iterator returned by createPopulateIterator in 
> DefaultJdbcPrepareStatementStrategy incorrectly uses a next value of "null" 
> to identify when it has run out of parameters.  This fails when the parameter 
> map intentionally contains a name with a null value, which is the case when 
> some columns in an insert should be set to null.  The attached pull request 
> adds an explicit preFetch flag and relies on the done flag, avoiding the 
> incorrect overloading of (next==null) to indicate completion.
> The iterator reports "hasNext() == false" when it encounters a map value of 
> null.  This happens when using the map header JDBC_PARAMETERS = 
> "CamelJdbcParameters" to insert null values with a prepared statement.  The 
> Iterator ends prematurely when it reaches a parameter name with a null value. 
>  
> For example, passing in a map where the 3rd parameter of 19 has a value of 
> null causes the following exception to be thrown:
> java.sql.SQLException: Number of parameters mismatch. Expected: 19, was:2
> at 
> org.apache.camel.component.jdbc.DefaultJdbcPrepareStatementStrategy.populateStatement(DefaultJdbcPrepareStatementStrategy.java:137)
> at 
> org.apache.camel.component.jdbc.JdbcProducer.doCreateAndExecuteSqlStatementWithHeaders(JdbcProducer.java:133)
> at 
> org.apache.camel.component.jdbc.JdbcProducer.createAndExecuteSqlStatement(JdbcProducer.java:116)
> at 
> org.apache.camel.component.jdbc.JdbcProducer.processingSqlBySettingAutoCommit(JdbcProducer.java:85)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (CAMEL-6473) NULL values are not supported in named parameters

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-6473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-6473:
-
Comment: was deleted

(was: I appreciate that this is fixed. I spent the past 48 hours trying to 
figure this out. Eventually I found this JIRA and switched to 2.14.1-SNAPSHOT. 
When will 2.14.1 be released? I'm OK but I thought I would add my two cents. 
This was a killer as the error message implies that it's user error.)

> NULL values are not supported in named parameters
> -
>
> Key: CAMEL-6473
> URL: https://issues.apache.org/jira/browse/CAMEL-6473
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 2.11.0
>Reporter: Sergey Galkin
> Fix For: 2.11.1, 2.12.0
>
>
> Due to the bug in the DefaultSqlPrepareStatementStrategy there no ability to 
> use NULL values.
> Following query will be failed, if we try to use NULL  as a parameter value:
> bq. select a, b from foo where (:#param1 IS NOT NULL AND a > 12 ) OR 
> (:#param2 IS NOT NULL AND b > 12)
> We'll get an error: 
> {quote}
> Caused by: java.sql.SQLException: Number of parameters mismatch. Expected: 2, 
> was:1
> at 
> org.apache.camel.component.sql.DefaultSqlPrepareStatementStrategy.populateStatement(DefaultSqlPrepareStatementStrategy.java:132)
>  ~[camel-sql-2.11.0.jar:2.11.0]
>   at 
> org.apache.camel.component.sql.SqlProducer$1.doInPreparedStatement(SqlProducer.java:74)
>  ~[camel-sql-2.11.0.jar:2.11.0]
>   at 
> org.apache.camel.component.sql.SqlProducer$1.doInPreparedStatement(SqlProducer.java:57)
>  ~[camel-sql-2.11.0.jar:2.11.0]
>   at 
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:587) 
> ~[spring-jdbc-3.1.4.RELEASE.jar:3.1.4.RELEASE]
> {quote}
> Fix is quite simple: iterator implementation (returned by 
> DefaultSqlPrepareStatementStrategy.createPopulateIterator()) should be 
> changed as follows:
> {code:java}
> return new Iterator() {
> private NamedQueryParser parser = new 
> NamedQueryParser(query);
> private String nextParam;
> private boolean done;
> @Override
> public boolean hasNext() {
> if (done) {
> return false;
> }
> 
> if (nextParam == null) {
> nextParam = parser.next();
> if (nextParam == null) {
> done = true;
> }
> }
> return nextParam != null;
> }
> @Override
> public Object next() {
> if(!hasNext()){
> throw new NoSuchElementException();
> }
> 
> boolean contains = bodyMap != null ? 
> bodyMap.containsKey(nextParam) : false;
> contains |= headerMap != null ? 
> headerMap.containsKey(nextParam) : false;
> if (!contains) {
> throw new RuntimeExchangeException("Cannot find 
> key [" + nextParam + "] in message body or headers to use when setting named 
> parameter in query [" + query + "]", exchange);
> }
> 
> // get from body before header
> Object next = bodyMap != null ? 
> bodyMap.get(nextParam) : null;
> if (next == null) {
> next = headerMap != null ? 
> headerMap.get(nextParam) : null;
> }
> nextParam = null;
> return next;
> }
> @Override
> public void remove() {
> // noop
> }
> };
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-6473) NULL values are not supported in named parameters

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-6473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14205351#comment-14205351
 ] 

Camel Guy commented on CAMEL-6473:
--

I appreciate that this is fixed. I spent the past 48 hours trying to figure 
this out. Eventually I found this JIRA and switched to 2.14.1-SNAPSHOT. When 
will 2.14.1 be released? I'm OK but I thought I would add my two cents. This 
was a killer as the error message implies that it's user error.

> NULL values are not supported in named parameters
> -
>
> Key: CAMEL-6473
> URL: https://issues.apache.org/jira/browse/CAMEL-6473
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 2.11.0
>Reporter: Sergey Galkin
> Fix For: 2.11.1, 2.12.0
>
>
> Due to the bug in the DefaultSqlPrepareStatementStrategy there no ability to 
> use NULL values.
> Following query will be failed, if we try to use NULL  as a parameter value:
> bq. select a, b from foo where (:#param1 IS NOT NULL AND a > 12 ) OR 
> (:#param2 IS NOT NULL AND b > 12)
> We'll get an error: 
> {quote}
> Caused by: java.sql.SQLException: Number of parameters mismatch. Expected: 2, 
> was:1
> at 
> org.apache.camel.component.sql.DefaultSqlPrepareStatementStrategy.populateStatement(DefaultSqlPrepareStatementStrategy.java:132)
>  ~[camel-sql-2.11.0.jar:2.11.0]
>   at 
> org.apache.camel.component.sql.SqlProducer$1.doInPreparedStatement(SqlProducer.java:74)
>  ~[camel-sql-2.11.0.jar:2.11.0]
>   at 
> org.apache.camel.component.sql.SqlProducer$1.doInPreparedStatement(SqlProducer.java:57)
>  ~[camel-sql-2.11.0.jar:2.11.0]
>   at 
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:587) 
> ~[spring-jdbc-3.1.4.RELEASE.jar:3.1.4.RELEASE]
> {quote}
> Fix is quite simple: iterator implementation (returned by 
> DefaultSqlPrepareStatementStrategy.createPopulateIterator()) should be 
> changed as follows:
> {code:java}
> return new Iterator() {
> private NamedQueryParser parser = new 
> NamedQueryParser(query);
> private String nextParam;
> private boolean done;
> @Override
> public boolean hasNext() {
> if (done) {
> return false;
> }
> 
> if (nextParam == null) {
> nextParam = parser.next();
> if (nextParam == null) {
> done = true;
> }
> }
> return nextParam != null;
> }
> @Override
> public Object next() {
> if(!hasNext()){
> throw new NoSuchElementException();
> }
> 
> boolean contains = bodyMap != null ? 
> bodyMap.containsKey(nextParam) : false;
> contains |= headerMap != null ? 
> headerMap.containsKey(nextParam) : false;
> if (!contains) {
> throw new RuntimeExchangeException("Cannot find 
> key [" + nextParam + "] in message body or headers to use when setting named 
> parameter in query [" + query + "]", exchange);
> }
> 
> // get from body before header
> Object next = bodyMap != null ? 
> bodyMap.get(nextParam) : null;
> if (next == null) {
> next = headerMap != null ? 
> headerMap.get(nextParam) : null;
> }
> nextParam = null;
> return next;
> }
> @Override
> public void remove() {
> // noop
> }
> };
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7904) JDBC component: Support for multiple resultSets

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169599#comment-14169599
 ] 

Camel Guy commented on CAMEL-7904:
--

I just went through the Statement JDBC interface and it appears that there is 
no way to know how many ResultSets will be returned. You have to process each 
ResultSet until there are no more. So my first suggestion won't work.

> JDBC component: Support for multiple resultSets
> ---
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.14.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the jdbc component because it only 
> returns the result set for the first command (set search_path), which is 
> always empty.
> Easiest solution is to provide a uri option to return the last result set 
> instead of the first one. This solution would be preferable to me and would 
> be compatible with streaming. 
> A more complete solution would be an option to return all of the result sets.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7904) JDBC component: Support for multiple resultSets

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169464#comment-14169464
 ] 

Camel Guy commented on CAMEL-7904:
--

See related 
http://stackoverflow.com/questions/11187834/accessing-stored-procedures-multiple-result-sets-in-apache-camel

> JDBC component: Support for multiple resultSets
> ---
>
> Key: CAMEL-7904
> URL: https://issues.apache.org/jira/browse/CAMEL-7904
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.14.0
>Reporter: Camel Guy
>
> For PostgreSQL it is common to run two commands in a single transaction in 
> order to set the schema search path:
> set search_path to foo, public;
> select 5;
> Due to connection pooling it is desirable to combine both statements in a 
> single operation.
> These types of queries don't work with the jdbc component because it only 
> returns the result set for the first command (set search_path), which is 
> always empty.
> Easiest solution is to provide a uri option to return the last result set 
> instead of the first one. This solution would be preferable to me and would 
> be compatible with streaming. 
> A more complete solution would be an option to return all of the result sets.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-7904) JDBC component: Support for multiple resultSets

[Camel Guy (JIRA)]

Camel Guy created CAMEL-7904:


 Summary: JDBC component: Support for multiple resultSets
 Key: CAMEL-7904
 URL: https://issues.apache.org/jira/browse/CAMEL-7904
 Project: Camel
  Issue Type: New Feature
Affects Versions: 2.14.0
Reporter: Camel Guy


For PostgreSQL it is common to run two commands in a single transaction in 
order to set the schema search path:

set search_path to foo, public;
select 5;

Due to connection pooling it is desirable to combine both statements in a 
single operation.

These types of queries don't work with the jdbc component because it only 
returns the result set for the first command (set search_path), which is always 
empty.

Easiest solution is to provide a uri option to return the last result set 
instead of the first one. This solution would be preferable to me and would be 
compatible with streaming. 

A more complete solution would be an option to return all of the result sets.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14144233#comment-14144233
 ] 

Camel Guy edited comment on CAMEL-7849 at 9/23/14 2:49 AM:
---

The Camel documentation for Jasypt reads like the examples work for both ${} 
and {}. It took me about 24 solid working hours to figure this out. This could 
just be a documentation problem. However, the downside is the additional 
CPU/memory overhead caused by loading the same .properties files twice. In my 
code, I load two properties files. Not a huge problem. The real problem is that 
this isn't as easy as it could be.

My use case involves restlet realms. I want to encrypt user passwords. I also 
want to encrypt JDBC passwords. Therefore, I very much need ${} to work.


was (Author: camelguy):
The Camel documentation for Jasypt reads like the examples work for both ${} 
and {}. It took me about 24 solid working hours to figure this out. This could 
just be a documentation problem. However, the downside is the additional 
CPU/memory overhead caused by loading the same .properties files twice. In my 
code, I load two properties files. Not a huge problem. The real problem is that 
this isn't as easy as it should be.

My use case involves restlet realms. I want to encrypt user passwords. I also 
want to encrypt JDBC passwords. Therefore, I very much need ${} to work.

> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following Camel Spring DSL snippet decrypts the 
> property value inside  via {{key}} but does 
> not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, first I remove all of the above. 
> Then I add jasypt dependencies to pom.xml:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> And add the following to Camel Spring DSL:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> This is the only solution that I could discover. Using 
> BridgePropertyPlaceholder 
> didn't work.  must be used inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14144233#comment-14144233
 ] 

Camel Guy edited comment on CAMEL-7849 at 9/23/14 2:49 AM:
---

The Camel documentation for Jasypt reads like the examples work for both ${} 
and {}. It took me about 24 solid working hours to figure this out. This could 
just be a documentation problem. However, the downside is the additional 
CPU/memory overhead caused by loading the same .properties files twice. In my 
code, I load two properties files. Not a huge problem. The real problem is that 
this isn't as easy as it should be.

My use case involves restlet realms. I want to encrypt user passwords. I also 
want to encrypt JDBC passwords. Therefore, I very much need ${} to work.


was (Author: camelguy):
The Camel documentation for Jasypt reads like the examples work for both ${} 
and {}. It took me about 24 solid working hours to figure this out. This could 
just be a documentation problem. However, the downside is the additional 
CPU/memory overhead caused by loading the same .properties files multiple 
times. In my code, I load two properties files. Not a huge problem. The real 
problem is that this isn't as easy as it should be.

My use case involves restlet realms. I want to encrypt user passwords. I also 
want to encrypt JDBC passwords. Therefore, I very much need ${} to work.

> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following Camel Spring DSL snippet decrypts the 
> property value inside  via {{key}} but does 
> not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, first I remove all of the above. 
> Then I add jasypt dependencies to pom.xml:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> And add the following to Camel Spring DSL:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> This is the only solution that I could discover. Using 
> BridgePropertyPlaceholder 
> didn't work.  must be used inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14144233#comment-14144233
 ] 

Camel Guy edited comment on CAMEL-7849 at 9/23/14 2:48 AM:
---

The Camel documentation for Jasypt reads like the examples work for both ${} 
and {}. It took me about 24 solid working hours to figure this out. This could 
just be a documentation problem. However, the downside is the additional 
CPU/memory overhead caused by loading the same .properties files multiple 
times. In my code, I load two properties files. Not a huge problem. The real 
problem is that this isn't as easy as it should be.

My use case involves restlet realms. I want to encrypt user passwords. I also 
want to encrypt JDBC passwords. Therefore, I very much need ${} to work.


was (Author: camelguy):
The Camel documentation for Jasypt reads like the examples work for both ${} 
and {}. It took me about 24 solid working hours to figure this out. This could 
just be a documentation problem. However, the downside is the additional 
CPU/memory overhead caused by loading the same .properties files multiple 
times. In my code, I load two properties files. Not a huge problem. The real 
problem is that this isn't as easy as it should be.

My real use case involves restlet realms. I want to encrypt user passwords. I 
also want to encrypt JDBC passwords. Therefore, I very much need ${} to work.

> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following Camel Spring DSL snippet decrypts the 
> property value inside  via {{key}} but does 
> not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, first I remove all of the above. 
> Then I add jasypt dependencies to pom.xml:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> And add the following to Camel Spring DSL:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> This is the only solution that I could discover. Using 
> BridgePropertyPlaceholder 
> didn't work.  must be used inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14144233#comment-14144233
 ] 

Camel Guy commented on CAMEL-7849:
--

The Camel documentation for Jasypt reads like the examples work for both ${} 
and {}. It took me about 24 solid working hours to figure this out. This could 
just be a documentation problem. However, the downside is the additional 
CPU/memory overhead caused by loading the same .properties files multiple 
times. In my code, I load two properties files. Not a huge problem. The real 
problem is that this isn't as easy as it should be.

My real use case involves restlet realms. I want to encrypt user passwords. I 
also want to encrypt JDBC passwords. Therefore, I very much need ${} to work.

> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following Camel Spring DSL snippet decrypts the 
> property value inside  via {{key}} but does 
> not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, first I remove all of the above. 
> Then I add jasypt dependencies to pom.xml:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> And add the following to Camel Spring DSL:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> This is the only solution that I could discover. Using 
> BridgePropertyPlaceholder 
> didn't work.  must be used inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following Camel Spring DSL snippet decrypts the 
property value inside  via {{key}} but does 
not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, first I remove all of the above. 
Then I add jasypt dependencies to pom.xml:


  org.jasypt
  jasypt
  lite
  1.9.2


 
  org.jasypt
  jasypt-spring3
  1.9.2
  

And add the following to Camel Spring DSL:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

This is the only solution that I could discover. Using 
BridgePropertyPlaceholder 
didn't work.  must be used inside .
{noformat}

  was:
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via \{ \{key\} \} but does not decrypt it outside of the  via 
${key}:


{code}





  
  
classpath:default.properties
  
  


{code}

In order to get ${} to decrypt, I first add jasypt dependencies:

{code}

  org.jasypt
  jasypt
  lite
  1.9.2


 
  org.jasypt
  jasypt-spring3
  1.9.2
  

{code}
Camel Spring DSL looks like:

{code}

   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

{code}

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder 
did not work, so I had to to use  inside .




> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Assignee: Willem Jiang
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following Camel Spring DSL snippet decrypts the 
> property value inside  via {{key}} but does 
> not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, first I remove all of the above. 
> Then I add jasypt dependencies to pom.xml:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> And add the following to Camel Spring DSL:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> This is the only solution that I could discover. Using 
> BridgePropertyPlaceholder 
> didn't work.  must be used inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I first add jasypt dependencies:


  org.jasypt
  jasypt
  lite
  1.9.2


 
  org.jasypt
  jasypt-spring3
  1.9.2
  

Camel Spring DSL looks like:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder 
did not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I first add jasypt dependencies:


  org.jasypt
  jasypt
  lite
  1.9.2


 
  org.jasypt
  jasypt-spring3
  1.9.2
  

Camel Spring DSL looks like:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following decrypts the property value inside  
> via {{key}} but does not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, I first add jasypt dependencies:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> Camel Spring DSL looks like:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder 
> did not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I first add jasypt dependencies:


  org.jasypt
  jasypt
  lite
  1.9.2


 
  org.jasypt
  jasypt-spring3
  1.9.2
  

Camel Spring DSL looks like:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead (in addition to adding 
jasypt 
dependencies to my project POM):

  

org.jasypt
jasypt
lite
1.9.2



  org.jasypt
  jasypt-spring3
  1.9.2
 


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following decrypts the property value inside  
> via {{key}} but does not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, I first add jasypt dependencies:
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
>  
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>   
> Camel Spring DSL looks like:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder did 
> not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead (in addition to adding 
jasypt 
dependencies to my project POM):

  

org.jasypt
jasypt
lite
1.9.2



  org.jasypt
  jasypt-spring3
  1.9.2
 


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead (in addition to adding 
jasypt dependencies to my 
project POM):


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following decrypts the property value inside  
> via {{key}} but does not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, I use this instead (in addition to adding 
> jasypt 
> dependencies to my project POM):
>   
> 
>   org.jasypt
>   jasypt
>   lite
>   1.9.2
> 
> 
>   org.jasypt
>   jasypt-spring3
>   1.9.2
>  
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder did 
> not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead (in addition to adding 
jasypt dependencies to my 
project POM):


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead (in addition to adding 
jasypt dependencies to my 
project POM):


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following decrypts the property value inside  
> via {{key}} but does not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>"org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, I use this instead (in addition to adding 
> jasypt dependencies to my 
> project POM):
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>'org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>"org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder did 
> not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead in addition to adding jasypt 
dependencies to my project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it 
outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead in addition to adding jasypt 
dependencies to my project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following decrypts the property value inside  
> via {{key}} but does not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>  class="org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, I use this instead in addition to adding 
> jasypt dependencies to my project POM:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>  class='org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder did 
> not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead (in addition to adding 
jasypt dependencies to my 
project POM):


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts the property value inside  
via {{key}} but does not decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead in addition to adding jasypt 
dependencies to my project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following decrypts the property value inside  
> via {{key}} but does not decrypt it outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>  class="org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, I use this instead (in addition to adding 
> jasypt dependencies to my 
> project POM):
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>  class='org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder did 
> not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
File default.properties contains and entry like: key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it 
outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead in addition to adding jasypt 
dependencies to my project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
I have a properties file named default.properties that contains and entry like:
key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it 
outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead in addition to adding jasypt 
dependencies to my project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> File default.properties contains and entry like: key=ENC(..)
> The following decrypts correctly inside  via {{key}} but does 
> not decrypt it 
> outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>  class="org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, I use this instead in addition to adding 
> jasypt dependencies to my project POM:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>  class='org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder did 
> not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
File default.properties contains an entry like: key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it 
outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead in addition to adding jasypt 
dependencies to my project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
File default.properties contains and entry like: key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it 
outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead in addition to adding jasypt 
dependencies to my project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> File default.properties contains an entry like: key=ENC(..)
> The following decrypts correctly inside  via {{key}} but does 
> not decrypt it 
> outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>  class="org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, I use this instead in addition to adding 
> jasypt dependencies to my project POM:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>  class='org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder did 
> not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
I have a properties file named default.properties that contains and entry like:
key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it 
outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to decrypt, I use this instead in addition to adding jasypt 
dependencies to my project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
I have a properties file named default.properties that contains and entry like:
key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it 
outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to work properly, I must do this after adding jasypt 
dependencies to my project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> I have a properties file named default.properties that contains and entry 
> like:
> key=ENC(..)
> The following decrypts correctly inside  via {{key}} but does 
> not decrypt it 
> outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>  class="org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to decrypt, I use this instead in addition to adding 
> jasypt dependencies to my project POM:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>  class='org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder did 
> not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
I have a properties file named default.properties that contains and entry like:
key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it 
outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to work properly, I must do this after adding jasypt 
dependencies to my project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
I have a properties file named default.properties that contains and entry like:
key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it 
outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to work properly, I must do this after adding jasypt to my 
project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> I have a properties file named default.properties that contains and entry 
> like:
> key=ENC(..)
> The following decrypts correctly inside  via {{key}} but does 
> not decrypt it 
> outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>  class="org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to work properly, I must do this after adding jasypt 
> dependencies to my project POM:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>  class='org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder did 
> not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7849:
-
Description: 
{noformat}
I have a properties file named default.properties that contains and entry like:
key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it 
outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to work properly, I must do this after adding jasypt to my 
project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did 
not work, so I had to to use  inside .
{noformat}


  was:
{noformat}
I have a properties file named default.properties that contains and entry like:
key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to work properly, I must do this after adding jasypt to my 
project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did not work, so I had to to use 
 inside .
{noformat}



> Encrypted properties inside and outside 
> --
>
> Key: CAMEL-7849
> URL: https://issues.apache.org/jira/browse/CAMEL-7849
> Project: Camel
>  Issue Type: Bug
>Affects Versions: 2.13.2, 2.14.0
>Reporter: Camel Guy
>Priority: Minor
>
> {noformat}
> I have a properties file named default.properties that contains and entry 
> like:
> key=ENC(..)
> The following decrypts correctly inside  via {{key}} but does 
> not decrypt it 
> outside of the  via ${key}:
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
>  class="org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer">
>   
>   
> classpath:default.properties
>   
>   
> 
> In order to get ${} to work properly, I must do this after adding jasypt to 
> my project POM:
>   class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>
>
>  
>class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
>
> 
>  class='org.jasypt.spring3.properties.EncryptablePropertyPlaceholderConfigurer'>
>  
>
>   
> classpath:default.properties
>   
> 
>  class="org.apache.camel.component.jasypt.JasyptPropertiesParser">
> 
> 
> 
> http://camel.apache.org/schema/spring";>
>   propertiesParserRef="jasypt" 
>  location="classpath:default.properties"/> 
> The second example is the only solution I could find. Using 
> BridgePropertyPlaceholder did 
> not work, so I had to to use  inside .
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-7849) Encrypted properties inside and outside

[Camel Guy (JIRA)]

Camel Guy created CAMEL-7849:


 Summary: Encrypted properties inside and outside 
 Key: CAMEL-7849
 URL: https://issues.apache.org/jira/browse/CAMEL-7849
 Project: Camel
  Issue Type: Bug
Affects Versions: 2.14.0, 2.13.2
Reporter: Camel Guy
Priority: Minor


{noformat}
I have a properties file named default.properties that contains and entry like:
key=ENC(..)

The following decrypts correctly inside  via {{key}} but does not 
decrypt it outside of the  via ${key}:






  
  
classpath:default.properties
  
  


In order to get ${} to work properly, I must do this after adding jasypt to my 
project POM:


   
   
 
 
   


 
   
  
classpath:default.properties
  







http://camel.apache.org/schema/spring";>

 

The second example is the only solution I could find. Using 
BridgePropertyPlaceholder did not work, so I had to to use 
 inside .
{noformat}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7811) Does every route that starts with the Direct component have its own thread?

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7811:
-
Description: 
All computing environments must promote decomposition if they are to withstand 
the ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route becomes reused often, and is even copy and 
pasted across camel projects (this happens especially when Spring DSL is used), 
perhaps the functionality should be refactored into a Java class (easy) or a 
Camel component (harder). But that is a different topic. Sometimes route reuse 
is preferred.

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs. I wonder if the Direct component 
could be changed some day to merely be called in-thread without the additional 
overhead.

  was:
All computing environments must promote decomposition if they are to withstand 
the ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route becomes reused often, and is even copy and 
pasted across camel projects (this happens especially when Spring DSL is used), 
perhaps the functionality should be refactored into a Java class (easy) or a 
Camel component (harder). But that is a different topic. Sometimes route reuse 
is preferred.

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs. I wonder if the Direct component 
could be changed some day to merely be called in-thread without all the extra 
overhead.


> Does every route that starts with the Direct component have its own thread?
> ---
>
> Key: CAMEL-7811
> URL: https://issues.apache.org/jira/browse/CAMEL-7811
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Camel Guy
>Priority: Minor
>
> All computing environments must promote decomposition if they are to 
> withstand the ravages of time. It is very convenient in Camel to define 
> routes as subroutines. As a particular route becomes reused often, and is 
> even copy and pasted across camel projects (this happens especially when 
> Spring DSL is used), perhaps the functionality should be refactored into a 
> Java class (easy) or a Camel component (harder). But that is a different 
> topic. Sometimes route reuse is preferred.
> Again, routes are very convenient for encapsulating arbitrarily complex 
> logic. However, the downside to factoring a Camel program into reusable 
> routes is that it appears that one Java thread is dedicated to every route, 
> even when they start with the "Direct" component, which is commonly 
> advertised in Camel literature as being the most efficient way for a route to 
> invoke another.
> If it is true that every route that starts with the Direct component has its 
> own thread, then these routes consume thread resources and are also expensive 
> to invoke because calling across thread boundaries ultimately requires some 
> form of synchronization.
> I may be missing an important aspect of Camel messaging, such as in vs. 
> in/out. I would like see Camel's architects discuss this topic so that I can 
> learn the best way to build complex Camel programs. I wonder if the Direct 
> component could be changed some day to

[jira] [Updated] (CAMEL-7811) Does every route that starts with the Direct component have its own thread?

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7811:
-
Description: 
Computing environments must promote decomposition if they are to withstand the 
ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route becomes reused often, and is even copy and 
pasted across camel projects (this happens especially when Spring DSL is used), 
perhaps the functionality should be refactored into a Java class (easy) or a 
Camel component (harder). But that is a different topic. Sometimes route reuse 
is preferred.

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs. I wonder if the Direct component 
could be changed some day to merely be called in-thread without the additional 
overhead.

  was:
All computing environments must promote decomposition if they are to withstand 
the ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route becomes reused often, and is even copy and 
pasted across camel projects (this happens especially when Spring DSL is used), 
perhaps the functionality should be refactored into a Java class (easy) or a 
Camel component (harder). But that is a different topic. Sometimes route reuse 
is preferred.

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs. I wonder if the Direct component 
could be changed some day to merely be called in-thread without the additional 
overhead.


> Does every route that starts with the Direct component have its own thread?
> ---
>
> Key: CAMEL-7811
> URL: https://issues.apache.org/jira/browse/CAMEL-7811
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Camel Guy
>Priority: Minor
>
> Computing environments must promote decomposition if they are to withstand 
> the ravages of time. It is very convenient in Camel to define routes as 
> subroutines. As a particular route becomes reused often, and is even copy and 
> pasted across camel projects (this happens especially when Spring DSL is 
> used), perhaps the functionality should be refactored into a Java class 
> (easy) or a Camel component (harder). But that is a different topic. 
> Sometimes route reuse is preferred.
> Again, routes are very convenient for encapsulating arbitrarily complex 
> logic. However, the downside to factoring a Camel program into reusable 
> routes is that it appears that one Java thread is dedicated to every route, 
> even when they start with the "Direct" component, which is commonly 
> advertised in Camel literature as being the most efficient way for a route to 
> invoke another.
> If it is true that every route that starts with the Direct component has its 
> own thread, then these routes consume thread resources and are also expensive 
> to invoke because calling across thread boundaries ultimately requires some 
> form of synchronization.
> I may be missing an important aspect of Camel messaging, such as in vs. 
> in/out. I would like see Camel's architects discuss this topic so that I can 
> learn the best way to build complex Camel programs. I wonder if the Direct 
> component could be changed some day to merely

[jira] [Updated] (CAMEL-7811) Does every route that starts with the Direct component have its own thread?

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7811:
-
Description: 
All computing environments must promote decomposition if they are to withstand 
the ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route becomes reused often, and is even copy and 
pasted across camel projects (this happens especially when Spring DSL is used), 
perhaps the functionality should be refactored into a Java class (easy) or a 
Camel component (harder). But that is a different topic. Sometimes route reuse 
is preferred.

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs. I wonder if the Direct component 
could be changed some day to merely be called in-thread without all the extra 
overhead.

  was:
All computing environments must promote decomposition if they are to withstand 
the ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route becomes reused often, and is even copy and 
pasted across camel projects (this happens especially when Spring DSL is used), 
perhaps the functionality should be refactored into a Java class (easy) or a 
Camel component (harder). But that is a different topic. Sometimes route reuse 
is preferred.

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs.


> Does every route that starts with the Direct component have its own thread?
> ---
>
> Key: CAMEL-7811
> URL: https://issues.apache.org/jira/browse/CAMEL-7811
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Camel Guy
>Priority: Minor
>
> All computing environments must promote decomposition if they are to 
> withstand the ravages of time. It is very convenient in Camel to define 
> routes as subroutines. As a particular route becomes reused often, and is 
> even copy and pasted across camel projects (this happens especially when 
> Spring DSL is used), perhaps the functionality should be refactored into a 
> Java class (easy) or a Camel component (harder). But that is a different 
> topic. Sometimes route reuse is preferred.
> Again, routes are very convenient for encapsulating arbitrarily complex 
> logic. However, the downside to factoring a Camel program into reusable 
> routes is that it appears that one Java thread is dedicated to every route, 
> even when they start with the "Direct" component, which is commonly 
> advertised in Camel literature as being the most efficient way for a route to 
> invoke another.
> If it is true that every route that starts with the Direct component has its 
> own thread, then these routes consume thread resources and are also expensive 
> to invoke because calling across thread boundaries ultimately requires some 
> form of synchronization.
> I may be missing an important aspect of Camel messaging, such as in vs. 
> in/out. I would like see Camel's architects discuss this topic so that I can 
> learn the best way to build complex Camel programs. I wonder if the Direct 
> component could be changed some day to merely be called in-thread without all 
> the extra overhead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7811) Does every route that starts with the Direct component have its own thread?

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7811:
-
Description: 
All computing environments must promote decomposition if they are to withstand 
the ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route becomes reused often, and is even copy and 
pasted across camel projects (this happens especially when Spring DSL is used), 
perhaps the functionality should be refactored into a Java class (easy) or a 
Camel component (harder). But that is a different topic. Sometimes route reuse 
is preferred.

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs.

  was:
All computing environments must promote decomposition if they are to withstand 
the ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route is reused considerably and is even copy and 
pasted across camel-based projects (this happens especially when Spring DSL is 
used), perhaps the functionality should be refactored into a Java class (easy) 
or a Camel component (harder). But that is a different subject. 

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs.


> Does every route that starts with the Direct component have its own thread?
> ---
>
> Key: CAMEL-7811
> URL: https://issues.apache.org/jira/browse/CAMEL-7811
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Camel Guy
>Priority: Minor
>
> All computing environments must promote decomposition if they are to 
> withstand the ravages of time. It is very convenient in Camel to define 
> routes as subroutines. As a particular route becomes reused often, and is 
> even copy and pasted across camel projects (this happens especially when 
> Spring DSL is used), perhaps the functionality should be refactored into a 
> Java class (easy) or a Camel component (harder). But that is a different 
> topic. Sometimes route reuse is preferred.
> Again, routes are very convenient for encapsulating arbitrarily complex 
> logic. However, the downside to factoring a Camel program into reusable 
> routes is that it appears that one Java thread is dedicated to every route, 
> even when they start with the "Direct" component, which is commonly 
> advertised in Camel literature as being the most efficient way for a route to 
> invoke another.
> If it is true that every route that starts with the Direct component has its 
> own thread, then these routes consume thread resources and are also expensive 
> to invoke because calling across thread boundaries ultimately requires some 
> form of synchronization.
> I may be missing an important aspect of Camel messaging, such as in vs. 
> in/out. I would like see Camel's architects discuss this topic so that I can 
> learn the best way to build complex Camel programs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-7811) Does every route that starts with the Direct component have its own thread?

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7811:
-
Description: 
All computing environments must promote decomposition if they are to withstand 
the ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route is reused considerably and is even copy and 
pasted across camel-based projects (this happens especially when Spring DSL is 
used), perhaps the functionality should be refactored into a Java class (easy) 
or a Camel component (harder). But that is a different subject. 

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs.

  was:
All programming environments must support decomposition if they are to overcome 
the ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route is reused considerably and is even copy and 
pasted across camel-based projects (this happens especially when Spring DSL is 
used), perhaps the functionality should be refactored into a Java class (easy) 
or a Camel component (harder). But that is a different subject. 

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs.


> Does every route that starts with the Direct component have its own thread?
> ---
>
> Key: CAMEL-7811
> URL: https://issues.apache.org/jira/browse/CAMEL-7811
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Camel Guy
>Priority: Minor
>
> All computing environments must promote decomposition if they are to 
> withstand the ravages of time. It is very convenient in Camel to define 
> routes as subroutines. As a particular route is reused considerably and is 
> even copy and pasted across camel-based projects (this happens especially 
> when Spring DSL is used), perhaps the functionality should be refactored into 
> a Java class (easy) or a Camel component (harder). But that is a different 
> subject. 
> Again, routes are very convenient for encapsulating arbitrarily complex 
> logic. However, the downside to factoring a Camel program into reusable 
> routes is that it appears that one Java thread is dedicated to every route, 
> even when they start with the "Direct" component, which is commonly 
> advertised in Camel literature as being the most efficient way for a route to 
> invoke another.
> If it is true that every route that starts with the Direct component has its 
> own thread, then these routes consume thread resources and are also expensive 
> to invoke because calling across thread boundaries ultimately requires some 
> form of synchronization.
> I may be missing an important aspect of Camel messaging, such as in vs. 
> in/out. I would like see Camel's architects discuss this topic so that I can 
> learn the best way to build complex Camel programs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-7811) Does every route that starts with the Direct component have its own thread?

[Camel Guy (JIRA)]

Camel Guy created CAMEL-7811:


 Summary: Does every route that starts with the Direct component 
have its own thread?
 Key: CAMEL-7811
 URL: https://issues.apache.org/jira/browse/CAMEL-7811
 Project: Camel
  Issue Type: Improvement
  Components: camel-core
Reporter: Camel Guy
Priority: Minor


All programming environments must support decomposition if they are to overcome 
the ravages of time. It is very convenient in Camel to define routes as 
subroutines. As a particular route is reused considerably and is even copy and 
pasted across camel-based projects (this happens especially when Spring DSL is 
used), perhaps the functionality should be refactored into a Java class (easy) 
or a Camel component (harder). But that is a different subject. 

Again, routes are very convenient for encapsulating arbitrarily complex logic. 
However, the downside to factoring a Camel program into reusable routes is that 
it appears that one Java thread is dedicated to every route, even when they 
start with the "Direct" component, which is commonly advertised in Camel 
literature as being the most efficient way for a route to invoke another.

If it is true that every route that starts with the Direct component has its 
own thread, then these routes consume thread resources and are also expensive 
to invoke because calling across thread boundaries ultimately requires some 
form of synchronization.

I may be missing an important aspect of Camel messaging, such as in vs. in/out. 
I would like see Camel's architects discuss this topic so that I can learn the 
best way to build complex Camel programs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-7710) simple: Use standard {{ }} syntax to reference values in properties files

[Camel Guy (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100179#comment-14100179
 ] 

Camel Guy commented on CAMEL-7710:
--

At least groovy works with {{ }} !

> simple: Use standard {{ }} syntax to reference values in properties files
> -
>
> Key: CAMEL-7710
> URL: https://issues.apache.org/jira/browse/CAMEL-7710
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-script
>Reporter: Terris Linenbach
>Assignee: Claus Ibsen
>
> This is not simple:
> ${property.head[depth]} <= ${properties:maxDepth}
> This is:
> ${property.head[depth]} <= {{maxDepth}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CAMEL-7548) Spring XML: Support {{ }} placeholder syntax inside pgp data format

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7548:
-

Description: 
I would like to do this:

{noformat}

  

{noformat}

Property placeholders are apparently not resolved inside  (I tried). 
Naturally, I want to use Jasypt to encrypt the password in the properties file.

  was:
I would like to do this:

{noformat}

  

{noformat}

Property placeholders are not resolved inside . Naturally, I want to use 
Jasypt to encrypt the password in the properties file.


> Spring XML: Support {{ }} placeholder syntax inside pgp data format
> ---
>
> Key: CAMEL-7548
> URL: https://issues.apache.org/jira/browse/CAMEL-7548
> Project: Camel
>  Issue Type: Improvement
>  Components:  camel-crypto
>Affects Versions: 2.13.1
>Reporter: Camel Guy
>Priority: Minor
>
> I would like to do this:
> {noformat}
> 
>   keyUserid="{{user}}" password="{{password}}"/>
> 
> {noformat}
> Property placeholders are apparently not resolved inside  (I tried). 
> Naturally, I want to use Jasypt to encrypt the password in the properties 
> file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CAMEL-7548) Spring XML: Support {{ }} placeholder syntax inside pgp data format

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7548:
-

Component/s:  camel-crypto

> Spring XML: Support {{ }} placeholder syntax inside pgp data format
> ---
>
> Key: CAMEL-7548
> URL: https://issues.apache.org/jira/browse/CAMEL-7548
> Project: Camel
>  Issue Type: Improvement
>  Components:  camel-crypto
>Affects Versions: 2.13.1
>Reporter: Camel Guy
>Priority: Minor
>
> I would like to do this:
> {noformat}
> 
>   keyUserid="{{user}}" password="{{password}}"/>
> 
> {noformat}
> Property placeholders are not resolved inside . Naturally, I want to use 
> Jasypt to encrypt the password in the properties file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CAMEL-7548) Spring XML: Support {{ }} placeholder syntax inside pgp data format

[Camel Guy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-7548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Camel Guy updated CAMEL-7548:
-

Description: 
I would like to do this:

{noformat}

  

{noformat}

Property placeholders are apparently not resolved inside . Naturally, I 
want to use Jasypt to encrypt the password in the properties file.

  was:
I would like to do this:

{noformat}

  

{noformat}

Property placeholders are apparently not resolved inside  (I tried). 
Naturally, I want to use Jasypt to encrypt the password in the properties file.


> Spring XML: Support {{ }} placeholder syntax inside pgp data format
> ---
>
> Key: CAMEL-7548
> URL: https://issues.apache.org/jira/browse/CAMEL-7548
> Project: Camel
>  Issue Type: Improvement
>  Components:  camel-crypto
>Affects Versions: 2.13.1
>Reporter: Camel Guy
>Priority: Minor
>
> I would like to do this:
> {noformat}
> 
>   keyUserid="{{user}}" password="{{password}}"/>
> 
> {noformat}
> Property placeholders are apparently not resolved inside . Naturally, I 
> want to use Jasypt to encrypt the password in the properties file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CAMEL-7548) Spring XML: Support {{ }} placeholder syntax inside pgp data format

[Camel Guy (JIRA)]

Camel Guy created CAMEL-7548:


 Summary: Spring XML: Support {{ }} placeholder syntax inside pgp 
data format
 Key: CAMEL-7548
 URL: https://issues.apache.org/jira/browse/CAMEL-7548
 Project: Camel
  Issue Type: Improvement
Affects Versions: 2.13.1
Reporter: Camel Guy
Priority: Minor


I would like to do this:

{noformat}

  

{noformat}

Property placeholders are not resolved inside . Naturally, I want to use 
Jasypt to encrypt the password in the properties file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)