May 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-7989) Missing org/apache/ws/policy classes in $JBOSS_HOME/client

by Shelly McGowan (JIRA)

Missing org/apache/ws/policy classes in $JBOSS_HOME/client ---------------------------------------------------------- Key: JBAS-7989 URL: https://jira.jboss.org/jira/browse/JBAS-7989 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Reporter: Shelly McGowan Assignee: Paul Gier Fix For: 6.0.0.CR1 JBAS-7962 removed deprecated dependencies from the JBoss AS build. One of the changes shown here: http://fisheye.jboss.org/browse/JBossAS/trunk/build/build.xml?r1=104040&r... specifically: 2241 - <fileset refid="org.apache.ws.policy:wscommons-policy:jar"/> 2241 + <fileset refid="ws-commons:policy:jar"/> 2242 2242 <fileset refid="com.sun.xml.ws:policy:jar"/> This change has caused tests failures in both the AS testsuite and the EE 6 TCK. While the classpath can be adjusted, this fix seems to be in error as it changes the jar name from wscommons-policy.jar to policy.jar resulting in two jar files of the same name, different content, being copied to the $JBOSS_HOME/client directory. The contents of ws-commons policy.jar no longer reside in $JBOSS_HOME/client. The ws-commons policy.jar is copied to $JBOSS_HOME/common/lib resulting in different policy.jar files between the client and common/lib directory. 1673 1673 <fileset refid="org.jboss.netty:netty:jar"/> <> 1674 - <fileset refid="org.apache.ws.policy:wscommons-policy:jar"/> 1674 + <fileset refid="ws-commons:policy:jar"/> -- 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

16 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBXB-250) update dtdparser dependency

by Alexey Loubyansky (JIRA)

update dtdparser dependency --------------------------- Key: JBXB-250 URL: https://jira.jboss.org/jira/browse/JBXB-250 Project: JBoss XML Binding (JBossXB) Issue Type: Thirdparty Change Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: JBossXB-2.0.2.GA From <dependency> <groupId>wutka-dtdparser</groupId> <artifactId>dtdparser121</artifactId> <version>1.2.1</version> <scope>compile</scope> </dependency> to <dependency> <groupId>com.wutka</groupId> <artifactId>dtdparser</artifactId> <version>1.21</version> </dependency> -- 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

16 years, 2 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBAS-1057) FK Violation deleting 1-1 relationship

by Alexey Loubyansky (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-1057?page=com.atlassian.jira.plug... ] Alexey Loubyansky commented on JBAS-1057: ----------------------------------------- No, it hasn't been fixed. I've reviewed it and I don't think it's going to be fixed. In this specific CMR scheme we won't support batch-cascade-delete. (If batch-cascade-delete is removed for group-has-groupids the test will pass). To properly fix this, significant changes will have to be made and we are not investing in CMP2 development anymore. Taking into account that batch-cascade-delete is an optimization, although an important one, in this use-case it won't work. > FK Violation deleting 1-1 relationship > -------------------------------------- > > Key: JBAS-1057 > URL: https://jira.jboss.org/jira/browse/JBAS-1057 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-3.2.6 Final > Reporter: SourceForge User > Assignee: Alexey Loubyansky > Fix For: Unscheduled > > > SourceForge Submitter: suzyrizzo . > I have attached a set of CMPs that cause a foreign key > violation when deleted. > Entities: > Group > Address > GroupId > Group has a uni-directional 1-1 relationship with > Address. A foreign key is set up on the > Group.physicalAddressKey field. > Group has a bi-directional 1-many relationship with > GroupId. > I have batch-cascade-delete turned on for the group- > has-groupids relationship because the GroupId.groupKey > cannot be null. > I do not have batch-cascade-delete turned on for the > group-has-address relationship because > physicalAddressKey is an FK into Address, so Address > cannot be deleted before Group. > The relationships work separately, but when I have them > defined at the same time, I get a Foreign Key violation. > I've included the server.log file with the full error > message in my attachment. -- 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

16 years, 2 months

1
0
0 / 0

[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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2010