Re: Karaf 3,4 plans?

[Scott Lewis]

On 6/19/2014 1:59 AM, Jean-Baptiste Onofré wrote:
Yes, it is but not yet released (it will be included in 3.0.2). I 
talked about the current version in 3.0.1 (latest release).


I'm a little confused about framework versions and Karaf version.

Is the conclusion that 3.0.1 (latest release) does not have the Felix 
version that supports OSGi R5?   But some version of Felix that supports 
R5 will be included in Karaf 3.0.2?


If that's right:

1) When is Karaf 3.0.2 to be expected?
2) Which version of Felix will be included in 3.0.2?

Thanksinadvance,

Scott

Re: Karaf 3,4 plans?

[Scott Lewis]

On 6/20/2014 2:01 AM, Jean-Baptiste Onofré wrote:

Hi Benjamin,

If you follow the discussion on the dev mailing list, I think the 
release plan is well defined.


FWIW, it would be helpful to translate the release plan to the roadmap:

https://cwiki.apache.org/confluence/display/KARAF/Roadmap

There is lots of traffic on this mailing list that naturally has no 
connection to the release plans, and at least some of us cannot monitor 
the mailing list closely at all times.



More over on the website you have the dependency matrix.


That's great.  Perhaps a link to it on the Roadmap would help.

Scott

EIK bug

[Scott Lewis]

Hi Folks,

Using Karaf 3.0.2, Eclipse Luna SR1, and EIK 0.9.0, I'm experiencing the 
exception reported by this bug:


https://issues.apache.org/jira/browse/KARAF-2668

The bug was apparently resolved, but it's not clear to me from the 
comments whether it was resolved because:


1) EIK works on Karaf 2.x (and not 3.x)
2) EIK has a 0.10.0 snapshot version that fixes
3) Some other change to Karaf, Eclipse, and/or EIK

How can I most easily determine how to use EIK with Karaf 3.x? (and 
eventually 4.x hopefully)


Thanks,

Scott

Re: [DISCUSSION] Karaf Boot

[Scott Lewis]

On 9/10/2015 2:58 PM, Achim Nierbeck wrote:


The microservice dance

actually it's just add a rest-service on top of a OSGi service, that's all
that is needed in Karaf.
Right now I'm not in favor of any certain framework. CXF seems a bit
bloated but is known to work, but requires blueprint.
Jersey, I've seen that to be working with "plain" OSGi. A bit of polishing
and it should be quite easy to use, especially with CDI at hand.


I would suggest the use of OSGi Remote Services/RSA [1].   The Remote 
Services spec defines standard service properties triggering the export 
of the service via some unspecified distribution 
system/transport...typically in response to service registration done 
through whatever means...e.g. DS, java code, Dependency Manager, Spring, 
or anything else that uses the service registry. One of the standardized 
properties allows a distribution provider to be selected, separately for 
each service instance if needed.


Each distribution provider can be as small or large as required for the 
use case.  For example, ECF's RSA impl now supports using CXF, Jersey, 
or other Jax-RS implementations along with Hazelcast, rosgi, tcp, JMS, 
MQTT, and other providers [2].   Or if you need to you can create and 
use your own distribution provider.  In any case, the service won't be 
bound to any distribution provider or RSA impl on server or clients, and 
can be changed prior to service registration.


Scott

[1] http://www.osgi.org/Specifications/HomePage
[2] 
https://wiki.eclipse.org/Tutorial:_Using_REST_and_OSGi_Standards_for_Micro_Services

https://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service





But it needs more to dance the microservice dance, you need "small"
containers ... which is quite contrary to the way Karaf and OSGi in general
is working with services.
But this is the point I think the karaf profiles come in handy. You don't
need a full blown Karaf, just a basic infrastructure with your own Bundle,
might as well ignore the shell. In the end dump that into a docker
container and if you need to do a bugfix do it the "docker" - way.


spring-boot brings it all in one go

karaf-boot should do the same, but actually I fear we do more then needed.
For a new Project setup I'd rather would like to see different
karaf-starter-* BOMs and a karaf:run maven plugin
Some more docuementation for the profiles of Karaf could also be helpful :D
to build minimalistic karaf instances runnable in docker containers.
Regarding the karaf:run it might be interesting to "re-activate" the
pax:run maven plugin to run nicely with a karaf instance, or use it as
foundation for the karaf:run maven plugin.



So in the end, do we really need all this?
I'm not so sure, but we surely need an easier "to use" approach.
Therefore we should first focus on having easier setup of bundle
development.
-> karaf-boot-starter-* BOMs should take care of that
-> karaf:run should make it easier to have a running container

