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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MessagingBuffer implementation leaking into MessageImpl

by ataylor

anonymous wrote : For this reason, I abstracted out the MessagingBuffer interface so it does not depend on MINA. The problem is that if i create a new Message it makes an assumption that we are using Mina and defaults he body to an IoBufferWrapper. If we were using the INVM transport properly and de/serialising to a ByteBufferWrapper instead when we encode or decode the message all the headers get written to the ByteBufferImpl and the bod gets written to the defaulted IoBufferWrapper. Also when we write the buffer we call buff.array(), isntthat doing a copy anyway? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158975#4158975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158975

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MessagingBuffer implementation leaking into MessageImpl

by timfox

The reason the message holds the buffer directly is to minimise copying. If we stored it as a byte buffer then copied it to the mina buffer that would involve unnecessary copying. For this reason, I abstracted out the MessagingBuffer interface so it does not depend on MINA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158973#4158973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158973

16 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Wrong position of DeploymentControllerContext addition

by alesj

I moved it up, before install: | + context.getTransientAttachments().addAttachment(ControllerContext.class, deploymentControllerContext); | try | { | controller.install(deploymentControllerContext); | context.setState(DeploymentState.DEPLOYING); | log.debug("Deploying " + context.getName()); | - context.getTransientAttachments().addAttachment(ControllerContext.class, deploymentControllerContext); View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158968#4158968 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158968

16 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - MessagingBuffer implementation leaking into MessageImpl

by ataylor

Currently when a message is encoded or decoded, the methods are called from The transport layer and the MessagingBuffer implementation is specific to this transport. The transport will encode/decode the messages by using the MessagingCodecImpl and this in turn delegates down to a specific Packet depending on the PacketType. When a Packet encodes/decodes itself it should not need to know anything about the MessagingBuffer implementation. However I've noticed that in MessageImpl the body of the message is also a MessagingBuffer and in the constructor and the decode method we default to the Mina Implementation. This all works at present since we only use Mina but will fail when the ByteBufferWrapper or the new Netty implementation when Trustin adds it. the method clearBody() in JbossBytesMessage and JBossStreamMessage also assumes an implementation. 1 solution would be to add a new class 'MessageBody' that uses an underlying ByteBuffer and when the message is encoded/decoded we call buffer.put(byteBuffer) etc. I'm not 100% sure what the effect on performance will be but i was thinking that using a direct ByteBuffer will mean no copying is done. thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158966#4158966 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158966

16 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBMETA-44, ws annotation processing for references

by emuckenhuber

"alessio.soldano(a)jboss.com" wrote : | Generally speaking this use case (@HandlerChain on a service ref) should of course be supported. | As far as I can see we don't have a testcase for this yet, thus I think I'll start creating one. | Okay - i have a prototype working for this.. just need to check again - maybe you can validate it then to make sure that i did not miss anything. But ServiceReferenceHandlerMetaData cannot be defined over annotations just via the xml descriptors - right? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158936#4158936 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158936

16 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Wrong position of DeploymentControllerContext addition

by alesj

There is a bug in DeployersImpl::process. :-) The position of where we add DeploymentControllerContext is wrong. Or we don't do enough checks. | controller.install(deploymentControllerContext); | context.setState(DeploymentState.DEPLOYING); | log.debug("Deploying " + context.getName()); | context.getTransientAttachments().addAttachment(ControllerContext.class, deploymentControllerContext); | After controller::install. But what if it fails there? So this is then null: | DeploymentControllerContext deploymentControllerContext = context.getTransientAttachments().getAttachment(ControllerContext.class.getName(), DeploymentControllerContext.class); | ControllerState current = deploymentControllerContext.getState(); | Should we move that addition before controller::install. Or add additional check if DCC is not null? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158927#4158927 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158927

16 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Regarding JBoss ESB

by AmbicaSona

Can anybody help me in sloving the problem ASAP. If i dont mention properties file in my config file i am getting the app servers index page code as Response. And if i use that property file inside my config i am getting error by saying ERROR [STDERR] javax.net.ssl.SSLHandshakeException: Remote host clo sed connection during handshake [STDERR] at com.sun.net.ssl.internal.ssl.SSLSocketImpl.re adRecord(SSLSocketImpl.java:801) ................................. I strucked there and not finding any solution. Trying to run the sample https_2way_ssl, which came with download is also not working. Highly thankful work quick responses. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158898#4158898 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158898

16 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Handling fatal JDBC connection exceptions

by jesper.pedersen

Sounds like a good idea - if you want to take a look see the org.jboss.resource.adapter.jdbc package. That being said - we are about to start a new implementation of the JCA container where we will keep this feature request in mind. Thanks ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158890#4158890 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158890

16 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: SOAPClient Wiki Page needs UPDATE!

by ehsanmx

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

16 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: ClientContainer injection

by scott.stark＠jboss.org

There is a server side org.jboss.injection.InjectionUtil from ejb3 that uses the classInjectors. There is also a client side org.jboss.ejb3.client.Utils that is what should be used in place of InjectionUtil to avoid mixing server side behavior in the client container. I see that the InjectionUtil is still being used in places in the client handlers, so I'll have to clean this up as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158839#4158839 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158839

16 years, 2 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 June 2008