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

[Design of EJB 3.0] - Re: The default local interface (vs. EJBTHREE-785)

by bill.burke＠jboss.com

"wolfc" wrote : Another failing scenario: http://jira.jboss.com/jira/browse/EJBTHREE-1062 Which is still different than the example you gave. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093182#4093182 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093182

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: The default local interface (vs. EJBTHREE-785)

by bill.burke＠jboss.com

"wolfc" wrote : The failing scenario is: | @Stateless class MyBean extends SuperBean implements SomeInterface {} | | | | interface SomeInterface {} | | | | class SuperBean implements RemoteInterface {} | | | | @Remote interface RemoteInterface {} | If I follow the letter than SomeInterface will become the only business interface (local). | The spec says nothing about inheritance of interfaces. anonymous wrote : | If I follow EJBTHREE-785 than RemoteInterface will become the only business interface (remote). | Nope, just read EJBTHREE_785. What Gavin wants is this: | public class MyBean implements MyRemote {} | | @Stateless | public class SubBean extends MyBean {} | Business interface of SubBean has a remote interface of MyRemote. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093178#4093178 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093178

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: The default local interface (vs. EJBTHREE-785)

by wolfc

Another failing scenario: http://jira.jboss.com/jira/browse/EJBTHREE-1062 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093167#4093167 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093167

18 years, 6 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - TestNG throws exception if @PersistenceContext is used in a

by rizqureshi2

I get the following error when I have a bean with @PersistenceContext declaration: ("register" is the name of bean used) FAILED CONFIGURATION: @BeforeClass init java.lang.RuntimeException: Could not create Component: register at org.jboss.seam.init.Initialization.addComponent(Initialization.java:833) at org.jboss.seam.init.Initialization.addComponents(Initialization.java:715) at org.jboss.seam.init.Initialization.init(Initialization.java:478) at org.jboss.seam.mock.SeamTest.init(SeamTest.java:701) Caused by: java.lang.IllegalArgumentException: @PersistenceContext may only be used on session bean or message driven bean components: register at org.jboss.seam.Component.initMembers(Component.java:541) at org.jboss.seam.Component.(Component.java:250) at org.jboss.seam.Component.(Component.java:200) at org.jboss.seam.init.Initialization.addComponent(Initialization.java:823) ... 25 more ... Removed 22 stack frames ----------------------------------------------------------------------------- I have been working on this problem for days and no success yet. Am I missing out something? Also note that the project deploys & runs fine on JBoss-As without any problem, so why should the TestNG case throw the above exception?? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093162#4093162 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093162

18 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Need Notification when message is dropped due to max siz

by jhowell＠redhat.com

The reason that the topic is not handled the same way is because if we were to throw an exception, then it would stop the processing of the other subscribers. So you have a topic and you have 100 subscribers. If the 5th subscriber throws an exception, then the delivery will not happen for the other 95. This could be alleviated by catching the exception, but then the exception might not be tossed high enough. So the answer seems to be in some refactoring. After speaking to Tim, we may implement something like the batch sql function in jdbc. It returns an array/collection of objects that represents the success/failure of each one of the durable subscriptions. Not sure what this will look like, but this could be interpreted to see why the failure happened. This would provide the handling needed to see if a queue(durable subscriber) has rejected the entry due to a max size. Jay:) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093141#4093141 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093141

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: The default local interface (vs. EJBTHREE-785)

by wolfc

Or even better: * If bean class implements a single interface, that interface is assumed to be a business interface of the bean. This business interface will be a local interface unless the interface is designated as a remote business interface by use of the Remote annotation on the bean class or interface or by means of the deployment descriptor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093134#4093134 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093134

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: The default local interface (vs. EJBTHREE-785)

by wolfc

The failing scenario is: @Stateless class MyBean extends SuperBean implements SomeInterface {} | | interface SomeInterface {} | | class SuperBean implements RemoteInterface {} | | @Remote interface RemoteInterface {} If I follow the letter than SomeInterface will become the only business interface (local). If I follow EJBTHREE-785 than RemoteInterface will become the only business interface (remote). I think we can get away with the following: * If the bean class has no interface (including interfaces from superclasses) explicitly declared as a business interface and the bean class implements a single interface, than that interface is assumed to be the local business interface of the bean. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093133#4093133 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093133

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: The default local interface (vs. EJBTHREE-785)

by bill.burke＠jboss.com

The letter of the law is, if the bean's implementation does not match the default pattern (implements one interface that isn't declared remote or local), then you must be explicit on what the Remote and/or local interface is. Its pretty simple and clear to me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093119#4093119 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093119

18 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Deadlock in JBoss Messaging during JBoss5 shutdown

by timfox

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

18 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: [sim] using simulation engine for load testing?

by kukeltje

hahaha... I agree with all of this. There should be a different engine to execute a loadtest. Maybe the sim scripts can be used to do something with grinder which is highly configurable/scriptable/.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093075#4093075 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093075

18 years, 6 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 2007