Do we need new annotations? I can't see that yet.
Instead we should/could focus on the following:
a) make sure DS also is capable to work with JPA/JTA and some other
enterprise annotations
b) make sure CDI works with runtime JPA/JTA annotation smoothly
c) provide more demos and archetypes with OSGi and CDI annotations


regards, Achim





2015-09-10 20:41 GMT+02:00 Jean-Baptiste Onofré :


Thanks Milen,

it's an open place to discussion. We just share standpoints and opinions:
that's the key part !!!

My goal is to give more traction on Karaf by providing easier

We all provide valid points, but I think we are not the most setted to
argue as we are deeply involved in OSGi and Karaf. The karaf-boot proto
came when discussing with new Karaf users, coming from "outside" of OSGi,
or people that decided to use spring-boot (even if they like a lot Karaf),
just because it's easier. It's hardly frustrating for us as we just need
some tooling to provide even more traction. On the container side, I think
Karaf is already great, and answers all needs. The part where we should
improve what we deliver is around developer tooling: easier, faster, key
turn.

If karaf-boot will be a success, I don't know (who knows ? ;)). But
anyway, it brings points, questions, and identify some missings in the
current picture.

My $0.01 ;)

Regards
JB


On 09/10/2015 08:02 PM, Milen Dyankov wrote:


Well I was just referring to your example but I get your point. Which
reminds me of EnRoute  project which despite
the
big names and the most popular OSGI build tool behind it, doesn't seem to
get as much traction as I expected!

That said, I really admire your enthusiasm and wish KarafBoot can be more
successful that that. I'm not trying to discourage you! Just it seams what
you are after is something that other people have tried already with
questionable success.

Best,
Milen



On Thu, Sep 10, 2015 at 7:22 PM, Jean-Baptiste Onofré 
wrote:

And how to you deal with jpa, jta, re

Re: [DISCUSSION] Karaf Boot

[Scott Lewis]

On 9/10/2015 11:14 PM, Christian Schneider wrote:
I agree with Scott that OSGi Remote Services is a good solution to 
publishing the Rest services. It also allows to consume Rest services 
in a similarly easy way.
For the spring boot like setup it makes sense to use a very ligth 
weight rest support by default.


We can also write an extender that scans annoations and publishes the 
rest services. It could be done a little bit smaller than ECF but I am 
not sure if the effort is worth it.


A couple of comments:

1) It's better if something intended to simplify life for programmers 
(e.g. remote services...or custom annotation/publishing) is 
cross-implementation (i.e. somehow 'standardized').   To me, this would 
favor something like RS/RSA over new/custom annotations to publish rest 
services, because multiple compliant impls already exist, a management 
agent (RSA) are already specified, implemented and compliant, technical 
subtleties are already dealt with (e.g. service dynamics, service 
versioning, remote service discovery, service-level security), someone 
else worries about impl, spec changes/update of standards, etc.


2) I'm of the view there is reason to be careful/deliberate about adding 
Karaf-specifc annotations in general (not just remote services/rest), as 
there are people that prefer other approaches, these days there are lots 
of annotations for different concerns...and there is a lot of resulting 
confusion about impl-specific annotations vs. standardized annotations, 
etc.  My recent experience with Jax-RS and impls has convinced me of this.


3) It would always be possible to add annotations *above* something like 
remote services that simply used/set standardized service properties as 
per the spec.


4) ECF is/has been attempting to introduce tooling (in Eclipse 
initially) that supports Remote Services dev and testing [1].   This 
effort is just beginning, but standardization (1) does help with 
parallel tooling efforts.


Scott

[1] https://www.eclipse.org/ecf/NewAndNoteworthy.html




Christian

Am 11.09.2015 um 00:40 schrieb Scott Lewis:

On 9/10/2015 2:58 PM, Achim Nierbeck wrote:


The microservice dance

actually it's just add a rest-service on top of a OSGi service, 
that's all

that is needed in Karaf.
Right now I'm not in favor of any certain framework. CXF seems a bit
bloated but is known to work, but requires blueprint.
Jersey, I've seen that to be working with "plain" OSGi. A bit of 
polishing

and it should be quite easy to use, especially with CDI at hand.


I would suggest the use of OSGi Remote Services/RSA [1].   The Remote 
Services spec defines standard service properties triggering the 
export of the service via some unspecified distribution 
system/transport...typically in response to service registration done 
through whatever means...e.g. DS, java code, Dependency Manager, 
Spring, or anything else that uses the service registry. One of the 
standardized properties allows a distribution provider to be 
selected, separately for each service instance if needed.


