Haleh, Will do (I probably dont have access, but I will write the text and submit it).
Thank you... Regards, Rajini On 9/5/07, haleh mahbod <[EMAIL PROTECTED]> wrote: > > Rajini, > If this goes into 1.0, can you please update Java user doc[1]? > Thanks, > Haleh > > [1]:http://incubator.apache.org/tuscany/sca-java-user-guide.html > > On 8/30/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > > > 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: <[email protected]>; <[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.osgiconsistent > > > >> > > > 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] > > > > > > > > >
