[Design of OSGi Integration] - Re: BundleActivatorDeployer Questions
by adrian＠jboss.org
"johnbailey" wrote :
| So the current thoughts are:
| 1. Invoke the Activator through REAL deployer - This just invokes the Activator and does not create a new kernel context
| 2. Continue to use the REAL deployer to create the BeanMetaData -allows the Activator to have decencies fulfilled prior to being invoke
|
You can implement both and let the user decide. It's easily configurable
which BundleActivatorDeployer they want. :-)
anonymous wrote :
| Please correct any terms I am misusing, I am still getting comfortable with the codebase, and there are a lot of classes that I could see being called "deployment".
I'm using the word deployment as a generic concept.
A deployment has lots of different 'views":
Deployment - the client side view
DeploymentContext - the internal view seen by the MainDeployer
DeploymentUnit - a facade over the DeploymentContext used by the deployers
DeploymentControllerContext - the deployment as seen by the Microcontainer
etc.
You're adding another one that makes it look like an OSGi bundle.
If you have a link to the DeploymentControllerContext in your Bundle facade
then you can move the deployment between the different DeploymentStages.
See DeployersImpl for how this works during normal deployment.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130228#4130228
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130228
18 years, 1 month
[Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote :
| First, does module name equate to the osgi bundle symbolic name? We would also need additional policy information that equates to the Require-Bundle header parameters.
|
As I understand it, yes. Although I allow multiple names, i.e.
multiple module capabilities/aliases.
I'm using a "context name" internally, which you can either specifiy explicitly
or it will generate one for you as "name:version"
anonymous wrote :
| "adrian(a)jboss.org" wrote :
| | 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. ;-)
| |
| I guess, I can't see why one would want to use both syntaxes.
|
I've erronously tried to do so in the tests which is why I thought about implementing it. :-)
anonymous wrote :
| "adrian(a)jboss.org" wrote :
| | 4) Should I create an included export filter?
| | This would mean all classes are in the classloader, but only
| | the listed packages are exported.
| | 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". :-)
| |
| I don't see the difference between this and the export-all="ALL" included="..." notion. What is the difference?
|
This would be exportAll="ALL" includedExport="p1,p2,p3".
The "included" by itself also controls what you can see of yourself in the module,
an included export or the package capabilities control what others can see,
i.e. your exports.
NOTE: included and excluded are still valid with explicit capabilities
since they only act as an additional filter that applies to both
you and others rather than as a potentially conflicting one. ;-)
anonymous wrote :
| "adrian(a)jboss.org" wrote :
| | 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?
| |
| What would the version be fixed up to? In terms of modules, unless its mapped to something usable like the deployment name, how would the fixed up name be usable?
|
Possible fix ups would be:
* Even if capabilities are explicit always add a module capability from the name
given in the top level element. e.g. for deployments it could be the deployment
name.
* If there is a version in the top level element then add that to any capability
that would otherwise have 0.0.0 as its version (the default, unspecified version).
anonymous wrote :
| "adrian(a)jboss.org" wrote :
| | b) Is it worth trying to go through the "hard problem" of merging
| | the simple but not very explicit exportAll processing with explicit capabilities?
| I think we need to go through the resolution process when there are amiguities to see if there are defaults we should fixup to minimize problems.
|
The issues would be around contradictory specifications, e.g.
| <classloader exportAll="ALL" excludeExport="p1">
| <capability>
| <package name="p1"/>
| ...
|
So is p1 in the exports or not? ;-)
There's probably other more complicated examples.
Especially since I didn't mention that although these filters are shown
as lists of packages, I'm potentially allowing any ClassFilter and wildcard
capabilities so I don't necessarily know exactly what they mean,
although I do know if the Capability implements ExportPackages
which is part of the way.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130223#4130223
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130223
18 years, 1 month
[Design of OSGi Integration] - Re: BundleActivatorDeployer Questions
by johnbailey
Thanks for the clarification.
I see why we wouldn't deploy the bundle and just allow access to the DeploymentControllerContext through the Bundle facade.
I am still not sure I am clear on the BundleActivator deployment.
So the current thoughts are:
1. Invoke the Activator through REAL deployer - This just invokes the Activator and does not create a new kernel context
2. Continue to use the REAL deployer to create the BeanMetaData -allows the Activator to have decencies fulfilled prior to being invoke
3.
anonymous wrote :
| If you want to create a kernel controller context for the bundle activator
| that's a different issue. e.g. in "PRE-REAL" you could create the context
| and make the deployment moving to REAL dependent on that "POJO".
|
In this option a context would be created in the PRE-REAL stage. What is meant by the "deployment" being made in the move to REAL? Is this the DeploymentControllerContext?
Please correct any terms I am misusing, I am still getting comfortable with the codebase, and there are a lot of classes that I could see being called "deployment".
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130219#4130219
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130219
18 years, 1 month
[Design the new POJO MicroContainer] - Re: Wrong dependency info after module uninstall
by alesj
"adrian(a)jboss.org" wrote :
| 1) Does the same problem exist in the new code? I don't understand your description
| about overriding a method with the same name.
|
Yup, the problem is still there.
Just run the test case, and tell what is the real missing dependency. :-)
What I meant with overriding is that unresolved from RequirementDI should override the unresolved(Controller) method from AbstractDI, which is what gets called when doing the uninstall.
Probably that's what was already intended in the first place, but we changed the signature of unresolved when introducing cardinality on callbacks.
The method went from (void + no params) to (boolean + Controller param). And RequirementsDI's unresolved is equal to the first/initial usage.
"adrian(a)jboss.org" wrote :
| 2) Does IncompleteDeploymentException use the toHumanReadableString()
| method on the DependecyItem?
|
Yes.
Once the iDependOn is nullified, this will get used in DeployersImpl.checkControllerContext method.
| Object iDependOn = item.getIDependOn();
| if (iDependOn == null)
| {
| dependency = "<UNKNOWN>";
| actualStateString = "** UNRESOLVED " + item.toHumanReadableString() + " **";
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130218#4130218
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130218
18 years, 1 month
[Design the new POJO MicroContainer] - Source code tidyup MC project - MetaType generics
by adrian＠jboss.org
The MC project had got into a bit of a mess with over 2000 warnings
in my eclipse workspace. It was taking forever to compile/load the projects with
it using so much memory. :-)
Most of them were javadoc or incorrect use of generics.
I've managed to get rid of all but 48 of them. The remaining ones are in the
generated code of the OSGi parser.
Boy did that take longer than expected. ;-)
Anyway. while I was doing it, it occurred to me that the generics
in the MetaType project are mostly useless.
I experimented with getting rid of them altogether. By doing that
I can see only two use cases, one of which is pointless.
1) There is <T extends Serializable) but the same thing is easily achieved
with the setValuie(Serializable value) on the MetaValue.
2) Being able to iterate over arrays (which looking at the tests
only works for single dimensional arrays). I don't see why this
is an important use case? In practice you won't know the array type
at compile time to make use of it?
In fact, it is impossible to write out a correct generic type for the more
complicated Arrays, e.g. arrays of composite types.
The code looks a lot less cluttered without the generics.
Most places have to do MetaType<?> anyway.
So should we bite the bullet and remove the generics, or does somebody
think they are useful?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4130217#4130217
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130217
18 years, 1 month
[Design the new POJO MicroContainer] - Re: ClassLoadingMetaData ease-of-use
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote :
| NOW FOR THE QUESTIONS.
|
First, does module name equate to the osgi bundle symbolic name? We would also need additional policy information that equates to the Require-Bundle header parameters.
"adrian(a)jboss.org" wrote :
| 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. ;-)
|
I guess, I can't see why one would want to use both syntaxes.
"adrian(a)jboss.org" wrote :
| 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.
|
Sure, this would be a reason to use the expanded syntax.
"adrian(a)jboss.org" wrote :
| 4) Should I create an included export filter?
| This would mean all classes are in the classloader, but only
| the listed packages are exported.
| 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". :-)
|
I don't see the difference between this and the export-all="ALL" included="..." notion. What is the difference?
"adrian(a)jboss.org" wrote :
| 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?
|
What would the version be fixed up to? In terms of modules, unless its mapped to something usable like the deployment name, how would the fixed up name be usable?
"adrian(a)jboss.org" wrote :
| 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=4130216#4130216
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4130216
18 years, 1 month