I'm using JBoss 4.2.1 and Mule 1.4.1. I am looking for a simple recipe like
this:
1. deploy your application (the .ear file) to jboss
2. deploy the mule rar file to jboss (the OOTB version, i.e. the one you can
download from the web; without any modifications)
3. create your mule configuration file (which will, naturally, reference
classes from the ear deployed in step 1) and drop it, too, in the jboss
deploy directory
4. start jboss
Presto! Everything works. I'm sure there is something I don't understand -
perhaps lots of things! ;-) Is there a way to get the ootb version of the
rar working in jboss? Or is one forced to hack it up?
I noticed the Quartz scheduler comes with the version of jboss I am using. I
guess I should check out the docs on using this with the classes in my ear
to see if the pain is similar.
Any help would be greatly appreciated!
TIA,
Mike (aka patzerbud)
Here is an earlier post to this list (but I could find no reply):
>Hi,
>
>How do I configure multiple configuration files for use with the Mule 1.4
>JCA RAR?
>
>Do I have to unjar the RAR file and change the ra.xml file ? This seems to
>not be correct to me i.e. download and use a framework, configuration
>should
>be external.
>
>OR, is there some include mechanism for including one mule-config.xml
>inside
>anothee one ?
>
>Regards
>
>Steve
>
_________________________________________________________________
Tease your brain--play Clink! Win cool prizes!
http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2
---------------------------------------------------------------------
To unsubscribe from this list please visit:
Thank you for responding.
Yes, I have already read that page. In fact, the content of that page was
why in my original post I referenced the Out Of The Box (OOTB) version of
the .RAR file. I don't understand WHY I need to unpack the .RAR remove some
files, edit others, repackage it, create an ear that contains the modified
RAR, etc., etc.
Why can't I just use it 'as is'? And if I can, then how do I do so? (And get
it to use my mule configuration file as well as my custom classes...)
I also followed the instructions on the JBoss+Integration page. I was able
to deploy the mule-jboss-jca-1.4.1.ear file I created and it worked when I
simply referenced the Echo example. However, when I modified the
mule-config.xml to reference my custom classes (which are deployed in a
separate ear file) then it complained with ClassNotFoundException(s). (For
this scenario I deviated slightly from the instructions on that page and set
java2ParentDelegation to 'true' in the application.xml file of my ear.)
So, that's as far as I got before asking for help.
Thanks,
Mike (aka patzerbud)
_________________________________________________________________
Find a local pizza place, movie theater, and more….then map the best route!
http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01
separate ear file) then it complained with ClassNotFoundException(s). (For
this scenario I deviated slightly from the instructions on that page and set
java2ParentDelegation to 'true' in the application.xml file of my ear.)
You said:
I don't understand WHY I need to unpack the .RAR remove some files, edit
others, repackage it, create an ear that contains the modified RAR,
etc., etc.
The Mule JCA Resource adapter .rar file is packaged in such a way as to
be able to be deployed by any type of Application Server and not just
JBoss. However, JBoss deployment isn't as stright forward as with other
AS since JBoss does not simply look for its own ra.xml file but looks
for anything containing "ra.xml" in its name, which causes some loading
problems. In addition to this, the jca resource adapter comes packaged
with a dummy configuration file. It is assumed that you would want to
replace this configuration file with your own. However, to do this you
need to unpack and repack the rar file. With regards to the removal of
some of the jars files, again, those jar files are required for Mule JCA
to run on any AS but unfortunately these cause problems with JBoss.
You wrote:
I deviated slightly from the instructions on that page and set
java2ParentDelegation to 'true' in the application.xml file of my ear.
Like Andrew P stated setting the java2ParentDelegation to true will
remove the classloading isolation which will create problems with the
libraries that JBoss and Mule use. What you can try to do instead is to
make your EAR share the same classloader repository as mule, i.e. if
your classes are deployed to the same classloader repository then mule
should be able to find them. Alternatively you could bundle them with
the Mule Ear file, which is the approach that I prefer.
Thanks and regards
Thank you for your reply. I am happy to report that I successfully have mule
running in jboss now!
I noticed the Jboss+Integration page changed on the website. Plus, there is
a mule-jboss-1.4.2.ear available for download! I decided to try using Mule
as suggested in scenario 2 - i.e. the mule ear inside my own (user) ear.
Here are a couple of things I discovered that may help others:
1. unpack the ear
2. edit the META-INF/jboss-app.xml file and put some whitespace int the
DOCTYPE declaration between the word PUBLIC and the following double quote.
3. unpack the rar
4. edit the META-INF/ra.xml file: when specifying the
<config-property-value> for the comma-separated list of mule configuration
files I found it easiest to specify an absolute (i.e. full) path and file
location. e.g. /opt/tools/jboss/server/myserver/conf/mule-config.xml
5. repack the rar
6. repack the ear
7. In your own application.xml file don't forget to add:
<!-- mule server -->
<module>
<java>mule-jboss-1.4.2.ear</java>
</module>
Finally, I have a question. When starting up the above configuration there
is a warning having to do with the classloader isolation specified in the
mule ear's jboss-app.xml file (something about only the parent being able to
do that; sorry, I don't have the exact error message text available right
now). Is this something I need to worry about? Should I transfer the
classloader repository configuration to my own ear's jboss-app.xml file?
Thanks! I hope the above steps I documented help save others some time...
Mike (aka patzerbud)
>From: "Andrew Perepelytsya" <aper...@gmail.com>
>Reply-To: us...@mule.codehaus.org
>To: us...@mule.codehaus.org
>Subject: Re: [mule-user] How to configure mule JCA RAR
_________________________________________________________________
Can you find the hidden words? Take a break and play Seekadoo!
http://club.live.com/seekadoo.aspx?icid=seek_hotmailtextlink1
thanks for your feedback!
> 2. edit the META-INF/jboss-app.xml file and put some whitespace int the
> DOCTYPE declaration between the word PUBLIC and the following double quote.
This is definitely a bug which I have fixed for 1.4.3 now :-)
Thanks for your feedback,
-dirk
You should try and place the isolation in the parent ear otherwise there
may be a conflict (i.e. mule trying to be isolated but the user ear is
not allowing it to be). All you need to do is to add the class loader
isolation in the jboss-app in your META-INF folder inside your user ear.
The class loader isolation can be specified by the following:
<loader-repository>org.mule:loader=mule-ear-1.4.1.ear
<loader-repository-config>
java2ParentDelegaton=false
</loader-repository-config>
</loader-repository>
Please note that the loader repository should have the same name as that
which is defined in the jboss-app in the mule ear. This will enable the
user ear and mule to use the same class loader repository.
Regards
Marie Rizzo
--
View this message in context: http://www.nabble.com/How-to-configure-mule-JCA-RAR-tf4357721.html#a12667423
Sent from the Mule - User mailing list archive at Nabble.com.
The steps are listed in
http://mulesource.org/display/MULE/JBoss+Integration
I could be more helpful if you could send the exact error that you are
getting. The incomplete deployment occurs when the deployment of some
item fails, but this is a symptom and not the root of the problem. Also,
you might want to take a look at the jboss log files. Usually there is a
greater possiblilty of finding the root cause of a problem than by just
looking at the console.
Regards
Marie Rizzo