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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: unit test code coverage

by jmesnil

that's interesting: the code coverage using the unit tests shows that we go through some of our JMS code. I'll check if it is not the sign of hidden dependencies to the JMS code in the core code. btw, shouldn't we take the opportunity now we've released JBM 2.0 alpha to split our source code between the core and the jms layer? If we do this split, the compiler can check that we don't introduce a dependency between from JMS to the core code quite easily. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155912#4155912 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155912

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Replacing system properties in metadata

by alesj

File a JIRA issue and I'll try to squeeze this feature in before I do MDR CR1 release. Replaceable would have an attrribute then to decide, which of the two options we use. Just need to decide which would be the default - since we mostly don't care here - so default is in order. My vote goes to 2), always liked lazy stuff. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155901#4155901 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155901

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Behavior when next state in a

by camunda

Yeah, a pattern that can be applied often and is currently under discussion with some of my "consultant colleagues" ;-) SHIL - Service Human Interaction Layer :-) As soon as I have time I will write something about it on our homepage (www.camunda.com). As Ronald described, you can just handle it in your interface. If it gets asynchronous you can even wait if a task shows up for the same user in a couple of seconds... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155893#4155893 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155893

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Behavior when next state in a

by kukeltje

Wrong forum, but close. This is a pure ui issue and has nothing to do with the core. If you develop your own ui, you could check if there is a new task for the current user in the same processinstance as the last task that was acted upon. If so, display that, if not, display the tasklist View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155857#4155857 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155857

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Public API

by genman

Removing type parameters seems like a good idea. Something to consider would be to change the Node interface to return live references, e.g. "Cache.getNode(x).getData()" would return a Map whose operations affect the in-cache state. So a "getData().clear()" would clear the node data. I'm not sure how well this would work. It may be poorly performing. I created a "Caches" utility/factory object a long time ago that created java.util.Map instances backed by JBoss Cache and it'd be interesting if something like that were endorsed. I would suggest changing the CacheLoader interface. Remove these methods: | Object put(Fqn name, Object key, Object value) throws Exception; | Object remove(Fqn fqn, Object key) throws Exception; | These are low-performing operations on many CacheLoaders implementations. Also I would remove | void put(Fqn name, Map<Object, Object> attributes) throws Exception; | and replace the put operation with: | void replaceAll(Fqn name, Map<Object, Object> attributes) throws Exception; | Remove methods that are redundant: | void loadEntireState(ObjectOutputStream os) throws Exception; | void storeEntireState(ObjectInputStream is) throws Exception; | (Though their removal is probably not critical.) Also, I'd take a look at how Hibernate uses JBoss Cache 2. It seems there's a bunch of "util" methods that might make sense to carry over. One thing that comes to mind is the use case of storing a single item in a Node. Maybe create a "key" singleton object? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155838#4155838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155838

17 years, 10 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Conflicting resource mapped/jndi-names, metadata complete is

by scott.stark＠jboss.org

One problem I'm currently seeing with the WebIntegrationUnitTestCase is that we are scanning for annotations too aggressively, for example, even when the war has a 2.4 or earlier web.xml descriptor. I supposed we should simply assume a metadata complete deployment for any web.xml 2.4 or earlier. The other problem that shows up because of this is that its very easy for mappedName collisions. Unlike the ejb component model where the enc is component local, the web component enc annotations are affecting the common web application enc. I can see its very easy for resources to be locally defined on a servlet and collide with annotations coming from the xml layer. Currently the annotation mappedNames are overwriting any existing xml metadata jndi-name/mapped-names without warning. In the case of the WebIntegrationUnitTestCase the annotations should not be processed and doing so does end up resulting in failures. http://jira.jboss.com/jira/browse/JBAS-5586 is for the metadata complete behavior. Need to look into what appears to be a bug with an annotation mappedName overwriting an xml jndi-name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155836#4155836 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155836

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5578 ServiceMBeanSupport as MC bean

by bstansberry＠jboss.com

