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

[Design of POJO Server] - Re: JBoss Managed - CR1

by scott.stark＠jboss.org

The 2 open issues still need to be completed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167072#4167072 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167072

17 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: need a jboss-cl release

by scott.stark＠jboss.org

Yes, I'm currently working with the snapshot locally. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167071#4167071 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167071

17 years, 8 months

1
0
0 / 0

[Design of JMX on JBoss (JBoss/JMX)] - Re: How to configure jboss to enable the authentication of t

by cnsunfocus

Is there nobody who encounter this question? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167061#4167061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167061

17 years, 8 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: How does version.properties get copied

by clebert.suconic＠jboss.com

AFAIK version.properties is generated based on the version attributes maintained on build-messaging.xml. So on that case (unless we change it), it should be generated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167059#4167059 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167059

17 years, 8 months

1
0
0 / 0

[Design of EJB 3.0] - Re: @RemoteBindings and clientBindUrl - JNDI binding questio

by jaikiran

"wolfc" wrote : | | The goal is to give the bean developer the ability to specify a client bind url per remote business interface. Now in your example you have 2 bindings and 1 interface. | I started off with this test based on what i read here http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/t.... The example there is similar, in the sense that it has a single remote interface but with 2 RemoteBinding. Has that behaviour changed? Currently I don't see a way where i can associate a remote business interface (rather than a remote jndi binding) with a client bind url? To make it more clear: | @RemoteBindings ( | { | @RemoteBinding (jndiBinding=MyStatelessBeanWithMultipleRemoteBindings.REMOTE_JNDI_NAME), | @RemoteBinding (jndiBinding=MyStatelessBeanWithMultipleRemoteBindings.ANOTHER_REMOTE_JNDI_NAME, clientBindUrl=MyStatelessBeanWithMultipleRemoteBindings.CUSTOM_CLIENT_BIND_URL) | } | | public class MyStatelessBeanWithMultipleRemoteBindings implements MyStatelessRemote, AnotherRemote | Currently, I can't specify that the @RemoteBinding with a CUSTOM_CLIENT_BIND_URL is for the "AnotherRemote" business interface. "wolfc" wrote : | In my mind clientBindUrl is an attribute of the remote business interface. | Since the intention is to allow the bean developer to specify a client bind url per remote business interface, shouldn't the @RemoteBinding have a provision where the beanInterface can be mentioned. Maybe a "beanInterface" property to the @RemoteBinding annotation?. Just a thought, maybe there's a better way to handle this. In terms of API changes, not sure how big this change would be. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167038#4167038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167038

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by david.lloyd＠jboss.com

"david.lloyd(a)jboss.com" wrote : "trustin" wrote : * We can run both R2 and R3 at the same time in the microkernel, so R2 users should be able to keep using R2 services or upgrade to R3. | | This is true; however then we will have not only both versions running, but all services will have to have an R2 and R3 version. This might be difficult to do in some cases where the Remoting implementation is tied to the service (like the UnifiedInvoker for example). | Not that I want to rule this out mind you. I'm just expressing that this difficulty does exist. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167024#4167024 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167024

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by david.lloyd＠jboss.com

"trustin" wrote : I talked to Tim in the JBoss Messaging IRC channel to get some quick answers about the flaws of R2 protocol. They were: | | * Connection pooling doesn't allow you to send other commands when a request is in progress. It also causes the order of invocation get mixed up. - This issue can be fixed by fixing R3 client behavior. Correct. "trustin" wrote : * The way ping works - I don't have much idea about how ping works. Someone could address this issue. | | * Protocol doesn't have a command type identifier - It's OK because we can bump up the version field and provide a command type identifier, sequence no, etc if necessary. If these issues are a problem, then don't use the R2 protocol. "trustin" wrote : Also, he suggested me to abandon R2 protocol and go straight to the whole new transport (e.g. SSH + new wireformat) because: | | * We are not required to be backward compatible with R2 and we should give it up to avoid maintenance difficulty. Incorrect, we are in fact required to be compatible with R2 before R3 can be accepted into JBossAS. "trustin" wrote : * We can run both R2 and R3 at the same time in the microkernel, so R2 users should be able to keep using R2 services or upgrade to R3. This is true; however then we will have not only both versions running, but all services will have to have an R2 and R3 version. This might be difficult to do in some cases where the Remoting implementation is tied to the service (like the UnifiedInvoker for example). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167023#4167023 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167023

17 years, 8 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: JBCLUSTER-206 - Extract HB/JBC integration layer from EJ

by bstansberry＠jboss.com

Cool. I'll have a look later today. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167022#4167022 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167022

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

by david.lloyd＠jboss.com

"trustin" wrote : I think we can make the XNIO-based protocol implementation look similar to that of Remoting 2 socket transport. As David explained in the IRC channel, we could simply retain the core classes which are serialized and deserialized in R2 and convert them to R3 classes and vice versa to implement R2 compatibility: This would be a problem due to the fundamental difference with how R2 requests are made. I don't think that the R2 version will have much similarity to R3 because the R2 marshaling and protocol format are very limited. Like Tim pointed out in a more recent post, R3 should not accept the same basic limitations at its core. A bit later I'll post a diagram illustrating how the various bits might work together. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167018#4167018 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167018

17 years, 8 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Streaming in R3

by david.lloyd＠jboss.com

Yeah, the ChannelSource can implement pooling if needed. In terms of QoS... I think that is up to the transport. Sockets for example are handled by the OS of course. Other transports specify how bandwidth is shared as well. I think it should be up to the channel implementation to keep stream handlers as simple as possible. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167016#4167016 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167016

17 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 2008