Re: [jboss-user] [JBoss Microcontainer] - jbossws-cxf and the spring libs in AS
by Alessio Soldano
Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion
"jbossws-cxf and the spring libs in AS"
To view the discussion, visit: http://community.jboss.org/message/549784#549784
--------------------------------------------------------------
> Ales Justin wrote:
> > While of course spring would not be needed in that case, the deployment unit classloader would not see the required cxf classes from cxf jars (as those need to be in the isolated classloader together with the spring jars because some classes in cxf jars references classes in spring jars).
> This looks more complicated then, and it would be good to know the details.
>
> e.g. we could add "the needed cxf classes that rely on spring" (crs) dynamically
Sound interesting... let's see how that could be done
> * hopefully we can lookup @Endpoint annotation w/o crs
Yes, we can as that "@Endpoint" is actually @WebService / @WebServiceProvider, which stay in the jaxws api jar. The code doing the check is in the jbossws container integration, which has no direct reference/dependency on anything stack specific.
> * if there is @Endpoint present in deployment, add crs to deployment's classpath
ok (well, if there deployment is a ws one, we need at least "cxf - crs", whole "cxf + spring" if there's the spring descriptor, but let's go on with the reasoning)... when / how to do that? shouldn't this happen before the real stage?
Besides that, this assumes we isolate crs from the rest of CXF classes. crs are almost always alone in separate "spring" packages in cxf (except for few particular cases which I could probably work on @Apache if we come to a solution requiring that)... are you thinking about specifying the packages to be included in a given classloader/domain?
Btw, here is the current dependency situation:
http://community.jboss.org/servlet/JiveServlet/showImage/3568/dep1.jpg http://community.jboss.org/servlet/JiveServlet/downloadImage/3568/450-277...
basically the jbossws-cxf integration uses cxf as well as spring directly when there's need to (actually right now it detects if spring is available on the classloader at deploy time, but that can be easily changed into looking for the existence of the spring conf file).
Coming to a situation like the following should not be a major problem:
http://community.jboss.org/servlet/JiveServlet/showImage/3569/dep2.jpg http://community.jboss.org/servlet/JiveServlet/downloadImage/3569/450-227...
iow we could isolate jbws_crs into different jars from the rest of jbossws-cxf integration, for simplyfing the isolation. Doing the same on apache cxf stuff is instead much more complicated and can't be easily done.
> ** if spring is already in deployment, only add (crs - spring)
Oh.. this is something I've been thinking about too, but finally thought it was probably asking too much ;-) Well, if there's a way for using the spring already included in the user deployment... that would most probably be the best solution, especially because we would not include spring at all in the AS.
We're of course able to detect that at deploy time (simply trying loading a spring class using the classloader for the deployment unit). Again, the problem then is the jars of jbossws-cxf integration (as well as the CXF ones) are loaded from a classloader that does not see spring. Ideally, for completing the deployment, we would need to get another classloader seeing everything (what's on the server, including "crs" + spring) and use that. I've been trying something on this line few days ago, basically loading a "bootstrap" jbossws-cxf-integration class for the first time in the deployment unit's classloader (in a case where spring is included in the deployment) and trying going on with the deployment process there (expecting this to work because the parent of the unit cl is the jbossws.deployer one using the big-ball-of-mud domain). But that failed, as far as I understand because in there I of course use cxf and jbossws-cxf-integration classes that come from jars already loaded by the common classloader that does not see spring.
Perhaps the solution here, if any, also lies in being able to separate "crs" from other classes (either by jar structure refactoring for jbws or by specifying packages in the jboss-classloading.xml or equivalent).
> Just thinking out loud ... :-)
Me too... considering my classloading / MC knowledge here is most probably not the same as yours...
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549784#549784]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
[JCA] - Using JMS managed connections for outbound connectivity?
by henk de boer
henk de boer [http://community.jboss.org/people/henk53] created the discussion
"Using JMS managed connections for outbound connectivity?"
To view the discussion, visit: http://community.jboss.org/message/549770#549770
--------------------------------------------------------------
If I define a JCA connection factory for JMS connections to a remote JMS provider ((JBoss Messaging), can these connections then be used for outbound connectivity? E.g. sending a message to a remote queue?
I.e. suppose I would have a definition like the one below in a -ds.xml file, with an appropriate JmsProviderAdapter for the remote JBoss AS server:
<tx-connection-factory>
<jndi-name>RemoteJmsXA</jndi-name>
<xa-transaction/>
<rar-name>jms-ra.rar</rar-name>
<connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
<config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/RemoteJMSProvider</config-property>
<max-pool-size>20</max-pool-size>
<depends>jboss.messaging:service=ServerPeer</depends>
</tx-connection-factory>
What can I then do myself with these connections? Is this connection factory only supposed to be used with stuff like bridges or invokers, or can I also request a connection in user code from this factory and use it to send a JMS message to a remote queue?
I did a quick test with this, and found that no matter what I do, the messages I sent using such a managed connection always end up being handled by the local PostOffice, which has no knowledge of any remote queue or topic and thus refuses to do any routing. If I use a remote queue that happens to have the same name as a local queue, then the PostOffice seems to sent it to this local queue, even though I'm using a managed connection to the remote server and a destination that I obtained from the JNDI of the remote server.
Any insight would be highly appreciated.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549770#549770]
Start a new discussion in JCA at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
[JBoss Portal] - Newbie Jboss EJB questions
by baa baa
baa baa [http://community.jboss.org/people/baabaa] created the discussion
"Newbie Jboss EJB questions"
To view the discussion, visit: http://community.jboss.org/message/549769#549769
--------------------------------------------------------------
1. Is there a way to use the debugger to debug EJB beans or webservices inside Eclipse-Jboss? Not the client code. I want to know about the server code(using the log files is an option, but I want to know about the debugger).
2. Is there a way to get the Eclipse Webservices explorer to work for SSL webservices?
I am able to test my webservice with a client which takes VM commandline arguments for keystore. But I am not able to test the webservice with the eclipse webservices explorer. I get "IWAB0135E An unexpected error has occurred. javax.net.ssl.SSLHandshakeException"
Is there a way to configure Eclipse so that there is no such error?
3. Building and deploying an EJB component as a Web service
I have a choice of implementing some functionality as plain old Java classes or as EJB beans. So suppose we implement and deploy such webservices (from Beans) on Jboss.
The question I have is:
When such webservice methods are called, will there be any advantage in implementing the classes as Beans instead of Plain Java classes?
Specifically If the webservice is based of plain old java classes will the "webserver" execute all the code in the Plain Java classes also?
If the webservice is based of beans, is the code in the beans executed by the "JBOSS app server" instead of "webserver", thereby improving scalabilty and performance?
What is the deciding factor?
Why would I want to convert an EJB to Webservice? Why isnt every java class an EJB automatically?
Please comment on how I should make this decision(whether to base my webservice on a java class or EJB java class).
4. Does Eclipse require JBoss server to be running inside Eclipse for autogeneration of webservice code from wsdl and server-config.wsdd? Or is there a way to configure Eclipse so that it can connect to the external Jboss running on the same machine and still generate webservice code completely from eclipse. If server is not running inside eclipse, the webservice code generation fails to generate server-config.wsdd.
Thanks for the responses
BB
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549769#549769]
Start a new discussion in JBoss Portal at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
[JBoss Tools Development] - How to Build JBoss Tools with Maven3
by Denis Golovin
Denis Golovin [http://community.jboss.org/people/dgolovin] created the document:
"How to Build JBoss Tools with Maven3"
To view the document, visit: http://community.jboss.org/docs/DOC-15513
--------------------------------------------------------------
Current trunk version of JBoss Tools can be built with maven 3 and make it faster and easier for everyone.
h2. Prerequisites
1. Java 1.6 SDK
2. Maven 3.beta1
3. About 6 GB of free disk space if you want to run all integration tests for (JBoss AS, Seam and Web Services Tools)
4. subversion client 1.6.X (should work with lower version as well)
h2. Environment Setup
h3. Maven and Java
Make sure your maven 3 is available by default and Java 1.6 is used.
$mvn -version
should print out something like
Apache Maven 3.0-alpha-7 (r921173; 2010-03-09 14:31:07-0800)
Java version: 1.6.0_18
Java home: /usr/lib/jvm/java-6-openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.32-22-generic-pae" arch: "i386" Family: "unix"
h3. Sources
Checkout sources from anonymous SVN like
svn co https://svn.jboss.org/repos/jbosstools/trunk jbosstools-src
This will take some time dependent on your bandwidth
h2. Build Strategies
All commands below is assuming that commands are executed in jbosstools-src folder after sources checked out as it suggested above.
There are several strategies to chose from building everything to build particular component or part of it like all plug-ins, all tests, all features, particular plugin/feature.
Target platform should be built first like
$mvn -f build/target-platform/pom.xml
If you want to just compile the modules, tests can be skipped by adding system property -Dmaven.test.skip=true and you should be able to faster verify compile issues.
h3. Build/Test Everything
Current version cannot be build without local changes because of problem with with drools component, so to go with this scenario you need to remove drools references from pom.xml and site/site.xml. After that to build/test everything use:
$mvn clean install
h3. Build/Test Particular Component with Dependencies
For convenience there are aggregator projects defined for each component. It provides a simple way to build/test components with dependencies.
$mvn clean install -f build/component/${component.name}.xml
where ${component.name} is component you want to build/test. Currently build/component folder contains aggregator projects for:
1. tests
2. jmx
3. archives
4. as
5. common
6. seam
more is coming soon.
h3. Build/Test Single Component
Be aware that to get this work all dependencies for this component must be installed in maven repo. It can be done by build everything first or by build component and its dependencies using aggregated project as it explained above. You can skip tests for this build and then enable them back when you run single component build.
To build single component use pom.xml in component's folder like it is shown below.
$mvn clean install -f ${component.name}/pom.xml
where ${component.name} is component's root folder name. For instance to build jmx component use command below
$mvn clean install -f jmx/pom.xml
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15513]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 10 months
