May 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-7992) Remove HASessionStateTopologyComputer and related SubPartitionInfo

by Brian Stansberry (JIRA)

Remove HASessionStateTopologyComputer and related SubPartitionInfo ------------------------------------------------------------------ Key: JBAS-7992 URL: https://jira.jboss.org/jira/browse/JBAS-7992 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 6.0.0.CR1 org.jboss.ha.hasessionstate.server.HASessionStateTopologyComputer and its impl appear to be unused. Remove them. They are the only users of org.jboss.ha.framework.interfaces.SubPartitionsInfo and SubPartitionInfo. Due to the package they appear in those classes are semi- user API. But I know of no usage of them. They should be removed as well. -- 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

13 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-247) Pb during http session replication : "Problem accessing session data : class java.lang.IllegalStateException metadata is null"

by A B (JIRA)

Pb during http session replication : "Problem accessing session data : class java.lang.IllegalStateException metadata is null" ------------------------------------------------------------------------------------------------------------------------------ Key: JBCLUSTER-247 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-247 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Environment: Linux fepapp-ren-l76 2.6.18-128.1.14.el5 #1 SMP Mon Jun 1 15:52:58 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux Server release 5.3 (Tikanga) 64 bits JBoss 5.1.0 GA / jdk1.6.0_17 + apache 2.2.14 + mod_jk 1.2.28 Reporter: A B Assignee: Brian Stansberry I have a basic JBoss cluster with two nodes that are running on a single server. Both nodes are up and OK : - node 1 : 17:22:29,564 INFO [RPCManagerImpl] Received new cluster view: [172.30.4.76:30577|1] [172.30.4.76:30577, 172.30.4.76:29898] 17:22:29,572 INFO [LegacyStateTransferIntegrator] Using version 4096 17:22:29,591 INFO [RPCManagerImpl] Cache local address is 172.30.4.76:29898 17:22:29,591 INFO [RPCManagerImpl] state was retrieved successfully (in 176 milliseconds) 17:22:29,613 INFO [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA 17:22:29,680 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-172.30.4.76-8080 17:22:29,767 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-172.30.4.76-8009 17:22:29,791 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:20s:161ms - node 2 : 17:22:27,152 INFO [RPCManagerImpl] Received new cluster view: [172.30.4.76:30577|0] [172.30.4.76:30577] 17:22:27,153 INFO [RPCManagerImpl] Cache local address is 172.30.4.76:30577 17:22:27,159 INFO [RPCManagerImpl] state was retrieved successfully (in 2.02 seconds) 17:22:27,184 INFO [ComponentRegistry] JBoss Cache version: JBossCache 'Cascabel' 3.1.0.GA 17:22:27,250 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-172.30.4.76-8180 17:22:27,293 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-172.30.4.76-8109 17:22:27,314 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:23s:438ms 17:22:29,560 INFO [RPCManagerImpl] Received new cluster view: [172.30.4.76:30577|1] [172.30.4.76:30577, 172.30.4.76:29898] I've deployed tomcat servlet examples and I'm using in particular "Session example" servlet to test http replication I'm adding attributes in the session that is managed on a node : OK 17:31:04,168 INFO [[/TomcatServletExamples]] SessionListener: sessionCreated('ghh7gRljrScVi+rGT-T-LQ__.ESAJBOSS3_jboss_172.30.4.76_1') 17:31:13,629 INFO [[/TomcatServletExamples]] SessionListener: attributeAdded('ghh7gRljrScVi+rGT-T-LQ__.ESAJBOSS3_jboss_172.30.4.76_1', 'aa', 'aa') 17:31:16,963 INFO [[/TomcatServletExamples]] SessionListener: attributeAdded('ghh7gRljrScVi+rGT-T-LQ__.ESAJBOSS3_jboss_172.30.4.76_1', 'bb', 'bb') I stop this node : OK 17:31:36,952 INFO [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener@35b83ac6 got new view [172.30.4.76:10321|2] [172.30.4.76:55196], old view is [172.30.4.76:10321|1] [172.30.4.76:10321, 172.30.4.76:55196] 17:31:36,953 INFO [GroupMember] I am (172.30.4.76:55196) 17:31:36,954 WARN [NAKACK] 172.30.4.76:55196] discarded message from non-member 172.30.4.76:10321, my view is [172.30.4.76:10321|2] [172.30.4.76:55196] 17:31:36,966 INFO [GroupMember] Dead members: 1 ([172.30.4.76:10321]) 17:31:36,966 INFO [GroupMember] All Members : 1 ([172.30.4.76:55196]) 17:31:38,156 INFO [RPCManagerImpl] Received new cluster view: [172.30.4.76:10321|2] [172.30.4.76:55196] 17:31:38,156 WARN [NAKACK] 172.30.4.76:55196] discarded message from non-member 172.30.4.76:10321, my view is [172.30.4.76:10321|2] [172.30.4.76:55196] 17:31:38,205 WARN [NAKACK] 172.30.4.76:55196] discarded message from non-member 172.30.4.76:10321, my view is [172.30.4.76:10321|2] [172.30.4.76:55196] 17:31:38,206 INFO [DocsPartition] New cluster view for partition DocsPartition (id: 2, delta: -1) : [172.30.4.76:1199] 17:31:38,211 INFO [DocsPartition] I am (172.30.4.76:1199) received membershipChanged event: 17:31:38,212 INFO [DocsPartition] Dead members: 1 ([172.30.4.76:1099]) 17:31:38,212 INFO [DocsPartition] New Members : 0 ([]) 17:31:38,212 INFO [DocsPartition] All Members : 1 ([172.30.4.76:1199]) I'm adding a new attribute : OK (request is served by second node of the cluster) : 17:32:20,789 INFO [[/TomcatServletExamples]] SessionListener: attributeAdded('ghh7gRljrScVi+rGT-T-LQ__.ESAJBOSS4_jboss_172.30.4.76_1', 'cc', 'cc') I'm adding a new attribute : KO 17:33:09,053 WARN [SessionBasedJBossCacheService] Problem accessing session data : class java.lang.IllegalStateException metadata is null 17:33:09,071 INFO [[/TomcatServletExamples]] SessionListener: sessionCreated('RVmtXKGKvGGWuGjXKxoXNw__.ESAJBOSS4_jboss_172.30.4.76_1') 17:33:09,078 INFO [[/TomcatServletExamples]] SessionListener: attributeAdded('RVmtXKGKvGGWuGjXKxoXNw__.ESAJBOSS4_jboss_172.30.4.76_1', 'dd', 'dd') => A new session is created and old values stored in the first session are lost Do you think it's a bug or did I make a mistake somewhere ? -- 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

