[JBoss JIRA] Created: (JBAS-4494) Error handling
by Adrian Brock (JIRA)
Error handling
---------------
Key: JBAS-4494
URL: http://jira.jboss.com/jira/browse/JBAS-4494
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Adrian Brock
As per the parent task, the error handling for the DateEditor is not handling null values correctly.
public void setValue(Object value)
{
if (value instanceof Date)
{
text = null;
super.setValue(value);
}
else
{
throw new IllegalArgumentException("setValue() expected java.util.Date value, got "
+ value.getClass().getName());
}
}
There needs to be an initial
if (value == null)
throw new IllegalArgumentException("Null value for setValue() expected java.util.Date");
or alternatively (since the javadocs don't disallow null values)
if (value == null)
return null;
The other property editors need checking for the same problem.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 1 month
[JBoss JIRA] Created: (JBPORTAL-1482) portal 2.6 and jboss 4.2.GA - CNFE for edu.emor.mathcs.backport.java.util.concurrent.locks.Lock
by Prabhat Jha (JIRA)
portal 2.6 and jboss 4.2.GA - CNFE for edu.emor.mathcs.backport.java.util.concurrent.locks.Lock
-----------------------------------------------------------------------------------------------
Key: JBPORTAL-1482
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1482
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Core
Affects Versions: 2.6 Final
Reporter: Prabhat Jha
Assigned To: Julien Viet
Priority: Critical
Fix For: 2.6 Final
Built portal trunk with jdk1.4 and tried to deploy jboss-portal.sar with JBoss AS 4.2.0.GA. Good thing is that I did not see any java versioning issue which I remember seeing earlier. The first error I see is java.lang.NoClassDefFoundError: edu/emory/mathcs/backport/java/util/concurrent/locks/Lock. Thomas had posted some comment about this in forum. Fix is to copy appropriate jar in lib but I am not sure why it's not included in in jboss4.2.0 by default. I think we need to have this in jboss-portal.sar/lib.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 1 month
[JBoss JIRA] Updated: (JBPM-426) enable jpdl schema extension via namespaces
by Ronald van Kuijk (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-426?page=all ]
Ronald van Kuijk updated JBPM-426:
----------------------------------
Fix Version/s: jBPM 3.3
Affects Version/s: jBPM jPDL 3.2
jBPM 3.1
(was: jBPM 3.3)
> enable jpdl schema extension via namespaces
> -------------------------------------------
>
> Key: JBPM-426
> URL: http://jira.jboss.com/jira/browse/JBPM-426
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Core Engine
> Affects Versions: jBPM 3.1, jBPM jPDL 3.2
> Reporter: Martin Dirichs
> Assigned To: Tom Baeyens
> Fix For: jBPM 3.3
>
>
> Customizing jpdl elements in a process definition via application-specific XML-elements is currently only possible outside of any schema validation. XML namespaces are the canonical way to allow for the extension of jpdl so that configuration data of delegation classes may be defined within an application-specific namespace and associated XML schema. In particular, this would be necessary to enable customization of jpdl elements
> - action
> - assignment
> - handler
> - controller
> - task
> Bug #JBPM-332:
> http://jira.jboss.com/jira/browse/JBPM-332
> is somewhat related to this issue. However, resolution of JBPM-332
> - only allows for arbitrary elements to appear inside jpdl files (without schema validation)
> - and only for customizing assignments (leaving out action, handler, controller and task).
> Implementation of this feature request would be done via a more intelligent version of an EntityResolver (defined in org.jbpm.jpdl.xml.SchemaValidationHandle) that can return application specific schemas in addition to the default one for jpdl.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 1 month
[JBoss JIRA] Created: (JGRP-527) MuxChannel stuck
by Bela Ban (JIRA)
MuxChannel stuck
----------------
Key: JGRP-527
URL: http://jira.jboss.com/jira/browse/JGRP-527
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.5
[from Bryce Alcock]
JGroups Users:
I am getting what appears to me on the surface to be a dead lock.
Here is the stack trace:
"***************BLA-STUCK THREAD**********************" prio=1 tid=0x08448ed8 nid=0x78dc in Object.wait() [0xb0c10000..0
xb0c110b0]
at java.lang.Object.wait(Native Method)
- waiting on <0x88f500c8> (a org.jgroups.util.Promise)
at org.jgroups.util.Promise.doWait(Promise.java:104)
at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:60)
at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:28)
- locked <0x88f500c8> (a org.jgroups.util.Promise)
at org.jgroups.mux.Multiplexer.fetchServiceInformation(Multiplexer.java:196)
at org.jgroups.JChannelFactory.connect(JChannelFactory.java:355)
- locked <0x88f37fe0> (a org.jgroups.JChannelFactory$Entry)
at org.jgroups.mux.MuxChannel.connect(MuxChannel.java:126)
- locked <0x88f63740> (a org.jgroups.mux.MuxChannel)
at scheduledtaskexecuteframework.group.GenericMultiplexer.connect(GenericMultiplexer.java:83)
at scheduledtaskexecuteframework.schedule.test.MainTest$1.run(MainTest.java:60)
i?
The Senarios is easily reproduced in my system:
I have 2 members of a MuxChannel join and do some work.
I then have a 3rd join.
then I have the second member quit.
wait about 5 mins and have the second member join.
the second member will get stuck like this.
However,
If I dont have the 3rd member join, and just have the second member leave wait five mins and come back
things work fine every time.
here is the line of code that is both holding the mutex and asking for it (apperently in different threads)
byte[] state=(byte[])service_state_promise.getResultWithTimeout(2000);
I am more then willing to give more details about the situation, however,
I am looking for Ideas on how to debug this.
I am using java 1.5.0_11
I am using JGroups-2.4.1-sp3
Bryce
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 1 month