How to retrieve the spring context in Apache Karaf ?

[cmoulliard]

Hi,

I would like to know How I can retrieve the
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext
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

[gnodet]

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<cmoulliard@...> wrote:

> Hi,
>
> I would like to know How I can retrieve the
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext
> 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: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[cmoulliard]

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 <gnodet@...> 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<cmoulliard@...>
> wrote:
> > Hi,
> >
> > I would like to know How I can retrieve the
> > org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext
> > 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: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Hendy Irawan]

I second Charles' request. I've been trying to do this with Geronimo
Blueprint and have been unsuccessful.

Is it possible to do this inside the blueprint XML file?

<reference id="something" interface="org.springframework.ApplicationContext"
/>

<!-- how to pass our bean ID here? -->
<bean factory-bean="something" factory-method="getBean" />

Ideally, it should be possible to use Spring beans directly from Blueprint
XML...


On Tue, Jun 23, 2009 at 1:37 PM, Charles Moulliard <cmoulliard@...>wrote:

> 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 <gnodet@...> 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<cmoulliard@...>
> > wrote:
> > > Hi,
> > >
> > > I would like to know How I can retrieve the
> > >
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext
> > > 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: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>

--
Best regards,
Hendy Irawan
[phone] :: [phone]
http://www.hendyirawan.com/ :: hendy@...

[Franz Seidl]

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 <gnodet@...> 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<cmoulliard@...>
> >
> > wrote:
> > > Hi,
> > >
> > > I would like to know How I can retrieve the
> > > org.springframework.osgi.context.support.OsgiBundleXmlApplicationContex
> > >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: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...

--
Franz Seidl
Bremerstraße 1, App. 131
67663 Kaiserslautern
Telefon [phone]
Mobil [phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[cmoulliard]

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/#bnd-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 <franz.g.seidl@...> 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 <gnodet@...>
> 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<cmoulliard@...>
> > >
> > > wrote:
> > > > Hi,
> > > >
> > > > I would like to know How I can retrieve the
> > > >
> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContex
> > > >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: users-unsubscribe@...
> > > For additional commands, e-mail: users-help@...
> --
> Franz Seidl
> Bremerstraße 1, App. 131
> 67663 Kaiserslautern
> Telefon [phone]
> Mobil [phone]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Franz Seidl]

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 <franz.g.seidl@...> 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 <gnodet@...>
> >
> > 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<cmoulliard@...>
> > > >
> > > > wrote:
> > > > > Hi,
> > > > >
> > > > > I would like to know How I can retrieve the
> >
> > org.springframework.osgi.context.support.OsgiBundleXmlApplicationContex
> >
> > > > >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: users-unsubscribe@...
> > > > For additional commands, e-mail: users-help@...
> >
> > --
> > Franz Seidl
> > Bremerstraße 1, App. 131
> > 67663 Kaiserslautern
> > Telefon [phone]
> > Mobil [phone]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[cmoulliard]

Many thanks. I will have a look on that :

http://java-x.blogspot.com/2007/01/spring-prototype-beans-with-singletons.html

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 <franz.g.seidl@...> 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 <franz.g.seidl@...>
> 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 <gnodet@...>
> > >
> > > 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<cmoulliard@...>
> > > > >
> > > > > wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I would like to know How I can retrieve the
> > >
> > > org.springframework.osgi.context.support.OsgiBundleXmlApplicationContex
> > >
> > > > > >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: users-unsubscribe@...
> > > > > For additional commands, e-mail: users-help@...
> > >
> > > --
> > > Franz Seidl
> > > Bremerstraße 1, App. 131
> > > 67663 Kaiserslautern
> > > Telefon [phone]
> > > Mobil [phone]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@...
> > > For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[gnodet]

That should work in both spring-dm and blueprint.
You just need to pass the argument which is the id of the bean you
want to create.

<reference id="appContext" interface="org.springframework.ApplicationContext"
<bean id="myBean" factory-bean="appContext" factory-method="getBean">
    <argument value="beanId" />
</bean>

This would be equivalent to

   appContext.getBean("beanId")

On Thu, Jun 25, 2009 at 04:51, Hendy Irawan<hendy@...> wrote:

