April 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBEE-29) Add jaxrpc-api_1.1_spec

by Richard Opalka (JIRA)

Add jaxrpc-api_1.1_spec ----------------------- Key: JBEE-29 URL: https://jira.jboss.org/jira/browse/JBEE-29 Project: JBoss JavaEE APIs Issue Type: Sub-task Reporter: Richard Opalka Assignee: Shelly McGowan Fix For: 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

15 years, 9 months

3
9
0 / 0

[JBoss JIRA] Created: (JBAS-7984) DataSource UNKNOWN run state

by Emanuel Muckenhuber (JIRA)

DataSource UNKNOWN run state ---------------------------- Key: JBAS-7984 URL: https://jira.jboss.org/jira/browse/JBAS-7984 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-6.0.0.M2, JBossAS-5.1.0.GA Reporter: Emanuel Muckenhuber Assignee: Emanuel Muckenhuber Fix For: JBossAS-6.0.0.M3 -- 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

15 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-6335) EjbModule is already installed

by Henrik Lindell (JIRA)

EjbModule is already installed ------------------------------ Key: JBAS-6335 URL: https://jira.jboss.org/jira/browse/JBAS-6335 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployers Affects Versions: JBossAS-5.0.0.GA Environment: Windows XP jdk1.6.0_11 Reporter: Henrik Lindell Assignee: Ales Justin Priority: Blocker When deploying 2 EARs containing each an ejb 2.x jar with the same name ("my-ejbs.jar") deployment fails with this stack trace when the second is handled by the EjbDeployer. The BasicMBeanRegistry tries to register them both with the name "jboss.j2ee:module="my-ejbs.jar",service=EjbModule" 14:33:27,796 WARN [AbstractDeploymentContext] Unable to register deployment mbean jboss.j2ee:module="my-ejbs.jar",service=EjbModule javax.management.InstanceAlreadyExistsException: jboss.deployment:id="jboss.j2ee:module="my-ejbs.jar",service=EjbModule",type=Component already registered. at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:767) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:236) at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376) at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.registerMBeans(AbstractDeploymentContext.java:989) at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext.addComponent(AbstractDeploymentContext.java:719) at org.jboss.deployers.structure.spi.helpers.AbstractDeploymentUnit.addComponent(AbstractDeploymentUnit.java:249) at org.jboss.system.deployers.ServiceDeploymentDeployer.addServiceComponent(ServiceDeploymentDeployer.java:62) at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:150) at org.jboss.system.deployers.ServiceDeploymentDeployer$ServiceMetaDataVisitor.deploy(ServiceDeploymentDeployer.java:141) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployerWithInput.deploy(AbstractRealDeployerWithInput.java:125) at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.deployComponents(AbstractComponentDeployer.java:102) at org.jboss.deployers.spi.deployer.helpers.AbstractComponentDeployer.internalDeploy(AbstractComponentDeployer.java:82) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405) at org.jboss.Main.boot(Main.java:209) at org.jboss.Main$1.run(Main.java:547) at java.lang.Thread.run(Thread.java:619) 14:33:27,828 INFO [TomcatDeployment] deploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war 14:33:28,046 WARN [TomcatDeployment] Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/pojo/jmx/PojoCacheJmxWrapperMBean 14:33:28,125 INFO [EjbModule] Deploying AbcSLS 14:33:28,203 INFO [ProxyFactory] Bound EJB Home 'AbcSLS' to jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc' 14:33:28,218 INFO [ProxyFactory] Unbind EJB Home 'AbcSLS' from jndi 'xyz/abc-6-0-4/internal/ejb/session/Abc' 14:33:28,218 INFO [EjbModule] Undeployed AbcSLS 14:33:28,218 INFO [TomcatDeployment] undeploy, ctxPath=/abc-6-0-4, vfsUrl=my-ear-6-0-4.ear/webApp.war 14:33:31,015 ERROR [AbstractKernelController] Error installing to Real: name=vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ state=PreReal mode=Manual requiredState=Real org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.j2ee:service=EjbModule,module="my-ejbs.jar" at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:123) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:45) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:304) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:205) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:405) at org.jboss.Main.boot(Main.java:209) at org.jboss.Main$1.run(Main.java:547) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed. at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540) at org.jboss.system.ServiceController.doInstall(ServiceController.java:670) at org.jboss.system.ServiceController.install(ServiceController.java:273) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:95) ... 24 more 14:33:31,093 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): *** CONTEXTS IN ERROR: Name -> Error vfsfile:/C:/develop/server/jboss-5.0.0.GA.JDK6/server/standard/deploy/my-ear-6-0-4.ear/ -> java.lang.IllegalStateException: jboss.j2ee:module="my-ejbs.jar",service=EjbModule is already installed. 14:33:31,109 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080 14:33:31,140 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009 14:33:31,140 INFO [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag=JBoss_5_0_0_GA date=200812042120)] Started in 1m:40s:531ms -- 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

15 years, 10 months

6
10
0 / 0

[JBoss JIRA] Created: (JBAS-7096) SLSB with dependency on HASingletonDeployer / Barrier results in error message on second node on startup

by Richard Taylor (JIRA)

SLSB with dependency on HASingletonDeployer / Barrier results in error message on second node on startup -------------------------------------------------------------------------------------------------------- Key: JBAS-7096 URL: https://jira.jboss.org/jira/browse/JBAS-7096 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-5.1.0.GA Environment: RHEL 4 Update 7 (and OSX 10.5.7), Sun JRE 1.6.0_12, JBoss 5.1.0 - "all" configuration Reporter: Richard Taylor Assignee: Brian Stansberry Priority: Minor Basic cluster, two JBoss 5.1.0 nodes, "all" configuration. First node starts fine. Second node starts, however at the end of starting, any SLSBs that depend on the barrier result in an error being logged at startup (on the second node). Example: DEPLOYMENTS MISSING DEPENDENCIES: Deployment "jboss.j2ee:ear=app-ear.ear,jar=app-ejb.jar,name=BoardPollerMDB,service=EJB3" is missing the following dependencies: Dependency "<UNKNOWN jboss.j2ee:ear=app-ear.ear,jar=app-ejb.jar,name=BoardPollerMDB,service=EJB3>" (should be in state "Described", bu t is actually in state "** UNRESOLVED Demands 'jboss.ha:service=HASingletonDeployer,type=Barrier' **") DEPLOYMENTS IN ERROR: Deployment "<UNKNOWN jboss.j2ee:ear=app-ear.ear,jar=app-ejb.jar,name=BoardPollerMDB,service=EJB3>" is in error due to the following reas on(s): ** UNRESOLVED Demands 'jboss.ha:service=HASingletonDeployer,type=Barrier' ** The SLSBs on node 2 do properly start in a failover scenario when node 1 goes down. So functionally things seem OK. However the error message is a little concerning and it leaves us wondering if there is more to the problem. -- 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

