Hi,
I got a bit further with this, and thought I'd share what I'm doing in case
anyone else is wanting to use mule and app fuse together. Appfuse provides
a fairly high production value web env and mule is the integration platform
from hell so together they make a formidable pair.
I thought I had doc'ed this on the list, and I may have, so I'll just
summarize here. I used only the mule 2.2.3 dependencies eventually, in the
pom.xml (top level, I used a struts2 modular archetype) and it pulled in CXF
2.1.5 on it's own. You must let the mule receiver servlet run the show, it
didn't play nice with the CXF servlet or vice versa, just take the CXF
servlet out of web.xml.
I also didn't declare any endpoints in any CXF file but did change the
annotations somewhat in the service / manager interface class. Here's an
example:
@WebResult(name="foosByName")
List<Foo> getFoosByName( @WebParam(name="name") String name );
Also, if you want to expose the superclass methods get(), save() etc., you
have to explicitly expose them by featuring them in the manager interface
and annotating them. For ex., here's getAll():
@WebResult(name="foos")
public List<Foo> getAll();
The implementation class is the same as in "regular appfuse" (i.e. in the
tutorials):
@WebService(serviceName = "FooService", endpointInterface =
"org.jackalista.integration.service.FooManager")
public class FooManagerImpl extends GenericManagerImpl<Foo, Long> implements
FooManager {
You can import your appContext file into your mule config like so:
<!-- import beans from appfuse applicationContext.xml -->
<spring:beans>
<spring:import resource="classpath:applicationContext.xml" />
</spring:beans>
Then declare your mule services in a model as usual; "fooManager" is the
name of my mgr bean from my appfuse spring context:
<service name="FooService">
<inbound>
<!-- Public interface -->
<inbound-endpoint
address="cxf:http://0.0.0.0:8888/services/FooService"/>
</inbound>
<pooled-component>
<spring-object bean="fooManager" />
</pooled-component>
</service>
This is of course a synchronous web service call hosted in mule using the
appfuse manager as the component and brings to bear all the functionality
associated with appfuse, hibernate, the web front end etc. and adds all the
tricks you can pull with mule. You can expose these services via mule and
it's host of transports and use appfuse infrastructure to look at database
persisted graphs of objects accepted via one of your mule service endpoints
or whatever you want to do.
Another couple of points that are worth mentioning are related to hibernate
persistence in the context of services that deliver graphs of hibernate
persistent domain classes. If your services need to retrieve an object and
that object's set valued properties, you will have to do a couple of things.
First, on the collection property in the parent class, change the cascade to
ALL like this:
------------------------------------------------------
|
v
@OneToMany(mappedBy="foo",cascade=CascadeType.ALL,fetch=FetchType.LAZY)
public Set<Bar> getBars() {
return bars;
}
This "@XmlTransient" annotation keeps JAXB from losing its mind when it
discovers the cycle in the object graph between the parent class with the
set and the set members parent reference. Put this in the child class above
the getter for the parent reference like this:
@XmlTransient
@ManyToOne( cascade = {CascadeType.PERSIST, CascadeType.MERGE} )
public Foo getFoo() {
return foo;
}
You also have to add this method to your child class (in my example the
class found in the set valued property, Bar.java) which allows JAXB to
reconnect the parent reference after unmarshalling from XML:
/**
* @return set the parent reference
*/
public void afterUnmarshal(Unmarshaller u, Object parent) {
this.order = (Foo)parent;
}
Lastly, you'll have to use a left join in your HQL to prevent a lazy init
exception when you fetch the top level class and want it's set full of child
objects too. The super class' methods don't do this but you can write quick
knockoffs of them that do like this that fetches Foos by name, pulling in
the collection Set<Bar> bars as well, here's the hibernate dao
implementation:
@SuppressWarnings("unchecked")
public List<Foo> getFoosByName(String name) {
return getHibernateTemplate().find("from Foo f left join fetch f.bars
where f.name=?", name);
}
I think this brings up to date the stuff I've found integrating appfuse and
mule. This is all stuff you'd want to do to build a java tomcat app using
mule, and so far none of the tweaks I've made have broken any app fuse stuff
that I can tell, I'm able to write pages as in the tutorials and it all
works so far. I'm writing a medium sized app with this so will post any
more generally useful things as I find them. So far, I'm relatively pleased
with the dist...
-=j=-
jackalista wrote:
>
> OK, that's what I'm doing, the stuff is building but I have a few problems
> to work out. It's occurred to me lately that mule *contains* CXF as well,
> so I'm not sure that migrating CXF into appfuse was necessary for this,
> but I'll keep notes about what I find and post them.
>
> --j
>
>
> mraible wrote:
>>
>> You should be able to upgrade any AppFuse dependencies w/o issues.
>> Downgrading them might be a different story. The best thing to do is
>> try upgrading and report back if you see any issues.
>>
>> Matt
>>
>> On Tue, Sep 29, 2009 at 3:26 PM, jackalista <j...@twaxx.com> wrote:
>>>
>>> Hi kids,
>>>
>>> I'm starting to integrate mule into appfuse and was wondering if anyone
>>> has
>>> any experience with this? My first question concerns dependencies and
>>> maven
>>> (and yes, I did read the maven for newbies page -- Nathan, public
>>> humiliation is the best perk of all -- no treading on thin ice == no
>>> cold
>>> water wake up, right?).
>>>
>>> First thing I noticed a couple of differences between the versions of
>>> things
>>> mule likes and those appfuse likes. Here's the stuff I found:
>>>
>>> stuff mule version appfuse version
>>> -----------------------------------------------
>>> jetty 6.1.11 6.1.9
>>> servlet-api 2.5 (?)* 2.4
>>> xalan 2.7.1 ??? - I'd thought
>>> xalan
>>> was in appfuse but I don't see a jar...?
>>> maven-compiler-plugin ? v listed** 2.0.2 -
>>> cxf 2.1.2 2.2.3 - ?!?!?
>>> prolly
>>> mule lore but anyone know about this?
>>>
>>>
>>> I'm going to take the tack of using the latest version either dist wants
>>> and
>>> hope for the best but if anybody has details on these I'd like to hear
>>> about
>>> it if you can spit it out... Also, do I care about things like this:
>>> "<encoding>ISO-8859-1</encoding>" in one maven compiler plugin and not
>>> the
>>> other? Also, is there any reason appfuse shouldn't upgrade to servlet
>>> api
>>> 2.5 (vs. 2.4 in use now)? Also, what's the deal with xalan, wasn't it
>>> in
>>> appfuse or am I confused? TIA... See notes for "*" and "**" below...
>>> thanks!
>>>
>>> -=j=-
>>>
>>>
>>> * = The servlet-api isn't called out in the mule pom.xml as it is in
>>> appfuse
>>> but this jetty dependecy makes it look like it's 2.5:
>>>
>>> <dependency>
>>> <groupId>org.mortbay.jetty</groupId>
>>> <artifactId>servlet-api-2.5</artifactId>
>>> <version>${jettyVersion}</version>
>>> <scope>test</scope>
>>> </dependency>
>>>
>>> ** = the mule maven-compiler-plugin lists an encoding value inside the
>>> <configuration> with a value of ISO-8859-1 while the appfuse plugin
>>> doesn't,
>>> do I care? Here's the mule version:
>>>
>>> <plugin>
>>> <groupId>org.apache.maven.plugins</groupId>
>>> <artifactId>maven-compiler-plugin</artifactId>
>>> <configuration>
>>> <source>1.5</source>
>>> <target>1.5</target>
>>> <encoding>ISO-8859-1</encoding>
>>> </configuration>
>>> </plugin>
>>>
>>> Here's the appfuse version:
>>>
>>> <plugin>
>>> <artifactId>maven-compiler-plugin</artifactId>
>>> <version>2.0.2</version>
>>> <configuration>
>>> <source>1.5</source>
>>> <target>1.5</target>
>>> </configuration>
>>> </plugin>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/integrating-enterprise-mule---appfuse-2.02-tp25672004s2369p25672004.html
>>> Sent from the AppFuse - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net
>>> For additional commands, e-mail: users-h...@appfuse.dev.java.net
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net
>> For additional commands, e-mail: users-h...@appfuse.dev.java.net
>>
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/integrating-enterprise-mule---appfuse-2.02-tp25672004s2369p26226555.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@appfuse.dev.java.net
For additional commands, e-mail: users-h...@appfuse.dev.java.net
