[
https://issues.apache.org/jira/browse/ONAMI-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591356#comment-13591356
]
Mikhail Mazursky commented on ONAMI-95:
---------------------------------------
0. What is the usecase for this? I'm just very curious =)
"Traditional" scoping of objects is: JVM -> ClassLoader -> Injector (in case of
Guice) -> Guice's Scope -> Object instance. Why would something created in a
narrower scope be brought to an outer scope? For me it's like setting static
fields from an instance method.
1. Correct me if i'm wrong but i'm pretty sure this implementation will not
work under OSGi - system classloader can not see classes from bundles. The same
holds for application servers (Tomcat, Jetty, etc). As an ugly workaround one
can place Onami Scopes jar on system classpath.
2. Looks like testMultiClassLoader() test is not working as it may be expected:
- First of all you are not loading Guice class with different classloaders -
see docs for ClassLoader class [1] ("The ClassLoader class uses a delegation
model to search for classes and resources. Each instance of ClassLoader has an
associated parent class loader. When requested to find a class or resource, a
ClassLoader instance will delegate the search for the class or resource to its
parent class loader before attempting to find the class or resource itself.");
- There is no point in loading Guice class with different classloaders -
ScopesModule and all underlying classes (specifically TrueSingletonScopeImpl
and it's internal Holder class) should be loaded by separate classloaders for
that test. Currently Holder class is loaded by single classloader that is used
to load all other classes in test;
3. I think the implementation is broken - Holder class that is loaded by
CURRENT classloader will try to assign a static field of type Holder (that is
loaded by CURRENT classloader) with a loaded by system classloader type Holder.
I.e. you cannot assign a field of type (CURRENT classloader, Holder) a value of
type (system classloader, Holder). ClassCastException will be thrown if i'm
correct. See [2] for example. Apparently test mentioned above passes because it
uses system classloader itself;
4. Use of such singleton opens a great possibility for classloader leaks under
application servers (and OSGi too). JVM holds references to objects
(singletons), objects hold references to their classloaders and those
classloaders hold references to all classes that were loaded by them. Reload
your application a couple of times and you will get OutOfMemoryError: PermGen
space. And even if not - preventing unneeded objects from being GC'ed is bad.
See [3].
[1]: http://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html
[2]:
http://stackoverflow.com/questions/2371967/java-getting-class-cast-exception-where-both-classes-are-exactly-the-same
[3]:
http://frankkieviet.blogspot.ca/2006/10/classloader-leaks-dreaded-permgen-space.html
> Add a "true" singleton scope
> ----------------------------
>
> Key: ONAMI-95
> URL: https://issues.apache.org/jira/browse/ONAMI-95
> Project: Apache Onami
> Issue Type: New Feature
> Components: scopes
> Affects Versions: scopes-1.0.0
> Reporter: Jordan Zimmerman
> Priority: Minor
> Fix For: scopes-1.0.0
>
> Attachments: ONAMI-95.patch
>
>
> In Guice, Singeltons are unique per injector. In the JVM, manual singletons
> are unique per ClassLoader. Add a scope that creates a true Singleton that is
> unique per JVM regardless of injector or ClassLoader.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
