May 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-6133) Upgrade Quartz to latest release

by Tomaz Cerar (JIRA)

Upgrade Quartz to latest release -------------------------------- Key: JBAS-6133 URL: https://jira.jboss.org/jira/browse/JBAS-6133 Project: JBoss Application Server Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Components: Scheduling/Timers Affects Versions: JBossAS-5.0.0.CR2 Reporter: Tomaz Cerar Assignee: Dimitris Andreadis Jboss 5 currenty (trunk) comes with quartz 1.5.2. which is more than 2 years old, it would be nice if if would be upgraded to latest release (1.6.1 at this time) if I just replace jar from latest dist it looks like everything works... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

5
6
0 / 0

[JBoss JIRA] Created: (JBAS-6782) Seam/VFS integration issue

by Charles Crouch (JIRA)

Seam/VFS integration issue -------------------------- Key: JBAS-6782 URL: https://jira.jboss.org/jira/browse/JBAS-6782 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.CR1 Reporter: Charles Crouch Assignee: Jason T. Greene Fix For: JBossAS-5.1.0.GA Essentially Seam is scanning too many files looking for Seam components when a Seam based web app is being deployed. This increases the deployment time significantly, e.g. double it in the case of EMBJOPR. See https://jira.jboss.org/jira/browse/EMBJOPR-85?focusedCommentId=12461922#a... for more details -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

4
9
0 / 0

[JBoss JIRA] Closed: (JBAS-2079) Add the support for mapping application roles to security groups

by Dominique Jean-Prost (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-2079?page=com.atlassian.jira.plug... ] Dominique Jean-Prost closed JBAS-2079. -------------------------------------- Resolution: Duplicate Issue duplicate of JBAS-3323 > Add the support for mapping application roles to security groups > ---------------------------------------------------------------- > > Key: JBAS-2079 > URL: https://jira.jboss.org/jira/browse/JBAS-2079 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Affects Versions: JBossAS-4.0.2 Final > Reporter: Dominique Jean-Prost > Priority: Minor > > Actually, JBoss requires that <security-role> or <role-name> are exactly the groups you can find in your security realm. As a result, if you want your application to be available to the role "myApplicationRole", you have to setup a group in your realm with the name "myApplicationRole". > Now if you want to restraint a specific feature to role1, using request.isUserInRole("role1"), you have to setup a <security-role-link> to map role1 to a group of your realm. This works well if this feature maps to a single role. If this feature maps to let's say 2 different groups (gr1 and gr2) of your realm, you have to create a new group in your realm, let's say "myFeatureGroup", put gr1 and gr2 in myFeatureGroup in order to see it works. You now have a application specific group in your global realm. I think we should avoid this. > I suggest to add the ability to map a role to 1-m group using jboss-web.xml (I thought it was aimed at it) so we could have : > web.xml : > <security-role>myRole</security-role> > and in jboss-web.xml > <security-role> > <role-name>myRole</role-name> > <principal-name>j2eegourp</principal-name> > <principal-name>joe</principal-name> > </security-role> > and joe is a user and j2eegroup are security groups. > Using this, we have the following advantages : > - application only deals with roles, and not security groups > - security groups only deals with global groups and not applications specific roles > - there is a clear separation between roles and groups. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-7165) start page (i.e. /index.html) still has old (pre Red Hat) JBoss logo and overall dated L&F

by Ian Springer (JIRA)

start page (i.e. /index.html) still has old (pre Red Hat) JBoss logo and overall dated L&F ------------------------------------------------------------------------------------------ Key: JBAS-7165 URL: https://jira.jboss.org/jira/browse/JBAS-7165 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-5.1.0.GA Reporter: Ian Springer Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-7986) NPE in StateslessContainer at line 396

by Nagin Kothari (JIRA)

NPE in StateslessContainer at line 396 ---------------------------------------- Key: JBAS-7986 URL: https://jira.jboss.org/jira/browse/JBAS-7986 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: 6.0.0.M2 Reporter: Nagin Kothari Assignee: Carlo de Wolf I have Ejb3 applicationn which is running successfully in jboss 4.3.2. When I migrated application to jboss 6.0 M2, I am getting Null pointer exception at line 396 of StatelessContainer class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1994) ServiceContainer.dynamicInvoke can lead to NPE

