My suggestion would be to: * define a listener so that it will be called with the ServiceReference * grab the real service using the given ServiceReference and do any introspection here However, if you don't use the proxy when invoking the service, you will loose the goodness of the proxy.
On Mon, Jun 29, 2009 at 23:21, Franz Seidl<[email protected]> wrote: > Sorry, I don't have an idea to solve your problem. Probably there is no way to > bring the annotations across in an at least remotely elegant way. > > The following possibilities came to my mind (blessed be long train rides). I > haven't thought them through, but perhaps you find something of value: > > - beat the proxied object out of the proxy, as Costin Leau suggested (the > proxies implement some interface that allows this). I'd wrap this step into a > factory and use only that in the client bundle. > - rework your design, so that the information now carried by annotations is > expressed in methods and parameters instead. Maybe a hierarchy of small > immutable objects can replace the combination of simple parameter and > annotation. > - move the service/bundle boundary, so that instances of the implementation > classes carrying annotations are created in the client bundle's scope. > - get the services manually > - make the service a factory of implementation instances > > Regards, > Franz > > Charles Moulliard schrieb am Freitag, 26. Juni 2009: >> You have well understand the question. Here is an example of a model that I >> have tried to expose through a service without success : >> >> @Section(nber = 1) >> public class Header extends Abstract implements Serializable { >> >> private static final long serialVersionUID = 5503190817793341749L; >> >> // Message Header >> @KeyValuePairField(tag = 8, position = 1) >> private String beginString; >> >> // Length of the message >> @KeyValuePairField(tag = 9, position = 2) >> private int bodyLength; >> >> The annotations were not discovered in the the service using this model. >> Here is the feedback from Spring : >> >> http://forum.springsource.org/showthread.php?p=245811#post245811 >> >> Regards, >> >> Charles Moulliard >> Senior Enterprise Architect >> Apache Camel Committer >> >> ***************************** >> blog : http://cmoulliard.blogspot.com >> >> On Thu, Jun 25, 2009 at 7:08 PM, 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] > > > --------------------------------------------------------------------- > 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]
