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]
>
>
