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

[Design of JBossCache] - Re: TxInterceptor logging of exceptions

by manik.surtani＠jboss.com

anonymous wrote : | | 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. | Agreed. Unless we intend to NOT throw the exception (failSilently is present) we should not log the exception. anonymous wrote : | | 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. | +1 as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008387#4008387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008387

17 years, 11 months

1
0
0 / 0

[Design of JBossCache] - Re: JBCACHE-957 Discussion Thread

by manik.surtani＠jboss.com

While this is an interesting idea, and will very cleanly encapsulate the decision around the type of lock acquired based on: 1) Locking Scheme (opt or pess) 2) Operation (readdata, writedata, deletedata, readchild, createchild, deletechild for PL, readIntoWorkspace, writeFromWorkspace for OL) 3) State of the LockParentForChildInsertRemove param. I'm a bit concerned about getting this into 2.0.0.B1. If anything, this will be a B2 feature, but I am really concerned with feature creep in 2.0.0. Anyone has the spare cycles for this? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008386#4008386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008386

17 years, 11 months

1
0
0 / 0

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

by bstansberry＠jboss.com

Can we solve the XPC issue with something along these lines? 1) XPC is stored in the parent bean context. 2) Child beans have an independent lifecycle (i.e. bean instance is cached with the context, not in an internal data structure of the parent. Child bean context stores data about location of parent, and vice versa. 3) When nested bean is invoked, interceptor accesses the parent bean, gets the XPC and injects it into the nested bean instance. On the way out clear the XPC ref from the nested bean. I.e. don't try to maintain a shared ref to XPC across serialization; instead cache it in the parent and inject it into the child as needed. 4) As part of remove process, check if the bean is a parent. If so, check if any children are still alive. If yes, don't remove context from the cache; instead set a removed flag in the context. If removed flag is set an interceptor will not allow any call to the context (throw NoSuchEjbException). But the context is still cached, so child beans can find the XPC. 5) As part of remove process, check if bean is a child. If so, have parent re-check if all its children are still alive. If not, parent context can be removed. Along with this, in general it would be good to have a background thread that runs to check for and remove orphaned beans. But that's true regardless of the value of the above. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008363#4008363 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008363

17 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Bug in Sun compiler?

by bkeh12

Sorry I post there. types = [class.java.lang.string, int] generic = [] Exception in thread "main" java.lang.RuntimeException: They should be the same? my config fedora5 + NetBeans 5.5 + jdk 6 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008334#4008334 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008334

17 years, 11 months

1
0
0 / 0

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

by alesj

anonymous wrote : | There already is an AnnotationInfo. Doesn't the inherrited TypeInfo.convertValue(Object value, boolean replaceProperties) come into play? | | If we wanted to use this, it probably means that we should push the replace param with the current Annotation creation: | ann = (Annotation) AnnotationCreator.createAnnotation(annString, Thread.currentThread().getContextClassLoader()); | But I don't see any easy way to call AnnotationInfo.convertValue(Object, boolean). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008325#4008325 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008325

17 years, 11 months

1
0
0 / 0

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

by david.lloyd＠jboss.com

Yes, and to be clear, here are the attributes that you can have on a transitionButton: * value: This is the caption of the button. If none is given, the transition name is given. * transition: This is the transition to take. (Up above I said it was called "to" - my apologies for the confusion). * src: The URL of an image file, if you want to override the little icon. Sensible defaults are automatically chosen for task form buttons. * All default h:commandButton attributes (except for "action"), which can be found here: http://java.sun.com/javaee/javaserverfaces/1.2/docs/tlddocs/h/commandButt... You may also have these attributes (except for "transition") on the saveButton. I think it would be wise for the GPD to not emit cancelButtons, since the cancel button does not serve any purpose that cannot be also done with a plain <h:commandButton>. Finally, the GPD should no longer generate a "comments" field by default. This field is already present elsewhere on the task view page. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008323#4008323 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008323

17 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Process definition element label attribute

by kukeltje

