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

[Design of EJB 3.0] - Kill Default Remote Binding if 1+ @RemoteBinding is specifie

by ALRubinger

The current implementation treats @RemoteBinding as an additional binding to the defaults. This makes for a situation that may present collisions. Given: @Stateless(name="MyBean") | @Remote(MyRemote.class) | @RemoteBinding(jndiBinding="MyBean") | class MyBean{...} Right now this would produce: /MyBean - Explicit from @RemoteBinding | /MyBean/remote - Default Remote Business Interface Proxy Binding ...this makes for a CCE when attempting a Context.bind() on the 2nd entry because "MyBean" would not be a subcontext. So I'm going to make a rule that says: "If at least one @RemoteBinding is specified, then the default remote business interface binding will not be applied." Anyone see problems w/ this approach? S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184366#4184366 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184366

17 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 / AS Integration

by ALRubinger

https://jira.jboss.org/jira/browse/EJBTHREE-1544 S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184363#4184363 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184363

17 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - EJB3 / AS Integration

by ALRubinger

Earlier this week I started a 2-class project, EJB3 Deployers. The idea is to provide a home for deployers which may be shared by any assembly that uses EJB3. AS, EJB3 Embeddable, AS Embedded, EJB3 Standalone...however we can spin it. I'd like to continue the trend of moving EJB3 further from AS, such that AS would depend on one component only. So I'll introduce "org.jboss.ejb3:jboss-ejb3-as-int". Instead of EJB3 Core, AS will depend upon the integration project which may define things like: * *-jboss-beans.xml * Transitive dependencies for required libraries * AS-specific code (which should be at an absolute minimum, if at all) My hope is that over the next few months we're able to remove the "ejb3" module of AS entirely. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184361#4184361 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184361

17 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Reintroducing Asynchronous Support

by ALRubinger

In addition to the simplicity argument, another motivation I have is to make the APIs between our support and that defined by EJB3.1 as close as possible. Even though EJB3.1 spec says that the decision to invoke async or not lies w/ the bean provider; I say it should be the caller's choice. So that's why we'll keep our implementation as well. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184357#4184357 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184357

17 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Reintroducing Asynchronous Support

by ALRubinger

In writing EJB3 Proxy, and to prioritize compliance w/ TCK, we've dropped support for asynchronous invocations. I'm now putting it back. The previous implementation worked like: * Get a traditional Proxy from JNDI * Cast that to an interface implemented by all Proxies, "JBossProxy" * Call Object myAsync = JBossProxy.getAsynchronousProxy(); * Cast myAsync to the the Business Interface to invoke * Cast myAsync to AsynchProvider (org.jboss.aspects.asynch.AsynchProvider) to get the Future (org.jboss.aspects.asynch.Future) ...it looks like: StatefulRemote tester = | (StatefulRemote) getInitialContext().lookup("StatefulBean/remote"); | assertEquals("Wrong return for stateful remote", 31, tester.method(31)); | | StatefulRemote asynchTester = (StatefulRemote)((JBossProxy)tester).getAsynchronousProxy(); | assertEquals("Wrong return value for stateful remote", 0, asynchTester.method(32)); | AsynchProvider ap = (AsynchProvider) asynchTester; | Future future = ap.getFuture(); | int ret = (Integer) future.get(); | assertEquals("Wrong async return value for stateful remote", ret, 32); I want to change the following: * Proxies should not be equipped with the facilities to return an asynchronous version of themselves. I'd rather see another component take an existing proxy and async-ize it. So async becomes a true add-on optional capability. * Remove use of org.jboss.aspects.asynch.Future in favor of java.util.concurrent.Future One hitch I see with Bill's Future implementations is that they directly support remoting via the AOP Dispatcher. I want to simplify the whole thing by making the async client-side interceptor act like a regular client which carries the invocation as a j.u.c.FutureTask. We'll see if I'm missing some reason why things were built as they were. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184356#4184356 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184356

17 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Default JNDI naming scheme in EJB3.0 and possible confli

by jaikiran

Okay :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184354#4184354 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184354

17 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Exception propagation using HTTP servlet transport on 1.

by ron.sigal＠jboss.com

Move thread to "Exception propagation using servlet transport" http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184344#4184344 on the Remoting Users forum. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184345#4184345 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184345

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-6104; slow Seam deployments

by shane.bryzak＠jboss.com

Excellent - can you please let me know when this makes it into jbossas trunk and I'll do some more performance testing. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184335#4184335 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184335

17 years, 2 months

1
0
0 / 0

[Design of EJB 3.0] - Re: r79976 Incompatible with AS

by ALRubinger

The reason the Plugin can't help us is: Caused by: java.lang.NoClassDefFoundError: org/jboss/jpa/spi/XPCResolver S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184330#4184330 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184330

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: build failing ?

by kukeltje

I'l try that tomorrow, now it is time to go to sleep (02:33 am) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184328#4184328 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184328

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