Raymond, The classes annotated in the bundle should be the classes used to implement OSGi services. @Property for example, can be used to inject properties only if the the annotation is in the class or superclass of the object implementing an OSGi service.
@Scope (and some of the other annotations which are not tied to an object instance) can be specified in any class in the bundle, but the class should be specified in <implementation.osgi/> for SCA to know that the class should be introspected. The classes that get introspected are the classes specified in < implementation.osgi/> and the classes of the service objects. Thank you... Regards, Rajini On 8/30/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > Hi, > > What java classes do you expect to be annotated with SCA annotations in > the > OSGi bundle? > > Thanks, > Raymond > > ----- Original Message ----- > From: "Rajini Sivaram" <[EMAIL PROTECTED]> > To: <tuscany-dev@ws.apache.org>; <[EMAIL PROTECTED]> > Sent: Thursday, August 30, 2007 4:05 AM > Subject: Re: implementation.osgi and SCA annotations > > > > Ant, > > > > The defaults used by implementation.osgi match the default behaviour of > > OSGi > > bundles. Scope is set to COMPOSITE, remotable interfaces use > > pass-by-value, > > and properties can only be set/read using standard OSGi mechanisms. The > > attributes provided in <implementation.osgi/> which are being replaced > by > > annotations provide support for SCA options in OSGi bundles, but these > > require changes to the bundle anyway. So it makes sense to add these > > additional properties in a way that is consistent with SCA, rather than > > add > > something which is neither consistent with OSGi nor SCA. > > > > > > > > Thank you... > > > > Regards, > > > > Rajini > > > > On 8/30/07, ant elder <[EMAIL PROTECTED]> wrote: > >> > >> If thats the way to go then doing it now would be better than after 1.0 > >> is > >> out. > >> > >> But why can't the SCDL attributes be kept as well as supporting > >> annotations > >> and doesn't supporting both then mean non-SCA aware OSGi bundles can > >> still > >> be used with Tuscany? (not particularly concerned about this,would just > >> like > >> to understand) > >> > >> ...ant > >> > >> On 8/30/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > >> > > >> > Ant, > >> > > >> > Thank you. > >> > > >> > I was planning to remove the support for <implementation.osgi/> > >> > attributes, > >> > making it not backward compatible. That was one of the reasons I > wanted > >> to > >> > introduce the change before 1.0. Is that a problem? > >> > > >> > Thank you... > >> > > >> > Regards, > >> > > >> > Rajini > >> > > >> > > >> > > >> > On 8/30/07, ant elder <[EMAIL PROTECTED]> wrote: > >> > > > >> > > On 8/29/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > >> > > > > >> > > > Hello, > >> > > > > >> > > > We would like to start supporting SCA annotations in > implementation > >> > > > classes > >> > > > used inside OSGi bundles to make implementation.osgi consistent > >> > > > with > >> > > > implementation.java. > >> > > > > >> > > > In the current implementation, SCA annotations are only supported > >> for > >> > > > annotations used in interfaces, since we were keen on supporting > >> > > existing > >> > > > OSGi bundles without any change. This meant that additional SCA > >> > > properties > >> > > > like @AllowsPassByReference had to be supported through > additional > >> > > > attributes on the <implementation.osgi/> element. But since these > >> > > > properties > >> > > > do not have an OSGi equivalent, they cannot be used with existing > >> OSGi > >> > > > bundles, and for new implementations which support these > >> > > > properties, > >> > we > >> > > > would like to support SCA annotations to make the OSGi > >> implementation > >> > > > consistent with the Java implementation. > >> > > > > >> > > > This is a fairly big change in implementation.osgi, and I would > >> > > > like > >> > > your > >> > > > views on whether this is a good time to make the change, so that > >> > > > the implementation will reflect the long-term strategy in the > next > >> > > > release. > >> > > > I can submit a patch early next week if it can be integrated > before > >> > the > >> > > > release. > >> > > > >> > > > >> > > If you think it can be done in time then I think you should go for > >> > > it, > >> > i'd > >> > > commit any patches for you. The next release is 1.0 with the > branch > >> for > >> > > that being taken around the 14th of September. If you can get > patches > >> > > submitted by at least a few days before then and the testcases and > >> > samples > >> > > are working after the changes then I can't see any problem with > going > >> > > ahead > >> > > now. > >> > > > >> > > Just to confirm one thing, are the changes going to be backward > >> > > compatible, > >> > > i.e. would SCDL that works today keep on working after the changes > >> > > are > >> > > done? > >> > > > >> > > ...ant > >> > > > >> > > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
