[
https://issues.apache.org/jira/browse/RIVER-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14255103#comment-14255103
]
Peter Firmstone commented on RIVER-444:
---------------------------------------
One issue with ProfilingSecurityManager is it depends on private state
of jvm classes and it uses reflection to access it. This has always
bothered me, but I never did anything about it.
We can create a new DebugSecurityManager that extends
CombinerSecurityManager that performs the same task using only public
api, this would fit into the runtime tools component.
The reason for the existance of this SecurityManager, is not all
ProtectionDomain's in the AccessControlContext consult the installed
policy during a permission check. Some Protec tionDomain's are given
their permissions during construction, by consulting the policy at the
time of their instantiation, however they never again consult the policy
(depending on the ProtectionDomain constructor used), so using
DebugDynamicPolicyProvider, we don't know the execution context when
they requrie these permissions.
Something else to be aware of, is lazy class initialization may alter
when a ProtectionDomain appears in the AccessControlContext, different
jvm versions, subtle library or application code revisions or even state
may determine when classes are initialized by the jvm.
For example, there are occassions when I've had to change policy files
in the test suite between Java 1.4, 5 and 6 due to changes in the
execution context.
Cheers,
Peter.
> Extract classdep and other tools to a separate project and upgrade to JDK1.8
> ----------------------------------------------------------------------------
>
> Key: RIVER-444
> URL: https://issues.apache.org/jira/browse/RIVER-444
> Project: River
> Issue Type: Improvement
> Components: build
> Affects Versions: River_2.2.2
> Reporter: Greg Trasuk
>
> Currently the build system in the 2.2 branch includes the classdep tool,
> which is built in an early phase of the build. It uses ASM3.2, which fails
> under JDK8.
> I proposed on the mailing list to remove the tools package to a separate
> project as follows:
> How about if I pull out the ‘tools’ package to a separate Maven project and
> integrate the changes that Peter did on qa_refactor? Then both the 2.2
> branch and qa_refactor can use the same tools.
> Process would be as follows:
> - Create a project in Apache git repo for ‘river-tools’
> - Create a Maven project (I’ll have a look at the modularization that Dennis
> did, I suspect this is already done) in that repository
> - Integrate Peter’s updates from qa-refactor (which update to use asm-5 in
> classdep)
> - Do a release on river-tools, so that tools.jar can go into Maven Central
> - Remove tools packages from 2.2. branch. Modify build to get tools.jar from
> Central rather than building it.
> - I can update qa_refactor at the same time.
> - Roll a release of the 2.2. branch.
> Which will leave a 2.2. release that builds under JDK1.8, qa_refactor that
> uses the same tool, and one less piece of build system confusion to put off
> new committers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
