Re: ClassLoader Deadlock fix was: Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Adrian [EMAIL PROTECTED] wrote on 25/05/2007 12:44:54: On Thu, 2007-05-24 at 11:00 +0100, Glyn Normington wrote: A better approach would be for the Java 7 platform to provide first class support for JSR 291. This boils down to standardising the experimental class loader deadlock fix ([1]) Fixing the deadlock just moves the problem. You'll still get ClassCircularityErrors when competing threads try to load classes using locks other than the classloader synchronization or they don't synchronize on the loadClass() or they release the lock during the classloading request to let others have a go (again to avoid the deadlock). This is because of the way the dictionary class determines whether a circular load is occuring. Although I haven't tried it with OpenJDK so maybe the dictionary class contains some other fixes to workaround the problem? The simple form of the problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4699981 has been fixed in recent JDKs, but spurious CCEs still exist in other cases. e.g. the testAbstractFactoryConcurrent() here: http://viewvc.jboss.org/cgi-bin/viewvc. cgi/jbossas/projects/microcontainer/trunk/classloader/src/tests/org/jboss/test/classloader/delegate/test/DelegateUnitTestCase. java?revision=62792view=markup will show CCEs in the log if you enable TRACE logging. 1445 TRACE [ClassLoaderManager] Run failed with exception java.lang.ClassCircularityError: org/jboss/test/classloader/delegate/support/b/TestFactoryImplementation at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) Some spurious CCEs were indeed fixed before the experimental deadlock fix was introduced, but there may be more to do to make this fix robust and complete. If you raise a sunbug for the above testcase, best to report it here so that class loader rearchitecture folks can take it into consideration for Java 7. Glyn Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Bryan Atsatt [EMAIL PROTECTED] wrote on 30/05/2007 19:11:02:
Responses inline, and a few clarifications here (I was a bit tired when
I finished this last night :^)...
The main point I was trying to make is that resolution must occur within
a specific context, but I don't think my example APIs showed that well.
I was assuming that ImportResolver had a ModuleContext as a field, but
we can make this much cleaner and easier to understand by passing it as
an argument:
public abstract class ImportResolver {
public abstract Module resolve(ModuleDefinition def,
ModuleContext ctx);
}
And we can really tie this together by adding a convenience method to
ModuleContext:
public abstract class ModuleContext {
...
public Module resolve(ModuleDefinition def) {
return getImportResolver().resolve(def, this);
}
}
Now resolution becomes simply:
context.resolve(definition);
(I also left out any use of the ImportPolicy, as it isn't yet clear to
me that it should remain a separate type in this model.)
// Bryan
Glyn Normington wrote:
*Bryan Atsatt [EMAIL PROTECTED]* wrote on 30/05/2007 07:57:59:
Andy Piper wrote:
At 23:19 25/05/2007, Stanley M. Ho wrote:
Anyway, it seems the EG consensus so far is to not add import
package
support. If any EG member disagrees, please speak up.
Well, it depends on what the solution for enabling
interoperation
with JSR 291 is.
Our requirement is that there must be a solution, if that
requires
import package, so be it. If not then not.
Exactly.
I think we can all agree that, at minimum, interoperation means
that
classes and resources are sharable *across* ModuleSystems at
runtime.
Which implies that *import dependencies must be resolvable across
multiple ModuleSystem instances*. (BTW, I think we should change
the
state name PREPARING to RESOLVING in 7.2.1.)
Agreed. We must avoid the trap of thinking that module system interop.
can be achieved by exposing class loaders (as loadClass will happily
load unexported classes).
So the open issue is the richness of the import language: must we
support only lowest-common-denominator, or can we do better without
over-complicating the design?
I for one would like to be able to have a single module express
dependencies on modules from both the same and different
ModuleSystems,
*using the standard semantics of each*. This may be reaching too
far,
but we should at least explore it seriously while we figure out
what
interop means here...
At this point, I feel that is likely to be reaching too far, but I'm
happy to play along and see what we can learn along the way.
BASICS
So far, we only know of two different import semantics:
module-name, and
package-name. For discussion, let's call these:
a. import-module
b. import-package
So, to start, we could:
1. Support declaration of both import types. If 294 supports
imports at
all, it should be relatively easy to support both, since a
superpackage
name is a module name, and it contains member package names.
(Compiler
support is clearly the critical issue here, but it will obviously
require use of the 277 runtime, so the import *type* should be
transparent to it.) At worst, we'd need two new annotation types.
A superpackage name is a deployment module name in the JSR 277 model
of
one superpackage per deployment module, but I don't see any reason why
a
JSR 291 deployment module should not contain more than one
superpackage.
So if 294 were to support import, then its import-module would really
be
a superpackage import rather than a development module import.
If we end up with nested superpackages, might it make sense to model
multiple superpackages by enclosing them in a single top-level one?
That is an option, but of course each nested superpackage has to name its
parent, so it wouldn't be possible to combine superpackages from
independent groups or sources without either modifying their superpackage
declarations or getting them to agree on the name of the parent
superpackage and code it themselves.
2. Provide API for both import types (e.g. ImportDependency has
getModuleName() and getPackageName() methods, one of which will
return
null on a given instance).
However, we know these are necessary but not sufficient. Leaving
aside
the resolution issue for a moment, support for import-package also
suggests that we:
3. Enable a single module to declare different versions for each of
its
member packages.
4. Enable efficient Repository lookup by package name.
I think these are relatively easy (but *could* be considered
optional).
We also need:
5. Standard Query types for lookup by module and package name
Re: Exported resources
Some feedback from an observer which may help:
Bryan misses the need for extender model to load internal impl classes
ala
Bundle.loadClass in OSGi.
You do not want to have to export the service impl class from a module.
You want to hide the class from others' casual loading. However an
extender bundle (e.g. ServiceLoader) will need to be able to load that
class to make it instances of it available to others under the service
interface class.
Glyn
Bryan Atsatt [EMAIL PROTECTED] wrote on 30/05/2007 21:21:36:
I've been assuming that Module private resources should not be visible
to *any* class outside of the module. Including ResourceBundle, or any
other existing framework classes that do resource lookups (e.g.
ServiceLoader, JSF, etc). If resources need to be visible to these
existing classes, they must be exported. The very simple check I
proposed (immediate caller) is sufficient to make this assertion.
I believe your point is that if we used the permission model instead, it
would become possible for a module to invoke an external class (e.g.
ResourceBundle.getBundle()) and enable *it* to successfully load a
private resource from the module.
Aside from the permission *grant* mechanism this model would rely on, it
is an entirely different model than that used for classes! (Though we
haven't explicitly defined this in 294, it seems extremely unlikely that
we will rely on permissions--none of the other access modes do so.) Such
asymmetry is very disconcerting to me, and, I believe, just plain
wrong...
Consider that you could grant the ServiceLoader, for example, access to
a resource that names a class that it could not instantiate. That class
would have to be exported. I believe the resource should be as well.
// Bryan
Stanley M. Ho wrote:
Hi Bryan,
Those resource-related methods in ClassLoader can be called by anyone,
including code that is part of the module, code that is from other
modules, or code that is part of the platform libraries (e.g.
ResourceBundle). The approach you described would require walking the
stack to get the caller's Module, but the real issue is that it is
difficult to determine who the actual caller is from the stack.
Treating the immediate caller on the stack as the actual caller
wouldn't
be sufficient because the immediate caller could be called by someone
else who is the one actually making the call. On the other hand,
treating the originated caller on the stack as the actual caller would
be the right semantic, but this is basically the same as the security
permission approach.
- Stanley
Bryan Atsatt wrote:
Both solutions require stack walking (unless there is some new
implementation of the java security model I've not yet seen!).
The permission check does much more work than is necessary here. Take
a
look at AccessController.checkPermission() to see what I mean.
And actually there is a very simple API to get the stack, which I've
used for years:
private static class StackAccessor extends SecurityManager {
public Class[] getStack() {
return getClassContext();
}
}
private static final STACK_ACCESSOR = new StackAccessor();
Now the enclosing class can simply call STACK_ACCESSOR.getStack().
// Bryan
Stanley M. Ho wrote:
Hi Bryan,
Bryan Atsatt wrote:
1. Definitely agree that resource search order should be identical
to
class search order.
Glad to hear!
2. Using permissions to limit access to private resources seems
like
overkill to me. The prototype implemented this in a very simple
fashion:
a. If resource is exported, return it, else
a. Get the caller's Module (get class from stack, get module from
it)
b. If callerModule == this, return resource, else return null.
The issue is that this approach still requires stack walking and
there
is no public API in the SE platform that let you implement this.
If stack walking is required for the check anyway, I think the
security
permission approach is better that it is implementable with the
existing
API in the SE platform.
- Stanley
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Strawman: Services and service-providers support
http://jcp.org/en/eg/download/jsr-277-service-provider-strawman-05222007.pdf?id=277fileId=3438 Glyn Andy Piper [EMAIL PROTECTED] wrote on 14/06/2007 12:43:45 PM: I share Glyn's concerns, but can someone remind me where the strawman is?! Thanks! andy At 11:07 AM 6/14/2007, Glyn Normington wrote: Stanley M. Ho [EMAIL PROTECTED] wrote on 13/06/2007 07:19:10 PM: Since I have not heard any further input on the services and service-providers strawman, I suppose the EG is fine with the strawman overall except the issue raised by Richard. Unless I hear any objection, I will incorporate the appropriate portion of the strawman based on the feedback you have provided into the next revision of the specification. I am very concerned that the scope of JSR 277 is being expanded considerably without much attention being paid to the state of the art (particularly Spring-OSGi and Declarative Services). If we could implement good interoperation with JSR 291, we could delegate the complexities of supporting services to JSR 291 and technologies like Spring-OSGi that layer nicely on top of JSR 291. Apart from that, the support for services in the strawman has some obvious holes, so I don't think it is ready to be incorporated into the JSR 277 specification: 1. It seems to be lacking any form of dependency injection. 2. The namespace of services is global, but not partitioned by service interface version. The effect of this is that a module could import v1 of a service interface class and obtain an instance of the service that implements v2 of the service interface and get a class cast exception. 3. There is no support for dynamic updates of service providers and notification of service updates to service consumers. (This is consistent with JSR 277's static nature, but I point it out as this is an obvious future requirement based on our experience in OSGi.) 4. There seems to be some confusion in the strawman between loading of service interfaces/implementations and construction and publication of service instances. I wonder what other Expert Group members think of this strawman. Silence does not necessarily indicate happiness, so it would be good to have more feedback. Glyn -- Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
