Re: problem exporting OSGI service using DOSGI

[Sergey Beryozkin]

Hi Georg

Thanks for getting back re this issue.
Sure, I understand it is tricky to get a test project based on OpenNaaS 
produced :-).

What would really help now if you could do a "Hello World" kind of 
project, completely bypassing OpenNasS. For example, have 2 DOSGI RS 
Blueprint bundles, one with "/rs/1" and another with "/rs/2" HTTP 
contexts, both bundles having some basic JAX-RS resource and see if the 
same issue persists outside of your production environment.

That will really help us isolate the initial issue and for our experts 
to prioritize on it.

Thanks, Sergey

On 23/10/13 07:28, Georg Mansky-Kummert wrote:
Hi Sergey,

   I'm sorry having to write you that coming up with a basic test project for 
this problem is not easily done, at least not based on our project, OpenNaaS.  
Nevertheless we can send you a description of how to reproduce the issue using 
OpenNaaS, but that's a lengthy process, which we feel would not help in pinning 
down the problem rapidly. If there's anything else we can contribute to 
reproducing the issue, we are more than happy to do that!

   Hoping to hear from you soon, kind regards,
Georg

Begin forwarded message:

From: Adrián Roselló Rey <adrian.rose...@i2cat.net>
Date: October 22, 2013 8:40:48 AM GMT+02:00
To: dana-dev <dana-...@listas.i2cat.net>
Subject: [Dana Dev] Fwd: problem exporting OSGI service using DOSGI



---------- Forwarded message ----------
From: Sergey Beryozkin <sberyoz...@gmail.com>
Date: 2013/10/21
Subject: Re: problem exporting OSGI service using DOSGI
To: users@cxf.apache.org


Hi, by the way, can you give me a favor and attach some basic test project to 
DOSGi issue ? I guess it makes no difference how two bundles are created, i.e, 
for the simplicity, you can probably have both DOSGI service endpoints declared 
in XML and the same issue would still be observed unless that Karaf property is 
commented out ?

It will help us in trying to reproduce the issue.

Thanks, Sergey


On 21/10/13 16:00, Sergey Beryozkin wrote:
Hi Adrián Roselló,

On 21/10/13 14:54, Adrián Roselló Rey wrote:
Hi Sergey,

Thanks for your quick response. I tested your suggestion, but I didn't
make
it works.

But we discovered something. Several days ago, we had some problems to
start one of our project's feature, due to dependencies between bundles
using JPA. After looking for some information, we discovered the
following
issue https://issues.apache.org/jira/browse/KARAF-1002

Basically, by adding the following propertiy in etc/config.propertries
file, the bundle is not started, but scheduled.

"org.apache.aries.blueprint.synchronous=true"

Just for testing, we commented this line again, and all services were
published by DOSGI again.

Thanks for experimenting with it all, this is very helpful.
It appears to me that having that property enabled by default causes the
side-effects, so I wonder, should that Karaf issue be re-opened ?


We were wondering if this information is usefull for you in order to see
what could be happening, since we don't know DOSGI and CXF so much ;)

This is not a DOSGi for sure, and I doubt that it is a CXF issue either.
Dan, do you reckon it could be of concern to CXF, specifically, is there
some code in CXF that may not be dealing with this correctly ?
That appears to be unlikely to me, if the bundles installed concurrently
are getting published as expected, why would a synchronous orderly
installation cause CXF Blueprint code to fail ?

Thanks, Sergey


Thanks again!

Cheers,

Adrián Roselló


2013/10/18 Sergey Beryozkin <sberyoz...@gmail.com>

Hi

I wonder if it is the same 'CXFServlet overriding the endpoint
address by
default' issue which gets in the way now. In fact I don't think this is
even possible to disable in DOSGI if no default CXF Servlet is used.

Lets try this option for now:
- remove "org.apache.cxf.rs.**httpservice.context" properties from both
registrations, and set "org.apache.cxf.rs.address" to "/serviceA" and
"/serviceB" respectively.

in Karaf/etc/org.apache.cxf.osgi.**cfg file set:

org.apache.cxf.servlet.**context=/myservice/myapp
org.apache.cxf.servlet.**disable-address-updates=true

This should lead to the default CXFServlet listening on
"/myservice/myapp"
register 2 endpoints and block the default overriding of the endpoint
address.

Can you give it a try please ?

Cheers, Sergey


On 18/10/13 08:37, Adrián Roselló Rey wrote:

Hi Sergey, David

Thanks for your suggestions. I installed the bundles you mentioned
and its
dependencies, and I could start our platform without problems, but the
extrange behaviour with DOSGI is still there, even though in logs we
can
read "Successfully registered CXF DOSGi servlet at xxxx" for all our
services.

Cheers,

Adrián Roselló


2013/10/17 David Bosschaert <david.bosscha...@gmail.com>

   On 17 October 2013 18:00, Sergey Beryozkin <sberyoz...@gmail.com>
wrote:

though this issue needs to be fixed for 2.7.8


I would recommend trying to get the maven-bundle-plugin/bnd to compute
the imports... That way you can't forget them going forward.
It's not 100% foolproof, you still need to check that the imports are
what you want, because if you use the automatic computation you might
inadvertently import additional things that you didn't intend to
import if you accidentally use them, but I think in general, and also
for the imported versions, it's a safer thing to do...

Cheers,

David










_______________________________________________
Dana-dev mailing list
dana-...@listas.i2cat.net
http://listas.i2cat.net/cgi-bin/mailman/listinfo/dana-dev

---
Georg Mansky-Kummert
Team Lead Professional Services
Distributed Applications and Networks Area (DANA)
i2CAT Foundation, Barcelona, Spain
http://dana.i2cat.net