Each distribution provider can be as small or large as required for 
the use case.  For example, ECF's RSA impl now supports using CXF, 
Jersey, or other Jax-RS implementations along with Hazelcast, rosgi, 
tcp, JMS, MQTT, and other providers [2].   Or if you need to you can 
create and use your own distribution provider.  In any case, the 
service won't be bound to any distribution provider or RSA impl on 
server or clients, and can be changed prior to service registration.


Scott

[1] http://www.osgi.org/Specifications/HomePage
[2] 
https://wiki.eclipse.org/Tutorial:_Using_REST_and_OSGi_Standards_for_Micro_Services
https://wiki.eclipse.org/Tutorial:_Exposing_a_Jax_REST_service_as_an_OSGi_Remote_Service 







But it needs more to dance the microservice dance, you need "small"
containers ... which is quite contrary to the way Karaf and OSGi in 
general

is working with services.
But this is the point I think the karaf profiles come in handy. You 
don't
need a full blown Karaf, just a basic infrastructure with your own 
Bundle,

might as well ignore the shell. In the end dump that into a docker
container and if you need to do a bugfix do it the "docker" - way.


spring-boot brings it all in one go

karaf-boot should do the same, but actually I fear we do more then 
needed.

For a new Project setup I'd rather would like to see different
karaf-starter-* BOMs and a karaf:run maven plugin
Some more docuementation for the profiles of Karaf could also be 
helpful :D

to build minimalistic karaf instances runnable in docker containers.
Regarding the karaf:run it might be interesting to "re-activate" the
pax:run maven plugin to run nicely with a karaf instance, or use it as
foundation for the karaf:run maven plugin.



So in the end, do we really need all this?
I'm not so sure, but we surely need 

Re: karaf/cellar generic discovery service

[Scott Lewis]

ECF [0] has a stable network discovery API [1] and a number of providers 
based upon various protocols (zeroconf, etcd, slp, zookeeper, dnssd, 
custom).  We would welcome cooperative creation of other providers (e.g. 
based upon cellar).


The discovery API is used by ECF's implementation of OSGi Remote 
Services, allowing any discovery provider to be used to discover remote 
services.


Scott

[0] https://wiki.eclipse.org/ECF
[1] 
http://download.eclipse.org/rt/ecf/3.12.0/javadoc/org/eclipse/ecf/discovery/package-summary.html 


[2] https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF

On 12/30/2015 4:53 AM, lb wrote:

Hi all,

I'm wondering if it would make sense to extend current discovery service to
make it more generic and shareable among other services that need discovery
capabilities.

This may be achieved by adding some filtering capability to discoverMembers
i.e.

Collection discoverMembers(String domain)

How domain is used is implementation dependant (labels for kubernetes, path
for etcd, etc). Domain used by karaf clustering may be then defined in
hazelcast's service configuration file or wherever it make sense.

It would also be useful to have additional info about the discovery
services like all the kubernetes label or any additional attribute
associated with the discovered service.

What do you think ?

Re: karaf/cellar generic discovery service

[Scott Lewis]

On 12/30/2015 8:56 AM, Jean-Baptiste Onofré wrote:

Hi Scott,

good idea, as said early, we could provide Cellar ECF for both 
discovery and remote service (as an alternative to DOSGi).


That would be splendid.  I would certainly contribute to the creation of 
both a Cellar discovery and/or distribution provider.




Let me create a Jira and work on a PoC about that.


Please feel free to add me to the Jira and/or contact me directly. Just 
FYI, ECF has github repos [1] in addition to the EF-hosted repos 
[2]...so we can be flexible about where things are developed.


Scott

[1] https://github.com/ECF
[2] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/



Regards
JB

On 12/30/2015 05:08 PM, Scott Lewis wrote:

ECF [0] has a stable network discovery API [1] and a number of providers
based upon various protocols (zeroconf, etcd, slp, zookeeper, dnssd,
custom).  We would welcome cooperative creation of other providers (e.g.
based upon cellar).

The discovery API is used by ECF's implementation of OSGi Remote
Services, allowing any discovery provider to be used to discover remote
services.

Scott

[0] https://wiki.eclipse.org/ECF
[1]
http://download.eclipse.org/rt/ecf/3.12.0/javadoc/org/eclipse/ecf/discovery/package-summary.html 



[2] https://wiki.eclipse.org/OSGi_Remote_Services_and_ECF

On 12/30/2015 4:53 AM, lb wrote:

Hi all,

I'm wondering if it would make sense to extend current discovery
service to
make it more generic and shareable among other services that need
discovery
capabilities.

This may be achieved by adding some filtering capability to
discoverMembers
i.e.

