[Design of POJO Server] - Tomcat deployer ported to VDF
by scott.stark＠jboss.org
An initial port of the tomcat deployer to the VDF has been checked in, and javaee14 style wars are deploying/working (for example, jmx-console.war). The classes that have been replaced are:
org.jboss.web.AbstractWebContainer replaced by org.jboss.web.deployers.AbstractWarDeployer
org.jboss.web.tomcat.tc6.Tomcat6 replaced by org.jboss.web.tomcat.tc6.deployers.TomcatDeployer
org.jboss.web.AbstractWebDeployer replaced by
org.jboss.web.deployers.AbstractWarDeployment
org.jboss.web.tomcat.tc6.TomcatDeployer replaced by
org.jboss.web.tomcat.tc6.deployers.TomcatDeployment
In addition, there are metadata deployers that remove the need for these classes to parse any web.xml/jboss-web.xml. org.jboss.deployment.WebAppParsingDeployer translates a web.xml descriptor into a org.jboss.metadata.WebMetaData instance. org.jboss.deployment.JBossWebAppParsingDeployer translates a jboss-web.xml descriptor into the existing org.jboss.metadata.WebMetaData instance. Short term TODOs for metadata processing include:
* Restore integration with the ejb3 annotation processing layer. The org.jboss.web.tomcat.tc6.TomcatInjectionContainer usage is currently commented out as this really should be external to the tomcat deployer. However, to get back to functioning servlet2.5 deployments it needs to be hooked up.
* Update the TomcatInjectionContainer to use the org.jboss.metadata.* classes. The org.jboss.web.metamodel.descriptor.* and org.jboss.metamodel.descriptor.* classes have been merged into the existing org.jboss.metadata.* classes.
Longer term TODOs to properly aspectize the tomcat layer include:
* integrate the annotations into the object model. Adrian is working a common framework for this.
* expand the web.xml parsing to include everything tomcat needs to run off of this rather than reparsing the web.xml.
* create deployers to translate the tomcat server.xml/context.xml.
* Update the TomcatDeployer/TomcatDeployment to run off of this rather than the current jmx stuff.
The deployers are packed up in the server/xxx/deployers/jbossweb-tomcat6.deployer directory:
| jbossweb-tomcat6.deployer/
| + META-INF/jboss-structure.xml - input into the structural deployment phase to identify the deployment structure context and classpath.
| + META-INF/war-deployers-beans.xml - an mc bean deployment descriptor that declares the war deployers and injects them into the MainDeployer. This replaces the old jboss-service.xml.
| + META-INF/webserver-xmbean.xml - currently unused jmx mbean info for the old Tomcat6 mbean.
| + conf/
| + context.xml
| + server.xml
| + annotations-api-temp.jar
| + el-api.jar
| + jasper-jdt.jar
| + jbossweb-extras.jar
| + jbossweb.jar
| + jboss-web-metamodel.jar - obsolete
| + jsf-libs/
| + jsp-api.jar
| + jstl.jar
| + servlet-api.jar
| + tomcat6-service.jar
|
An overview of the deployment process.
The relative order of the deployer defines the point at which it runs in the deployment process. The lower the order, the earlier the deployer runs. The relative ordering of the war-deployers-beans.xml deployers is:
org.jboss.deployment.WebAppParsingDeployer (1)
org.jboss.deployment.JBossWebAppParsingDeployer (2)
org.jboss.web.tomcat.tc6.deployers.TomcatDeployer (3)
The WebAppParsingDeployer runs first to parse the WEB-INF/web.xml into a org.jboss.metadata.WebMetaData object graph. It extends the org.jboss.deployers.plugins.deployers.helpers.ObjectModelFactoryDeployer to define the deploymentType to WebMetaData, and implements getObjectModelFactory to return a org.jboss.metadata.web.WebMetaDataObjectFactory instance and, deploy(DeploymentUnit unit) to invoke createMetaData(unit, webXmlPath, null) to trigger the parsing of the web.xml descriptor. The result will be stored in the unit transient managed object attachments under the key "org.jboss.metadata.WebMetaData" with an expected type of WebMetaData.
The JBossWebAppParsingDeployer runs next to parse the WEB-INF/jboss-web.xml into the existing WebMetaData object graph produced by the WebAppParsingDeployer. It extends the org.jboss.deployers.plugins.deployers.helpers.ObjectModelFactoryDeployer to define the deploymentType to WebMetaData, and implements getObjectModelFactory to return a org.jboss.metadata.web.JBossWebMetaDataObjectFactory instance and, deploy(DeploymentUnit unit) to invoke createMetaData(unit, webXmlPath, null) to trigger the parsing of the jboss-web.xml descriptor. The result will be stored in the unit transient managed object attachments under the key "org.jboss.metadata.WebMetaData" with an expected type of WebMetaData.
The TomcatDeployer runs last to translate the WebMetaData instance attached by the WebAppParsingDeployer/JBossWebAppParsingDeployer deployers into a org.jboss.system.metadata.ServiceMetaData instance representing the service mbean of the web application. The web application bean is represented by the org.jboss.web.tomcat.tc6.deployers.TomcatDeployment service bean. This implementation is a bridge between the legacy jmx service oriented deployer and the pure microcontainer bean based deployer. Longer term I expect the TomcatDeployer to be an extension of org.jboss.deployers.plugins.deployers.helpers.AbstractComponentDeployer<WebMetaData, SomeWebComponentMetaData> that translates the web-app WebMetaData into SomeWebComponentMetaData for the servlets, jsp pages, etc., and a new AbstractSimpleRealDeployer will create kernel bean metadata to deploy these components directly to the microcontainer.
See the http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5DeploymentFramework for an overview of the VDF and existing classes/deployers.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978367#3978367
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978367
19 years, 5 months
[Design of JBoss Transaction Services] - Re: transaction support in JBossAS 5.0
by mark.little＠jboss.com
"reverbel" wrote : "mark.little(a)jboss.com" wrote : However, although I understand why you're doing this reference approach, I'm not convinced it buys you much. The size of an IOR is so large anyway when compared to an Xid, that saving a few bytes is unlikely to make much of a difference on the number of blocks that get written in the log. It's the number of physical disk blocks and not the amount of information, that makes a difference.
| The difference needs to be measured. An Xid can take up to 128 bytes, but in an IOR it will take up to 256 bytes, due to the encoding of bytes as pairs of ASCII characters that represent hex digits. This looks like a significant increase in the size of IORs,
|
For small IORs, yes. However, it really depends on the ORB implementation. I've used pretty much every C++ and Java ORB that has been around since the mid 1990's and I've seen several (names withheld to protect the innocent!) where the IOR is in excess of 4K.
anonymous wrote :
| but it may or may not have a significant impact on the performance of marshalling, transaction context propagation, and logging tasks. The impact is more likely to be significant in the case of JBossRemoting, whose URIs are much smaller than IORs and WS-Addressing endpoint references. But it needs to be measured anyway.
|
Agreed. Ultimately this approach may be something that is best chosen at runtime (dynamically) by a deployer/sys admin when all of the related implications are known. Plus it may depend on what implementation of logging you're using. For example, if you use replicated NVRAM, then there's no notion of a physical block size and it may be that my previous comment doesn't apply.
anonymous wrote :
| It appears that we are in agreement that this is a reasonable approach, which has a conceptual advantage (it avoids nesting of globally unique identifiers), but whose practical benefits need to be validated by measurements.
|
| Regards,
|
| Francisco
|
Yes, now that I have all of the information ;-) I think it's actually quite an interested research topic. If you need any help/input, let me know.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978315#3978315
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978315
19 years, 6 months
[Design of JBoss ESB] - How to start jbossesb?
by jinmy liao
recently,i have down the jbossesb-4.0Beta1MP1,and installed it.
but when i run the example of TestJBossESB,the exception appearance is :
whether my install have error,how can i get a simple document to get start? thank you.
----------------------------------------
C:\Document\java\jbossesb\jbossesb-4.0Beta1MP1\docs\samples\TestJBossESB>SET ESB
_HOME=C:\Document\java\jbossesb\jbossesb-4.0Beta1MP1
C:\Document\java\jbossesb\jbossesb-4.0Beta1MP1\docs\samples\TestJBossESB>SET JBO
SS_HOME=D:\App\jboss-4.0.4.GA
C:\Document\java\jbossesb\jbossesb-4.0Beta1MP1\docs\samples\TestJBossESB>java -c
p C:\Document\java\jbossesb\jbossesb-4.0Beta1MP1/build/dist/lib/jbossesb-service
s.jar;C:\Document\java\jbossesb\jbossesb-4.0Beta1MP1/build/dist/lib/jbossesb-com
mon.jar;C:\Document\java\jbossesb\jbossesb-4.0Beta1MP1/build/dist/lib/jbossesb-l
isteners.jar;D:\App\jboss-4.0.4.GA/client/jbossall-client.jar;D:\App\jboss-4.0.4
.GA/client/log4j.jar;D:\App\jboss-4.0.4.GA/client/jboss-aspect-jdk50-client.jar;
D:\App\jboss-4.0.4.GA/client/jboss-aop-jdk50-client.jar;D:\App\jboss-4.0.4.GA/cl
ient/jboss-ejb3-client.jar;. org.jboss.soa.esb.listeners.GpListener paramsDir/Fi
leMoverConfigExample.xml
09:02:00,375 INFO ParamFileRepository:62 - Setting parameter repository root di
r to [C:\Document\java\jbossesb\jbossesb-4.0Beta1MP1\docs\samples\TestJBossESB\.
].
09:02:00,781 ERROR GpListener:328 - Cannot launch <org.jboss.soa.esb.listeners.D
irectoryPoller>
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.jboss.soa.esb.listeners.GpListener.tryToLaunchChildListener(GpLis
tener.java:323)
at org.jboss.soa.esb.listeners.GpListener.run(GpListener.java:279)
at org.jboss.soa.esb.listeners.GpListener.main(GpListener.java:67)
Caused by: java.lang.Exception: Directory C:\de\jbossesb\product\docs\samples\Te
stJBossESB\inputDir not found
at org.jboss.soa.esb.listeners.DirectoryPoller.seeIfOkToWorkOnDir(Direct
oryPoller.java:148)
at org.jboss.soa.esb.listeners.DirectoryPoller.checkMyParms(DirectoryPol
ler.java:98)
at org.jboss.soa.esb.listeners.DirectoryPoller.(DirectoryPoller.ja
va:48)
... 7 more
09:03:00,609 INFO GpListener:290 - Reloading parameters _______________________
______________________________
09:03:00,703 ERROR GpListener:328 - Cannot launch <org.jboss.soa.esb.listeners.D
irectoryPoller>
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at org.jboss.soa.esb.listeners.GpListener.tryToLaunchChildListener(GpLis
tener.java:323)
at org.jboss.soa.esb.listeners.GpListener.run(GpListener.java:279)
at org.jboss.soa.esb.listeners.GpListener.main(GpListener.java:67)
Caused by: java.lang.Exception: Directory C:\de\jbossesb\product\docs\samples\Te
stJBossESB\inputDir not found
at org.jboss.soa.esb.listeners.DirectoryPoller.seeIfOkToWorkOnDir(Direct
oryPoller.java:148)
at org.jboss.soa.esb.listeners.DirectoryPoller.checkMyParms(DirectoryPol
ler.java:98)
at org.jboss.soa.esb.listeners.DirectoryPoller.(DirectoryPoller.ja
va:48)
... 7 more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978300#3978300
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978300
19 years, 6 months