The changes you made resolved the problem I was seeing -- failing org.jboss.test.cluster.defaultcfg.test.HASingletonElectionPolicyUnitTestCase. I also see the HASingletonController for the HASingletonDeploymentScanner bean now properly starts the singleton (although the scanner doesn't work correctly -- unrelated issue). I saw a couple regressions from this: 1) HAPartitionStateTransferTestCase has some failures. This is because the test fixture overrides ServiceMBeanSupport.start() and caches a ref to any exception thrown. Your addition of @Start public void pojoStart() means an exception thrown in startService() no longer propagates through start(). I changed the fixture to override startService() instead of start() (which is more correct anyway) and the test works fine. 2) PartitionRestartUnitTestCase now fails. I don't see anything wrong with the way ServiceMBeanSupport is working in this test; its a UnifiedInvoker/Remoting issue. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136822. It's not clear to me why this test started failing now, other than that perhaps ServiceMBeanSupport wasn't working properly before and was masking the remoting issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155822#4155822 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155822

17 years, 10 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Ability to restart a Connect with SocketServerInvoker

by bstansberry＠jboss.com

I'm seeing some issues with an AS clustering test that attempts to restart (ie. deploy, then stop(), then start()) a bunch of services. They tie back to restarting an instance of UnifiedInvoker and how it interacts the Remoting classes. Problem occurs when trying to start a UnifiedInvoker that has previously been deployed: | 2008-06-04 12:33:00,382 DEBUG [org.jboss.invocation.unified.server.UnifiedInvokerHA] (RMI TCP Connection(31)-127.0.0.1) Starting failed jboss:service=invoker,type=unifiedha,partitionName=RestartPartition | java.lang.IllegalArgumentException: Illegal cache capacities | at org.jboss.util.LRUCachePolicy.<init>(LRUCachePolicy.java:77) | at org.jboss.remoting.transport.socket.LRUPool.<init>(LRUPool.java:44) | at org.jboss.remoting.transport.socket.SocketServerInvoker.start(SocketServerInvoker.java:231) | at org.jboss.invocation.unified.server.UnifiedInvoker.startService(UnifiedInvoker.java:140) | at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376) | at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:322) | at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) Looking into this I've found a couple things: 1) The UnifiedInvoker stopService() method has this: | public void stopService() throws Exception | { | if(serverInvoker != null) | { | serverInvoker.stop(); | } | } That seems broken. The UnifiedInvoker is handed back a ref to the serverInvoker when it registers itself with the connector as a ServerInvocationHandler. AFAICT, that serverInvoker belongs to the Connector, and any other registered handlers will also have a ref to it. So UnifiedInvoker should not be stopping it; the stop of one handler shouldn't affect the other handlers. 2) Seems SocketServerInvoker can't be restarted. If you call stop(), it calls cleanup(), which does this: maxPoolSize = 0; // so ServerThreads don't reinsert themselves Thereafter, if you call start(), the max pool size will be less than the min pool size, leading to the exception shown above. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155802#4155802 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155802

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Behavior when next state in a "job" is the same swimlane

by woo37830

I can't tell from the documentation how to change the default behavior for handling the next state being for the same swimlane in a process. To explain, I as the "initiator" do step1 filling in some information. The next step(step2) is for a user in the role of "mgr". If they select one transition, the next step(step3) will be for the iniator to handle. However, a different transition would be for the "mgr" to add additional information in step4. It would seem that the process would be queued for someone acting in the role of "mgr", but would automatically show the next screen for step4 to the user who is currently logged in with the role of "mgr". I.e. they would not "have" to select the next step from a tasklist. They could choose to cancel step4 and leave it in the queue, but the default would be to present it. The reason is that there might be several "step4" processes queued. They would like, by default, to continue on the one they were processing. Is this available in the design? Is it prohibited because of pessimistic locking or is optimistic locking used? Thanks, View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155798#4155798 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155798

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Metadata view with system properties resolved

by bstansberry＠jboss.com

Anyone reading this thread, see also http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136805 for a discussion on how to implement such a view for an annotation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155786#4155786 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155786

17 years, 10 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 June 2008