Collection discoverMembers(String domain)

How domain is used is implementation dependant (labels for kubernetes,
path
for etcd, etc). Domain used by karaf clustering may be then defined in
hazelcast's service configuration file or wherever it make sense.

It would also be useful to have additional info about the discovery
services like all the kubernetes label or any additional attribute
associated with the discovered service.

What do you think ?

Re: Proposal - Lightweight standalone remote OSGi implementation for karaf-cellar

[Scott Lewis]

Hi Sascha,

On 2/12/2016 7:42 AM, Sascha Vogt wrote:

Hi all,

we (a colleague of mine and myself) started searching for a
high-performance / lightweight remote OSGi implementation. We have a
requirement that the implementation has to /also/ (in addition to Karaf)
run on a heavily customized JBoss 7.1.1 as well, so the lightweight part
was kinda important ;)

We stumbled accross http://moi.vonos.net/java/dosgi-fabric/ which talks
about using the "old" dosgi implementation from Fabric8 (former Fuse
ESB). We had a look and we really liked it. Performance wise it comes
really close to RMI with about 30% overhead at 10k invocations of a
service sending back and forth a simple string on the same host. Using
different hosts the times were identical. Yes I know, that's not a
"real" use case, but it made us confident in taking a deeper look. It
also only has two external dependencies (hawtdispatch and hawtbuf, both
ASL-2 licensed).

So now the proposal: Resurrect the old Fabric8 implementation, directly
at the karaf-cellar subproject. As the copyright of the original code
belongs to RedHat, Guillaume could you ask internally if the following
resources could be donated to the Karaf project?


https://github.com/fabric8io/fabric8/tree/4d878d1f47226a2c3fb77aeee76814419f5edce0

Paths

/fabric/fabric-dosgi
/fabric/fabric-api/src/main/java/io/fabric8/api/ManagedCuratorFrameworkAvailable.java
/fabric/fabric-api/src/main/java/io/fabric8/api/scr/Configurer.java
/fabric/fabric-api/src/main/java/io/fabric8/api/scr/ValidatingReference.java
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/utils/ZooKeeperUtils.java
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/Constants.java
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/CuratorConfig.java
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/CuratorFrameworkLocator.java
/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/ManagedCuratorFramework.java

Test-Dependecies paths

/fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/bootstrap/BootstrapConfiguration.java
/fabric/fabric-api/src/main/java/io/fabric8/api/Container.java
/fabric/fabric-api/src/main/java/io/fabric8/api/ContainerOptions.java
/fabric/fabric-api/src/main/java/io/fabric8/api/HasId.java
/fabric/fabric-api/src/main/java/io/fabric8/api/ZkDefs.java
/fabric/fabric-api/src/main/java/io/fabric8/api/RuntimeProperties.java
/fabric/fabric-api/src/main/java/io/fabric8/api/DataStore.java
/fabric/fabric-api/src/main/java/io/fabric8/api/DataStoreTemplate.java
/fabric/fabric-zookeeper-spring/src/main/java/io/fabric8/zookeeper/spring/ZKServerFactoryBean.java

The test dependencies could probably be done without, if they provide
too big of a hassle, though it's better to start with running tests ;)
They would also go into fabric-dosgi/src/test/java/...

Given that RedHat would be willing to donate the code, we (mainly
Johannes and me, both working for SEEBURGER AG) would work on it with
the following roadmap in mind:

1. Make the implementation remote OSGi compatible (implement the defined
interfaces, etc.)
2. Make the discovery exchangeable (so Zookeeper becomes an optional
dependency). We need that part, as we have our own database based
discovery, not really usable for the rest of the world. This would also
allow to replace the currently available remote OSGi impl in Karaf and
using the Cellar internals for discovery.
3. That is a bigger step / work and needs to be discussed further. There
are at least two possible options
3. a) Inline the needed parts of hawt* as they seem to be an abandoned
project too.
3. b) Make the transport exchangeable so the dependency to hawtbuf /
hawtdispatch becomes optional and provide our own implementation

Regarding hawt and option 3.a) inlining it: Guillaume do you know who
owns the copyright to that? I assume also RedHat? Maybe those could also
be donated?

@all: What are your thoughts on that?


I would suggest simply creating a new distribution provider for ECF's 
remote services/RSA implementation (fully spec compliant and 
CT-tested).  In terms of the spec/standards, what was called 
'distributed osgi' is now called 'remote services/remote service admin'.


