JBossDeveloper

"scott.stark@jboss.org" wrote:
ManagedOperations are never property getters if that is what you mean. They are bean methods that may return a value.

"adrian@jboss.org" wrote:

NOTE: Even the joinpoint stuff in the existing KernelBus is irrelevant.
It is legacy from when I was experimenting with AOP/POJO and JMX implementing the
Joinpoint api. The DispatchContext replaced this.

"adrian@jboss.org" wrote:

All that was required was to extend the dispatch api to have the name of the target
and add that to the kernel bus api.

"adrian@jboss.org" wrote:

We need to find a way to remove the getClassLoader()
and make it an implementation detail, or introduce a permission check
into the implementations. Exposing classloaders in public methods is a security hole.

See Class.getClassLoader() or Thread.currentThread().getContextClassLoader()
for the kind of checks required.

 public ClassLoader getClassLoader() throws Throwable
 {
 SecurityManager sm = System.getSecurityManager();
 if (sm != null)
 sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);
 return Configurator.getClassLoader(getBeanMetaData());
 }

 public ClassLoader getClassLoader() {
 ClassLoader cl = getClassLoader0();
 if (cl == null)
 return null;
 SecurityManager sm = System.getSecurityManager();
 if (sm != null) {
 ClassLoader ccl = ClassLoader.getCallerClassLoader();
 if (ccl != null && ccl != cl && !cl.isAncestor(ccl)) {
 sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);
 }
 }
 return cl;
 }

"adrian@jboss.org" wrote:
You can getCallerClassLoader() using code similar to the HACK class in the classloader project, although it is suble because you need to skip reflection classes.

 protected Class<?> getRequestingClass(Class[] stack)
 {
 for (Class clazz : stack)
 {
 if (Hack.class.isAssignableFrom(clazz) == false &&
 JDKChecker.class.isAssignableFrom(clazz) == false &&
 BaseClassLoaderDomain.class.isAssignableFrom(clazz) == false &&
 BaseClassLoaderPolicy.class.isAssignableFrom(clazz) == false &&
 ClassLoader.class.isAssignableFrom(clazz) == false &&
 Class.class.isAssignableFrom(clazz) == false)
 {
 return clazz;
 }
 }
 throw new RuntimeException("Should not be here!");
 }

"scott.stark@jboss.org" wrote:

The properties are updated during the ManagementView.process call based on what updateComponent calls have been made. These currently just map back to the deployemnt attachment.

 ManagedProperty ctxProp = serverComp.getProperties().get(prop.getName());
 // Check for a mapped name
 if( ctxProp == null )
 {
 String mappedName = prop.getMappedName();
 if( mappedName != null )
 ctxProp = serverComp.getProperties().get(mappedName);
 }
 if( ctxProp == null )
 {
 formatter.applyPattern(i18n.getString("ManagementView.InvalidTemplateProperty")); //$NON-NLS-1$
 Object[] args = {prop.getName()};
 String msg = formatter.format(args);
 throw new IllegalArgumentException(msg);
 }
 ctxProp.setValue((Serializable)prop.getValue());

"scott.stark@jboss.org" wrote:

... we also need to send the change to the runtime component.

*** CONTEXTS IN ERROR: Name -> Error

vfsfile:/C:/projects/jboss5/trunk/build/output/jboss-5.0.0.Beta3/server/profileservice/deploy/testHqldbDS-ds.xml -> org.xml.sax.SAXParseException: Premature end of file.

"scott.stark@jboss.org" wrote:

The call to the ctxProp.setValue is the server side invocation on the ManagedProperty that is wired to the metadata. This changes the metadata instance associated with the deployment.

"scott.stark@jboss.org" wrote:

This is what Weston is working on.

"scott.stark@jboss.org" wrote:

It has to tie into the setValue call for ViewUse.RUNTIME properties. However that is best done. Seems like within the ManagementViewImpl to the KernelBus is how it has to be done. Don't we need the KernelBus updates to replace the RuntimeComponentDispatcher?