[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6402:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1310908|https://bugzilla.redhat.com/show_bug.cgi?id=1310908] from VERIFIED to CLOSED
> EJBs accessible too early (spec violation)
> ------------------------------------------
>
> Key: WFLY-6402
> URL: https://issues.jboss.org/browse/WFLY-6402
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Fedor Gavrilov
> Labels: downstream_dependency
> Attachments: auto-test-reproducer.zip
>
>
> {code}
> EJB 3.1 spec, section 4.8.1:
> "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application.
> {code}
> Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call.
> This Jira ticket handles two PR's on WFLY:
> https://github.com/wildfly/wildfly/pull/8824 (that is already merged)
> and https://github.com/wildfly/wildfly/pull/8989
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1499) logging custom-handler does not load module with slot
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1499?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1499:
-------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1349223|https://bugzilla.redhat.com/show_bug.cgi?id=1349223] from VERIFIED to CLOSED
> logging custom-handler does not load module with slot
> -----------------------------------------------------
>
> Key: WFCORE-1499
> URL: https://issues.jboss.org/browse/WFCORE-1499
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Erwan Lacoste
> Assignee: James Perkins
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> Tested on EAP 6.4
> when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
> my/loghandler/main
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
> {code}
> Nevertheless I want to version the module, therefore package my module with a given slot:
> my/loghandler/1.0
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
> {code}
> But this fails with following stacktrace:
> {code}
> 11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "4H")
> ]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 13 more
> {code}
> why is the module not found being *my.loghandler:1.0:main* ?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6566) SAR deployer uses wrong MBean class to resolve source Method for property injection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6566?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6566:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1329314|https://bugzilla.redhat.com/show_bug.cgi?id=1329314] from VERIFIED to CLOSED
> SAR deployer uses wrong MBean class to resolve source Method for property injection
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6566
> URL: https://issues.jboss.org/browse/WFLY-6566
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Server
> Affects Versions: 10.0.0.Final
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Bartosz Spyrko-Śmietanko
> Labels: downstream_dependency
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> If using a <value-factory> or <inject> element with "parameter" attribute in jboss-service.xml to inject a value from one bean to another, a "java.lang.IllegalArgumentException: object is not an instance of declaring class" error is raised during deployment.
> jboss-service.xml
> {noformat}
> <server xmlns="urn:jboss:service:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:service:7.0 jboss-service_7_0.xsd">
> <mbean code="com.test.redhat.mbean.OtherValueFactory" name="test:type=OtherValueFactory">
> <attribute name="WelcomeString">Welcome</attribute>
> <attribute name="CustName">Other</attribute>
> </mbean>
> <mbean code="com.test.redhat.mbean.TestValueFactory" name="test:type=SarTestValueFactory">
> <depends>test:type=OtherValueFactory</depends>
> <attribute name="WelcomeString">Welcome</attribute>
> <attribute name="CustName">
> <value-factory bean="test:type=OtherValueFactory" method="getNameOfCustomer">
> <parameter class="java.lang.String">Foo</parameter>
> </value-factory>
> </attribute>
> </mbean>
> </server>
> {noformat}
> Full error:
> {noformat}
> 16:54:36,505 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "test.sar" (runtime-name: "test.sar")
> 16:54:36,690 WARN [org.jboss.msc.inject] (MSC service thread 1-2) MSC000100: Unexpected failure to uninject public void com.test.redhat.mbean.TestValueFactory.setCustName(java.lang.String): java.lang.NullPointerException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.msc.value.MethodValue.getValue(MethodValue.java:62)
> at org.jboss.msc.value.CachedValue.getValue(CachedValue.java:54)
> at org.jboss.msc.value.Values.getValues(Values.java:68)
> at org.jboss.msc.value.Values.getValues(Values.java:82)
> at org.jboss.msc.inject.MethodInjector.uninject(MethodInjector.java:119)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1923)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 16:54:36,691 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.mbean.service.test:type=SarTestValueFactory.create: org.jboss.msc.service.StartException in service jboss.mbean.service.test:type=SarTestValueFactory.create: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.msc.inject.InjectionException: Injection failed
> at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:102)
> at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1672)
> at org.jboss.msc.service.ServiceControllerImpl.access$2000(ServiceControllerImpl.java:51)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1917)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876)
> ... 3 more
> Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.msc.value.MethodValue.getValue(MethodValue.java:62)
> at org.jboss.msc.value.CachedValue.getValue(CachedValue.java:54)
> at org.jboss.msc.value.Values.getValues(Values.java:68)
> at org.jboss.msc.value.Values.getValues(Values.java:82)
> at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:92)
> ... 7 more
> 16:54:36,697 INFO [com.test.redhat.mbean.OtherValueFactory] (ServerService Thread Pool -- 58) >> TestValuFactory.start() invoked
> 16:54:36,698 INFO [stdout] (ServerService Thread Pool -- 58) TestValuFactory.start() invoked
> 16:54:36,776 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "test.sar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.mbean.service.test:type=SarTestValueFactory.create" => "org.jboss.msc.service.StartException in service jboss.mbean.service.test:type=SarTestValueFactory.create: Failed to start service
> Caused by: org.jboss.msc.inject.InjectionException: Injection failed
> Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class"}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (LOGMGR-122) Syslog handler is not generating correct timestamp format
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-122?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on LOGMGR-122:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1295657|https://bugzilla.redhat.com/show_bug.cgi?id=1295657] from VERIFIED to CLOSED
> Syslog handler is not generating correct timestamp format
> ---------------------------------------------------------
>
> Key: LOGMGR-122
> URL: https://issues.jboss.org/browse/LOGMGR-122
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.0.0.Final
> Environment: Wildfly 9.0.1.Final, Oracle JRE 1.8.0_11, CentOS 6
> Reporter: Ricardo Kagawa
> Assignee: James Perkins
> Fix For: 1.4.4.Final, 1.5.5.Final, 2.0.1.Final, 2.1.0.Beta1
>
>
> The Syslog handler is outputting an extra zero before the month in the header timestamp for RFC5424, specifically for October.
> Checking [Github|https://github.com/jboss-logging/jboss-logmanager/blob/master/src/...], I have noticed that the month number is tested for double digit before being offset, so a zero is added for October (month 9 for java.util.Calendar), then offset for proper display (month "10" for ISO8601), resulting in a three-digit month ("010").
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5242) Inconsistent format for IPv6 addresses in server log
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5242?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5242:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1258298|https://bugzilla.redhat.com/show_bug.cgi?id=1258298] from VERIFIED to CLOSED
> Inconsistent format for IPv6 addresses in server log
> ----------------------------------------------------
>
> Key: WFLY-5242
> URL: https://issues.jboss.org/browse/WFLY-5242
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta2
> Reporter: Lyle Wang
> Assignee: Chao Wang
> Priority: Minor
> Fix For: 10.0.0.CR1
>
>
> Description of problem:
> When IPv6 is used, square brackets for IPv6 addresses are missed in some of log entries. Specifically, the address format from Undertow logs is different from those "WFLYSRV" logs.
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Config IPv6 (example: https://docs.jboss.org/author/display/WFLY10/Interfaces+and+ports)
> 2. Start WildFly and check the log
> Actual results:
> ----------------------------------------
> 2015-08-31 12:51:47,812 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTP listener default listening on /0:0:0:0:0:0:0:1:8080
> ......
> 2015-08-31 12:51:48,431 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://[::1]:9993/management
> 2015-08-31 12:51:48,432 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://[::1]:9993
> ----------------------------------------
> In Undertow logs it's like "/0:0:0:0:0:0:0:1:8080" but in WildFly server logs "http://[::1]:9993/management"
> Expected results:
> Consistent format should be used for IPv6 address across different components and the address is enclosed in square brackets [ ].
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-5478) allow custom scoped persistence unit name hint in persistence unit definition
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5478?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5478:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1262401|https://bugzilla.redhat.com/show_bug.cgi?id=1262401] from VERIFIED to CLOSED
> allow custom scoped persistence unit name hint in persistence unit definition
> -----------------------------------------------------------------------------
>
> Key: WFLY-5478
> URL: https://issues.jboss.org/browse/WFLY-5478
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.1.1.Final, 8.0.0.Final, 9.0.0.Final, 10.0.0.CR2
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 10.0.0.CR3
>
>
> Consider allowing applications to override the scoped persistence unit name, so instead of using names like "test2.ear/w2.war#warPUnit_PU", the application can specify a unique (across all deployments on the app server) name.
> The idea is that application deployments can include a persistence unit hint "jboss.as.jpa.scopedname" that specifies the unique scoped persistence unit name that will be used for several internal settings (e.g. hibernate.cache.region_prefix will be set to the scopedname value unless the application specifies a different hibernate.cache.region_prefix value).
> The WildFly management console does not yet work with applications that specify the jboss.as.jpa.scopedname. Once this change is merged to WildFly, a management console change should be requested.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months