15 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (JBAS-4753) ExternalContext needs pass proxy interface set to the Proxy.newProxyInstance(loader, interfaces, handler); in createProxyContext method.

by Vicky Kak (JIRA)

ExternalContext needs pass proxy interface set to the Proxy.newProxyInstance(loader, interfaces, handler); in createProxyContext method. ---------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-4753 URL: http://jira.jboss.com/jira/browse/JBAS-4753 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.5.GA Reporter: Vicky Kak Fix For: JBossAS-5.0.0.Beta3 In the ExternalContext Classes.getAllInterfaces(ifaces, ctx.getClass()); can populate the ifaces with the duplicate Interface entries . When the ifaces with duplicate Interface entries is passed to the Proxy.newProxyInstance(loader, interfaces, handler); it results in the exception >>java.lang.IllegalArgumentException: repeated interface: -- 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

15 years, 10 months

2
7
0 / 0

[JBoss JIRA] Created: (JBCOMMON-98) Release jboss-common 1.2.2.GA

by Dimitris Andreadis (JIRA)

Release jboss-common 1.2.2.GA ----------------------------- Key: JBCOMMON-98 URL: https://jira.jboss.org/jira/browse/JBCOMMON-98 Project: JBoss Common Issue Type: Release Security Level: Public (Everyone can see) Components: common-old (1.x) Reporter: Dimitris Andreadis Assignee: Dimitris Andreadis Fix For: 1.2.2.GA -- 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

15 years, 10 months

1
5
0 / 0

[JBoss JIRA] Created: (JBCOMMON-108) CVE-2009-2693

by Mike Millson (JIRA)

CVE-2009-2693 ------------- Key: JBCOMMON-108 URL: https://jira.jboss.org/jira/browse/JBCOMMON-108 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Components: common-old (1.x) Affects Versions: 1.2.1.GA, 1.0.0.GA Reporter: Mike Millson CVE-2009-2693: When deploying WAR files, the WAR files were not checked for directory traversal attempts. This allows an attacker to create arbitrary content outside of the web root by including entries such as ../../bin/catalina.sh in the WAR. -- 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

15 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-983) @EJB injection fails, RuntimeException, IllegalArgumentException

by dpocock (JIRA)

@EJB injection fails, RuntimeException, IllegalArgumentException ---------------------------------------------------------------- Key: EJBTHREE-983 URL: http://jira.jboss.com/jira/browse/EJBTHREE-983 Project: EJB 3.0 Issue Type: Bug Components: EJB3 Extensions Affects Versions: AS 4.2.0 GA, EJB 3.0 RC9 - Patch 1 Environment: Debian Linux, Sun Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Reporter: dpocock Similar to bug EJBTHREE-862. However, setting `Isolated' to false in $JBOSS_HOME/server/XXX/deploy/ear-deployer.xml does not resolve the issue for me. Here is the scenario: There are two applications, app1.ear and app2.ear. app1.ear contains a stateless session bean, App1Bean, with local and remote interface app2.ear contains a stateless session bean, App2Bean, which has a field defined like so: @EJB(mappedName="app1/App1Bean/local") // I've tried local and remote com.app1.ejb.session.App1 app1; app1.ear and app2.ear are loaded successfully by the application server. When App2Bean is activated, JBoss tries to perform the injections. At this point, the RuntimeException (see stack below) occurs. App2Bean can successfully obtain a reference to app1 bean using the traditional JNDI lookup methods. This is a workaround. When inspecting the stack, notice the presence of IllegalArgumentException, even though the interface matches. 16:22:12,155 ERROR [STDERR] java.lang.RuntimeException: Non matching type for inject of field: App1Bean app1 for type: $Proxy79 of jndiName env/App2Bean/app2 intfs: , App1, org.jboss.ejb3.JBossProxy, javax.ejb.EJBObject 16:22:12,155 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:135) 16:22:12,155 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:104) 16:22:12,155 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:61) 16:22:12,155 ERROR [STDERR] at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:92) 16:22:12,155 ERROR [STDERR] at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48) 16:22:12,165 ERROR [STDERR] at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:209) 16:22:12,165 ERROR [STDERR] at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:303) 16:22:12,165 ERROR [STDERR] at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106) 16:22:12,165 ERROR [STDERR] at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) 16:22:12,175 ERROR [STDERR] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828) 16:22:12,175 ERROR [STDERR] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681) 16:22:12,175 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358) 16:22:12,175 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412) 16:22:12,175 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239) 16:22:12,185 ERROR [STDERR] Caused by: java.lang.IllegalArgumentException 16:22:12,185 ERROR [STDERR] at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63) 16:22:12,185 ERROR [STDERR] at java.lang.reflect.Field.set(Field.java:656) 16:22:12,185 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:119) 16:22:12,185 ERROR [STDERR] ... 13 more -- 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

15 years, 10 months

5
5
0 / 0

[JBoss JIRA] Created: (JBAS-6627) The JMX console /MBean Inspector page doesn't handle org.w3c.dom.Element correctly

by Howard Gao (JIRA)

The JMX console /MBean Inspector page doesn't handle org.w3c.dom.Element correctly ---------------------------------------------------------------------------------- Key: JBAS-6627 URL: https://jira.jboss.org/jira/browse/JBAS-6627 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX/Web Console Affects Versions: JBossAS-4.2.3.GA Reporter: Howard Gao Assignee: Darran Lofthouse When a mbean is opened in the MBeanInspector page, if the mbean has attributes that are of type org.w3c.dom.Element, the corresponding input field cannot display them correctly if the element's value contains special characters like ' (quote). Special characters in this case should be converted to html code in order to be displayed properly on the web browser. See related jira https://jira.jboss.org/jira/browse/JBMESSAGING-1517. -- 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

