[JBoss JIRA] (WFLY-776) Inject POJO to MBean by using <inject bean="XXX"> in jboss-service.xml does not work in SAR
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-776?page=com.atlassian.jira.plugin.s... ]
Romain Pelisse commented on WFLY-776:
-------------------------------------
Regarding the two technical issues raised by Tomasz (and I've discussed with him over IRC):
1) dependency between the mbean service and the pojo service seems to be OK - it's not far fetch to think that MBean would need to access POJO just for this purpose (looking up dependency)
2) rather than chaning the XML syntax, we could change the content of the bean attribute, by adding a prefix:
{code:xml}
<mbean code="com.redhat.jboss.support.HelloService"
name="example:type=HelloService,service=Hello">
<attribute name="Message">Hello!!</attribute>
<attribute name="Task"><inject bean="pojo:myTask"/></attribute>
</mbean>
{code}
Which leads to no prefix, default behavior, prefix load some factories/resolver based on the prefix. On top of not arming the current syntax, it also reuse an usual practice (like URL) to specifiy other mechanism to inject dependency.
> Inject POJO to MBean by using <inject bean="XXX"> in jboss-service.xml does not work in SAR
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-776
> URL: https://issues.jboss.org/browse/WFLY-776
> Project: WildFly
> Issue Type: Bug
> Components: JMX, POJO
> Reporter: Masafumi Miura
> Attachments: HelloService-AS7-inject-reproducer.tar.gz
>
>
> When injecting POJO to MBean by using {{<inject bean="myTask"/>}} in {{jboss-service.xml}} of SAR like the following:
> * META-INF/jboss-service.xml:
> {code:xml}
> <server>
> <mbean code="com.redhat.jboss.support.HelloService"
> name="example:type=HelloService,service=Hello">
> <attribute name="Message">Hello!!</attribute>
> <attribute name="Task"><inject bean="myTask"/></attribute>
> </mbean>
> </server>
> {code}
> * META-INF/jboss-beans.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <deployment ... >
> <bean name="myTask" class="com.redhat.jboss.support.SimpleTask">
> </bean>
> </deployment>
> {code}
> Then the following ERROR is happened at deployment of SAR:
> {noformat:title=7.1.4.Final}
> ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.mbean.service.example:type=HelloService,service=Hello.start Missing[jboss.mbean.service.myTask.start]","jboss.mbean.registration.example:type=HelloService,service=Hello Missing[JBAS014861: <one or more transitive dependencies>]","jboss.mbean.service.example:type=HelloService,service=Hello.create Missing[jboss.mbean.service.myTask.create]"]}}}
> {noformat}
> {noformat:title=7.2.0.Alpha1}
> ERROR [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "HelloService.sar" was rolled back with the following failure message:
> {"JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.mbean.service.example:type=HelloService,service=Hello.start is missing [jboss.mbean.service.myTask.start]",
> "jboss.mbean.service.example:type=HelloService,service=Hello.create is missing [jboss.mbean.service.myTask.create]"
> ]}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-447) Add jboss-metadata-common 8.1.2.Final
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-447?page=com.atlassian.jira.plugin... ]
Jeff Mesnil reassigned WFCORE-447:
----------------------------------
Assignee: Jeff Mesnil (was: Tomaz Cerar)
> Add jboss-metadata-common 8.1.2.Final
> -------------------------------------
>
> Key: WFCORE-447
> URL: https://issues.jboss.org/browse/WFCORE-447
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Test Suite
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> To be able to validate the subsystem's XML (in the tests and provided by the templates), we need to replace any expression in the XML (e.g. to replace an expression that resolve to a boolean or an int).
> We need to add jboss-metadata-commons to the wildly-core project that will be used in the subsystem-test/framework/ module.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFCORE-447) Add jboss-metadata-common 8.1.2.Final
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFCORE-447:
----------------------------------
Summary: Add jboss-metadata-common 8.1.2.Final
Key: WFCORE-447
URL: https://issues.jboss.org/browse/WFCORE-447
Project: WildFly Core
Issue Type: Component Upgrade
Components: Test Suite
Reporter: Jeff Mesnil
Assignee: Tomaz Cerar
To be able to validate the subsystem's XML (in the tests and provided by the templates), we need to replace any expression in the XML (e.g. to replace an expression that resolve to a boolean or an int).
We need to add jboss-metadata-commons to the wildly-core project that will be used in the subsystem-test/framework/ module.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (LOGMGR-119) Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-119?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated LOGMGR-119:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1171020
> Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
> ----------------------------------------------------------------------------
>
> Key: LOGMGR-119
> URL: https://issues.jboss.org/browse/LOGMGR-119
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 1.5.2.Final
> Reporter: Osamu Nagano
> Assignee: James Perkins
>
> When {{PeriodicRotatingFileHandler}} with suffix "yyyy-ww" rotates a log file over a year, file that belongs to the new year is incorrectly named using the previous year.
> Here is a demonstrating test code supposed to be pasted into {{src/test/java/org/jboss/logmanager/handlers/PeriodicSizeRotatingFileHandlerTests.java}}. It mimics a record started from 2014-12-24 and the resulting backup log file is named {{rotating-file-handler.log.2014-01}}. It should be 2015 instead.
> {code}
> /*
> * Run with the following command:
> * mvn compile test -Dtest=PeriodicSizeRotatingFileHandlerTests#testPeriodicRotateWeekOfYear
> */
> @Test
> public void testPeriodicRotateWeekOfYear() throws Exception {
> SimpleDateFormat fmt = periodFormatMap.get(Calendar.WEEK_OF_YEAR);
> Calendar cal = Calendar.getInstance(java.util.TimeZone.getTimeZone("GMT"));
>
> PeriodicRotatingFileHandler handler = new PeriodicRotatingFileHandler();
> handler.setAutoFlush(true);
> handler.setFormatter(new PatternFormatter("%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"));
> handler.setSuffix("." + fmt.toPattern());
> handler.setFile(logFile);
>
> cal.set(Calendar.YEAR, 2014);
> cal.set(Calendar.MONTH, 12 - 1);
> cal.set(Calendar.DAY_OF_MONTH, 24);
> cal.set(Calendar.HOUR_OF_DAY, 12);
>
> for (int i = 0; i < 14; i++) {
> long tim = cal.getTimeInMillis();
> String fdate = fmt.format(tim);
> ExtLogRecord record = createLogRecord("%02d th formatted date is %s", i, fdate);
> record.setMillis(tim);
> handler.publish(record);
>
> cal.add(Calendar.DAY_OF_MONTH, 1);
> }
>
> handler.close();
>
> for (String logFile : BASE_LOG_DIR.list()) {
> System.out.println(logFile);
> }
> Assert.assertTrue("Dummy.", true);
> }
> {code}
> And here is the result of the test method.
> {code}
> % ll logs
> total 12K
> -rw-r--r--. 1 onagano onagano 228 Dec 5 17:09 rotating-file-handler.log
> -rw-r--r--. 1 onagano onagano 532 Dec 5 17:09 rotating-file-handler.log.2014-01
> -rw-r--r--. 1 onagano onagano 0 Dec 5 17:09 rotating-file-handler.log.2014-49
> -rw-r--r--. 1 onagano onagano 304 Dec 5 17:09 rotating-file-handler.log.2014-52
> % cat logs/rotating-file-handler.log.2014-52
> 2014-12-24 21:09:43,921 INFO [null] (main) 00 th formatted date is 2014-52
> 2014-12-25 21:09:43,921 INFO [null] (main) 01 th formatted date is 2014-52
> 2014-12-26 21:09:43,921 INFO [null] (main) 02 th formatted date is 2014-52
> 2014-12-27 21:09:43,921 INFO [null] (main) 03 th formatted date is 2014-52
> % cat logs/rotating-file-handler.log.2014-01
> 2014-12-28 21:09:43,921 INFO [null] (main) 04 th formatted date is 2014-01
> 2014-12-29 21:09:43,921 INFO [null] (main) 05 th formatted date is 2014-01
> 2014-12-30 21:09:43,921 INFO [null] (main) 06 th formatted date is 2014-01
> 2014-12-31 21:09:43,921 INFO [null] (main) 07 th formatted date is 2014-01
> 2015-01-01 21:09:43,921 INFO [null] (main) 08 th formatted date is 2015-01
> 2015-01-02 21:09:43,921 INFO [null] (main) 09 th formatted date is 2015-01
> 2015-01-03 21:09:43,921 INFO [null] (main) 10 th formatted date is 2015-01
> % cat logs/rotating-file-handler.log
> 2015-01-04 21:09:43,921 INFO [null] (main) 11 th formatted date is 2015-02
> 2015-01-05 21:09:43,921 INFO [null] (main) 12 th formatted date is 2015-02
> 2015-01-06 21:09:43,921 INFO [null] (main) 13 th formatted date is 2015-02
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (LOGMGR-119) Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
by Osamu Nagano (JIRA)
Osamu Nagano created LOGMGR-119:
-----------------------------------
Summary: Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
Key: LOGMGR-119
URL: https://issues.jboss.org/browse/LOGMGR-119
Project: JBoss Log Manager
Issue Type: Bug
Affects Versions: 1.5.2.Final
Reporter: Osamu Nagano
Assignee: James Perkins
When {{PeriodicRotatingFileHandler}} with suffix "yyyy-ww" rotates a log file over a year, file that belongs to the new year is incorrectly named using the previous year.
Here is a demonstrating test code supposed to be pasted into {{src/test/java/org/jboss/logmanager/handlers/PeriodicSizeRotatingFileHandlerTests.java}}. It mimics a record started from 2014-12-24 and the resulting backup log file is named {{rotating-file-handler.log.2014-01}}. It should be 2015 instead.
{code}
/*
* Run with the following command:
* mvn compile test -Dtest=PeriodicSizeRotatingFileHandlerTests#testPeriodicRotateWeekOfYear
*/
@Test
public void testPeriodicRotateWeekOfYear() throws Exception {
SimpleDateFormat fmt = periodFormatMap.get(Calendar.WEEK_OF_YEAR);
Calendar cal = Calendar.getInstance(java.util.TimeZone.getTimeZone("GMT"));
PeriodicRotatingFileHandler handler = new PeriodicRotatingFileHandler();
handler.setAutoFlush(true);
handler.setFormatter(new PatternFormatter("%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"));
handler.setSuffix("." + fmt.toPattern());
handler.setFile(logFile);
cal.set(Calendar.YEAR, 2014);
cal.set(Calendar.MONTH, 12 - 1);
cal.set(Calendar.DAY_OF_MONTH, 24);
cal.set(Calendar.HOUR_OF_DAY, 12);
for (int i = 0; i < 14; i++) {
long tim = cal.getTimeInMillis();
String fdate = fmt.format(tim);
ExtLogRecord record = createLogRecord("%02d th formatted date is %s", i, fdate);
record.setMillis(tim);
handler.publish(record);
cal.add(Calendar.DAY_OF_MONTH, 1);
}
handler.close();
for (String logFile : BASE_LOG_DIR.list()) {
System.out.println(logFile);
}
Assert.assertTrue("Dummy.", true);
}
{code}
And here is the result of the test method.
{code}
% ll logs
total 12K
-rw-r--r--. 1 onagano onagano 228 Dec 5 17:09 rotating-file-handler.log
-rw-r--r--. 1 onagano onagano 532 Dec 5 17:09 rotating-file-handler.log.2014-01
-rw-r--r--. 1 onagano onagano 0 Dec 5 17:09 rotating-file-handler.log.2014-49
-rw-r--r--. 1 onagano onagano 304 Dec 5 17:09 rotating-file-handler.log.2014-52
% cat logs/rotating-file-handler.log.2014-52
2014-12-24 21:09:43,921 INFO [null] (main) 00 th formatted date is 2014-52
2014-12-25 21:09:43,921 INFO [null] (main) 01 th formatted date is 2014-52
2014-12-26 21:09:43,921 INFO [null] (main) 02 th formatted date is 2014-52
2014-12-27 21:09:43,921 INFO [null] (main) 03 th formatted date is 2014-52
% cat logs/rotating-file-handler.log.2014-01
2014-12-28 21:09:43,921 INFO [null] (main) 04 th formatted date is 2014-01
2014-12-29 21:09:43,921 INFO [null] (main) 05 th formatted date is 2014-01
2014-12-30 21:09:43,921 INFO [null] (main) 06 th formatted date is 2014-01
2014-12-31 21:09:43,921 INFO [null] (main) 07 th formatted date is 2014-01
2015-01-01 21:09:43,921 INFO [null] (main) 08 th formatted date is 2015-01
2015-01-02 21:09:43,921 INFO [null] (main) 09 th formatted date is 2015-01
2015-01-03 21:09:43,921 INFO [null] (main) 10 th formatted date is 2015-01
% cat logs/rotating-file-handler.log
2015-01-04 21:09:43,921 INFO [null] (main) 11 th formatted date is 2015-02
2015-01-05 21:09:43,921 INFO [null] (main) 12 th formatted date is 2015-02
2015-01-06 21:09:43,921 INFO [null] (main) 13 th formatted date is 2015-02
{code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months
[JBoss JIRA] (WFLY-4008) MBean deployment causes javax.naming.NameNotFoundException: java:comp/BeanManager
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-4008?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-4008:
---------------------------------
I thinks I find the root clause of this issue. There are two action in the setupActions: org.jboss.as.ee.naming.JavaNamespaceSetup and org.jboss.as.weld.arquillian.WeldContextSetup. When the following codes run in MBeanRegistrationService.java
{code}
public synchronized void start(final StartContext context) throws StartException {
final MBeanServer mBeanServer = getMBeanServer();
final T value = this.value.getValue();
try {
objectName = new ObjectName(name);
} catch (MalformedObjectNameException e) {
throw JmxLogger.ROOT_LOGGER.mbeanRegistrationFailed(e, name);
}
try {
for (SetupAction action : setupActions) {
action.setup(Collections.<String, Object>emptyMap());
}
try {
ROOT_LOGGER.debugf("Registering [%s] with name [%s]", value, objectName);
mBeanServer.registerMBean(value, objectName);
} catch (Exception e) {
throw ROOT_LOGGER.mbeanRegistrationFailed(e, name);
}
} finally {
for (SetupAction action : setupActions) {
action.teardown(Collections.<String, Object>emptyMap());
}
}
}
{code}
The JavaNamespaceSetup teardown happens before the WeldContextSetup so it throws NameNotFound Exception in the WeldContextSetup teardown.
The possible fix is to reverse the setupActions before running the teardown method.
> MBean deployment causes javax.naming.NameNotFoundException: java:comp/BeanManager
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4008
> URL: https://issues.jboss.org/browse/WFLY-4008
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMX, Naming
> Affects Versions: 8.1.0.Final
> Reporter: Darryl Miles
> Assignee: Stuart Douglas
> Labels: mbean
>
> If you create an MBean in your EJB and deploy the EJB.
> <pre>
> @SuppressWarnings("serial")
> public class Monitor implements MonitorMXBean, Serializable {
> private static final Logger log = LoggerFactory.getLogger(Monitor.class);
> private Boolean enabled = Boolean.FALSE;
> private Long valueOne;
> public Monitor() {
> log.debug("CTOR");
> }
> @Override
> public Boolean isEnabled() {
> return enabled;
> }
> @Override
> public void setEnabled(Boolean enabled) {
> this.enabled = enabled;
> }
> @Override
> public Long getValueOne() {
> return valueOne;
> }
> @Override
> public void setValueOne(Long valueOne) {
> this.valueOne = valueOne;
> }
> }
> </pre>
> And JMX MXBean
> <pre>
> import javax.management.MXBean;
> @MXBean
> public interface MonitorMXBean {
> void setEnabled(Boolean enabled);
> Boolean isEnabled();
> void setValueOne(Long valueOne);
> Long getValueOne();
> }
> </pre>
> 17:34:42,455 ERROR [org.jboss.as.weld] (MSC service thread 1-1) JBAS016001: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at javax.naming.InitialContext.lookup(InitialContext.java:417) [rt.jar:1.8.0_25]
> at javax.naming.InitialContext.lookup(InitialContext.java:417) [rt.jar:1.8.0_25]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.jmx.MBeanRegistrationService.stop(MBeanRegistrationService.java:132) [wildfly-jmx-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
> Is this related to: https://issues.jboss.org/browse/WFLY-822 ?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 7 months