[
https://issues.apache.org/jira/browse/CAMEL-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14639382#comment-14639382
]
Chris Pimlott commented on CAMEL-9002:
--------------------------------------
A Map for additional variables would be just fine. I'm picturing a new header
{{CamelVelocityAdditionalContext}}, {{CamelVelocitySupplementaryContext}} or
something like that.
I'm not certain what you mean about the last question. There would be
different variables to pre-populate depending both on the type of email and the
message data type. The values would differ depending on the message contents.
e.g. one notification route splits request messages by part and one by client,
so they have different boilerplate:
{code}
#set( $part = $body )
#set( $request = $part.request )
...
{code}
{code}
#set( $client = $body )
#set( $request = $client.parts[0].request )
...
{code}
> Headers set within velocity header are not saved when using custom
> VelocityContext
> ----------------------------------------------------------------------------------
>
> Key: CAMEL-9002
> URL: https://issues.apache.org/jira/browse/CAMEL-9002
> Project: Camel
> Issue Type: Bug
> Affects Versions: 2.15.2
> Reporter: Chris Pimlott
> Priority: Minor
> Attachments: VelocityContextHeaderSetHeaderTest.java
>
>
> Normally, any headers set within the velocity header are preserved as headers
> on the out message. However, this does not work if you use your own
> VelocityContext via the CamelVelocityContext. This is because
> VelocityEndpoint relies on the fact that the "headers" entry in the velocity
> context normally points directly to the current Exchange's in headers. This
> is not likely true when using an existing velocity context.
> A more foolproof solution might be to look for and explicitly copy any
> updated headers from the velocity context to the out message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
