[jira] [Updated] (CAMEL-7157) Marshalling list of POJOs to a fixed length format
[ https://issues.apache.org/jira/browse/CAMEL-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail updated CAMEL-7157: --- Description: Hello guys! I faced an issue while trying to marshal a list of annotated POJOs to an OutPutStream using org.apache.camel.dataformat.bindy.fixed.BindyFixedLengthDataFormat . The cause of the issue is that if the processing body is of type java.util.List, then the BindyFixedLengthDataFormat expects the elements of the list to be of type MapString, Object but they are really not and as a result java.lang.ClassCastException exception is thrown. Please see attached junit tests. was: Hello guys! I faced an issue while trying to marshal list of annotated POJOs to an OutPutStream using org.apache.camel.dataformat.bindy.fixed.BindyFixedLengthDataFormat . The cause of the issue is that if the processing body is of type java.util.List, then the BindyFixedLengthDataFormat expects the elements of the list to be of type MapString, Object but they are really not and as a result java.lang.ClassCastException exception is thrown. Please see attached junit tests. Marshalling list of POJOs to a fixed length format -- Key: CAMEL-7157 URL: https://issues.apache.org/jira/browse/CAMEL-7157 Project: Camel Issue Type: Bug Components: camel-bindy Affects Versions: 2.12.2 Reporter: Mikhail Attachments: bindy.7z Hello guys! I faced an issue while trying to marshal a list of annotated POJOs to an OutPutStream using org.apache.camel.dataformat.bindy.fixed.BindyFixedLengthDataFormat . The cause of the issue is that if the processing body is of type java.util.List, then the BindyFixedLengthDataFormat expects the elements of the list to be of type MapString, Object but they are really not and as a result java.lang.ClassCastException exception is thrown. Please see attached junit tests. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CAMEL-7157) Marshalling list of POJOs to a fixed length format
Mikhail created CAMEL-7157: -- Summary: Marshalling list of POJOs to a fixed length format Key: CAMEL-7157 URL: https://issues.apache.org/jira/browse/CAMEL-7157 Project: Camel Issue Type: Bug Components: camel-bindy Affects Versions: 2.12.2 Reporter: Mikhail Attachments: bindy.7z Hello guys! I faced an issue while trying to marshal list of annotated POJOs to an OutPutStream using org.apache.camel.dataformat.bindy.fixed.BindyFixedLengthDataFormat . The cause of the issue is that if the processing body is of type java.util.List, then the BindyFixedLengthDataFormat expects the elements of the list to be of type MapString, Object but they are really not and as a result java.lang.ClassCastException exception is thrown. Please see attached junit tests. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CAMEL-7157) Marshalling list of POJOs to a fixed length format
[ https://issues.apache.org/jira/browse/CAMEL-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail updated CAMEL-7157: --- Attachment: bindy.7z junit test with the issue Marshalling list of POJOs to a fixed length format -- Key: CAMEL-7157 URL: https://issues.apache.org/jira/browse/CAMEL-7157 Project: Camel Issue Type: Bug Components: camel-bindy Affects Versions: 2.12.2 Reporter: Mikhail Attachments: bindy.7z Hello guys! I faced an issue while trying to marshal list of annotated POJOs to an OutPutStream using org.apache.camel.dataformat.bindy.fixed.BindyFixedLengthDataFormat . The cause of the issue is that if the processing body is of type java.util.List, then the BindyFixedLengthDataFormat expects the elements of the list to be of type MapString, Object but they are really not and as a result java.lang.ClassCastException exception is thrown. Please see attached junit tests. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CAMEL-7143) camel-groovy - Evaluation returns 1st result only
[ https://issues.apache.org/jira/browse/CAMEL-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13887783#comment-13887783 ] Claus Ibsen commented on CAMEL-7143: Thanks for the test case which reproduces the issue camel-groovy - Evaluation returns 1st result only - Key: CAMEL-7143 URL: https://issues.apache.org/jira/browse/CAMEL-7143 Project: Camel Issue Type: Bug Components: camel-groovy Affects Versions: 2.11.2, 2.12.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.11.4, 2.12.3, 2.13.0 Attachments: groovy-test.zip Seems like we have another issue reported which we couldn't reproduce. But maybe this time we can. Issue at SO http://stackoverflow.com/questions/21221085/strange-behaiour-with-camel-groovy-spring-dsl -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CAMEL-7159) camel-bindy not picking up @Link annotation items
Jonathan Anstey created CAMEL-7159: -- Summary: camel-bindy not picking up @Link annotation items Key: CAMEL-7159 URL: https://issues.apache.org/jira/browse/CAMEL-7159 Project: Camel Issue Type: Bug Affects Versions: 2.12.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey It works fine (like in the tests) when you provide bindy with a MapString, Object of model objects corresponding to the @Linked-ed classes. We should do better though and try to figure this out for users. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CAMEL-7159) camel-bindy not picking up @Link annotation items
[ https://issues.apache.org/jira/browse/CAMEL-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey updated CAMEL-7159: --- Fix Version/s: 2.13.0 2.12.3 2.11.4 camel-bindy not picking up @Link annotation items - Key: CAMEL-7159 URL: https://issues.apache.org/jira/browse/CAMEL-7159 Project: Camel Issue Type: Bug Affects Versions: 2.12.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.11.4, 2.12.3, 2.13.0 It works fine (like in the tests) when you provide bindy with a MapString, Object of model objects corresponding to the @Linked-ed classes. We should do better though and try to figure this out for users. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CAMEL-7143) camel-groovy - Evaluation returns 1st result only
[ https://issues.apache.org/jira/browse/CAMEL-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13887874#comment-13887874 ] Claus Ibsen commented on CAMEL-7143: Okay have a fix for this, and will backport this to branches shortly. camel-groovy - Evaluation returns 1st result only - Key: CAMEL-7143 URL: https://issues.apache.org/jira/browse/CAMEL-7143 Project: Camel Issue Type: Bug Components: camel-script Affects Versions: 2.11.2, 2.12.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.11.4, 2.12.3, 2.13.0 Attachments: groovy-test.zip Seems like we have another issue reported which we couldn't reproduce. But maybe this time we can. Issue at SO http://stackoverflow.com/questions/21221085/strange-behaiour-with-camel-groovy-spring-dsl -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CAMEL-7143) camel-groovy - Evaluation returns 1st result only
[ https://issues.apache.org/jira/browse/CAMEL-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7143: --- Component/s: (was: camel-groovy) camel-script The problem is in camel-script camel-groovy - Evaluation returns 1st result only - Key: CAMEL-7143 URL: https://issues.apache.org/jira/browse/CAMEL-7143 Project: Camel Issue Type: Bug Components: camel-script Affects Versions: 2.11.2, 2.12.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.11.4, 2.12.3, 2.13.0 Attachments: groovy-test.zip Seems like we have another issue reported which we couldn't reproduce. But maybe this time we can. Issue at SO http://stackoverflow.com/questions/21221085/strange-behaiour-with-camel-groovy-spring-dsl -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CAMEL-6988) 2.12.1 caches groovy call - resulting with previous caller state
[
https://issues.apache.org/jira/browse/CAMEL-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-6988:
--
Assignee: Claus Ibsen
2.12.1 caches groovy call - resulting with previous caller state
Key: CAMEL-6988
URL: https://issues.apache.org/jira/browse/CAMEL-6988
Project: Camel
Issue Type: Bug
Components: camel-groovy
Affects Versions: 2.12.1
Environment: same results using java 7 on osx, ubuntu, and windoze
Reporter: Terry Walters
Assignee: Claus Ibsen
2.12.1
Works
{code}
simple${body.subOrderName}Endpoint/simple
{code}
Fails
{code}
groovy${request.body.subOrderName}Endpoint/groovy
{code}
2.11.1
Works
{code}
simple${body.subOrderName}Endpoint/simple
{code}
Works
{code}
groovy${request.body.subOrderName}Endpoint/groovy
{code}
*Fails by returning a previous calls result for subOrderName.
To reproduce you must make several calls in a timely manner with different
bean data (OGNL/subOrderName).
Route:
{code}
...
setHeader headerName=RSSX_ORDER_ROUTING_SLIP
groovyreturn ${request.body.subOrderName}Endpoint/groovy
/setHeader
!-- Route the order by the routing slip header --
routingSlip
headerRSSX_ORDER_ROUTING_SLIP/header
/routingSlip
...
{code}
Log:
1st execution
Before set header:UpdatePortIn
After set header: RSSX_ORDER_ROUTING_SLIP=UpdatePortInEndpoint
2nd execution (in a timely manner – exposing a LRU Cache issue?)
Before set header: ResellerAddSubscriberPortIn
After set header:RSSX_ORDER_ROUTING_SLIP=UpdatePortInEndpoint
Same logic works in 2.11.1
Additionally this does not appear OGNL related:
I just ran into the case where
{code}
setHeader headerName=RSSX_ORDER_ROUTING_SLIP
groovy${request.body.getSubOrderName()}Endpoint/groovy
/setHeader
{code}
returns the cached subOrderName from the previous transaction
So this appears to be isolated to the groovy component changes (LRU Cache?)
that were introduced in 2.12.1
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CAMEL-6988) 2.12.1 caches groovy call - resulting with previous caller state
[
https://issues.apache.org/jira/browse/CAMEL-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13887877#comment-13887877
]
Claus Ibsen commented on CAMEL-6988:
CAMEL-7143 fixes this.
2.12.1 caches groovy call - resulting with previous caller state
Key: CAMEL-6988
URL: https://issues.apache.org/jira/browse/CAMEL-6988
Project: Camel
Issue Type: Bug
Components: camel-groovy
Affects Versions: 2.12.1
Environment: same results using java 7 on osx, ubuntu, and windoze
Reporter: Terry Walters
Assignee: Claus Ibsen
Fix For: 2.11.4, 2.12.3, 2.13.0
2.12.1
Works
{code}
simple${body.subOrderName}Endpoint/simple
{code}
Fails
{code}
groovy${request.body.subOrderName}Endpoint/groovy
{code}
2.11.1
Works
{code}
simple${body.subOrderName}Endpoint/simple
{code}
Works
{code}
groovy${request.body.subOrderName}Endpoint/groovy
{code}
*Fails by returning a previous calls result for subOrderName.
To reproduce you must make several calls in a timely manner with different
bean data (OGNL/subOrderName).
Route:
{code}
...
setHeader headerName=RSSX_ORDER_ROUTING_SLIP
groovyreturn ${request.body.subOrderName}Endpoint/groovy
/setHeader
!-- Route the order by the routing slip header --
routingSlip
headerRSSX_ORDER_ROUTING_SLIP/header
/routingSlip
...
{code}
Log:
1st execution
Before set header:UpdatePortIn
After set header: RSSX_ORDER_ROUTING_SLIP=UpdatePortInEndpoint
2nd execution (in a timely manner – exposing a LRU Cache issue?)
Before set header: ResellerAddSubscriberPortIn
After set header:RSSX_ORDER_ROUTING_SLIP=UpdatePortInEndpoint
Same logic works in 2.11.1
Additionally this does not appear OGNL related:
I just ran into the case where
{code}
setHeader headerName=RSSX_ORDER_ROUTING_SLIP
groovy${request.body.getSubOrderName()}Endpoint/groovy
/setHeader
{code}
returns the cached subOrderName from the previous transaction
So this appears to be isolated to the groovy component changes (LRU Cache?)
that were introduced in 2.12.1
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CAMEL-6988) 2.12.1 caches groovy call - resulting with previous caller state
[
https://issues.apache.org/jira/browse/CAMEL-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-6988.
Resolution: Fixed
Fix Version/s: 2.13.0
2.12.3
2.11.4
2.12.1 caches groovy call - resulting with previous caller state
Key: CAMEL-6988
URL: https://issues.apache.org/jira/browse/CAMEL-6988
Project: Camel
Issue Type: Bug
Components: camel-groovy
Affects Versions: 2.12.1
Environment: same results using java 7 on osx, ubuntu, and windoze
Reporter: Terry Walters
Assignee: Claus Ibsen
Fix For: 2.11.4, 2.12.3, 2.13.0
2.12.1
Works
{code}
simple${body.subOrderName}Endpoint/simple
{code}
Fails
{code}
groovy${request.body.subOrderName}Endpoint/groovy
{code}
2.11.1
Works
{code}
simple${body.subOrderName}Endpoint/simple
{code}
Works
{code}
groovy${request.body.subOrderName}Endpoint/groovy
{code}
*Fails by returning a previous calls result for subOrderName.
To reproduce you must make several calls in a timely manner with different
bean data (OGNL/subOrderName).
Route:
{code}
...
setHeader headerName=RSSX_ORDER_ROUTING_SLIP
groovyreturn ${request.body.subOrderName}Endpoint/groovy
/setHeader
!-- Route the order by the routing slip header --
routingSlip
headerRSSX_ORDER_ROUTING_SLIP/header
/routingSlip
...
{code}
Log:
1st execution
Before set header:UpdatePortIn
After set header: RSSX_ORDER_ROUTING_SLIP=UpdatePortInEndpoint
2nd execution (in a timely manner – exposing a LRU Cache issue?)
Before set header: ResellerAddSubscriberPortIn
After set header:RSSX_ORDER_ROUTING_SLIP=UpdatePortInEndpoint
Same logic works in 2.11.1
Additionally this does not appear OGNL related:
I just ran into the case where
{code}
setHeader headerName=RSSX_ORDER_ROUTING_SLIP
groovy${request.body.getSubOrderName()}Endpoint/groovy
/setHeader
{code}
returns the cached subOrderName from the previous transaction
So this appears to be isolated to the groovy component changes (LRU Cache?)
that were introduced in 2.12.1
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CAMEL-7143) camel-groovy - Evaluation returns 1st result only
[ https://issues.apache.org/jira/browse/CAMEL-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7143. Resolution: Fixed camel-groovy - Evaluation returns 1st result only - Key: CAMEL-7143 URL: https://issues.apache.org/jira/browse/CAMEL-7143 Project: Camel Issue Type: Bug Components: camel-script Affects Versions: 2.11.2, 2.12.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.11.4, 2.12.3, 2.13.0 Attachments: groovy-test.zip Seems like we have another issue reported which we couldn't reproduce. But maybe this time we can. Issue at SO http://stackoverflow.com/questions/21221085/strange-behaiour-with-camel-groovy-spring-dsl -- This message was sent by Atlassian JIRA (v6.1.5#6160)
