You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Daniel Kulp (JIRA)" <ji...@apache.org> on 2011/06/22 17:18:49 UTC
[jira] [Created] (CAMEL-4139) Unify blueprint and spring namespace
parsing in camel-cxf
Unify blueprint and spring namespace parsing in camel-cxf
---------------------------------------------------------
Key: CAMEL-4139
URL: https://issues.apache.org/jira/browse/CAMEL-4139
Project: Camel
Issue Type: Improvement
Components: camel-cxf
Reporter: Daniel Kulp
Assignee: Daniel Kulp
Fix For: 2.8.0
Currently, spring parses into a CxfEndpointBean whereas blueprint parses into a CxfEndpoint directly. This mismatch then requires extra casting in the CxfComponent.
Also, it means there are features supported by Spring that are not supported yet by blueprint (like configuring interceptors). I'm attaching a patch that removes the spring specific CxfEndpointBean stuff and allows both spring and blueprint to parse directly into the CxfEndpoint (well, subclasses of) so the two approaches can be maintained together.
It also reduces the usage of "Strings" for properties in CxfEndpoint and uses QNames where appropriate (added a Converter for that) and Class<?> for the service class. That will allow OSGi to provide the Class directly instead of having to Class.forName the thing. (still need to do that, but this is a start)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4139) Unify blueprint and spring namespace
parsing in camel-cxf
Posted by "Edstrom Johan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Edstrom Johan resolved CAMEL-4139.
----------------------------------
Resolution: Fixed
> Unify blueprint and spring namespace parsing in camel-cxf
> ---------------------------------------------------------
>
> Key: CAMEL-4139
> URL: https://issues.apache.org/jira/browse/CAMEL-4139
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
> Reporter: Daniel Kulp
> Assignee: Daniel Kulp
> Fix For: 2.8.0
>
> Attachments: CAMEL-4139.txt, CAMEL-4139b.txt
>
>
> Currently, spring parses into a CxfEndpointBean whereas blueprint parses into a CxfEndpoint directly. This mismatch then requires extra casting in the CxfComponent.
> Also, it means there are features supported by Spring that are not supported yet by blueprint (like configuring interceptors). I'm attaching a patch that removes the spring specific CxfEndpointBean stuff and allows both spring and blueprint to parse directly into the CxfEndpoint (well, subclasses of) so the two approaches can be maintained together.
> It also reduces the usage of "Strings" for properties in CxfEndpoint and uses QNames where appropriate (added a Converter for that) and Class<?> for the service class. That will allow OSGi to provide the Class directly instead of having to Class.forName the thing. (still need to do that, but this is a start)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4139) Unify blueprint and spring namespace
parsing in camel-cxf
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp updated CAMEL-4139:
-------------------------------
Attachment: CAMEL-4139.txt
> Unify blueprint and spring namespace parsing in camel-cxf
> ---------------------------------------------------------
>
> Key: CAMEL-4139
> URL: https://issues.apache.org/jira/browse/CAMEL-4139
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
> Reporter: Daniel Kulp
> Assignee: Daniel Kulp
> Fix For: 2.8.0
>
> Attachments: CAMEL-4139.txt
>
>
> Currently, spring parses into a CxfEndpointBean whereas blueprint parses into a CxfEndpoint directly. This mismatch then requires extra casting in the CxfComponent.
> Also, it means there are features supported by Spring that are not supported yet by blueprint (like configuring interceptors). I'm attaching a patch that removes the spring specific CxfEndpointBean stuff and allows both spring and blueprint to parse directly into the CxfEndpoint (well, subclasses of) so the two approaches can be maintained together.
> It also reduces the usage of "Strings" for properties in CxfEndpoint and uses QNames where appropriate (added a Converter for that) and Class<?> for the service class. That will allow OSGi to provide the Class directly instead of having to Class.forName the thing. (still need to do that, but this is a start)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4139) Unify blueprint and spring
namespace parsing in camel-cxf
Posted by "Willem Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053574#comment-13053574 ]
Willem Jiang commented on CAMEL-4139:
-------------------------------------
Just committed the patch of removing the CxfEndpointBean.java and CxfSpringEndpointBean.java.
> Unify blueprint and spring namespace parsing in camel-cxf
> ---------------------------------------------------------
>
> Key: CAMEL-4139
> URL: https://issues.apache.org/jira/browse/CAMEL-4139
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
> Reporter: Daniel Kulp
> Assignee: Daniel Kulp
> Fix For: 2.8.0
>
> Attachments: CAMEL-4139.txt, CAMEL-4139b.txt
>
>
> Currently, spring parses into a CxfEndpointBean whereas blueprint parses into a CxfEndpoint directly. This mismatch then requires extra casting in the CxfComponent.
> Also, it means there are features supported by Spring that are not supported yet by blueprint (like configuring interceptors). I'm attaching a patch that removes the spring specific CxfEndpointBean stuff and allows both spring and blueprint to parse directly into the CxfEndpoint (well, subclasses of) so the two approaches can be maintained together.
> It also reduces the usage of "Strings" for properties in CxfEndpoint and uses QNames where appropriate (added a Converter for that) and Class<?> for the service class. That will allow OSGi to provide the Class directly instead of having to Class.forName the thing. (still need to do that, but this is a start)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4139) Unify blueprint and spring namespace
parsing in camel-cxf
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp updated CAMEL-4139:
-------------------------------
Attachment: CAMEL-4139b.txt
New version of patch that uses the bundle to load the class.
> Unify blueprint and spring namespace parsing in camel-cxf
> ---------------------------------------------------------
>
> Key: CAMEL-4139
> URL: https://issues.apache.org/jira/browse/CAMEL-4139
> Project: Camel
> Issue Type: Improvement
> Components: camel-cxf
> Reporter: Daniel Kulp
> Assignee: Daniel Kulp
> Fix For: 2.8.0
>
> Attachments: CAMEL-4139.txt, CAMEL-4139b.txt
>
>
> Currently, spring parses into a CxfEndpointBean whereas blueprint parses into a CxfEndpoint directly. This mismatch then requires extra casting in the CxfComponent.
> Also, it means there are features supported by Spring that are not supported yet by blueprint (like configuring interceptors). I'm attaching a patch that removes the spring specific CxfEndpointBean stuff and allows both spring and blueprint to parse directly into the CxfEndpoint (well, subclasses of) so the two approaches can be maintained together.
> It also reduces the usage of "Strings" for properties in CxfEndpoint and uses QNames where appropriate (added a Converter for that) and Class<?> for the service class. That will allow OSGi to provide the Class directly instead of having to Class.forName the thing. (still need to do that, but this is a start)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira