So this is broken in 2.x trunk as well then, so i'm still feeling at this late stage this just missed the M3 boat. From whats been said it sounds like the options are:
1) just pull the dosgi samples from M3 and get them working for the next release 2) fix whatever is broken in trunk, merge those changes into M3, and if that means we need a new bundle plugin release start that now and run it in parallel with the M3 votes 3) fix whatever is broken in trunk, merge those changes into M3, and if that means we need a new bundle plugin release then change the release processes so the bundle plugin is released as part of the sca release. I'm not kean on (3) as i think there's a lot of potential for delaying M3. So (1) seems easiest to me but i guess (2) could work too is its started real soon ...ant On Mon, Jun 22, 2009 at 5:53 PM, Raymond Feng <[email protected]> wrote: > Not really. I just downloaded the distro and confirmed the issue related to > woden-impl-dom: > > Steps to reproduce the issue: > > 1) C:\Apache\tuscany-sca-2.0-M3\modules>java -jar > osgi-3.4.0-v20080605-1900.jar -co > nfiguration ..\features\configuration -clean -console > > osgi> install > file:/C:/Apache/tuscany-sca-2.0-M3/samples/dosgi-calculator/target > /sample-dosgi-calculator.jar > Bundle id is 183 > > osgi> start 183 > Jun 22, 2009 9:52:22 AM calculator.dosgi.impl.CalculatorActivator start > INFO: Starting > file:/C:/Apache/tuscany-sca-2.0-M3/samples/dosgi-calculator/targe > t/sample-dosgi-calculator.jar [183] > Jun 22, 2009 9:52:22 AM calculator.dosgi.impl.CalculatorActivator start > INFO: Registering calculator.dosgi.CalculatorService > Jun 22, 2009 9:52:22 AM calculator.dosgi.impl.CalculatorActivator getBundle > INFO: calculator.dosgi.operations.AddService is loaded by bundle: > calculator.dos > gi > Jun 22, 2009 9:52:22 AM org.apache.tuscany.sca.node.osgi.impl.NodeManager > bundle > Started > SEVERE: javax/xml/namespace/QName > java.lang.LinkageError: javax/xml/namespace/QName > at > com.ctc.wstx.sr.NsInputElementStack.getCurrentElementName(NsInputElem > entStack.java:651) > at > com.ctc.wstx.sr.BasicStreamReader.getName(BasicStreamReader.java:723) > > at > org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactP > rocessor.read(ExtensibleStAXArtifactProcessor.java:147) > at > org.apache.tuscany.sca.definitions.xml.DefinitionsDocumentProcessor.r > ead(DefinitionsDocumentProcessor.java:146) > at > org.apache.tuscany.sca.definitions.xml.DefinitionsDocumentProcessor.r > ead(DefinitionsDocumentProcessor.java:1) > at > org.apache.tuscany.sca.contribution.processor.DefaultURLArtifactProce > > ssorExtensionPoint$LazyURLArtifactProcessor.read(DefaultURLArtifactProcessorExte > nsionPoint.java:339) > at > org.apache.tuscany.sca.definitions.xml.DefaultDefinitionsExtensionPoi > nt.getDefinitions(DefaultDefinitionsExtensionPoint.java:103) > at > org.apache.tuscany.sca.node.impl.NodeFactoryImpl.init(NodeFactoryImpl > .java:449) > at > org.apache.tuscany.sca.node.osgi.impl.OSGiNodeFactoryImpl.init(OSGiNo > deFactoryImpl.java:84) > at > org.apache.tuscany.sca.node.osgi.impl.OSGiNodeFactoryImpl.getConfigur > ation(OSGiNodeFactoryImpl.java:56) > at > org.apache.tuscany.sca.node.osgi.impl.NodeManager.bundleStarted(NodeM > anager.java:100) > at > org.apache.tuscany.sca.node.osgi.impl.NodeManager.bundleChanged(NodeM > anager.java:124) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEv > ent(BundleContextImpl.java:1234) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventM > anager.java:211) > at > org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchr > onous(ListenerQueue.java:141) > at > org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent > Privileged(Framework.java:1518) > at > org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent > (Framework.java:1469) > at > org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(Bundl > eHost.java:355) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Abstrac > tBundle.java:265) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Abstrac > tBundle.java:257) > at > org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._st > art(FrameworkCommandProvider.java:257) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter. > execute(FrameworkCommandInterpreter.java:150) > at > org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(F > rameworkConsole.java:302) > at > org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(Fra > meworkConsole.java:287) > at > org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(Framewo > rkConsole.java:223) > at java.lang.Thread.run(Unknown Source) > > osgi> > > -------------------------------------------------- > From: "ant elder" <[email protected]> > Sent: Friday, June 19, 2009 11:30 PM > To: <[email protected]> > Subject: Re: [VOTE] Release Tuscany SCA 2.0 M3 RC1 > > On Fri, Jun 19, 2009 at 6:10 PM, Raymond Feng<[email protected]> wrote: >> >>> We added the support to override the problematic OSGi MANIFEST.MF in >>> woden/axis2/axiom bundles. There are issues with such bundles if not >>> patched >>> under OSGi in the distribution. >>> >>> >> That is for the problems talked about in this email [1] right? And >> that is all new code (eg the new sca binding) that also isn't in M3, >> so what is the problem with fixing this in a later release after M3 is >> out? That would give time to sort out whatever the plugin release >> process might be and pick up whatever osgi fixes Axis2 might do etc, >> would that be acceptable to you? >> >> ...ant >> >> [1] http://apache.markmail.org/message/esqa3rbhqqgenmoq >> > >
