[jira] [Assigned] (CAMEL-8039) Implement halfOpen state in CircuitBreaker
[ https://issues.apache.org/jira/browse/CAMEL-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-8039: --- Assignee: Willem Jiang Implement halfOpen state in CircuitBreaker -- Key: CAMEL-8039 URL: https://issues.apache.org/jira/browse/CAMEL-8039 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Matteo Pavesi Assignee: Willem Jiang Priority: Trivial Fix For: 2.14.1 Attachments: 0001-halfOpen-state-in-CircuitBreaker.patch The CircuitBreaker EIP described in ReleaseIt! has an halfOpen state. It means that after the halfOpen time timeout, the circuitBreaker is accepting one more exchange and it close the circuit only if the processor succeeds. This is not implemented in Camel, I would like to propose the attached patch with code and test for implementing the HalfOpen state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8041) Camel commands - Make the commands reusable
[ https://issues.apache.org/jira/browse/CAMEL-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8041. Resolution: Fixed Camel commands - Make the commands reusable --- Key: CAMEL-8041 URL: https://issues.apache.org/jira/browse/CAMEL-8041 Project: Camel Issue Type: New Feature Components: tooling Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.15.0 The current Camel commands are Karaf implemented only. But we can make that pluggable so we have a core command module with the generic implementation, and then a plugin for when running in karaf. We can then provider other plugins for other environments, such as a jolokia based that works with JVMs that has jolokia agent installed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8044) Camel commands - Make CamelController useable for remote JVMs
Claus Ibsen created CAMEL-8044: -- Summary: Camel commands - Make CamelController useable for remote JVMs Key: CAMEL-8044 URL: https://issues.apache.org/jira/browse/CAMEL-8044 Project: Camel Issue Type: Sub-task Components: tooling Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.15.0 The org.apache.camel.commands.CamelController which is used by the Camel commands to get the data, are currently tied to a local JVM only. We should make this support remoting so the commands can be used to control any JVMs with Camel whether that is local or remote. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7998) Support connection less udp sending
[ https://issues.apache.org/jira/browse/CAMEL-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14209596#comment-14209596 ] ASF GitHub Bot commented on CAMEL-7998: --- Github user asfgit closed the pull request at: https://github.com/apache/camel/pull/318 Support connection less udp sending --- Key: CAMEL-7998 URL: https://issues.apache.org/jira/browse/CAMEL-7998 Project: Camel Issue Type: New Feature Components: camel-netty4 Affects Versions: 2.14.0 Reporter: Thomas Termin Assignee: Willem Jiang An config parameter should be added to support connection less udp sending which is a real fire and forget. A connected udp send receive the PortUnreachableException if no one is listen on the receiving port. That might on some circumstances not what is expected e.g. sending a lot of data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8045) Not possible to load a public key from a a PrivateKeyEntry in a keystore
Colm O hEigeartaigh created CAMEL-8045: -- Summary: Not possible to load a public key from a a PrivateKeyEntry in a keystore Key: CAMEL-8045 URL: https://issues.apache.org/jira/browse/CAMEL-8045 Project: Camel Issue Type: Bug Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Priority: Minor Fix For: 2.14.1, 2.15.0, 2.13.4 It's not possible to retrieve a certificate/public-key for encryption in the camel-xmlsecurity component, if the certificate in question is stored in a PrivateKeyEntry in the keystore. This is because the truststore password is incorrectly used (instead of the keyPassword) to retrieve the key. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8045) Not possible to load a public key from a a PrivateKeyEntry in a keystore
[ https://issues.apache.org/jira/browse/CAMEL-8045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CAMEL-8045. Resolution: Fixed Not possible to load a public key from a a PrivateKeyEntry in a keystore Key: CAMEL-8045 URL: https://issues.apache.org/jira/browse/CAMEL-8045 Project: Camel Issue Type: Bug Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Priority: Minor Fix For: 2.14.1, 2.15.0, 2.13.4 It's not possible to retrieve a certificate/public-key for encryption in the camel-xmlsecurity component, if the certificate in question is stored in a PrivateKeyEntry in the keystore. This is because the truststore password is incorrectly used (instead of the keyPassword) to retrieve the key. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8039) Implement halfOpen state in CircuitBreaker
[ https://issues.apache.org/jira/browse/CAMEL-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-8039. - Resolution: Fixed Fix Version/s: (was: 2.14.1) 2.15.0 Applied the patch into camel master branch with thanks to Matteo. Implement halfOpen state in CircuitBreaker -- Key: CAMEL-8039 URL: https://issues.apache.org/jira/browse/CAMEL-8039 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Matteo Pavesi Assignee: Willem Jiang Priority: Trivial Fix For: 2.15.0 Attachments: 0001-halfOpen-state-in-CircuitBreaker.patch The CircuitBreaker EIP described in ReleaseIt! has an halfOpen state. It means that after the halfOpen time timeout, the circuitBreaker is accepting one more exchange and it close the circuit only if the processor succeeds. This is not implemented in Camel, I would like to propose the attached patch with code and test for implementing the HalfOpen state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7998) Support connection less udp sending
[ https://issues.apache.org/jira/browse/CAMEL-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang updated CAMEL-7998: Component/s: camel-netty Fix Version/s: 2.15.0 Support connection less udp sending --- Key: CAMEL-7998 URL: https://issues.apache.org/jira/browse/CAMEL-7998 Project: Camel Issue Type: New Feature Components: camel-netty, camel-netty4 Affects Versions: 2.14.0 Reporter: Thomas Termin Assignee: Willem Jiang Fix For: 2.15.0 An config parameter should be added to support connection less udp sending which is a real fire and forget. A connected udp send receive the PortUnreachableException if no one is listen on the receiving port. That might on some circumstances not what is expected e.g. sending a lot of data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8042) CxfClientCallBack handleException does not honour exception
[
https://issues.apache.org/jira/browse/CAMEL-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CAMEL-8042:
---
Assignee: Willem Jiang
CxfClientCallBack handleException does not honour exception
---
Key: CAMEL-8042
URL: https://issues.apache.org/jira/browse/CAMEL-8042
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.11.2, 2.14.0
Environment: Windows
Reporter: John McKeogh
Assignee: Willem Jiang
Fix For: 2.14.1
Attachments: greeter-corba.wsdl
Hi,
Since Camel 2.11.2, The cxfClientCallBack doesn't seem to be honouring the
exception that it is passed in.
Here is a copy of the HandleException funciton before and after 11.2
2.11.1
public void handleException(MapString, Object ctx, Throwable
ex) {
try {
super.handleException(ctx, ex);
camelExchange.setException(ex);
} finally {
// copy
2.11.2
public void handleException(MapString, Object ctx, Throwable ex) {
try {
super.handleException(ctx, ex);
// need to call the conduitSelector complete method to enable the
fail over feature
ConduitSelector conduitSelector =
cxfExchange.get(ConduitSelector.class);
if (conduitSelector != null) {
conduitSelector.complete(cxfExchange);
ex = cxfExchange.getOutMessage().getContent(Exception.class);
if (ex == null cxfExchange.getInMessage() != null) {
ex =
cxfExchange.getInMessage().getContent(Exception.class);
}
if (ex != null) {
camelExchange.setException(ex);
}
} else {
camelExchange.setException(ex);
}
} finally {
So for our testcase where we have a cxf client calling through camel to a
Corba web service, the exception that the webservice is passing back to camel
is no longer honoured.
I believe this change was introduced by the following jira:
https://issues.apache.org/jira/browse/CAMEL-6609
I have attached the wsdl of the corba web-service.
In the service we are calling PingMe expecting to get back a
PingMeFault_Exception. The exception is set in the cxf corba binding and
reached the exception handler in camel. But the exception is no longer being
sent back to the client. Instead a generic SoapFaultException is reaching the
client.
Cheers,
John.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7998) Support connection less udp sending
[ https://issues.apache.org/jira/browse/CAMEL-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7998. - Resolution: Fixed update the wiki page for the new added option. Support connection less udp sending --- Key: CAMEL-7998 URL: https://issues.apache.org/jira/browse/CAMEL-7998 Project: Camel Issue Type: New Feature Components: camel-netty, camel-netty4 Affects Versions: 2.14.0 Reporter: Thomas Termin Assignee: Willem Jiang Fix For: 2.15.0 An config parameter should be added to support connection less udp sending which is a real fire and forget. A connected udp send receive the PortUnreachableException if no one is listen on the receiving port. That might on some circumstances not what is expected e.g. sending a lot of data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8046) Use OSGi capabilities to offer components
Christian Schneider created CAMEL-8046: -- Summary: Use OSGi capabilities to offer components Key: CAMEL-8046 URL: https://issues.apache.org/jira/browse/CAMEL-8046 Project: Camel Issue Type: New Feature Components: osgi Affects Versions: 2.14.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 2.15.0 Currently bundles using camel detect components at runtime. If a component is missing then there are two cases: - blueprint : The user bundle goes into graceperiod status and waits for the component to come up. In case the component is still missing there is a failure. - In other cases: Camel will simply display and error about the missing component. The proper OSGi way to handle camel components would be to use capabilities and requirements. See http://wiki.osgi.org/wiki/Provide-Capability http://wiki.osgi.org/wiki/Require-Capability So a bundle offering a component should have a capability to express that as well as the user bundle should have a requirement for the capability. This will even allow a suitable OSGi resolver to auto install bundles that match the required capabilties. In any case it will make sure the required components are installed before the user bundle starts. So to support this the first decision is how to name the capability. I propose: org.apache.camel.component. Then we have to decide how we name the components. I propose we use the component prefix. E.g file for the file component. The next thing is to add the Provide-Capability headers to the components. This has to be done before the users start creating Require-Capability headers. To automate this step I propose to create a maven plugin that scans for META-INF/services/org/apache/camel/component/* files and creates suitable headers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-7627) Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings
[ https://issues.apache.org/jira/browse/CAMEL-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14209893#comment-14209893 ] Jonathan Anstey edited comment on CAMEL-7627 at 11/13/14 3:23 PM: -- Just merged your patches with a few minor modifications. Thanks Nikolay! was (Author: janstey): Just merged your patches with a few miro modifications. Thanks Nikolay! Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings - Key: CAMEL-7627 URL: https://issues.apache.org/jira/browse/CAMEL-7627 Project: Camel Issue Type: Bug Components: camel-quartz, camel-quartz2 Reporter: Nikolay Turpitko Assignee: Jonathan Anstey Fix For: 2.14.1, 2.15.0, 2.13.4 Attachments: 0001-Fix-reshedule-changed-trigger-after-restart.patch, 0002-Test-trigger-type-change.patch Camel-quartz2 component in clustered mode uses trigger options stored in DB rather (possibly changed) ones from endpoint's URI. Desirable behavior is to compare trigger options in DB and endpoint's URI and reschedule quartz job when they changed (like in camel-quartz component). Component camel-quartz already have this functionality, but there is no test for it and it works incorrectly with changed SimpleTrigger options. I attached a patch with unit tests. Every test prepares DB, than creates application context twice with different trigger options. Both times it retrieves options back, accessing them via trigger (not via endpoint, so that it uses values stored in DB). After that it asserts that retrieved options are indeed different. You can ensure, that the tests fail with old versions of org.apache.camel.component.quartz2.QuartzEndpoint#addJobInScheduler or org.apache.camel.component.quartz.QuartzComponent#hasTriggerChanged methods and pass with patched implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7627) Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings
[ https://issues.apache.org/jira/browse/CAMEL-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-7627. Resolution: Fixed Fix Version/s: 2.13.4 2.14.1 Assignee: Jonathan Anstey Just merged your patches with a few miro modifications. Thanks Nikolay! Quartz/Quartz2 in cluster mode doesn't apply changed trigger settings - Key: CAMEL-7627 URL: https://issues.apache.org/jira/browse/CAMEL-7627 Project: Camel Issue Type: Bug Components: camel-quartz, camel-quartz2 Reporter: Nikolay Turpitko Assignee: Jonathan Anstey Fix For: 2.14.1, 2.15.0, 2.13.4 Attachments: 0001-Fix-reshedule-changed-trigger-after-restart.patch, 0002-Test-trigger-type-change.patch Camel-quartz2 component in clustered mode uses trigger options stored in DB rather (possibly changed) ones from endpoint's URI. Desirable behavior is to compare trigger options in DB and endpoint's URI and reschedule quartz job when they changed (like in camel-quartz component). Component camel-quartz already have this functionality, but there is no test for it and it works incorrectly with changed SimpleTrigger options. I attached a patch with unit tests. Every test prepares DB, than creates application context twice with different trigger options. Both times it retrieves options back, accessing them via trigger (not via endpoint, so that it uses values stored in DB). After that it asserts that retrieved options are indeed different. You can ensure, that the tests fail with old versions of org.apache.camel.component.quartz2.QuartzEndpoint#addJobInScheduler or org.apache.camel.component.quartz.QuartzComponent#hasTriggerChanged methods and pass with patched implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8047) Replace BundleDelegatingClassLoader with BundleWiring
Christian Schneider created CAMEL-8047: -- Summary: Replace BundleDelegatingClassLoader with BundleWiring Key: CAMEL-8047 URL: https://issues.apache.org/jira/browse/CAMEL-8047 Project: Camel Issue Type: Improvement Components: osgi Affects Versions: 2.14.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 2.15.0 I found we have the class BundleDelegatingClassLoader in camel-core-osgi. I wonder if the same could be achieved by bundle.adapt(BundleWiring.class).getClassLoder ? As we use the OSGi spec 4.3.1 now I think we can replace this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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 6:46 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}
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 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] [Commented] (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 commented on CAMEL-7678:
-
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 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] [Resolved] (CAMEL-4710) Upgrade to Karaf 3
[ https://issues.apache.org/jira/browse/CAMEL-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-4710. Resolution: Fixed Camel can run on Karaf 3 and 2.x now Upgrade to Karaf 3 -- Key: CAMEL-4710 URL: https://issues.apache.org/jira/browse/CAMEL-4710 Project: Camel Issue Type: Task Affects Versions: 2.10.0, 3.0.0 Reporter: Guillaume Nodet Assignee: Jean-Baptiste Onofré Fix For: 3.0.0 -- 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* 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 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
