September 2006 - jboss-dev-forums

[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

17 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-565 - Race condition on QueueManagementTest

by clebert.suconic＠jboss.com

I have talked to Tim... We will add a sleep in between the receive and the getMessageCount. This will give Deliver enough time to feed another message into deliveries.size(). Clebert View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975174#3975174 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975174

17 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: 3.2 alpha 1 release status

by falazar

I believe I found the problem now, after digging for yet another day. It appears we were using hte API to try and put the swimlane actors on a task before the task was created... we are juggling it around now, and should have it back to working soon. James View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975154#3975154 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975154

17 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS isLeaf() vs isDirectory()/isFile()

by scott.stark＠jboss.org

(1) can also be used as input into the handling of the failure to recognize a file. If the user marked a file as a deployable node, failure to recognize the structure is equivalent to the current "no deployers for ...' error of jboss4. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975149#3975149 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975149

17 years, 11 months

1
0
0 / 0

[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

17 years, 11 months

1
0
0 / 0

[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

17 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Trunk out of bounds

by mark.little＠jboss.com

We're merging the rearchitecture branch into trunk this weekend. Don't check anything in there until further notice. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975139#3975139 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975139

17 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: VFS isLeaf() vs isDirectory()/isFile()

by scott.stark＠jboss.org

Identityfing a vfs path as a context for setting up the war structure is far from a predetermined structure. I still need something to translate from a URI to a DeploymentContext (the attributed VirtualFile). The VFScanner does need the structural deployers to do this, and the deployment centric isArchive should be dropped from the VFS to clear up the current confusion on where the functional boundaries are. In terms of the else clause, the scanner should just be reporting an error that the deployment location contains content that cannot be recognized. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975137#3975137 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975137

17 years, 11 months

1
0
0 / 0

[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

17 years, 11 months

1
0
0 / 0

[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

17 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2006