[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-dev] latest NPN and start.jar
|
Hi,
On Fri, Sep 13, 2013 at 2:57 PM, Eirik Bjørsnøs <eirbjo@xxxxxxxxx> wrote:
>
> Simone,
>
> A couple of points:
>
> 1) I don't see how replacing SSL classes with -javaagent creates more or
> less problems than replacing them with -Xbootclasspath..? In this regard, I
> see -Xbootclasspath as just some other class replacing agent that is
> guaranteed to always run before other agents.
Sure, and exactly my point.
java -javaagent:newrelic.jar -Xbootclasspath:npn-boot.jar will work.
java -javaagent:newrelic.jar -javaagent:npn-agent.jar may not work.
My approach has been to take the smallest risk.
> 2) Using an agent, we could check the incoming class byte arrays agains hash
> signatures of well known byte arrays of the classes we are replacing. When a
> signature is unknown, we can bail out with a System.err.println letting the
> user know that he's either A) running a "too new" JVM, or B) he's running
> other agents before the NPN one. This way we can be one hundred percent sure
> we're not redefining classes when we really shouldn't. The println could
> even say "you screwd up, please read the documentation at this URL:.."
Sure, but more metadata to store somewhere.
And I am not sure the hash approach works in all JVMs.
The OpenJDK hash may be different from the Oracle JDK one (I have seen
that already - the javac compilers are different).
Look, I am not against the agent, really. I think it has a lot of
value in providing better failure messages.
But it can only be an alternative solution to the boot jar in the
cases where the agent would not work for the reasons we discussed.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.