Background:  In addition to a fully compliant implementation, ECF has 
pluggable distribution and discovery providers [1].   This has allowed 
us and others to create a growing set of providers that are based upon 
various transports (e.g. distribution:  CXF, Jersey, r-OSGi, 
ActiveMQ/JMS, Hazelcast, MQTT, custom REST, generic, others; discovery: 
Zookeeper, etcd, SLP, DNSSD, zeroconf, EDEF, others) [2].  These are the 
ones we know about...there can/could be others that we are not aware 
of.   It would be great to have additional providers, both for discovery 
(Cellar?), and others either in open source or not.


One major advantage:   There's no need for new providers (discovery or 
distribution) to consult the spec to create RS/RSA-compliant

Re: Proposal - Lightweight standalone remote OSGi implementation for karaf-cellar

[Scott Lewis]

On 2/16/2016 7:12 AM, Johannes Utzig wrote:

OK, I made it further (I had an issue with SCR).
Now I got my remote service running with ECF using 'ecf.generic.server'.
I then tried to switch to 'ecf.r_osgi.peer'. It looks like the service is
exported, the provider side shows:




Yes, the r-osgi provider (by default) exports all EventAdmin topics and 
unfortunately Eclipse RCP apps send events to topics that cannot be 
serialized.



Now I am down to these errors on consumer side:

