[Snowdrop] - Spring Load-Time Weaving in JBoss AS 6: Usage Notes
by Marius Bogoevici
Marius Bogoevici [http://community.jboss.org/people/marius.bogoevici] modified the document:
"Spring Load-Time Weaving in JBoss AS 6: Usage Notes"
To view the document, visit: http://community.jboss.org/docs/DOC-16458
--------------------------------------------------------------
Load-time weaving for AspectJ is a powerful feature of the Spring Framework and JBoss is one of the servers which Spring is capable of detecting automatically and for which it provides an out-of-the box LoadTimeWeaver implementation.
This means, that when running in JBoss AS 5 and later (including JBoss AS 6) the application context definition needs to include only the default namespace configuration option:
<context:load-time-weaver/>
As a result, the application context definition is fully portable and can be used for deploying in other environments.
When running in JBoss AS 6 there is one thing that you need to pay attention to: Spring's load-time weaving feature is based upon the fundamental yet not explicitly formulated assumption that the woven classes will be loaded after the application context has been started.
While this may be true in certain cases, it is still an assumption that is not backed by a standard. Wherever it is not valid, this assumption becomes a limitation and you will notice that the target classes will not be advised, although a Transformer has been registered with the classloader. What happens really is that the required transformations are not performed on the target classes, because they are already loaded.
In the particular case of JBoss AS 6, this can happen due to the annotation scanning performed by the application server. Starting with Java EE 5, annotations have been increasingly adopted means of specifying component metadata, reducing or even elliminating the need of deployment descriptors. This has simplified the task of developers, but at the same time, the deployment process has become more expensive - instead of reading metadata from a well-known location, containers have to scan and extract it from the application classes.
One of the most expensive parts of this process is reading class annotations. For solving this problem, JBoss will scan and index the application classes upfront once, leaving the individual deployers the task of interpreting them.
In JBoss AS 6, class scanning can use either Java Introspection or Javassist for reading class data. The former is more performant and therefore enabled by default, but will also load the application classes while reading their information - Javassist will read the information directly from the bytecode.
So, out of the box, with Introspection enabled, Spring applications that use load-time weaving will see their application classes unadvised. Fortunately, being aware of how load-time weaving actually works and what the assumptions (or limitations) are, you can either:
1. Reduce the scope of annotation scanning by providing a jboss-scanning.xml configuration file in your deployment see [1] and [2] for more details. While this is adding a JBoss-specific metadata to your deployment, the application remains portable as other environments will effectively ignore it - and, once again, the goal is to align the expectations of the framework (no classes will be pre-loaded) with the behaviour of the container (will load classes by default but will back off when told not to do so). This option has the advantage that works with the default JBoss AS6 configuration and can be enabled per-deployment. However, please note that annotation scanning is necessary for Java EE components, so you need to be careful what you actually exclude.
2. Switch scanning from Introspection to Javassist. This option will be available only in JBoss AS 6.1 and later (and not in JBoss AS 6.0.0.Final). In order to do so, you need to launch the AS with a specific startup option like this:
./run.sh -Dorg.jboss.reflect.spi.TypeInfoFactory=org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactory
Please note that this will enable Javassist for the entire application server. This option is not available in JBoss AS 6.0.0.Final.
Links:
[1] http://java.dzone.com/articles/jboss-microcontainer-scanning http://java.dzone.com/articles/jboss-microcontainer-scanning
[2] http://community.jboss.org/docs/DOC-13178 http://community.jboss.org/wiki/JBoss5custommetadatafiles
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16458]
Create a new document in Snowdrop at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
[JBoss Web Services] - From wsdl to java and opposite to deployable service
by jonny 69
jonny 69 [http://community.jboss.org/people/jonny69] created the discussion
"From wsdl to java and opposite to deployable service"
To view the discussion, visit: http://community.jboss.org/message/585327#585327
--------------------------------------------------------------
Hi everybody
I'm new so sory for me language and everything wrong. OK so I explain what I want to ask BIG Jboss family. I have developed Web-Service in Java using annotations, package it to .war, and deploy on Jboss. Everything is allright. After deploy on server, jboss generated .wsdl in ..server/myserver/data/wsdl/ folder, which I use to eclipse IDE to test my webservice. But what if I want to make things in different way. Based on wsdl file generate *deployable* server-side? This is a problem. I know how to use eclipse axis plugin to generate server side of webservice but after deploying on server wsdl isn't generete - because there are no annotations so jboss doesn't know hot to do it. I use Axis, and wsimport but I'm not satisfied with these. Maybe you know some tool-s which generate server side exacly or very similar to source definition of webservice.
Thanks
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/585327#585327]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 10 months
[Snowdrop] - Spring Load-Time Weaving in JBoss AS 6: A Few Usage Notes
by Marius Bogoevici
Marius Bogoevici [http://community.jboss.org/people/marius.bogoevici] created the document:
"Spring Load-Time Weaving in JBoss AS 6: A Few Usage Notes"
To view the document, visit: http://community.jboss.org/docs/DOC-16458
--------------------------------------------------------------
Load-time weaving for AspectJ is a powerful feature of the Spring Framework and JBoss is one of the servers which Spring is capable of detecting automatically and for which it provides an out-of-the box LoadTimeWeaver implementation.
This means, that when running in JBoss AS 5 and later (including JBoss AS 6) the application context definition needs to include only the default namespace configuration option:
<context:load-time-weaver/>
As a result, the application context definition is fully portable and can be used for deploying in other environments.
When running in JBoss AS 6 there is one thing that you need to pay attention to: Spring's load-time weaving feature is based upon the fundamental yet not explicitly formulated assumption that the woven classes will be loaded after the application context has been started.
While this may be true in certain cases, it is still an assumption that is not backed by a standard. Wherever it is not valid, this assumption becomes a limitation and you will notice that the target classes will not be advised, although a Transformer has been registered with the classloader. What happens really is that the required transformations are not performed on the target classes, because they are already loadaed.
In the particular case of JBoss AS 6, this can happen due to the annotation scanning performed by the application server. Starting with Java EE 5, the annotations have been increasingly adopted means of specifying component metadata, reducing or even elliminating the need of deployment descriptors. This has simplified the task of developers, but at the same time, the deployment process has become more expensive - instead of reading metadata from a well-known location, containers have to scan and extract it from the application classes.
One of the most expensive parts of this process is reading class annotations. For solving this problem, JBoss will scan and index the application classes upfront once, leaving the individual deployers the task of interpreting them.
In JBoss AS 6, class scanning can use either Java Introspection or Javassist for reading class data. The former is more performant and therefore enabled by default, but will also load the application classes while reading their information - Javassist will use read the information directly from the bytecode.
So, out of the box, with Introspection enabled, Spring applications that use load-time weaving will see their application classes unadvised. Fortunately, being aware of how load-time weaving actually works and what the assumptions (or limitations) are, you can either:
1. Reduce the scope of annotation scanning by providing a jboss-scanning.xml configuration file in your deployment. While this is adding a JBoss-specific metadata to your deployment, the application remains portable as other environments will effectively ignore it - and, once again, the goal is to align the expectations of the framework (no classes will be pre-loaded) with the behaviour of the container (will load classes by default but will back off when told not to do so). This option has the advantage that works with the default JBoss AS6 configuration and can be enabled per-deployment. However, please note that annotation scanning is necessary for Java EE components, so you need to be careful what you actually exclude.
2. switch scanning from Introspection to Javassist (available in JBoss AS 6.1). In order to do so, you need to launch the AS with a specific startup option like this:
./run.sh -Dorg.jboss.reflect.spi.TypeInfoFactory=org.jboss.reflect.plugins.javassist.JavassistTypeInfoFactory
Please note that this will enable Javassist for the entire application server.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16458]
Create a new document in Snowdrop at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 10 months
[JBoss Tools] - Tools, Tools, Tools... ESB, BPEL, and WS in JBoss Tools 3.2
by Brian Fitzpatrick
Brian Fitzpatrick [http://community.jboss.org/people/bfitzpat] modified the blog post:
"Tools, Tools, Tools... ESB, BPEL, and WS in JBoss Tools 3.2"
To view the blog post, visit: http://community.jboss.org/community/tools/blog/2011/02/08/tools-tools-tools
--------------------------------------------------------------
I've seen two major releases of JBoss Tools in my year and a half at JBoss/Red Hat. In that time, the many talented folks we have working on tooling have developed new tools and updated existing ones. Functionality has been added just about anywhere you look in the tooling.
As such, I want to call out just a few of the areas we've made progress in for JBoss Tools 3.2...
First, the ESB Editor gained support for new ESB 4.9 functionality including BPELInvoke, new methods for creating ESB actions via annotations, and Camel ESB integration. And the team also added a first cut at better validation of ESB configurations to help make sure files will will work before they're deployed.
http://community.jboss.org/servlet/JiveServlet/downloadImage/38-3604-1131... (http://community.jboss.org/servlet/JiveServlet/showImage/38-3604-11313/ws..., there's the great BPEL Editor work that Bob has already mentioned here (http://community.jboss.org/community/tools/blog/2011/01/24/bpel-technical...)
Beyond that, I have to say that I'm happy with the work we've done on the Web Service Tester that's been added. I know Bob uses it for testing web services used in BPEL processes and Lukas has used it extensively in QE. More feedback would be great, but I'm happy with where we are for a first release! You can read more about the WS Tester here (http://community.jboss.org/docs/DOC-15749).
And I'm also happy with some of the new Web Service wizards we've introduced for bottom-up WS development in this release. Though the WTP Web Service wizard works, it's not the most user friendly beast in the world and it's also not the easiest framework to extend. As such, we reused a few chunks that we'd written and found ways to present a simpler approach for developing web service artifacts for existing annotated classes.
We integrate with JBossWS and JAX-WS annotated classes and we even integrate with RESTful services if you have RESTEasy installed. So hopefully these will help you get work done a bit faster than before. You can read more about these new wizards here (http://community.jboss.org/docs/DOC-15778).
So there you have a few of the areas we've worked on for this release. As always with JBoss Tools, this is just the tip of the iceberg so be sure to keep an eye out for posts celebrating functionality in other areas!
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/community/tools/blog/2011/02/08/tools-tools-tools]
13 years, 10 months
[Beginner's Corner] - Re: Running Multiple JVMs as Windows Services on a Single System
by Peter Johnson
Peter Johnson [http://community.jboss.org/people/peterj] created the discussion
"Re: Running Multiple JVMs as Windows Services on a Single System"
To view the discussion, visit: http://community.jboss.org/message/586069#586069
--------------------------------------------------------------
I was going to say that this could be easily done, but changed my mind (not that it can;t be done, but it is a little more work). But I first have to tell you how it works before you will understand the issue. Service.bat registers jbosssvc.exe as a service. Thus when the service starts, jbosssvc.exe runs. jbosssvc.exe in truns runs service.bat (or a renamed version thereof, provided you mad the approriate changes in service.bat). As far as I know there is no way to also specify a parameter to pass to service.bat.
So, if you grabbed the source for jbosssvc.bat and made the appropriate changes, you could possibly do what you want. You would also want to change the service registration code in service.bat to paramerize the "instance" value (so that you could register instances with the single service.bat). And of course change service.bat to read in the instance configuration file. You might also have to play with the current working directory in jbosssvc.exe so that it can easily find the config files.
But consider what I did - I have a single service.bat source file. I have various configurations that currently are in a single ant script but could easily be pulled into separate ant properties file. I run the ant script, which reads the properties files and builds the run-time service.bat files for me. I never edit the run-time service.bat files - if I need to make changes I modify the properties and regenerate the runtime files.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/586069#586069]
Start a new discussion in Beginner's Corner at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 10 months
Next){kind=link}