Here's whats in the standard error....

*** JFluid warning: class <package>.<classname> that should be
instrumented is not loaded by target VM
*** Requested classloader: AdaptiveClassLoader(  ), index = 1
*** Please report this problem to Mikhail.Dmitriev@sun.com

Ok, I believe I have a simpler test case to get this error.

1.  take the attached zip file, and expand it to your C: drive

2. Go to C:\JFLUID_tomcat-3.2.1\bin and edit the file  
jfluid_noattach_on_startup.bat    and change the NETBEANS_MODULES_DIR 
variable to point to where it is on your machine

3. If set correctly, you can double click on this bat file, and a new
window will open up while tomcat is starting up (on port 
8080.... make sure you don't have something else already running there)

4.  In a browser on the same machine hit this URL: 
http://localhost:8080/examples/servlet/RequestInfoExample

5. Now attach to it via Netbeans 4.0b2 profiler:
            Working Dir: C:\JFLUID_tomcat-3.2.1\bin
            Analyze Memory Usage, record object creation
            Use ctrl-break method

6.  You will get error message:         Target VM cannot load class to
instrument requestMap.Servlet1

And you will see this in the console of the VM:

JFluid: current dir is C:\JFLUID_tomcat-3.2.1\bin

JFluid: target app manager starting on port 5140
*** JFluid warning: class requestMap.Servlet1 that should be
instrumented is not loaded by target VM
*** Requested classloader: AdaptiveClassLoader(  ), index = 1
*** Please report this problem to Mikhail.Dmitriev@sun.com


Let me know if you are able to reproduce this on your machine.

Also, if you flip steps 5 and 6 so that you attach first and then hit
the URL, I've gotten the EXCEPTION_ACCESS_VIOLATION error for 
doExtendConstantPool, \src\share\vm\runtime\os.cpp, 760 several times
(which I've entered as a seperate issue...... # 51229 )

-Jon

----- Original Message ----- 
From: <Mikhail.Dmitriev@sun.com>
To: <jchristi@netbeans.org>
Sent: Friday, November 05, 2004 6:14 PM
Subject: Re: [Issue 51222] New - Getting message: "Target VM cannot
load class to instrument <classname>" when I have multiple 
webapps in Tomcat


> Hi Jon,
>
> Well, what a flood of bug reports... looks like we could have done a
better
> job this time :-) Anyway, I am interested in this particular one:
some of the
> changes that we've made were supposed to address exactly this sort
> of things. I therefore wonder why you are getting these messages. Is
> it possible for you to share your application code with us, or
provide some
> idea about its "architecture", or get "instrumented" JFluid code from us
> that will emit additional diagnostics information? The latter may be
> sort of laborious, though - it's not easy to indentify the exact
reason for
> this problem, thus it may require multiple code/results exchange
iterations...
>
> Thanks,
>
> Misha
>
> ----- Original Message -----
> From: issues@www.netbeans.org
> Date: Friday, November 5, 2004 3:44 pm
> Subject: [Issue 51222] New - Getting message: "Target VM cannot load
class to instrument <classname>" when I have multiple webapps 
> in Tomcat
>
>> http://www.netbeans.org/issues/show_bug.cgi?id=51222
>>
>>                  Summary: Getting message: "Target VM cannot load
>> class to
>>                           instrument <classname>" when I have
>> multiple webapps in
>>                           Tomcat
>>                Component: profiler
>>                  Version: 4.1
>>                 Platform: PC
>>                      URL:
>>               OS/Version: Windows 2000
>>                   Status: NEW
>>        Status Whiteboard:
>>                 Keywords:
>>               Resolution:
>>               Issue type: DEFECT
>>                 Priority: P3
>>             Subcomponent: code
>>               AssignedTo: issues@profiler.netbeans.org
>>               ReportedBy: jchristi@netbeans.org
>>
>>
>> I believe each webapp has its own classloader?
>> This is with Tomcat 3.2.1.
>>
>> I have 5 different webapps deployed (ROOT, admin
>> and then 3 webapps specific to the product I develop).
>>
>> With M3 release, I seem to be getting these error
>> messages for at least two of the three
>> webapps/classloaders.  (I dont believe the ROOT or
>> admin ones are being invoked during my testing, so
>> that may be why I dont see it for those two as well)
>>
>> -------------------------------------------------------------------
>> --
>> To unsubscribe, e-mail: issues-unsubscribe@profiler.netbeans.org
>> For additional commands, e-mail: issues-help@profiler.netbeans.org
>>
>>
> 

The same problem with the Resin 3.0.8 class loaders:

Resin-3.0.8 (built Tue, 08 Jun 2004 02:25:40 PDT)
Copyright(c) 1998-2004 Caucho Technology.  All rights reserved.
 

  #002333 -- 5 Resin-EE servers licensed to SC Telemobil SA
 
Starting Resin on Mon, 08 Nov 2004 16:40:23 +0200 (EET)
 
[16:40:25.928] Loaded Socket JNI library.
[16:40:25.944] http listening to *:80
[16:40:25.944] ServletServer[] starting
[16:40:25.959] hmux listening to localhost:6802
[16:40:26.365] Host[] starting
[16:40:26.834] In-place class redefinition (HotSwap) is available.
[16:40:39.365] Application[http://localhost:80/orca] starting
[16:40:42.256] UpdateServlet: init
[16:40:42.334] UpdateServletCredit: init
[16:40:43.428] FlowInstanceCache: init
[16:40:43.615] Application[http://localhost:80] starting
JFluid: target app manager starting on port 5140
*** JFluid warning: class _jsp._login__jsp that should be 
instrumented is not loaded by target VM
*** Requested classloader: DynamicClassLoader[SimpleLoader
[/C:/resin/webapps/orca/WEB-INF/work]], index = 18
*** Please report this problem to Mikhail.Dmitriev@sun.com
*** JFluid warning: class _jsp._header_0orca__jsp that should be 
instrumented is not loaded by target VM
*** Requested classloader: DynamicClassLoader[SimpleLoader
[/C:/resin/webapps/orca/WEB-INF/work]], index = 18
*** Please report this problem to Mikhail.Dmitriev@sun.com

Ok, the root cause appears to be the following: JFluid used just 
ClassLoader.toString() method to distinguish between classloader 
instances. If your classloader's class CL overrides toString() such 
that the same value is returned for two or more instances of CL, 
JFluid gets confused. I've fixed that by replacing 'cl.toString()' 
with 'cl.toString() + cl.hashCode()' as a unique classloader 
identifier.

We may be able to provide interested users with the fixed code for 
testing/evaluation - let us know if you are interested. And thanks 
for providing a test case Jon!

It would be perfect if you can provide a URL for the fix.

This fix will be available in M3 v2

Verification of old issues.

Closing old issues.

Reverting to the original Target Milestone value changed by mistake. Sorry for
inconvenience.