August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (EJBTHREE-629) need to get remote binding uri from Connector for default

by Andrew Rubinger (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-629?page=comments#action_12342380 ] Andrew Rubinger commented on EJBTHREE-629: ------------------------------------------ Proposed fix outlined in http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3968474#3968474. > need to get remote binding uri from Connector for default > --------------------------------------------------------- > > Key: EJBTHREE-629 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-629 > Project: EJB 3.0 > Issue Type: Task > Affects Versions: EJB 3.0 RC8 - FD > Reporter: Andrea Luciano > Assigned To: Bill Burke > Fix For: EJB 3.0 RC2, EJB 3.0 RC9 - FD > > > The issue http://jira.jboss.com/jira/browse/EJBTHREE-204 reopen. > I downloaded jboss 4.0.4 GA and jboss-EJB-3.0_RC8-FD. > I installed jboss and ejb3 support than I tryed to modify the standard port 3873 so I changed the file deploy/ejb3.deployer/META-INF/jboss-service.xml: > <mbean code="org.jboss.remoting.transport.Connector" > xmbean-dd="org/jboss/remoting/transport/Connector.xml" > name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3"> > <depends>jboss.aop:service=AspectDeployer</depends> > <attribute name="InvokerLocator">socket://${jboss.bind.address}:10009</attribute> > <attribute name="Configuration"> > <handlers> > <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler> > </handlers> > </attribute> > </mbean> > While the server listens correctly on new port the client has no way to contact the bean I deployed. > Using strace I figured out that the client ignores the new port and tries to contact port 3873 as before RC3 of ejb3 support (while another installation with ejb3 rc3 works without problems). > Is this a regression? > Regards. > Andrea -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-440) Unable remove a rule package when it was added after it has been added and removed

by song hanzeng (JIRA)

Unable remove a rule package when it was added after it has been added and removed ---------------------------------------------------------------------------------- Key: JBRULES-440 URL: http://jira.jboss.com/jira/browse/JBRULES-440 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Environment: Windows2000 Advanced Server JBRules3.0.4 Reporter: song hanzeng Assigned To: Mark Proctor Unable remove a rule package when it was added after it has been added and removed. I have seen the issue [#JBRULES-358]. My test go a little far than [#JBRULES-358]. I remove the package again when it was added for the seconn time, then an exception was thrown. My test case is: public void testRuleBaseRemove() throws Exception { RuleBase ruleBase = RuleBaseFactory.newRuleBase(); File file = new File("test.drl"); //add and remove PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl(new FileReader(file)); Package pkg = builder.getPackage(); ruleBase.addPackage(pkg); ruleBase.removePackage(pkg.getName()); //add and remove again builder = new PackageBuilder(); builder.addPackageFromDrl(new FileReader(file)); pkg = builder.getPackage(); ruleBase.addPackage(pkg); ruleBase.removePackage(pkg.getName()); } the exception is throw: java.lang.NullPointerException at org.drools.reteoo.HashedObjectSinkList.remove(HashedObjectSinkList.java:102) at org.drools.reteoo.ObjectTypeNode.remove(ObjectTypeNode.java:245) at org.drools.reteoo.AlphaNode.remove(AlphaNode.java:211) at org.drools.reteoo.AlphaNode.remove(AlphaNode.java:211) at org.drools.reteoo.LeftInputAdapterNode.remove(LeftInputAdapterNode.java:285) at org.drools.reteoo.TerminalNode.remove(TerminalNode.java:297) at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:589) at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:244) at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:338) at com.zte.ums.uep.pal.fm.osf.rules.core.RuleBaseTest.testRuleBaseRemove(RuleBaseTest.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- 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

19 years, 11 months

2
3
0 / 0

[JBoss JIRA] Commented: (JBPM-614) delete sub process instances recursively

by Keejbo Jbooger (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-614?page=comments#action_12342375 ] Keejbo Jbooger commented on JBPM-614: ------------------------------------- Why is this considered a bug? Now, if I delete a process p1 that uses sub-process p2, then any other processes that refer to p2 will be invalid. Wouldn't it be better to leave p2 around for cases where it is run independently or used in another process? > delete sub process instances recursively > ---------------------------------------- > > Key: JBPM-614 > URL: http://jira.jboss.com/jira/browse/JBPM-614 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Fix For: jBPM 3.2 alpha 1, jBPM 3.1.1 > > > this has to be verified first if it is actually a bug. but the stacktrace that was provided by a customer made me think in this direction. > When a process instance is deleted, we should first scan all tokens of the process for subprocess instances and delete those first (recursively) -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-485) CTSMiscellaneousTest.testContestedQueueOnRollback temporarily commented out

by Ovidiu Feodorov (JIRA)

CTSMiscellaneousTest.testContestedQueueOnRollback temporarily commented out --------------------------------------------------------------------------- Key: JBMESSAGING-485 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-485 Project: JBoss Messaging Issue Type: Task Components: JMS Facade Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Minor Fix For: 1.0.1.CR5 CTSMiscellaneousTest.testContestedQueueOnRollback temporarily is temporarily commented out until after CR4. It must be cleaned to make it semantically correct. -- 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

19 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-459) Literal constraint using 'null' triggers a NPE.

by Serge Brisson (JIRA)

Literal constraint using 'null' triggers a NPE. ----------------------------------------------- Key: JBRULES-459 URL: http://jira.jboss.com/jira/browse/JBRULES-459 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.4 Environment: Windows XP SP2. Reporter: Serge Brisson Assigned To: Mark Proctor The following triggers the problem: rule "Drops null results" when $result: Result(value == null) then retract($result); end Stack trace: java.lang.NullPointerException at org.drools.base.evaluators.ArrayFactory$ArrayEqualEvaluator.evaluate(Unknown Source) at org.drools.rule.LiteralConstraint.isAllowed(Unknown Source) at org.drools.reteoo.AlphaNode.assertObject(Unknown Source) at org.drools.reteoo.ObjectSource.propagateAssertObject(Unknown Source) at org.drools.reteoo.ObjectTypeNode.assertObject(Unknown Source) at org.drools.reteoo.Rete.assertObject(Unknown Source) at org.drools.reteoo.ReteooRuleBase.assertObject(Unknown Source) at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(Unknown Source) at org.drools.common.AbstractWorkingMemory.assertObject(Unknown Source) at org.drools.common.AbstractWorkingMemory.assertObject(Unknown Source) at org.drools.jsr94.rules.StatelessRuleSessionImpl.executeRules(Unknown Source) at org.drools.jsr94.rules.StatelessRuleSessionImpl.executeRules(Unknown Source) at org.rvpf.rules.ServiceProviderTests.testStatelessSession(ServiceProviderTests.java:130) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:552) at org.testng.internal.Invoker.invokeMethod(Invoker.java:411) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:785) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:114) at org.testng.TestRunner.privateRun(TestRunner.java:695) at org.testng.TestRunner.run(TestRunner.java:574) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:241) at org.testng.SuiteRunner.run(SuiteRunner.java:145) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:901) at org.testng.TestNG.runSuitesLocally(TestNG.java:863) at org.testng.TestNG.run(TestNG.java:613) at org.rvpf.tests.FrameworkTests.main(FrameworkTests.java:132) The following is a successful work-around: rule "Drops null results" when $result: Result() eval($result.getValue() == null) then retract($result); end -- 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

19 years, 11 months

2
7
0 / 0

[JBoss JIRA] Created: (JBSEAM-341) Support for Regex-es in pages.xml

by Raja (JIRA)

Support for Regex-es in pages.xml --------------------------------- Key: JBSEAM-341 URL: http://jira.jboss.com/jira/browse/JBSEAM-341 Project: JBoss Seam Issue Type: Feature Request Components: JSF Reporter: Raja Currently the pages.xml supports wildcards but that too very limited(ending with *). If we have support for Regex-es in pages.xml , that would help the developers write page actions that can match a particular viewid. For e.g. I was trying to create a filter that will make my application go to the login page for any request but the login.seam page. Having a regex support for pages.xml will make this easier. An alternative solution would be to have an except attribute that indicates that the page actions should be performed for all the view-ids that match it but except the ones in the "except" attribute. -- 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

19 years, 11 months

2
1
0 / 0

[JBoss JIRA] Resolved: (JBPORTAL-602) DivDecorationRenderer renders broken titlebar when browser window is small

by Roy Russo (JIRA)

[ http://jira.jboss.com/jira/browse/JBPORTAL-602?page=all ] Roy Russo resolved JBPORTAL-602. -------------------------------- Fix Version/s: 2.6.Alpha1 (was: 2.6 Final) Resolution: Done Assignee: Roy Russo Fixed in IE and FF. > DivDecorationRenderer renders broken titlebar when browser window is small > -------------------------------------------------------------------------- > > Key: JBPORTAL-602 > URL: http://jira.jboss.com/jira/browse/JBPORTAL-602 > Project: JBoss Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Portal Portlet, Portal Theme > Affects Versions: 2.2 Final > Environment: IE 6 client > Reporter: Steve Dunstan > Assigned To: Roy Russo > Priority: Trivial > Fix For: 2.6.Alpha1 > > Attachments: Firefox screen .jpg > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > If the browser window is small enough using the DivRenderSet the "left" region breaks (the borders are misaligned.) To fix, the portlet-titlebar-decoration div needs to be cosed before the portlet-titlebar-title span. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (EJBTHREE-629) need to get remote binding uri from Connector for default

by Andrew Rubinger (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-629?page=comments#action_12342366 ] Andrew Rubinger commented on EJBTHREE-629: ------------------------------------------ Use case against Branch_4_0 noted in http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3968428#3968428. > need to get remote binding uri from Connector for default > --------------------------------------------------------- > > Key: EJBTHREE-629 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-629 > Project: EJB 3.0 > Issue Type: Task > Affects Versions: EJB 3.0 RC8 - FD > Reporter: Andrea Luciano > Assigned To: Bill Burke > Fix For: EJB 3.0 RC2, EJB 3.0 RC9 - FD > > > The issue http://jira.jboss.com/jira/browse/EJBTHREE-204 reopen. > I downloaded jboss 4.0.4 GA and jboss-EJB-3.0_RC8-FD. > I installed jboss and ejb3 support than I tryed to modify the standard port 3873 so I changed the file deploy/ejb3.deployer/META-INF/jboss-service.xml: > <mbean code="org.jboss.remoting.transport.Connector" > xmbean-dd="org/jboss/remoting/transport/Connector.xml" > name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3"> > <depends>jboss.aop:service=AspectDeployer</depends> > <attribute name="InvokerLocator">socket://${jboss.bind.address}:10009</attribute> > <attribute name="Configuration"> > <handlers> > <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler> > </handlers> > </attribute> > </mbean> > While the server listens correctly on new port the client has no way to contact the bean I deployed. > Using strace I figured out that the client ignores the new port and tries to contact port 3873 as before RC3 of ejb3 support (while another installation with ejb3 rc3 works without problems). > Is this a regression? > Regards. > Andrea -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-951) Navigation portlet incorrectly wraps in smaller resolution

by Roy Russo (JIRA)

Navigation portlet incorrectly wraps in smaller resolution ---------------------------------------------------------- Key: JBPORTAL-951 URL: http://jira.jboss.com/jira/browse/JBPORTAL-951 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.4 Final Reporter: Roy Russo Assigned To: Roy Russo Rendering must be modified to not break the page. -- 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

19 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBIDE-355) jdk15 code used in jbossas adapter

by Max Andersen (JIRA)

jdk15 code used in jbossas adapter ---------------------------------- Key: JBIDE-355 URL: http://jira.jboss.com/jira/browse/JBIDE-355 Project: JBoss IDE Issue Type: Bug Components: JBossAS Adapter Affects Versions: 2.0.0.Beta1 Reporter: Max Andersen Assigned To: Robert Stryker Caused by: java.lang.NoSuchMethodError: java.lang.Class.getSimpleName()Ljava/lang/String; at org.jboss.ide.eclipse.as.core.util.ASDebug.p(ASDebug.java:32) getSimpleName is jdk 1.5 only. you do run with jdk 1.4 compiler check for your plugins, right ? :) see full story here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968413#3968413 -- 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

19 years, 11 months

2
1
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 August 2006