July 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Transaction Services] - Re: Listen address of JBossTS ports not configurable

by adrian＠jboss.org

Agreed. Although I'm yet to be convinced that NIO in java really does have those advantages. It certainly hasn't been true of the spec/Sun implementation. The best threading model is one thread per cpu doing NBIO (minimal context switching and cpu cache misses! :-) Its great in terms of throughput for asynchronous work. But the response times are appalling under load for more RPC style uses. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065955#4065955 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065955

18 years, 8 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Memory leak tests trunk

by kabir.khan＠jboss.com

The memory leak tests have been ported over from Branch_AOP_1_5. To run them, you need to download http://labs.jboss.com/jbossprofiler/downloads/jboss-profiler-1.0.CR4.zip and get the contained jvmti/native/win32/jbossAgent.dll (or jvmti/native/linux/libjbossAgent.so). The containing folder must be added to the PATH environment variable. Then to run the tests $ build.sh -f build-tests-jdk50.xml memory-tests Leaks will be output in a file called output/reports-leak-report-TEST_CASE_NAME.html One important thing is if you have run tests with -Djboss.aop.debug.classes=true, make sure that you delete the jboss-aop/aop/org folder, otherwise it gets confused wrt the classloaders. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065951#4065951 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065951

18 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService todos for deployer changes

by scott.stark＠jboss.org

The ManagedObject api does not reflect the full structure currently. They only map to the attachments managed for a given DeploymentContext. The full structural view is what the ManagedDeployment/ManagedComponent being created by the aspects associated with the ManagementViewImpl provide. I think we are saying the same thing. The ManagedDeployment should be moved into the org.jboss.managed.api package and created on the server side as part of the deployer chain. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065942#4065942 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065942

18 years, 8 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: Listen address of JBossTS ports not configurable

by david.lloyd＠jboss.com

"adrian(a)jboss.org" wrote : In fact, my real opinion is that you should do the reverse and provide | an implementation of an interface like the following: | | void run(InputStream is, OutputStream os) throws IOException {} | Except this makes it totally impossible to use NIO. Probably better would be to depend on an NIO framework (like Grizzly or MINA perhaps?) which could still conceptually allow you to fiddle with the socket and protocol details within the container, but at the same time support nice NIO things like reducing copying and better (than thread-per-connection/thread-per-request) threading models. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065923#4065923 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065923

18 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - JBossESB 4.2 MR3 is out

by Kevin.Conner＠jboss.com

This has just been announced on the User Forum (http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065918). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065920#4065920 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065920

18 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService todos for deployer changes

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | + testJmsDestinationComponents is broken because the ManagedDeployment/ManagedComponent tree cannot be built from the DeploymentUnit or client Deployment view as there is no access to the service descriptor component mbeans. A destinations-service.xml corresponds to multiple mbeans of various component types. In general the component types are unknown. We need to move the ManagedDeployment construction out of the client view of the profile service into a ManagedDeploymentDeployer, and start adding annotations to the other deployers/deployments to identify the component/jsr77 types that are produced. | I don't understand this. The managed objects are built on the server side by the MainDeployer with the help of the (parsing) deployers. The client should not be doing anything except asking for the ManagedObjects. IMHO the "jsr77 types" should be a part of the managed object api. i.e. you deploy a -ds.xml and you then ask for the managed objects you get back a set of managed objects which return "datasource" or "connectionfactory" from ManagedObject.getType() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065915#4065915 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065915

18 years, 8 months

1
0
0 / 0

[Design of JBoss jBPM] - Exception handling

by kevin.l.wilson

I've been trying to work with the Process-State node and implement a exception handler. However, I found that the exceptions are handled by the node previous. (I was surprised ...) This means that if a exception is not handled by a node the previous nodes in the hierarchy have the opertunity to handle the exception. This does not seem like what a user would expect. Also, shouldn't the Process-State be able to handle the exception from the subprocess. (execute is overridden in Node which does the exception processing, and no other catches are put in the ProcessState node. Can fix this by doing a lot of config to get my own process state node: 1) Implement the fix in my own version of the process state node. - I modified the signal call in enter() method to do the following: try { ...signal(); } catch (Exception e) { raiseException(e, executionContext); } This cause the exception handler I defined in the XML to be called correctly. However, I still could not call the leave() on the exception handler recieving a NullPointerException. (After, some testing I found I did not need to call leave in my code that it would leave on its own. However, this would need to be addressed in a patch. ) 2) Update a modified version of the ProcessState.hbm.xml - Change the implementation class. 3) Update the hybernate.cfg.xml - Point to the new mapping file for hybernate created in 2. 4) update the node.types.xml - Update the implementation class 5) Update the jbpm.cfg.xml to point to the new hybernate.cfg.xml and the node.types.xml Is this issue patchable? Is there a way to get a patched to this issue? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065913#4065913 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065913

18 years, 8 months

1
0
0 / 0

[Design of POJO Server] - ProfileService todos for deployer changes

by scott.stark＠jboss.org

Some issues remaining from the deployer changes affecting the profile service are: + testDataSourceDeploymentType is broken because the getDeploymentNamesForType cannot be implemented. This is probably useless functionality, as it relies on the DeploymentContext.getTypes(). What is really needed is the ability to view the jsr77 types in a deployment structure. + testJmsDestinationComponents is broken because the ManagedDeployment/ManagedComponent tree cannot be built from the DeploymentUnit or client Deployment view as there is no access to the service descriptor component mbeans. A destinations-service.xml corresponds to multiple mbeans of various component types. In general the component types are unknown. We need to move the ManagedDeployment construction out of the client view of the profile service into a ManagedDeploymentDeployer, and start adding annotations to the other deployers/deployments to identify the component/jsr77 types that are produced. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065905#4065905 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065905

18 years, 8 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP Testsuite nearly fixed in JBoss-Head

by adrian＠jboss.org

I improved the error reporting in this area and now I get a more reasonable explanation of the problem: | 19:19:23,836 ERROR [STDERR] Caused by: java.lang.IllegalStateException: ClassLoader has been undeployed: org.jboss.mx.loading.UnifiedClassLoader3@1689e12{ url=vfsfile:/home/ejort/jboss-head/testsuite/output/lib/aop-scopedear2.ear ,addedOrder=62} | 19:19:23,836 ERROR [STDERR] at org.jboss.aop.deployment.ScopedClassLoaderDomain.getScopedRepository(ScopedClassLoaderDomain.java:181) | 19:19:23,836 ERROR [STDERR] at org.jboss.aop.deployment.ScopedClassLoaderDomain.getPerVmAspectWithNoParentDelegation(ScopedClassLoaderDomain.java:121) | 19:19:23,836 ERROR [STDERR] at org.jboss.aop.deployment.ScopedClassLoaderDomain.getPerVMAspect(ScopedClassLoaderDomain.java:105) | 19:19:23,836 ERROR [STDERR] at org.jboss.aop.Domain.getPerVMAspect(Domain.java:735) | 19:19:23,836 ERROR [STDERR] at org.jboss.aop.Domain.getPerVMAspect(Domain.java:721) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065904#4065904 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065904

18 years, 8 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: AS Startup time suggestions?

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | I've made no quantative effort on this subject and I personally am | not going to look at optimization until we get closer to the final release. | "Early optimization is the root of all evil". :-) And even then the main optimization effort should be spent on the runtime not the deployment. It's perfectly acceptable to slow down the bootstrap to improve runtime performance. e.g. the classloader creates an index of every package in every jar deployed to speed up the classloading during the runtime. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065902#4065902 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065902

18 years, 8 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 July 2007