Hi Sergey, We finally developed a small project reproducing the issue. Please find it in following Github repo
https://github.com/adrian-rosello/opennaas-blueprint-sync It includes a README file explaning how to reproduce the issue, as well as the environment where we tested it. If you have any doubt, or you need additional information, please let us know. All the best, Adrián Roselló 2013/10/24 Georg Mansky-Kummert <[email protected]> > Hi, Sergey! > > We discussed your reproduction request and came to the conclusion that > it is a good idea to make an effort to writing a separate, small project to > reproduce this issue. As soon as we have results, we are going to let you > know! > > Regards, > Georg > > On Oct 23, 2013, at 3:14 PM, Sergey Beryozkin wrote: > > > 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 <[email protected]> > >>> Date: October 22, 2013 8:40:48 AM GMT+02:00 > >>> To: dana-dev <[email protected]> > >>> Subject: [Dana Dev] Fwd: problem exporting OSGI service using DOSGI > >>> > >>> > >>> > >>> ---------- Forwarded message ---------- > >>> From: Sergey Beryozkin <[email protected]> > >>> Date: 2013/10/21 > >>> Subject: Re: problem exporting OSGI service using DOSGI > >>> To: [email protected] > >>> > >>> > >>> 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 <[email protected]> > >>> > >>> 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 <[email protected]> > >>> > >>> On 17 October 2013 18:00, Sergey Beryozkin <[email protected]> > >>> 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 > >>> [email protected] > >>> 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 > >> > >> > >> > >> > >> > > > > --- > Georg Mansky-Kummert > Distributed Applications and Networks Area (DANA) > i2CAT Foundation, Barcelona, Spain > http://dana.i2cat.net > > > > >