15 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (JBBUILD-526) Add "all" profile to generate and include javadocs in AS build

by Paul Gier (JIRA)

Add "all" profile to generate and include javadocs in AS build -------------------------------------------------------------- Key: JBBUILD-526 URL: https://jira.jboss.org/jira/browse/JBBUILD-526 Project: JBoss Build System Issue Type: Task Reporter: Paul Gier Assignee: Paul Gier Fix For: Maven Build - App Server (Phase 3) The AS build does not currently have the equivalent of the "all" target in the old ant build. This basically involves setting up a profile to call the javadoc plugin, and then updating build-distr.xml to copy the generated javadocs. -- 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

15 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (JBBUILD-543) Look into jarring resources from various AS modules.

by Paul Gier (JIRA)

Look into jarring resources from various AS modules. ---------------------------------------------------- Key: JBBUILD-543 URL: https://jira.jboss.org/jira/browse/JBBUILD-543 Project: JBoss Build System Issue Type: Task Reporter: Paul Gier Assignee: Paul Gier Fix For: Maven Build - App Server (Phase 3) Some of the AS modules generate an output directory called "resources". These should be divided into main and test resources, and possibly put into jar files so that they can be put in the maven repository. -- 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

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7291) Reduce memory usuage

by Scott Marlow (JIRA)

Reduce memory usuage -------------------- Key: JBAS-7291 URL: https://jira.jboss.org/jira/browse/JBAS-7291 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.2.0.Beta1 Reporter: Scott Marlow Fix For: JBossAS-6.0.0.Alpha1 This is an umbrella jira for all projects that are part of the application server. 6mb of memory used by 109, 552 instances of org.jboss.logging.Logger (these numbers include objects referenced by the Logger instances) 65.5mb org.jboss.mx.server.MBeanServerImpl 30mb org.jboss.virtual.plugins.context.zip.ZipEntryContext$EntryInfo Other details to be added -- 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

15 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (JGRP-1188) Probe.sh does not display matches summary on termination.

by Richard Achmatowicz (JIRA)

Probe.sh does not display matches summary on termination. --------------------------------------------------------- Key: JGRP-1188 URL: https://jira.jboss.org/jira/browse/JGRP-1188 Project: JGroups Issue Type: Bug Affects Versions: 2.4.7 Reporter: Richard Achmatowicz Assignee: Bela Ban Priority: Minor Fix For: 2.4.8 Matched statistics are not appearing at the end of the probe.sh output - when probe.sh, with the -match option specified, terminates, I should only see responses which contain the match string, and should see a summary line something like: Total responses=1, 1 matches, 3 non-matches This reflects how many responses were matched with the -match <match string> parameter. For example: [rachmatowicz@vmg18 bin]$ ./probe.sh -match Tomcat-Cluster -- send probe on /224.0.75.75:7500 #1 (262 bytes): 10.16.95.19:44066 (Tomcat-Cluster) local_addr=10.16.95.19:44066 group_name=Tomcat-Cluster version=2.4.7.GA, cvs="$Id: Version.java,v 1.42.2.14 2009/11/03 23:15:25 rachmatowicz Exp $" view: [10.16.95.19:44066|0] [10.16.95.19:44066] group_addr=239.11.12.13:45577 Here, the responses were correctly matched, but no summary line is produded. This summary line is not appearing, because a thread set up to close the multicast socket after timeout seconds is causing the multicast socket to generate an exception and return, before the control loop can be exited and the summary line printed. Moving the summary line into the exception handling code fixes the problem. -- 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

15 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-1121) Leverage JAXB to the full extent

by Vladimir Blagojevic (JIRA)

Leverage JAXB to the full extent -------------------------------- Key: JGRP-1121 URL: https://jira.jboss.org/jira/browse/JGRP-1121 Project: JGroups Issue Type: Task Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 2.9 Since we are going to base 2.9 release on JDK 6 we can use JAXB for configuration reading, XSD schema and documentation generation. -- 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

15 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JGRP-1102) Invalid hyperlink in error message

by Brian Stansberry (JIRA)

Invalid hyperlink in error message ---------------------------------- Key: JGRP-1102 URL: https://jira.jboss.org/jira/browse/JGRP-1102 Project: JGroups Issue Type: Bug Affects Versions: 2.7, 2.6.13, 2.4.7 Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: 2.6.14, 2.8, 2.4.7 As reported by Rado Husar on JBPAPP-3117: > Setting an incorrent mcast_addr results in the exception below, which points to stale location: > > http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking > > [JBoss] 05:57:35,544 WARN [UDP] could not bind to /234.1.78.86 (IPv4 address); make sure your mcast_addr is of the same type as the preferred IP stack (IPv4 or IPv6) by checking the value of the system properties java.net.preferIPv4Stack and java.net.preferIPv6Addresses. > [JBoss] Will ignore mcast_addr, but this may lead to cross talking (see http://www.jboss.com/wiki/Edit.jsp?page=CrossTalking for details). > [JBoss] Exception was: java.net.BindException: Cannot assign requested address I'll change this to the permanent (knock on wood) URL for this page: https://www.jboss.org/community/docs/DOC-9469 -- 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

15 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2326) request to improve upon error message received from invalid rule syntax (currently getting NPE)

by Jeremy Ary (JIRA)

