Re: RESTful web service in Karaf using CXF and blueprint

[Tim Ward]

If the services that you're looking to provide use JAX-RS the there is a 
specification proposal for OSGi R7 that you should look at. Prototyping work is 
starting in Apache Aries now.

Tim

Sent from my iPhone

> On 15 Aug 2016, at 18:56, Scott Lewis  wrote:
> 
>> On 8/15/2016 10:28 AM, Christian Schneider wrote:
>> 
>> 
>> ECF also supports CXF now but I am not sure at what level of CXF features.
> 
> This provider [1], will support all of the jax-rs Configurable/Configuration 
> capabilities that CXF supports.   It will also be possible to extend [1] to 
> create a custom provider, which are of course free use any of CXF's APIs.   
> Same with Jersey.
> 
> Scott
> 
> [1] 
> https://github.com/ECF/JaxRSProviders/tree/master/bundles/org.eclipse.ecf.provider.cxf.server
> 
>> 
>> Christian
>> 
>> 2016-08-15 17:21 GMT+02:00 Marc Durand :
>>> Hello,
>>> I was following Christian's tutorial here:
>>> http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi
>>> 
>>> And I also found come blog posts from JB that show how to deploy RESTful
>>> services using blueprint.
>>> 
>>> What I couldn't find was an example on how to deploy a RESTful service where
>>> the resource class is an OSGi service (to take advantage of SCR references
>>> to other services in the resource class).  I was able to do it by using a
>>>  element instead of a  element in the blueprint file.  Is
>>> this approach correct or will it lead to other problems down the road?
>>> 
>>> Thanks!
>>> Marc
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
>>> Sent from the Karaf - User mailing list archive at Nabble.com.
>> 
>> 
>> 
>> -- 
>> -- 
>> Christian Schneider
>> http://www.liquid-reality.de
>> 
>> Open Source Architect
>> http://www.talend.com
> 

Re: Karaf 4.0.5 - No subshell in remote connection?

[Jean-Baptiste Onofré]

OK I gonna reproduce and investigate. I'm sure it worked at least on 4.0.3 
afair.

Regards
JB



On Aug 15, 2016, 14:42, at 14:42, Erwin Hogeweg  wrote:
>I does not, and it is reproducible on Mac.
>
>Erwin
>
>> On Aug 15, 2016, at 09:35, Jean-Baptiste Onofré 
>wrote:
>> 
>> Hi
>> 
>> Does it work when starting Karaf using bin/karaf ?
>> 
>> Regards
>> JB
>> 
>> On Aug 15, 2016, at 14:05, Erwin Hogeweg > wrote:
>> All -
>> 
>> I don’t see the subshells when I connect from a remote machine.
>Either by opening the gogo shell in web console or logging in from an
>ssh connection. This is the standard karaf user with all the default
>settings. Is there another permission that needs to be enabled? I
>checked the 4.0 manual but I didn’t see it. Did I miss something?
>> 
>> BTW… karaf is running as a Windows service. Could that have something
>to do with it? There are no msgs in the log indicating that something
>went wrong.
>> 
>> 
>> Thanks.
>> 
>> 
>> karaf@root>completion subshell 
>> karaf@root>feature
>> karaf@root>help
>> export-bundles Export all of the bundles that make up a specified
>feature to a directory on the file system.
>> info   Shows information about selected feature.
>> installInstalls a feature with the specified name and
>version.
>> list   Lists all existing features available from the
>defined repositories.
>> 

Re: RESTful web service in Karaf using CXF and blueprint

[Scott Lewis]

On 8/15/2016 10:28 AM, Christian Schneider wrote:



ECF also supports CXF now but I am not sure at what level of CXF features.


This provider [1], will support all of the jax-rs 
Configurable/Configuration capabilities that CXF supports.   It will 
also be possible to extend [1] to create a custom provider, which are of 
course free use any of CXF's APIs.   Same with Jersey.


Scott

[1] 
https://github.com/ECF/JaxRSProviders/tree/master/bundles/org.eclipse.ecf.provider.cxf.server




Christian

2016-08-15 17:21 GMT+02:00 Marc Durand >:


Hello,
I was following Christian's tutorial here:

http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi



And I also found come blog posts from JB that show how to deploy
RESTful
services using blueprint.

What I couldn't find was an example on how to deploy a RESTful
service where
the resource class is an OSGi service (to take advantage of SCR
references
to other services in the resource class).  I was able to do it by
using a
 element instead of a  element in the blueprint
file.  Is
this approach correct or will it lead to other problems down the road?

Thanks!
Marc




--
View this message in context:

http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html


Sent from the Karaf - User mailing list archive at Nabble.com.




