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

[Design of EJB 3.0] - Meta data merging of beans using ejb-class

by wolfc

Why is ejb-class considered during the merge? Is it a left-over from Ejb30Creator? https://jira.jboss.org/jira/browse/JBMETA-154 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195282#4195282 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195282

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Large message code review

by timfox

*** 9.Flow control - for large message flow control should be called before adding adding to buffer APART from last chunk which should have flow control called before consumption, otherwise could flood the buffer. *** View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195259#4195259 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195259

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Task Management component?

by heiko.braun＠jboss.com

anonymous wrote : | a consequence of taking both decisions would be that we have to show facelets task forms in a GWT based console. but i don't see a problem with that. do you ? | Yes, I do see a problem with that. IMO the forms and the data associated with task management shouldn't be implementation specific. JSF is already a particular implementation and as results cannot be easily used with the console. If we would instead focus on data input and output sets to tasks, backed by a data type description (i.e. xsd) then we could easily build applications that interact with the task management by any means. JSF could then be one of them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195256#4195256 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195256

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Paging code review

by timfox

In your latest commit flow control appears broken, and not implemented as we discussed. This needs to be discussed later View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195250#4195250 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195250

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ConsumerTest Hudson intermittent failure

by timfox

To make the test assertion valid we'd have to make sure deliveringcount was incremented in the queue *before* the message reference was given to the server consumer for delivery. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195243#4195243 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195243

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ConsumerTest Hudson intermittent failure

by timfox

I think it's a very simple problem: The test assertion is invalid: | assertEquals(0, messagingService.getServer().getPostOffice().getBinding(QUEUE).getQueue().getDeliveringCount()); | Delivering count is incremented in the queue *after* the message is delivered: | HandleStatus status = distributionPolicy.distribute(reference); | | if (status == HandleStatus.HANDLED) | { | deliveringCount.incrementAndGet(); | return HandleStatus.HANDLED; | } | So, depending on thread scheduling the consumer could receive the message before delivering count gets incremented, in which case it would see the value -1, because the message is actually acked and delivering count decremented *before* it's incremented. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195242#4195242 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195242

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 Strict ordering via ordering groups

by timfox

"gaohoward" wrote : About performance: for each ordering group, it needs to have a sorted list to store message refs yet to be delivered, and for each message to deliver, it needs to check if the message is at the front of the list, if not, detain the delivery. | Huh? That's a performance penalty for your ordering group implementation not the message group implementation! I think you're getting them mixed up. I was suggesting using message groups, not ordering groups. anonymous wrote : | About the cluster: if there are a cluster Q on two nodes, M1 is sent to node1 and M2 to node2. If node1 dies when M1 is delivering, M1 will be moved to node2 for delivery. It need to make sure M2 will never be delivered until M1 is delivered, but who receives M1 or M2, doesn't matter. | Yes order is preserved on failover already in JBM 2.0 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195239#4195239 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195239

17 years, 4 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Upgrading Scout/JUDDI combo

by richard.opalka＠jboss.com

What about Scout 1.0rc1 it uses xml beans in multiple sources, not just IRegistry implementation: [/home/opalka][/home/opalka/THIRDPARTY/SCOUT/sources/tags]>grep -r "xmlbeans" * | grep -v "\.svn" | grep import v1.0rc1/scout/src/main/java/org/apache/ws/scout/registry/BusinessLifeCycleManagerImpl.java:import org.apache.xmlbeans.XmlObject; v1.0rc1/scout/src/main/java/org/apache/ws/scout/registry/RegistryImpl.java:import org.apache.xmlbeans.XmlCursor; v1.0rc1/scout/src/main/java/org/apache/ws/scout/registry/RegistryImpl.java:import org.apache.xmlbeans.XmlException; v1.0rc1/scout/src/main/java/org/apache/ws/scout/registry/RegistryImpl.java:import org.apache.xmlbeans.XmlObject; v1.0rc1/scout/src/main/java/org/apache/ws/scout/util/ScoutJaxrUddiHelper.java:import org.apache.xmlbeans.XmlObject; Thus it's not just about replacing the IRegistry implementation. Also ScoutJaxrUddiHelper is heavily reused in scout and there's no JVM property for replacing it with custom impl:( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195238#4195238 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195238

17 years, 4 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Upgrading Scout/JUDDI combo

by richard.opalka＠jboss.com

"tcunning" wrote : What Anil is saying sounds right for now - that AS should use the scout 0.72rc2 version, upgrade jUDDI to 2.0rc5, and we'll work on supporting JAXB so that we can move scout to the latest version. Maybe, but it doesn't work :( Scout 0.7x tries to call jUDDI methods that doesn't exist in jUDDI 2.0rc5. Here's one example: 12-08-2008 14:56:56: ERROR: Exception at: 12-08-2008 14:56:56: ERROR: java.lang.NoSuchMethodError: org.apache.juddi.datatype.tmodel.TModel.getName()Ljava/lang/String; at org.apache.ws.scout.util.ScoutUddiJaxrHelper.getConcept(ScoutUddiJaxrHelper.java:370) at org.apache.ws.scout.registry.BusinessQueryManagerImpl.getRegistryObject(BusinessQueryManagerImpl.java:739) at com.sun.ts.tests.jaxr.ee.javax_xml_registry.BusinessLifeCycleManager.JAXRClient.businessLifeCycleManager_deleteServiceBindingsTest(JAXRClient.java:1015) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.ts.lib.harness.EETest.run(EETest.java:495) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:112) at com.sun.ts.tests.common.vehicle.EmptyVehicleRunner.run(EmptyVehicleRunner.java:30) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:102) at com.sun.ts.lib.harness.EETest.getPropsReady(EETest.java:392) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:209) at com.sun.ts.lib.harness.EETest.run(EETest.java:204) at com.sun.ts.tests.common.vehicle.VehicleClient.main(VehicleClient.java:27) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.ejb3.client.ClientContainer.invokeMain(ClientContainer.java:289) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.ejb3.client.ClientLauncher.launch(ClientLauncher.java:301) at org.jboss.ejb3.client.ClientLauncher.launch(ClientLauncher.java:174) at org.jboss.ejb3.client.ClientLauncher.launch(ClientLauncher.java:138) at org.jboss.client.AppClientMain.main(AppClientMain.java:134) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195235#4195235 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195235

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1607 Update EJB3.0 Tutorials

by ALRubinger

BTW, to get this written somewhere: I've been hoping for awhile to have some self-validating documentation much like this, which accomplishes: * CI runs to ensure the examples stay up-to-date * Make the examples "live", ie runnable so a user can play around and execute tests via a webapp so see them in action So this is a step in the right direction. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195218#4195218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195218

17 years, 4 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 December 2008