request to improve upon error message received from invalid rule syntax (currently getting NPE) ----------------------------------------------------------------------------------------------- Key: JBRULES-2326 URL: https://jira.jboss.org/jira/browse/JBRULES-2326 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.1.0.M1 Reporter: Jeremy Ary Assignee: Mark Proctor My (albeit improper) rule syntax that caused the NPE error: when QueueList ( queueIds contains 1 ) ( not EventList ( events contains 1 ) || ( $eventList : EventList ( events contains 1 ) && RfEvent ( eventTypeId == 1, lastActivationLong after[-1h] sessionTime ) from $eventList.events ) ) then modify (eventList) { add(1) } Stack Trace: org.drools.runtime.rule.ConsequenceException: java.lang.NullPointerException at org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:23) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:943) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:885) at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1086) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:660) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:627) at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:183) at com.famc.service.RuleFlowRunner.main(RuleFlowRunner.java:118) Caused by: java.lang.NullPointerException at org.drools.base.mvel.DroolsMVELFactory.getTupleObjectFor(DroolsMVELFactory.java:182) at org.drools.base.mvel.DroolsMVELFactory.setContext(DroolsMVELFactory.java:176) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:57) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:934) ... 6 more Request for ticket: [10:19] <etirelli> jary: raising a NPE is clearly a bug, but the reason is that you have modify(eventList) instead of modify($eventList)... in any case, the way you authored the rule is not ideal [10:19] <etirelli> jary: could you please open a JIRA so that we can provide an appropriate error message, please? -- 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

15 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-2268) Unknown Parser Error when spreading rule condition over multiple lines

by Jeremy Ary (JIRA)

Unknown Parser Error when spreading rule condition over multiple lines ---------------------------------------------------------------------- Key: JBRULES-2268 URL: https://jira.jboss.org/jira/browse/JBRULES-2268 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.0.CR1 Environment: XP-SP3, eclipse 3.4.2, 5.0.0.CR1 Reporter: Jeremy Ary Assignee: Mark Proctor Full message: Unknown error while parsing. This is a bug. Please contact the Development team. To recreate: I broke a condition over multiple lines and mistakenly misgrouped my parentheses, leading to an unknown error while parsing: {code} rule "recreate bug" when Loan ( amount >= 175000 ) && ( program == "FHA" ) ) then modify (queueList) { add (QueueIds.UWENTRY) } end {code} When corrected to the following, the rule is parsed properly: {code} rule "recreate bug" when Loan ( ( amount >= 175000 ) && ( program == "FHA" ) ) then modify (queueList) { add (QueueIds.UWENTRY) } end {code} -- 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

15 years, 10 months

2
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2041) Refactor the concurrency module into a component

by jaikiran pai (JIRA)

Refactor the concurrency module into a component ------------------------------------------------ Key: EJBTHREE-2041 URL: https://jira.jboss.org/jira/browse/EJBTHREE-2041 Project: EJB 3.0 Issue Type: Task Components: concurrency Reporter: jaikiran pai Assignee: jaikiran pai The concurrency module currently consists of a EJBReadWriteLock and AOP based interceptors. The AOP interceptors need to be split out into a separate module. -- 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

15 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2019) Refactor java:comp

by Carlo de Wolf (JIRA)

Refactor java:comp ------------------ Key: EJBTHREE-2019 URL: https://jira.jboss.org/jira/browse/EJBTHREE-2019 Project: EJB 3.0 Issue Type: Task Reporter: Carlo de Wolf Fix For: EJB 3.1 The container should no longer be responsible for creating java:comp, but should use the java:comp created by the namespace deployers. (This is to allow a shared java:comp in web deployments and have other services augment a java:comp space.) -- 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

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7068) Wrong timeout-valiue in OracleValidConnectionChecker

by Christian Daszenies (JIRA)

Wrong timeout-valiue in OracleValidConnectionChecker ---------------------------------------------------- Key: JBAS-7068 URL: https://jira.jboss.org/jira/browse/JBAS-7068 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-5.1.0.GA Reporter: Christian Daszenies Assignee: Jesper Pedersen OracleValidConnectionChecker calls oracle.jdbc.driver.OracleConnection.pingDatabase(5000) - 5000 is used as timeout in seconds! by pingDatabase furthermore it would be nice if the timeout would be configurable (or at least easy to override) -- 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

15 years, 10 months

5
4
0 / 0

[JBoss JIRA] Created: (JBVFS-134) IterableTimedVFSCache doesn't cache entries once they get expired

by Toshiya Kobayashi (JIRA)

IterableTimedVFSCache doesn't cache entries once they get expired ----------------------------------------------------------------- Key: JBVFS-134 URL: https://jira.jboss.org/jira/browse/JBVFS-134 Project: JBoss VFS Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.3.SP1 Reporter: Toshiya Kobayashi Assignee: John Bailey When resolving virtual files, 1. DefaultVFSRegistry checks expiration of root context by IterableTimedVFSCache.findContext() which is implemented based on TimedCachePolicy.getValidKeys() 2. If the context is expired, a new context is created and CachePolicyVFSCache.putContext() is called, but the method checks the existence of cache entry by TimedCachePolicy.peek() which doesn't care about its expiration. Then the new entry won't be inserted into the cache and the expiration time of the old entry won't be updated. So once cache entries are expired, caching won't work and contexts will be created again and again. -- 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

15 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (JBAS-7285) Lazy initialization fix for wrong use case.

by Vicky Kak (JIRA)

Lazy initialization fix for wrong use case. ------------------------------------------- Key: JBAS-7285 URL: https://jira.jboss.org/jira/browse/JBAS-7285 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Reporter: Vicky Kak Assignee: Vicky Kak Fix For: JBossAS-5.2.0.GA, JBossAS-Branch_4_2 The JCA lazy initialization does not work in the following sceanrio ********************************************************************* DataSource ds = ... Connection c = ds.getConnection(); UserTransaction ut = ... ut.begin(); // Do work c = ds.getConnection(); // This should be avoided and looks antipattern. ut.commit(); ut.begin(); ********************************************************************* Getting the connection again in the TX context causes the issue, the subsequent ds.getConnection() leads to multiple enlistment of the local XAResources and thus causing this warning http://www.jboss.org/community/wiki/Multiple1pc The application developers should not follow the above coding pattern, however we should fix the issue cropping due to this coding practice as it could lead some misbehaviour in container, there are no evidences about the misbehaviour but it had been reported by our customers. -- 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

15 years, 10 months

5
9
0 / 0

[JBoss JIRA] Created: (JBAS-7924) smoke-tests build SUCCESS despite FAILURE

by Thomas Diesler (JIRA)