The variable declarations have their advantage in the GPD, but also in the webservice. It would be possible to generate xsd's with the correct types for setting variables in certain states/nodes/tasks. Now, there is not type checking other than manualy generating an XSD and using XSD validation. Regarding the generation, seam form generation does a nice job. They are kind of similar to the jbpm forms. The FTL templates that are used use the type to generate correct input types, which is nice. Using FTL for the jBPM forms would be cool and in line with using similar frameworks for similar things across multiple jboss projects. If I find time (lots of experimenting with seam now) I'll have a look at the id/ref stuff. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008318#4008318 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008318

17 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Bug in Sun compiler?

by adrian＠jboss.org

I found this while looking at a microcontainer test. It fails in both JDK5 and JDK6, but works with eclipse. Looks like a bug to me? Anybody confirm? | package test; | | import java.lang.reflect.Constructor; | import java.lang.reflect.Type; | import java.util.Arrays; | | public class Main | { | public static void main(String[] args) throws Exception | { | Class<MyEnum> clazz = MyEnum.class; | Constructor<MyEnum> constructor = clazz.getDeclaredConstructor(new Class[] { String.class, Integer.TYPE }); | Type[] types = constructor.getParameterTypes(); | Type[] generic = constructor.getGenericParameterTypes(); | System.out.println("types = " + Arrays.asList(types)); | System.out.println("generic = " + Arrays.asList(generic)); | if (Arrays.equals(types, generic) == false) | throw new RuntimeException("They should be the same?"); | } | | public enum MyEnum { ONE, TWO, THREE }; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008317#4008317 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008317

17 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Web console changes - IMPORTANT

by david.lloyd＠jboss.com

"tom.baeyens(a)jboss.com" wrote : Did you have a look at facelets composition, fragment, include and insert ? Ah, yes that is correct. The task form itself could include <ui:fragment> around the body in order to trim outside of the tags. I thought you were talking about something in the facelets API. So yes, a task form could look like this: | <jbpm:dataform xmlns="http://www.w3.org/1999/xhtml" | xmlns:ui="http://java.sun.com/jsf/facelets" | xmlns:c="http://java.sun.com/jstl/core" | xmlns:h="http://java.sun.com/jsf/html" | xmlns:f="http://java.sun.com/jsf/core" | xmlns:tf="http://jbpm.org/jsf/tf" | xmlns:jbpm="http://jbpm.org/jsf"> | | <f:facet name="header"> | <h:outputText value="#{taskName}"/> | </f:facet> | |  | <jbpm:datacell> | <f:facet name="header"> | <h:outputText value="Payment ID:"/> | </f:facet> | <h:inputText value="#{var['paymentId']}"/> | </jbpm:datacell> | <jbpm:datacell> | <f:facet name="header"> | <h:outputText value="Actions:"/> | </f:facet> |  | <tf:saveButton value="Save"/> | <tf:transitionButton value="Update Books"/> | </jbpm:datacell> | | </jbpm:dataform> | Or if this: | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" > | |  | <html xmlns="http://www.w3.org/1999/xhtml" | xmlns:ui="http://java.sun.com/jsf/facelets" | xmlns:c="http://java.sun.com/jstl/core" | xmlns:h="http://java.sun.com/jsf/html" | xmlns:f="http://java.sun.com/jsf/core" | xmlns:tf="http://jbpm.org/jsf/tf" | xmlns:jbpm="http://jbpm.org/jsf"> | <ui:fragment> | | <jbpm:dataform> | <f:facet name="header"> | <h:outputText value="#{taskName}"/> | </f:facet> | |  | <jbpm:datacell> | <f:facet name="header"> | <h:outputText value="Payment ID:"/> | </f:facet> | <h:inputText value="#{var['paymentId']}"/> | </jbpm:datacell> | <jbpm:datacell> | <f:facet name="header"> | <h:outputText value="Actions:"/> | </f:facet> |  | <tf:saveButton value="Save"/> | <tf:transitionButton value="Update Books"/> | </jbpm:datacell> | | </jbpm:dataform> | </ui:fragment> | </html> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008312#4008312 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008312

17 years, 11 months

1
0
0 / 0

[Design of JBoss Portal] - Re: DB test matrix

by prabhat.jha＠jboss.com

Yes, I saw that error right after test was finished. I have corrected it. I will force a CC run early today so that we don't have to wait to see something else is broken. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008294#4008294 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008294

17 years, 11 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