September 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4125) Move clustering test support classes to test module

by Brian Stansberry (JIRA)

Move clustering test support classes to test module --------------------------------------------------- Key: JBAS-4125 URL: http://jira.jboss.com/jira/browse/JBAS-4125 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Brian Stansberry The org.jboss.test.JBossClusteredTestCase, JBossClusteredTestServices and JBossClusteredTestSetup classes should be moved out of the testsuite module and into test. They are just utility classes to support deployment to more than one AS instance and exposure to test clients of more than one JNDI URL and base HTTP URL. EJB3 uses them as well, so they need to be in a binary to allow EJB3 to decouple from the AS. This should be done on both trunk and Branch_4_2. -- 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

18 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-4664) Move JBossClusteredTestCase to test module in Branch_4_2

by Brian Stansberry (JIRA)

Move JBossClusteredTestCase to test module in Branch_4_2 -------------------------------------------------------- Key: JBAS-4664 URL: http://jira.jboss.com/jira/browse/JBAS-4664 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, Test Suite Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-4.2.2.GA 4.2 approach to the parent task. We don't use jboss-test.jar in 4.2; still use the test module. -- 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

18 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1668) A user with "Administrator" privileges is not able to create resources at the root level of the CMS repo

by Sohil Shah (JIRA)

A user with "Administrator" privileges is not able to create resources at the root level of the CMS repo -------------------------------------------------------------------------------------------------------- Key: JBPORTAL-1668 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1668 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.1 Final, 2.6 Final, 2.6 CR3, 2.6.CR1, 2.6.CR2, 2.6.Beta1, 2.6.Alpha2, 2.6.Alpha1 Reporter: Sohil Shah Assigned To: Sohil Shah Fix For: 2.6.2 Final How to reproduce- Assign a Portal user to Administrator group. Login as this user, and try to create a Folder at "/" path of the CMS repo. You get an Access Denied Exception -- 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

18 years, 10 months

2
3
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-687) PojoCache to use aop 2.0 to bind interceptor dynamically

by Jason T. Greene (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-687?page=all ] Jason T. Greene resolved JBCACHE-687. ------------------------------------- Fix Version/s: (was: 2.1.0.GA) Resolution: Out of Date This is no longer needed. > PojoCache to use aop 2.0 to bind interceptor dynamically > -------------------------------------------------------- > > Key: JBCACHE-687 > URL: http://jira.jboss.com/jira/browse/JBCACHE-687 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Jason T. Greene > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently in 2.0, I am introducing new field level interceptos such as SubjectInterceptor to emit the field events. However, make "introduction" to a POJO with a Subject interface also has the side effect of the interceptor will bind to that method jointpoint as well. This is not desirable. > Workaround is to check for MehtodInvocation is each field level interceptor or in AOP2.0, we can bind specifically to the Pointcut programmtically as discussed in the forum post. -- 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

18 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1044) Replace clustering test case usage of RMIAdaptor

by Brian Stansberry (JIRA)

Replace clustering test case usage of RMIAdaptor ------------------------------------------------ Key: EJBTHREE-1044 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1044 Project: EJB 3.0 Issue Type: Task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: AS 4.2.2.GA, EJB 3.0 RC11 - FD Part of removing dependency on testsuite module via JBossClusteredTestCase. See JBAS-4663. -- 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

18 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4663) Replace JBossClusteredTestCase usage of RMIAdaptor

by Brian Stansberry (JIRA)

Replace JBossClusteredTestCase usage of RMIAdaptor -------------------------------------------------- Key: JBAS-4663 URL: http://jira.jboss.com/jira/browse/JBAS-4663 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta3 Use MBeanServerConnection instead to avoid pulling in a dependency. -- 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

18 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-992) Optional dependencies not marked as optional in maven pom xmls

by Tuomas Kiviaho (JIRA)

Optional dependencies not marked as optional in maven pom xmls -------------------------------------------------------------- Key: JBRULES-992 URL: http://jira.jboss.com/jira/browse/JBRULES-992 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.MR3 Environment: Maven 2.0.7 Reporter: Tuomas Kiviaho Assigned To: Mark Proctor Slimming (<http://markproctor.blogspot.com/2007/05/jboss-rules-even-slimmer.html>) could be taken even further by marking optional dependencies listed in <http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/README_DEPENDENCIES.txt> with <optional>true<optional/>. This would effectively remove transitional dependencies by default. Now I have to exclude them manually as a workaround. Having xerces and xml-apis as transitive dependencies reminds me of commons-logging 1.1 situation where container/JDK provided packages emerge in wrong places of classpath hierarchy. Here endorsement via provided scope is in my opinion more appropriate. XPP3 could probably be replaced with StaxDriver, thus replacing one dependency with JDK provided dependency, but this goes already into implementation details. -- 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

18 years, 10 months

3
11
0 / 0

[JBoss JIRA] Created: (JBAS-4668) Specifying java.naming.factory.initial and java.naming.provider.url for default in-container InitialContext