--
--
Christian Schneider
http://www.liquid-reality.de 



Open Source Architect
http://www.talend.com 

Re: RESTful web service in Karaf using CXF and blueprint

[Benson Margulies]

Christian, you might recall that I got into problems with
configuration issues, and you plan to address the issues I ran into in
2.0. I can dig that mail up again if you don't still have it. Thus
'not ready yet.'

On Mon, Aug 15, 2016 at 1:30 PM, Christian Schneider
 wrote:
> Hi Benson,
>
> would be great to get some feedback about your experiences using dOSGi. As
> we are approaching the 2.0 version now is the best time to get important
> features in.
>
> Christian
>
> 2016-08-15 19:24 GMT+02:00 Benson Margulies :
>>
>> Correct. I tried the dOSGi stuff, and it wasn't really ready to do
>> what I needed to do.
>>
>> On Mon, Aug 15, 2016 at 1:17 PM, David Jencks 
>> wrote:
>> > Just to see if I understand what you are doing, this approach does not
>> > involve the osgi service registry in any way for the REST service
>> > implementation object?  You are directly registering the component instance
>> > with CXF, and there is no need for it to expose any service interfaces at
>> > all?
>> >
>> > thanks
>> > david jencks
>> >
>> >> On Aug 15, 2016, at 10:10 AM, Benson Margulies 
>> >> wrote:
>> >>
>> >> I do this by making DS @Activate methods call the CXF API to publish
>> >> REST services.
>> >>
>> >>
>> >> On Mon, Aug 15, 2016 at 1:08 PM, Scott Lewis 
>> >> wrote:
>> >>> Hi Marc,
>> >>>
>> >>> The OSGi Remote Services specification (and the associated Remote
>> >>> Service
>> >>> Admin sepc) defines a standardized way to export OSGi services for
>> >>> remote
>> >>> access.   The specification is defined in a way that allows the use of
>> >>> arbitrary distribution providers that are responsible for making the
>> >>> OSGi
>> >>> service accessible from outside of the OSGi process.
>> >>>
>> >>> ECF [1] has an implementation of these specs that supports many
>> >>> distribution
>> >>> providers [2], including two that I'm working on now that supports any
>> >>> Jax-RS implementation (i.e. both CXF and Jersey).   These two
>> >>> distribution
>> >>> providers are here [3] and I'm finalizing them for an initial release.
>> >>> Note that for these providers, in addition to specifying jax-rs
>> >>> resources
>> >>> via OSGi services, the jax-rs configuration (e.g.
>> >>> MessageBodyReader/Writers,
>> >>> Features, etc) can also be specified via OSGi services.
>> >>>
>> >>> Scott
>> >>>
>> >>> [1] https://wiki.eclipse.org/ECF
>> >>> [2] https://wiki.eclipse.org/Distribution_Providers
>> >>> [3] https://github.com/ECF/JaxRSProviders
>> >>>
>> >>> On 8/15/2016 8:21 AM, Marc Durand wrote:
>> 
>>  Hello,
>>  I was following Christian's tutorial here:
>> 
>> 
>>  http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi
>> 
>>  And I also found come blog posts from JB that show how to deploy
>>  RESTful
>>  services using blueprint.
>> 
>>  What I couldn't find was an example on how to deploy a RESTful
>>  service
>>  where
>>  the resource class is an OSGi service (to take advantage of SCR
>>  references
>>  to other services in the resource class).  I was able to do it by
>>  using a
>>   element instead of a  element in the blueprint
>>  file.  Is
>>  this approach correct or will it lead to other problems down the
>>  road?
>> 
>>  Thanks!
>>  Marc
>> 
>> 
>> 
>> 
>>  --
>>  View this message in context:
>> 
>>  http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
>>  Sent from the Karaf - User mailing list archive at Nabble.com.
>> >>>
>> >>>
>> >>>
>> >
>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com

Re: RESTful web service in Karaf using CXF and blueprint

[Christian Schneider]

Hi Benson,

would be great to get some feedback about your experiences using dOSGi. As
we are approaching the 2.0 version now is the best time to get important
features in.

Christian

2016-08-15 19:24 GMT+02:00 Benson Margulies :

