You're welcome. I'm slightly ashamed that I didn't notice earlier.
I deliberately changed the topic line :-)
M.
Vinicius Carvalho schrieb:
Mika: DUDE YOU ROCK!!!!!!! Can you believe that, all that I needed to
do was that serviceClass not implementation :D
Now WSLD is fine, service is working with it's injected classes!
Thanks, Thanks Thanks Thanks Thanks Thanks
On 4/27/06, *Vinicius Carvalho* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Latest from the front... my mistake on the last post :P
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]
<mailto:[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]
<mailto:[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 ;)
Regards
On 4/27/06, *Ron Anderson* < [EMAIL PROTECTED]
<mailto:[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?
thx
Ron
----- Original Message ----
From: Vinicius Carvalho < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
To: [email protected]
<mailto:[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?
Regards
On 4/27/06, *Dan Diephouse* < [EMAIL PROTECTED]
<mailto:[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]>
> <mailto: [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
--
cyber:con gmbh
Mika Göckel
Rathausallee 10
53757 Sankt Augustin
tel (+49)2241 / 9350 0
fax (+49)2241 / 9350 99
mob (+49) 172 / 279 2771
skype mika.goeckel
email [EMAIL PROTECTED]
