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

[Design of JBoss Profiler] - Re: Instructions for use with JBoss 3.2.6 ?

by jesper.pedersen

Mhmm 3.2.6 thats pretty old ;) You are a bit on your own here - as 3.2 hasn't been tested with JDK 5, but hey if you got it working... I would use the ASM library as the core - the rest should _properly_ be ok. I havn't tested it, so can't say for sure. So go with: core=asm and see if that works. Feel free to post your results. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150853#4150853 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150853

17 years, 11 months

1
0
0 / 0

[Design of JBoss Profiler] - Instructions for use with JBoss 3.2.6 ?

by rickcr

The readme file ssems a bit confusing for use with JBoss 3.2.6 (Yea I know we should upgrade.. it's coming:). Anyway, are there specific things I need to do to use this in 3.2.6 that are different from what the readme says. The readme mentions not using javassist (Whatever that is) and some other posts mention about using a different sar in the deploy dir? Also, do I comment out the javasssist line in the props file since I'm not supposed to use it? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150850#4150850 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150850

17 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - running server from src.

by ataylor

Ive added a target to the main build file that will start the server. simply execute in the root directory ant runServer View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150849#4150849 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150849

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBAS-2408 - EJB3 / JCA integration

by jesper.pedersen

Just a small update on the SPI work. The EndpointActivationBusLocator isn't needed as the EndpointActivationBusManager should be injection using @Inject or through a -beans.xml file. The manager itself is installed in the microcontainer using a -beans.xml together with its dependencies. The manager is a singleton. One dependency is currently the JCAMetaDataRepository as the manager needs information about the resource archives that have been installed. Furthermore the client can activate the endpoint using a set of properties -- and of course the client callback object (Endpoint). I'm currently investigating the interaction with the EndpointActivation from a clients point of view using the EJB3 messaging container as the example. The EJB3 messaging container currently relies on two classes: JBossMessageEndpointFactory and MessageInflowLocalProxy both in the org.jboss.ejb3.mdb.inflow package. Most of the functionality in JBossMessageEndpointFactory will be replaced by the EndpointActivation and the callback object. The task is to replace the MessageInflowLocalProxy with something on both sides - or some sort of callback that the client provides. The AOPEndpoint interface doesn't currently fit in here, since MessageInflowLocalProxy is an java.lang.reflect.InvocationHandler. The question is also how much of the JCA API we expose to the client. I havn't investigated yet how the resolveRarContext method should be implemented, but properly a scan through the metadata and lookups in the microcontainer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150845#4150845 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150845

17 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Optimisations: A couple of low hanging fruits going for

by timfox

"david.lloyd(a)jboss.com" wrote : Incorrect, Tim. A char holds 16 bits - high-plane code points are *already* split into surrogate pairs in a char[] such as used to back a String. This is probably all moot since we're talking about bitwise operations here which are going to be fast :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150841#4150841 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150841

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Serialization of ProxiedStatefulBeanContext

by bstansberry＠jboss.com

Done. http://jira.jboss.com/jira/browse/EJBTHREE-1360 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150839#4150839 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150839

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Scope of the Proxy Component

by ALRubinger

So this debate is actually, "What *is* the scope of the Proxy Component?" :) I maintain that Carlo's stated requirement is a "business requirement" of EJB3, and therefore should be tested by EJB3 Integration Tests. Additionally, I believe this is achieved through two "functional requirements" of disparate components: * jboss-metadata must return Strings of the JNDI Names in correct form * EJB3 Proxy must return appropriate proxies from whatever addresses are specified by jboss-metadata. The fundamental difference is that I disagree with: "wolfc" wrote : Clearly it is the responsibility of the proxy component to satisfy this requirement, so the test is a post condition for the component. >From a more generic perspective, I'm not familiar with this notion of "Component Testing": A is a Component B consumes A This forms another Component (A,B) B is responsible for testing A to certify (A,B) is OK. The above is from Carlo's reference http://www.faqs.org/faqs/software-eng/testing-faq/section-14.html By the above definition, each component we have would be responsible for running acceptance tests on the libraries it consumes (dependent upon the risk factor at stake). I'm more aligned with the Agile Community's stance on acceptance testing, which says that it's done at the user story (ie. final integration) level (http://en.wikipedia.org/wiki/Acceptance_testing#Acceptance_Testing_in_Ext...). S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150836#4150836 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150836

17 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Optimisations: A couple of low hanging fruits going for

by david.lloyd＠jboss.com

Incorrect, Tim. A char holds 16 bits - high-plane code points are *already* split into surrogate pairs in a char[] such as used to back a String. A char represents a UCS-16 character, not a Unicode codepoint. So again, just write out the chars and you've got UTF-16. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150831#4150831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150831

17 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Optimisations: A couple of low hanging fruits going for

by timfox

"david.lloyd(a)jboss.com" wrote : | UTF-16 on the other hand, being the native encoding for Java, is written one char at a time without transcoding - no shifts, no comparisons, no bitmasks. It's just a straight write of chars. You can't possibly do better than that in terms of processing speed. Even for UT-16 I believe for the high planes of unicode the characters have to be encoded using pairs of chars, so it's not quite a simple write of chars but pretty close. But in any case, simple comparisons and bitwise operations are fast. I doubt this is the reason why the encoding is slow. My bet, as mentioned before is there is some other overhead due to the setup of the codec classes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150827#4150827 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150827

17 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Optimisations: A couple of low hanging fruits going for

by trustin

"timfox" wrote : "trustin" wrote : | | | | for (int i = 0; i < str.length(); i ++) { | | buf.putChar(str.charAt(i)); | | } | | Well... UTF-8 is just putting a sequence of bytes generated from bitwise operations on the chars? So should be fast right? | | Maybe the overhead is due to the creation of the encoder class etc, I don't really know I haven't profiled it yet... | | Maybe we should just write our own encoding that writes directly onto a SimpleString... Yes, the creation of a CharsetEncoder takes a lot of time and therefore cached somewhere. String.getBytes() uses ThreadLocal for this purpose, but if you already have some context object that stores the decoding/encoding state, then you can just add a field there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150823#4150823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150823

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