[Design of POJO Server] - Re: VFS Permissions - JBMICROCONT-149
by alesj
"anil.saldhana(a)jboss.com" wrote : This is because I got the policy working for the vfs urls and now the mc releases have switched to real urls.
|
You can do something like this:
| import org.jboss.classloading.spi.dependency.policy.ClassLoaderPolicyModule;
| import org.jboss.classloading.spi.metadata.ClassLoadingMetaData;
| import org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy;
| import org.jboss.deployers.plugins.classloading.AbstractClassLoaderDescribeDeployer;
| import org.jboss.deployers.spi.DeploymentException;
| import org.jboss.deployers.structure.spi.DeploymentUnit;
| import org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule;
|
| /**
| * VFSClassLoaderDescribeDeployer that exposes realURL flag in VFSDeploymentClassLoaderPolicyModule.
| *
| * @author ales.justin(a)jboss.org
| */
| public class VFSClassLoaderDescribeDeployer extends AbstractClassLoaderDescribeDeployer
| {
| /**
| * The useRealURL flag.
| */
| private boolean useRealURL;
|
| protected ClassLoaderPolicyModule createModule(DeploymentUnit unit, ClassLoadingMetaData classLoadingMetaData) throws DeploymentException
| {
| return new UseRealFlagVFSDeploymentClassLoaderPolicyModule(unit);
| }
|
| private class UseRealFlagVFSDeploymentClassLoaderPolicyModule extends VFSDeploymentClassLoaderPolicyModule
| {
| private UseRealFlagVFSDeploymentClassLoaderPolicyModule(DeploymentUnit deploymentUnit)
| {
| super(deploymentUnit);
| }
|
| @Override
| protected VFSClassLoaderPolicy determinePolicy()
| {
| VFSClassLoaderPolicy policy = super.determinePolicy();
| policy.setUseRealURL(useRealURL);
| return policy;
| }
| }
|
| /**
| * Set use real url flag.
| *
| * @param useRealURL the real url flag
| */
| public void setUseRealURL(boolean useRealURL)
| {
| this.useRealURL = useRealURL;
| }
| }
|
And change the existing VFSClassLoaderDescribeDeployer in deployers.xml.
Just make sure you add this class where deployers.xml classpath points to.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193038#4193038
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193038
16 years, 1 month
[Design the new POJO MicroContainer] - Re: MC upgrade breaks scoped aop tests in trunk
by adrian＠jboss.org
"kabir.khan(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : "kabir.khan(a)jboss.com" wrote :
| | | Some code in GenericBeanAspectFactory.doCreate() handled that scenario and pushed the correct loader to use into the underlying GenericBeanFactory.
| | |
| | How did this work? I don't see anything in the previous GBF code that allowed you
| | to override the classloader (other than the metadata).
| |
| The "pushed" metadata was the mechanism. For some reason the GBF.getClassLoader() always returned null,
I think this is the real change isn't it? It would depend upon how you
created/deployed the GBF's metadata. How old is the previous code I showed?
anonymous wrote :
| and I think the KCC loader was ignored previously. Anyway, whatever was put in by the metadata did work.
|
This is the code from 7 months ago before recent changes.
You can see it looks at the context first
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine...
But actually looking at the logic behind all this, I don't see why we need to look
at the context for classloader since the next step is to ask the
ClassLoaderMetaData anyway (or use the TCL absent that).
| private Object createBean(ClassLoader cl) throws Throwable
| {
| ClassLoader loader = cl;
| if (loader == null)
| loader = Configurator.getClassLoader(classLoader);
|
For everybody else, this will be same as asking the controller context
since the "classLoader" above is the same ClassLoaderMetaData.
But for you who wants to change the logic, it will do something different.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193035#4193035
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193035
16 years, 1 month
[Design the new POJO MicroContainer] - Re: MC upgrade breaks scoped aop tests in trunk
by kabir.khan＠jboss.com
What I am doing now and which makes all tests pass locally again is:
GenericBeanAspectFactory:
| protected Object doCreate(Advisor advisor, InstanceAdvisor instanceAdvisor, Joinpoint jp)
| {
| try
| {
| log.debug("Creating advice " + name);
|
| Object object = null;
| final ClassLoader loader = getCreatingClassLoader(advisor);
| if (loader == null)
| {
| object = factory.createBean();
| }
| else
| {
| if (context == null)
| {
| throw new IllegalStateException("Attempting to create aspects in an undeployed factory");
| }
| KernelConfigurator configurator = context.getKernel().getConfigurator();
| ClassLoaderAwareGenericBeanFactory factoryWrapper = new ClassLoaderAwareGenericBeanFactory(configurator, loader, (GenericBeanFactory)factory);
| object = factoryWrapper.createBean();
| }
|
|
| if (object instanceof XmlLoadable)
| {
| ((XmlLoadable)object).importXml(element);
| }
| configureInstance(object, advisor, instanceAdvisor, jp);
| return object;
| }
| catch (Throwable throwable)
| {
| throw new RuntimeException(throwable);
| }
| }
|
| private ClassLoader getCreatingClassLoader(Advisor advisor)
| {
| if (advisor == null)
| {
| return getLoader();
| }
| return SecurityActions.getClassLoader(advisor.getClass());
| }
|
The createBean() and invokeLifecycle() methods are modified copies of the GBF and AbstractBeanFactory equivalents
| public class ClassLoaderAwareGenericBeanFactory implements BeanFactory
| {
| ClassLoader loader;
| GenericBeanFactory delegate;
| KernelConfigurator configurator;
|
| public ClassLoaderAwareGenericBeanFactory(KernelConfigurator configurator, ClassLoader loader, GenericBeanFactory factory)
| {
| this.configurator = configurator;
| this.loader = loader;
| this.delegate = factory;
| }
|
| public Object createBean() throws Throwable
| {
| if (loader == null)
| {
| return delegate.createBean();
| }
| else
| {
| BeanInfo info = null;
| if (delegate.getBean() != null)
| info = configurator.getBeanInfo(delegate.getBean(), loader, delegate.getAccessMode());
|
| Joinpoint joinpoint = configurator.getConstructorJoinPoint(info, delegate.getConstructor(), null);
| Object result = joinpoint.dispatch();
| if (info == null && result != null)
| info = configurator.getBeanInfo(result.getClass(),delegate.getAccessMode());
|
| if (delegate.getProperties() != null && delegate.getProperties().size() > 0)
| {
| for (Map.Entry<String, ValueMetaData> entry : delegate.getProperties().entrySet())
| {
| String property = entry.getKey();
| ValueMetaData vmd = entry.getValue();
| PropertyInfo pi = info.getProperty(property);
| pi.set(result, vmd.getValue(pi.getType(), loader));
| }
| }
| invokeLifecycle("create", delegate.getCreate(), info, loader, result);
| invokeLifecycle("start", delegate.getStart(), info, loader, result);
| return result;
|
| }
| }
|
| protected void invokeLifecycle(String methodName, LifecycleMetaData lifecycle, BeanInfo info, ClassLoader cl, Object target) throws Throwable
| {
| if (lifecycle == null || lifecycle.isIgnored() == false)
| {
| String method = methodName;
| if (lifecycle != null && lifecycle.getMethodName() != null)
| method = lifecycle.getMethodName();
| List<ParameterMetaData> parameters = null;
| if (lifecycle != null)
| parameters = lifecycle.getParameters();
| MethodJoinpoint joinpoint;
| try
| {
| joinpoint = configurator.getMethodJoinPoint(info, cl, method, parameters, false, true);
| }
| catch (JoinpointException ignored)
| {
| return;
| }
| joinpoint.setTarget(target);
| joinpoint.dispatch();
| }
| }
|
| }
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193032#4193032
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193032
16 years, 1 month
[Design the new POJO MicroContainer] - Re: MC upgrade breaks scoped aop tests in trunk
by kabir.khan＠jboss.com
"adrian(a)jboss.org" wrote : "kabir.khan(a)jboss.com" wrote :
| | Some code in GenericBeanAspectFactory.doCreate() handled that scenario and pushed the correct loader to use into the underlying GenericBeanFactory.
| |
| How did this work? I don't see anything in the previous GBF code that allowed you
| to override the classloader (other than the metadata).
|
The "pushed" metadata was the mechanism. For some reason the GBF.getClassLoader() always returned null, and I think the KCC loader was ignored previously. Anyway, whatever was put in by the metadata did work.
"adrian(a)jboss.org" wrote :
| Asking the controller context essentially asks the ClassLoaderMetaData
| if it has one (otherwise it uses the TCL),
| which will be coming from whatever you setup in the deployer.
|
That is different from the ClassLoaderMetaData that is in GBF. Maybe not before I start messing around with things, but definitely after calling GBF.setClassLoader().
"adrian(a)jboss.org" wrote :
| AbstractAopMetaDataDeployer
|
| | private void deploy(FakeComponentUnit unit, BeanMetaData deployment) throws DeploymentException
| | {
| | // No explicit classloader, use the deployment's classloader
| | if (deployment.getClassLoader() == null)
| | {
| | try
| | {
| | // Check the unit has a classloader
| | unit.getClassLoader();
| | // TODO clone the metadata?
| | deployment.setClassLoader(new DeploymentClassLoaderMetaData(unit)); // HERE
| | }
| | catch (Exception e)
| | {
| | log.debug("Unable to retrieve classloader for deployment: " + unit.getName() + " reason=" + e.toString());
| | }
| | }
| |
|
Yes, that sets the correct classloader to use for the GenericBeanAspectFactory. But when needing to create an instance from a scoped classloader with no child delegation that also defines the class, that is the wrong loader (i.e. the parent). In all other cases this loader is fine.
"adrian(a)jboss.org" wrote :
| anonymous wrote :
| | Rather than calling GBF directly from GBAF, if there is a pushed classloader I am trying to wrap GBF in a wrapper class that implements the same createBean() method, but with the option to specify the classloader. This gives me better results although I am still seeing some failures.
|
| The ClassLoaderMetaData is also used to decide the classloader for other things,
| e.g. string conversion to classes so I don't think being able to specify a classloader
| on the GBF method is much help without rewriting all the metadata classes to also
| allow the classloader to be overridden.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193029#4193029
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193029
16 years, 1 month
[Design the new POJO MicroContainer] - Re: MC upgrade breaks scoped aop tests in trunk
by adrian＠jboss.org
"kabir.khan(a)jboss.com" wrote :
| Some code in GenericBeanAspectFactory.doCreate() handled that scenario and pushed the correct loader to use into the underlying GenericBeanFactory.
|
How did this work? I don't see anything in the previous GBF code that allowed you
to override the classloader (other than the metadata).
anonymous wrote : However, now the underlying GenericBeanFactory will always use the loader of its KernelControllerContext to create the bean instance, so in the case outlined the wrong loader is used to create the bean.
|
This hasn't changed. All that changed is that this retrieval is now in a privileged block.
Asking the controller context essentially asks the ClassLoaderMetaData
if it has one (otherwise it uses the TCL),
which will be coming from whatever you setup in the deployer.
AbstractAopMetaDataDeployer
| private void deploy(FakeComponentUnit unit, BeanMetaData deployment) throws DeploymentException
| {
| // No explicit classloader, use the deployment's classloader
| if (deployment.getClassLoader() == null)
| {
| try
| {
| // Check the unit has a classloader
| unit.getClassLoader();
| // TODO clone the metadata?
| deployment.setClassLoader(new DeploymentClassLoaderMetaData(unit)); // HERE
| }
| catch (Exception e)
| {
| log.debug("Unable to retrieve classloader for deployment: " + unit.getName() + " reason=" + e.toString());
| }
| }
|
anonymous wrote :
| Rather than calling GBF directly from GBAF, if there is a pushed classloader I am trying to wrap GBF in a wrapper class that implements the same createBean() method, but with the option to specify the classloader. This gives me better results although I am still seeing some failures.
The ClassLoaderMetaData is also used to decide the classloader for other things,
e.g. string conversion to classes so I don't think being able to specify a classloader
on the GBF method is much help without rewriting all the metadata classes to also
allow the classloader to be overridden.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193019#4193019
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193019
16 years, 1 month
[Design of JBoss ESB] - Re: ServiceInvoker / deliver in new transaction
by camunda
Hi Mark.
I agree 100% with you, synchronous delivery shouldn't be the default paradigm in a SOA world. And I think everybody starting with the ESB should read at least some of the literature you mentioned (I like especially Gregor Hohpes articles and interviews on that).
But at some layer close to the client you often try to hide the asynchronism if possible (e.g. the UI should display some result if possible synchronously). In our app we face this requirement but since we do not expose the ServiceInvoker to the client, the client accesses a SLSB instead as entry point. And it will behave synchronously if we get an answer within the timeout period, otherwise the client will get a "try to fetch result later on"...
I agree, that people should not be motivated to use synchronism in a SOA, but it would be nice to have it supported better out-of-the-box...
Anyway, for the moment it seems I have to implement the code around the ServiceInvoker myself :-/. But at least I can post the code for other people facing this requirement later...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193018#4193018
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193018
16 years, 1 month