[Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use
by adrian＠jboss.org
OFF-TOPIC: Also for completeness.
There's other metadata for the classloader.
Old "big ball mud" (import everything in the same domain)
| <classloading importAll="true" xmlns="urn:jboss:classloading:1.0"/>
|
Servlet spec style
| <classloading parent-first="false" xmlns="urn:jboss:classloading:1.0"/>
|
Domain hierarchies
| <classloading domain="MyDomain" parentDomain="AnotherDomain" xmlns="urn:jboss:classloading:1.0"/>
|
Caching and blacklisting (enabled by default)
| <classloading cache="false" blackList="false" xmlns="urn:jboss:classloading:1.0"/>
|
And you can also "write your own classloader dependency"
since the metadata supports wildcards on the Capability/Requirement interfaces.
| <classloading xmlns="urn:jboss:classloading:1.0">
| <capabilities>
| <module name="test" version="1.0.0"/>
| <test xmlns="urn:jboss:test:classloading:capability:1.0" name="foo" version="1.0.0"/>
| </capabilities>
| <requirements>
| <test xmlns="urn:jboss:test:classloading:requirement:1.0" name="bar" from="1.0.0"/>
| </requirements>
| </classloading>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129721#4129721
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129721
18 years, 1 month
[Design the new POJO MicroContainer] - ClassLoadingMetaData ease-of-use
by adrian＠jboss.org
I'd like to here people's opinions on the following issues
with the new OSGi classloading metadata.
First some explanation.
The classloading metadata looks like this:
| <classloading xmlns="urn:jboss:classloading:1.0">
|
| <!-- capabilities are classloading exports -->
| <capabilities>
| <!-- This deployment can be referenced by either of these two module names -->
| <module name="export2" version="2.0.0"/>
| <module name="export1" version="1.0.0"/>
| <!-- It exports these packages with the given versions -->
| <package name="export2" version="2.0.0"/>
| <package name="export1" version="1.0.0"/>
| </capabilities>
| <!-- requirements are classloading imports -->
| <requirements>
| <!-- It needs to import the following modules -->
| <module name="import2" from="2.0.0"/>
| <module name="import1" from="1.0.0"/>
| <!-- and packages -->
| <package name="import2" from="2.0.0"/>
| <package name="import1" from="1.0.0"/>
| </requirements>
| </classloading>
|
OFF-TOPIC: The above is the deployment metadata, i.e. META-INF/jboss-classloading.xml where the "classpath" is already known
from the deployment structure.
There's a similar one for use in a -beans.xml, except
in a different namespace because there you have to specify the
roots as well, e.g.
| <deployment>
| <classloader><inject bean='MyClassLoader"/></classLoader>
|
| <classloader name="MyClassLoader" xmlns="urn:jboss:classloading:1.0">
| <!-- similar to above -->
|
| <root>${jboss.lib.url}/some.jar</root>
| <root>${jboss.lib.url}/another.jar</root>
| </classloader>
|
| <!-- beans here -->
| </deployment>
|
For ease-of-use and "backwards compatibity" there are some shorthands.
Module name and version shorthand which automatically
creates a single module capability.
| <classloading name="test" version="1.0.0" xmlns="urn:jboss:classloading:1.0"/>
|
Exporting all packages
| <classloading name="test" version="1.0.0" export-all="ALL"
| xmlns="urn:jboss:classloading:1.0"/>
|
Exporting all packages with an inclusion filter
i.e. only the packages listed are part of the classloader and exported
| <classloading name="test" version="1.0.0" export-all="ALL" included="org.jboss.package1,org.jboss.package2"
| xmlns="urn:jboss:classloading:1.0"/>
|
Exporting all packages with an exclusion filter
i.e. all packages are included in the classloader and exported except
the ones listed
| <classloading name="test" version="1.0.0" export-all="ALL" excluded="org.jboss.package1,org.jboss.package2"
| xmlns="urn:jboss:classloading:1.0"/>
|
Exporting all packages with an excluded export filter
i.e. all packages are included in the classloader but the given classes
are not exported
| <classloading name="test" version="1.0.0" export-all="ALL" excludedExport="org.jboss.package1,org.jboss.package2"
| xmlns="urn:jboss:classloading:1.0"/>
|
In the above examples with filters, the packages are automatically
created as "capabilities" with the same version as the module.
Note: the exportAll and explicitly listing capabilities are mutually exclusive.
ExportALL and its related filters are ignored if you list capabilities explicity
NOW FOR THE QUESTIONS.
1) Is the above "Note" about mutual exclusion of exportAll and listing
capabilities correct? If not, it could get very messy trying to merge them. ;-)
2) In the filter case, the packages automatically get the version of the module,
but this doesn't happen for listing capabilities explicitly
| <classloading xmlns="urn:jboss:classloading:1.0">
| <capabilities>
| <module name="export1" version="1.0.0"/>
| <package name="export2"/>
|
The package export2 has version 0.0.0 if you are explicit.
3) Similar to (2) there is no fixup on the explicit capabilities.
| <classloading xmlns="urn:jboss:classloading:1.0">
| <capabilities>
| <package name="export2"/>
|
This deployment has NO module capability.
4) Should I create and included export filter?
While this might seem obvious, it is effectively the same as listing the
packages in the capabilities and therefore redundant.
It would also mean that "exportAll" doesn't really have that meaning anymore,
instead a better name would be something like "autoDiscoverPackages". :-)
SUMMARY
The above questions boil down to two issues.
a) Do you think we should "fixup" the capabilities, i.e.
missing module capabilities, missing package versions
or should we just do what the user says?
b) Is it worth trying to go through the "hard problem" of merging
the simple but not very explicit exportAll processing with explicit capabilities?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129715#4129715
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129715
18 years, 1 month
[Design the new POJO MicroContainer] - Re: Concurrent deployments
by adrian＠jboss.org
"bstansberry(a)jboss.com" wrote :
| "adrian(a)jboss.org" wrote :
| | The Deployments (which are also managed for dependency by the MC)
| | also run in "manual" mode which might be a good thing
| | since it would still ensure that classloaders are constructed in a predictable order
| | on one thread.
|
| Did you mean the "Deployers" here?
No, I mean't the deployments. Each deployment is managed by the MC
as it goes through its states. It is "manual" because it will only advance
to the next state when the "MainDeployer' says it can.
During startup The MainDeployer tells all deployments to advance to Parse,
the all to advance to Describe, repeated for each stage.
But the MC may veto the request if a deployment is missing a depenendency.
e.g. a deployment could have a classloading dependency on a different deployment
that is not deployed (osgi style classloading rules).
But in general this all happens currently on the bootstrap or hot deployment scanner
thread.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129663#4129663
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129663
18 years, 1 month
[Design the new POJO MicroContainer] - BeanMetaDataBuilder
by adrian＠jboss.org
I've done a major tidyup on the BeanMetaDataBuilder.
A lot of it was javadoc but there were some other problems.
1) Although this class is public api, the only way to get access to it was
from a private api. BeanMetaDataBuilderFactory :-)
2) There were a lot of things you could not do, especially with the install metadata
or creating values to pass to the metadata
I've changed the interface to an abstract class to include both factory methods
and also to implement most of the helper methods based on a small amount
of implementation detail abstract methods.
I added some factory methods for values.
This also included a helper for parameters/properties
addParameter(..., String string) instead of Object
which creates a StringValueMetaData, i.e. it can use property editors
instead of just passing the String.
I also reworked the installs so you can pass reasonable values,
i.e. ValueMetaData, with a special method for the common case of "this".
I also add methods to configure the "factory" part of the constructor.
There's still some work to do on the in/uncallbacks which currently have no support.
But this class is a lot more useful now. Not that it wasn't useful before, but it
only catered for simple cases (unless you fell back to using implementation details).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129661#4129661
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129661
18 years, 1 month
[Design the new POJO MicroContainer] - Re: MC deadlock
by adrian＠jboss.org
"adrian(a)jboss.org" wrote : I think I've found a problem related to this?
| Although I haven't managed to reproduce the problem so I can't be sure
| it is actually this issue.
|
I found the problem but not the solution. :-)
I think I managed to find a way to reproduce the problem by putting a Thread.sleep() i
n a key place and was able to see what was really causing the problem.
The issue is a "sneaky thread".
Thread 1: managing classloading for somebody else does some classloading
Thread 2: starts to do classloading on the same classloader
Thread 1: finishes and tries to unlock (it doesn't hold the classloader monitor - but it does hold the lock on the classloader loading tasks)
Thread 1: It releases the ReentrantLock
Thread 2: checks the ReentrantLock and decides to continue
Thread 2: can't get the classloading tasks (held by thread 1)
Thread 1: Tries to do a notifyAll() which requires the classloader monitor (held by thread 2)
So basically, we need to stop the sneaky thread 2 from continuing into the
classloading until we've done the notifyAll(). The notifyAll is only there
to improve performance so waiting threads don't block for 10 seconds
between checks on the ReentrantLock - i.e. we wake up the waiting
threads immediately after we release lock.
So, I've fixed the problem by putting the release of the ReentrantLock
inside holding the classloader monitor.
This will force the "sneaky" thread to go into the acquireLock wait
(where it will release the classloader monitor)
until the releasing has done its notifyAll() and no longer needs the classloader monitor.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129658#4129658
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129658
18 years, 1 month