[jira] [Commented] (CAMEL-7462) camel-netty-http doesn't use "Expect: 100-continue" correctly
[
https://issues.apache.org/jira/browse/CAMEL-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957770#comment-16957770
]
Grzegorz Grzybek commented on CAMEL-7462:
-
Oh my - I completely forgot about this issue!! Probably you're right, but I
really don't remember ;).
> camel-netty-http doesn't use "Expect: 100-continue" correctly
> -
>
> Key: CAMEL-7462
> URL: https://issues.apache.org/jira/browse/CAMEL-7462
> Project: Camel
> Issue Type: Bug
> Components: camel-netty-http
>Affects Versions: 2.12.3
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 2.12.4, 2.13.2, 2.14.0
>
>
> Camel-netty-http component, when sending HTTP request with:
> {noformat}
> Expect: 100-continue
> {noformat}
> header, always sends the HTTP body with first request and treats:
> {noformat}
> HTTP/1.1 100 Continue
> {noformat}
> as final response.
> Additionally
> {{org.apache.camel.component.netty.http.handlers.HttpServerChannelHandler}}
> sends {{HTTP/1.1 100 Continue}} partial response after the same partial
> response was send by
> {{org.jboss.netty.handler.codec.http.HttpChunkAggregator#messageReceived}}
> Attached: wireshark session dump.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14102) Create a Camel-graphql Karaf feature
Andrea Cosentino created CAMEL-14102: Summary: Create a Camel-graphql Karaf feature Key: CAMEL-14102 URL: https://issues.apache.org/jira/browse/CAMEL-14102 Project: Camel Issue Type: Task Components: karaf Reporter: Andrea Cosentino Assignee: Andrea Cosentino Fix For: 3.0.0, 3.0.0.RC4 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14103) Camel-Graphql: Add Karaf and Spring Boot integration test
Andrea Cosentino created CAMEL-14103: Summary: Camel-Graphql: Add Karaf and Spring Boot integration test Key: CAMEL-14103 URL: https://issues.apache.org/jira/browse/CAMEL-14103 Project: Camel Issue Type: Task Components: tests Reporter: Andrea Cosentino Assignee: Andrea Cosentino Fix For: 3.0.0, 3.0.0.RC4 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14102) Create a Camel-graphql Karaf feature
[ https://issues.apache.org/jira/browse/CAMEL-14102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-14102. -- Resolution: Fixed > Create a Camel-graphql Karaf feature > > > Key: CAMEL-14102 > URL: https://issues.apache.org/jira/browse/CAMEL-14102 > Project: Camel > Issue Type: Task > Components: karaf >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.0.0, 3.0.0.RC4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-7462) camel-netty-http doesn't use "Expect: 100-continue" correctly
[
https://issues.apache.org/jira/browse/CAMEL-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957750#comment-16957750
]
Zheng Feng commented on CAMEL-7462:
---
Hi [~gzres], I came cross this issue when working on CAMEL-14069 and it seems
that the camel-netty-http still send the body with the request even if we set
the header "Expect: 100-continue". The fix only ignores the HTTP 100-continue
response, is it right ?
> camel-netty-http doesn't use "Expect: 100-continue" correctly
> -
>
> Key: CAMEL-7462
> URL: https://issues.apache.org/jira/browse/CAMEL-7462
> Project: Camel
> Issue Type: Bug
> Components: camel-netty-http
>Affects Versions: 2.12.3
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
>Priority: Major
> Fix For: 2.12.4, 2.13.2, 2.14.0
>
>
> Camel-netty-http component, when sending HTTP request with:
> {noformat}
> Expect: 100-continue
> {noformat}
> header, always sends the HTTP body with first request and treats:
> {noformat}
> HTTP/1.1 100 Continue
> {noformat}
> as final response.
> Additionally
> {{org.apache.camel.component.netty.http.handlers.HttpServerChannelHandler}}
> sends {{HTTP/1.1 100 Continue}} partial response after the same partial
> response was send by
> {{org.jboss.netty.handler.codec.http.HttpChunkAggregator#messageReceived}}
> Attached: wireshark session dump.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14103) Camel-Graphql: Add Karaf and Spring Boot integration test
[ https://issues.apache.org/jira/browse/CAMEL-14103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-14103. -- Resolution: Fixed > Camel-Graphql: Add Karaf and Spring Boot integration test > - > > Key: CAMEL-14103 > URL: https://issues.apache.org/jira/browse/CAMEL-14103 > Project: Camel > Issue Type: Task > Components: tests >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.0.0, 3.0.0.RC4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14105) avoid using deprecated org.eclipse.jetty.util.MultiPartInputStreamParser
Freeman Yue Fang created CAMEL-14105:
Summary: avoid using deprecated
org.eclipse.jetty.util.MultiPartInputStreamParser
Key: CAMEL-14105
URL: https://issues.apache.org/jira/browse/CAMEL-14105
Project: Camel
Issue Type: Bug
Reporter: Freeman Yue Fang
This will be removed in future jetty version and already not visible in
current(9.4.20) jetty OSGi bundle
{code}
headers org.eclipse.jetty.util
Jetty :: Utilities (276)
.
Export-Package =
org.eclipse.jetty.util;
exclude:=MultiPartInputStreamParser;
uses:="org.eclipse.jetty.util.annotation,
org.eclipse.jetty.util.component,
org.eclipse.jetty.util.log,
org.eclipse.jetty.util.resource,
org.eclipse.jetty.util.thread";
{code}
We should use the new fast MultiPartFormInputStream instead by using Servlet 3
API
{code}
javax.servlet.http.HttpServletRequest.getParts()
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-14105) avoid using deprecated org.eclipse.jetty.util.MultiPartInputStreamParser
[
https://issues.apache.org/jira/browse/CAMEL-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CAMEL-14105:
Assignee: Freeman Yue Fang
> avoid using deprecated org.eclipse.jetty.util.MultiPartInputStreamParser
> -
>
> Key: CAMEL-14105
> URL: https://issues.apache.org/jira/browse/CAMEL-14105
> Project: Camel
> Issue Type: Bug
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This will be removed in future jetty version and already not visible in
> current(9.4.20) jetty OSGi bundle
> {code}
> headers org.eclipse.jetty.util
> Jetty :: Utilities (276)
> .
> Export-Package =
> org.eclipse.jetty.util;
> exclude:=MultiPartInputStreamParser;
> uses:="org.eclipse.jetty.util.annotation,
> org.eclipse.jetty.util.component,
> org.eclipse.jetty.util.log,
> org.eclipse.jetty.util.resource,
> org.eclipse.jetty.util.thread";
> {code}
> We should use the new fast MultiPartFormInputStream instead by using Servlet
> 3 API
> {code}
> javax.servlet.http.HttpServletRequest.getParts()
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14105) avoid using deprecated org.eclipse.jetty.util.MultiPartInputStreamParser
[
https://issues.apache.org/jira/browse/CAMEL-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CAMEL-14105.
--
Fix Version/s: 3.0.0.RC4
2.25.0
3.0.0
2.24.3
Resolution: Fixed
> avoid using deprecated org.eclipse.jetty.util.MultiPartInputStreamParser
> -
>
> Key: CAMEL-14105
> URL: https://issues.apache.org/jira/browse/CAMEL-14105
> Project: Camel
> Issue Type: Bug
>Reporter: Freeman Yue Fang
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 2.24.3, 3.0.0, 2.25.0, 3.0.0.RC4
>
>
> This will be removed in future jetty version and already not visible in
> current(9.4.20) jetty OSGi bundle
> {code}
> headers org.eclipse.jetty.util
> Jetty :: Utilities (276)
> .
> Export-Package =
> org.eclipse.jetty.util;
> exclude:=MultiPartInputStreamParser;
> uses:="org.eclipse.jetty.util.annotation,
> org.eclipse.jetty.util.component,
> org.eclipse.jetty.util.log,
> org.eclipse.jetty.util.resource,
> org.eclipse.jetty.util.thread";
> {code}
> We should use the new fast MultiPartFormInputStream instead by using Servlet
> 3 API
> {code}
> javax.servlet.http.HttpServletRequest.getParts()
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14104) Update FHIR to latest version
John Poth created CAMEL-14104: - Summary: Update FHIR to latest version Key: CAMEL-14104 URL: https://issues.apache.org/jira/browse/CAMEL-14104 Project: Camel Issue Type: Improvement Components: camel-fhir Reporter: John Poth This will introduce new features and minor breaking changes so should probably be for Camel 3 only -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-14104) Update FHIR to latest version
[ https://issues.apache.org/jira/browse/CAMEL-14104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Poth reassigned CAMEL-14104: - Assignee: John Poth > Update FHIR to latest version > - > > Key: CAMEL-14104 > URL: https://issues.apache.org/jira/browse/CAMEL-14104 > Project: Camel > Issue Type: Improvement > Components: camel-fhir >Reporter: John Poth >Assignee: John Poth >Priority: Major > > This will introduce new features and minor breaking changes so should > probably be for Camel 3 only -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14106) Camel-AWS
Vishal Vijayan created CAMEL-14106: -- Summary: Camel-AWS Key: CAMEL-14106 URL: https://issues.apache.org/jira/browse/CAMEL-14106 Project: Camel Issue Type: New Feature Reporter: Vishal Vijayan -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14106) Camel-AWS: S3 Range Get
[ https://issues.apache.org/jira/browse/CAMEL-14106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Vijayan updated CAMEL-14106: --- Component/s: camel-aws-s3 Description: The _camel-s3_ component does not have an option to perform a Range get. Currently the S3 consumer issues a _GetObject_ with only the _bucketName_ and _bucketKey_ as parameters. Hence the _range_ parameter in the _GetObjectRequest_ is unused. Ranged get is very effective when the S3 objects are large and having this as an optional parameter allows uses additional control. Summary: Camel-AWS: S3 Range Get (was: Camel-AWS) > Camel-AWS: S3 Range Get > --- > > Key: CAMEL-14106 > URL: https://issues.apache.org/jira/browse/CAMEL-14106 > Project: Camel > Issue Type: New Feature > Components: camel-aws-s3 >Reporter: Vishal Vijayan >Priority: Minor > > The _camel-s3_ component does not have an option to perform a Range get. > Currently the S3 consumer issues a _GetObject_ with only the _bucketName_ and > _bucketKey_ as parameters. Hence the _range_ parameter in the > _GetObjectRequest_ is unused. > Ranged get is very effective when the S3 objects are large and having this as > an optional parameter allows uses additional control. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14069) netty4-http - Add logic to handle http 100-Continue
[ https://issues.apache.org/jira/browse/CAMEL-14069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958472#comment-16958472 ] Zheng Feng commented on CAMEL-14069: [~urken] I doubt that the camel-netty4-http producer could support the expect 100-continue which is sending the request with the header "EXPECT: 100-continue" and waiting for the response "HTTP/1.1 100 Continue" and then sending the body. Now the client only sends the request with the body at once even if we set the EXPECT header. By the way, I raise the PR to ignore the "100 Continue" response in the client handlers based on your fix. > netty4-http - Add logic to handle http 100-Continue > --- > > Key: CAMEL-14069 > URL: https://issues.apache.org/jira/browse/CAMEL-14069 > Project: Camel > Issue Type: Improvement > Components: camel-netty4, camel-netty4-http >Affects Versions: 2.24.0 >Reporter: Göran Erkstam >Assignee: Zheng Feng >Priority: Major > Fix For: 3.0.0, 2.25.0 > > Attachments: ClientChannelHandler.java, HttpClientChannelHandler.java > > Time Spent: 10m > Remaining Estimate: 0h > > When using netty4-http as a client we have a problem when the server side > answers with a http 100-Continue. We expected the client to handle that > internally and continue the call but it's actually returning http 100. > This is handled by Nettys own channel handlers but since the Camel > HttpClientChannelHandler/ClientChannelHandler stop waiting when a http > 100-Continue arrives it doesn't help. > In the project I'm working with we made a custom ClientInitilizer and made > some small changes in the HttpClientChannelHandler and ClientChannelHandler > that just "ignores" the http 100-Continue when it arrives to solve this issue. > See the attached files to see our solution > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14069) netty4-http - Add logic to handle http 100-Continue
[ https://issues.apache.org/jira/browse/CAMEL-14069?focusedWorklogId=333060=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-333060 ] ASF GitHub Bot logged work on CAMEL-14069: -- Author: ASF GitHub Bot Created on: 24/Oct/19 04:13 Start Date: 24/Oct/19 04:13 Worklog Time Spent: 10m Work Description: zhfeng commented on pull request #3279: CAMEL-14069 Update to ignore the 100-Continue response and continue to URL: https://github.com/apache/camel/pull/3279 wait for the answer This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 333060) Time Spent: 20m (was: 10m) > netty4-http - Add logic to handle http 100-Continue > --- > > Key: CAMEL-14069 > URL: https://issues.apache.org/jira/browse/CAMEL-14069 > Project: Camel > Issue Type: Improvement > Components: camel-netty4, camel-netty4-http >Affects Versions: 2.24.0 >Reporter: Göran Erkstam >Assignee: Zheng Feng >Priority: Major > Fix For: 3.0.0, 2.25.0 > > Attachments: ClientChannelHandler.java, HttpClientChannelHandler.java > > Time Spent: 20m > Remaining Estimate: 0h > > When using netty4-http as a client we have a problem when the server side > answers with a http 100-Continue. We expected the client to handle that > internally and continue the call but it's actually returning http 100. > This is handled by Nettys own channel handlers but since the Camel > HttpClientChannelHandler/ClientChannelHandler stop waiting when a http > 100-Continue arrives it doesn't help. > In the project I'm working with we made a custom ClientInitilizer and made > some small changes in the HttpClientChannelHandler and ClientChannelHandler > that just "ignores" the http 100-Continue when it arrives to solve this issue. > See the attached files to see our solution > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14099) Mocking OSGi Services failes using classes
[
https://issues.apache.org/jira/browse/CAMEL-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957633#comment-16957633
]
Christian Eve commented on CAMEL-14099:
---
Thanks for the quick response. Without using Mockito, it doesn't work as well
{code:java}
protected void addServicesOnStartup(Map> services) {
FooImpl foo = new FooImpl();
services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
super.addServicesOnStartup(services);
}
{code}
What else do you recommend?
> Mocking OSGi Services failes using classes
> --
>
> Key: CAMEL-14099
> URL: https://issues.apache.org/jira/browse/CAMEL-14099
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint
>Affects Versions: 2.21.0
> Environment: Camel 2.21.0 on Karaf 4.2.0
>Reporter: Christian Eve
>Priority: Minor
> Labels: test
>
> Using Camel with OSGi Blueprint XML, mocking OSGi services in the test class
> extending CamelBlueprintTestSupport does not work under some speical
> circumstances.
> In the blueprint.xml, there is the following code:
> {code:java}
>
>
>
>
> interface="com.myexample.FooImpl" ext:proxy-method="classes" />
> {code}
> The execution on the Karaf server works fine.
> Mocking the service 'FooImpl' in the test class failes with
> _java.lang.RuntimeException: Gave up waiting for BlueprintContainer from
> bundle "FooTest" at com.myexample.test.FooTest.setUp(FooTest.java:49)_
> The mock setup is done this way:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooImpl foo = Mockito.mock(FooImpl.class);
> services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
> super.addServicesOnStartup(services);
> }
> {code}
> Using an interface as reference instead of a class, the mock works fine:
> blueprint.xml:
> {code:java}
>
> {code}
> Mock in test class:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooInterface foo = Mockito.mock(FooImpl.class);
> services.put(FooInterface.class.getCanonicalName(), asService(foo,
> null));
> super.addServicesOnStartup(services);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14099) Mocking OSGi Services failes using classes
[
https://issues.apache.org/jira/browse/CAMEL-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957635#comment-16957635
]
Claus Ibsen commented on CAMEL-14099:
-
Reg it via the interface in the put
> Mocking OSGi Services failes using classes
> --
>
> Key: CAMEL-14099
> URL: https://issues.apache.org/jira/browse/CAMEL-14099
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint
>Affects Versions: 2.21.0
> Environment: Camel 2.21.0 on Karaf 4.2.0
>Reporter: Christian Eve
>Priority: Minor
> Labels: test
>
> Using Camel with OSGi Blueprint XML, mocking OSGi services in the test class
> extending CamelBlueprintTestSupport does not work under some speical
> circumstances.
> In the blueprint.xml, there is the following code:
> {code:java}
>
>
>
>
> interface="com.myexample.FooImpl" ext:proxy-method="classes" />
> {code}
> The execution on the Karaf server works fine.
> Mocking the service 'FooImpl' in the test class failes with
> _java.lang.RuntimeException: Gave up waiting for BlueprintContainer from
> bundle "FooTest" at com.myexample.test.FooTest.setUp(FooTest.java:49)_
> The mock setup is done this way:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooImpl foo = Mockito.mock(FooImpl.class);
> services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
> super.addServicesOnStartup(services);
> }
> {code}
> Using an interface as reference instead of a class, the mock works fine:
> blueprint.xml:
> {code:java}
>
> {code}
> Mock in test class:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooInterface foo = Mockito.mock(FooImpl.class);
> services.put(FooInterface.class.getCanonicalName(), asService(foo,
> null));
> super.addServicesOnStartup(services);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14099) Mocking OSGi Services failes using classes
Christian Eve created CAMEL-14099:
-
Summary: Mocking OSGi Services failes using classes
Key: CAMEL-14099
URL: https://issues.apache.org/jira/browse/CAMEL-14099
Project: Camel
Issue Type: Bug
Components: camel-blueprint
Affects Versions: 2.21.0
Environment: Camel 2.21.0 on Karaf 4.2.0
Reporter: Christian Eve
Assignee: Grzegorz Grzybek
Using Camel with OSGi Blueprint XML, mocking OSGi services in the test class
extending CamelBlueprintTestSupport does not work under some speical
circumstances.
In the blueprint.xml, there is the following code:
{code:java}
{code}
The execution on the Karaf server works fine.
Mocking the service 'FooImpl' in the test class failes with
_java.lang.RuntimeException: Gave up waiting for BlueprintContainer from
bundle "FooTest" at com.myexample.test.FooTest.setUp(FooTest.java:49)_
The mock setup is done this way:
{code:java}
protected void addServicesOnStartup(Map> services) {
FooImpl foo = Mockito.mock(FooImpl.class);
services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
super.addServicesOnStartup(services);
}
{code}
Using an interface as reference instead of a class, the mock works fine:
blueprint.xml:
{code:java}
{code}
Mock in test class:
{code:java}
protected void addServicesOnStartup(Map> services) {
FooInterface foo = Mockito.mock(FooImpl.class);
services.put(FooInterface.class.getCanonicalName(), asService(foo,
null));
super.addServicesOnStartup(services);
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14099) Mocking OSGi Services failes using classes
[
https://issues.apache.org/jira/browse/CAMEL-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Eve updated CAMEL-14099:
--
Description:
Using Camel with OSGi Blueprint XML, mocking OSGi services in the test class
extending CamelBlueprintTestSupport does not work under some speical
circumstances.
In the blueprint.xml, there is the following code:
{code:java}
{code}
The execution on the Karaf server works fine.
Mocking the service 'FooImpl' in the test class failes with
_java.lang.RuntimeException: Gave up waiting for BlueprintContainer from
bundle "FooTest" at com.myexample.test.FooTest.setUp(FooTest.java:49)_
The mock setup is done this way:
{code:java}
protected void addServicesOnStartup(Map> services) {
FooImpl foo = Mockito.mock(FooImpl.class);
services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
super.addServicesOnStartup(services);
}
{code}
Using an interface as reference instead of a class, the mock works fine:
blueprint.xml:
{code:java}
{code}
Mock in test class:
{code:java}
protected void addServicesOnStartup(Map> services) {
FooInterface foo = Mockito.mock(FooImpl.class);
services.put(FooInterface.class.getCanonicalName(), asService(foo,
null));
super.addServicesOnStartup(services);
}
{code}
was:
Using Camel with OSGi Blueprint XML, mocking OSGi services in the test class
extending CamelBlueprintTestSupport does not work under some speical
circumstances.
In the blueprint.xml, there is the following code:
{code:java}
{code}
The execution on the Karaf server works fine.
Mocking the service 'FooImpl' in the test class failes with
_java.lang.RuntimeException: Gave up waiting for BlueprintContainer from
bundle "FooTest" at com.myexample.test.FooTest.setUp(FooTest.java:49)_
The mock setup is done this way:
{code:java}
protected void addServicesOnStartup(Map> services) {
FooImpl foo = Mockito.mock(FooImpl.class);
services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
super.addServicesOnStartup(services);
}
{code}
Using an interface as reference instead of a class, the mock works fine:
blueprint.xml:
{code:java}
{code}
Mock in test class:
{code:java}
protected void addServicesOnStartup(Map> services) {
FooInterface foo = Mockito.mock(FooImpl.class);
services.put(FooInterface.class.getCanonicalName(), asService(foo,
null));
super.addServicesOnStartup(services);
}
{code}
> Mocking OSGi Services failes using classes
> --
>
> Key: CAMEL-14099
> URL: https://issues.apache.org/jira/browse/CAMEL-14099
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint
>Affects Versions: 2.21.0
> Environment: Camel 2.21.0 on Karaf 4.2.0
>Reporter: Christian Eve
>Assignee: Grzegorz Grzybek
>Priority: Blocker
> Labels: test
>
> Using Camel with OSGi Blueprint XML, mocking OSGi services in the test class
> extending CamelBlueprintTestSupport does not work under some speical
> circumstances.
> In the blueprint.xml, there is the following code:
> {code:java}
>
>
>
>
> interface="com.myexample.FooImpl" ext:proxy-method="classes" />
> {code}
> The execution on the Karaf server works fine.
> Mocking the service 'FooImpl' in the test class failes with
> _java.lang.RuntimeException: Gave up waiting for BlueprintContainer from
> bundle "FooTest" at com.myexample.test.FooTest.setUp(FooTest.java:49)_
> The mock setup is done this way:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooImpl foo = Mockito.mock(FooImpl.class);
> services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
> super.addServicesOnStartup(services);
> }
> {code}
> Using an interface as reference instead of a class, the mock works fine:
> blueprint.xml:
> {code:java}
>
> {code}
> Mock in test class:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooInterface foo = Mockito.mock(FooImpl.class);
> services.put(FooInterface.class.getCanonicalName(), asService(foo,
> null));
> super.addServicesOnStartup(services);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-14099) Mocking OSGi Services failes using classes
[
https://issues.apache.org/jira/browse/CAMEL-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-14099:
---
Assignee: (was: Grzegorz Grzybek)
> Mocking OSGi Services failes using classes
> --
>
> Key: CAMEL-14099
> URL: https://issues.apache.org/jira/browse/CAMEL-14099
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint
>Affects Versions: 2.21.0
> Environment: Camel 2.21.0 on Karaf 4.2.0
>Reporter: Christian Eve
>Priority: Minor
> Labels: test
>
> Using Camel with OSGi Blueprint XML, mocking OSGi services in the test class
> extending CamelBlueprintTestSupport does not work under some speical
> circumstances.
> In the blueprint.xml, there is the following code:
> {code:java}
>
>
>
>
> interface="com.myexample.FooImpl" ext:proxy-method="classes" />
> {code}
> The execution on the Karaf server works fine.
> Mocking the service 'FooImpl' in the test class failes with
> _java.lang.RuntimeException: Gave up waiting for BlueprintContainer from
> bundle "FooTest" at com.myexample.test.FooTest.setUp(FooTest.java:49)_
> The mock setup is done this way:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooImpl foo = Mockito.mock(FooImpl.class);
> services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
> super.addServicesOnStartup(services);
> }
> {code}
> Using an interface as reference instead of a class, the mock works fine:
> blueprint.xml:
> {code:java}
>
> {code}
> Mock in test class:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooInterface foo = Mockito.mock(FooImpl.class);
> services.put(FooInterface.class.getCanonicalName(), asService(foo,
> null));
> super.addServicesOnStartup(services);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14099) Mocking OSGi Services failes using classes
[
https://issues.apache.org/jira/browse/CAMEL-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14099:
Priority: Minor (was: Blocker)
> Mocking OSGi Services failes using classes
> --
>
> Key: CAMEL-14099
> URL: https://issues.apache.org/jira/browse/CAMEL-14099
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint
>Affects Versions: 2.21.0
> Environment: Camel 2.21.0 on Karaf 4.2.0
>Reporter: Christian Eve
>Assignee: Grzegorz Grzybek
>Priority: Minor
> Labels: test
>
> Using Camel with OSGi Blueprint XML, mocking OSGi services in the test class
> extending CamelBlueprintTestSupport does not work under some speical
> circumstances.
> In the blueprint.xml, there is the following code:
> {code:java}
>
>
>
>
> interface="com.myexample.FooImpl" ext:proxy-method="classes" />
> {code}
> The execution on the Karaf server works fine.
> Mocking the service 'FooImpl' in the test class failes with
> _java.lang.RuntimeException: Gave up waiting for BlueprintContainer from
> bundle "FooTest" at com.myexample.test.FooTest.setUp(FooTest.java:49)_
> The mock setup is done this way:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooImpl foo = Mockito.mock(FooImpl.class);
> services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
> super.addServicesOnStartup(services);
> }
> {code}
> Using an interface as reference instead of a class, the mock works fine:
> blueprint.xml:
> {code:java}
>
> {code}
> Mock in test class:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooInterface foo = Mockito.mock(FooImpl.class);
> services.put(FooInterface.class.getCanonicalName(), asService(foo,
> null));
> super.addServicesOnStartup(services);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14099) Mocking OSGi Services failes using classes
[
https://issues.apache.org/jira/browse/CAMEL-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957624#comment-16957624
]
Claus Ibsen commented on CAMEL-14099:
-
You are using mockito and all of that can screw things up. CamelTestBlueprint
is just a tiny test for some use-cases with OSGi blueprint. It cannot do
everything, and sometimes you need to use something else with karaf testing
libraries.
> Mocking OSGi Services failes using classes
> --
>
> Key: CAMEL-14099
> URL: https://issues.apache.org/jira/browse/CAMEL-14099
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint
>Affects Versions: 2.21.0
> Environment: Camel 2.21.0 on Karaf 4.2.0
>Reporter: Christian Eve
>Priority: Minor
> Labels: test
>
> Using Camel with OSGi Blueprint XML, mocking OSGi services in the test class
> extending CamelBlueprintTestSupport does not work under some speical
> circumstances.
> In the blueprint.xml, there is the following code:
> {code:java}
>
>
>
>
> interface="com.myexample.FooImpl" ext:proxy-method="classes" />
> {code}
> The execution on the Karaf server works fine.
> Mocking the service 'FooImpl' in the test class failes with
> _java.lang.RuntimeException: Gave up waiting for BlueprintContainer from
> bundle "FooTest" at com.myexample.test.FooTest.setUp(FooTest.java:49)_
> The mock setup is done this way:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooImpl foo = Mockito.mock(FooImpl.class);
> services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
> super.addServicesOnStartup(services);
> }
> {code}
> Using an interface as reference instead of a class, the mock works fine:
> blueprint.xml:
> {code:java}
>
> {code}
> Mock in test class:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooInterface foo = Mockito.mock(FooImpl.class);
> services.put(FooInterface.class.getCanonicalName(), asService(foo,
> null));
> super.addServicesOnStartup(services);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14099) Mocking OSGi Services failes using classes
[
https://issues.apache.org/jira/browse/CAMEL-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957658#comment-16957658
]
Christian Eve commented on CAMEL-14099:
---
Using
{code:java}
FooInterface foo = new FooImpl();
services.put(FooInterface.class.getCanonicalName(), asService(foo, null));
{code}
doesn't work. Or did you mean something else?
> Mocking OSGi Services failes using classes
> --
>
> Key: CAMEL-14099
> URL: https://issues.apache.org/jira/browse/CAMEL-14099
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint
>Affects Versions: 2.21.0
> Environment: Camel 2.21.0 on Karaf 4.2.0
>Reporter: Christian Eve
>Priority: Minor
> Labels: test
>
> Using Camel with OSGi Blueprint XML, mocking OSGi services in the test class
> extending CamelBlueprintTestSupport does not work under some speical
> circumstances.
> In the blueprint.xml, there is the following code:
> {code:java}
>
>
>
>
> interface="com.myexample.FooImpl" ext:proxy-method="classes" />
> {code}
> The execution on the Karaf server works fine.
> Mocking the service 'FooImpl' in the test class failes with
> _java.lang.RuntimeException: Gave up waiting for BlueprintContainer from
> bundle "FooTest" at com.myexample.test.FooTest.setUp(FooTest.java:49)_
> The mock setup is done this way:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooImpl foo = Mockito.mock(FooImpl.class);
> services.put(FooImpl.class.getCanonicalName(), asService(foo, null));
> super.addServicesOnStartup(services);
> }
> {code}
> Using an interface as reference instead of a class, the mock works fine:
> blueprint.xml:
> {code:java}
>
> {code}
> Mock in test class:
> {code:java}
> protected void addServicesOnStartup(Map Dictionary>> services) {
> FooInterface foo = Mockito.mock(FooImpl.class);
> services.put(FooInterface.class.getCanonicalName(), asService(foo,
> null));
> super.addServicesOnStartup(services);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14069) netty4-http - Add logic to handle http 100-Continue
[ https://issues.apache.org/jira/browse/CAMEL-14069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957667#comment-16957667 ] Zheng Feng commented on CAMEL-14069: I came across the CAMEL-7462 and it seems this similar issue had been fixed in the camel-netty-http. I just kept investigating and the [NettyHttpClientExpectContinueTest|https://github.com/apache/camel/blob/camel-2.x/components/camel-netty4-http/src/test/java/org/apache/camel/component/netty4/http/NettyHttpClientExpectContinueTest.java#L25] is just ignored and marked with "TODO Fix". So I assume this could be a bug rather than an improvement. > netty4-http - Add logic to handle http 100-Continue > --- > > Key: CAMEL-14069 > URL: https://issues.apache.org/jira/browse/CAMEL-14069 > Project: Camel > Issue Type: Improvement > Components: camel-netty4, camel-netty4-http >Affects Versions: 2.24.0 >Reporter: Göran Erkstam >Assignee: Zheng Feng >Priority: Major > Fix For: 3.0.0, 2.25.0 > > Attachments: ClientChannelHandler.java, HttpClientChannelHandler.java > > > When using netty4-http as a client we have a problem when the server side > answers with a http 100-Continue. We expected the client to handle that > internally and continue the call but it's actually returning http 100. > This is handled by Nettys own channel handlers but since the Camel > HttpClientChannelHandler/ClientChannelHandler stop waiting when a http > 100-Continue arrives it doesn't help. > In the project I'm working with we made a custom ClientInitilizer and made > some small changes in the HttpClientChannelHandler and ClientChannelHandler > that just "ignores" the http 100-Continue when it arrives to solve this issue. > See the attached files to see our solution > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14069) netty4-http - Add logic to handle http 100-Continue
[ https://issues.apache.org/jira/browse/CAMEL-14069?focusedWorklogId=332503=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-332503 ] ASF GitHub Bot logged work on CAMEL-14069: -- Author: ASF GitHub Bot Created on: 23/Oct/19 09:04 Start Date: 23/Oct/19 09:04 Worklog Time Spent: 10m Work Description: zhfeng commented on pull request #3276: CAMEL-14069 Update to ignore the 100-Continue response and continue to URL: https://github.com/apache/camel/pull/3276 wait for the answer https://issues.apache.org/jira/browse/CAMEL-14069 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 332503) Remaining Estimate: 0h Time Spent: 10m > netty4-http - Add logic to handle http 100-Continue > --- > > Key: CAMEL-14069 > URL: https://issues.apache.org/jira/browse/CAMEL-14069 > Project: Camel > Issue Type: Improvement > Components: camel-netty4, camel-netty4-http >Affects Versions: 2.24.0 >Reporter: Göran Erkstam >Assignee: Zheng Feng >Priority: Major > Fix For: 3.0.0, 2.25.0 > > Attachments: ClientChannelHandler.java, HttpClientChannelHandler.java > > Time Spent: 10m > Remaining Estimate: 0h > > When using netty4-http as a client we have a problem when the server side > answers with a http 100-Continue. We expected the client to handle that > internally and continue the call but it's actually returning http 100. > This is handled by Nettys own channel handlers but since the Camel > HttpClientChannelHandler/ClientChannelHandler stop waiting when a http > 100-Continue arrives it doesn't help. > In the project I'm working with we made a custom ClientInitilizer and made > some small changes in the HttpClientChannelHandler and ClientChannelHandler > that just "ignores" the http 100-Continue when it arrives to solve this issue. > See the attached files to see our solution > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14100) camel-main: routes collector to support patters/globs
Luca Burgazzoli created CAMEL-14100: --- Summary: camel-main: routes collector to support patters/globs Key: CAMEL-14100 URL: https://issues.apache.org/jira/browse/CAMEL-14100 Project: Camel Issue Type: Improvement Components: camel-main Reporter: Luca Burgazzoli Fix For: 3.x With spring boot is is possible to collect routes using a pattern [1] like: classpath:*.xml It would be nice to have the same behaviours wit camel-main [2]. [1] https://github.com/apache/camel/blob/master/components/camel-spring-boot/src/main/java/org/apache/camel/spring/boot/SpringBootRoutesCollector.java#L113-L135 [2] https://github.com/apache/camel/blob/master/core/camel-main/src/main/java/org/apache/camel/main/DefaultRoutesCollector.java#L95-L115 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14101) json-jackson dataformat: potential ObjectMapper configuration clashes
Luca Burgazzoli created CAMEL-14101: --- Summary: json-jackson dataformat: potential ObjectMapper configuration clashes Key: CAMEL-14101 URL: https://issues.apache.org/jira/browse/CAMEL-14101 Project: Camel Issue Type: Improvement Components: camel-jackson Reporter: Luca Burgazzoli Fix For: 3.x The current default behaviour of the json-jackson data format is to try to lookup an ObjectMapper instance to the registry and if not found to create a new one. In case one is found, the data format instance does customize it according to its local properties but as the same ObjectMapper instance could be shared among different json-jackson data formats, it may lead to inconsistencies or unpredictable behaviors. It would be nice to either: - disable auto discovery by default so user can opt in - if an ObjectMapper is given or found from the registry, discard local customizations and log a warning/throw an error -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CAMEL-14101) json-jackson dataformat: potential ObjectMapper configuration clashes
[ https://issues.apache.org/jira/browse/CAMEL-14101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reassigned CAMEL-14101: Assignee: Andrea Cosentino > json-jackson dataformat: potential ObjectMapper configuration clashes > - > > Key: CAMEL-14101 > URL: https://issues.apache.org/jira/browse/CAMEL-14101 > Project: Camel > Issue Type: Improvement > Components: camel-jackson >Reporter: Luca Burgazzoli >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 3.x > > > The current default behaviour of the json-jackson data format is to try to > lookup an ObjectMapper instance to the registry and if not found to create a > new one. > In case one is found, the data format instance does customize it according to > its local properties but as the same ObjectMapper instance could be shared > among different json-jackson data formats, it may lead to inconsistencies or > unpredictable behaviors. > It would be nice to either: > - disable auto discovery by default so user can opt in > - if an ObjectMapper is given or found from the registry, discard local > customizations and log a warning/throw an error -- This message was sent by Atlassian Jira (v8.3.4#803005)
