[jira] [Created] (CAMEL-8048) Main overrides context's registry
Alexey Markevich created CAMEL-8048: --- Summary: Main overrides context's registry Key: CAMEL-8048 URL: https://issues.apache.org/jira/browse/CAMEL-8048 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.13.3 Reporter: Alexey Markevich Attachments: camel-core.patch org.apache.camel.main.Main with custom context overrides registry in case bind used -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8048) Main overrides context's registry
[ https://issues.apache.org/jira/browse/CAMEL-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Markevich updated CAMEL-8048: Attachment: camel-core.patch Main overrides context's registry - Key: CAMEL-8048 URL: https://issues.apache.org/jira/browse/CAMEL-8048 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.13.3 Reporter: Alexey Markevich Attachments: camel-core.patch org.apache.camel.main.Main with custom context overrides registry in case bind used -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7999) Camel Toolbox - Easy information about all Camel components and the release for tooling
[ https://issues.apache.org/jira/browse/CAMEL-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7999: --- Description: A Camel release contains many components, and we have the ability to let components document which options they offer. Though there is currently a few shortcomings that can be improved - the component json schema is currently runtime generated, which requires to load the component and create an instance of it. Instead we should build-time generate it, which we do today with the camel apt compiler plugin. *DONE* - we should include documentation about the option from the javadoc, that allows end users to fully document a component using plain java getter/settr with javadocs, and add those @UriParam annotations for the apt compiler to detect and leverage *DONE* - add a module that embeds all these json schema files in a single module, and also other information, such as the xml schemas, and what else can be handy. Then there is a single module as a one stop shop for tooling and whatnot to gather information about a Camel release. There is a new camel-catalog module that contains this now. *DONE* - allow at runtime to explain an endpoint uri what the options in use are, eg as we got the json schema, we can add mbeans that can explain those options, than we can use in tooling, JMX, karaf commands etc. And also IDE editors etc *DONE* - enrich the dsl xml to inject javadoc for the eips into the xml schema, so we have documented in the xsd directly that any tooling can use. We have a old ticket about this. But the apt compiler plugin can detect the @JAXB annotations in the model and extract the javadoc, and generate a json schema with, and then we can load those and enrich into the generated xsd, or enrich into the jaxb model generator, or something. - migrate more Camel components to include javadoc as documentation for their options - figure out how to specify a default value in the json schema. Unfortunately the apt plugin cannot grab that from the source code. So the only solution I can think of now is to add an attribute to the @UriParam where you can specify that, eg this is also what I have seen others do. There is now a defaultValue attribute on UriParam to be used. *DONE* - add component summary to component json file so we have a description of what the component does *DONE* - add attribute to @UriEndpoint to link it to the component class, so we can include the class name of the component in the json schema, which allows Camel to link from component class - schema. eg the point is that if people define a component as activemq we do not know its the jms schema that has its documentation. Though we can infer this by the component class name. And alternative is for a component to have an api to return its original schema name etc. So activemq can say jms etc. We can resolve this by iterating the component data, and find the FQN of the components. *DONE* - add @UriComponent annotation to component class which allows end users to provide meta-data about the component. Currently we grab a summary of what the component does from the maven pom.xml. Though this annotation prepares us for being able to scan the component class as well for which option it provides, so we can have out of the box documentation for that also. - add JMX/Java API to explain a component and also get a tabular data with a list of all components and that data. *DONE* - improve karaf commands to use the component information to show that also *DONE* - add name of karaf feature of the component, eg its 99% came-xxx, but there may be some exceptions. We can likely add a property to the maven plugin that generates component.properties to include the karaf feature name as the artifactId by default. But allow to set a property in the pom.xml in case there is another name, or no karaf feature - add support for @UriPath in apt plugin *DONE* - javadoc documentation is not acessible from components which extend other components (eg javadoc from source code of parent components). For example camel-ftp extending file in camel-core etc. Added description to @UriParam to be used for this purpose. *DONE* - add support for associating label(s) to a endpoint so we can group the various Camel components. A bit like this page: http://camel.apache.org/component-list-grouped.html was: A Camel release contains many components, and we have the ability to let components document which options they offer. Though there is currently a few shortcomings that can be improved - the component json schema is currently runtime generated, which requires to load the component and create an instance of it. Instead we should build-time generate it, which we do today with the camel apt compiler plugin. *DONE* - we should include documentation about the option from the javadoc, that allows end
[jira] [Comment Edited] (CAMEL-7678) Update camel-rabbitmq URI for consumers
[
https://issues.apache.org/jira/browse/CAMEL-7678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14211930#comment-14211930
]
Yap Poh Soon edited comment on CAMEL-7678 at 11/14/14 9:55 AM:
---
I think [~edwardost] is refering to the RabbitMQ's default exchange, where the
default exchange is specify with empty string. I use camel-rabbitmq just two
days ago, and i encounter that i am unable to define a from route with the
rabbitmq default exchange as following:
{quote}
camelContext xmlns=http://camel.apache.org/schema/spring;
route
from uri=rabbitmq://localhost?routingKey=ad_google_dfa_reporting_queue/
{quote}
Following is the Java exception stack
{noformat}
Caused by: java.lang.IllegalArgumentException: No URI path as the exchangeName
for the RabbitMQEndpoint, the URI is
rabbitmq://localhost?routingKey=ad_google_dfa_reporting_queue
at
org.apache.camel.component.rabbitmq.RabbitMQComponent.createEndpoint(RabbitMQComponent.java:50)
at
org.apache.camel.component.rabbitmq.RabbitMQComponent.createEndpoint(RabbitMQComponent.java:31)
at
org.apache.camel.impl.DefaultComponent.createEndpoint(DefaultComponent.java:122)
at
org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:525)
{noformat}
instead, the following is required:
{quote}
from
uri=rabbitmq://localhost/*adserver*?routingKey=ad_google_dfa_reporting_queue/
{quote}
was (Author: reusable):
I think [~edwardost] is refering to the RabbitMQ's default exchange, where the
default exchange is specify with empty string. I use camel-rabbitmq just two
days ago, and i encounter that i am unable to define a from route with the
rabbitmq default exchange as following:
{quote}
camelContext xmlns=http://camel.apache.org/schema/spring;
route
from uri=rabbitmq://localhost/?routingKey=ad_google_dfa_reporting_queue/
{quote}
instead, the following is required:
{quote}
from
uri=rabbitmq://localhost/*adserver*?routingKey=ad_google_dfa_reporting_queue/
{quote}
Update camel-rabbitmq URI for consumers
---
Key: CAMEL-7678
URL: https://issues.apache.org/jira/browse/CAMEL-7678
Project: Camel
Issue Type: Bug
Components: camel-rabbitmq
Affects Versions: 2.13.2
Reporter: Edward Ost
The camel-rabbitmq requires a mandatory amqp exchange as the first parameter
in the URI. Other options are specfied after the ?. This is appropriate
for producers, but not for consumers. Subscribers should specify the queue
name as the first parameter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-8048) Main overrides context's registry
[ https://issues.apache.org/jira/browse/CAMEL-8048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-8048: --- Assignee: Willem Jiang Main overrides context's registry - Key: CAMEL-8048 URL: https://issues.apache.org/jira/browse/CAMEL-8048 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.13.3 Reporter: Alexey Markevich Assignee: Willem Jiang Attachments: camel-core.patch org.apache.camel.main.Main with custom context overrides registry in case bind used -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8031) camel-netty maximumPoolSize option is ignored
[ https://issues.apache.org/jira/browse/CAMEL-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-8031. - Resolution: Fixed Fix Version/s: 2.15.0 Applied the patch into camel master and camel-2.14.x branch. camel-netty maximumPoolSize option is ignored - Key: CAMEL-8031 URL: https://issues.apache.org/jira/browse/CAMEL-8031 Project: Camel Issue Type: Bug Components: camel-netty Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.14.1, 2.15.0 maximumPoolSize endpoint option of the Netty component is effectively ignored. We keep OrderedMemoryAwareThreadPoolExecutor in the NettyComponent#executorService field - it means that we keep, configure and start the executor on the component, not the endpoint level. Netty component is started before the endpoint is created, so NettyComponent#executorService will be always created with the default size (before endpoint will set the pool size on the configuration object). There is a workaround for this issue (changing configuration on the component level), but if we provide maximumPoolSize on the endpoint, then we should respect it. IMHO it is impossible to configure maximumPoolSize at the endpoint level and cache executor instance in the component at the same time. Maybe we should just remove that option from the documentation of the endpoint options as maximumPoolSize should be configured only on the component level? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8049) DefaultRestletBinding can not deal with multi-valued HTTP request parameters
Bojan Tomic created CAMEL-8049:
--
Summary: DefaultRestletBinding can not deal with multi-valued HTTP
request parameters
Key: CAMEL-8049
URL: https://issues.apache.org/jira/browse/CAMEL-8049
Project: Camel
Issue Type: Bug
Components: camel-restlet
Affects Versions: 2.14.0
Reporter: Bojan Tomic
Multi-valued HTTP request parameters are a common practice yet, with the
provided binding, Camel Restlet component can not deal with them.
In DefaultRestletBinding, we can see the following problematic code:
{code}
public void populateRestletRequestFromExchange(Request request, Exchange
exchange) {
...
form.add(key, value.toString());
...
}
{code}
where the value is always treated as a String, even though it can be a
Collection.
And similarly:
{code}
public void populateExchangeFromRestletRequest(Request request, Response
response, Exchange exchange) throws Exception {
...
for (Map.EntryString, String entry : form.getValuesMap().entrySet()) {
...
}
...
}
{code}
where getValuesMap() effectively disregards all duplicate key names.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8049) DefaultRestletBinding can not deal with multi-valued HTTP request parameters
[
https://issues.apache.org/jira/browse/CAMEL-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bojan Tomic updated CAMEL-8049:
---
Attachment: DefaultRestletBinding.patch
A very naive patch...
DefaultRestletBinding can not deal with multi-valued HTTP request parameters
Key: CAMEL-8049
URL: https://issues.apache.org/jira/browse/CAMEL-8049
Project: Camel
Issue Type: Bug
Components: camel-restlet
Affects Versions: 2.14.0
Reporter: Bojan Tomic
Attachments: DefaultRestletBinding.patch
Multi-valued HTTP request parameters are a common practice yet, with the
provided binding, Camel Restlet component can not deal with them.
In DefaultRestletBinding, we can see the following problematic code:
{code}
public void populateRestletRequestFromExchange(Request request, Exchange
exchange) {
...
form.add(key, value.toString());
...
}
{code}
where the value is always treated as a String, even though it can be a
Collection.
And similarly:
{code}
public void populateExchangeFromRestletRequest(Request request, Response
response, Exchange exchange) throws Exception {
...
for (Map.EntryString, String entry : form.getValuesMap().entrySet()) {
...
}
...
}
{code}
where getValuesMap() effectively disregards all duplicate key names.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CAMEL-8049) DefaultRestletBinding can not deal with multi-valued HTTP request parameters
[
https://issues.apache.org/jira/browse/CAMEL-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bojan Tomic updated CAMEL-8049:
---
Comment: was deleted
(was: A very naive patch...)
DefaultRestletBinding can not deal with multi-valued HTTP request parameters
Key: CAMEL-8049
URL: https://issues.apache.org/jira/browse/CAMEL-8049
Project: Camel
Issue Type: Bug
Components: camel-restlet
Affects Versions: 2.14.0
Reporter: Bojan Tomic
Multi-valued HTTP request parameters are a common practice yet, with the
provided binding, Camel Restlet component can not deal with them.
In DefaultRestletBinding, we can see the following problematic code:
{code}
public void populateRestletRequestFromExchange(Request request, Exchange
exchange) {
...
form.add(key, value.toString());
...
}
{code}
where the value is always treated as a String, even though it can be a
Collection.
And similarly:
{code}
public void populateExchangeFromRestletRequest(Request request, Response
response, Exchange exchange) throws Exception {
...
for (Map.EntryString, String entry : form.getValuesMap().entrySet()) {
...
}
...
}
{code}
where getValuesMap() effectively disregards all duplicate key names.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8049) DefaultRestletBinding can not deal with multi-valued HTTP request parameters
[
https://issues.apache.org/jira/browse/CAMEL-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bojan Tomic updated CAMEL-8049:
---
Attachment: (was: DefaultRestletBinding.patch)
DefaultRestletBinding can not deal with multi-valued HTTP request parameters
Key: CAMEL-8049
URL: https://issues.apache.org/jira/browse/CAMEL-8049
Project: Camel
Issue Type: Bug
Components: camel-restlet
Affects Versions: 2.14.0
Reporter: Bojan Tomic
Multi-valued HTTP request parameters are a common practice yet, with the
provided binding, Camel Restlet component can not deal with them.
In DefaultRestletBinding, we can see the following problematic code:
{code}
public void populateRestletRequestFromExchange(Request request, Exchange
exchange) {
...
form.add(key, value.toString());
...
}
{code}
where the value is always treated as a String, even though it can be a
Collection.
And similarly:
{code}
public void populateExchangeFromRestletRequest(Request request, Response
response, Exchange exchange) throws Exception {
...
for (Map.EntryString, String entry : form.getValuesMap().entrySet()) {
...
}
...
}
{code}
where getValuesMap() effectively disregards all duplicate key names.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8049) DefaultRestletBinding can not deal with multi-valued HTTP request parameters
[
https://issues.apache.org/jira/browse/CAMEL-8049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bojan Tomic updated CAMEL-8049:
---
Attachment: DefaultRestletBinding.patch
Supplying a naive patch
DefaultRestletBinding can not deal with multi-valued HTTP request parameters
Key: CAMEL-8049
URL: https://issues.apache.org/jira/browse/CAMEL-8049
Project: Camel
Issue Type: Bug
Components: camel-restlet
Affects Versions: 2.14.0
Reporter: Bojan Tomic
Attachments: DefaultRestletBinding.patch
Multi-valued HTTP request parameters are a common practice yet, with the
provided binding, Camel Restlet component can not deal with them.
In DefaultRestletBinding, we can see the following problematic code:
{code}
public void populateRestletRequestFromExchange(Request request, Exchange
exchange) {
...
form.add(key, value.toString());
...
}
{code}
where the value is always treated as a String, even though it can be a
Collection.
And similarly:
{code}
public void populateExchangeFromRestletRequest(Request request, Response
response, Exchange exchange) throws Exception {
...
for (Map.EntryString, String entry : form.getValuesMap().entrySet()) {
...
}
...
}
{code}
where getValuesMap() effectively disregards all duplicate key names.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8050) Google Calendar component
Jonathan Anstey created CAMEL-8050: -- Summary: Google Calendar component Key: CAMEL-8050 URL: https://issues.apache.org/jira/browse/CAMEL-8050 Project: Camel Issue Type: New Feature Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.15.0 Looking at creating a component for accessing Google's calendar API https://developers.google.com/google-apps/calendar/v3/reference/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8051) feature camel-core does not install in karaf 4
Christian Schneider created CAMEL-8051: -- Summary: feature camel-core does not install in karaf 4 Key: CAMEL-8051 URL: https://issues.apache.org/jira/browse/CAMEL-8051 Project: Camel Issue Type: Bug Components: camel-core, osgi Affects Versions: 2.14.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 2.15.0 feature:repo-add camel 2.15-SNAPSHOT feature:install -v camel-core Karaf then tries to install the karaf shell console from karaf 2.4.0 which of course fails. I first removed the reference to the karaf spring feature repo which transitively imported the karaf standard feature. After that change it could not resolve the package: (org.apache.felix.service.command)(version=0.14.0)(!(version=1.0.0) The problem here was that we forgot status=provisional in the import. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8051) feature camel-core does not install in karaf 4
[ https://issues.apache.org/jira/browse/CAMEL-8051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved CAMEL-8051. Resolution: Fixed feature camel-core does not install in karaf 4 -- Key: CAMEL-8051 URL: https://issues.apache.org/jira/browse/CAMEL-8051 Project: Camel Issue Type: Bug Components: camel-core, osgi Affects Versions: 2.14.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 2.15.0 feature:repo-add camel 2.15-SNAPSHOT feature:install -v camel-core Karaf then tries to install the karaf shell console from karaf 2.4.0 which of course fails. I first removed the reference to the karaf spring feature repo which transitively imported the karaf standard feature. After that change it could not resolve the package: (org.apache.felix.service.command)(version=0.14.0)(!(version=1.0.0) The problem here was that we forgot status=provisional in the import. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8021) Fix Maven surefire warning during build
[ https://issues.apache.org/jira/browse/CAMEL-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14212463#comment-14212463 ] Andrea Cosentino commented on CAMEL-8021: - I'll work on this task. Fix Maven surefire warning during build --- Key: CAMEL-8021 URL: https://issues.apache.org/jira/browse/CAMEL-8021 Project: Camel Issue Type: Task Components: build system Reporter: Claus Ibsen Priority: Minor We get [WARNING] The parameter forkMode is deprecated since version 2.14. Use forkCount and reuseForks instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8052) New: removeProperties
Camel Guy created CAMEL-8052: Summary: New: removeProperties 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 removeProperties would have the same attributes and behavior of removeHeaders, except it works on properties instead of headers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
