If you want to use jsr181 proxy from a SU not targeted at servicemix-jsr181,
you
can not use the #context reference. The #jbi reference will not work
either.
Fortunately. if you don't specify any of these, the proxy factory will try
to find
the ClientFactory in the JNDI context and should be able to create a client
as needed.
So, let's try with:
<bean id="myClientBean" class="com.mycompany.MyClientBean">
<property name="myService">
<jsr181:proxy service="myns:MyService" type="
com.mycompany.MyService" />
</property>
</bean>
On 5/21/07, callum <[EMAIL PROTECTED]> wrote:
Thanks for the assistance.
Perhaps I can just clarify what I'm doing and then you can indicate
whether
or not the context bean should be available.
I create a service assembly containing a number of service units. In the
xbean.xml file for one of those service units (call it SUa) exposes a pojo
as a jsr 181 endpoint using a fragment of the following form (this is used
to expose it as a web service, but config for this is not relevant):
<jsr181:endpoint service="myns:MyService"
pojoClass="com.mycompany.MyService" style="document"
/>
A second service unit (call it SUb), requires access to that endpoint, and
it would be convenient if I could simply use a pojo proxy which would
allow
me to call java methods and have them translated into NMR messages. Will
the jsr 181 proxy allow me to do this? To that end I include the
following
fragment in the xbean.xml file for the second sevice unit:
<bean id="myClientBean" class="com.mycompany.MyClientBean">
<property name="myService">
<jsr181:proxy service="myns:MyService"
context="#context"
type="com.mycompany.MyService" />
</property>
</bean>
Once the service assembly has been packaged as a jar, I copy it to
$SERVICEMIX_HOME/deploy. I then call $SERVICEMIX_HOME/bin/servicemix
$SERVICEMIX_HOME/conf/servicemix.xml.
Under these circumstances should the context bean be available to my
service
unit?
Am I using the jsr 181 proxy correctly?
Thanks in advance,
Callum.
gnodet wrote:
>
> The context bean will only be created when deploying in a SU.
> It won't be available from the main configuration file.
> In such a case, you can use a reference to the jbi container
> as you suggested (container="#jbi").
>
> On 5/21/07, callum <[EMAIL PROTECTED]> wrote:
>>
>>
>> I'm having trouble configuring a jsr181 proxy, with the error messages
>> indicating that the required context bean cannot be found.
>>
>> I include a clause such as the following in the SU configuration
>> xbean.xml
>> file, then startup Servicemix 3.1 (using "./bin/servicemix
>> ./conf/servicemix.xml"). Deployment yields a warning that no bean
called
>> "context" can be found.
>>
>> <jsr181:proxy id="myId" context="#context"
>> service="myns:myService" type="com.mycompany.myproject.MyClass"/>
>>
>> I have read posts that indicate that the context bean is automatically
>> created when the SU is deployed. Is this true always? Does it make a
>> difference if servicemix is executed as a standalone app, or itself
>> deployed
>> within a web container?
>>
>> In the ./conf/servicemix.xml file, the jbi container configuration is
>> identified by "#jbi". I did wonder if using a clause such as this
might
>> be
>> more appropriate:
>>
>> <jsr181:proxy id="myId" container="#jbi"
>> service="myns:myService" type="com.mycompany.myproject.MyClass"/>
>>
>> I have tried both of these without success.
>>
>> Does the version make a difference? If it doesn't work in 3.1 does it
>> work
>> in the latest version from the repository?
>>
>> Regards,
>> Callum.
>> --
>> View this message in context:
>> http://www.nabble.com/Jsr181-proxy-tf3788321s12049.html#a10713260
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>
>
--
View this message in context:
http://www.nabble.com/Jsr181-proxy-tf3788321s12049.html#a10715663
Sent from the ServiceMix - User mailing list archive at Nabble.com.
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