smoke-tests build SUCCESS despite FAILURE ----------------------------------------- Key: JBAS-7924 URL: https://jira.jboss.org/jira/browse/JBAS-7924 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Reporter: Thomas Diesler Assignee: Shelly McGowan Fix For: JBossAS-6.0.0.M3 [tdiesler@tdvaio testsuite]$ ./build.sh clean jars smoke-tests smoke-tests: [server:start] Starting server "all", with command (start timeout is 120 seconds ): [server:start] /usr/java/jdk1.6.0_17/bin/java -cp /home/tdiesler/git/jbossas/build/target/jboss-6.0.0-SNAPSHOT/bin/run.jar:/usr/java/jdk1.6/lib/tools.jar -Xms128m -Xmx512m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -XX:-UseGCOverheadLimit -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/home/tdiesler/git/jbossas/build/target/jboss-6.0.0-SNAPSHOT/lib/endorsed -Djgroups.udp.ip_ttl=0 -Djboss.server.log.threshold=DEBUG -Djava.endorsed.dirs=/home/tdiesler/git/jbossas/build/target/jboss-6.0.0-SNAPSHOT/lib/endorsed/ -Dxb.builder.useUnorderedSequence=true org.jboss.Main -c all -b localhost -g DefaultPartition [server:start] Server started. ... smoke-tests-raw: [echo] [echo] junit.timeout: 300000 [echo] jbosstest.iterationcount: 10 [echo] jbosstest.threadcount: 5 [echo] jbosstest.beancount: 5 [echo] [mkdir] Created dir: /home/tdiesler/git/jbossas/testsuite/output/log ... [junit] Running org.jboss.test.jmsra.test.RaJMSSessionUnitTestCase [junit] javax.ejb.EJBException: javax.jms.JMSException: Could not create a session: Unable to get managed connection for JmsXA) [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.423 sec [junit] Test org.jboss.test.jmsra.test.RaJMSSessionUnitTestCase FAILED ... [server:stop] Shutting down server: all [server:stop] log4j:WARN No appenders could be found for logger (org.jnp.interfaces.TimedSocketFactory). [server:stop] log4j:WARN Please initialize the log4j system properly. [server:stop] shutdownTimeout will be=45 [server:stop] Server stopped. BUILD SUCCESSFUL Total time: 6 minutes 3 seconds -- 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

15 years, 10 months

4
10
0 / 0

[JBoss JIRA] Created: (JBAS-7212) Web app context not being processed in JBoss 5.1 for Cactus test case

by Brendan Farragher (JIRA)

Web app context not being processed in JBoss 5.1 for Cactus test case --------------------------------------------------------------------- Key: JBAS-7212 URL: https://jira.jboss.org/jira/browse/JBAS-7212 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.GA Environment: JBoss 5.1.0GA, Cactus 1.8.1, Red Hat Developer Studio 2.0.0GA, Ubuntu Linux 9.04 Reporter: Brendan Farragher Configuring context-root in application.xml for Cactus test case works on JBoss 4.2.3 AS but not on JBoss 5.1 AS. Please deploy the attached .ear file to both JBoss 4.2.3 and JBoss 5.1 servers, and run Cactus test case from IDE. Cactus test app runs fine in JBoss 4.2.3, but not JBoss 5.1. Tried multiple configurations, including adding a context.xml file with the context path name to META-INF folder, and then to WEB-INF/lib (in separate tests). Both tests failed in JBoss 5.1. I have attached the .ear file that I tested with on my machine, and the Eclipse projects to build the web app. The code is from the samples/ejb3 folder of the Cactus 1.8.1 distribution. Thanks. -- 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

15 years, 10 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-7568) org.jboss.test.jca.test.TxConnectionManagerUnitTestCase

by Shelly McGowan (JIRA)

org.jboss.test.jca.test.TxConnectionManagerUnitTestCase ------------------------------------------------------- Key: JBAS-7568 URL: https://jira.jboss.org/jira/browse/JBAS-7568 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Shelly McGowan -- 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

15 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMETA-224) Incompatible types compilation errors when building with OpenJDK Runtime Environment (IcedTea6 1.6)

by David Walluck (JIRA)

Incompatible types compilation errors when building with OpenJDK Runtime Environment (IcedTea6 1.6) --------------------------------------------------------------------------------------------------- Key: JBMETA-224 URL: https://jira.jboss.org/jira/browse/JBMETA-224 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.1.GA Reporter: David Walluck Assignee: Alexey Loubyansky Fix For: 1.0.2.GA Incompatible types errors when building with OpenJDK Runtime Environment (IcedTea6 1.6). Does not occur with Java(TM) SE Runtime Environment (build 1.6.0_15-b03). Build log follows: [INFO] [compiler:compile] [INFO] Compiling 664 source files to /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/target/classes [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Compilation failure /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/ejb/jboss/JBossAssemblyDescriptorMetaData.java:[434,71] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.SecurityRolesMetaData required: org.jboss.metadata.javaee.spec.SecurityRolesMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/ejb/jboss/JBossAssemblyDescriptorMetaData.java:[447,77] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.MessageDestinationsMetaData required: org.jboss.metadata.javaee.spec.MessageDestinationsMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/spec/MessageDestinationsMetaData.java:[61,37] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.MessageDestinationsMetaData required: org.jboss.metadata.javaee.spec.MessageDestinationsMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/spec/EJBLocalReferencesMetaData.java:[58,37] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.EJBLocalReferencesMetaData required: org.jboss.metadata.javaee.spec.EJBLocalReferencesMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/spec/EJBReferencesMetaData.java:[58,37] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.EJBReferencesMetaData required: org.jboss.metadata.javaee.spec.EJBReferencesMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/spec/MessageDestinationReferencesMetaData.java:[59,37] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.MessageDestinationReferencesMetaData required: org.jboss.metadata.javaee.spec.MessageDestinationReferencesMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/spec/PersistenceContextReferencesMetaData.java:[49,37] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.PersistenceContextReferencesMetaData required: org.jboss.metadata.javaee.spec.PersistenceContextReferencesMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/spec/ResourceEnvironmentReferencesMetaData.java:[56,37] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.ResourceEnvironmentReferencesMetaData required: org.jboss.metadata.javaee.spec.ResourceEnvironmentReferencesMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/spec/ResourceReferencesMetaData.java:[56,37] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.ResourceReferencesMetaData required: org.jboss.metadata.javaee.spec.ResourceReferencesMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/spec/ServiceReferencesMetaData.java:[64,37] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.ServiceReferencesMetaData required: org.jboss.metadata.javaee.spec.ServiceReferencesMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/spec/AnnotatedEJBReferencesMetaData.java:[59,37] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>org.jboss.metadata.javaee.spec.AnnotatedEJBReferencesMetaData required: org.jboss.metadata.javaee.spec.AnnotatedEJBReferencesMetaData /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/support/JavaEEMetaDataUtil.java:[48,18] incompatible types; inferred type argument(s) java.lang.Object do not conform to bounds of type variable(s) T found : <T>M required: M /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/support/JavaEEMetaDataUtil.java:[145,26] incompatible types; inferred type argument(s) org.jboss.metadata.javaee.support.MappableMetaData,java.lang.Object do not conform to bounds of type variable(s) C,T found : <C,T>M required: M /home/david/dist/jboss-metadata/JPP-6/jboss-metadata-1.0.1/src/main/java/org/jboss/metadata/javaee/support/JavaEEMetaDataUtil.java:[154,26] incompatible types; inferred type argument(s) org.jboss.metadata.javaee.support.MappableMetaData,java.lang.Object do not conform to bounds of type variable(s) C,T found : <C,T>M required: M -- 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

