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

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Another way to write clustered singletons

by batter

"oglueck" wrote : Not only such a list would be interesting. You also must filter them for instance with the DeploymentInfoNotificationFilterFactory. So one must know the possible filter cirteria. Definitely; I am trying to add a dependency on the MQ service being started so I know f.e. that my queues and topics are deployed. Finally ran into this barrier discussion and am now playing with using that and then filtering on 'some' mq notification. For the time being I wrote my own bean and playing with it; if people leave me alone today I might do that NotificationListener thingy Dimitris suggested :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001038#4001038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001038

19 years, 2 months

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: Message redelivery from non transacted MDBs

by weston.price＠jboss.com

Correct. Technically, there is nothing to *force* us to redeliver the message in the case of a non specified transaction context (ie BMT, CMT NotSupported). All specs are at best ambiguous, and at worst, completely ingnorant of this subject. However, a customer requirement (not supported by me mind you) came up and this *feature* was added to the JCA adapter. This change initially was added in HEAD and then aggressively, and stupidly might I add, backported to multiple branches on the 4.x line. After the dust cleared I went back in HEAD and reworked some of it to be more performant and easier to understand. I haven't backported these changes yet. So, the long and short of it: If you want redelivery in the case of BMT, CMT NotSupported you a) Have to use JCA b) Are encouraged, if at all possible, to use the current implementation in HEAD. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001033#4001033 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001033

19 years, 2 months

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: Message redelivery from non transacted MDBs

by timfox

One other thing to note is that our redelivery behaviour differs from our competitors: http://edocs.bea.com/wls/docs81/ejb/message_beans.html The actual reason redelivery doesn't occur is that the MDB container which sits between the JMS provider and the customer provide onMessage implementation, catches the RuntimeException and wraps it in an EJBException. So when it gets to the JMS provider it's no longer a RuntimeException and the JMS provider won't redeliver the message (JMS says any RuntimeExceptions should cause redelivery). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001006#4001006 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001006

19 years, 2 months

1
0
0 / 0

[Design of the JBoss EJB Container] - Message redelivery from non transacted MDBs

by timfox

Using JBoss-4.0.5.GA. If I throw a RuntimeException from inside the onMessage method of a MDB set to tx NotSupported, then redelivery does not occur. The EJB2 spec is pretty silent about what should occur (17.6.3.1, 17.6.3.2) and only really says that redeliver should occur if the onMessage is running in a tx context. For the analogous case of a RuntimeException thrown from a non MDB (straightforward jms MessageListener) onMessage method with ack mode of AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE, then the JMS 1.1 spec is pretty clear that redelivery should be immediately attempted. It seems to me that the current MDB container behaviour is a bit weird, since you end up with messages remaining unacked in the connection consumers session until the mdb container is redeployed. A better and more intuitive behaviour IMHO would be to attempt to redeliver the message x times then put it in the DLQ. Then at least the user can do something with it. Otherwise it is effectively lost. I would have thought that if the EJB spec is silent about one aspect of MDB delivery behaviour we should fall back to what's specified in the JMS spec, rather than do something completely different. Or perhaps there's a good reason why redelivery isn't attempted in this situation that I haven't thought about. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001004#4001004 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001004

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1260 - such a part must refer to an element named a

by darran.lofthouse＠jboss.com

I can't reproduce the error you are seeing if my WSDL contains messages with 2 parts, instead I get the following error reported: - anonymous wrote : | [junit] org.jboss.ws.WSException: Only Request-Only and Request-Response MEPs are allowed | [junit] at org.jboss.ws.metadata.wsdl.WSDLUtils.getWsdl11Input(WSDLUtils.java:885) | [junit] at org.jboss.ws.tools.WSDLToJava.appendMethods(WSDLToJava.java:287) | [junit] at org.jboss.ws.tools.WSDLToJava.createSEIFile(WSDLToJava.java:588) | [junit] at org.jboss.ws.tools.WSDLToJava.createSEI(WSDLToJava.java:618) | [junit] at org.jboss.ws.tools.WSDLToJava.generateSEI(WSDLToJava.java:187) | [junit] at org.jboss.ws.tools.helpers.ToolsHelper.handleWSDLToJavaGeneration(ToolsHelper.java:304) | [junit] at org.jboss.ws.tools.WSTools.process(WSTools.java:138) | I think this check was part of some refactoring that happened on trunk. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000953#4000953 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000953

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: What does this mean?

by adrian＠jboss.org

I raised the following issues: http://jira.jboss.com/jira/browse/JBMICROCONT-140 http://jira.jboss.com/jira/browse/JBMICROCONT-141 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000942#4000942 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000942

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: What does this mean?

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | Either this code or the caller needs to validate that a getter exists. | The code should be: | JoinpointFactory jpf = info.getBeanInfo().getJoinpointFactory(); | MethodInfo minfo = info.getGetter(); | + if (minfo == null) | + throw new IllegalArgumentException("Property is write only"); | return getMethodJoinpoint(null, jpf, minfo.getName(), null, null); | The preinstantiated lookup should be using a different mechanism that first checks whether the property is readable rather than logging a warning when it is not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000939#4000939 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000939

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: bean/mbean integration issue

by adrian＠jboss.org

If as I suggested before, the BeanInfo becomes the main entry point for these operations the code would look something like: | public Object get(String name) throws Throwable | { | Object object = getTarget(); | BeanInfo info = getBeanInfo(); | return info.getPropertyValue(name, object); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000933#4000933 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000933

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: bean/mbean integration issue

by adrian＠jboss.org

"alesj" wrote : I added DispatchContext interface. | This interface is not correct. PropertyMetaData and ParameterMetaData are POJO specific. This interface belongs in the dependency module that knows nothing about POJOs/services. You need something like the DynamicMBean interface | Object get(String name) throws Throwable; | void set(String name, Object value) throws Throwable; | Object invoke(String name, String[] signature, Object[] parameters) throws Throwable; | The kernel/pojo context will turn this into joinpoint invocations on the context's target. | public Object get(String name) throws Throwable | { | KernelController controller = (KernelController) getController(); | Kernel kernel = controller.getKernel(); | KernelConfigurator configurator = kernel.getConfigurator(); | | Object object = getTarget(); | BeanInfo info = getBeanInfo(); | | TargetttedJoinpoint joinpoint = configurator.getPropertyGetterJoinpoint(info, name); | joinpoint.setTarget(object); | return joinpoint.dispatch(); | } | The service context will turn them into mbean invocations, e.g. | public Object get(String name) throws Throwable | { | return serviceController.getMBeanServer().getAttribute(objectName, name); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000931#4000931 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000931

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: bean/mbean integration issue

by adrian＠jboss.org

"alesj" wrote : | What's the 'hack'? | If the controller doesn't find the context, it asks the registry if it knows the name. Overridden method in the kernel controller: | public ControllerContext getContext(Object name, ControllerState state) | { | ControllerContext context = super.getContext(name, state); | if (context != null) | return context; | if (state == null || state == ControllerState.INSTALLED) | { | KernelRegistry registry = kernel.getRegistry(); | try | { | return registry.getEntry(name); | } | catch (Throwable ignored) | { | } | } | return null; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000923#4000923 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4000923

19 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 January 2007