February 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8878) ModelTypeValidator should do more sophisticated type evaluations

by Brian Stansberry (JIRA)

ModelTypeValidator should do more sophisticated type evaluations ---------------------------------------------------------------- Key: JBAS-8878 URL: https://issues.jboss.org/browse/JBAS-8878 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.0.0.Beta1 ModelTypeValidator is doing an exact type match; it should be more sophisticated and accept nodes that will properly convert to the desired type. For example, a validator configured for ModelType.INT should accept ModelType.STRING if ModelNode.asInt() will work. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1292) UNICAST2: resend other messages when getting request to resend first message

by Bela Ban (JIRA)

UNICAST2: resend other messages when getting request to resend first message ---------------------------------------------------------------------------- Key: JGRP-1292 URL: https://issues.jboss.org/browse/JGRP-1292 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12 When A sends a unicast message to B, A's message #1 is tagged as first. This will create an entry in the receiver table of B. However, when A sends messages #1 and #2 concurrently, then #2 is probably processed first because #1 takes a bit more time to create the entry in the receiver table. When #2 is received by B, it is discarded, as it isn't tagged as 'first', and we send a request to A to resend the first seqno. However, until A sends message #3, or a stability message is received, A won't retransmit #2 to B. If A was an RPC, it might time out. SOLUTION: when asking A to resend the lowest seqno, we also pass in the seqno (#2) we received, that caused us to ask A for the resend. A will then resend all messages in the range [lowest .. seqno]. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-8877) Launch instance wizard: I get an error if I cancel the launch task

by Andre Dietisheim (JIRA)

Launch instance wizard: I get an error if I cancel the launch task ------------------------------------------------------------------ Key: JBAS-8877 URL: https://issues.jboss.org/browse/JBAS-8877 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Andre Dietisheim Attachments: canceled-the-launching.png -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBEE-74) jboss-jaxb-api_2.2_spec-1.0.0.Final missing Message.properties

by Alessio Soldano (JIRA)

jboss-jaxb-api_2.2_spec-1.0.0.Final missing Message.properties -------------------------------------------------------------- Key: JBEE-74 URL: https://issues.jboss.org/browse/JBEE-74 Project: JBoss JavaEE APIs Issue Type: Bug Reporter: Alessio Soldano Assignee: Shelly McGowan Looking at the jaxb api archive contents, I don't see the Message.properties in javax/xml/bind folder. That makes troubleshooting very hard, as whenever an error requiring a localized message occurs, the actual issue is masked by an exception regarding the properties file not being found. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
6
0 / 0

[JBoss JIRA] Closed: (JGRP-1291) jgroups.xsd does not define sym_provider for ENCRYPT protocol

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1291?page=com.atlassian.jira.plugin.... ] Bela Ban closed JGRP-1291. -------------------------- > jgroups.xsd does not define sym_provider for ENCRYPT protocol > ------------------------------------------------------------- > > Key: JGRP-1291 > URL: https://issues.jboss.org/browse/JGRP-1291 > Project: JGroups > Issue Type: Bug > Reporter: Manuel Dominguez Sarmiento > Assignee: Bela Ban > Priority: Minor > Fix For: 2.12 > > > asym_provider is defined, but sym_provider is not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Deleted: (JGRP-1291) jgroups.xsd does not define sym_provider for ENCRYPT protocol

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1291?page=com.atlassian.jira.plugin.... ] Bela Ban deleted JGRP-1291: --------------------------- > jgroups.xsd does not define sym_provider for ENCRYPT protocol > ------------------------------------------------------------- > > Key: JGRP-1291 > URL: https://issues.jboss.org/browse/JGRP-1291 > Project: JGroups > Issue Type: Bug > Reporter: Manuel Dominguez Sarmiento > Assignee: Bela Ban > Priority: Minor > > asym_provider is defined, but sym_provider is not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-1291) jgroups.xsd does not define sym_provider for ENCRYPT protocol

by Manuel Dominguez Sarmiento (JIRA)

jgroups.xsd does not define sym_provider for ENCRYPT protocol ------------------------------------------------------------- Key: JGRP-1291 URL: https://issues.jboss.org/browse/JGRP-1291 Project: JGroups Issue Type: Bug Affects Versions: 2.12 Reporter: Manuel Dominguez Sarmiento Assignee: Bela Ban Priority: Minor asym_provider is defined, but sym_provider is not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2707) Split up drools-guvnor into drools-guvnor-gwtclient and drools-guvnor(-server)

by Geoffrey De Smet (JIRA)