> Correct. I tried the dOSGi stuff, and it wasn't really ready to do
> what I needed to do.
>
> On Mon, Aug 15, 2016 at 1:17 PM, David Jencks 
> wrote:
> > Just to see if I understand what you are doing, this approach does not
> involve the osgi service registry in any way for the REST service
> implementation object?  You are directly registering the component instance
> with CXF, and there is no need for it to expose any service interfaces at
> all?
> >
> > thanks
> > david jencks
> >
> >> On Aug 15, 2016, at 10:10 AM, Benson Margulies 
> wrote:
> >>
> >> I do this by making DS @Activate methods call the CXF API to publish
> >> REST services.
> >>
> >>
> >> On Mon, Aug 15, 2016 at 1:08 PM, Scott Lewis 
> wrote:
> >>> Hi Marc,
> >>>
> >>> The OSGi Remote Services specification (and the associated Remote
> Service
> >>> Admin sepc) defines a standardized way to export OSGi services for
> remote
> >>> access.   The specification is defined in a way that allows the use of
> >>> arbitrary distribution providers that are responsible for making the
> OSGi
> >>> service accessible from outside of the OSGi process.
> >>>
> >>> ECF [1] has an implementation of these specs that supports many
> distribution
> >>> providers [2], including two that I'm working on now that supports any
> >>> Jax-RS implementation (i.e. both CXF and Jersey).   These two
> distribution
> >>> providers are here [3] and I'm finalizing them for an initial release.
> >>> Note that for these providers, in addition to specifying jax-rs
> resources
> >>> via OSGi services, the jax-rs configuration (e.g.
> MessageBodyReader/Writers,
> >>> Features, etc) can also be specified via OSGi services.
> >>>
> >>> Scott
> >>>
> >>> [1] https://wiki.eclipse.org/ECF
> >>> [2] https://wiki.eclipse.org/Distribution_Providers
> >>> [3] https://github.com/ECF/JaxRSProviders
> >>>
> >>> On 8/15/2016 8:21 AM, Marc Durand wrote:
> 
>  Hello,
>  I was following Christian's tutorial here:
> 
>  http://liquid-reality.de/display/liquid/2011/12/22/
> Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi
> 
>  And I also found come blog posts from JB that show how to deploy
> RESTful
>  services using blueprint.
> 
>  What I couldn't find was an example on how to deploy a RESTful service
>  where
>  the resource class is an OSGi service (to take advantage of SCR
> references
>  to other services in the resource class).  I was able to do it by
> using a
>   element instead of a  element in the blueprint
> file.  Is
>  this approach correct or will it lead to other problems down the road?
> 
>  Thanks!
>  Marc
> 
> 
> 
> 
>  --
>  View this message in context:
>  http://karaf.922171.n3.nabble.com/RESTful-web-service-in-
> Karaf-using-CXF-and-blueprint-tp4047529.html
>  Sent from the Karaf - User mailing list archive at Nabble.com.
> >>>
> >>>
> >>>
> >
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com

Re: RESTful web service in Karaf using CXF and blueprint

[Christian Schneider]

 The tutorial uses blueprint to publish the service and uses the CXF
namespace for blueprint. This is currently the most flexible approach as it
supports all features of CXF. It is limited to blueprint though.

If you want to use DS to annotate your service and do injections then like
Scott described Remote Service Admin is the better choice as DS is not
directly supported by CXF. If you want to expose SOAP and REST services
then CXF DOSGi provides a quite complete support for the CXF features. The
upcoming version 2.0 of CXF DOSGi will be slimmer in footprint and support
even more CXF features so it will be almost en par with CXF blueprint. It
allows to define almost all CXF settings using intents (Databinding,
binding, SSL, security, Rest providers, Logging, CXF features, http
conduits).

ECF also supports CXF now but I am not sure at what level of CXF features.

Christian

2016-08-15 17:21 GMT+02:00 Marc Durand :

> Hello,
> I was following Christian's tutorial here:
> http://liquid-reality.de/display/liquid/2011/12/22/
> Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi
>
> And I also found come blog posts from JB that show how to deploy RESTful
> services using blueprint.
>
> What I couldn't find was an example on how to deploy a RESTful service
> where
> the resource class is an OSGi service (to take advantage of SCR references
> to other services in the resource class).  I was able to do it by using a
>  element instead of a  element in the blueprint file.  Is
> this approach correct or will it lead to other problems down the road?
>
> Thanks!
> Marc
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com

Re: RESTful web service in Karaf using CXF and blueprint

[Benson Margulies]

Correct. I tried the dOSGi stuff, and it wasn't really ready to do
what I needed to do.

