Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports
by Adrian Brock
Adrian Brock [http://community.jboss.org/people/warjort] replied to the discussion
"Wildcard support in Dynamic-imports"
To view the discussion, visit: http://community.jboss.org/message/546816#546816
--------------------------------------------------------------
Looks kind of ok. But...
1) You should use the delegate you just created NOT the module.
The operations on the module don't respect export restrictions, they can see private stuff.
Like I said before, you shouldn't be using those module operations. They are for debug purposes on the management console.
i.e. the request starts from that module which is not the case here.
You want the operation to go through the delegate to the other policy with whatever export/import restrictions apply.
*protected* DelegateLoader resolve(String pckg)
{
Requirement requirement = *new* PackageRequirement(pckg, range);
// TODO -- add this DI to module? new DI impl to remove delegate from policy when resolved module goes away?
RequirementDependencyItem item = *new* RequirementDependencyItem(module, requirement, module.getClassLoaderState(), ControllerState.INSTALLED);
*if* (item.resolve(controller))
{
ClassLoaderPolicy policy = getPolicy();
// TODO -- add delegate to policy
return delegate;
}
*return* null;
}
2) I think you should return null for failures, I didn't check but I remember trying to write the internal handling of "not found" to not throw
ClassNotFoundExceptions all over the place. Throwing the RuntimeException would likely mean it doesn't go onto the next delegate?
3) You don't show how you are handling the undeploy of the dynamically resolved module when it is not shutdownPolicy=GarbageCollection.
It will move your ClassLoaderPolicy back to DESCRIBED since one of the dependencies has been removed. But I think you should also
remove the dynamic wildcard dependency items you will be adding in the first TODO shown above.
For shutdownPolicy=GarbageCollection you still need to do something in the Module to make the refreshPackages() stuff work properly.
For the GC policy used by OSGi, the dependsOnMe are tracked inside the Module rather than the DependencyInfo.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546816#546816]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports
by Ales Justin
Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion
"Wildcard support in Dynamic-imports"
To view the discussion, visit: http://community.jboss.org/message/546799#546799
--------------------------------------------------------------
It now boils down to this prototype (with lots of details yet to impl).
Is this what you had in mind - roughly speaking :-)?
public class WildcardDelegateLoader extends FilteredDelegateLoader
{
private Controller controller;
private Module module;
private VersionRange range;
public WildcardDelegateLoader(Controller controller, ClassLoaderPolicyFactory factory, ClassFilter filter, RequirementDependencyItem item)
{
super(factory, filter);
if (controller == null)
throw new IllegalArgumentException("Null controller");
if (item == null)
throw new IllegalArgumentException("Null item");
Requirement requirement = item.getRequirement();
if (requirement instanceof PackageRequirement == false)
throw new IllegalArgumentException("Illegal package requirement: " + requirement);
this.controller = controller;
this.module = item.getModule();
this.range = ((PackageRequirement)requirement).getVersionRange();
}
protected Module resolve(String pckg)
{
Requirement requirement = new PackageRequirement(pckg, range);
// TODO -- add this DI to module? new DI impl to remove delegate from policy when resolved module goes away?
RequirementDependencyItem item = new RequirementDependencyItem(module, requirement, module.getClassLoaderState(), ControllerState.INSTALLED);
if (item.resolve(controller))
{
ClassLoaderPolicy policy = getPolicy();
// TODO -- add delegate to policy
}
return item.getResolvedModule();
}
@Override
protected Class<?> doLoadClass(String className)
{
Module resolvedModule = resolve(ClassLoaderUtils.getClassPackageName(className));
try
{
return resolvedModule != null ? resolvedModule.loadClass(className) : null;
}
catch (ClassNotFoundException e)
{
throw new RuntimeException(e);
}
}
@Override
protected URL doGetResource(String name)
{
Module resolvedModule = resolve(ClassLoaderUtils.getResourcePackageName(name)); // TODO -- extract package name
return resolvedModule != null ? resolvedModule.getResource(name) : null;
}
@Override
protected void doGetResources(String name, Set<URL> urls) throws IOException
{
Module resolvedModule = resolve(ClassLoaderUtils.getResourcePackageName(name)); // TODO -- extract package name
if (resolvedModule != null)
{
Enumeration<URL> ue = resolvedModule.getResources(name);
while (ue.hasMoreElements())
urls.add(ue.nextElement());
}
}
@Override
protected Package doGetPackage(String name)
{
return null; // TODO -- how to get package from here, from resolved Module?
}
@Override
protected void doGetPackages(Set<Package> packages)
{
// do nothing?
}
}
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546799#546799]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"Profiles in domain.xml"
To view the discussion, visit: http://community.jboss.org/message/546605#546605
--------------------------------------------------------------
Here's a few more thoughts that fall out of this:
1. Management operations can be categorized by their type:1. Query operations which read a value
2. Update operations which change or add a value
2. Management operations can be organized into two scopes:1. Domain scope, which affect the domain object/XML model as a whole and (in the case of updates) are validated and then propagated to the relevant servers1. Only values which are configured at the domain level would be visible from the domain level; deployment specific values which were not present at the domain level would only be readable at the server scope
2. Although it is conceivable that we may decide that the DC must introspect all deployments and build a complete object model, this might or might not be practical implementation-wise1. But on the other hand, if we do this (effectively putting the functionality that is currently residing in the structure deployers into the DC), server startup would be lightning-fast because all the deployment information will be parsed out and validated already (and the servers wouldn't need to have those classes)...
2. Server scope, which *must not* affect the domain model in any way, and which take effect only on the server for which they are targeted, keeping in mind:1. Some operations might be applicable to a server group, for convenience (like retrying a deployment that failed across many servers in a group with the same failure cause, which an admin can perform when the underlying problem is fixed)1. Though this is realized as simply a broadcast of an operation across multiple servers, accumulating whatever responses come back
2. Extra-domain monitoring operations might fall into this category
3. All "actual" values that pertain to deployments would be readable at this level
4. All operations which pertain to transient run-time state (such as the failed deployment restart action I alluded to above, or other runtime administrative ops like killing connections or interrupting threads) would fall into this category
Jason points out that having the DC parse out all deployments does have a lot of advantages, and I'm starting to agree with him.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546605#546605]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years
Re: [jboss-dev-forums] [Management Development] - Profiles in domain.xml
by David Lloyd
David Lloyd [http://community.jboss.org/people/david.lloyd%40jboss.com] replied to the discussion
"Profiles in domain.xml"
To view the discussion, visit: http://community.jboss.org/message/546601#546601
--------------------------------------------------------------
To reply to an earlier message...
> Brian Stansberry wrote:
>
> But b) is more problematic. We could say the DC has access to all domain resources and can therefore start the components needed by any ServerGroup configuration and thereby determine the defaults. But... yuck. IMHO we should try really hard to avoid imposing any such requirement on the DC.
>
> We could say the DC has the ability to query the Servers to determine defaults, but besides being a can of worms it means the admin can't just start the DC and manipulate the domain configuration.
Jason had a good solution to this problem. The configuration classes would know the defaults (which are in their corresponding XML schemas); by having the configuration classes separate from their projects (not unlike how the metadata project is intended to work, if I understand correctly), we can have the best of both worlds. The domain controller (DC) can map the XML configuration into these classes at the domain level, and pass the object model on to the servers, which can then use that information directly to configure and/or override the deployed services.
Basically a configuration module for a given subsystem could have these responsibilities:
1. Register any XML namespace(s) it is associated with (on the DC)
2. Have the ability to validate & convert any relevant XML segments to the corresponding object model (on the DC)
3. Be responsible for configuring the subsystem they are associated with (on the server instance) via that subsystem's individual API
4. Knowing the management operations (queries and updates) available for a subsystem, and:1. Making the DC aware of them, and
2. Knowing how they affect the object model, so that
3. when the operation is sent to the DC and is passed on to the server instances, the DC and the server instances can all update their local domain models appropriately, to retain a consistent view.
4. Having an object representation of each management operation to effect the above.
5. Have the ability to convert the configuration they represent back into XML (on the DC)
6. Be aware of default values for any given configuration item (reflected in the schema as well)
This also would imply that the domain model passed to the server instances is actually a serialized representation.
An interesting issue this raises is how to deal with management operation failures in a server group. In my view, the only sane way to handle it is to persist the change anyway, but make sure the admin client is aware of the problem. This solution also enables consistent behavior between (a) making a change which affects a server which is not currently running and (b) making a change which fails to take effect for some reason.
Note that performing santiy checks and validation on the DC can minimize this (to give a simple example, the DC *should* be able to detect if you've assigned two services to the same port and are attempting to put those services in the same server group).
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546601#546601]
Start a new discussion in Management Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years