August 2008 - jboss-dev-forums - Jboss List Archives

[Design of AOP on JBoss (Aspects/JBoss)] - AOPLogging

by stale.pedersen＠jboss.org

after looking into JBAOP-623 ive changed our logger to something similar to what messaging got. i havent changed the logic for when we apply our own logger (which is SystemOutLoggerPlugin), and the problem that i see is that its not applied at all when aop is running standalone. when i run in "verbose" mode standalone i usually get: [java] log4j:WARN No appenders could be found for logger (org.jboss.aop.instrument.InstrumentorFactory). | [java] log4j:WARN Please initialize the log4j system properly. this is something we should set by if its not set by the user imo. - but i guess we cant always set org.jboss.logging.Logger.pluginClassName to our own logger since this would overwrite what others has set it to (correct me if im wrong here). we also have a lot of System.err.print outputs in our code, should i change them to use the logger too or is it a good reason why its not using the logger? :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172539#4172539 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172539

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Message Chunking Performance problems

by ataylor

FYI, I did 2 comparisons for both Mina and Netty View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172536#4172536 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172536

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Message Chunking Performance problems

by ataylor

I've put together some figures comparing the performance of the current trunk and the message chunking work that I've been doing. It was compiled using the perf example, both sender and listener, and uses the default settings ( apart from message count ) and were all run on the same machine, my laptop. These figures can be found here, http://wiki.jboss.org/wiki/_Files/JBM2HandlingLgeMessages/messageChunking.... Basically there are 3 sets of data, the trunk, the message branch with an initial buffer size of 1k and a max buffer size of 64k, and the message branch with an initial buffer size of 1k and max buffer size of 1k, NB. Using different initial and max buffer sizes means we need auto growing buffers. Basically the results show that if we send lots of small buffers, say 1k, it has a massive impact om performance but if we increase the max buffer size to 64k there is little or no difference. These results are limited so if anyone has some decent hardware it would be good to see some more figures. I was thinking we could make the initial and max buffer size configurable and set it to a default of 1k and 64k respectively. I also tested the speed of basic writing and reading from the buffer, for 100,000,000 bytes it took 7857/1048 Milliseconds for the branch and 8918/319 for the trunk for writing and reading. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172534#4172534 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172534

17 years, 7 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-5171 - New metadata - track-connection-by-tx

by alex.loubyansky＠jboss.com

I've deprecated track-connection-by-tx and introduced interleaving element and managed attribute in the code. Also corrected the examples in connector/example-config. The remaining is the schema connector/resources/schema/jboss-cf.xsd and the dtd. Both look inaccurate to me. E.g. track-connection-by-tx in the schema is of boolean type and must always be present. track-connection-by-tx is the dtd is declared as EMPTY but must always be present! So, it seems like none of them was actually used (or used only when it didn't fail)? I would fix the track-connection-by-tx in the current versions of schema and dtd then create another version of both w/o track-connection-by-tx but with interleaving. Does this sound right to everybody? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172530#4172530 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172530

17 years, 7 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: Persistence unit deployers are not invoked for WEB-INF/l

by wolfc

I already have such a deployer, it's the PersistenceParsingDeployer. I just need something that triggers this deployer. Maybe the WARStructure can fire something off? It's similar to deploying an EAR with modules in it, but for JavaEE 5 most 'module' types should be ignored. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172528#4172528 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172528

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JBMICROCONT-336; empty string failure

by alex.loubyansky＠jboss.com

In XB empty string processing is different for simple and complex types. I.e. for the following element <e></e> the result will be an empty string if e is of a simple type and null if e is of a complex type. It's null for the complex types because otherwise elements of complex types would always get non-null text data which was undesirable. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172517#4172517 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172517

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JBMICROCONT-336; empty string failure

by alesj

Shouldn't this - https://jira.jboss.org/jira/browse/JBMICROCONT-336 be handled in JBossXB? Where in MC's case, PropertyMetaData would get StringValueMetaData with empty string set. Or what would be appropriate place/hack to set this in MC's xml metadata handling? I've added PropertyUsageTestCase which exposes the issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172507#4172507 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172507

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Some Maven related changes

by pgier

"alesj" wrote : | "pgier" wrote : | | Also, is there any reason not to change the directory names to follow the maven conventions? Currently we have src/main and src/tests. I'd like to change these to src/main/java and src/test/java. | Dunno, never thought about it. | What else can it be if not java? | Probably this comes in handy when you have multi-language project? | | If we eventually go this path, | then you must change all of MC's subprojects. ;-) | - http://www.jboss.org/jbossmc | For microcontainer we wouldn't have anything other than Java. But if we use the standard maven directory names, then I can remove that config from the poms. Yes, it's most useful when you have multi language projects which includes stuff like javacc grammar files (src/main/javacc) like we have in the app server build. I'll plan on changing all the MC subproject directories also. And eventually the app server will change once it's fully migrated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172421#4172421 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172421

17 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - JGroups Protocol Stack Configuration & Shunning Behavior

by jiwils

Currently, the JBoss Messaging control channel sets FD.shun=true and GMS.shun=false. Given that JBoss Messaging doesn't use the AUTO_RECONNECT configuration for a channel due to concerns about state, should we be shunning nodes or not given that a shunned node will never attempt to rejoin the cluster? It seems to me that we would want shunning enabled to kick out nodes that are behaving badly for whatever reason, but is our concern for the network split case reason enough to avoid this altogether? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172420#4172420 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172420

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Some Maven related changes

by alesj

"pgier" wrote : I'd like to make a couple of changes in the microcontainer build. The first is to change the parent/aggregate relationship so that the pom in the root directory functions as the parent. This will be more like how the app server build and the aop maven build are set up, and more like how maven builds itself. The build subdirectory will then be just for creating the combined jar files. | Isn't app server similar to what we have in MC? Component-matrix ~ build? But yeah, fine with me. Adrian (as now my first officer :-)? "pgier" wrote : | Also, is there any reason not to change the directory names to follow the maven conventions? Currently we have src/main and src/tests. I'd like to change these to src/main/java and src/test/java. Dunno, never thought about it. What else can it be if not java? Probably this comes in handy when you have multi-language project? If we eventually go this path, then you must change all of MC's subprojects. ;-) - http://www.jboss.org/jbossmc View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172416#4172416 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172416

17 years, 7 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 August 2008