Dietmar Wolz Another issue: do we need to use ManagedServiceFactorys? They can be used to configure multiple instances of the same service. This is uncommon in our scenario, so it seems not necessary to support this concept in Swordfish, but maybe someone else can envision its use in Swordfish? Maybe we can defer this until we really see an application needing the concept.
Guillaume Nodet is that the same as what we've done in servicemix ?
we've done that months ago: https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/
in a better way imho (the api does not add any public class and does not need any extra steps on the client bundle
also, the implementation can be swapped if needed
so the bundle using the stax api does not know anything about the implementation
Volodymyr Zhabiuk Thanks Guillaume, we will try this solution
Guillaume Nodet we haven't done jpa though, but we can do it quite easily
Oliver Wolf ok, then i would just have to file CQs for these additional bundles... the ones in the eclipse orbit are just plain old-style-JARs converted into bundles without any changes to the factory mechanism
BTW, nice to see you here, Guillaume
Volodymyr Zhabiuk the solution proposed by Guillaume works in our case.
But regretfully, we need the stax-api library with version 1.0.1. SMX guys did only 1.0. Besides still there is a classcast problem (com.sun.xml.bind.v2.runtime.JAXBContextImpl) inside the cxf bundle
Andrey Kopachevsky I would propose for the time been to user 2 extension bundles I've just created to fix jaxb and jaxp implementation lookup problem (at least it works now without exceptions), and later definitely make scene to proceed with Guillaume's solution adaptation, other vise I could start with adaptation right now
Guillaume Nodet what's the difference between stax 1.0 and 1.0.1 ?
i don't think there is any public api changes
it was only about fixing the discovery mechanism, which is bypassed when using osgi anyway
from the stax.codehaus.org web site: 13-Mar-2006: Stax API 1.0.1 maintenance release: fixes one critical implementation problem in XMLInputFactory implementation detection (jaxp.properties that existed but missed stax impl entry threw NullPointerException). No changes to API or javadocs.
Volodymyr Zhabiuk Probably there is no difference, but other bundles that we download from public maven repos are dependent on this particular version
Guillaume Nodet you could exclude the unneeded versions though ...
Volodymyr Zhabiuk Don't know if I understood you correctly, do u propose to modify MANIFEST files inside that bundles?
we will try to find bundles that do not rely on that version but it will take time and efforts
Guillaume Nodet oh, you mean they import the osgi package with a 1.0.1 version ?
Volodymyr Zhabiuk yep
Guillaume Nodet well, we could have a 1.0.1 stax api in smx if that can help
Volodymyr Zhabiuk Maybe at first we will try to replace that bundles. If we would fail we will ask you to add the 1.0.1 stax api. Thanks
@Oliver: It would be great to set up the continous integration and snapshot repository for the Swordfish. Could we engage someone from the sopera team to do it?
Dietmar Wolz i put the initial configuration and event handling ppts to our svn under org.eclipse.swordfish.design.docs, please commit changes there. As soon as Volodymyr is commiter (should happen this week) we plan to switch to https://dev.eclipse.org/svnroot/rt/org.eclipse.swordfish to enable public access
Volodymyr Zhabiuk What about Andrey?
Andrey Kopachevsky I've created account on eclipse bugzilla
Dietmar Wolz Oliver will initiate Andreys commiter election soon. In between we have to find a solution - maybe Andrey sends stuff to you, Volodymyr and you check it in?
Tel.: +49 228-182 19059
Fax: +49 228-182 19093
Mobil: +49 160 98931313
SOPERA GmbH - Open Source SOA
Subscription Services, Support & Maintenance, Training,
Technical SOA Consulting & Customized Development
SOPERA GmbH · Geschäftsführer: Dr. Ricco Deutscher, Harald Weimer, Peter Spiegel
Standort Bonn: Sträßchensweg 10 · 53113 Bonn · Handelsregister: Bonn HRB 15336
Standort München: Hohenlindnerstraße 11b · 85622 München
Vertraulichkeitshinweis: Diese Nachricht und jeder übermittelte Anhang beinhaltet vertrauliche Informationen und ist nur für die Personen oder das Unternehmen bestimmt, an welche sie tatsächlich gerichtet ist. Sollten Sie nicht der Bestimmungsempfänger sein, weisen wir Sie darauf hin, dass die Verbreitung, das (auch teilweise) Kopieren sowie der Gebrauch der empfangenen E-Mail und der darin enthaltenen Informationen gesetzlich verboten ist und gegebenenfalls Schadensersatzpflichten auslösen kann. Sollten Sie diese Nachricht aufgrund eines Übermittlungsfehlers erhalten haben, bitten wir Sie, den Sender unverzüglich hiervon in Kenntnis zu setzen.