tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajini Sivaram" <rajinisiva...@googlemail.com>
Subject Re: OSGi service with SDO
Date Thu, 17 Apr 2008 11:49:50 GMT
Roshan,

The exception indicates that the Felix framework was not on your CLASSPATH.
By default, Tuscany 1.1 and the snapshot version use different versions of
Felix. If you are running the sample from maven, it should automatically
find the framework. But if you running it without maven, can you make sure
that the latest felix libraries have been downloaded and are on your
classpath.


On 4/17/08, Joseph, Roshan IN BLR SISL <Roshan.Joseph@siemens.com> wrote:
>
> Hi Rajani,
> I tried to run my project with the latest binary from nightly build and
> the felix runtime won't start and gives me the error as "OSGI bundle
> could not be found". The debug shows the sca-contribution has my bundle
> jar in it as on of the object. If I changed the settings to point to
> Tuscany 1.1 then I don't find any problem with the felix runtime.
>
> So I tried to test the sample, supply-chain example which is part of the
> Tuscany 2.0 SNAPSHOT, and this gives the below error. Do I need to add
> anything or make any changes with the new version of Tuscany runtime?
>
> Thank you for your suggestion and support, really appreciate it.
>
> Regards
> Roshan
>
>
> run:
>     [java] Exception in thread "main" java.lang.NoClassDefFoundError:
> org/osgi/
> framework/BundleException
>     [java]     at
> org.apache.tuscany.sca.contribution.osgi.impl.OSGiBundleRefer
> enceModelResolver.resolveModel(OSGiBundleReferenceModelResolver.java:89)
>     [java]     at
> org.apache.tuscany.sca.contribution.resolver.ExtensibleModelR
> esolver.resolveModel(ExtensibleModelResolver.java:150)
>     [java]     at
> org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementa
> tionProcessor.resolve(OSGiImplementationProcessor.java:207)
>     [java]     at
> org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementa
> tionProcessor.resolve(OSGiImplementationProcessor.java:74)
>     [java]     at
> org.apache.tuscany.sca.contribution.processor.DefaultStAXArti
> factProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStA
> XArtifac
> tProcessorExtensionPoint.java:252)
>     [java]     at
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXA
> rtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109)
>     [java]     at
> org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.res
> olveImplementation(BaseAssemblyProcessor.java:248)
>     [java]     at
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolv
> e(CompositeProcessor.java:876)
>     [java]     at
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolv
> e(CompositeProcessor.java:80)
>     [java]     at
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXA
> rtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109)
>     [java]     at
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcesso
> r.resolve(CompositeDocumentProcessor.java:139)
>     [java]     at
> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcesso
> r.resolve(CompositeDocumentProcessor.java:53)
>     [java]     at
> org.apache.tuscany.sca.contribution.processor.ExtensibleURLAr
> tifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
>     [java]     at
> org.apache.tuscany.sca.contribution.service.impl.Contribution
> ServiceImpl.processResolvePhase(ContributionServiceImpl.java:485)
>     [java]     at
> org.apache.tuscany.sca.contribution.service.impl.Contribution
> ServiceImpl.addContribution(ContributionServiceImpl.java:369)
>     [java]     at
> org.apache.tuscany.sca.contribution.service.impl.Contribution
> ServiceImpl.contribute(ContributionServiceImpl.java:165)
>     [java]     at
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.ad
> dContribution(DefaultSCADomain.java:291)
>     [java]     at
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.in
> it(DefaultSCADomain.java:174)
>     [java]     at
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.<i
> nit>(DefaultSCADomain.java:113)
>     [java]     at
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta
> nce(SCADomain.java:245)
>     [java]     at
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SC
> ADomain.java:73)
>     [java]     at
> supplychain.SupplyChainClient.main(SupplyChainClient.java:33)
>
>     [java] Java Result: 1
>
> BUILD SUCCESSFUL
> Total time: 21 seconds
>
>
>
> -----Original Message-----
> From: Rajini Sivaram [mailto:rajinisivaram@googlemail.com]
> Sent: Monday, April 14, 2008 1:02 AM
> To: tuscany-user@ws.apache.org; roshan joseph
> Subject: Re: OSGi service with SDO
>
> Roshan,
>
> I have added test bundles and testcases in itest/osgi-implementation
> which
> test both implementation.java components with references to OSGi
> services
> and implementation.osgi components with references to Java services
> where
> the parameters are SDOs. The code is in the directory helloworld.sdo.
>
>
> On 4/9/08, roshan joseph <roshanjose@yahoo.com> wrote:
> >
> > Hi Rajani,
> >  I have made the classes which I am using as a seperate bundle, bu the
> > problem now is with the tuscany sdo jars, which is a dependency for my
> > current sdo bundle. How do I get my import package resolved with the
> library
> > jars of tuscany sdo's. Has anyone tried them and run as bundles.
> >
> > I tried with some, but the dependency resolution for these jars are
> keep
> > on expanding exponentially. Any kind of advice is really helpful.
> >
> > Thank you for your suggestions.
> >
> > Regards
> > Roshan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Roshan,
> >
> > The classes corresponding to the SDO datatype should be imported by
> (or
> > contained in) the bundle implementing the OSGi service. And if you are
> > using
> > the default SCA binding, the Java service and the OSGi service should
> be
> > using the same classes for the SDO datatypes. Which means that the
> Java
> > service should be defined inside a bundle contribution (a jar file
> > containing OSGi manifest headers). Does this help?
> >
> >
> > On 3/27/08, roshan joseph <[EMAIL PROTECTED]> wrote:
> > >
> > >    Hello,
> > >   I am trying to work on a prototype to use osgi service with a java
> sca
> > > service using SDO datatypes. I had no problem with the datatypes
> like
> > > String, but when I changed the dataype to SDO based it does not
> work, as
> > the
> > > bundle cannot understand the SDO data, which is passed as arguments
> for
> > osgi
> > > service call. Can someone suggest what am I missing here?
> > >
> > > If anyone has encountered or tried this, please comment on the
> > experience.
> > >
> > > Thanks for any info in advance..
> > >
> > > Regards
> > > Roshan
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
>
>
>
> --
> Thank you...
>
> Regards,
>
> Rajini
>
>
>
>
> Important notice:This e-mail and any attachment thereto contains corporate
> proprietary information. If you have received it by mistake, please notify
> us immediately by reply e-mail and delete this e-mail and its attachments
> from your system. Thank You.
>



-- 
Thank you...

Regards,

Rajini

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message