6:14 a.m.
Someone just mentioned that Max posted this question regarding AS7 startup:
Going over the AS7.1 server and how startup arguments has changed we
noticed besides the -logmodule not being needed the following two was
added:
-Djboss.modules.system.pkgs=org.jboss.byteman
-Djava.awt.headless=true
. . .
Any reason why byte man gets added and not the others ?
Yes. If you don't add this at startup then the module loader will hide
all the Byteman classes from all JBoss classloaders. This means that you
cannot decide to install a Byteman agent after AS startup in order to
debug/trace behaviour in a broken App Server. It just won't work (TM).
That's going to give our support team (not to mention our developers who
need to use Byteman for testing) a major headache.
Of course, we could always advise all AS7 users to configure this
setting in their own startup and leave it undefined by default but in
practice that's just going to be a FAIL. David Lloyd and I discussed
this some months back (July 11?) and having checked that adding this to
the startup had *negligible* overhead it was added as a default.
Also, I think the idea of adding this via a properties file sounds nice
at first but actually it is just splitting up the config by another
name. One file to rule them all . . .
regards,
Andrew Dinn
-----------
9:29 a.m.
New subject: Changed arguments…can we do better ? :P
Someone just mentioned that Max posted this question regarding AS7
startup:
> Going over the AS7.1 server and how startup arguments has changed we
> noticed besides the -logmodule not being needed the following two was
> added:
>
> -Djboss.modules.system.pkgs=org.jboss.byteman
> -Djava.awt.headless=true
> . . .
> Any reason why byte man gets added and not the others ?
Yes. If you don't add this at startup then the module loader will hide
all the Byteman classes from all JBoss classloaders. This means that you
cannot decide to install a Byteman agent after AS startup in order to
debug/trace behaviour in a broken App Server. It just won't work (TM).
That's going to give our support team (not to mention our developers who
need to use Byteman for testing) a major headache.
Yes, I know - same problem for those wanting to use jprofiler, yourkit, eclemma, and
others.
Of course, we could always advise all AS7 users to configure this
setting in their own startup and leave it undefined by default but in
practice that's just going to be a FAIL. David Lloyd and I discussed
this some months back (July 11?) and having checked that adding this to
the startup had *negligible* overhead it was added as a default.
Yes, I just suggest we make this list include more than just byteman and
take it *off* the commandline into a setting.
Also, I think the idea of adding this via a properties file sounds
nice
at first but actually it is just splitting up the config by another
name. One file to rule them all . . .
The problem is there are not one file to rule them all.
There is one per OS and tools that need to launch cannot use the .bat/.sh files
since no way to portably and reliably kill the process.
/max
http://about.me/maxandersen
9:40 a.m.
New subject: Changed arguments…can we do better ? :P
If byteman really needs to be added to the appserver for development
usage then at least make this internal to code itself checking the
property property and possibly some other property at runtime to
determine whether you should append the org.jboss.byteman leaving
jboss.modules.system.pkgs tools using this property for production usage.
The problem I have with the way this has been done up to now is that we
have this property in the script and then the same property set by a
tool integration script. Which one gets precedence is undefined - at
least I have yet to see the behavior specified.
On 01/02/2012 16:29, Max Rydahl Andersen wrote:
> Someone just mentioned that Max posted this question regarding
AS7 startup:
>
>> Going over the AS7.1 server and how startup arguments has changed we
>> noticed besides the -logmodule not being needed the following two was
>> added:
>>
>> -Djboss.modules.system.pkgs=org.jboss.byteman
>> -Djava.awt.headless=true
>> . . .
>> Any reason why byte man gets added and not the others ?
> Yes. If you don't add this at startup then the module loader will hide
> all the Byteman classes from all JBoss classloaders. This means that you
> cannot decide to install a Byteman agent after AS startup in order to
> debug/trace behaviour in a broken App Server. It just won't work (TM).
> That's going to give our support team (not to mention our developers who
> need to use Byteman for testing) a major headache.
Yes, I know - same problem for those wanting to use jprofiler, yourkit, eclemma, and
others.
> Of course, we could always advise all AS7 users to configure this
> setting in their own startup and leave it undefined by default but in
> practice that's just going to be a FAIL. David Lloyd and I discussed
> this some months back (July 11?) and having checked that adding this to
> the startup had *negligible* overhead it was added as a default.
Yes, I just suggest we make this list include more than just byteman and
take it *off* the commandline into a setting.
> Also, I think the idea of adding this via a properties file sounds nice
> at first but actually it is just splitting up the config by another
> name. One file to rule them all . . .
The problem is there are not one file to rule them all.
There is one per OS and tools that need to launch cannot use the .bat/.sh files
since no way to portably and reliably kill the process.
/max
http://about.me/maxandersen
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
10:06 a.m.
New subject: Changed arguments…can we do better ? :P
That's why I introduced the JBOSS_MODULE_SYSTEM_PKGS environment
variable. You set that and it will override the value used by teh
scripts. You can also set JAVA_OPTS env variable which overrides
everything.
On 2/1/12 9:40 AM, William Louth (JINSPIRED.COM) wrote:
If byteman really needs to be added to the appserver for development
usage then at least make this internal to code itself checking the
property property and possibly some other property at runtime to
determine whether you should append the org.jboss.byteman leaving
jboss.modules.system.pkgs tools using this property for production usage.
The problem I have with the way this has been done up to now is that we
have this property in the script and then the same property set by a
tool integration script. Which one gets precedence is undefined - at
least I have yet to see the behavior specified.
On 01/02/2012 16:29, Max Rydahl Andersen wrote:
>> Someone just mentioned that Max posted this question regarding AS7 startup:
>>
>>> Going over the AS7.1 server and how startup arguments has changed we
>>> noticed besides the -logmodule not being needed the following two was
>>> added:
>>>
>>> -Djboss.modules.system.pkgs=org.jboss.byteman
>>> -Djava.awt.headless=true
>>> . . .
>>> Any reason why byte man gets added and not the others ?
>> Yes. If you don't add this at startup then the module loader will hide
>> all the Byteman classes from all JBoss classloaders. This means that you
>> cannot decide to install a Byteman agent after AS startup in order to
>> debug/trace behaviour in a broken App Server. It just won't work (TM).
>> That's going to give our support team (not to mention our developers who
>> need to use Byteman for testing) a major headache.
> Yes, I know - same problem for those wanting to use jprofiler, yourkit, eclemma, and
others.
>
>> Of course, we could always advise all AS7 users to configure this
>> setting in their own startup and leave it undefined by default but in
>> practice that's just going to be a FAIL. David Lloyd and I discussed
>> this some months back (July 11?) and having checked that adding this to
>> the startup had *negligible* overhead it was added as a default.
> Yes, I just suggest we make this list include more than just byteman and
> take it *off* the commandline into a setting.
>
>> Also, I think the idea of adding this via a properties file sounds nice
>> at first but actually it is just splitting up the config by another
>> name. One file to rule them all . . .
> The problem is there are not one file to rule them all.
>
> There is one per OS and tools that need to launch cannot use the .bat/.sh files
> since no way to portably and reliably kill the process.
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
9:54 a.m.
New subject: Changed arguments…can we do better ? :P
On 02/01/2012 03:29 PM, Max Rydahl Andersen wrote:
> Yes. If you don't add this at startup then the module loader
will hide
> all the Byteman classes from all JBoss classloaders. This means that you
> cannot decide to install a Byteman agent after AS startup in order to
> debug/trace behaviour in a broken App Server. It just won't work (TM).
> That's going to give our support team (not to mention our developers who
> need to use Byteman for testing) a major headache.
Yes, I know - same problem for those wanting to use jprofiler, yourkit, eclemma, and
others.
No, it's not actually the same at all. Very far from it.
With jprofiler etc you know in advance that you want to profile your
program run or whatever. With byteman you don't know until something
goes wrong that you might need to load the Byteman agent, install some
trace rules and see what is going wrong. Most customers don't even know
that this is an option. However, our support team do and regularly use
it to talk customers through problems which arise in both sandbox and
live installs. Without this preliminary step the customer has to stop
and restart the AS in order to load the Byteman agent and Byteman rules
and this often means that the problem goes away -- i.e. important
support opportunity lost.
Anyway, I don't really need to convince you of this. Our support team
have already convinced *me* that this is a vital config option. If you
want to remove this on the grounds that it is just like all these other
cases I suggest you talk them first. Otherwise when the support problems
start piling up you are definitely not going to be Mr Popular.
Yes, I just suggest we make this list include more than just byteman
and
take it *off* the commandline into a setting.
It is a setting already. The fact that it is set using a shell script
doesn't really change that. If you want to argue for an alternative
control well, I'll leave that to our usability experts.
> Also, I think the idea of adding this via a properties file
sounds nice
> at first but actually it is just splitting up the config by another
> name. One file to rule them all . . .
The problem is there are not one file to rule them all.
There is one per OS and tools that need to launch cannot use the .bat/.sh files
since no way to portably and reliably kill the process.
There is one file to rule them all as far as the normal startup
mechanism is concerned. At least that's precisely how Jason described it
some months back -- unless, perhaps, he has changed his mind?
That may not be of any help to you if you are starting the AS by other
means but surely you can provide equivalent configuration options and an
API to configure them. In which case just be sure to include this in
your default config. It may not be so important to your usrs but I
suspect that is not the case.
regards,
Andrew Dinn
-----------
11:51 a.m.
New subject: Changed arguments…can we do better ? :P
Anyway, I don't really need to convince you of this. Our support team have already
convinced *me* that this is a vital config option. If you want to remove this on the
grounds that it is just like all these other cases I suggest you talk them first.
Otherwise when the support problems start piling up you are definitely not going to be Mr
Popular.
Andrew - i'm not saying byte man should not be supported out of box - i'm saying
there are other mechanisms that will fail too thus wishing to add them.
i.e. jvisualvm also seems to have problems if not explicitly listed and that is part of a
default hotspot jvm.
> Yes, I just suggest we make this list include more than just
byteman and
> take it *off* the commandline into a setting.
It is a setting already. The fact that it is set using a shell script doesn't really
change that. If you want to argue for an alternative control well, I'll leave that to
our usability experts.
i'm trying to reduce the need for having "special controls"
>> Also, I think the idea of adding this via a properties file
sounds nice
>> at first but actually it is just splitting up the config by another
>> name. One file to rule them all . . .
>
> The problem is there are not one file to rule them all.
>
> There is one per OS and tools that need to launch cannot use the .bat/.sh files
> since no way to portably and reliably kill the process.
There is one file to rule them all as far as the normal startup mechanism is concerned.
At least that's precisely how Jason described it some months back -- unless, perhaps,
he has changed his mind?
I don't see such one file.
I see standalone.conf.bat and standalone.conf and they are not honored unless you use
bash/bat to launch with.
That may not be of any help to you if you are starting the AS by
other means but surely you can provide equivalent configuration options and an API to
configure them. In which case just be sure to include this in your default config. It may
not be so important to your usrs but I suspect that is not the case.
of course I can provide equal options but the day more options gets added this needs to
updated too.
Which is why I ask to actually get one file and file format (which doesn't assume
existence of bash or windows command bat engine) that rule's most of them.
/max
http://about.me/maxandersen
10:13 a.m.
New subject: Changed arguments…can we do better ? :P
On 2/1/12 11:51 AM, Max Rydahl Andersen wrote:
> That may not be of any help to you if you are starting the AS by
> other means but surely you can provide equivalent configuration
> options and an API to configure them. In which case just be sure to
> include this in your default config. It may not be so important to
> your usrs but I suspect that is not the case.
of course I can provide equal options but the day more options gets
added this needs to updated too.
Which is why I ask to actually get one file and file format (which
doesn't assume existence of bash or windows command bat engine) that
rule's most of them.
I am very much in favor of a shared file for win and linux. I just don't
have any bandwidth to do it for 7.1.0 (1.1 maybe). Such a solution would
require that JBoss Tools parse the file since we have a chicken/egg
problem with VM launching on standalone, and we don't want to have a JVM
launching a JVM in a standalone setup (adds too much time to boot). It
might also require that we write a native launcher on windows.
Although keep in mind that none of those JVM parameters are absolutely
necessary. We got rid of logmodule, which was the only required one.
There is a couple of settings for bootstrap logging, but the system will
still work without it.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
4:52 a.m.
New subject: Changed arguments…can we do better ? :P
I am very much in favor of a shared file for win and linux. I just
don't have any bandwidth to do it for 7.1.0 (1.1 maybe). Such a solution would require
that JBoss Tools parse the file since we have a chicken/egg problem with VM launching on
standalone, and we don't want to have a JVM launching a JVM in a standalone setup
(adds too much time to boot). It might also require that we write a native launcher on
windows.
Although keep in mind that none of those JVM parameters are
absolutely necessary. We got rid of logmodule, which was the only required one. There is a
couple of settings for bootstrap logging, but the system will still work without it.
For me there are two different kind of arguments/parameters.
The one that are JVM specific/required at Java VM startup and those that are non-JVM
specific and can be read by the launcher it self.
It is the latter I'm suggesting to externalize.
OS specific/required at Java VM is currently for standalone.sh (as far as I can see?):
-d32
-client
-Xms64m
-Xmx512m
-XX:MaxPermSize=256m
-Djava.net.preferIPv4Stack=true
-Dsun.rmi.dgc.client.gcInterval=3600000*
-Dsun.rmi.dgc.server.gcInterval=3600000*
-Djava.awt.headless=true*
-jar
"/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/jboss-modules.jar"
*=might not be necessary to setup - depend if those are not getting activated during jboss
modules.
Arguments that I would think could be derived by the java launch instead of at command
line:
-Dorg.jboss.resolver.warning=true
-Djboss.modules.system.pkgs=org.jboss.byteman
"-Dorg.jboss.boot.log.file=/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/log/boot.log"
"-Dlogging.configuration=file:/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties"
-mp "/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/modules"
-jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone
-Djboss.home.dir="/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT"
Most of these could just be calculated based on jboss.home.dir as a nice default.
Leaving us with:
-Dorg.jboss.resolver.warning=true
-Djboss.modules.system.pkgs=org.jboss.byteman
-jaxpmodule javax.xml.jaxp-provider
Which could be read in via a properties file or even defaulted?
But Jason, I'm reading your mail as you even want to go to the length of having the vm
arguments externalized?
/max
http://about.me/maxandersen
11:27 a.m.
New subject: Changed arguments…can we do better ? :P
This implies then two separate files for setting these things, given
that we want setting them to be externalized from
standalone.sh/domain.sh itself.
On 2/3/12 4:52 AM, Max Rydahl Andersen wrote:
> I am very much in favor of a shared file for win and linux. I
just don't have any bandwidth to do it for 7.1.0 (1.1 maybe). Such a solution would
require that JBoss Tools parse the file since we have a chicken/egg problem with VM
launching on standalone, and we don't want to have a JVM launching a JVM in a
standalone setup (adds too much time to boot). It might also require that we write a
native launcher on windows.
>
> Although keep in mind that none of those JVM parameters are absolutely necessary. We
got rid of logmodule, which was the only required one. There is a couple of settings for
bootstrap logging, but the system will still work without it.
For me there are two different kind of arguments/parameters.
The one that are JVM specific/required at Java VM startup and those that are non-JVM
specific and can be read by the launcher it self.
It is the latter I'm suggesting to externalize.
OS specific/required at Java VM is currently for standalone.sh (as far as I can see?):
-d32
-client
-Xms64m
-Xmx512m
-XX:MaxPermSize=256m
-Djava.net.preferIPv4Stack=true
-Dsun.rmi.dgc.client.gcInterval=3600000*
-Dsun.rmi.dgc.server.gcInterval=3600000*
-Djava.awt.headless=true*
-jar
"/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/jboss-modules.jar"
*=might not be necessary to setup - depend if those are not getting activated during
jboss modules.
Arguments that I would think could be derived by the java launch instead of at command
line:
-Dorg.jboss.resolver.warning=true
-Djboss.modules.system.pkgs=org.jboss.byteman
"-Dorg.jboss.boot.log.file=/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/log/boot.log"
"-Dlogging.configuration=file:/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties"
-mp "/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/modules"
-jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone
-Djboss.home.dir="/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT"
Most of these could just be calculated based on jboss.home.dir as a nice default.
Leaving us with:
-Dorg.jboss.resolver.warning=true
-Djboss.modules.system.pkgs=org.jboss.byteman
-jaxpmodule javax.xml.jaxp-provider
Which could be read in via a properties file or even defaulted?
But Jason, I'm reading your mail as you even want to go to the length of having the
vm arguments externalized?
/max
http://about.me/maxandersen
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
6:56 a.m.
New subject: Changed arguments…can we do better ? :P
Note, things could be much much simplified if all the properties that are rooted in
"JBOSS_HOME" could be defaulted and calculated by the java process launching
as7.
Then only in the "exceptional" case would you need to mess with these.
/max
This implies then two separate files for setting these things, given
that we want setting them to be externalized from
standalone.sh/domain.sh itself.
On 2/3/12 4:52 AM, Max Rydahl Andersen wrote:
>> I am very much in favor of a shared file for win and linux. I just don't have
any bandwidth to do it for 7.1.0 (1.1 maybe). Such a solution would require that JBoss
Tools parse the file since we have a chicken/egg problem with VM launching on standalone,
and we don't want to have a JVM launching a JVM in a standalone setup (adds too much
time to boot). It might also require that we write a native launcher on windows.
>>
>
>> Although keep in mind that none of those JVM parameters are absolutely necessary.
We got rid of logmodule, which was the only required one. There is a couple of settings
for bootstrap logging, but the system will still work without it.
>
>
> For me there are two different kind of arguments/parameters.
>
> The one that are JVM specific/required at Java VM startup and those that are non-JVM
specific and can be read by the launcher it self.
>
> It is the latter I'm suggesting to externalize.
>
> OS specific/required at Java VM is currently for standalone.sh (as far as I can
see?):
>
> -d32
> -client
> -Xms64m
> -Xmx512m
> -XX:MaxPermSize=256m
> -Djava.net.preferIPv4Stack=true
> -Dsun.rmi.dgc.client.gcInterval=3600000*
> -Dsun.rmi.dgc.server.gcInterval=3600000*
> -Djava.awt.headless=true*
> -jar
"/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/jboss-modules.jar"
>
> *=might not be necessary to setup - depend if those are not getting activated during
jboss modules.
>
> Arguments that I would think could be derived by the java launch instead of at
command line:
>
> -Dorg.jboss.resolver.warning=true
> -Djboss.modules.system.pkgs=org.jboss.byteman
>
"-Dorg.jboss.boot.log.file=/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/log/boot.log"
>
"-Dlogging.configuration=file:/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/standalone/configuration/logging.properties"
> -mp "/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT/modules"
> -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone
> -Djboss.home.dir="/Users/max/jboss-runtimes/jboss-as-7.1.0.Final-SNAPSHOT"
>
> Most of these could just be calculated based on jboss.home.dir as a nice default.
>
> Leaving us with:
>
> -Dorg.jboss.resolver.warning=true
> -Djboss.modules.system.pkgs=org.jboss.byteman
> -jaxpmodule javax.xml.jaxp-provider
>
> Which could be read in via a properties file or even defaulted?
>
> But Jason, I'm reading your mail as you even want to go to the length of having
the vm arguments externalized?
>
>
> /max
> http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
/max
http://about.me/maxandersen
1:18 p.m.
New subject: Changed arguments…can we do better ? :P
On 02/01/2012 09:54 AM, Andrew Dinn wrote:
On 02/01/2012 03:29 PM, Max Rydahl Andersen wrote:
>> Yes. If you don't add this at startup then the module loader will hide
>> all the Byteman classes from all JBoss classloaders. This means that you
>> cannot decide to install a Byteman agent after AS startup in order to
>> debug/trace behaviour in a broken App Server. It just won't work (TM).
>> That's going to give our support team (not to mention our developers who
>> need to use Byteman for testing) a major headache.
>
> Yes, I know - same problem for those wanting to use jprofiler, yourkit, eclemma, and
others.
No, it's not actually the same at all. Very far from it.
With jprofiler etc you know in advance that you want to profile your
program run or whatever...[etc]
Profiler vendors have made a general move towards no longer needing this
setting (JProfiler in particular does not require it anymore).
--
- DML
3:17 p.m.
New subject: Changed arguments…can we do better ? :P
Did you consider having byteman instrument the Class Loaders in the target vm, to always
delegate to the system class loader if the class being loading starts with
"org.byteman" ?
I am pretty sure this is how JProfiler gets around the need for this setting.
Stuart
On 01/02/2012, at 11:14 PM, Andrew Dinn wrote:
Someone just mentioned that Max posted this question regarding AS7
startup:
> Going over the AS7.1 server and how startup arguments has changed we
> noticed besides the -logmodule not being needed the following two was
> added:
>
> -Djboss.modules.system.pkgs=org.jboss.byteman
> -Djava.awt.headless=true
> . . .
> Any reason why byte man gets added and not the others ?
Yes. If you don't add this at startup then the module loader will hide
all the Byteman classes from all JBoss classloaders. This means that you
cannot decide to install a Byteman agent after AS startup in order to
debug/trace behaviour in a broken App Server. It just won't work (TM).
That's going to give our support team (not to mention our developers who
need to use Byteman for testing) a major headache.
Of course, we could always advise all AS7 users to configure this
setting in their own startup and leave it undefined by default but in
practice that's just going to be a FAIL. David Lloyd and I discussed
this some months back (July 11?) and having checked that adding this to
the startup had *negligible* overhead it was added as a default.
Also, I think the idea of adding this via a properties file sounds nice
at first but actually it is just splitting up the config by another
name. One file to rule them all . . .
regards,
Andrew Dinn
-----------
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
3:05 a.m.
New subject: Changed arguments…can we do better ? :P
Hi Stuart,
On 02/01/2012 09:17 PM, Stuart Douglas wrote:
Did you consider having byteman instrument the Class Loaders in the
target vm, to always delegate to the system class loader if the class
being loading starts with "org.byteman" ?
I am pretty sure this is how JProfiler gets around the need for this
setting.
I did consider this but I decided against it for two reasons:
1) the existing mechanism in JBoss modules already does the basic job of
making Byteman classes available everywhere. So, duplicating it seemed
inefficient both at devtime and at runtime.
2) doing the job properly will also involve adding exemptions for other,
non-Byteman classes referenced at the point of injection and I am
considering a better mechanism to make this work
To explain the latter, imagine that a rule injected into a JBossTS class
needs access EJB types/methods. However, Byteman currently has to
type-check and link the rule using the loader of the target class. So,
you are snookered if the JTS module does not import the EJB classes.
I think I can get round this by adding i) module import statements to
Byteman rule scripts ii) a plugin to the Byteman agent which resolves
module imports and hands Byteman a multi-module loader for
type-check/load, allowing rules to be linked against the union of the
target module and the imported modules.
Of course the plugin and the import syntax would have to be module
loader-specific.So, you would need an OSGI plugin, a JBoss Modules
plugin, a Jigsaw plugin etc. But it should be easy to define a generic
API for delegation of loader issues. So, watch this space.
regards,
Andrew Dinn
-----------
4703
days inactive
4709
days old
12 comments
7 participants
participants (7)
-
Andrew Dinn -
Brian Stansberry -
David M. Lloyd -
Jason T. Greene -
Max Rydahl Andersen -
Stuart Douglas -
William Louth (JINSPIRED.COM)