Split up drools-guvnor into drools-guvnor-gwtclient and drools-guvnor(-server) ------------------------------------------------------------------------------ Key: JBRULES-2707 URL: https://jira.jboss.org/browse/JBRULES-2707 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 5.1.1.FINAL Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: 5.2.0.M1 All classes/resources under the client/public package go to drools-guvnor-gwtclient. The drools-guvnor-gwtclient pom.xml - is of type war - has only the gwt dependencies All classes under the server package go to drools-guvnor(-server) The drools-guvnor(-server) pom.xml - is of type war - has a dependency on drools-guvnor-gwtclient (= war overlay!) - has dependencies on drools-core, drools-compiler (so on jdt too), ... What do we do with drools-ide-common and drools-factconstraints? Split them up to, or simply move the client package code into drools-guvnor? Where will the drools-ide-common and drools-factconstraints GWT modules be reused, besides in Guvnor? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
9
0 / 0

[JBoss JIRA] Created: (JBMETA-329) Using ejb-jar.xml for @Singleton bean

by Benoit Heinrich (JIRA)

Using ejb-jar.xml for @Singleton bean ------------------------------------- Key: JBMETA-329 URL: https://issues.jboss.org/browse/JBMETA-329 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBoss AS 6.0.0.Final Reporter: Benoit Heinrich Hi all, After talking on the forum about a problem with @Singleton and the use of ejb-jar.xml I've been instructed to open a bug report. An example project is available on the jboss forum post, and can be used to reproduce the problem here. Here is the stacktrace thrown by jboss when deploying the attached sample project: {code} 12:48:35,699 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Real: name=vfs:///opt/src/jboss-6.0.0.Final/server/default/deploy/02-startup.ear state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error during deploy: org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.StartupBean at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) [:2.2.0.GA] at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:185) [:2.2.0.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1603) [:2.2.0.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA] at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA] at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA] at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA] at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final] at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2] at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2] at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2] at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2] at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2] at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2] at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_22] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_22] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_22] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_22] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_22] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_22] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22] at java.lang.Thread.run(Thread.java:680) [:1.6.0_22] Caused by: java.lang.RuntimeException: Could not resolve @EJB reference: [EJB Reference: beanInterface 'com.example.services.version.VersionManager', beanName 'null', mappedName 'null', lookupName 'null', owning unit 'ComponentDeploymentContext(a)10824652{org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.StartupBean}'] for environment entry: env/ejb/VersionManager in unit ComponentDeploymentContext(a)10824652{org.jboss.metadata.ejb.jboss.JBossEnterpriseBeanMetaData.StartupBean} at org.jboss.ejb3.jndi.deployers.resource.provider.AnnotatedEJBRefResourceProvider.provide(AnnotatedEJBRefResourceProvider.java:99) [:0.1.7] at org.jboss.ejb3.jndi.deployers.resource.provider.AnnotatedEJBRefResourceProvider.provide(AnnotatedEJBRefResourceProvider.java:50) [:0.1.7] at org.jboss.switchboard.mc.JndiEnvironmentProcessor.process(JndiEnvironmentProcessor.java:68) [:1.0.0-alpha-15] at org.jboss.switchboard.mc.deployer.AbstractSwitchBoardDeployer.process(AbstractSwitchBoardDeployer.java:119) [:1.0.0-alpha-15] at org.jboss.switchboard.mc.deployer.EJBEnvironmentSwitchBoardDeployer.internalDeploy(EJBEnvironmentSwitchBoardDeployer.java:87) [:1.0.0-alpha-15] at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA] at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA] ... 39 more {code} I hope it won't be too hard to fix it. Cheers, /Benoit -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-1288) FD_SOCK ignores port_range when opening server sockets

by Manuel Dominguez Sarmiento (JIRA)

FD_SOCK ignores port_range when opening server sockets ------------------------------------------------------ Key: JGRP-1288 URL: https://issues.jboss.org/browse/JGRP-1288 Project: JGroups Issue Type: Bug Affects Versions: 2.12 Reporter: Manuel Dominguez Sarmiento Assignee: Bela Ban Priority: Minor FD_SOCK.startServerSocket() calls Util.createServerSocket(), which does not take into account a port_range. The docs for FD_SOCK state that port_range applies both for client and server socket ports. The configured value should be used instead of incrementing the port number until a free port can be bound to. Also, the port number keeps incrementing - there's no check for MAX_PORT i.e. 65535 which could mean this could loop forever, unless an IOException is thrown before because of an invalid port number, but I don't know whether this is specified anywhere. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
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 February 2011