15 years, 10 months

5
6
0 / 0

[JBoss JIRA] Created: (JBAS-7726) Resolve JBoss AS 6.0.0 M3 Test Suite Issues

by Shelly McGowan (JIRA)

Resolve JBoss AS 6.0.0 M3 Test Suite Issues ------------------------------------------- Key: JBAS-7726 URL: https://jira.jboss.org/jira/browse/JBAS-7726 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Shelly McGowan Assignee: Shelly McGowan Fix For: JBossAS-6.0.0.M3 Parent JIRA for test suite issues uncovered in Milestone 3. -- 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

15 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-7955) org.jboss.test.management.test.JSR77SpecUnitTestCase

by Shelly McGowan (JIRA)

org.jboss.test.management.test.JSR77SpecUnitTestCase ---------------------------------------------------- Key: JBAS-7955 URL: https://jira.jboss.org/jira/browse/JBAS-7955 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Shelly McGowan -- 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

15 years, 10 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-6871) don't create delegate operations for stopped components

by Emanuel Muckenhuber (JIRA)

don't create delegate operations for stopped components ------------------------------------------------------- Key: JBAS-6871 URL: https://jira.jboss.org/jira/browse/JBAS-6871 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ProfileService Affects Versions: JBossAS-5.1.0.CR1 Reporter: Emanuel Muckenhuber Assignee: Emanuel Muckenhuber Fix For: JBossAS-5.1.0.GA We should not create delegate operations and properties for stopped components. -- 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

15 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMAN-93) Separate creation and population of ManagedObjects

by Emanuel Muckenhuber (JIRA)

Separate creation and population of ManagedObjects -------------------------------------------------- Key: JBMAN-93 URL: https://jira.jboss.org/jira/browse/JBMAN-93 Project: JBoss Managed Issue Type: Task Reporter: Emanuel Muckenhuber Assignee: Emanuel Muckenhuber Priority: Critical Fix For: JBoss Managed 3.0.0.Alpha1 The creation needs to be separated from populating the values to the ManagedObject. -- 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

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-6817) Add isNullable attribute to ManagedOperation

by Charles Crouch (JIRA)

Add isNullable attribute to ManagedOperation -------------------------------------------- Key: JBAS-6817 URL: https://jira.jboss.org/jira/browse/JBAS-6817 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Charles Crouch -- 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

15 years, 10 months

4
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2011) Create Session Manager for EJB3 Stateful Session Beans

by Andrew Lee Rubinger (JIRA)

Create Session Manager for EJB3 Stateful Session Beans ------------------------------------------------------ Key: EJBTHREE-2011 URL: https://jira.jboss.org/jira/browse/EJBTHREE-2011 Project: EJB 3.0 Issue Type: Task Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger EJB 2.x has the notion of an EJB "Home", which can destroy bean instances (sessions) without invoking any business logic. CDI demands the same "backdoor" removal from EJB3, and we must provide a remotable, replicable mechanism. Additionally, SFSB injection is not a great idea. Sessions can time out or be removed by the container entirely, leading invocations upon the injected reference to throw NoSuchEJBException. Instead we can leverage a "SessionManager" to be injected, which may create/destroy bean instances as instructed by the bean provider. -- 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

15 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-1104) Revisit critical path in NAKACK

by Vladimir Blagojevic (JIRA)

Revisit critical path in NAKACK ------------------------------- Key: JGRP-1104 URL: https://jira.jboss.org/jira/browse/JGRP-1104 Project: JGroups Issue Type: Task Affects Versions: 2.8 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 2.9 Revisit NAKACK#handleMessage and see if we can: a) lower contention on NRW lock by not attempting to propel up oob messages one-by-one I have no profiling data so I am speaking without a solid proof to back my claims. I am envisioning both oob and regular threads contending for a window as they push messages up the stack. oob threads are always going to attempt to lock per message (line 788). In an event that we received missing oob message in a series of oob messages we are going to repeatedly lock window per message traversed. Not good. We don't need this IMHO. I really like lock efficient removeMany algorithm. Let removeMany propel messages up the stack as much as possible, even oob messages. b) why are we propelling oob messages on a timer (line 833)? Is it to lower the workload of the current thread, or is there a more fundamental reason? c) undelivered_msgs is complicating things unnecessarily IMHO. Why don't we let oob threads go into removeMany code and remove as much messages as they can - both oob and regular and push them up rather than lock NRW per message? -- 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

15 years, 11 months

2
10
0 / 0

[JBoss JIRA] Created: (JBAS-4435) WebAppClassLoader.getResource() fails when the war is deployed as part of an ear

by Thomas Diesler (JIRA)