ChannelEndpoint;(factory=ch.ethz.iks.r_osgi.impl.TCPChannelFactory@31cdb74a,endpointAddress=r-osgi://UTZIGJ02.seeb
urger.de:9278)
ChannelEndpoint;(channel=TCPChannel
(r-osgi://UTZIGJ02.seeburger.de:62762);remoteAddress=r-osgi://UTZIGJ02.seeburg
er.de:62762;localAddress=r-osgi://UTZIGJ02.seeburger.de:9278)
ChannelEndpoint;send(msg=[LEASE] - XID: 18695, services: , topics:
[];remoteAddress=r-osgi://UTZIGJ02.seeburger.de:9278)

ChannelEndpoint;handleMessage(msg=[LEASE] - XID: 18695, services: , topics:
[];remoteAddress=r-osgi://UTZIGJ02.seeburger
.de:62762)
ChannelEndpoint;reply(msg=[LEASE] - XID: 18695, services: , topics:
[];remoteAddress=r-osgi://UTZIGJ02.seeburger.de:6276


2016-02-16 16:08:51,074 | WARN  | cator Dispatcher | remoteserviceadmin
| 60 - org.eclipse.ecf.osgi.services.remoteserviceadmin -
4.3.300.v20160114-0324 |
org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.osgi.services.remoteserviceadmin;code=2;message=org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin:doImportService:getRemoteServiceReferences
return null for
targetID=r-osgi://UTZIGJ02.seeburger.de:9278,idFilter=[Lorg.eclipse.ecf.core.identity.ID;@2c1c090f,intf=com.seeburger.remote.osgi.MyRemoteService,rsFilter=(&(ecf.rsvc.id=240))
on
rsContainerID=r-osgi://UTZIGJ02.seeburger.de:9278;severity2;exception=null;children=[]]
2016-02-16 16:08:51,075 | ERROR | cator Dispatcher | remoteserviceadmin
| 60 - org.eclipse.ecf.osgi.services.remoteserviceadmin -
4.3.300.v20160114-0324 |
org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.osgi.services.remoteserviceadmin;code=4;message=org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin:importService:selectRemoteServiceReference
returned null for
rsRefs=[],targetID=r-osgi://UTZIGJ02.seeburger.de:9278,idFilter=[Lorg.eclipse.ecf.core.identity.ID;@2c1c090f,interfaces=[com.seeburger.remote.osgi.MyRemoteService],rsFilter=(&(ecf.rsvc.id=240)),rsContainerID=r-osgi://UTZIGJ02.seeburger.de:9278;severity4;exception=RemoteReferenceNotFoundException[targetID=r-osgi://UTZIGJ02.seeburger.de:9278,
idFilter=[r-osgi://UTZIGJ02.seeburger.de:9278],
interfaces=[com.seeburger.remote.osgi.MyRemoteService],
rsFilter=(&(ecf.rsvc.id=240))];children=[]]
RemoteReferenceNotFoundException[targetID=r-osgi://UTZIGJ02.seeburger.de:9278,
idFilter=[r-osgi://UTZIGJ02.seeburger.de:9278],
interfaces=[com.seeburger.remote.osgi.MyRemoteService],
rsFilter=(&(ecf.rsvc.id=240))]
at
org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.importService(RemoteServiceAdmin.java:2388)[60:org.eclipse.ecf.osgi.services.remoteserviceadmin:4.3.300.v20160114-0324]
at
org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.importService(RemoteServiceAdmin.java:440)[60:org.eclipse.ecf.osgi.services.remoteserviceadmin:4.3.300.v20160114-0324]
at
org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.handleECFEndpointAdded(AbstractTopologyManager.java:295)[60:org.eclipse.ecf.osgi.services.remoteserviceadmin:4.3.300.v20160114-0324]
at
org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.handleEndpointAdded(BasicTopologyManagerImpl.java:104)[59:org.eclipse.ecf.osgi.services.distribution:2.1.0.v20160114-0324]
at
org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.endpointChanged(BasicTopologyManagerImpl.java:181)[59:org.eclipse.ecf.osgi.services.distribution:2.1.0.v20160114-0324]
at
org.eclipse.ecf.internal.osgi.services.distribution.Activator$ProxyEndpointEventListener.deliverSafe(Activator.java:206)[59:org.eclipse.ecf.osgi.services.distribution:2.1.0.v20160114-0324]
at
org.eclipse.ecf.internal.osgi.services.distribution.Activator$ProxyEndpointEventListener.endpointChanged(Activator.java:183)[59:org.eclipse.ecf.osgi.services.distribution:2.1.0.v20160114-0324]
at
org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator$1.dispatchEvent(EndpointDescriptionLocator.java:219)[60:org.eclipse.ecf.osgi.services.remoteserviceadmin:4.3.300.v20160114-0324]
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
at
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
2016-02-16 16:08:51,080 | ERROR | cator Dispatcher | remoteserviceadmin
| 60 - org.eclipse.ecf.osgi.services.remoteserviceadmin -
4.3.300.v2016011

Re: Proposal - Lightweight standalone remote OSGi implementation for karaf-cellar

[Scott Lewis]

On 2/16/2016 9:20 AM, Johannes Utzig wrote:

Thank you for your swift response.
I see what you mean. I think r-OSGi (at least combined with zookeeper
discovery) isn't really meant to run between two instances on the same
machine.


Yes, that's correct.


However, since r-OSGi ended up killing my karaf instance quite a few times I
think this is probably not a transport we'd want to employ right now.

Instead I switched to ecf.generic.server which works out of the box.

I ran our simple benchmark which calls a remote service 1000 times with 5
parallel threads and compares the execution time with RMI (each call sends
and receives a string array).

ecf.generic.server seems to be roughly 10 times slower than RMI, but the
strange part is, with each invocation it becomes slower. Please see the test
output below:

karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 6838 milliseconds. Parallel level is
5
Test parallel RMI completed in 829 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 6188 milliseconds. Parallel level is
5
Test parallel RMI completed in 649 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 8024 milliseconds. Parallel level is
5
Test parallel RMI completed in 190 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 10415 milliseconds. Parallel level is
5
Test parallel RMI completed in 190 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 12628 milliseconds. Parallel level is
5
Test parallel RMI completed in 176 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 14125 milliseconds. Parallel level is
5
Test parallel RMI completed in 184 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 16330 milliseconds. Parallel level is
5
Test parallel RMI completed in 191 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 18014 milliseconds. Parallel level is
5
Test parallel RMI completed in 189 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 21011 milliseconds. Parallel level is
5
Test parallel RMI completed in 186 milliseconds. Parallel level is 5
karaf@root()> benchmark:run 1000 5 utzigj02
Test parallel remote OSGi completed in 22741 milliseconds. Parallel level is
5
Test parallel RMI completed in 190 milliseconds. Parallel level is 5

This persists until I restart the karaf instance that provides the service.


Would it be possible for you to make this test/benchmark code 
available?   We haven't seen this pattern before, and I would like to 
use it to determine what is going on.





We are looking for perfomance similar to RMI and the fabric implementation
was able to provide that.
Now to my understanding we could implement a distribution provider based on
the fabric code that could be used by ECF.


Yes, that's right.


Unfortunately, I am a bit unsure on how to do this. I looked at
https://wiki.eclipse.org/Tutorial:_Creating_a_RESTful_Remote_Service_Provider
and a lot of additional documentation but so far I am still a bit unsure on
how to proceed or which is the minimal set of dependencies I would need.
I also noticed that the ECF artifacts on maven central are very outdated, so
I probably cannot use them to compile against. Are there plans to publish
up-to-date artifacts to central for easier consumption?


We routinely make a maven repository available as part of our releases 
[1].  The primary reason why we don't put these on maven central is that 
we are currently not able to include the dependencies that we have on 3 
equinox 'extra' bundles.  FWIW we would very much like to get this 
worked out an publish regularly to maven central but the equinox deps 
make this complicated.





Would this serve as a mimimal example on how to implement a new TCP based
distribution provider, or should I use a different implementation as a
template?
https://github.com/eclipse/ecf/tree/master/providers/bundles/org.eclipse.ecf.provider.r_osgi/src/org/eclipse/ecf/internal/provider/r_osgi


We have recently created a distribution provider API [2] (see toward 
end) in order to make it easier to create custom providers and register 
them via the whiteboard pattern.There is dependency information 
about the bundle containing this API (org.eclipse.ecf.remoteservice) on 
this new documentation page [3].


As for existing providers as examples, I would suggest looking at the 
providers that have recently been created using this new distribution 
provider API [4].


I am in the process of creating a tutorial about the use of this new 
distribution provider API.   If

Re: Proposal - Lightweight standalone remote OSGi implementation for karaf-cellar

[Scott Lewis]

On 2/16/2016 9:47 AM, Scott Lewis wrote:

On 2/16/2016 9:20 AM, Johannes Utzig wrote:

Thank you for your swift response.
I see what you mean. I think r-OSGi (at least combined with zookeeper
discovery) isn't really meant to run between two instances on the same
machine.


Yes, that's correct.


I wasn't particularly clear with this.   The default r-osgi transport is 
indeed not really meant to run between two instances on same machine.


We have, however, also created an rosgi transport replacement based upon 
websockets [1].   With two additional rosgi bundles, the rosgi provider 
can be used in a manner more amenable to running two instances on the 
same machine (as well as having other advantages depending upon use case).


Scott

[1] https://github.com/ECF/Websockets

Re: Proposal - Lightweight standalone remote OSGi implementation for karaf-cellar

[Scott Lewis]

On 2/16/2016 11:27 AM, Johannes Utzig wrote:

Scott Lewis wrote

Would it be possible for you to make this test/benchmark code
available?   We haven't seen this pattern before, and I would like to
use it to determine what is going on.

Absolutely. It is very basic stuff. I will extract the pieces into a github
repo and post it tomorrow.

Thank you very much for the pointer to those examples, that looks much
easier to digest than the r-OSGi implementation.
I will need a little time to read into the example code and would post again
once I am (hopefully) getting somewhere.


Of course.   If you wish, please feel free to contact me directly at 
slewis at composent.com for direct support, or for connections to other 
ECF commiters and contributors responsible for respective components of ECF.


Scott

Re: Proposal - Lightweight standalone remote OSGi implementation for karaf-cellar

[Scott Lewis]

On 2/22/2016 8:01 AM, Christian Schneider wrote:

Aries sounds like a good place for this.

In the mean time I looked a bit into the CXF DOSGi code. I think we 
can split off the CXF part. So what remains is discovery support for 
zookeeper and local discovery
and a core RemoteServiceAdmin impl that can be enhanced with providers 
like CXF or for example an RMI or Hazelcast one.
I have extracted the interface the providers would need to implement. 
I think we should be fine with something like blow. The details of the 
interface of course can be discussed but the classes below
is what CXF DOSGi would need for the CXF support and it looks like 
other providers should be possible too with such informations.


I also think that ECF has a similar set of interfaces. Maybe we can 
even sync with them.


Yes it does.   ECF has an API called the 'remote services API' 
(org.eclipse.ecf.remoteservices bundle) [1], that the ECF Remote Service 
Admin implementation uses to export and import remote services (using 
whatever topology manager).   All providers (us and others) implement 
the appropriate parts of this remote services API, and they then may be 
used as R6+-compliant RSA implementations...with any desired discovery 
and/or topology manager.


The ECF remote service API has dependencies as described here [2].We 
would be happy to support and/or enhance/extend as needed to sync up.


Scott

[1] http://download.eclipse.org/rt/ecf/3.12.1/javadoc/index.html
[2] http://wiki.eclipse.org/Distribution_Providers#Remote_Services_API



So if this code is independent from CXF and implements an OSGi 
specification it would fit great into Aries.
I have not yet looked into the Redhat code but I think at the very 
least we could take the RMI impl from there.


Christian


public interface ConfigurationTypeHandler {

public Object createProxy(
ServiceReference reference,
BundleContext bundleContext,
Class interfaceClass,
EndpointDescription endpoint);

public ExportResult createServer(
ServiceReference serviceReference,
BundleContext bundleContext,
Map serviceProperties,
Class interfaceClass,
Object service);

}
---
public class ExportResult {
private Map eProps;
private Closeable server;
private Throwable ex;

public ExportResult(Map eProps, Closeable server) {
this.eProps = eProps;
this.server = server;
}

public ExportResult(Map eProps, Throwable ex) {
this.ex = ex;
}

public Throwable getException() {
return ex;
}

public Closeable getServer() {
return server;
}

public Map getEndpointProps() {
return eProps;
}

}


On 22.02.2016 15:52, Guillaume Nodet wrote:
You see things backward. RedHat has not proposed to donate the code. 
I've been asked on this list if RedHat would actually donate the 
code. That's quite different. As for why the code suits Johannes and 
Sasha's need better than the CXF or the Cellar one, I'm sure they can 
answer that part if not already done. And you're right we don't 
really need to start any legal stuff at this point. We first need to 
decide if the Karaf community wants this code along with 2 committers 
to maintain it. Actually, I think Aries may be a better choice for 
this code, especially if the goal is to somehow merge efforts from 
CXF / Karaf communities.

Kind regards,
Łukasz
—
l...@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org

Re: Enabling compression of HTTP responses when using osgi-jax-rs-connector

[Scott Lewis]

There appear to be standardized Jax-RS annotations to support 
compression via interceptors [1].


As Jax-RS impls, I would expect that interceptors would be supported by 
either Jersey or CXF of appropriate version, but have not tested either 
impl.


Scott

[1] 
https://jersey.java.net/documentation/latest/filters-and-interceptors.html



On 7/8/2016 11:34 AM, Marc Durand wrote:

I am not sure how a CXF annotation can work in my case - I am not using CXF
at all.  I am using Jersey and OSGI-JAX-RS-Connector.

On Fri, Jul 8, 2016 at 2:12 PM, Benson Margulies 
wrote:


org.apache.cxf.annotations.GZIP

On Fri, Jul 8, 2016 at 2:05 PM, Marc Durand  wrote:

Thanks Benson for the quick response.  What is the package name of that
annotation?

Marc

On Fri, Jul 8, 2016 at 1:46 PM, Benson Margulies 
wrote:


@GZIP on the resource class works for me.


On Fri, Jul 8, 2016 at 1:44 PM, Marc Durand 

wrote:

I have successfully added a gzip filter to the default web container

in

Karaf

and responses coming from regular servlets are compressed.  This

filter

does

not seem to apply to REST responses that are produced through the
osgi-jax-rs-connector bundle.  How can I enable compression of REST
responses in Karaf?

Thanks in advance!
Marc



--
View this message in context:

http://karaf.922171.n3.nabble.com/Enabling-compression-of-HTTP-responses-when-using-osgi-jax-rs-connector-tp4047174.html

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

Re: OSGi related PoC and Karaf

[Scott Lewis]

On 6/14/2017 4:46 AM, Milen Dyankov wrote:

Hi Karaf developers,

I'd like to ask you to have a look at something I've been working on. It's
a PoC called Eccentric Modularity (EM) and it's available here
https://github.com/azzazzel/EM


FWIW:I think your example would be improved by using OSGi remote 
services specs for the remote service metadata (e.g. provide/require 
capability, standardized remote service properties, etc) rather than the 
jax-rs connector specifically.   It would also then allow for supporting 
osgi remote service dynamics, service versioning, rs discovery, etc.


Scott

Re: OSGi related PoC and Karaf

[Scott Lewis]

On 6/15/2017 1:24 AM, Milen Dyankov wrote:

Thanks Scott,

I was looking into that some time ago but AFAIK it comes in R7. Not sure if
thete is anything released at this point that would work with R6.


Were you saying 'there'?   The OSGi remote services and RSA specs have 
been quite stable since R5 (chap 100 and 122 in compendium).


The Jax-RS distribution provider impls that I'm aware of are ECF's 
[1].   It supports Jersey's or CXF's Jax-RS impls.


I will attempt to work on a reworking of your POC remote service 
metadata for a pull request, after the upcoming ECF release (June 28 I 
think).


Scott

[1] https://github.com/ECF/JaxRSProviders


So for
now I just decided to go with what I know works. But if you have practical
experience with this spec, pull request would be more than welcome.

Best,
Milen




14 cze 2017 18:59 "Scott Lewis"  napisał(a):

On 6/14/2017 4:46 AM, Milen Dyankov wrote:


Hi Karaf developers,

I'd like to ask you to have a look at something I've been working on. It's
a PoC called Eccentric Modularity (EM) and it's available here
https://github.com/azzazzel/EM


FWIW:I think your example would be improved by using OSGi remote
services specs for the remote service metadata (e.g. provide/require
capability, standardized remote service properties, etc) rather than the
jax-rs connector specifically.   It would also then allow for supporting
osgi remote service dynamics, service versioning, rs discovery, etc.

Scott