[JBoss JIRA] Updated: (JBPORTAL-859) Support portlet which use GET method in forms.
by Chris Laprun (JIRA)
[ http://jira.jboss.com/jira/browse/JBPORTAL-859?page=all ]
Chris Laprun updated JBPORTAL-859:
----------------------------------
Summary: Support portlet which use GET method in forms. (was: Suport portlet which use GET method in forms.)
> Support portlet which use GET method in forms.
> ----------------------------------------------
>
> Key: JBPORTAL-859
> URL: http://jira.jboss.com/jira/browse/JBPORTAL-859
> Project: JBoss Portal
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Portal WSRP
> Affects Versions: 2.4 Final
> Reporter: Chris Laprun
> Assigned To: Chris Laprun
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> We probably need to add an element similar to remotable to the jboss portlet descriptors...
> From WSRP spec (10.2.4 Method=get in HTML forms):
> User-Agents often throw away any query string from the URL indicated with the form's action attribute when generating the URL they will activate when the form's method is "get". This is the simplest means for them to generate a valid query string. The difficulty this causes is that Consumer's often prefer to store the information they will use when a portlet URL is activated as query string parameters. As a result, Portlets that include HTML forms with method=get in their markup MUST specify usesMethodGet as "true" in their PortletDescription. Consumers choosing to use such Portlets need to format their portlet URLs such that portlet URL activations are processed correctly, regardless of whether Consumer or Producer URL writing is in use.
--
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, 3 months
[JBoss JIRA] Created: (JBBUILD-359) Add retroweaving of classes or jars in a directory
by Reshat Sabiq (JIRA)
Add retroweaving of classes or jars in a directory
--------------------------------------------------
Key: JBBUILD-359
URL: http://jira.jboss.com/jira/browse/JBBUILD-359
Project: JBoss Build System
Issue Type: Feature Request
Components: jboss-retro-maven-plugin
Affects Versions: jboss-retro-maven-plugin-0.5.GA
Reporter: Reshat Sabiq
Assigned To: Paul Gier
It would be nice to be able to translate classes and jars in a directory, kinda like this:
<execution>
<id>retroweave-war-classes</id>
<phase>package</phase>
<goals>
<goal>translate</goal>
</goals>
<configuration>
<filesets>
<fileset>
<directory>
target/my-project-${project.version}/WEB-INF/classes
</directory>
<includes>
<include>**/*.class</include>
</includes>
</fileset>
</filesets>
<verbose>true</verbose>
</configuration>
</execution>
<execution>
<id>retroweave-dependencies</id>
<phase>package</phase>
<goals>
<goal>translate</goal>
</goals>
<configuration>
<jarfilesets>
<jarfileset>
<directory>
target/my-project-${project.version}/WEB-INF/lib
</directory>
<includes>
<include>**/*.jar</include>
</includes>
</jarfileset>
</jarfilesets>
<lazy>true</lazy>
</configuration>
</execution>
--
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, 3 months
[JBoss JIRA] Created: (JBRULES-812) Indexing failing when more than 3 indexable constraints are specified
by Edson Tirelli (JIRA)
Indexing failing when more than 3 indexable constraints are specified
---------------------------------------------------------------------
Key: JBRULES-812
URL: http://jira.jboss.com/jira/browse/JBRULES-812
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 3.1-m1
Reporter: Edson Tirelli
Assigned To: Edson Tirelli
Fix For: 3.1-m2
Guys, repeating a query from someone who perhaps didn't write it that clearly (chinese):
If they try the following condition:
varclu : cluster(clusterid==v_cluster
_id, transitionid==v_transition, stateid==v_state,ruleid==v_rule_id, v_evtid : evtid, v_evttype : evttype, v_srcaddress : srcaddress, v_destaddress : destaddress, v_timestamp : timestamp, v_alertid : alertid)" .
It blows up with "There cannot be more than 3 indexes"
Which is due to QuadroupleBetaConstraints not dealing with that many indexes.
When he deletes one equality ,such as "ruleid==v_rule_id", and then add "eval(varclu.getRuleid()==v_rule_id)", it works - so it looks like a bug/limitation to the current approach.
--
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, 3 months
[JBoss JIRA] Created: (JBRULES-722) NullPointerException when using inserAfter method with an empty LinkedList
by Pierre Paysant-Le Roux (JIRA)
NullPointerException when using inserAfter method with an empty LinkedList
--------------------------------------------------------------------------
Key: JBRULES-722
URL: http://jira.jboss.com/jira/browse/JBRULES-722
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.1-m1
Environment: Windows, jdk 1.5
Reporter: Pierre Paysant-Le Roux
Assigned To: Mark Proctor
JBoss rules throws a NullPointerException when adding my rules file. The problem is with the inserAfter methode in LinkedList. Debug shows that it appends when inserting a node in an empty list.
I wrote a simple test case to illustrate the problem :
Index: drools-core/src/test/java/org/drools/util/LinkedListTest.java
===================================================================
--- drools-core/src/test/java/org/drools/util/LinkedListTest.java (revision 9968)
+++ drools-core/src/test/java/org/drools/util/LinkedListTest.java (working copy)
@@ -264,4 +264,7 @@
3 );
}
-}
\ No newline at end of file
+ public void testInsertAfter(){
+ this.list.insertAfter( null, this.node1 );
+ }
+}
And a patch to avoid the problem :
Index: drools-core/src/main/java/org/drools/util/LinkedList.java
===================================================================
--- drools-core/src/main/java/org/drools/util/LinkedList.java (revision 9968)
+++ drools-core/src/main/java/org/drools/util/LinkedList.java (working copy)
@@ -151,17 +151,21 @@
}
if ( existingNode == null ) {
- // if existing node is null, then insert it as a first node
- final LinkedListNode node = this.firstNode;
- node.setPrevious( newNode );
- newNode.setNext( node );
- this.firstNode = newNode;
+ if(this.isEmpty())
+ this.add(newNode);
+ else{
+ // if existing node is null, then insert it as a first node
+ final LinkedListNode node = this.firstNode;
+ node.setPrevious( newNode );
+ newNode.setNext( node );
+ this.firstNode = newNode;
+ }
} else if ( existingNode == this.lastNode ) {
existingNode.setNext(newNode);
newNode.setPrevious( existingNode );
this.lastNode = newNode;
} else {
- ((LinkedListNode)existingNode.getNext()).setPrevious( newNode );
+ ((LinkedListNode)existingNode.getNext()).setPrevious( newNode );
newNode.setNext( existingNode.getNext() );
existingNode.setNext( newNode );
newNode.setPrevious( existingNode );
Excuse me if I'm wrong.
--
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, 3 months
[JBoss JIRA] Closed: (JBAS-2909) Testcase infra structure for MemoryLeaks
by Clebert Suconic (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]
Clebert Suconic closed JBAS-2909.
---------------------------------
Resolution: Done
> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
> Key: JBAS-2909
> URL: http://jira.jboss.com/jira/browse/JBAS-2909
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Reporter: Clebert Suconic
> Assigned To: Brian Stansberry
> Fix For: JBossAS-4.2.0.GA
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
> jvmtiInterface.forceReleaseOfGC();
> Class[] classes = jvmtiInterface.getLoadedClasses();
--
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, 3 months
[JBoss JIRA] Updated: (JBAS-2909) Testcase infra structure for MemoryLeaks
by Clebert Suconic (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]
Clebert Suconic updated JBAS-2909:
----------------------------------
Fix Version/s: JBossAS-4.2.0.GA
(was: JBossAS-5.0.1.CR1)
Assignee: Brian Stansberry (was: Clebert Suconic)
Brian has created those tests
> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
> Key: JBAS-2909
> URL: http://jira.jboss.com/jira/browse/JBAS-2909
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Reporter: Clebert Suconic
> Assigned To: Brian Stansberry
> Fix For: JBossAS-4.2.0.GA
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
> jvmtiInterface.forceReleaseOfGC();
> Class[] classes = jvmtiInterface.getLoadedClasses();
--
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, 3 months
[JBoss JIRA] Created: (JBTM-207) Contention in TransactionReaper
by Phillip Thurmond (JIRA)
Contention in TransactionReaper
-------------------------------
Key: JBTM-207
URL: http://jira.jboss.com/jira/browse/JBTM-207
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.2
Environment: Linux, JDK 5
Reporter: Phillip Thurmond
Assigned To: Mark Little
Under heavy load I am seeing a lot of contention on the TransactionReaper object. The remove() method has a large synchronized block. Could this synchronization be decreased or made to be more fine-grained?
Stack trace:
"http-10.68.0.196-8080-247" daemon prio=1 tid=0x0000002af2b7b030 nid=0x351a waiting for monitor entry [0x000000005a95a000..0x000000005a95cb30]
at com.arjuna.ats.arjuna.coordinator.TransactionReaper.remove(TransactionReaper.java:318)
- waiting to lock <0x0000002aa7dc7248> (a com.arjuna.ats.arjuna.coordinator.TransactionReaper)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:185)
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1204)
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateful.StatefulInstanceInterceptor.invoke(StatefulInstanceInterceptor.java:83)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.remoting.ReplicantsManagerInterceptor.invoke(ReplicantsManagerInterceptor.java:51)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:105)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateful.StatefulContainer.localInvoke(StatefulContainer.java:204)
at org.jboss.ejb3.stateful.StatefulLocalProxy.invoke(StatefulLocalProxy.java:100)
at $Proxy109.update(Unknown Source)
at TodoDaoInt$$FastClassByCGLIB$$6f227f03.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:45)
at org.jboss.seam.intercept.ClientSideInterceptor$1.proceed(ClientSideInterceptor.java:74)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:55)
at org.jboss.seam.interceptors.RemoveInterceptor.removeIfNecessary(RemoveInterceptor.java:40)
at sun.reflect.GeneratedMethodAccessor362.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:18)
at org.jboss.seam.intercept.Interceptor.aroundInvoke(Interceptor.java:169)
at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:64)
at org.jboss.seam.intercept.RootInterceptor.createSeamInvocationContext(RootInterceptor.java:144)
at org.jboss.seam.intercept.RootInterceptor.invokeInContexts(RootInterceptor.java:129)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:102)
at org.jboss.seam.intercept.ClientSideInterceptor.interceptInvocation(ClientSideInterceptor.java:83)
at org.jboss.seam.intercept.ClientSideInterceptor.intercept(ClientSideInterceptor.java:52)
at org.jboss.seam.intercept.Proxy$$EnhancerByCGLIB$$e1e24e7.update(<generated>)
at sun.reflect.GeneratedMethodAccessor422.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.el.parser.AstValue.invoke(AstValue.java:131)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:77)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:95)
at javax.faces.component.UICommand.broadcast(UICommand.java:383)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:448)
--
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, 3 months