[Design the new POJO MicroContainer] - Re: MutableClassInfo?
by alesj
Why do all these MutableX take MutableY as parameters?
e.g.
| public interface MutableMethodInfo extends MethodInfo
| {
| void setReturnType(MutableClassInfo returnType);
|
Why would you force a MutableY as a return type?
"stale.pedersen(a)jboss.org" wrote :
| The usage of the Class parameter needs to be removed, internal methods using it will just use the CtClass object.
|
How does this effect the (weak type) cache?
"stale.pedersen(a)jboss.org" wrote :
| The question is the method getType(), can we just remove it altogether? -its been marked as deprecated.
|
You can, but then you have to fix all MC code. :-)
Unfortunately we have quite a few places where we use it.
MDR, Kernel, ...
"stale.pedersen(a)jboss.org" wrote :
| Is there a reason why the JMI constructor is public? if not it should be set to package protected.
|
Add a TODO, so we fix this with the future minor release,
where we can break the api. :-)
"stale.pedersen(a)jboss.org" wrote :
| We need functionality to get the method signature from a method. This could be implemented in a utilclass, but i would rather see it added to the MethodInfo interface.
|
Signature API is part of MDR sub-project.
"stale.pedersen(a)jboss.org" wrote :
| We might also need a method like ClassInfo.getClassLoader(), but i guess Kabir/Adrian know more about that.
|
I guess if you have a permission check you're fine?
"stale.pedersen(a)jboss.org" wrote :
| Javassist have a lot of functionality to create new methods/constructors/etc that i dont think we need to support directly in MCI, but rather create some util classes to do that. Im thinking of classes/methods like: CtNewMethod.copy/abstractMethod/getter/setter/delegator/etc.
|
This can come in when ever you have the time, it's a feature not a task.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204741#4204741
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204741
17 years, 2 months
[Design the new POJO MicroContainer] - Re: Module.getModuleForClassLoader()
by kabir.khan＠jboss.com
"adrian(a)jboss.org" wrote :
| What is different between that and using the bootstrap if you are asking the question
| part way through the bootstrap process?
|
The Bootstrap implementations are invoked AFTER the bootstrap deployments are deployed, so all the classloaders have been created. AbstractServerImpl:
| public void start() throws IllegalStateException, Exception
| {
| ...
| // deploys conf/bootstrap.xml and conf/bootstrap/*.xml
| doStart(watch);
|
| // TODO Fix the TCL hack used here!
| ClassLoader cl = Thread.currentThread().getContextClassLoader();
| try
| {
| // Run the bootstraps
| for (Bootstrap bootstrap : bootstraps)
| {
| Thread.currentThread().setContextClassLoader(bootstrap.getClass().getClassLoader());
| startedBootstraps.add(0, bootstrap);
| bootstrap.start(this);
| }
| }
| finally
| {
| Thread.currentThread().setContextClassLoader(cl);
| }
| ...
| }
|
"adrian(a)jboss.org" wrote :
| Maybe a better mechanism would be to use the in/uncallback to be notified of the Modules
| as they are constructed/destroyed.
|
Why is that better? I'm happy with using bootstrap, as long as the following is ok:
- use KernelDeployment.getClassLoader() to get classloader name and look that up in MC
- use ClassLoading.getModuleForClassLoader() to get the module corresponding to the classloader rather than the findModule() stuff from my workaround example
If I have understood correctly, using a bootstrap I only need to modify aop.xml, making it easy to upgrade older versions of AS. Otherwise I need to modify classloader.xml to add the in/uncallback stuff. Will that work when the classes I need are in the aop classloader that has not been deployed yet? If I add the un/incallback in aop.xml, is that retroactive, i.e. will classloaders added previously in the bootstrap process (from classloader.xml) be added?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204740#4204740
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204740
17 years, 2 months
[Design of POJO Server] - Re: Mapping web resources over VDF
by alesj
"remy.maucherat(a)jboss.com" wrote :
| "alesj" wrote :
| | At least I wouldn't limit myself to TLDs ... if that's possible.
| |
| All "standard" descriptors and annotations are already given by AS.
| context.xml files are then read through the VFS in JBossContextConfig.
| The only thing missing is really TLDs, parsed using TldLocationsCache
| and TagLibraryInfoImpl in Jasper, which is not pluggable right now.
|
| It is a two step process:
| 1) scan to associate the requested taglib uri with the location of its
| TLD
| 2) parse the actual TLD file
|
"remy.maucherat(a)jboss.com" wrote :
| "alesj" wrote :
| | afaik they are eager to get things working cleanly/nicely on the new VDF.
| |
| | Hence the mutable VFSDeploymentUnit.
| |
| That's what is used: WebApplication.getDeploymentUnit.getFile
|
| But redoing TLD processing is not trivial. I think in theory since they
| are standard EE metadata, then the parsing should be in
| JBossWebMetaData, and Jasper should not have to do any TLD scanning and
| parsing like it does right now.
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204722#4204722
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204722
17 years, 2 months
[Design of POJO Server] - Re: Using temp at undeploy
by alesj
"alesj" wrote :
| More to follow ...
|
OK, I'm done with the change,
and I'm happy with how it's done. :-)
I added a simple StructureProcessor interface
| public interface StructureProcessor
| {
| /**
| * Prepare structure metadata.
| *
| * @param deployment the deployment
| * @param structureMetaData the structure metadata
| */
| void prepareStructureMetaData(Deployment deployment, StructureMetaData structureMetaData);
|
| /**
| * Prepare context info.
| *
| * @param parentDeploymentContext the parent deployment context
| * @param contextInfo the context info
| */
| void prepareContextInfo(DeploymentContext parentDeploymentContext, ContextInfo contextInfo);
|
| /**
| * Apply structure metadata.
| *
| * @param deploymentContext the deployment context
| * @param structureMetaData the structure metadata
| */
| void applyStructureMetaData(DeploymentContext deploymentContext, StructureMetaData structureMetaData);
|
| /**
| * Apply context info.
| *
| * @param deploymentContext the deployment context
| * @param contextInfo the context info
| */
| void applyContextInfo(DeploymentContext deploymentContext, ContextInfo contextInfo);
| }
|
which gets appropriately called in AbstractStructureBuilder.
Currently the only impl is ModificationTypeStructureProcessor.
This one hold a list of previously mentioned ModificationTypeMatchers.
ModificationTypeMatcher now looks like this:
| public interface ModificationTypeMatcher
| {
| /**
| * Should we modify the file.
| *
| * @param root the deployment root
| * @param structureMetaData the current structure metadata
| * @return true if we determined modification
| */
| boolean determineModification(VirtualFile root, StructureMetaData structureMetaData);
|
| /**
| * Should we modify the file.
| *
| * @param root the deployment root
| * @param contextInfo the current context info
| * @return true if we determined modification
| */
| boolean determineModification(VirtualFile root, ContextInfo contextInfo);
| }
|
The test on how this is applied in 'reality':
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204718#4204718
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204718
17 years, 2 months