Blueprint uses proxies on interfaces usually. This means that all annotations on interfaces will be exposed. Also see [1] : just make sure both the exporter and importer import the package containing the annotations.
[1] http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-Whyismybundlenotabletoseeannotationsatruntime? On Thu, Jun 25, 2009 at 19:08, Franz Seidl<[email protected]> wrote: > I'm not sure I understand the question. ;-) > > Annotations are attached to classes (if their retention policy is not > "SOURCE") and they are types themselves. I'd expect them to work over bundle > boundaries, if the imports and exports of those bundles are declared correctly > so the types are visible. > > Proxies and the osgi service registry are about object references. Unlikely > that they are guilty of hiding annotations. (BTW, some annotations are > inherited and proxies are often created by subclassing.) > > Can't tell anything with regard to blueprint. > > regards, > Franz > > Charles Moulliard schrieb am Donnerstag, 25. Juni 2009: >> Many thanks. I will have a look on that : >> >> http://java-x.blogspot.com/2007/01/spring-prototype-beans-with-singletons.h >>tml >> >> By the way, do you think that there is a solution to expose Spring OSGI >> service when some of the classes implemented behind this OSGI service have >> annotations. Such annotations are not visible from bundle using this OSGI >> service due to the fact that spring proxyified those classes. >> >> Is it also the case with OSGI Blueprint ? >> >> Regards, >> >> Charles Moulliard >> Senior Enterprise Architect >> Apache Camel Committer >> >> ***************************** >> blog : http://cmoulliard.blogspot.com >> >> On Thu, Jun 25, 2009 at 2:27 PM, Franz Seidl <[email protected]> wrote: >> > That paragraph in the reference docs does imho refer to accessing the >> > application context of a *different* bundle. But of course, accessing the >> > context programmatically couples your code to Spring. Injecting is the >> > most elegant solution. >> > I've assumed there is a reason why di can't be used in your case. (If >> > there is >> > - e.g. because there are prototypes involved - you might want to have a >> > look >> > at "Lookup method injection".) >> > >> > regards, >> > Franz >> > >> > Charles Moulliard schrieb am Donnerstag, 25. Juni 2009: >> > > Spring team does not like that we use directly the ApplicationContext >> > > directly in a bundle. This is a little bit explained in the >> > > documentation >> > >> > http://static.springframework.org/osgi/docs/1.2.0/reference/html-single/# >> >bn >> > >> > >d-app-ctx:app-creation >> > > >> > > *"Note: the application context is published as a service primarily to >> > > facilitate testing, administration, and management. Accessing this >> > >> > context >> > >> > > object at runtime and invoking getBean() or similar operations is >> > > discouraged. The preferred way to access a bean defined in another >> > > application context is to export that bean as an OSGi service from the >> > > defining context, and then to import a reference to that service in the >> > > context that needs access to the service. Going via the service >> > > registry >> > >> > in >> > >> > > this way ensures that a bean only sees services with compatible >> > > versions >> > >> > of >> > >> > > service types, and that OSGi platform dynamics are respected.*" >> > > >> > > From my point of view, this approach imposes that you use spring >> > >> > injection >> > >> > > to retrieve by example a bean created instead of >> > > ApplicationContext.getBean() in a java class >> > > >> > > Regards, >> > > >> > > Charles >> > > >> > > On Thu, Jun 25, 2009 at 9:37 AM, Franz Seidl <[email protected]> >> > >> > wrote: >> > > > In Spring, there is the ApplicationContextAware-Interface. Won't that >> > >> > do >> > >> > > > what >> > > > you need? >> > > > Just out of curiosity: Why can't you inject the bean? >> > > > >> > > > Regards, >> > > > Franz >> > > > >> > > > Charles Moulliard schrieb am Dienstag, 23. Juni 2009: >> > > > > I will provide an example : >> > > > > >> > > > > Bundle A >> > > > > >> > > > > In this bundle, I instantiate a bean with parameters like this : >> > > > > >> > > > > <bean id="emxHeader" >> > > > > class="com.xpectis.x3s.model.backoffice.emx.common.Header"> >> > > > > <property name="beginString" value="FIX.4.1"/> >> > > > > <property name="bodyLength" value="58"/> >> > > > > <property name="msgSeqNum" value="32"/> >> > > > > <property name="msgType" value="0"/> >> > > > > <property name="sendCompId" value="CLIENT"/> >> > > > > <property name="clientCompId" value="20090619-08:46:35"/> >> > > > > <property name="targetCompId" value="SERVER"/> >> > > > > </bean> >> > > > > >> > > > > In the same bundle, I would like from a Java class to retrieve the >> > >> > bean >> > >> > > > and >> > > > >> > > > > use it to do a transformation (using DataFormat of Camel : POJO to >> > >> > FIX >> > >> > > > > message) locally. The result of this transformation will be next >> > > > > made available to another bundle B though a service >> > > > > (getFIXMessage). >> > > > > >> > > > > Regards, >> > > > > >> > > > > Charles Moulliard >> > > > > Senior Enterprise Architect >> > > > > Apache Camel Committer >> > > > > >> > > > > ***************************** >> > > > > blog : http://cmoulliard.blogspot.com >> > > > > >> > > > > On Tue, Jun 23, 2009 at 1:19 AM, Guillaume Nodet <[email protected]> >> > > > >> > > > wrote: >> > > > > > Not sure what you mean. If you create your own spring-dm powered >> > > > > > bundle, the application context will be exported as an OSGi >> > > > > > service (unless you configure your bundle to not do so). >> > > > > > You can access this object through the OSGi registry and >> > > > > > manipulate it as any other application context. >> > > > > > >> > > > > > On Mon, Jun 22, 2009 at 12:16, Charles >> > > > > > Moulliard<[email protected]> >> > > > > > >> > > > > > wrote: >> > > > > > > Hi, >> > > > > > > >> > > > > > > I would like to know How I can retrieve the >> > > > >> > > > org.springframework.osgi.context.support.OsgiBundleXmlApplicationCont >> > > >ex >> > > > >> > > > > > >t published in an OSGI bundle (using Apache Karaf) ? Is there >> > > > > > > any >> > > > >> > > > helper >> > > > >> > > > > > class >> > > > > > >> > > > > > > in karaf that I use to have access to beans created by Spring >> > > > > > > ? >> > > > > > > >> > > > > > > Regards, >> > > > > > > >> > > > > > > Charles Moulliard >> > > > > > > Senior Enterprise Architect >> > > > > > > Apache Camel Committer >> > > > > > > >> > > > > > > ***************************** >> > > > > > > blog : http://cmoulliard.blogspot.com >> > > > > > >> > > > > > -- >> > > > > > Cheers, >> > > > > > Guillaume Nodet >> > > > > > ------------------------ >> > > > > > Blog: http://gnodet.blogspot.com/ >> > > > > > ------------------------ >> > > > > > Open Source SOA >> > > > > > http://fusesource.com >> > >> > --------------------------------------------------------------------- >> > >> > > > > > To unsubscribe, e-mail: [email protected] >> > > > > > For additional commands, e-mail: [email protected] >> > > > >> > > > -- >> > > > Franz Seidl >> > > > Bremerstraße 1, App. 131 >> > > > 67663 Kaiserslautern >> > > > Telefon +49 (0) 631 6251291 >> > > > Mobil +49 (0) 173 6777026 >> > > > >> > > > --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: [email protected] >> > > > For additional commands, e-mail: [email protected] >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