> I second Charles' request. I've been trying to do this with Geronimo
> Blueprint and have been unsuccessful.
>
> Is it possible to do this inside the blueprint XML file?
>
> <reference id="something" interface="org.springframework.ApplicationContext"
> />
>
> <!-- how to pass our bean ID here? -->
> <bean factory-bean="something" factory-method="getBean" />
>
> Ideally, it should be possible to use Spring beans directly from Blueprint
> XML...
>
>
> On Tue, Jun 23, 2009 at 1:37 PM, Charles Moulliard <cmoulliard@...>wrote:
>
>> 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 <gnodet@...> 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<cmoulliard@...>
>> > wrote:
>> > > Hi,
>> > >
>> > > I would like to know How I can retrieve the
>> > >
>> org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext
>> > > 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: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>>
>
>
>
> --
> Best regards,
> Hendy Irawan
> [phone] :: [phone]
> http://www.hendyirawan.com/ :: hendy@...
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Franz Seidl]

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 <franz.g.seidl@...> 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 <franz.g.seidl@...>
> >
> > 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 <gnodet@...>
> > > >
> > > > 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<cmoulliard@...>
> > > > > >
> > > > > > 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: users-unsubscribe@...
> > > > > > For additional commands, e-mail: users-help@...
> > > >
> > > > --
> > > > Franz Seidl
> > > > Bremerstraße 1, App. 131
> > > > 67663 Kaiserslautern
> > > > Telefon [phone]
> > > > Mobil [phone]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@...
> > > > For additional commands, e-mail: users-help@...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[gnodet]

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<franz.g.seidl@...> 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 <franz.g.seidl@...> 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 <franz.g.seidl@...>
>> >
>> > 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 <gnodet@...>
>> > > >
>> > > > 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<cmoulliard@...>
>> > > > > >
>> > > > > > 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: users-unsubscribe@...
>> > > > > > For additional commands, e-mail: users-help@...
>> > > >
>> > > > --
>> > > > Franz Seidl
>> > > > Bremerstraße 1, App. 131
>> > > > 67663 Kaiserslautern
>> > > > Telefon [phone]
>> > > > Mobil [phone]
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: users-unsubscribe@...
>> > > > For additional commands, e-mail: users-help@...
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[cmoulliard]

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 <franz.g.seidl@...> 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 <franz.g.seidl@...>
> 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 <franz.g.seidl@...>
> > >
> > > 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 <
> gnodet@...>
> > > > >
> > > > > 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<cmoulliard@...>
> > > > > > >
> > > > > > > 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: users-unsubscribe@...
> > > > > > > For additional commands, e-mail: users-help@...
> > > > >
> > > > > --
> > > > > Franz Seidl
> > > > > Bremerstraße 1, App. 131
> > > > > 67663 Kaiserslautern
> > > > > Telefon [phone]
> > > > > Mobil [phone]
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@...
> > > > > For additional commands, e-mail: users-help@...
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@...
> > > For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Franz Seidl]

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 <franz.g.seidl@...> 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 <franz.g.seidl@...>
> >
> > 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 <franz.g.seidl@...>
> > > >
> > > > 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 <
> >
> > gnodet@...>
> >
> > > > > > 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<cmoulliard@...>
> > > > > > > >
> > > > > > > > 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: users-unsubscribe@...
> > > > > > > > For additional commands, e-mail: users-help@...
> > > > > >
> > > > > > --
> > > > > > Franz Seidl
> > > > > > Bremerstraße 1, App. 131
> > > > > > 67663 Kaiserslautern
> > > > > > Telefon [phone]
> > > > > > Mobil [phone]
> >
> > ---------------------------------------------------------------------
> >
> > > > > > To unsubscribe, e-mail: users-unsubscribe@...
> > > > > > For additional commands, e-mail: users-help@...
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@...
> > > > For additional commands, e-mail: users-help@...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[gnodet]

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<franz.g.seidl@...> 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 <franz.g.seidl@...> 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 <franz.g.seidl@...>
>> >
>> > 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 <franz.g.seidl@...>
>> > > >
>> > > > 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 <
>> >
>> > gnodet@...>
>> >
>> > > > > > 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<cmoulliard@...>
>> > > > > > > >
>> > > > > > > > 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: users-unsubscribe@...
>> > > > > > > > For additional commands, e-mail: users-help@...
>> > > > > >
>> > > > > > --
>> > > > > > Franz Seidl
>> > > > > > Bremerstraße 1, App. 131
>> > > > > > 67663 Kaiserslautern
>> > > > > > Telefon [phone]
>> > > > > > Mobil [phone]
>> >
>> > ---------------------------------------------------------------------
>> >
>> > > > > > To unsubscribe, e-mail: users-unsubscribe@...
>> > > > > > For additional commands, e-mail: users-help@...
>> > > >
>> > > > ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: users-unsubscribe@...
>> > > > For additional commands, e-mail: users-help@...
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...