September 2007 - jboss-dev-forums

[Design of JBoss Profiler] - Re:How to capture the data from the JVMTI

by singhsachin13

Hi Clebert Suconic, Thanks for the reply. My application is compiled in the JDK 1.6 and from your reply I came to know that JBoss Profiler will not support JVMPI running with JDK 1.6 My problem is that I want to get the method level details i.e time consumed by each method of my application under load. So How can I profile JBoss under JDK 1.6 to get this details. Thanks and Regards Sachin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087203#4087203 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087203

18 years, 6 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - run: IdleRemover notifying pools, interval: 450000

by pkalpana2k

I'm using JBoss Server, Oracle 10G and JDK1.5. I'm getting Error this error for every 7.5 mins. 2007-09-21 05:33:29,768 DEBUG [org.jboss.resource.connectionmanager.IdleRemover] run: IdleRemover notifying pools, interval: 450000 What does it mean? Then sometimes, i'm getting below error. 2007-09-21 12:07:22,034 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.parentTraceEnabled=true 2007-09-21 12:07:22,035 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.nestedTraceEnabled=false 2007-09-21 12:07:22,035 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.detectDuplicateNesting=true why it is coming like this? But my application runs without any issues. Can anyone guide me? Thanks in Advance. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087201#4087201 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087201

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by adrian＠jboss.org

"alesj" wrote : | "adrian(a)jboss.org" wrote : | | All that was required was to extend the dispatch api to have the name of the target | | and add that to the kernel bus api. | | | | But if I do this, I think we need to add all three ways of dispatching something to context - invoke, get and set - into the KernelBus. | Correct. If that's not correct then the dispatch context is wrong for the same reason. anonymous wrote : | How to push this change then back to AS trunk? | Waiting for beta5, cr1? | That depends upon whether Scott needs it for jboss5-beta3. If he does, then we'll need to apply your changes to the 2.0 branch and create a 2.0-beta5 release of the MC. http://anonsvn.jboss.org/repos/jbossas/projects/microcontainer/branches/2_0/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087199#4087199 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087199

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by adrian＠jboss.org

"wolfc" wrote : I don't like all the merge logic in the binding classes. Can't we have a separate class hierarchy for that? | | Then it would become: new MergedJBossMetaData(ejbJarMetaData, jbossMetaData); | And standardjboss.xml: new MergedJBossMetaData(standardJbossMetaData, new MergedJBossMetaData(ejbJarMetaData, jbossMetaData)); | | (it still needs some polishing) | | And no more the need to ask for merged beans or stuff. That's ok as long as you can get back to the original metadata. If you can't ask for the original ejb-jar and jboss metadata and marshal them back to the original xml then its no good. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087193#4087193 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087193

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : A bigger problem is lack of support for dom Elements as is needed for the standardjboss.xml proxy-factory-config elements. The content of these depends on the invoker type: | This works in the MC stuff, so its obviously not defined correctly in the annotations for the ejb stuff. It shouldn't be trying to construct a javabean for an array of xml Elements. It shouldn't even be going through the base jbossxb bean code. There are seperate interceptors/handlers that understand xml wildcards (and their collections) in the builder project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087190#4087190 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087190

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Unifying metadata

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | The root org.jboss.ejb.metadata.jboss.JBossMetaData would have to add a mergeOverridenMetaData method that took the existing override and merged the second override into it. | Why do you need to merge standardjboss.xml? standardjboss.xml should just be parsed once into a JBossMetaData and then it should just be a case of delegating. If you merge standardjboss.xml into the JBossMetaData then you'll loose the reversability. Let's not make the same mistakes as the old metadata did! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087188#4087188 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087188

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by alesj

"adrian(a)jboss.org" wrote : | NOTE: Even the joinpoint stuff in the existing KernelBus is irrelevant. | It is legacy from when I was experimenting with AOP/POJO and JMX implementing the | Joinpoint api. The DispatchContext replaced this. If you posted this INFO before, I wouldn't go into trouble of writing that rubbish new joinpoint. :-) "adrian(a)jboss.org" wrote : | All that was required was to extend the dispatch api to have the name of the target | and add that to the kernel bus api. | But if I do this, I think we need to add all three ways of dispatching something to context - invoke, get and set - into the KernelBus. How to push this change then back to AS trunk? Waiting for beta5, cr1? ps: we could have changed KernelBus long time ago ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087187#4087187 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087187

18 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: ManagedOperation aspects for the ProfileService.Manageme

by adrian＠jboss.org

"alesj" wrote : I've added the following code to KernelBus: Why did you go to all this extra work of creating joinpoints and all the other rubbish? All that was required was to extend the dispatch api to have the name of the target and add that to the kernel bus api. e.g. | /** | * Invoke method / operation | * | * @param name the name of the target | * @param methodName method name | * @param parameters parameter values | * @param signature method's parameter types / signatures | * @return invocation's return object | * @throws Throwable for any error | */ | Object invoke(Object name, String methodName, Object parameters[], String[] signature) throws Throwable; | A bus is just the same api as a single context with the target found by looking up the name in a registry. The name being the extra parameter. The rest of the api you've created, is just useless object construction and irrelevant implement details. NOTE: Even the joinpoint stuff in the existing KernelBus is irrelevant. It is legacy from when I was experimenting with AOP/POJO and JMX implementing the Joinpoint api. The DispatchContext replaced this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087183#4087183 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087183

18 years, 6 months

1
0
0 / 0

[Design of JBoss Build System] - Trying to release jboss-ejb3-cache

by wolfc

I'm having a release problem with ejb3-cache: [INFO] Working directory: /home/carlo/work/ejb3/ejb3-cache | [INFO] Tagging release with the label jboss-ejb3-cache-0.11.0... | [INFO] Executing: svn --non-interactive copy --file /tmp/maven-scm-1736308454.commit . https://svn.jboss.org/repos/jbossas/projects/ejb3/tags/jboss-ejb3-cache-0... | [INFO] Working directory: /home/carlo/work/ejb3/ejb3-cache | [INFO] ------------------------------------------------------------------------ | [ERROR] BUILD FAILURE | [INFO] ------------------------------------------------------------------------ | [INFO] Unable to tag SCM | Provider message: | The svn tag command failed. | Command output: | svn: Commit failed (details follow): | svn: Directory '/home/carlo/work/ejb3/ejb3-cache/src/test/java/org/jboss/ejb3/test/xpc' is missing | | [INFO] ------------------------------------------------------------------------ | [INFO] For more information, run Maven with the -e switch | [INFO] ------------------------------------------------------------------------ | [INFO] Total time: 25 seconds | [INFO] Finished at: Fri Sep 21 12:42:26 CEST 2007 | [INFO] Final Memory: 5M/10M | [INFO] ------------------------------------------------------------------------ It appears to be a svn problem. The xpc directory is marked as deleted in entries (and thus not on the filesystem). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087164#4087164 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087164

18 years, 6 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: TransactionLocal: values, locks and headaches

by jhalliday

Just one more headache: the current TransactionLocal.get() implementation in the app server actually tries to write the value in certain cases. If it?s called after transaction resolution, that storeValue now throws an IllegalStateException, causing get() to blow up. The options seem to be: change get() to be read only or change storeValue to fail silent on terminated transactions. I vote for the former, but it may cause problems with the behaviour of initialValues. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087143#4087143 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087143

18 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2007