[JBoss JIRA] (WFLY-5299) WFLYWELD0001 and WFLYWELD0002 errors deploying helloworld-mbean quickstart
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5299?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5299.
----------------------------
> WFLYWELD0001 and WFLYWELD0002 errors deploying helloworld-mbean quickstart
> --------------------------------------------------------------------------
>
> Key: WFLY-5299
> URL: https://issues.jboss.org/browse/WFLY-5299
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Sande Gilda
> Assignee: Stuart Douglas
> Fix For: 10.0.0.CR1
>
>
> When deploying helloworld-mbean QS, WFLYWELD0001 and WFLYWELD0002 error messages are logged in server log:
> {code}
> ERROR [org.jboss.as.weld] (ServerService Thread Pool -- 58) WFLYWELD0001: Failed to setup Weld contexts: javax.naming.NameNotFoundException: BeanManager -- service jboss.naming.context.java.module."jboss-helloworld-mbean-helloworld-mbean-service.sar"."jboss-helloworld-mbean-helloworld-mbean-service.sar".BeanManager
> ERROR [org.jboss.as.weld] (ServerService Thread Pool -- 58) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: BeanManager -- service jboss.naming.context.java.module."jboss-helloworld-mbean-helloworld-mbean-service.sar"."jboss-helloworld-mbean-helloworld-mbean-service.sar".BeanManager
> {code}
> [~jharting] said:
> The problem is triggered by this change: https://github.com/wildfly/wildfly/commit/20bbfce9f972c73ed1c3ba250ad3f15...
> I am not sure why WeldContextSetup is being called for each AbstractService.invokeLifecycleMethod(). Looks like either WeldContextSetup should not be added to this particular list of setup actions or a wrong list of setup actions is used by AbstractService.
> See this issue for details: https://issues.jboss.org/browse/JBEAP-625
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-5199) On MariaDB 5.3+ and MySQL 5.6.4+, EJB timers in a JDBC storage don't work correctly due to timestamp rounding
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5199?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5199.
----------------------------
> On MariaDB 5.3+ and MySQL 5.6.4+, EJB timers in a JDBC storage don't work correctly due to timestamp rounding
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5199
> URL: https://issues.jboss.org/browse/WFLY-5199
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Beta2
> Environment: MariaDB 5.3+, Mysql 5.6.4+
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
> Fix For: 10.0.0.CR1
>
>
> EJB timers don't execute, because the DatabaseTimerPersistence.shouldRun method returns false for them, because it is unable to SELECT them from the database using a java.sql.Timestamp.
> On MariaDB 5.3+ and MySQL 5.6.4+, the behavior of the DATETIME type has changed compared to MySQL 5.5 and older.
> In previous versions, it was possible to insert into DATETIME columns with JDBC using a java.sql.Timestamp which contained fractional seconds, the fraction was truncated/rounded and a subsequent SELECT statement with the same java.sql.Timestamp returned such rows, because the fraction was truncated/rounded from the queried Timestamp too.
> On MySQL 5.6.4+ and MariaDB 5.3+, when a java.sql.Timestamp including a fractional second is inserted into a DATETIME, attempting to SELECT with the same Timestamp doesn't return the row, because the DATETIME type now defaults to DATETIME(0) which truncates/rounds to whole seconds, and the queried Timestamp no longer gets truncated/rounded during the query execution. It would only work if the column was declared as DATETIME(6), which ensures that inserted values don't get truncated/rounded. Documentation: https://dev.mysql.com/doc/refman/5.7/en/fractional-seconds.html
> MySQL rounds the timestamp, MariaDB truncates it (always rounds down).
> However, declaring DATETIME(6) is not possible in older versions of MySQL or MariaDB, so to support both new and old versions, we have probably these options:
> 1. introduce a new DDL file(s) for MySQL 5.6.4+ and MariaDB 5.3+ and use it depending on the detected version - this DDL would use DATETIME(6) instead of DATETIME
> 2. change the DatabaseTimerPersistence implementation so that it will not insert fractional seconds into the database at all (EJB timers don't support timing with higher precision than whole seconds anyway)
> 3. same as option 2, but only for MariaDB/MySQL dialects
> 4. any other idea?
> I personally like number 3 the best, it is the least risky and introduces only minimal changes.. but it's still somewhat ugly.
> This seems to resolve it for me (implementation suggestion of option 3): https://github.com/jmartisk/wildfly/commits/mysql-mariadb-timer-suggestion
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-5092) Can't start server in --admin-only with EAP 6.4 configuration
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5092?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5092.
----------------------------
> Can't start server in --admin-only with EAP 6.4 configuration
> -------------------------------------------------------------
>
> Key: WFLY-5092
> URL: https://issues.jboss.org/browse/WFLY-5092
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 10.0.0.Beta2
>
>
> When starting WildFly 10.0.0.Beta1 in {{--admin-only}} mode to perform {{:migrate}} operations on old subsystems, using an unmodified {{standalone-full-ha.xml}} configuration file from EAP 6.4.0, I'm getting errors.
> Based on http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004306.html, I'm expecting that I don't have to perform any changes to the EAP 6.4 configuration file, yet in order to successfully boot the new server with the old configuration file, I have to perform the following set of changes:
> - remove the {{cmp}}, {{jaxr}} and {{threads}} extensions and subsystems (this seems to be already covered by WFCORE-875)
> - copy the entire configuration of the {{ejb3}} subsystem (version 3.0) from a new {{standalone-full-ha.xml}} to the old one, because I'm not able to fix the old subsystem (version 1.5) from the error message \[1\]
> - add the {{io}} extension and subsystem from a new {{standalone-full-ha.xml}} to the old one, because {{remoting}} needs it to boot \[2\]
> \[1\] {code}16:31:35,167 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: "WFLYEJB0451: Attribute 'default-clustered-sfsb-cache' is not supported on current version servers; it is only allowed if its value matches 'default-sfsb-cache'"{code}
> \[2\] {code}16:34:35,376 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=remoting' are not available:
> org.wildfly.io.worker.default
> {code}
> In http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004303.html, I also mentioned {{datasources}}, but that was a false alarm -- that was from normal server boot, not {{--admin-only}}, and hence invalid.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month