[jira] [Commented] (CAMEL-13438) Camel jBPM WorkItemHandler should allow passthrough of Exceptions
[ https://issues.apache.org/jira/browse/CAMEL-13438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822077#comment-16822077 ] Duncan Doyle commented on CAMEL-13438: -- We also need to backport this to 2.23-2 > Camel jBPM WorkItemHandler should allow passthrough of Exceptions > - > > Key: CAMEL-13438 > URL: https://issues.apache.org/jira/browse/CAMEL-13438 > Project: Camel > Issue Type: Bug > Components: camel-jbpm >Affects Versions: 2.23.2, 3.0.0-M2 >Reporter: Duncan Doyle >Assignee: Maciej Swiderski >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the Camel-JBPM WorkItemHandler wraps every exception coming from a > Camel Route into a WorkItemRuntimeException. Although this is a safe way to > handle the exceptions, it's also very inflexible, as we can only return a > single exception type, and thus only react to a single exception type in our > BPMN2 model. > We should add a "HandleExceptions" WIH parameter to indicate whether any > exceptions should be handled by the WorkItemHandler or not. That way, we can > make the Camel Routes responsible for handling the exceptions, which gives us > much greater flexibility wrt error and exception handling. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13437) ThrowExceptionProcessor should use 'getConstructor' instead of 'getDeclaredConstructor', so it doesn't force users to implement the constructors of their exception cla
[
https://issues.apache.org/jira/browse/CAMEL-13437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822075#comment-16822075
]
Duncan Doyle commented on CAMEL-13437:
--
PR: [https://github.com/apache/camel/pull/2876]
> ThrowExceptionProcessor should use 'getConstructor' instead of
> 'getDeclaredConstructor', so it doesn't force users to implement the
> constructors of their exception classes.
>
>
> Key: CAMEL-13437
> URL: https://issues.apache.org/jira/browse/CAMEL-13437
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.23.2
>Reporter: Duncan Doyle
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ThrowExceptionProcessor uses this line of code to retrieve the constructor of
> an Exception class:
> {code:java}
> Constructor constructor = type.getDeclaredConstructor(String.class);{code}
> The problem is that this will only find constructors defined in the actual
> class itself, not in its superclasses. This forces users to unnecessarily
> implement a constructor that excepts a {{String}} in their custom exception
> classes.
> Easy fix, use the following method:
> {code:java}
> Constructor constructor = type.getConstructor(String.class);{code}
> Will fix and create a PR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13438) Camel jBPM WorkItemHandler should allow passthrough of Exceptions
[ https://issues.apache.org/jira/browse/CAMEL-13438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16822061#comment-16822061 ] Duncan Doyle commented on CAMEL-13438: -- PR: [https://github.com/apache/camel/pull/2875] > Camel jBPM WorkItemHandler should allow passthrough of Exceptions > - > > Key: CAMEL-13438 > URL: https://issues.apache.org/jira/browse/CAMEL-13438 > Project: Camel > Issue Type: Bug > Components: camel-jbpm >Affects Versions: 2.23.2, 3.0.0-M2 >Reporter: Duncan Doyle >Assignee: Maciej Swiderski >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, the Camel-JBPM WorkItemHandler wraps every exception coming from a > Camel Route into a WorkItemRuntimeException. Although this is a safe way to > handle the exceptions, it's also very inflexible, as we can only return a > single exception type, and thus only react to a single exception type in our > BPMN2 model. > We should add a "HandleExceptions" WIH parameter to indicate whether any > exceptions should be handled by the WorkItemHandler or not. That way, we can > make the Camel Routes responsible for handling the exceptions, which gives us > much greater flexibility wrt error and exception handling. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13438) Camel jBPM WorkItemHandler should allow passthrough of Exceptions
Duncan Doyle created CAMEL-13438: Summary: Camel jBPM WorkItemHandler should allow passthrough of Exceptions Key: CAMEL-13438 URL: https://issues.apache.org/jira/browse/CAMEL-13438 Project: Camel Issue Type: Bug Components: camel-jbpm Affects Versions: 3.0.0-M2, 2.23.2 Reporter: Duncan Doyle Assignee: Maciej Swiderski Currently, the Camel-JBPM WorkItemHandler wraps every exception coming from a Camel Route into a WorkItemRuntimeException. Although this is a safe way to handle the exceptions, it's also very inflexible, as we can only return a single exception type, and thus only react to a single exception type in our BPMN2 model. We should add a "HandleExceptions" WIH parameter to indicate whether any exceptions should be handled by the WorkItemHandler or not. That way, we can make the Camel Routes responsible for handling the exceptions, which gives us much greater flexibility wrt error and exception handling. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13437) ThrowExceptionProcessor should use 'getConstructor' instead of 'getDeclaredConstructor', so it doesn't force users to implement the constructors of their exception class
[
https://issues.apache.org/jira/browse/CAMEL-13437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Doyle updated CAMEL-13437:
-
Description:
ThrowExceptionProcessor uses this line of code to retrieve the constructor of
an Exception class:
{code:java}
Constructor constructor = type.getDeclaredConstructor(String.class);{code}
The problem is that this will only find constructors defined in the actual
class itself, not in its superclasses. This forces users to unnecessarily
implement a constructor that excepts a {{String}} in their custom exception
classes.
Easy fix, use the following method:
{code:java}
Constructor constructor = type.getConstructor(String.class);{code}
Will fix and create a PR.
was:
ThrowExceptionProcessor uses this line of code to retrieve the constructor of
an Exception class:
{code:java}
Constructor constructor = type.getDeclaredConstructor(String.class);{code}
The problem is that this will only find constructors defined in the actual
class itself, not in its superclasses. This forces users to unnecessarily
implement a constructor that excepts a {{String}} in their custom exception
classes.
Easy fix, use the following method:
{code:java}
Constructor constructor = type.getConstructor(String.class);{code}
> ThrowExceptionProcessor should use 'getConstructor' instead of
> 'getDeclaredConstructor', so it doesn't force users to implement the
> constructors of their exception classes.
>
>
> Key: CAMEL-13437
> URL: https://issues.apache.org/jira/browse/CAMEL-13437
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.23.2
>Reporter: Duncan Doyle
>Priority: Major
>
> ThrowExceptionProcessor uses this line of code to retrieve the constructor of
> an Exception class:
> {code:java}
> Constructor constructor = type.getDeclaredConstructor(String.class);{code}
> The problem is that this will only find constructors defined in the actual
> class itself, not in its superclasses. This forces users to unnecessarily
> implement a constructor that excepts a {{String}} in their custom exception
> classes.
> Easy fix, use the following method:
> {code:java}
> Constructor constructor = type.getConstructor(String.class);{code}
> Will fix and create a PR.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13437) ThrowExceptionProcessor should use 'getConstructor' instead of 'getDeclaredConstructor', so it doesn't force users to implement the constructors of their exception class
Duncan Doyle created CAMEL-13437:
Summary: ThrowExceptionProcessor should use 'getConstructor'
instead of 'getDeclaredConstructor', so it doesn't force users to implement the
constructors of their exception classes.
Key: CAMEL-13437
URL: https://issues.apache.org/jira/browse/CAMEL-13437
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.23.2
Reporter: Duncan Doyle
ThrowExceptionProcessor uses this line of code to retrieve the constructor of
an Exception class:
{code:java}
Constructor constructor = type.getDeclaredConstructor(String.class);{code}
The problem is that this will only find constructors defined in the actual
class itself, not in its superclasses. This forces users to unnecessarily
implement a constructor that excepts a {{String}} in their custom exception
classes.
Easy fix, use the following method:
{code:java}
Constructor constructor = type.getConstructor(String.class);{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13330) Camel JBPM WID definitions contain incorrect WIH classname
Duncan Doyle created CAMEL-13330: Summary: Camel JBPM WID definitions contain incorrect WIH classname Key: CAMEL-13330 URL: https://issues.apache.org/jira/browse/CAMEL-13330 Project: Camel Issue Type: Bug Components: camel-jbpm Affects Versions: 3.0.0-M1, 2.23.1 Reporter: Duncan Doyle Assignee: Maciej Swiderski The .wid files in the camel-jbpm JAR contain incorrect classnames for the InOutCamelConnector and InOnlyCamelConnector, which causes the generated WorkItemHandler configuration in the kie-deployment-descriptor to be incorrect. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13155) Add WidProcessor and Assembly configuration to Maven build to enable integration of WIH with jBPM Service Repository
Duncan Doyle created CAMEL-13155: Summary: Add WidProcessor and Assembly configuration to Maven build to enable integration of WIH with jBPM Service Repository Key: CAMEL-13155 URL: https://issues.apache.org/jira/browse/CAMEL-13155 Project: Camel Issue Type: Improvement Components: camel-jbpm Affects Versions: 2.23.1 Reporter: Duncan Doyle Assignee: Maciej Swiderski The jBPM WorkItems Repository ([https://github.com/kiegroup/jbpm-work-items/tree/master/repository)] allows us to host WorkItem bundles to provide easy access to these components from our designers. This Camel-jBPM component should be bundled in the same way as our other WIHs to enable easy consumer for users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13155) Add WidProcessor and Assembly configuration to Maven build to enable integration of WIH with jBPM Service Repository
[ https://issues.apache.org/jira/browse/CAMEL-13155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759467#comment-16759467 ] Duncan Doyle commented on CAMEL-13155: -- Already have a working confguration. Will create a PR as soon as I have properly tested this ... > Add WidProcessor and Assembly configuration to Maven build to enable > integration of WIH with jBPM Service Repository > > > Key: CAMEL-13155 > URL: https://issues.apache.org/jira/browse/CAMEL-13155 > Project: Camel > Issue Type: Improvement > Components: camel-jbpm >Affects Versions: 2.23.1 >Reporter: Duncan Doyle >Assignee: Maciej Swiderski >Priority: Major > > The jBPM WorkItems Repository > ([https://github.com/kiegroup/jbpm-work-items/tree/master/repository)] allows > us to host WorkItem bundles to provide easy access to these components from > our designers. This Camel-jBPM component should be bundled in the same way as > our other WIHs to enable easy consumer for users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13152) Camel-JBPM KIE-Server extension should use KJAR project classloaded in deployment-scoped CamelContext
[ https://issues.apache.org/jira/browse/CAMEL-13152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Doyle updated CAMEL-13152: - Fix Version/s: 3.0.0 > Camel-JBPM KIE-Server extension should use KJAR project classloaded in > deployment-scoped CamelContext > - > > Key: CAMEL-13152 > URL: https://issues.apache.org/jira/browse/CAMEL-13152 > Project: Camel > Issue Type: Bug > Components: camel-jbpm >Affects Versions: 2.23.1 >Reporter: Duncan Doyle >Assignee: Maciej Swiderski >Priority: Major > Fix For: 3.0.0, 2.23.2 > > > When a camel-route configured in a KJAR deployment reference a class in the > KJAR (for example in an element), you get a > ClassNotFoundException. The problem is that the CamelContext is unable to > find the custom class defined in the KJAR. > We should set the Application CamelContext classloader to the KJAR > classloader for deployment-scoped (KJAR scoped) CamelContext. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13152) Camel-JBPM KIE-Server extension should use KJAR project classloaded in deployment-scoped CamelContext
Duncan Doyle created CAMEL-13152: Summary: Camel-JBPM KIE-Server extension should use KJAR project classloaded in deployment-scoped CamelContext Key: CAMEL-13152 URL: https://issues.apache.org/jira/browse/CAMEL-13152 Project: Camel Issue Type: Bug Components: camel-jbpm Affects Versions: 2.23.1 Reporter: Duncan Doyle Assignee: Maciej Swiderski Fix For: 2.23.2 When a camel-route configured in a KJAR deployment reference a class in the KJAR (for example in an element), you get a ClassNotFoundException. The problem is that the CamelContext is unable to find the custom class defined in the KJAR. We should set the Application CamelContext classloader to the KJAR classloader for deployment-scoped (KJAR scoped) CamelContext. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12978) Add support to configure CamelContext created by KIE-Server extension
Duncan Doyle created CAMEL-12978: Summary: Add support to configure CamelContext created by KIE-Server extension Key: CAMEL-12978 URL: https://issues.apache.org/jira/browse/CAMEL-12978 Project: Camel Issue Type: Improvement Components: camel-jbpm Affects Versions: 2.23.0 Reporter: Duncan Doyle Assignee: Maciej Swiderski To support advanced use-cases, users need to be able to manually build and/or configure the CamelContext provided by the KIE-Server extension. We should add support to allow custom extensions (CamelContext builders) to override the default CamelContext created by KIE-Server to allow advanced configuration of the CamelContetx. The Global CamelContext could be configured through a CamelContextBuilder that is fetched using the ServiceLoader mechanism. For KJAR Deployment scoped configuration, we should allow configuring the CamelContextBuilder through the KJAR's DeploymentDescriptor (e.g. EnvironmentEntries). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12977) Add support for loading of camel-rest DSL in KIE-Server CamelContext
Duncan Doyle created CAMEL-12977: Summary: Add support for loading of camel-rest DSL in KIE-Server CamelContext Key: CAMEL-12977 URL: https://issues.apache.org/jira/browse/CAMEL-12977 Project: Camel Issue Type: Improvement Components: camel-jbpm Affects Versions: 2.23.0 Reporter: Duncan Doyle Assignee: Maciej Swiderski The current CamelContext created by the KIE-Server extension only supports the configuration of routes through RoutesDefinition XML file. We should also support loading RESTDefinitions through a RestsDefinitions XML file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12973) AbstractCamelWorkItemHandler init fails when WIH is loaded before CamelContext is created.
Duncan Doyle created CAMEL-12973: Summary: AbstractCamelWorkItemHandler init fails when WIH is loaded before CamelContext is created. Key: CAMEL-12973 URL: https://issues.apache.org/jira/browse/CAMEL-12973 Project: Camel Issue Type: Bug Components: camel-jbpm Affects Versions: 2.23.1 Reporter: Duncan Doyle Assignee: Maciej Swiderski When the AbstractCamelWorkItemHandler is created before the referenced CamelContext is created and registered, deployment of a KJAR fails with an IllegalArgumentException. This can happen when the deployment uses a combination of a Singleton RuntimeStrategy and a Deployment-scoped CamelContext. This is due to the fact that the jBPM KIE-Server extension runs after the jBPM extension. In such a situation we need to defer the creation of the ProducerTemplate until the first call to WIH.execute. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12964) Create new CamelWIH to integrate with recently added Camel support in jBPM/KIE-Server
Duncan Doyle created CAMEL-12964: Summary: Create new CamelWIH to integrate with recently added Camel support in jBPM/KIE-Server Key: CAMEL-12964 URL: https://issues.apache.org/jira/browse/CAMEL-12964 Project: Camel Issue Type: New Feature Components: camel-jbpm Affects Versions: 2.23.0 Reporter: Duncan Doyle Assignee: Maciej Swiderski The new camel-jbpm component allows CamelContexts and Routes to be defined on both a global (KIE-Server) and runtimeManager/deploymentUnit/KJAR level. A new CamelWorkItemHandler that integrates with these CamelContexts and routes would allow easy integration with external resources throuch Camel Components from within a process/case definition. See: https://issues.jboss.org/browse/JBPM-7995 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12959) Container specific context is not registered in jBPM Camel KIE-Server Extension
Duncan Doyle created CAMEL-12959: Summary: Container specific context is not registered in jBPM Camel KIE-Server Extension Key: CAMEL-12959 URL: https://issues.apache.org/jira/browse/CAMEL-12959 Project: Camel Issue Type: Bug Components: camel-jbpm Affects Versions: 2.23.0 Reporter: Duncan Doyle Assignee: Maciej Swiderski See this line [https://github.com/apache/camel/blob/master/components/camel-jbpm/src/main/java/org/apache/camel/component/jbpm/server/CamelKieServerExtension.java#L120] Instead of registering the container specific "context" DefaultCamelContext, the "this.camel" DefaultCamelContext (the global CamelContext of the KIE-Server extension) is registered. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-7942) Support Oauth, Ouath2 & OpenID client to request token
[ https://issues.apache.org/jira/browse/CAMEL-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440498#comment-16440498 ] Duncan Doyle commented on CAMEL-7942: - I would probably have a look at Keycloak client adapters: https://www.keycloak.org > Support Oauth, Ouath2 & OpenID client to request token > -- > > Key: CAMEL-7942 > URL: https://issues.apache.org/jira/browse/CAMEL-7942 > Project: Camel > Issue Type: New Feature >Reporter: Charles Moulliard >Priority: Major > > Apache Camel does not provide any security layer to support OAuth, OAuth2 or > OpenID specifications to obtain a token, refresh it and maintain the existing > tokens in a cache. > Such a security layer should be interesting for the camel-cxf, camel-jetty, > camel-http, REST DSL components ... > The Apache OLTU project (https://oltu.apache.org/) could be used to support > OAuth, OAuth2 and OpenID4java (https://code.google.com/p/openid4java/) for > OpenID -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-7942) Support Oauth, Ouath2 OpenID client to request token
[ https://issues.apache.org/jira/browse/CAMEL-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14501215#comment-14501215 ] Duncan Doyle edited comment on CAMEL-7942 at 4/18/15 9:31 AM: -- I've recently created a Camel-based app (for a demo) that integrates with Facebook using OAuth2, based on OLTU. I can try to create an initial component, based on the camel-gae (gauth) component. was (Author: ddoyle): I've recently created a Camel-based app (for a demo) that integrates with Facebook using OAuth2, based on OLTU. I can try to create an initial component, based on the camel-age (gauth) component. Support Oauth, Ouath2 OpenID client to request token -- Key: CAMEL-7942 URL: https://issues.apache.org/jira/browse/CAMEL-7942 Project: Camel Issue Type: New Feature Reporter: Charles Moulliard Apache Camel does not provide any security layer to support OAuth, OAuth2 or OpenID specifications to obtain a token, refresh it and maintain the existing tokens in a cache. Such a security layer should be interesting for the camel-cxf, camel-jetty, camel-http, REST DSL components ... The Apache OLTU project (https://oltu.apache.org/) could be used to support OAuth, OAuth2 and OpenID4java (https://code.google.com/p/openid4java/) for OpenID -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7942) Support Oauth, Ouath2 OpenID client to request token
[ https://issues.apache.org/jira/browse/CAMEL-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14501215#comment-14501215 ] Duncan Doyle commented on CAMEL-7942: - I've recently created a Camel-based app (for a demo) that integrates with Facebook using OAuth2, based on OLTU. I can try to create an initial component, based on the camel-age (gauth) component. Support Oauth, Ouath2 OpenID client to request token -- Key: CAMEL-7942 URL: https://issues.apache.org/jira/browse/CAMEL-7942 Project: Camel Issue Type: New Feature Reporter: Charles Moulliard Apache Camel does not provide any security layer to support OAuth, OAuth2 or OpenID specifications to obtain a token, refresh it and maintain the existing tokens in a cache. Such a security layer should be interesting for the camel-cxf, camel-jetty, camel-http, REST DSL components ... The Apache OLTU project (https://oltu.apache.org/) could be used to support OAuth, OAuth2 and OpenID4java (https://code.google.com/p/openid4java/) for OpenID -- This message was sent by Atlassian JIRA (v6.3.4#6332)