by jaikiran pai (JIRA)

ServiceContainer.dynamicInvoke can lead to NPE ---------------------------------------------- Key: EJBTHREE-1994 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1994 Project: EJB 3.0 Issue Type: Bug Components: core Affects Versions: Plugin 1.0.19, EJB3_1 1.0.1 Reporter: jaikiran pai Assignee: jaikiran pai When a method is not present, the ServiceContainer.dynamicInvoke leads to NPE: java.lang.NullPointerException at org.jboss.ejb3.service.ServiceContainer.dynamicInvoke(ServiceContainer.java:477) at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53) at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891) at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:211) at org.jboss.remoting.Client.invoke(Client.java:1724) at org.jboss.remoting.Client.invoke(Client.java:629) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at rte.gsr.app.jboss.ClientIntercepteur.invoke(ClientIntercepteur.java:114) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62) at $Proxy3.invoke(Unknown Source) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164) at $Proxy2.toto(Unknown Source) Looking at the other containers (like StatelessContainer) they too can lead to such a NPE. The containers need to throw NoSuchMethodError or something more meaningful in the absence of a method. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
2
0 / 0

[JBoss JIRA] Created: (SECURITY-504) Hot redeploy does not invalidate AuthCache when flushOnSessionInvalidation="true"

by Ondrej Medek (JIRA)

Hot redeploy does not invalidate AuthCache when flushOnSessionInvalidation="true" --------------------------------------------------------------------------------- Key: SECURITY-504 URL: https://jira.jboss.org/jira/browse/SECURITY-504 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss 5.1.0GA Reporter: Ondrej Medek Assignee: Anil Saldhana Hi, AuthCache is still valid, when I hot redeploy my web app. I have set flushOnSessionInvalidation="true". My jboss-web.xml: <jboss-web> <security-domain flushOnSessionInvalidation="true">java:/jaas/blue-tiger</security-domain> <context-root>tiger</context-root> <max-active-sessions>5000</max-active-sessions> </jboss-web> Note: I have an EAR with EJB module, which has jboss.xml: <jboss> <security-domain>java:/jaas/blue-tiger</security-domain> <unauthenticated-principal>anonymous</unauthenticated-principal> <container-configurations></container-configurations> </jboss> and my WAR is deployed separately to the EAR. Steps to reproduce: 1. Deploy WAR with flushOnSessionInvalidation="true" 2. Log in any user. 3. Change a role of the user in the database. 4. Redeploy the WAR (delete it and copy it to the deploy dir again) 5. Log in as the the same user. Check the user roles by HttpServletRequest.isUserInRole(String role) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-692) Unable to recover from suspect/merge, with auto-reconnect

by Matt Magoffin (JIRA)

Unable to recover from suspect/merge, with auto-reconnect --------------------------------------------------------- Key: JGRP-692 URL: http://jira.jboss.com/jira/browse/JGRP-692 Project: JGroups Issue Type: Bug Affects Versions: 2.6.1 Environment: JBoss 4.2.2 on Linux 2.4.21-47.0.1.ELsmp i686 using Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode) Reporter: Matt Magoffin Assigned To: Bela Ban Attachments: jgroups-logs.tbz2 I'm having an issue with a 2-machine cluster using a TCP stack based on the tcp.xml from JGroups 2.6.1. On each machine I have 8 separate channels running, on different ports, with 4 groups in 2 JVM instances. After some period of time, one machine will fail to respond to a FD ping, and gets suspected. The machine that failed is not responding in time it seems from high CPU use, and many of the channels will fail FD around the same time. The channels are configured with auto-reconnect. My understanding was that the channel should "heal" itself and eventually re-form into a new view with the same 2 members in the cluster, which should apply to this situation because the machine that failed to respond eventually will respond. However, the group does not always seem to "heal" (sometimes it does, sometimes not). Once it stops healing, it never seems to ever do so again, and I get tons of NAKACK "message X not found in retransmission table" ERROR logs. The only way to get the channel working agin is to shut down the channel on both machines and then start them up again. I'm not using muxed channels... just normal channels. I have for now disabled shunning, and the channels seem to be able to re-connect after a shun situation occurs, but after time I'm still seeing something wrong with the channel in that the nodes are not able to send messages to each other successfully, and I have tons of 2008-02-21 21:01:53,572 WARN [org.jgroups.protocols.pbcast.NAKACK] 172.16.172.233:19182] discarded message from non-member 172.16.172.234:19182, my view is [172.16.172.233:19182|8] [172.16.172.233:19182] log entries, even while FD is receiving acks on that channel. this is a degradation problem for me while my servers are running, not just during deployment. After a while of running, the nodes get shunned/disconnected some how (often from a slow response from the other node) and then fail to ever merge back to form the original view of the 2 nodes again. Now even with shun set to false in both FD and pbcast.GMS on both nodes for all channels, eventually still the nodes reach the same state of never re-forming... and I have tons eventual 2008-02-21 21:28:24,857 WARN [org.jgroups.protocols.pbcast.NAKACK] 172.16.172.233:19182] discarded message from non-member 172.16.172.234:19182, my view is [172.16.172.233:19182|8] [172.16.172.233:19182] After a while in my application I'll force the channel to close wait a minute, and reopen, and sometimes this gets the channel working again, but doesn't always seem to. -- 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