On Mon, Aug 15, 2016 at 1:17 PM, David Jencks  wrote:
> Just to see if I understand what you are doing, this approach does not 
> involve the osgi service registry in any way for the REST service 
> implementation object?  You are directly registering the component instance 
> with CXF, and there is no need for it to expose any service interfaces at all?
>
> thanks
> david jencks
>
>> On Aug 15, 2016, at 10:10 AM, Benson Margulies  wrote:
>>
>> I do this by making DS @Activate methods call the CXF API to publish
>> REST services.
>>
>>
>> On Mon, Aug 15, 2016 at 1:08 PM, Scott Lewis  wrote:
>>> Hi Marc,
>>>
>>> The OSGi Remote Services specification (and the associated Remote Service
>>> Admin sepc) defines a standardized way to export OSGi services for remote
>>> access.   The specification is defined in a way that allows the use of
>>> arbitrary distribution providers that are responsible for making the OSGi
>>> service accessible from outside of the OSGi process.
>>>
>>> ECF [1] has an implementation of these specs that supports many distribution
>>> providers [2], including two that I'm working on now that supports any
>>> Jax-RS implementation (i.e. both CXF and Jersey).   These two distribution
>>> providers are here [3] and I'm finalizing them for an initial release.
>>> Note that for these providers, in addition to specifying jax-rs resources
>>> via OSGi services, the jax-rs configuration (e.g. MessageBodyReader/Writers,
>>> Features, etc) can also be specified via OSGi services.
>>>
>>> Scott
>>>
>>> [1] https://wiki.eclipse.org/ECF
>>> [2] https://wiki.eclipse.org/Distribution_Providers
>>> [3] https://github.com/ECF/JaxRSProviders
>>>
>>> On 8/15/2016 8:21 AM, Marc Durand wrote:

 Hello,
 I was following Christian's tutorial here:

 http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi

 And I also found come blog posts from JB that show how to deploy RESTful
 services using blueprint.

 What I couldn't find was an example on how to deploy a RESTful service
 where
 the resource class is an OSGi service (to take advantage of SCR references
 to other services in the resource class).  I was able to do it by using a
  element instead of a  element in the blueprint file.  Is
 this approach correct or will it lead to other problems down the road?

 Thanks!
 Marc




 --
 View this message in context:
 http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
 Sent from the Karaf - User mailing list archive at Nabble.com.
>>>
>>>
>>>
>

Re: RESTful web service in Karaf using CXF and blueprint

[David Jencks]

Just to see if I understand what you are doing, this approach does not involve 
the osgi service registry in any way for the REST service implementation 
object?  You are directly registering the component instance with CXF, and 
there is no need for it to expose any service interfaces at all?

thanks
david jencks

> On Aug 15, 2016, at 10:10 AM, Benson Margulies  wrote:
> 
> I do this by making DS @Activate methods call the CXF API to publish
> REST services.
> 
> 
> On Mon, Aug 15, 2016 at 1:08 PM, Scott Lewis  wrote:
>> Hi Marc,
>> 
>> The OSGi Remote Services specification (and the associated Remote Service
>> Admin sepc) defines a standardized way to export OSGi services for remote
>> access.   The specification is defined in a way that allows the use of
>> arbitrary distribution providers that are responsible for making the OSGi
>> service accessible from outside of the OSGi process.
>> 
>> ECF [1] has an implementation of these specs that supports many distribution
>> providers [2], including two that I'm working on now that supports any
>> Jax-RS implementation (i.e. both CXF and Jersey).   These two distribution
>> providers are here [3] and I'm finalizing them for an initial release.
>> Note that for these providers, in addition to specifying jax-rs resources
>> via OSGi services, the jax-rs configuration (e.g. MessageBodyReader/Writers,
>> Features, etc) can also be specified via OSGi services.
>> 
>> Scott
>> 
>> [1] https://wiki.eclipse.org/ECF
>> [2] https://wiki.eclipse.org/Distribution_Providers
>> [3] https://github.com/ECF/JaxRSProviders
>> 
>> On 8/15/2016 8:21 AM, Marc Durand wrote:
>>> 
>>> Hello,
>>> I was following Christian's tutorial here:
>>> 
>>> http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi
>>> 
>>> And I also found come blog posts from JB that show how to deploy RESTful
>>> services using blueprint.
>>> 
>>> What I couldn't find was an example on how to deploy a RESTful service
>>> where
>>> the resource class is an OSGi service (to take advantage of SCR references
>>> to other services in the resource class).  I was able to do it by using a
>>>  element instead of a  element in the blueprint file.  Is
>>> this approach correct or will it lead to other problems down the road?
>>> 
>>> Thanks!
>>> Marc
>>> 
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
>>> Sent from the Karaf - User mailing list archive at Nabble.com.
>> 
>> 
>> 

Re: RESTful web service in Karaf using CXF and blueprint

[Benson Margulies]

I do this by making DS @Activate methods call the CXF API to publish
REST services.


