[JBoss JIRA] (JBAS-9465) NPE during deployment in org.jboss.weld.util.ApiAbstraction.annotationTypeForName
by Dirk Mahler (Created) (JIRA)
NPE during deployment in org.jboss.weld.util.ApiAbstraction.annotationTypeForName
---------------------------------------------------------------------------------
Key: JBAS-9465
URL: https://issues.jboss.org/browse/JBAS-9465
Project: Application Server 3, 4, 5 and 6
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Weld/CDI
Affects Versions: 6.1.0
Environment: Windows 7 64bit
Java 1.6.0_29 64bit
Maven Cargo Plugin 1.4 or command line
Reporter: Dirk Mahler
Assignee: Marius Bogoevici
We are using maven cargo plugin for our integration tests to start/stop JBoss AS 6.1.0.Final and deploying artifacts. The cargo plugin is configured with a installation directory (e.g. C:/development/work/cargo) which is used by cargo to construct a command line to start the AS. On some of our Windows 7 systems we faced the following exception while starting and deploying EAR artifacts containing CDI enabled bean archives with the default JBOSS server configuration:
11:11:46,637 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Create: name=vfs:///C:/development/work/cargo/default/deploy/application.ear-2.3.7.3-SNAPSHOT.ear_WeldBootstrapBean state=Configured: java.lang.NullPointerException
at org.jboss.weld.util.ApiAbstraction.annotationTypeForName(ApiAbstraction.java:86) [:6.1.0.Final]
at org.jboss.weld.ejb.EJBApiAbstraction.<init>(EJBApiAbstraction.java:36) [:6.1.0.Final]
at org.jboss.weld.bootstrap.BeanDeployment.<init>(BeanDeployment.java:100) [:6.1.0.Final]
at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBootstrap.java:185) [:6.1.0.Final]
at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBootstrap.java:197) [:6.1.0.Final]
at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBootstrap.java:156) [:6.1.0.Final]
at org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:293) [:6.1.0.Final]
at org.jboss.weld.integration.deployer.env.helpers.BootstrapBean.initialize(BootstrapBean.java:106) [:6.1.0.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_29]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_29]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_29]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_29]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-ker
nel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:
2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.SP
2]
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.
2.0.SP2]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.2.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.2.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.2.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.1.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:151) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94) [:0.2.2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.
2.0.SP2]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.SP2]
at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159) [:0.2.2]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:112) [:0.2.2]
at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87) [:0.2.2]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91) [:0.2.2]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132) [:6.1.0.Final]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.1.0.Final]
at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-6]
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-6]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
The reason could be tracked down to the fact that the specified directory must be specified using the correct case as reported by the file system (e.g. C:/development/work/cargo vs. C:/Development/work/cargo).
The problem also exists if running the AS from the command line (without maven cargo plugin involved):
C:\development\Java\jdk_1.6.0_29\jre\bin\java.exe -Xmx1200M -XX:MaxPermSize=768M -Xms128m -XX:PermSize=48m -Djboss.bind.address=127.0.0.1 -Dlogging.configuration=file:/C:/development/work/cargo/jboss-as-distribution-6.1.0.Final/jboss-6.1.0.Final/bin/logging.properties -Djboss.common.lib.url=file:/C:/development/work/cargo/jboss-as-distribution-6.1.0.Final/jboss-6.1.0.Final/common/lib/ -Djava.endorsed.dirs=C:\development\work\cargo\jboss-as-distribution-6.1.0.Final\jboss-6.1.0.Final\lib\endorsed -Djboss.home.dir=C:\development\work\cargo\jboss-as-distribution-6.1.0.Final\jboss-6.1.0.Final -Djboss.server.home.dir=C:\development\work/cargo/default -Djboss.server.home.url=file:/C:/development/work/cargo/default/ -Djboss.server.name=default -Djboss.server.lib.url=file:/C:/development/work/cargo/jboss-as-distribution-6.1.0.Final/jboss-6.1.0.Final/server/default/lib/ -Djboss.server.log.threshold=INFO -classpath C:\development\work\cargo\jboss-as-distribution-6.1.0.Final\jboss-6.1.0.Final\bin\run.jar;C:\development\Java\jdk_1.6.0_29\lib\tools.jar org.jboss.Main --host=localhost --configuration=default
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4115) Jboss Web Connector resources max-threads data not available in ui or cli/json data
by Simeon Pinder (JIRA)
[ https://issues.jboss.org/browse/AS7-4115?page=com.atlassian.jira.plugin.s... ]
Simeon Pinder moved JBPAPP-8188 to AS7-4115:
--------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-4115 (was: JBPAPP-8188)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: (was: EAP 6.0.0 DR 13)
Component/s: (was: Other)
Security: (was: Public)
Fix Version/s: (was: TBD EAP 6)
Docs QE Status: (was: NEW)
> Jboss Web Connector resources max-threads data not available in ui or cli/json data
> ------------------------------------------------------------------------------------
>
> Key: AS7-4115
> URL: https://issues.jboss.org/browse/AS7-4115
> Project: Application Server 7
> Issue Type: Bug
> Environment: Using JBEAP-6.0.0.ER1.
> Reporter: Simeon Pinder
> Assignee: Fernando Nasser
> Labels: rhq
>
> Looks like max-threads is not currently exposed for JBoss Web Connectors.
> "connector" => {"http" => {
> "bytesReceived" => "0",
> "bytesSent" => "0",
> "enable-lookups" => false,
> "enabled" => true,
> "errorCount" => "0",
> "max-post-size" => 2097152,
> "max-save-post-size" => 4096,
> "maxTime" => "0",
> "processingTime" => "0",
> "protocol" => "HTTP/1.1",
> "redirect-port" => 8443,
> "requestCount" => "0",
> "scheme" => "http",
> "secure" => false,
> "socket-binding" => "http",
> "ssl" => undefined,
> "virtual-server" => undefined
> }}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4116) removal of unrequested json snippet '"server-groups" => undefined' postpended to operation responses via cli
by Simeon Pinder (JIRA)
[ https://issues.jboss.org/browse/AS7-4116?page=com.atlassian.jira.plugin.s... ]
Simeon Pinder moved JBPAPP-8233 to AS7-4116:
--------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-4116 (was: JBPAPP-8233)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: (was: EAP 6.0.0 ER 1)
Component/s: (was: Other)
Security: (was: Public)
Fix Version/s: (was: TBD EAP 6)
Docs QE Status: (was: NEW)
> removal of unrequested json snippet '"server-groups" => undefined' postpended to operation responses via cli
> ------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4116
> URL: https://issues.jboss.org/browse/AS7-4116
> Project: Application Server 7
> Issue Type: Enhancement
> Reporter: Simeon Pinder
> Assignee: Fernando Nasser
> Priority: Minor
> Labels: rhq
>
> When submitting operations to as7 via CLI sometimes and extra ["server-groups" => undefined] string is post-pended to the response. The result is still valid JSON it appears, but the results are potentially confusing to external json integrators.
> To reproduce:
> - run AS7 via domain.sh to run HostController.
> - login
> - submit the following operation:
> /host=master/core-service=platform-mbean/type=threading/:read-resource(recursive=true,proxies=false,include-runtime=true,include-defaults=true)
> - Look at the result returned:
> {
> "outcome" => "success",
> "result" => {
> "all-thread-ids" => [
> 2173L,
> 2172L,
> 2171L,
> 51L,
> 50L,
> 49L,
> 48L,
> 45L,
> 44L,
> 43L,
> 42L,
> 41L,
> 40L,
> 39L,
> 38L,
> 37L,
> 36L,
> 35L,
> 34L,
> 33L,
> 32L,
> 31L,
> 30L,
> 29L,
> 28L,
> 27L,
> 26L,
> 25L,
> 24L,
> 23L,
> 22L,
> 21L,
> 19L,
> 18L,
> 17L,
> 16L,
> 15L,
> 14L,
> 13L,
> 12L,
> 11L,
> 8L,
> 4L,
> 3L,
> 2L,
> 1L
> ],
> "thread-contention-monitoring-supported" => true,
> "thread-cpu-time-supported" => true,
> "current-thread-cpu-time-supported" => true,
> "object-monitor-usage-supported" => true,
> "synchronizer-usage-supported" => true,
> "thread-contention-monitoring-enabled" => false,
> "thread-cpu-time-enabled" => true,
> "thread-count" => 46,
> "peak-thread-count" => 49,
> "total-started-thread-count" => 2168L,
> "daemon-thread-count" => 6,
> "current-thread-cpu-time" => 0L,
> "current-thread-user-time" => 0L
> },
> "server-groups" => undefined
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4114) datasource min/max pool size details not available via json/cli
by Simeon Pinder (JIRA)
[ https://issues.jboss.org/browse/AS7-4114?page=com.atlassian.jira.plugin.s... ]
Simeon Pinder moved JBPAPP-8169 to AS7-4114:
--------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-4114 (was: JBPAPP-8169)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.0.Final
(was: EAP 6.0.0 DR 13)
Component/s: REST
(was: Other)
Security: (was: Public)
Fix Version/s: (was: TBD EAP 6)
Docs QE Status: (was: NEW)
> datasource min/max pool size details not available via json/cli
> ---------------------------------------------------------------
>
> Key: AS7-4114
> URL: https://issues.jboss.org/browse/AS7-4114
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.Final
> Environment: DR13, cli/json interface.
> Reporter: Simeon Pinder
> Assignee: Fernando Nasser
> Labels: rhq
>
> Use cli to browse data with recursive/runtime both true but fields are undefined. The max/min pool sizes are available via localhost:9990/console/App.hmtl.
> /subsystem=datasources/data-source=H2DS/
> max-pool-size => undefined
> min-pool-size => undefined
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4099) Clustered EJB invocations for server to server communication fail on secured servers
by jaikiran pai (JIRA)
jaikiran pai created AS7-4099:
---------------------------------
Summary: Clustered EJB invocations for server to server communication fail on secured servers
Key: AS7-4099
URL: https://issues.jboss.org/browse/AS7-4099
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.0.Final
Reporter: jaikiran pai
Assignee: jaikiran pai
Priority: Critical
Fix For: 7.1.1.Final
While writing a documentation for server to server EJB invocations when security is involved, I just noticed that we lack a way to let the user deployments configure security and other connection details for dynamic nodes that participate in the clustered invocation. Consider the following scenario:
1) Server A and Server B both running in standalone HA mode. Both server A and B have a deployment "foo" containing clustered SFSBs.
2) Server C is a client server (may or may not have cluster capability).
3) Server C has a deployment "bar" containing a jboss-ejb-client.xml with reference to a outbound remoting connection:
{code:xml}
<jboss-ejb-client xmlns="urn:jboss:ejb-client:1.0">
<client-context>
<ejb-receivers>
<remoting-ejb-receiver outbound-connection-ref="server-A-outbound-connection" />
</ejb-receivers>
</client-context>
</jboss-ejb-client>
{code}
Server C has a outbound connection configuration to server A, configured in its remoting subsystem with appropriate security and other connection settings.
The "bar" application on server C invokes a SFSB from "foo" application on server A. Server A sends back the cluster topology to server C and that topology includes server B (and other nodes if any). Now server C has no knowledge on how to connect to server B with the appropriate security credentials. The EJB client API falls back on default connection options and will try to connect to server B, but that will obviously fail because those defaults won't be applicable in a secured server environment.
The infrastructure is in place, in EJB client API to dynamically connecting to the cluster nodes. What we are missing is a way to let users configure this. For a remote standalone client, we allow this via jboss-ejb-client.properties. We need something similar but more applicable for a client hosted on the server, in the jboss-ejb-client.xml.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month