So I have it working, but not with serviceBeans. So I'll keep this approach, just gotta figure out how to have my springbeans being exposed as services not their direct classes. Could anyone help me here? I'm reading the source right now, but it's a lot of stuff to catch...
regards
On 4/27/06,
Vinicius Carvalho <[EMAIL PROTECTED]> wrote:
Well, sorry... not that good :( Service class was mapped to an interface, an although the WSDL seems to be ok, invoking it is not. I'm really getting to a dead corner on how to expose non desired properties and methods.
Again, sorry for all the problem...On 4/27/06, Vinicius Carvalho < [EMAIL PROTECTED]> wrote:Dan, all this problem I'm having, seems to be a problem with ServiceBeans only. I've just changed to the default services.xml configuration and the WSDL is just fine (it is based on the interface) problem is, It will have null values, since I'm using the class, not the one managed by spring. So, with this, is there any possible solutions? I was thinking in overriding the default ServiceFactory (getting the appcontext from the WebContextUtils) I'd really rather use ServiceBeans because we could rely on only one XML (the spring) it would be easier for our developers, not need to care about another xml syntax.
If there's something that could be done could you help me, but anyway, I'm glad I could find a way, now we can continue with XFire. Soon I can post the project specs so if you'd like to put on the site ;)
RegardsOn 4/27/06, Ron Anderson < [EMAIL PROTECTED]> wrote:Dan does it also work with Aegis bindings + Spring remoting? Also what is your estimate on when 1.1 will be released?
thxRon
----- Original Message ----
From: Vinicius Carvalho < [EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, April 27, 2006 9:30:09 AM
Subject: Re: [xfire-user] XFire + Aegis = Simply don't
Dan, this new version works well with Aegis bindings + ServiceBeans? The reason I'm using serviceBeans is because my service must be managed by spring (it has a lot of dependency injections) it is not possible using tradicional service.xml is it?
RegardsOn 4/27/06, Dan Diephouse < [EMAIL PROTECTED]> wrote:Just to be clear, the JSR 181 stuff can and does work on Java 1.4. We
use commons attributes to do this.
Additionally I just checked in code for 1.1 where we can do:
<service>
<serviceClass>Echo</serviceClass>
<method name="nonEchoMethod" exclude="true"/>
</service>
It also does an array of other things like let you define the names for
your parameters,
<service>
<serviceClass>Echo</serviceClass>
<method name="echo" xmlns:e="urn:echo">
<parameter index="0" name="e:text"/>
</method>
</service>
Cheers,
- Dan
Tyler Nelson wrote:
>
> Hi Vinicius*,*
>
> * *I feel your pain. A while ago when I was first evaluating Xfire ,
> I went through very similar frustrations with Aegis. We are stuck
> using Websphere 5.1, so besides being in our own person hell, we
> didn't have an option to use JSR 181 either.
>
> Once I can to terms with only using Aegis for quickly prototyping
> things, I became a much happier person. (Sorry Dan : ( )
>
> We are currently using the XFire's MessageBinding, which is working
> pretty well for us, however I'm not sure if you want to manipulate the
> XML yourself or not, we had some high performance requirements so this
> was a better solution for us anyway.
>
> You may want to look at Xfire's Castor Binding or I think I heard Dan
> say that the JiBx binding was in Xfire's Sandbox. I'm not sure if it
> is ready or not, but it's where I would look.
>
> I hope that helps.
>
> --Tyler
>
>
>
> On 4/27/06, *Vinicius Carvalho* < [EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>> wrote:
>
> Hello Folks!
> Well, I'm sorry can't use JSR 181 (JDK 1.4 here :( damn Oracle AS)
> Well, I'm exposing my services via Service Bean, and I do not have
> the get/set methods on the interface check it out:
>
> <beans>
> <bean id="baseService"
> class="org.codehaus.xfire.spring.ServiceBean" abstract="true">
> <property name="style" value="document"></property>
> <property name="use" value="literal"></property>
> <property name="inHandlers">
> <list>
> <ref bean="addressingHandler"/>
> </list>
> </property>
> </bean>
> <bean id="addressingHandler"
> class=" org.codehaus.xfire.addressing.AddressingInHandler"/>
>
>
> <bean id="userService" parent="baseService">
> <property name="implementationClass"
> value="com.acme.services.UserService"></property> <-- tThis is the
> interface
> <property name="serviceBean">
> <ref bean="userServiceImpl"/>
> </property>
> <property name="namespace" value="
> http://com.acme.services/UserService"></property>
> </bean>
> <bean name="userDAO" class="com.acme.eai.dao.HibernateUserDAO"></bean>
> <bean name="userBO" class=" com.acme.bo.AcmeUserBO"></bean>
> <bean name="userServiceImpl"
> class="com.acme.services.UserServiceImpl">
> <property name="bo">
> <ref bean="userBO"/>
> </property>
> </bean>
> public interface UserService {
>
> public abstract User getUser(Integer id);
>
> }
>
>
> Still, it is exposing the BO type.
>
> I also have UserService.aegis.xml
>
> <?xml version=" 1.0" encoding="UTF-8"?>
> <mappings>
> <mapping>
> <property name="bo" ignore="true"/>
> </mapping>
> </mappings>
> and AcmeUserBO.aegis.xml (This is just a test hence the Acme name ;) )
>
> <?xml version="1.0" encoding="UTF-8"?>
> <mappings>
> <mapping>
> <property name="dao" ignore="true"/>
> </mapping>
> </mappings>
>
> Best Regards
>
>
>
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