On Mon, Aug 15, 2016 at 1:08 PM, Scott Lewis  wrote:
> Hi Marc,
>
> The OSGi Remote Services specification (and the associated Remote Service
> Admin sepc) defines a standardized way to export OSGi services for remote
> access.   The specification is defined in a way that allows the use of
> arbitrary distribution providers that are responsible for making the OSGi
> service accessible from outside of the OSGi process.
>
> ECF [1] has an implementation of these specs that supports many distribution
> providers [2], including two that I'm working on now that supports any
> Jax-RS implementation (i.e. both CXF and Jersey).   These two distribution
> providers are here [3] and I'm finalizing them for an initial release.
> Note that for these providers, in addition to specifying jax-rs resources
> via OSGi services, the jax-rs configuration (e.g. MessageBodyReader/Writers,
> Features, etc) can also be specified via OSGi services.
>
> Scott
>
> [1] https://wiki.eclipse.org/ECF
> [2] https://wiki.eclipse.org/Distribution_Providers
> [3] https://github.com/ECF/JaxRSProviders
>
> On 8/15/2016 8:21 AM, Marc Durand wrote:
>>
>> Hello,
>> I was following Christian's tutorial here:
>>
>> http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi
>>
>> And I also found come blog posts from JB that show how to deploy RESTful
>> services using blueprint.
>>
>> What I couldn't find was an example on how to deploy a RESTful service
>> where
>> the resource class is an OSGi service (to take advantage of SCR references
>> to other services in the resource class).  I was able to do it by using a
>>  element instead of a  element in the blueprint file.  Is
>> this approach correct or will it lead to other problems down the road?
>>
>> Thanks!
>> Marc
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>
>
>

Re: RESTful web service in Karaf using CXF and blueprint

[Scott Lewis]

Hi Marc,

The OSGi Remote Services specification (and the associated Remote 
Service Admin sepc) defines a standardized way to export OSGi services 
for remote access.   The specification is defined in a way that allows 
the use of arbitrary distribution providers that are responsible for 
making the OSGi service accessible from outside of the OSGi process.


ECF [1] has an implementation of these specs that supports many 
distribution providers [2], including two that I'm working on now that 
supports any Jax-RS implementation (i.e. both CXF and Jersey).   These 
two distribution providers are here [3] and I'm finalizing them for an 
initial release.   Note that for these providers, in addition to 
specifying jax-rs resources via OSGi services, the jax-rs configuration 
(e.g. MessageBodyReader/Writers, Features, etc) can also be specified 
via OSGi services.


Scott

[1] https://wiki.eclipse.org/ECF
[2] https://wiki.eclipse.org/Distribution_Providers
[3] https://github.com/ECF/JaxRSProviders

On 8/15/2016 8:21 AM, Marc Durand wrote:

Hello,
I was following Christian's tutorial here:
http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi

And I also found come blog posts from JB that show how to deploy RESTful
services using blueprint.

What I couldn't find was an example on how to deploy a RESTful service where
the resource class is an OSGi service (to take advantage of SCR references
to other services in the resource class).  I was able to do it by using a
 element instead of a  element in the blueprint file.  Is
this approach correct or will it lead to other problems down the road?

Thanks!
Marc




--
View this message in context: 
http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
Sent from the Karaf - User mailing list archive at Nabble.com.

RESTful web service in Karaf using CXF and blueprint

[Marc Durand]

Hello,
I was following Christian's tutorial here:
http://liquid-reality.de/display/liquid/2011/12/22/Karaf+Tutorial+Part+4+-+CXF+Services+in+OSGi

And I also found come blog posts from JB that show how to deploy RESTful
services using blueprint.  

What I couldn't find was an example on how to deploy a RESTful service where
the resource class is an OSGi service (to take advantage of SCR references
to other services in the resource class).  I was able to do it by using a
 element instead of a  element in the blueprint file.  Is
this approach correct or will it lead to other problems down the road?

Thanks!
Marc




--
View this message in context: 
http://karaf.922171.n3.nabble.com/RESTful-web-service-in-Karaf-using-CXF-and-blueprint-tp4047529.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: How do mvn: urls end up in classpaths in Karaf 4.0.5?

[Benson Margulies]

One other factoid:

When I don't use "#methodname" to select a method, I do see a few of
these IllegalStateExceptions go by for things like configadmin and
sshd. They don't even result in log traffic. When I use the #, that
adds a guice jar file, and the result is a fail.