WebAppClassLoader.getResource() fails when the war is deployed as part of an ear -------------------------------------------------------------------------------- Key: JBAS-4435 URL: http://jira.jboss.com/jira/browse/JBAS-4435 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Reporter: Thomas Diesler Assigned To: Scott M Stark For some reason WebAppClassLoader.getResource("WEB-INF/wsdl/TestEndpoint.wsdl") fails when the war is deployed as part of an ear deployment. I use this workaround in static class VirtualFileClassLoader extends ClassLoader { private UnifiedVirtualFile vFile; public VirtualFileClassLoader(UnifiedVirtualFile file, ClassLoader parent) { super(parent); vFile = file; } @Override public URL getResource(String name) { URL url = super.getResource(name); if (url == null) { try { url = vFile.findChild(name).toURL(); } catch (IOException e) { // ignore } } return url; } } -- 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

15 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3970) NPE in JBossTestCase

by Thomas Diesler (JIRA)

NPE in JBossTestCase -------------------- Key: JBAS-3970 URL: http://jira.jboss.com/jira/browse/JBAS-3970 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite Reporter: Thomas Diesler Assigned To: Scott M Stark getServerHost() throws a NPE, because the delegate is not initialized before setUp() is called public class SimpleJSETestCase extends JBossTestCase { private String WSDL_LOCATION = "http://" + getServerHost() + ":8080/ws4ee-simple?wsdl"; private String NAMESPACE = "http://test.jboss.org/ws4eesimple"; private QName SERVICE_NAME = new QName(NAMESPACE, "HelloService"); .... } This is quite common in the webservice test suite -- 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

15 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-1181) PING messages to entire cluster limit scalability.

by Jonathan Oddy (JIRA)

PING messages to entire cluster limit scalability. -------------------------------------------------- Key: JGRP-1181 URL: https://jira.jboss.org/jira/browse/JGRP-1181 Project: JGroups Issue Type: Feature Request Reporter: Jonathan Oddy Assignee: Bela Ban PING messages generate a response from every node that receives them. In a large cluster this will lead to a large number of responses needing to be processed. Making PINGs target-able (e.g. ping to only coordinators, ping to anyone with a view not matching ViewID N) could significantly reduce the number of nodes responding to a request. -- 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

15 years, 11 months

2
8
0 / 0

[JBoss JIRA] Created: (JGRP-1049) Concurrent hashmaps: set parameters via system properties

by Bela Ban (JIRA)

Concurrent hashmaps: set parameters via system properties --------------------------------------------------------- Key: JGRP-1049 URL: https://jira.jboss.org/jira/browse/JGRP-1049 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 ConcurrentHashMap ----------------- CCHMs have a default initial capacity (16), load factor (0.75) and concurrency level (16). These are OK for most scenarios, but we have to investigate whether these values are sufficient for 1000 node clusters. When for example 1000 threads from different senders access the same CCHM, we need to make sure we don't have high contention, ie. by spreading a 1000 senders over 16 buckets. Investigate whether we should add CCHM initial sizes, load factors and concurrency levels as system properties. With ergonomics [1], we could for example set bucket sizes for CCHMs dynamically, e.g. based on cluster size. [1] https://jira.jboss.org/jira/browse/JGRP-1037 -- 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

15 years, 11 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1790) Provide support for resolving @EJB/ejb-local-ref references to no-interface view

by jaikiran pai (JIRA)

Provide support for resolving @EJB/ejb-local-ref references to no-interface view -------------------------------------------------------------------------------- Key: EJBTHREE-1790 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1790 Project: EJB 3.0 Issue Type: Task Affects Versions: EJB 3.1 Reporter: jaikiran pai Assignee: jaikiran pai The EJB3.1 spec allows no-interface view reference, using a @EJB and through ejb-local-ref. We need to have a resolver (similar to FirstMatchEjbReferenceResolver) which does this. -- 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

15 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-859) Message: add LOOPBACK flag

by Bela Ban (JIRA)

Message: add LOOPBACK flag -------------------------- Key: JGRP-859 URL: https://jira.jboss.org/jira/browse/JGRP-859 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 When LOOPBACK is set in a message, the UNICAST.loopback and TP.loopback flags are overridden and a message is looped back up the stack, regardless of the value of the property. This is useful for example for VIEW and SUSPECT messages, where a socket could be disconnected (e.g. cable plugged) and we still need to be able to receive our own messages. -- 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

15 years, 11 months

1
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1933) EJB 3.1 - Support deployment of EJBs packaged in .war files

by jaikiran pai (JIRA)

EJB 3.1 - Support deployment of EJBs packaged in .war files ------------------------------------------------------------ Key: EJBTHREE-1933 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1933 Project: EJB 3.0 Issue Type: Task Reporter: jaikiran pai Assignee: jaikiran pai Fix For: EJB 3.1 As per the EJB 3.1 spec section 20.4, implement the support for deploying EJBs packaged in .war files. -- 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

15 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2075) Track dependency upgrades for EJB3_1 1.0.8

by jaikiran pai (JIRA)

Track dependency upgrades for EJB3_1 1.0.8 ------------------------------------------ Key: EJBTHREE-2075 URL: https://jira.jboss.org/jira/browse/EJBTHREE-2075 Project: EJB 3.0 Issue Type: Task Components: ejb3_1 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: EJB3_1 1.0.8 Track dependency upgrades for ejb3_1 1.0.8 -- 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

15 years, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-996) AUTH: handle multiple physical addresses in FixedMembershipToken

by Bela Ban (JIRA)

AUTH: handle multiple physical addresses in FixedMembershipToken ---------------------------------------------------------------- Key: JGRP-996 URL: https://jira.jboss.org/jira/browse/JGRP-996 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 -- 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

15 years, 11 months

1
5
0 / 0

[JBoss JIRA] Created: (JBAS-5599) Eliminate build time configuration directories and replace with tool for generating configuration through the profile service API

by Andrig Miller (JIRA)

Eliminate build time configuration directories and replace with tool for generating configuration through the profile service API --------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-5599 URL: http://jira.jboss.com/jira/browse/JBAS-5599 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Build System, Getting Started Guide, Installation Guide, Installer, Management services, ProfileService, Server Configuration Guide, Test Suite Reporter: Andrig Miller Assigned To: Paul Gier Fix For: No Release With the addition of the profile service, it seems silly to generate various configurations, like "all", "default" and "minimal" through the build. Instead we should have a tool that generates the configuration through the profile service, with the understanding of the dependencies of the various features. The tool could still have the concepts of "all", "default" and "minimal" embedded in it to make the transition easier, but most times to do the testing that we need to do we customize the configuration. We also add an additional configuration in productizing the EAP, and this would simplify that process as well. This tool would have to be usable at the command-line, in JBoss Tools, and from the installer. -- 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