13 years, 1 month

3
12
0 / 0

[JBoss JIRA] Created: (JBMETA-280) Add jboss release repo to distributionManagement in jboss-metadata-ejb pom

by jaikiran pai (JIRA)

Add jboss release repo to distributionManagement in jboss-metadata-ejb pom -------------------------------------------------------------------------- Key: JBMETA-280 URL: https://jira.jboss.org/jira/browse/JBMETA-280 Project: JBoss Metadata Issue Type: Task Security Level: Public (Everyone can see) Components: ejb Affects Versions: jboss-metadata-ejb-2.0.0-alpha-11 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: jboss-metadata-ejb-2.0.0-alpha-12 As per the new release guidelines http://community.jboss.org/wiki/MavenDeployingaRelease <quote> In order to deploy to the Maven releases repository, your project POM (or parent POM) will need to be configured with the appropriate distributionManagement information. The best practice is to inherit this information from the JBoss parent pom (version 5 or later). <parent> <groupId>org.jboss</groupId> <artifactId>jboss-parent</artifactId> <version>5</version> </parent> If you are not able to inherit from the jboss parent pom, you will need the following configuration in your POM. <distributionManagement> <repository> <id>jboss-releases-repository</id> <name>JBoss Releases Repository</name> <url>https://repository.jboss.org/nexus/service/local/staging/deploy/maven2/</url> </repository> ... </distributionManagement> </quote> We have had some issues using jboss-parent 5, so instead of using that version, add the distribution management section to the pom. -- 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

13 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBMETA-277) Revert JPA 2 functionality from metadata 1.0

by Carlo de Wolf (JIRA)

Revert JPA 2 functionality from metadata 1.0 -------------------------------------------- Key: JBMETA-277 URL: https://jira.jboss.org/jira/browse/JBMETA-277 Project: JBoss Metadata Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 1.0.2.GA Reporter: Carlo de Wolf Assignee: Alexey Loubyansky Fix For: 1.0.3.GA JPA 2 should not have ended up in version metadata 1.0. Revert 95190 -- 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

13 years, 1 month

1
5
0 / 0

[JBoss JIRA] Created: (JBMETA-279) Invalid jboss-logging-log4j ends up in dependency tree

by Carlo de Wolf (JIRA)

Invalid jboss-logging-log4j ends up in dependency tree ------------------------------------------------------ Key: JBMETA-279 URL: https://jira.jboss.org/jira/browse/JBMETA-279 Project: JBoss Metadata Issue Type: Task Security Level: Public (Everyone can see) Components: ejb Affects Versions: jboss-metadata-ejb-2.0.0-alpha-11 Reporter: Carlo de Wolf Assignee: Carlo de Wolf Fix For: jboss-metadata-ejb-2.0.0-alpha-12 Failed to initalize plugin: org.jboss.logging.log4j.Log4jLoggerPlugin@1176e5c, cause: java.lang.AbstractMethodError: org.jboss.logging.log4j.Log4jLoggerPlugin.getInstance(Ljava/lang/String;Ljava/lang/String;)Lorg/jboss/logging/LoggerPluginInstance; [INFO] [dependency:tree] [INFO] org.jboss.metadata:jboss-metadata-ejb:jar:2.0.0-SNAPSHOT [INFO] +- org.jboss.metadata:jboss-metadata-common:jar:2.0.0.Alpha15:compile [INFO] | \- org.jboss.logging:jboss-logging-spi:jar:2.2.0.CR1:compile [INFO] \- org.jboss.test:jboss-test:jar:1.1.4.GA:test [INFO] \- org.jboss.logging:jboss-logging-log4j:jar:2.0.5.GA:test -- 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

13 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-7888) Investigate EJB3 Injection Integration Issue

by Richard Opalka (JIRA)

Investigate EJB3 Injection Integration Issue -------------------------------------------- Key: JBAS-7888 URL: https://jira.jboss.org/jira/browse/JBAS-7888 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3, Web Services Reporter: Richard Opalka Assignee: Richard Opalka Fix For: JBossAS-6.0.0.M3 The following test is failing against AS trunk ATM: org.jboss.test.ws.jaxws.ejb3Integration.injection.InjectionTestCase -- 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

13 years, 1 month

3
11
0 / 0

[JBoss JIRA] Created: (JBAS-7990) Upgrade JBossWS to 3.3.0.CR2

by Richard Opalka (JIRA)

Upgrade JBossWS to 3.3.0.CR2 ---------------------------- Key: JBAS-7990 URL: https://jira.jboss.org/jira/browse/JBAS-7990 Project: JBoss Application Server Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: Web Services Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 6.0.0.CR1 -- 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

13 years, 1 month

1
1
0 / 0

[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

13 years, 1 month

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

13 years, 1 month

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

13 years, 1 month

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2010