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

[Design of JBoss Web Services] - RI tools dependency

by heiko.braun＠jboss.com

I introduced a dependency on the RI tools in order to create the interop artifacts. The main reasons for this are: - We need to be more flexible when facing the next plug-fest - Having a pluggable tools layer within the test suite means that we can easily verify our own JAX-WS tools codebase at some later point in time - We do verify that our stack really works with the JAX-WS artifacts that the RI tools generate Currently this requires a now build property to be set | # | # JAX-WS Home | # The testsuite requires the RI tools to generate the artifacts | # NOTE: Don't use the JWSDP 2.0, it contains legacy API. | # Use the RI codebase from java.net instead: | # https://jax-ws.dev.java.net/jax-ws-20-fcs/ | # | ri.home=/home/hbraun/dev/env/jaxws-ri_2.0 | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008171#4008171 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008171

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Issues with passivation of nested SFSBs

by wolfc

I say we should not attach lifecycle from one SFSB to another. You don't know where a reference ends up and I can always come up with a scenario in which it breaks (we haven't even covered handles yet). The bean developer should be responsible for both parent and child lifecycle. We can always have orphaned SFSB, because that's the nature of the beast. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008165#4008165 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008165

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: web console problem

by koen.aers＠jboss.com

"david.lloyd(a)jboss.com" wrote : Koen, is it possible to modify the GPD so that if there is only one transition, that the "to" attribute is not emitted? | As Tom stated, this has nothing to do with the 'to' attribute of the transition which is a mandatory attribute. I will revisit the task form generation shortly. I assume you guys want the following: - if there is no name on the transition, do nothing - if there is a name, use the name - offer the possibility to override in both cases Is this correct? Regards, Koen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008157#4008157 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008157

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - TxInterceptor logging of exceptions

by bstansberry＠jboss.com

TxInterceptor catches all exceptions that come up from lower in the interceptor chain, logs them at INFO, and then rethrows the exception if there isn't a failSilently option set. 1) Why log at all if the exception is going to be rethrown? The log doesn't indicate any action on the part of the interceptor. Eviction now uses a 0 ms timeout, so a lot of those timeouts could end up getting logged. 2) If failSilently is set, a stack trace in the log at INFO doesn't seem very silent. People freak at stack traces no matter what level. At a minimum I think any INFO logging should be just the message, with a stack trace only at DEBUG or TRACE. But with Hibernate's usage, I think these are going to be too frequent for INFO. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008144#4008144 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008144

17 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Two more ESB packaging options.

by kurt.stam＠jboss.com

In the product/install directory on the trunk we now have two more packaging options. Besides deploying to JBossAS, you can now create a standalone launcher or deploy as a war to tomcat. I'd love if people could give this a spin and provide some feedback. For standalone launching read the README in install/launcher, for deploying to tomcat read the README in install/tomcat. Thanks! --Kurt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008119#4008119 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008119

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Can't deploy processdefinition from GPD into jBPM 3.2 -

by jeffdelong

Koen, Thanks, I will test this combo out. Jeff View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008114#4008114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008114

17 years, 4 months

1
0
0 / 0

[Design of JBossCache] - JBCACHE-957 Discussion Thread

by bstansberry＠jboss.com

Discussions related to http://jira.jboss.com/jira/browse/JBCACHE-957 -- Allow per-node configuration of LockParentForChildInsertRemove. Elias Ross had a good suggestion on this: anonymous wrote : | The Node itself keeps a NodeLock instance. Perhaps the specific choice of lock (read-write) could be delegated to the NodeLock itself? | | In particular, for the method: | | boolean acquire(Object caller, long timeout, NodeLock.LockType lock_type); | | it might make sense to replace the LockType parameter with an operation parameter? E.g. | | boolean acquire(Object caller, long timeout, NodeLock.Operation op); | | Then there needs to be some way to set the particular strategy per node. It's theoretically possible, but there needs to be a standard API to expose this. E.g. | | void setLockStrategy( ... ); | | With this in mind, the NodeLock interface should get revisited in time for 2.0. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008104#4008104 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008104

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover possible dead lock

by clebert.suconic＠jboss.com

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

17 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Property replacement

by scott.stark＠jboss.org

In terms of the current schema, its just a different type of element that would need to be treated separately as the AnnotationMetaData does not have a natural string representation outside of the annotation attribute values. We would have to make this a richer type of element with more of a javabean type of property/value structure, but the allowed values are more restricted. There already is an AnnotationInfo. Doesn't the inherrited TypeInfo.convertValue(Object value, boolean replaceProperties) come into play? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008095#4008095 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008095

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failover possible dead lock

by clebert.suconic＠jboss.com

"Tim Fox" wrote : I don't think this is a deadlock - deadlock implies a race for two exclusive locks: Well.. I know technical name wouldn't be dead lock... But you will still be waiting forever on a writeLock, that will never occur. (you're dead anyway :-) ) I guess I could call Failover to notify the receive thread.. yes... but I just don't think it would be a good solution. The way it works now, we only start failure detection after we close the valve. We can't close the valve if there is an invocation pending. I would prefer using the Valve only on places where a server communication is needed. On that case we don't have a problem as we will aways get an IOException or a CannotConnectException when the server dies. A receive is only waiting on an internal buffer and I don't see any problems on letting it wait Callback to be re-established and feed the buffer again after failover. I have talked to Ovidiu by IM, and he thinks it would make sense to use the Valve only on places where an IO to the server is being performed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008084#4008084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008084

17 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2007