[JBoss JIRA] Created: (JBFORUMS-262) Empty post error displays MessageValidationException
by Luc Boudreau (JIRA)
Empty post error displays MessageValidationException
----------------------------------------------------
Key: JBFORUMS-262
URL: http://jira.jboss.com/jira/browse/JBFORUMS-262
Project: JBoss Forums
Issue Type: Bug
Components: Forum View Layer
Affects Versions: 1.0.1 RC
Environment: Any
Reporter: Luc Boudreau
Assigned To: Ryszard Kozmik
Priority: Critical
Try to create a post, don't write anything as a subject or a body and press submit. The error message is totally useless.
Message : org.jboss.portlet.forums.ui.action.MessageValidationException. Please try again
Stack :
2007-11-05 15:41:35,075 ERROR [org.jboss.portlet.forums.ui.JSFUtil] org.jboss.po
rtlet.forums.ui.JSFUtil
org.jboss.portlet.forums.ui.action.MessageValidationException
at org.jboss.portlet.forums.ui.action.PostAction.validateMessage(PostAct
ion.java:561)
at org.jboss.portlet.forums.ui.action.NewTopic.execute(NewTopic.java:118
)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.el.parser.AstValue.invoke(AstValue.java:130)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:274)
at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.ja
va:68)
at com.sun.facelets.el.LegacyMethodBinding.invoke(LegacyMethodBinding.ja
va:69)
at org.apache.myfaces.application.ActionListenerImpl.processAction(Actio
nListenerImpl.java:63)
at org.jboss.portlet.forums.auth.AuthorizationListener.processAction(Aut
horizationListener.java:101)
at javax.faces.component.UICommand.broadcast(UICommand.java:106)
at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:9
0)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1
64)
at org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(Lifecycl
eImpl.java:316)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java
:86)
at org.jboss.portlet.forums.ui.ForumsJSFPortlet.processAction(ForumsJSFP
ortlet.java:281)
at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.invokeActio
n(PortletContainerImpl.java:458)
at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl.dispatch(Po
rtletContainerImpl.java:401)
at org.jboss.portal.portlet.container.PortletContainerInvoker$1.invoke(P
ortletContainerInvoker.java:86)
at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.j
ava:131)
at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jbos
s$portal$core$aspects$portlet$TransactionInterceptor$invokeRequired$aop(Transact
ionInterceptor.java:106)
at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRe
quired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103
964459766407072.java)
at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java
:195)
at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeRe
quired_9103964459766407072.invokeNext(TransactionInterceptor$invokeRequired_9103
964459766407072.java)
at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java
:195)
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBAS-4455) LoadBalancePolicy that tries to pin all requests associated with a tx to one server
by Brian Stansberry (JIRA)
LoadBalancePolicy that tries to pin all requests associated with a tx to one server
-----------------------------------------------------------------------------------
Key: JBAS-4455
URL: http://jira.jboss.com/jira/browse/JBAS-4455
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Galder Zamarreno
Priority: Minor
The HA proxies don't allow failover once a tx has reached a server. This can lead to this kind of situation:
EJB A deployed on nodes 1 and 2.
EJB B deployed on nodes 1 and 2.
1) Start tx, invoke on A.1.
2) Lookup B.
3) Invoke on B. LB policy picks B.2
4) Node 2 is dead for some reason so call fails.
5) Can't fail over because tx context won't allow a failover after a call has reached a server.
But, B.1 is fine and is running on the only node the tx has invoked on. :(
Approach to improving this. This is based on JRMPInovkerProxyHA methods, but the idea is generic:
In invocationHasReachedAServer, instead of storing null as the value, you store the target (key is the tx).
In invoke, if there's a tx, you add that target (if there is one) to the invocation as transient metadata
The LB policy gets passed the invocation as an arg when it chooses a target (this is already in the API)
LB policy checks for the metadata. If there, and that target is in its target list, return that target
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBCACHE-1215) NullEvictionPolicy
by Brian Stansberry (JIRA)
NullEvictionPolicy
------------------
Key: JBCACHE-1215
URL: http://jira.jboss.com/jira/browse/JBCACHE-1215
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Minor
An eviction policy that allows returns 'true' to EvictionPolicy.canIgnoreEvent(). Other methods are no-ops or equivalent defaults.
Use case is situations where there are multiple eviction regions in a cache, some of which should never evict anything. You could use an LRUPolicy with maxAge=0, maxNodes=0 to accomplish a similar thing, but then you incur wasted overhead of generating, queuing up and processing node events. NullEvictionPolicy just bypasses everything.
Some usages:
Hibernate timestamp caching. The timestamp region should never be evicted.
HttpSession caching with FIELD. I'll probably need to use JBC eviction for the JBossInternal_ area to passivate pojos. But passivating the sessions themselves should not be managed by JBC. So I could use NullEvictionPolicy for the session storage area.
Could also be inserted as a global default if JBC detects that the _default_ region wasn't configured while a subregion was.
I coded this up one night a while ago and forgot about it. Could be added to 2.1.0.GA if not too late; otherwise later.
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBRULES-1354) Duplicate parameter while trying to use pattern bound variables or globals in accumulate function
by Eric Miles (JIRA)
Duplicate parameter while trying to use pattern bound variables or globals in accumulate function
-------------------------------------------------------------------------------------------------
Key: JBRULES-1354
URL: http://jira.jboss.com/jira/browse/JBRULES-1354
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.3
Environment: JDK 1.5.0_13, Ubuntu 7.10
Reporter: Eric Miles
Whenever I attempt to reference a pattern bound variable (declared outside of accumulate) or a global from within an accumulate function, I get a "Duplicate parameter" error.
Example of pattern bound variable:
rule "Test"
when
$obj: SomeObject()
Integer() from accumulate( AnotherObject() , init (int total = 0 ), action ( total += $obj.getValue(); ), reverse ( total -= $obj.getValue(); ), result ( total) )
then
System.out.println("HI!");
end
The same happens when if I attempt to use a global. Here is an exact stacktrace of the error:
org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule
name=Daily Core Hours, agendaGroup=MAIN, salience=0, no-loop=false]
com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java
(32:1301) : Duplicate parameter $schedOut
com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java
(32:1330) : Duplicate parameter $schedIn
com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java
(41:1735) : Duplicate parameter $schedOut
com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java
(41:1764) : Duplicate parameter $schedIn
com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java
(51:2330) : Duplicate parameter $schedOut
com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java
(51:2359) : Duplicate parameter $schedIn
com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java
(58:2738) : Duplicate parameter $schedOut
com/kronos/webta/service/smarttime/rules/Rule_Daily_Core_Hours_0.java
(58:2767) : Duplicate parameter $schedIn
at org.drools.rule.Package.checkValidity(Package.java:424)
at
org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:364)
at
com.kronos.webta.service.smarttime.rules.maxiflex.FlowTest.setUpBeforeClass(FlowTest.java:79)
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.junit.internal.runners.ClassRoadie.runBefores(ClassRoadie.java:49)
at
org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:36)
at
org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBAS-5097) MessageDestinationReferenceMetaData produced by merge of annotation and xml loses information
by Scott M Stark (JIRA)
MessageDestinationReferenceMetaData produced by merge of annotation and xml loses information
---------------------------------------------------------------------------------------------
Key: JBAS-5097
URL: http://jira.jboss.com/jira/browse/JBAS-5097
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services
Reporter: Scott M Stark
Assigned To: Scott M Stark
Fix For: JBossAS-5.0.0.CR1
ejb-jar.xml:
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
<enterprise-beans>
<message-driven>
<ejb-name>DestBean</ejb-name>
<message-destination-type>javax.jms.Queue</message-destination-type>
<message-destination-link>two_ejb.jar#MsgBeanInQueue</message-destination-link>
<message-destination-ref>
<description>test destination</description>
<message-destination-ref-name>replyQueue</message-destination-ref-name> <message-destination-type>javax.jms.Queue</message-destination-type>
<message-destination-usage>Produces</message-destination-usage>
<message-destination-link>two_ejb.jar#MsgBeanOutQueue</message-destination-link>
</message-destination-ref>
</message-driven>
</enterprise-beans>
</ejb-jar>
with an annotated mdb like:
@MessageDriven(name="DestBean")
public class DestBean
extends DestBeanBase
implements MessageListener
{
@Resource(name="mdc")
private MessageDrivenContext mdc;
public DestBean()
{
super();
}
public EJBContext getEJBContext() {
return this.mdc;
}
}
abstract public class DestBeanBase
{
public static final String test1 = "test1";
abstract public javax.ejb.EJBContext getEJBContext();
@Resource(name="qFactory")
private QueueConnectionFactory qFactory;
@Resource(name="replyQueue")
private Queue replyQueue;
public void onMessage(javax.jms.Message msg) {...}
}
Is producing a MessageDestinationReferenceMetaData that is missing much of the ejb-jar.xml information:
MessageDestinationReferenceMetaData{
descriptions DescriptionsImpl (id=7741)
id null
ignoreDependency null
injectionTargets Collections$SingletonSet<E> (id=7708)
link null
mappedName null
name "replyQueue"
resolvedJndiName null
type "javax.jms.Queue"
usage null
}
The merge of the annotation metadata with the descriptor metadata is losing information.
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBBUILD-324) Build.xml in testsuite directory doesn't support multiple JVM argument
by Sunny Chan (JIRA)
Build.xml in testsuite directory doesn't support multiple JVM argument
----------------------------------------------------------------------
Key: JBBUILD-324
URL: http://jira.jboss.com/jira/browse/JBBUILD-324
Project: JBoss Build System
Issue Type: Feature Request
Components: Targets and Tasks
Affects Versions: Repository Build head, Repsository Build Branch_4_0
Environment: Any
Reporter: Sunny Chan
Priority: Minor
We are using the JBoss unit test as part of our JVM verification testsuite. We wanted to be able to invoke tests with multiple JVM options, but it didn't work. If you set parameters via build.sh -Djunit.vm.options with multiple paramters (e.g. -Djunit.vm.options="-d64 -verbose:gc"), it will fail with unrecongized option error.
The problem is that in testsuite/build.xml, the junit.vm.options is passed onto junit ant task via <jvmarg value> tag rather then <jvmarg line> tag. The jvmarg line allows multiple JVM options exist in one line. Once I replace all instance of <jvmarg value="${junit.jvm.options}"/> with <jvmarg line="${junit.jvm.options}"/> then the problem goes away.
I can provide a patch for this if you want - but I don't know the rules on patches (whether I need to be cleared for contribution) so let me know if you want that.
--
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
18 years, 6 months
[JBoss JIRA] Created: (JBAOP-497) ClassNotFoundException on JBoss 5
by Flavia Rainone (JIRA)
ClassNotFoundException on JBoss 5
---------------------------------
Key: JBAOP-497
URL: http://jira.jboss.com/jira/browse/JBAOP-497
Project: JBoss AOP
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.CR2
Reporter: Flavia Rainone
Fix For: 2.0.0.GA
JBoss AOP is generating several ClassNotFoundExceptions during JBoss 5 startup.
This happens when JBoss AOP tries to load annotation classes.
An example of a stack trace is:
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.<init>(Throwable.java:218)
at java.lang.Exception.<init>(Exception.java:59)
at
java.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:65)
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at
java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:891)
at java.lang.ClassLoader.loadClass(ClassLoader.java:301)
- locked <0x91ea0d38> (a sun.misc.Launcher$ExtClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
- locked <0x91ea0cf0> (a sun.misc.Launcher$AppClassLoader)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
- locked <0x91ea0cf0> (a sun.misc.Launcher$AppClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
- locked <0x91ea0d80> (a
org.jboss.system.NoAnnotationURLClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
- locked <0x91e9da68> (a
org.jboss.system.NoAnnotationURLClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.jboss.aop.Advisor.hasJoinPointAnnotationFromStringName(Advisor.java:615)
at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:533)
at org.jboss.aop.Advisor.hasAnnotation(Advisor.java:512)
at
org.jboss.aop.pointcut.MethodMatcher.matchesIdentifier(MethodMatcher.java:309)
at
org.jboss.aop.pointcut.MethodMatcher.matches(MethodMatcher.java:106)
at
org.jboss.aop.pointcut.MethodMatcher.visit(MethodMatcher.java:99)
at
org.jboss.aop.pointcut.ast.ASTMethod.jjtAccept(ASTMethod.java:43)
at
org.jboss.aop.pointcut.ExecutionMethodMatcher.visit(ExecutionMethodMatcher.java:58)
at
org.jboss.aop.pointcut.ast.ASTExecution.jjtAccept(ASTExecution.java:37)
at
org.jboss.aop.pointcut.MatcherHelper.visit(MatcherHelper.java:89)
at
org.jboss.aop.pointcut.MatcherHelper.matches(MatcherHelper.java:83)
at
org.jboss.aop.pointcut.PointcutExpression.matchesExecution(PointcutExpression.java:119)
at org.jboss.aop.Advisor.resolveMethodPointcut(Advisor.java:887)
at
org.jboss.aop.ClassContainer.createInterceptorChains(ClassContainer.java:261)
- locked <0xb0127790> (a java.util.LinkedHashMap)
at
org.jboss.aop.ClassContainer.rebuildInterceptors(ClassContainer.java:130)
at
org.jboss.aop.ClassContainer.initializeClassContainer(ClassContainer.java:66)
at
org.jboss.aop.proxy.container.ClassProxyContainer.initialise(ClassProxyContainer.java:172)
at
org.jboss.aop.proxy.container.InstanceProxyContainer.<init>(InstanceProxyContainer.java:56)
at
org.jboss.aop.proxy.container.InstanceProxyContainer.createInstanceProxyContainer(InstanceProxyContainer.java:68)
at
org.jboss.aop.proxy.container.ContainerCache.initInstanceContainer(ContainerCache.java:277)
at
org.jboss.aop.proxy.container.ContainerCache.initialise(ContainerCache.java:93)
- locked <0x91ee4b60> (a java.lang.Object)
at
org.jboss.aop.proxy.container.ContainerCache.initialise(ContainerCache.java:72)
at
org.jboss.aop.microcontainer.integration.AOPDependencyBuilder.getDependencies(AOPDependencyBuilder.java:97)
- locked <0x91ee4b60> (a java.lang.Object)
at
org.jboss.classadapter.plugins.BasicClassAdapter.getDependencies(BasicClassAdapter.java:80)
at
org.jboss.beans.info.plugins.AbstractBeanInfo.getDependencies(AbstractBeanInfo.java:211)
To reproduce the failure, generating one or more thread dumps during server boot is enough.
--
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
18 years, 6 months