On Mon, Aug 15, 2016 at 10:34 AM, Benson Margulies  wrote:
> Folks,
>
> I just upgraded my build to use pax-exam 4.9.1. And I got a very
> strange problem.
>
> If I run a single function test method:
>
>   mvn 
> -Dit.test=com.basistech.ws.itest.AnvilsRealComponentIT"#complexEntityRouting"
>
> my code dies, because an mvn: URL leaks out.
>
> This happens when Guice is referencing one of its classes, and the
> class load fails.
>
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm
> throws an IllegalStateException due to getting an mvn: URL as the
> class source location. Does anyone have any clues as to what to look
> at here?
>
>
> java.lang.Thread.State: RUNNABLE
>  at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)
>  at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
>  at java.net.URL.toExternalForm(URL.java:922)
>  at java.net.URL.toString(URL.java:908)
>  at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:675)
>  at java.lang.ClassLoader.defineClass(ClassLoader.java:759)
>  at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)
>  at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)
>  at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)
>  at 
> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>  at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>  at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>  at 
> com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:166)
>  at 
> com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
>  - locked <0x2409> (a com.google.inject.internal.InheritingState)
>  at com.google.inject.Guice.createInjector(Guice.java:96)
>  at com.google.inject.Guice.createInjector(Guice.java:73)
>  at com.google.inject.Guice.createInjector(Guice.java:62)
>  at 
> com.basistech.rosette.relax.RelationshipAnnotatorFactory.initializeInternal(RelationshipAnnotatorFactory.java:130)
>  - locked <0x23da> (a 
> com.basistech.rosette.relax.RelationshipAnnotatorFactory)
>  at 
> com.basistech.rosette.relax.RelationshipAnnotatorFactory.initialize(RelationshipAnnotatorFactory.java:111)
>  at 
> com.basistech.relax.osgi.impl.RelaxComponentService$Factory.(RelaxComponentService.java:121)
>  at 
> com.basistech.relax.osgi.impl.RelaxComponentService.createFactory(RelaxComponentService.java:85)
>  at 
> com.basistech.rosette.osgi.util.AbstractComponentService.createFactory(AbstractComponentService.java:47)
>  at 
> com.basistech.ws.worker.api.AbstractWorkerDocumentComponentService.configureOneFactory(AbstractWorkerDocumentComponentService.java:82)
>  at 
> com.basistech.ws.worker.api.AbstractWorkerDocumentComponentService.init(AbstractWorkerDocumentComponentService.java:57)
>  at com.basistech.ws.worker.core.Worker.configureComponent(Worker.java:223)
>  at com.basistech.ws.worker.core.Worker.lambda$activate$12(Worker.java:179)
>  a

How do mvn: urls end up in classpaths in Karaf 4.0.5?

[Benson Margulies]

Folks,

I just upgraded my build to use pax-exam 4.9.1. And I got a very
strange problem.

If I run a single function test method:

  mvn 
-Dit.test=com.basistech.ws.itest.AnvilsRealComponentIT"#complexEntityRouting"

my code dies, because an mvn: URL leaks out.

This happens when Guice is referencing one of its classes, and the
class load fails.

org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm
throws an IllegalStateException due to getting an mvn: URL as the
class source location. Does anyone have any clues as to what to look
at here?


java.lang.Thread.State: RUNNABLE
 at 
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)
 at 
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
 at java.net.URL.toExternalForm(URL.java:922)
 at java.net.URL.toString(URL.java:908)
 at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:675)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:759)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)
 at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)
 at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
 at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
 at 
com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:166)
 at 
com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
 - locked <0x2409> (a com.google.inject.internal.InheritingState)
 at com.google.inject.Guice.createInjector(Guice.java:96)
 at com.google.inject.Guice.createInjector(Guice.java:73)
 at com.google.inject.Guice.createInjector(Guice.java:62)
 at 
com.basistech.rosette.relax.RelationshipAnnotatorFactory.initializeInternal(RelationshipAnnotatorFactory.java:130)
 - locked <0x23da> (a com.basistech.rosette.relax.RelationshipAnnotatorFactory)
 at 
com.basistech.rosette.relax.RelationshipAnnotatorFactory.initialize(RelationshipAnnotatorFactory.java:111)
 at 
com.basistech.relax.osgi.impl.RelaxComponentService$Factory.(RelaxComponentService.java:121)
 at 
com.basistech.relax.osgi.impl.RelaxComponentService.createFactory(RelaxComponentService.java:85)
 at 
com.basistech.rosette.osgi.util.AbstractComponentService.createFactory(AbstractComponentService.java:47)
 at 
com.basistech.ws.worker.api.AbstractWorkerDocumentComponentService.configureOneFactory(AbstractWorkerDocumentComponentService.java:82)
 at 