14 years

4
24
0 / 0

[JBoss JIRA] Created: (JBAS-7594) Seam testsuite ears fail to deploy due to parse issues

by Scott M Stark (JIRA)

Seam testsuite ears fail to deploy due to parse issues ------------------------------------------------------ Key: JBAS-7594 URL: https://jira.jboss.org/jira/browse/JBAS-7594 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: JBossAS-6.0.0.M1 Reporter: Scott M Stark The seam apps are failing to deploy due to some xml ordering issue that must have become more strict recently, or the seam examples have changed. Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: cvc-complex-type.2.4.a: Invalid content was found starting with element 'description'. One of '{"http://java.sun.com/xml/ns/javaee":type, "http://java.sun.com/xml/ns/javaee":deferred-value, "http://java.sun.com/xml/ns/javaee":deferred-method}' is expected. @ vfszip:/Users/svn/JBossHead/trunk/build/output/jboss-6.0.0-SNAPSHOT/server/all/deploy/jboss-seam-numberguess.ear/jboss-seam-numberguess.war/WEB-INF/lib/jboss-seam-ui.jar/META-INF/s.tld[2205,18] at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168) at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:229) at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:206) at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137) at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:62) at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:37) at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121) Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: cvc-complex-type.2.4.a: Invalid content was found starting with element 'description'. One of '{"http://java.sun.com/xml/ns/javaee":type, "http://java.sun.com/xml/ns/javaee":deferred-value, "http://java.sun.com/xml/ns/javaee":deferred-method}' is expected. @ vfszip:/Users/svn/JBossHead/trunk/build/output/jboss-6.0.0-SNAPSHOT/server/all/deploy/jboss-seam-booking.ear/jboss-seam-booking.war/WEB-INF/lib/jboss-seam-ui.jar/META-INF/s.tld[2205,18] at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203) at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168) at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:229) at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:206) at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137) at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:62) at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:37) at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

4
13
0 / 0

[JBoss JIRA] Created: (JBAS-7872) Update ClusterCacheTester to use JMXConnectorFactory instead of RMIAdaptor for cluster unit testing

by Scott Marlow (JIRA)

Update ClusterCacheTester to use JMXConnectorFactory instead of RMIAdaptor for cluster unit testing --------------------------------------------------------------------------------------------------- Key: JBAS-7872 URL: https://jira.jboss.org/jira/browse/JBAS-7872 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Scott Marlow Fix For: JBossAS-6.0.0.M4 Using JMXServiceURL "service:jmx:rmi:///jndi/rmi://localhost:8099/jmxrmi" (will need binding support for new rmi registry port + rmi connector), obtain JSR-160 style jmx connectors for cluster nodes. For example: JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:8099/jmxrmi"); JMXConnector jmxc = JMXConnectorFactory.connect(url, new HashMap()); return jmxc.getMBeanServerConnection(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2010