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 <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 >> >> >> >> >> > --- Georg Mansky-Kummert Distributed Applications and Networks Area (DANA) i2CAT Foundation, Barcelona, Spain http://dana.i2cat.net