com.basistech.ws.worker.api.AbstractWorkerDocumentComponentService.init(AbstractWorkerDocumentComponentService.java:57)
 at com.basistech.ws.worker.core.Worker.configureComponent(Worker.java:223)
 at com.basistech.ws.worker.core.Worker.lambda$activate$12(Worker.java:179)
 a

Re: Introducing blueprint-test

[Matt Pavlovich]

Thanks =)  I'll get the patch to Aries knocked out this week.

There is a little cruft in the helper/util classes, but that can be 
trimmed out without impacting users as time goes on.


On 8/15/16 9:05 AM, James Carman wrote:
This is cool, Matt! I am sure a lot of us have already gone through 
this hassle, but I have not seen it formalized yet. Good work!


On Mon, Aug 15, 2016 at 9:51 AM Matt Pavlovich > wrote:


This blueprint-test is useful for testing blueprints that do
*/not/* contain Camel routes.  The camel-test-blueprint requires a
Camel route to startup, so it can't be used as a general purpose
blueprint test library.

-Matt Pavlovich


On 8/14/16 7:59 AM, Jean-Baptiste Onofré wrote:


What's the purpose exactly ?

I wrote a blog about camel blueprint testing already a while ago ?

Regards
JB

On Aug 12, 2016, at 10:11, Matt Pavlovich > wrote:

I've taken Camel Test Blueprint and removed all the Camel parts to have
a self-contained library that allows for quick testing of blueprint
files. Thought folks here might find it handy (please excuse the
x-post). I opened a JIRA with Aries Blueprint for inclusion into 
upstream.

Code:https://github.com/mattrpav/blueprint-test

Aries JIRA:https://issues.apache.org/jira/browse/ARIES-1592

-Matt

Re: Introducing blueprint-test

[James Carman]

This is cool, Matt! I am sure a lot of us have already gone through this
hassle, but I have not seen it formalized yet. Good work!

On Mon, Aug 15, 2016 at 9:51 AM Matt Pavlovich  wrote:

> This blueprint-test is useful for testing blueprints that do *not*
> contain Camel routes.  The camel-test-blueprint requires a Camel route to
> startup, so it can't be used as a general purpose blueprint test library.
> -Matt Pavlovich
>
>
> On 8/14/16 7:59 AM, Jean-Baptiste Onofré wrote:
>
> What's the purpose exactly ?
>
> I wrote a blog about camel blueprint testing already a while ago ?
>
> Regards
> JB
> On Aug 12, 2016, at 10:11, Matt Pavlovich  wrote:
>>
>> I've taken Camel Test Blueprint and removed all the Camel parts to have
>> a self-contained library that allows for quick testing of blueprint
>> files. Thought folks here might find it handy (please excuse the
>> x-post). I opened a JIRA with Aries Blueprint for inclusion into upstream.
>>
>> Code:https://github.com/mattrpav/blueprint-test
>>
>> Aries JIRA:https://issues.apache.org/jira/browse/ARIES-1592
>>
>> -Matt
>>
>>
>>
>

Re: Introducing blueprint-test

[Matt Pavlovich]

This blueprint-test is useful for testing blueprints that do */not/* 
contain Camel routes.  The camel-test-blueprint requires a Camel route 
to startup, so it can't be used as a general purpose blueprint test 
library.


-Matt Pavlovich

On 8/14/16 7:59 AM, Jean-Baptiste Onofré wrote:


What's the purpose exactly ?

I wrote a blog about camel blueprint testing already a while ago ?

Regards
JB

On Aug 12, 2016, at 10:11, Matt Pavlovich > wrote:


I've taken Camel Test Blueprint and removed all the Camel parts to have
a self-contained library that allows for quick testing of blueprint
files. Thought folks here might find it handy (please excuse the
x-post). I opened a JIRA with Aries Blueprint for inclusion into upstream.

Code:https://github.com/mattrpav/blueprint-test

Aries JIRA:https://issues.apache.org/jira/browse/ARIES-1592

-Matt

Re: Karaf 4.0.5 - No subshell in remote connection?

[Erwin Hogeweg]

I does not, and it is reproducible on Mac.

Erwin

> On Aug 15, 2016, at 09:35, Jean-Baptiste Onofré  wrote:
> 
> Hi
> 
> Does it work when starting Karaf using bin/karaf ?
> 
> Regards
> JB
> 
> On Aug 15, 2016, at 14:05, Erwin Hogeweg  > wrote:
> All -
> 
> I don’t see the subshells when I connect from a remote machine. Either by 
> opening the gogo shell in web console or logging in from an ssh connection. 
> This is the standard karaf user with all the default settings. Is there 
> another permission that needs to be enabled? I checked the 4.0 manual but I 
> didn’t see it. Did I miss something?
> 
> BTW… karaf is running as a Windows service. Could that have something to do 
> with it? There are no msgs in the log indicating that something went wrong.
> 
> 
> Thanks.
> 
> 
> karaf@root>completion subshell 
> karaf@root>feature
> karaf@root>help
> export-bundles Export all of the bundles that make up a specified feature 
> to a directory on the file system.
> info   Shows information about selected feature.
> installInstalls a feature with the specified name and version.
> list   Lists all existing features available from the defined 
> repositories.
> 

Re: 4.0.6 release

[James Carman]

That's great!  Thanks again, JB.  Let us know if there's something we can
help with.  :)


On Mon, Aug 15, 2016 at 9:32 AM Jean-Baptiste Onofré 
wrote:

> Hi James
>
> I plan to cut the release and submit to vote on Thursday. I have some work
> in progress.
>
> Regards
> JB
> On Aug 15, 2016, at 14:22, James Carman 
> wrote:
>>
>>

Re: Karaf 4.0.5 - No subshell in remote connection?

[Jean-Baptiste Onofré]

Hi

Does it work when starting Karaf using bin/karaf ?

Regards
JB



On Aug 15, 2016, 14:05, at 14:05, Erwin Hogeweg  wrote:
>All -
>
>I don’t see the subshells when I connect from a remote machine. Either
>by opening the gogo shell in web console or logging in from an ssh
>connection. This is the standard karaf user with all the default
>settings. Is there another permission that needs to be enabled? I
>checked the 4.0 manual but I didn’t see it. Did I miss something?
>
>BTW… karaf is running as a Windows service. Could that have something
>to do with it? There are no msgs in the log indicating that something
>went wrong.
>
>
>Thanks.
>
>
>karaf@root>completion subshell 
>karaf@root>feature
>karaf@root>help
>export-bundles Export all of the bundles that make up a specified
>feature to a directory on the file system.
>info   Shows information about selected feature.
>installInstalls a feature with the specified name and
>version.
>list   Lists all existing features available from the
>defined repositories.

Re: 4.0.6 release

[Jean-Baptiste Onofré]

Hi James

I plan to cut the release and submit to vote on Thursday. I have some work in 
progress.

Regards
JB



On Aug 15, 2016, 14:22, at 14:22, James Carman  
wrote:
>

Re: 4.0.6 release

[James Carman]

JB,

What's the current plan on 4.0.6?  I can hold off a release of my custom
container if it's happening relatively soon.  We'd love to have the proper
boot feature ordering stuff.  Thanks for getting 3.0.8 out so quickly, btw!

Thanks,

James

On Thu, Aug 4, 2016 at 9:17 AM Jean-Baptiste Onofré  wrote:

> Hi Jason,
>
> The plan is 3.0.8 end of this week and 4.0.6 end of next week (or
> beginning of the following one).
>
> Regards
> JB
>
> On 08/04/2016 03:00 PM, Jason Smith wrote:
> > Hello! Are there any updates on when 4.0.6 will be released?  Thanks
> >
> >
> >
> > -  Jason
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Karaf 4.0.5 - No subshell in remote connection?

[Erwin Hogeweg]

All -

I don’t see the subshells when I connect from a remote machine. Either by 
opening the gogo shell in web console or logging in from an ssh connection. 
This is the standard karaf user with all the default settings. Is there another 
permission that needs to be enabled? I checked the 4.0 manual but I didn’t see 
it. Did I miss something?

BTW… karaf is running as a Windows service. Could that have something to do 
with it? There are no msgs in the log indicating that something went wrong.


Thanks.


karaf@root>completion subshell 
karaf@root>feature
karaf@root>help
export-bundles Export all of the bundles that make up a specified feature 
to a directory on the file system.
info   Shows information about selected feature.
installInstalls a feature with the specified name and version.
list   Lists all existing features available from the defined 
repositories.

Re: Aries JPA 2.3.0: mapping file not used

[Timothy Ward]

There was a major rewrite of Aries JPA between version 1.x and 2.x. It appears 
as though the mapping file support was lost (I can find no reference to mapping 
files in the parser).

This is obviously something that needs to be fixed - is there any way that you 
can supply a simplified version of this as a test case?

Regards,

Tim

> On 12 Aug 2016, at 10:14, jochenw  wrote:
> 
> Sorry, forgot to mention that this happens with Karaf 4.0.4 and 4.0.5, and it
> is still the case when explicitly installing the JPA 2.4.0 features.
> 
> Regards,
> 
> Jochen
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Aries-JPA-2-3-0-mapping-file-not-used-tp4047501p4047507.html
> Sent from the Karaf - User mailing list archive at Nabble.com.