by Mike Millson (JIRA)

Specifying java.naming.factory.initial and java.naming.provider.url for default in-container InitialContext ----------------------------------------------------------------------------------------------------------- Key: JBAS-4668 URL: http://jira.jboss.com/jira/browse/JBAS-4668 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mike Millson Allow for a reference to the static NamingContext.localServer field to be returned from the org.jnp.interfaces.NamingContext.checkRef(Hashtable) method for a given java.naming.provider.url. Use cases exist where applications use property files to specify JNDI connection properties such as java.naming.factory.initial and java.naming.provider.url. The apps are written in such a way that require these properties be explicitly defined, even though the default in-container initial context is what will be used. Customers are currently specifying something like: java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.provider.url=jnp://abcxyz:1099/ However, this approach has several drawbacks, including: 1) Server names are hard-coded in property files, which reduces deployment flexibility 2) This approach appears to use a socket connection, which is probably not as efficient as the in-container initial context. For these use cases, customers would like to specify a value java.naming.factory.initial and java.naming.provider.url that will result in the default in-container InitialContext being used. Not specifying any properties will give this context, but the way some applications are written, something needs to be passed. -- 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

18 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1667) Problems for connecting a Weblogic 10 Portal WSRP Producer

by Mehmet Salgar (JIRA)

Problems for connecting a Weblogic 10 Portal WSRP Producer ---------------------------------------------------------- Key: JBPORTAL-1667 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1667 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal WSRP Affects Versions: 2.6.1 Final, 2.6 Final Environment: Microsoft Windows 2000 Sun JDK 1.5.06 JBoss Portal 2.6.1 Final JBoss Portal 2.6 Final Reporter: Mehmet Salgar Assigned To: Chris Laprun I have problem for connecting a Weblogic Portal 10 as a remote Producer. I am receiving a message 'ERROR [CallImpl] Call invocation failed with SOAPFaultException javax.xml.rpc.soap.SOAPFaultException: The given registrationHandle [null] is invalid.; nested exception is: java.lang.NumberFormatException: null' I have a simple Portal application for Weblogic Portal 10 which is inluding only a JSF portlet. When I try to connect from WSRP Admin portlet to the WSDL URL I am getting this exception. Funny part about it, I deployed the same portal application to the WLP 9.2 then I was able to access it with JBoss Portal without problem. Because of the some difficulties we are getting at WLP 9.2 I like to see the same portal at WLP 10, but we are getting this exception. I look to the WSDL off the WLP it looks like somethings are changed from 9.2 to 10, so I am guessing that is the reason for the problem. The reason that I report this as a bug, I think JBoss has to change something to stay compatible and draw attention to the problem. Btw, WLP 10 can connect to is own portlet as Remote Portlet over WSRP. So I think the implementation from Weblogic side is correct, at least for themselves. I would try to attach the Portal Project, while it is really simple and can function as reproducer and WLP 10 is freely downloadable for development purposes. -- 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

18 years, 10 months

2
19
0 / 0

[JBoss JIRA] Created: (JGRP-564) Unicast from within viewAccepted() callback throws exception in UNICAST

by Bela Ban (JIRA)

Unicast from within viewAccepted() callback throws exception in UNICAST ----------------------------------------------------------------------- Key: JGRP-564 URL: http://jira.jboss.com/jira/browse/JGRP-564 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 Unit test is UnicastUnitTest.testUnicastMessageInCallbackExistingMember(). Swapping lines 505 and 506 in GMS fixes the issue. Stack trace is below. The issue is that - since we propagate the new view up the stack first, then down - the viewAccepted() callback gets invoked first, before UNICAST can update its view (done when the new view is propagated down the stack). We need to investigate whether swapping lines 505 and 506 breaks JGRP-347 7:45:12,375 [WARN] [Incoming Thread,x,192.168.5.2:1959] JChannel.up(): failed calling viewAccepted() in receiver java.lang.RuntimeException: java.lang.IllegalArgumentException: 192.168.5.2:1961 is not a member of the group [192.168.5.2:1959] (enabled_members=[]) at org.jgroups.tests.UnicastUnitTest$MyReceiver.viewAccepted(UnicastUnitTest.java:84) at org.jgroups.JChannel.up(JChannel.java:1099) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:325) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:151) at org.jgroups.protocols.FRAG2.up(FRAG2.java:197) at org.jgroups.protocols.FC.up(FC.java:414) at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:505) at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:449) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:661) at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:160) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) at org.jgroups.protocols.UNICAST.up(UNICAST.java:263) at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:720) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:546) at org.jgroups.protocols.BARRIER.up(BARRIER.java:122) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167) at org.jgroups.protocols.FD.up(FD.java:322) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:298) at org.jgroups.protocols.MERGE2.up(MERGE2.java:145) at org.jgroups.protocols.Discovery.up(Discovery.java:247) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1486) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1435) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) -- 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

18 years, 10 months

1
2
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 September 2007