[JBoss JIRA] (WFCORE-915) Allow concurrent registration of slave host controllers
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-915?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFCORE-915:
----------------------------------
Hi Petr,
Just thought I'd follow up on this, since I know things with EAP have been busy. We're possibly considering this change as a feature for EAP 7.1, so just wanted to get your thoughts on testing in some large domains etc, and if that would take a long time to get setup.
Thanks,
Ken
> Allow concurrent registration of slave host controllers
> -------------------------------------------------------
>
> Key: WFCORE-915
> URL: https://issues.jboss.org/browse/WFCORE-915
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha1
>
>
> Registration of slave host controllers must be done with the exclusive ModelController lock held, in order to ensure that the registering HC sees a consistent config throughout the entire process. The drawback to this is registrations must therefore be done in series, which is inefficient in a large domain.
> We need to evaluate how this can be done in parallel, without losing the correctness semantics. For example, have the first registration request acquire the lock, but then don't release the lock as long as any other registrations are in progress.
> The current lock acquisition mechanism based on an OperationStepHandler acquiring the lock[1] can't do this, or at least not without having the request that acquires the lock have to wait for final completion until all other concurrent requests complete. (Doing that will likely cause problems due to that "unlucky" first slave not getting the expected final response. Plus it just smells bad.)
> A possibility is to remove the currrent lock acquisition in the OSH[1] and instead change the internal HostControllerRegistrationHandler.OperationExecutor API to expose a use-case specific method for the initial registration call.[2] The actual HostControllerRegistrationHandler.OperationExecutor impl is DomainModelControllerService, which is the service that installs the ModelControllerImpl and potentially has closer access to its non-public API (i.e. the locking methods.) So DomainModelControllerService can perhaps therefore coordinate the locking, holding the lock until all active registrations complete.
> [1] https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/m...
> [2] I want to change that API anyway. See TODO at https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/m...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.
by Gabriel Lavoie (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Gabriel Lavoie edited comment on WFLY-6489 at 4/18/16 2:39 PM:
---------------------------------------------------------------
I've a tested a new build with your pull request and the NPE has been fixed.
{quote}"So long as you don't have referential integrity constraints across session attributes (e.g. a given object isn't referenced by multiple session attributes), you can use attribute replication without issue."{quote}
I don't understand your statement, if I have a mutable complex object and I get it and modifies it within a request, it will not get replicated at the end of the request with transactions disabled unless I explicitly call session.setAttribute() on it again.
There is another example where the session attribute application doesn't work at all with batch disabled: use of the <jsp:useBean/> tag.
In the following sample, we never see the Date update on the second node:
{code}
<%@ page import="java.util.Date" %>
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<jsp:useBean id="complexAttr" scope="session" class="bean.ComplexAttr"/>
<%
complexAttr.value = new Date();
%>
{code}
{code}
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<jsp:useBean id="complexAttr" scope="session" class="bean.ComplexAttr"/>
<html>
<head>
<title></title>
</head>
<body>
Date is: <%=complexAttr.value%>
</body>
</html>
{code}
{code}
package bean;
import java.io.Serializable;
import java.util.Date;
public class ComplexAttr implements Serializable {
public Date value;
}
{code}
was (Author: glavoie):
"So long as you don't have referential integrity constraints across session attributes (e.g. a given object isn't referenced by multiple session attributes), you can use attribute replication without issue."
I don't understand your statement, if I have a mutable complex object and I get it and modifies it within a request, it will not get replicated at the end of the request with transactions disabled unless I explicitly call session.setAttribute() on it again.
There is another example where the session attribute application doesn't work at all with batch disabled: use of the <jsp:useBean/> tag.
In the following sample, we never see the Date update on the second node:
{code}
<%@ page import="java.util.Date" %>
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<jsp:useBean id="complexAttr" scope="session" class="bean.ComplexAttr"/>
<%
complexAttr.value = new Date();
%>
{code}
{code}
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<jsp:useBean id="complexAttr" scope="session" class="bean.ComplexAttr"/>
<html>
<head>
<title></title>
</head>
<body>
Date is: <%=complexAttr.value%>
</body>
</html>
{code}
{code}
package bean;
import java.io.Serializable;
import java.util.Date;
public class ComplexAttr implements Serializable {
public Date value;
}
{code}
> Distributable session may not exist after redirect to same node with optimistic locking.
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6489
> URL: https://issues.jboss.org/browse/WFLY-6489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final, 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: wfly-6489-showcase.zip, wildfly-10-session-issue.zip
>
>
> I'm currently working on porting an application running on EAP 6.1 to WildFly 10 and am encountering multiple session/authentication issues with clustering enabled. Our login flow currently starts from a servlet that accepts the credentials, creates the session, then redirect to the welcome page.
> The first time we execute this flow after the startup of a node, the welcome page can't see at all the session created previously.
> - request.getSession() creates yet another session and a new session cookie is returned.
> - request.getSession(false) returns "null"
> On the second attempt, the flow works as expected.
> The issue can be reproduced on both a single node or a two nodes cluster, as long as <distributable /> is enabled in web.xml.
> We are currently using the master build https://ci.jboss.org/hudson/job/WildFly-latest-master/2244/, but the problem has been noticed on 10.0.0-Final and also 8.2.1-Final.
> I attached a sample web application that I used to reproduce the issue. Our standalone.xml is also included with the clustering configuration we've been using for the web/session cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.
by Gabriel Lavoie (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Gabriel Lavoie commented on WFLY-6489:
--------------------------------------
"So long as you don't have referential integrity constraints across session attributes (e.g. a given object isn't referenced by multiple session attributes), you can use attribute replication without issue."
I don't understand your statement, if I have a mutable complex object and I get it and modifies it within a request, it will not get replicated at the end of the request with transactions disabled unless I explicitly call session.setAttribute() on it again.
There is another example where the session attribute application doesn't work at all with batch disabled: use of the <jsp:useBean/> tag.
In the following sample, we never see the Date update on the second node:
{code}
<%@ page import="java.util.Date" %>
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<jsp:useBean id="complexAttr" scope="session" class="bean.ComplexAttr"/>
<%
complexAttr.value = new Date();
%>
{code}
{code}
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<jsp:useBean id="complexAttr" scope="session" class="bean.ComplexAttr"/>
<html>
<head>
<title></title>
</head>
<body>
Date is: <%=complexAttr.value%>
</body>
</html>
{code}
{code}
package bean;
import java.io.Serializable;
import java.util.Date;
public class ComplexAttr implements Serializable {
public Date value;
}
{code}
> Distributable session may not exist after redirect to same node with optimistic locking.
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6489
> URL: https://issues.jboss.org/browse/WFLY-6489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final, 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: wfly-6489-showcase.zip, wildfly-10-session-issue.zip
>
>
> I'm currently working on porting an application running on EAP 6.1 to WildFly 10 and am encountering multiple session/authentication issues with clustering enabled. Our login flow currently starts from a servlet that accepts the credentials, creates the session, then redirect to the welcome page.
> The first time we execute this flow after the startup of a node, the welcome page can't see at all the session created previously.
> - request.getSession() creates yet another session and a new session cookie is returned.
> - request.getSession(false) returns "null"
> On the second attempt, the flow works as expected.
> The issue can be reproduced on both a single node or a two nodes cluster, as long as <distributable /> is enabled in web.xml.
> We are currently using the master build https://ci.jboss.org/hudson/job/WildFly-latest-master/2244/, but the problem has been noticed on 10.0.0-Final and also 8.2.1-Final.
> I attached a sample web application that I used to reproduce the issue. Our standalone.xml is also included with the clustering configuration we've been using for the web/session cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGTOOL-104) FQCN and an import improperly deconflicted - FQCN lost
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-104?page=com.atlassian.jira.plugi... ]
David Lloyd commented on LOGTOOL-104:
-------------------------------------
I've tagged JDeparser 2.0.2.Final with this fix. If you update the component version in your build, the problem should disappear.
> FQCN and an import improperly deconflicted - FQCN lost
> ------------------------------------------------------
>
> Key: LOGTOOL-104
> URL: https://issues.jboss.org/browse/LOGTOOL-104
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Arcadiy Ivanov
>
> Given:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @MessageLogger(projectCode = "JBOSGI")
> public interface FrameworkLogger extends BasicLogger {
> @LogMessage(level = WARN)
> @Message(id = 11019, value = "Error while calling event hook: %s")
> void warnErrorWhileCallingEventHook(@Cause Throwable cause, EventHook hook);
> @LogMessage(level = WARN)
> @Message(id = 11040, value = "Error while calling bundle event hook: %s")
> void warnErrorWhileCallingBundleEventHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.EventHook hook);
> }
> {code}
> Compilation failure:
> {quote}
> ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[26,8] org.jboss.osgi.framework.FrameworkLogger_$logger is not abstract and does not override abstract method warnErrorWhileCallingBundleEventHook(java.lang.Throwable,org.osgi.framework.hooks.bundle.EventHook) in org.jboss.osgi.framework.FrameworkLogger
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[336,5] method does not override or implement a method from a supertype
> {quote}
> Cause:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @Generated(value = "org.jboss.logging.processor.generator.model.MessageLoggerImplementor", date = "2016-04-18T04:40:24-0400")
> public class FrameworkLogger_$logger extends DelegatingBasicLogger implements FrameworkLogger,BasicLogger,Serializable {
> @Override
> public final void warnErrorWhileCallingEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingEventHook$str(), hook);
> }
> @Override
> public final void warnErrorWhileCallingBundleEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingBundleEventHook$str(), hook);
> }
> }
> {code}
> As you can see the cause of the failure is that {{EventHook}} argument FQCN is lost in the generated {{warnErrorWhileCallingBundleEventHook}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGTOOL-81) Log Tool generates class names that violate FindBugs standard rules
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-81?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGTOOL-81:
--------------------------------------
My main concern is we'd have to update {{org.jboss.logging:jboss-logging}} too making the generated source only compatible with a new release of JBoss Logging. Maybe not the end of the world, but something to consider.
> Log Tool generates class names that violate FindBugs standard rules
> -------------------------------------------------------------------
>
> Key: LOGTOOL-81
> URL: https://issues.jboss.org/browse/LOGTOOL-81
> Project: Log Tool
> Issue Type: Bug
> Environment: OS X Mavericks, Java 1.7
> Reporter: Tom Cunningham
> Assignee: James Perkins
>
> Log Tool generates class names like :
> ./api/target/generated-sources/annotations/org/switchyard/APILogger_$logger.java
> ./validate/target/generated-sources/annotations/org/switchyard/validate/ValidateMessages_$bundle.java
> When I run findbugs, my project isn't clean anymore because of these generated classes - findbugs complains that these classes do not start with a capital letter. It looks like this violates the NM_CLASS_NAMING_CONVENTION rule.
> From Findbugs website :
> Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
> http://findbugs.sourceforge.net/bugDescriptions.html
> I can probably work around this by providing FindBugs exceptions for "_$logger" and "_$bundle", but it might be good practice if the first letter were upper cased in the generated class (i.e. "_$Logger" and "_$Bundle" .
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGTOOL-104) FQCN and an import improperly deconflicted - FQCN lost
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-104?page=com.atlassian.jira.plugi... ]
Arcadiy Ivanov edited comment on LOGTOOL-104 at 4/18/16 1:36 PM:
-----------------------------------------------------------------
[~dmlloyd] You are correct. The following method
{code}
@Override
public final void warnErrorWhileCallingBundleFindHook(final Throwable cause, final FindHook hook) {
{code}
is generated from this
{code}
@LogMessage(level = WARN)
@Message(id = 11039, value = "Error while calling bundle find hook: %s")
void warnErrorWhileCallingBundleFindHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.FindHook hook);
{code}
with no import conflicts. However, the {{FindHook}} type imported is {{import org.osgi.framework.hooks.service.FindHook;}} instead of {{org.osgi.framework.hooks.bundle.FindHook}}.
I'll follow [~jamezp] workaround advice and relax method signatures to j.l.O or convert FQCN to import where available.
was (Author: arcivanov):
[~dmlloyd] You are correct. The following method
{code}
@Override
public final void warnErrorWhileCallingBundleFindHook(final Throwable cause, final FindHook hook) {
{code}
is generated from this
{code}
@LogMessage(level = WARN)
@Message(id = 11039, value = "Error while calling bundle find hook: %s")
void warnErrorWhileCallingBundleFindHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.FindHook hook);
{code}
with no import conflicts.
I'll follow [~jamezp] workaround advice and relax method signatures to j.l.O or convert FQCN to import where available.
> FQCN and an import improperly deconflicted - FQCN lost
> ------------------------------------------------------
>
> Key: LOGTOOL-104
> URL: https://issues.jboss.org/browse/LOGTOOL-104
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Arcadiy Ivanov
>
> Given:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @MessageLogger(projectCode = "JBOSGI")
> public interface FrameworkLogger extends BasicLogger {
> @LogMessage(level = WARN)
> @Message(id = 11019, value = "Error while calling event hook: %s")
> void warnErrorWhileCallingEventHook(@Cause Throwable cause, EventHook hook);
> @LogMessage(level = WARN)
> @Message(id = 11040, value = "Error while calling bundle event hook: %s")
> void warnErrorWhileCallingBundleEventHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.EventHook hook);
> }
> {code}
> Compilation failure:
> {quote}
> ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[26,8] org.jboss.osgi.framework.FrameworkLogger_$logger is not abstract and does not override abstract method warnErrorWhileCallingBundleEventHook(java.lang.Throwable,org.osgi.framework.hooks.bundle.EventHook) in org.jboss.osgi.framework.FrameworkLogger
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[336,5] method does not override or implement a method from a supertype
> {quote}
> Cause:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @Generated(value = "org.jboss.logging.processor.generator.model.MessageLoggerImplementor", date = "2016-04-18T04:40:24-0400")
> public class FrameworkLogger_$logger extends DelegatingBasicLogger implements FrameworkLogger,BasicLogger,Serializable {
> @Override
> public final void warnErrorWhileCallingEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingEventHook$str(), hook);
> }
> @Override
> public final void warnErrorWhileCallingBundleEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingBundleEventHook$str(), hook);
> }
> }
> {code}
> As you can see the cause of the failure is that {{EventHook}} argument FQCN is lost in the generated {{warnErrorWhileCallingBundleEventHook}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGTOOL-104) FQCN and an import improperly deconflicted - FQCN lost
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-104?page=com.atlassian.jira.plugi... ]
Arcadiy Ivanov edited comment on LOGTOOL-104 at 4/18/16 1:35 PM:
-----------------------------------------------------------------
[~dmlloyd] You are correct. The following method
{code}
@Override
public final void warnErrorWhileCallingBundleFindHook(final Throwable cause, final FindHook hook) {
{code}
is generated from this
{code}
@LogMessage(level = WARN)
@Message(id = 11039, value = "Error while calling bundle find hook: %s")
void warnErrorWhileCallingBundleFindHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.FindHook hook);
{code}
with no import conflicts.
I'll follow [~jamezp] workaround advice and relax method signatures to j.l.O or convert FQCN to import where available.
was (Author: arcivanov):
[~dmlloyd] You are correct. The following method
{{{
@Override
public final void warnErrorWhileCallingBundleFindHook(final Throwable cause, final FindHook hook) {
}}}
is generated from this
{{{
@LogMessage(level = WARN)
@Message(id = 11039, value = "Error while calling bundle find hook: %s")
void warnErrorWhileCallingBundleFindHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.FindHook hook);
}}}
with no import conflicts.
I'll follow [~jamezp] workaround advice and relax method signatures to j.l.O or convert FQCN to import where available.
> FQCN and an import improperly deconflicted - FQCN lost
> ------------------------------------------------------
>
> Key: LOGTOOL-104
> URL: https://issues.jboss.org/browse/LOGTOOL-104
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Arcadiy Ivanov
>
> Given:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @MessageLogger(projectCode = "JBOSGI")
> public interface FrameworkLogger extends BasicLogger {
> @LogMessage(level = WARN)
> @Message(id = 11019, value = "Error while calling event hook: %s")
> void warnErrorWhileCallingEventHook(@Cause Throwable cause, EventHook hook);
> @LogMessage(level = WARN)
> @Message(id = 11040, value = "Error while calling bundle event hook: %s")
> void warnErrorWhileCallingBundleEventHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.EventHook hook);
> }
> {code}
> Compilation failure:
> {quote}
> ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[26,8] org.jboss.osgi.framework.FrameworkLogger_$logger is not abstract and does not override abstract method warnErrorWhileCallingBundleEventHook(java.lang.Throwable,org.osgi.framework.hooks.bundle.EventHook) in org.jboss.osgi.framework.FrameworkLogger
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[336,5] method does not override or implement a method from a supertype
> {quote}
> Cause:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @Generated(value = "org.jboss.logging.processor.generator.model.MessageLoggerImplementor", date = "2016-04-18T04:40:24-0400")
> public class FrameworkLogger_$logger extends DelegatingBasicLogger implements FrameworkLogger,BasicLogger,Serializable {
> @Override
> public final void warnErrorWhileCallingEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingEventHook$str(), hook);
> }
> @Override
> public final void warnErrorWhileCallingBundleEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingBundleEventHook$str(), hook);
> }
> }
> {code}
> As you can see the cause of the failure is that {{EventHook}} argument FQCN is lost in the generated {{warnErrorWhileCallingBundleEventHook}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ELY-497) Lazt scope creation
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-497:
------------------------------------
Summary: Lazt scope creation
Key: ELY-497
URL: https://issues.jboss.org/browse/ELY-497
Project: WildFly Elytron
Issue Type: Feature Request
Components: HTTP
Reporter: Darran Lofthouse
Priority: Critical
Fix For: 1.1.0.CR1
It is not confirmed that we will do this but if we want to support lazy creation of scoped e.g. session scoped then we need to do it now or adding later may become a compatibility problem.
We could add methods to check if one exists and a method to create it - or we could wait until the firs attachment is added - or other options.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGTOOL-104) FQCN and an import improperly deconflicted - FQCN lost
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-104?page=com.atlassian.jira.plugi... ]
Arcadiy Ivanov commented on LOGTOOL-104:
----------------------------------------
[~dmlloyd] You are correct. The following method
{{{
@Override
public final void warnErrorWhileCallingBundleFindHook(final Throwable cause, final FindHook hook) {
}}}
is generated from this
{{{
@LogMessage(level = WARN)
@Message(id = 11039, value = "Error while calling bundle find hook: %s")
void warnErrorWhileCallingBundleFindHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.FindHook hook);
}}}
with no import conflicts.
I'll follow [~jamezp] workaround advice and relax method signatures to j.l.O or convert FQCN to import where available.
> FQCN and an import improperly deconflicted - FQCN lost
> ------------------------------------------------------
>
> Key: LOGTOOL-104
> URL: https://issues.jboss.org/browse/LOGTOOL-104
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Arcadiy Ivanov
>
> Given:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @MessageLogger(projectCode = "JBOSGI")
> public interface FrameworkLogger extends BasicLogger {
> @LogMessage(level = WARN)
> @Message(id = 11019, value = "Error while calling event hook: %s")
> void warnErrorWhileCallingEventHook(@Cause Throwable cause, EventHook hook);
> @LogMessage(level = WARN)
> @Message(id = 11040, value = "Error while calling bundle event hook: %s")
> void warnErrorWhileCallingBundleEventHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.EventHook hook);
> }
> {code}
> Compilation failure:
> {quote}
> ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[26,8] org.jboss.osgi.framework.FrameworkLogger_$logger is not abstract and does not override abstract method warnErrorWhileCallingBundleEventHook(java.lang.Throwable,org.osgi.framework.hooks.bundle.EventHook) in org.jboss.osgi.framework.FrameworkLogger
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[336,5] method does not override or implement a method from a supertype
> {quote}
> Cause:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @Generated(value = "org.jboss.logging.processor.generator.model.MessageLoggerImplementor", date = "2016-04-18T04:40:24-0400")
> public class FrameworkLogger_$logger extends DelegatingBasicLogger implements FrameworkLogger,BasicLogger,Serializable {
> @Override
> public final void warnErrorWhileCallingEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingEventHook$str(), hook);
> }
> @Override
> public final void warnErrorWhileCallingBundleEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingBundleEventHook$str(), hook);
> }
> }
> {code}
> As you can see the cause of the failure is that {{EventHook}} argument FQCN is lost in the generated {{warnErrorWhileCallingBundleEventHook}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGTOOL-104) FQCN and an import improperly deconflicted - FQCN lost
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-104?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGTOOL-104:
---------------------------------------
A simple fix would just be to use a generic type or even just a {{java.lang.Object}} argument for one of the parameters.
> FQCN and an import improperly deconflicted - FQCN lost
> ------------------------------------------------------
>
> Key: LOGTOOL-104
> URL: https://issues.jboss.org/browse/LOGTOOL-104
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Arcadiy Ivanov
>
> Given:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @MessageLogger(projectCode = "JBOSGI")
> public interface FrameworkLogger extends BasicLogger {
> @LogMessage(level = WARN)
> @Message(id = 11019, value = "Error while calling event hook: %s")
> void warnErrorWhileCallingEventHook(@Cause Throwable cause, EventHook hook);
> @LogMessage(level = WARN)
> @Message(id = 11040, value = "Error while calling bundle event hook: %s")
> void warnErrorWhileCallingBundleEventHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.EventHook hook);
> }
> {code}
> Compilation failure:
> {quote}
> ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[26,8] org.jboss.osgi.framework.FrameworkLogger_$logger is not abstract and does not override abstract method warnErrorWhileCallingBundleEventHook(java.lang.Throwable,org.osgi.framework.hooks.bundle.EventHook) in org.jboss.osgi.framework.FrameworkLogger
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[336,5] method does not override or implement a method from a supertype
> {quote}
> Cause:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @Generated(value = "org.jboss.logging.processor.generator.model.MessageLoggerImplementor", date = "2016-04-18T04:40:24-0400")
> public class FrameworkLogger_$logger extends DelegatingBasicLogger implements FrameworkLogger,BasicLogger,Serializable {
> @Override
> public final void warnErrorWhileCallingEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingEventHook$str(), hook);
> }
> @Override
> public final void warnErrorWhileCallingBundleEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingBundleEventHook$str(), hook);
> }
> }
> {code}
> As you can see the cause of the failure is that {{EventHook}} argument FQCN is lost in the generated {{warnErrorWhileCallingBundleEventHook}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years