15 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBJCA-298) Maven plugin for validate tool

by Jeff Zhang (JIRA)

Maven plugin for validate tool ------------------------------ Key: JBJCA-298 URL: https://jira.jboss.org/jira/browse/JBJCA-298 Project: JBoss JCA Issue Type: Task Components: Validator Reporter: Jeff Zhang Assignee: Jeff Zhang make a maven plugin for validate tool that user can use it in the maven pom.xml -- 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

15 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-897) Anycasting: better use of logical addresses

by Bela Ban (JIRA)

Anycasting: better use of logical addresses ------------------------------------------- Key: JGRP-897 URL: https://jira.jboss.org/jira/browse/JGRP-897 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 See whether logical addresses allow us to handle anycasting more efficiently, ie. handle them at the transport level, and not by sending multiple unicasts -- 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

15 years, 11 months

1
9
0 / 0

[JBoss JIRA] Created: (JGRP-1154) FC: separate implementations for multicast and unicast messages

by Bela Ban (JIRA)

FC: separate implementations for multicast and unicast messages --------------------------------------------------------------- Key: JGRP-1154 URL: https://jira.jboss.org/jira/browse/JGRP-1154 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.11 Currently, FC handles both multicast (=group) and unicast messages. This has a few disadvantages: - Complexity - Unicast messages are not dependent on multicast messages (and vice versa), so why should this be different for flow control ? E.g. why should a multicast message block waiting for credits from X because a recent unicast message was sent to X ? - If we have separate flow control protocols for multicasts and unicasts, we can selectively remove one or the other. This is currently not possible Design (see separate documents in ./doc/design): FC_MCAST: ----------------- (see whether some concepts can be borrowed from SFC) Sender: - Every sender has a credits AtomicLong variable - When sending a message and the message length exceeds credits, the sender blocks (until it gets credits from all current group members) - Else credits is decremented by the message length and the message is sent - When credits are received from all current group members, credits is reset to the initial value and all blocked senders are unblocked - When a new member joins, credits is also reset and all blocked senders are unblocked Receiver: - Maintains a hashmap of senders and credits (Map<Address,AtomicLong>) - When a message is received from S, the credits for S are decremented by the message length - If the remaining length is less than the threshold, new credits are sent to S and S's credits are reset to their initial value - When a new member joins, all credits (including the newly joined member) are reset to the initial value FC_UNICAST: -------------------- Sender: - A hashmap of addresses and credits is maintained: every receiver has associated credits - When a message is sent to P, if P's credits minus the message length is less than 0, the sender blocks until it gets new credits from the receiver - Else P's credits are decremented by the message length and the message is sent Receiver: -Same as for FC_MCAST -- 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

15 years, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-6987) Disable registering of MC bean components as MBeans by default

by jaikiran pai (JIRA)

Disable registering of MC bean components as MBeans by default -------------------------------------------------------------- Key: JBAS-6987 URL: https://jira.jboss.org/jira/browse/JBAS-6987 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Deployers Affects Versions: JBossAS-5.1.0.GA Reporter: jaikiran pai Assignee: jaikiran pai Fix For: JBossAS-6.0.0.Alpha1 Every MC bean that gets deployed, also gets registered as a MBean. These MBeans are optional and only provide debug information. These can by default be disabled. Refer to the referenced forum thread for 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

15 years, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JASSIST-48) Create a common interface to MethodCall & NewExpr

by Guy Korland (JIRA)

Create a common interface to MethodCall & NewExpr ------------------------------------------------- Key: JASSIST-48 URL: http://jira.jboss.com/jira/browse/JASSIST-48 Project: Javassist Issue Type: Feature Request Reporter: Guy Korland Assigned To: Shigeru Chiba MethodCall & NewExpr both have common methods that are not part of the javassist.expr.Expr interface. public String getClassName() public String getSignature() suggested API: abstract public class Invoke extends Expr{ abstract public String getClassName(); abstract public String getSignature(); } public class MethodCall extends Invoke public class NewExpr extends Invoke -- 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

15 years, 11 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1861) Ruleflow diagram not proprly displayed

by Jaroslaw Kijanowski (JIRA)

Ruleflow diagram not proprly displayed -------------------------------------- Key: JBRULES-1861 URL: https://jira.jboss.org/jira/browse/JBRULES-1861 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.0.0.M3 Reporter: Jaroslaw Kijanowski Assignee: Michael Neale Attachments: expected.png, rf.png -- 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

15 years, 11 months

3
9
0 / 0

[JBoss JIRA] Created: (EJBTHREE-913) java.lang.IllegalStateException in SessionContext::getCallerPrincipal()

by Mihail Druzinin (JIRA)

java.lang.IllegalStateException in SessionContext::getCallerPrincipal() ----------------------------------------------------------------------- Key: EJBTHREE-913 URL: http://jira.jboss.com/jira/browse/EJBTHREE-913 Project: EJB 3.0 Issue Type: Bug Components: Security Affects Versions: EJB 3.0 RC9 - FD Environment: AS: jboss-4.0.5 (ejb3 Version EJB 3.0 RC7 - FD and EJB3 RC9 Patch 1) OS: Windows, GentooLinux Reporter: Mihail Druzinin >From HttpServlet I execute methods from stateless been. All methods executed correctly with authorization. When in method I try sessionContext.getCallerPrincipal(), then throws java.lang.IllegalStateException: No valid security context for the caller identity After see in jboss security module I find that in org.jboss.security.SecurityAssociation getCallerPrincipal() when used RunAsIdentity, it getted not from top of RunAsIdentity stack, but "for the active run-as the previous caller has assumed": Principal thePrincipal = peekRunAsIdentity(1); (SecurityAssociation.java:216). After fixed that string to: Principal thePrincipal = peekRunAsIdentity(0), all start work. -- 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

15 years, 11 months

2
6
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 April 2010