[Design of JBoss Profiler] - Re: dpConsole.jar
by clebert.suconic@jboss.com
Thanks for pointing this out.
I will change this to
Possible options include:
start=<prefix name>
include=<prefix name>
ignore=<prefix name>
socket=<server|IP>:
This option is used to be used in conjunction with profilerConsole.jar. If
you use that option you have to include dpConsole.jar on the class-path of your
application server.
uniqueNames=true
Useful for running test cases
wakeupOnStartup=true
Start the profiler always after the JVM start
memory=true|false (default=true)
Disable the memory profiler.
If this options is disable the profiler wouldn't capture any allocations events during data gathering
In fact socket was supposed to be used with profilerConsole.jar, but I'm not sure if that feature is still working on recent JVMs. I have used a couple of hacks (events from JVMPI) to connect to a prompt based console.
And that was really error prone. I had a lot of work to determine the correct sequence of events, and if anything goes in a different order I would get a GPF/core dumped.
I would stick with JMX-Console or kill-3 if you want to run the profiler outside of a JBoss server.
As for the wakupOnStartup that will start capturing at the first minute the JVM is activated. That means the startup will be also be profiled what will make the activation much slower.
Thanks again,
Clebert
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975190#3975190
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975190
18 years
[Design of POJO Server] - Re: VFS isLeaf() vs isDirectory()/isFile()
by scott.stark@jboss.org
"adrian(a)jboss.org" wrote : Rather than arguing about and disagreeing, I'd suggest we write some
| tests for the use cases and implement it.
|
| It sounds like both approaches would work and have different use cases.
|
| 1) Being able to attribute a VirtualFile with deployment attributes
| and have the structure deployer check the attribute(s).
|
| 2) Being able define your own structure by predetermined
| deployment contexts.
|
| I still think (2) is simpler.
| And more generic since it doesn't require the construction
| of metadata files when you already have the metadata object in memory
| i.e. constructed on the fly.
|
| It is also unclear to me how the attributes in (1) are
| persisted in general? i.e. going beyond the case where
| the ide can remember these in some ide config file.
|
I agree that we need a real demonstration of how the proposed apis are used as in the end that is the determining factor. I don't see that (1) precludes (2). Its just more information into a structural analysis pass, which is still something a naive user of the deployment layer (like the jsr88/profile service) need to be able to translate deployment urls into deployable objects.
In terms of allowing attributes on files, the api will have to support adding them, and how/if they are stored an impl detail of the VFS.
"adrian(a)jboss.org" wrote :
| Removing the isArchive() from the VFS layer, requires
| the changes I suggested.
|
| However, just ignoring the unrecognised structure means
| it will not appear in the summary IncompleteDeployments
| unless that processing is extended to include them somehow?
|
I don't see why having the unkown virtual file show up in the IncompleteDeployments is a needed element. In this case we are talking about multiple deployments, not an uknown element inside a top level deployment. How this is handled is purely a VFScanner detail as far as I can see.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975146#3975146
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975146
18 years
[Design of POJO Server] - Re: VFS isLeaf() vs isDirectory()/isFile()
by adrian@jboss.org
Rather than arguing about and disagreeing, I'd suggest we write some
tests for the use cases and implement it.
It sounds like both approaches would work and have different use cases.
1) Being able to attribute a VirtualFile with deployment attributes
and have the structure deployer check the attribute(s).
2) Being able define your own structure by predetermined
deployment contexts.
I still think (2) is simpler.
And more generic since it doesn't require the construction
of metadata files when you already have the metadata object in memory
i.e. constructed on the fly.
It is also unclear to me how the attributes in (1) are
persisted in general? i.e. going beyond the case where
the ide can remember these in some ide config file.
Removing the isArchive() from the VFS layer, requires
the changes I suggested.
However, just ignoring the unrecognised structure means
it will not appear in the summary IncompleteDeployments
unless that processing is extended to include them somehow?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975143#3975143
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975143
18 years
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Application Server Integration Tests
by adrian@jboss.org
I'd also recommend that most tests bootstrap
a default configuration for the server.
The default Microcontainer delegate looks for an xml file
based on the test class name.
e.g.
org.jboss.test.jms.test.TestSomething.class
uses
org.jboss.test.jms.test.TestSomething.xml
Rather than writing one for each test, there should be
a mechanism to provide a default JMS config
(while still allowing individual tests to use different configurations).
e.g. maybe?
| public class JMSTestDelegate extends MicrocontainerTestDelegate
| {
| static JMSAdmin admin;
|
| ...
|
| protected void setUp() throws Execption
| {
| super.setUp();
|
| // No test specific configuration?
| if (getBean("ConnectionFactory") == null)
| {
| String name = admin.getDefaultConfigName();
| URL url = clazz.getResource(name); // the config will be in the classpath
| deploy(url);
| }
| }
| }
|
Or perhaps:
| protected void setUp() throws Execption
| {
| super.setUp();
|
|
| String name = admin.getConfig(clazz.getName());
| // No test specific configuration?
| if (name == null)
| name = admin.getDefaultConfigName();
| URL url = clazz.getResource(name); // the config will be in the classpath
| deploy(url);
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975123#3975123
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975123
18 years
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Application Server Integration Tests
by adrian@jboss.org
"rachmatowicz(a)jboss.com" wrote :
| All in all, I am in favour of using a simpler approach, based on the simplified scheme described above, where test cases
| continue to sublass from JBossTestCase
|
No the point is to write unit tests. You are not testing JBoss integration!
The tests should be written against the microcontainer:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76657
I said this should be based on a JMSAdmin like the JORAM tests.
Not that it should use the JORAM admin implementation.
Once we have our own admin implementation, the JORAM tests
can use that as a delegate.
The general outline should be something like:
// A base class
| public abstract class AbstractJMSTest extends MicrocontainerTest
| {
| /**
| * Get the delegate
| *
| * @return the delegate
| */
| protected JMSTestDelegate getJMSDelegate()
| {
| return (JMSTestDelegate) getDelegate();
| }
|
| // helper methods that delegate/admin
| }
|
// The delegate that encapsulates the admin/implementation
| public class JMSTestDelegate extends MicrocontainerTestDelegate
| {
| static JMSAdmin admin;
|
| static
| {
| // Possible rules
| // 1) Look at system property
| // 2) Is JBoss Messaging in the classpath
| // 3) Is JBossMQ in the classpath
| admin = initialiseAdmin();
| }
| }
|
// Real tests just use the infrastructure
| public class RealTest extends AbstractJMSTest
| {
| public void testSomething()
| {
| ConnectionFactory cf = super.getConnectionFactory();
| Queue queue = super.createQueue("something");
| ...
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975119#3975119
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975119
18 years