December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1699) Better CMS workflow approval

by Will Jones (JIRA)

Better CMS workflow approval ---------------------------- Key: JBPORTAL-1699 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1699 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.1 Final Reporter: Will Jones Assigned To: Sohil Shah When approving a workflow cms item, the Administrator should be allowed to view the submitted content prior to making the decision to approve or deny. The approver should also be able to make changes to the content before approving item. -- 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

16 years, 4 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-5019) Turn ClusterNode into an interface

by Brian Stansberry (JIRA)

Turn ClusterNode into an interface ---------------------------------- Key: JBAS-5019 URL: http://jira.jboss.com/jira/browse/JBAS-5019 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta3 ClusterNode leaks the JGroup IpAddress class via getOriginalJGAddress. AFAICT the only code that uses that method is ClusterPartition. So, look into making ClusterNode an interface that doesn't expose getOriginalJGAddress(). ClusterPartition can use the method on the implementing class, which it controls. -- 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

16 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5028) Push RunAsIdentity for ejbTimeOut methods

by Anil Saldhana (JIRA)

Push RunAsIdentity for ejbTimeOut methods ----------------------------------------- Key: JBAS-5028 URL: http://jira.jboss.com/jira/browse/JBAS-5028 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2, Security Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta3 If an EJB implements the TimedObject interface and defines a RunAsIdentity, then in the ejbTimeOut method, the bean can access other secured JavaEE components, in which case the configured RAI should kick in. Push the configured rai on the security context. -- 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

16 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1140) EJBContext needs to have BeanPrincipal for getCallerPrincipal calls

by Anil Saldhana (JIRA)

EJBContext needs to have BeanPrincipal for getCallerPrincipal calls ------------------------------------------------------------------- Key: EJBTHREE-1140 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1140 Project: EJB 3.0 Issue Type: Bug Components: Security Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: AS 5.0.0.Beta3 The BeanPrincipal isespecially relevant for Stateful Session Beans. This is how EJB2 EnterpriseContext.getCallerPrincipal works. -- 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

16 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-746) need to be able to tell ServerInvokerServlet to use the platform MBean server

by John Mazzitelli (JIRA)

need to be able to tell ServerInvokerServlet to use the platform MBean server ----------------------------------------------------------------------------- Key: JBREM-746 URL: http://jira.jboss.com/jira/browse/JBREM-746 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.0.SP4 Reporter: John Mazzitelli Assigned To: Ron Sigal Right now, ServerInvokerServlet assumes the MBeanServer where it can find the server invoker is the JBoss MBeanServer. See the comments in ServerInvokerServlet.getMBeanServer() It would be nice to be able to tell it to not use the MBeanServer whose default domain is "jboss", but rather we should be able to tell it (via servlet init params) either: a) the name of the MBeanServer's default domain (in case I want to use my own, not the jboss one) or b) a flag to indicate it should use the Java5 platform MBeanServer (java.lang.management.ManagementFactory.getPlatformMBeanServer()) Workaround is for customers to write their own subclass of ServerInvokerServlet, override the getMBeanServer method to find the appropriate one. -- 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

16 years, 5 months

2
9
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1171) Session.close (indirectly Producer.close) should wait async execution buffers to be emptied before closing channels

by Clebert Suconic (JIRA)

Session.close (indirectly Producer.close) should wait async execution buffers to be emptied before closing channels ------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1171 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1171 Project: JBoss Messaging Issue Type: Bug Reporter: Clebert Suconic Assigned To: Tim Fox Fix For: 1.4.0.SP2 To easily replicate this, use org.jboss.test.messaging.jms.stress.SeveralClientsStressTest At your workspace you could lower the total time for the execution. (I will have attached a patch on this JIRA) protected static long PRODUCER_ALIVE_FOR=5000; // originalValue=60000 protected static long CONSUMER_ALIVE_FOR=5000; // originalValue=60000 protected static long TEST_ALIVE_FOR=15000; // originalValue = 5 * 60 * 1000 protected static int NUMBER_OF_PRODUCERS=50; protected static int NUMBER_OF_CONSUMERS=50; The test is loosing messages on this following condition: - you have N Threads, each Thread equals one Producer, sending messages at a constant rate. - Each message is sent asynchronously - After some time the Thread decides to stop producing messages, and immediately closes the session. - Any message that hasn't been sent to the server yet would be lost. How to validate what I'm talking about: Run the testcase as is (lowering the time as I said before on this message). You will see a warning at the end of the test with non processed messages: @main 17:51:50,486 WARN [SeveralClientsStressTest] Message non processed, txt="msg prod#38 seq#31", msgToString=[delegator->JBossMessage[463]:NON-PERSISTENT, deliveryId=0] @main 17:51:50,486 WARN [SeveralClientsStressTest] Message non processed, txt="msg prod#38 seq#29", msgToString=[delegator->JBossMessage[434]:NON-PERSISTENT, deliveryId=0] @main 17:51:50,486 WARN [SeveralClientsStressTest] Message non processed, txt="msg prod#38 seq#24", msgToString=[delegator->JBossMessage[339]:NON-PERSISTENT, deliveryId=0] @main 17:51:50,486 WARN [SeveralClientsStressTest] Message non processed, txt="msg prod#38 seq#26", msgToString=[delegator->JBossMessage[374]:NON-PERSISTENT, deliveryId=0] If you look on logs you will realize that any message appearing on this list didn't make to the server. and it will aways coincide with the very few last messages sent on this thread. If you put a Thread.sleep(10000); before the conn.close() on SeveralClientsStressTest.Producer (line 422) the test will pass: Thread.sleep(10000); finally { Thread.sleep(10000); conn.close(); } - Somehow producer.close / session.close should empty the async buffer before closing the session. I have attached a patch for this test. -- 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

16 years, 5 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007