[Microcontainer] - Re: Blog post about deployers
by adrian＠jboss.org
PHILOSOPHY
I'd say you mostly got it correct Bob.
The part you are missing is actually the most important part.
The Deployers create components, i.e. metadata for MBeans and POJOs
(or other component models).
They don't directly create anything, deployers are about MetaData processing.
Instead it is the Microcontainer that creates the runtime objects from this
component metadata when their dependencies are satisfied.
CLASSLOADING
The "magic" that occurs in the ClassLoader part is because it is doing
"two stage" deployment.
The DESCRIBE stage populates the ClassLoading system to say what classloaders you
want to construct - ClassLoadingMetaData).
This includes any dependencies (similar to OSGi)
e.g. My deployment needs version 1.0 of the com.acme.foo package.
META-INF/jboss-classloading.xml
| <classloading xmlns="urn:jboss:classloading:1.0">
| <requirements>
| <package name="com.acme.foo" version="1.0"/>
| </requirements>
| </classloading>
|
Only when that dependency is satisfied (thanks to some more "magic" in
the microcontainer :-) will it allow your deployment to move to the CLASSLOADER stage.
Of course, the CLASSLOADER stage actually creates the classloader
and wires together the related deployments so your deployment can see
the requested modules/packages.
WAR CLASSLOADING
The WEB classloader is probably the most complicated,
so it was probably a bad example for a simple explanation. :-)
In general, the ClassLoadingMetaData comes from three different places.
1) META-INF/jboss-classloading.xml (PARSE STAGE)
2) A specific deployer for the deployment type (POST PARSE)
3) The ClassLoadingDefaultDeployer (DESCRIBE)
For a WAR we have to do special things. WARs get their own classloader
that does "servlet spec" classloading, i.e. parent last,
hence the WARClassLoaderDeployer. This is true whether the WAR is a top
level deployment or a part of another archive, e.g. an EAR
For other deployments the ClassLoadingDefaultDeployer just
creates a simple "standard" classloader for the whole deployment (if you don't describe
it explicitly using the xml).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178372#4178372
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4178372
17 years, 9 months
Considered UNSOLICITED BULK EMAIL, apparently from you
by Content-filter＠localhost
A message from <jboss-user(a)lists.jboss.org> to:
-> awf(a)leftside.org
was considered unsolicited bulk e-mail (UBE).
Our internal reference code for your message is 02103-08/JaDUNRu5FmYt
The message carried your return address, so it was either a genuine mail
from you, or a sender address was faked and your e-mail address abused
by third party, in which case we apologize for undesired notification.
We do try to minimize backscatter for more prominent cases of UBE and
for infected mail, but for less obvious cases of UBE some balance
between losing genuine mail and sending undesired backscatter is sought,
and there can be some collateral damage on both sides.
First upstream SMTP client IP address: [121.235.83.51]
According to a 'Received:' trace, the message originated at: [121.235.83.51],
[192.168.15.76] [192.168.15.76]
Return-Path: <jboss-user(a)lists.jboss.org>
Message-ID: <20080923154139.5FDE61BE48D(a)leftside.org>
Subject:
=?windows-1251?B?4uX35fDo7ergIPEg5+3g7OXt6PLu8fL/7OggLSDoIOrw8/Lu6SDy8A==?=
=?windows-1251?B?4PUg7+7x6+Ug7/z/7eroLi4uIPXu9+X4/CDj6//t8/L8PyD36PLg6Q==?=
=?windows-1251?B?IA==?=
Delivery of the email was stopped!
17 years, 9 months