You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by roshan joseph <ro...@yahoo.com> on 2008/04/09 19:30:52 UTC
Re: OSGi service with SDO
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
Re: OSGi service with SDO
Posted by Rajini Sivaram <ra...@googlemail.com>.
Roshan,
The SDO packages required to create SDO instances from OSGi bundles are now
exported by the system bundle of the embedded Felix runtime started by
Tuscany. The changes have been committed under revision 646679. You should
now be able to import these packages in your bundles without installing
additional SDO bundles.
On 4/9/08, roshan joseph <ro...@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
Re: OSGi service with SDO
Posted by Rajini Sivaram <ra...@googlemail.com>.
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 <Ro...@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 <ro...@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
RE: OSGi service with SDO
Posted by "Joseph, Roshan IN BLR SISL" <Ro...@siemens.com>.
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 <ro...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: OSGi service with SDO
Posted by Rajini Sivaram <ra...@googlemail.com>.
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 <ro...@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