[JBoss JIRA] (WFCORE-1311) WFCORE-893 Fix breaks mixed-domain
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1311?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1311:
-------------------------------------
Priority: Major (was: Critical)
> WFCORE-893 Fix breaks mixed-domain
> ----------------------------------
>
> Key: WFCORE-1311
> URL: https://issues.jboss.org/browse/WFCORE-1311
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Affects Versions: 2.0.7.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.8.Final
>
>
> The WFCORE-893 fix breaks mixed-domain use cases by adding subsystem=io if its not present. That's ok for standalone, but in a domain it means a subsystem not understood by legacy slaves will get added into profiles used by those slaves. Which will fail.
> I've considered doing some sort of transformer trick to discard this subsystem if its config is default, but I suspect it's better to just not do the WFCORE-893 thing on the DC.
> Discarding might be ok if we just do a resource transformer discard but reject all ops thereafter. Idea being that if the io config is default, matching what legacy slaves did, then we let the slave boot. Then any subsequent op must be either pointless or moving away from default, and must be rejected.
> But still, just not doing the WFCORE-893 thing on the DC is probably better. Or at least simpler right now.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-4786) Clustering integration tests fails once -Dnode0 and -Dnode1 are used
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4786?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-4786:
--------------------------------------
Current list of failures is:
{noformat}
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<2ss7WTESS7lVo3Is6zP9Lq6HGLrsV7rMfbHJjIYV=node-1>
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<Frmey6bDfZCM7e-2ScAc7AnFI6CSdk3NaaVyVZOL=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<HqqvZ0a_ACDXWc0RDmYyCON3cEZL3h7mf1KfpO2n=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<oqVW8pfo_r1ZeaL-zyVMaIJ40uWrOF_Xin3lKeNp=node-1>
NonDistributableTestCase.test:127 expected:<2> but was:<1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ia8teO0bP1vW5DM0pqEevfUE-brgUsdmBJlMnejs=node-1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ULQ3vjz743vvjnLJE7nLQDNTNeDJ2p02NS6qRGp0=node-1>
Tests run: 54, Failures: 7, Errors: 0, Skipped: 3
{noformat}
All except for the non-distrubutable fails on line
org/jboss/as/test/clustering/cluster/web/ClusteredWebFailoverAbstractCase.java:164
which was introduced in WFLY-2774 via commit id:
c3902e26957f607983d81c7a8f3f18e358acf743
> Clustering integration tests fails once -Dnode0 and -Dnode1 are used
> --------------------------------------------------------------------
>
> Key: WFLY-4786
> URL: https://issues.jboss.org/browse/WFLY-4786
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Alpha3
> Reporter: Petr Kremensky
> Assignee: Radoslav Husar
> Fix For: 10.0.0.Beta2
>
> Attachments: maven.logs, results.zip, testsuite.clustering.logs.zip
>
>
> Tests from wildfly-ts-integ-clustering module fails once we change default binding interfaces by -Dnode0 and -Dnode1 properties.
> See https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-...
> * build 5 binds to localhost (no -Dnode*)
> * build 6 uses -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2
> Similar failures were addressed for EAP 6 by https://bugzilla.redhat.com/show_bug.cgi?id=1076015
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-4786) Clustering integration tests fails once -Dnode0 and -Dnode1 are used
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4786?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-4786 at 1/25/16 7:38 PM:
---------------------------------------------------------------
Current list of failures is:
{noformat}
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<2ss7WTESS7lVo3Is6zP9Lq6HGLrsV7rMfbHJjIYV=node-1>
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<Frmey6bDfZCM7e-2ScAc7AnFI6CSdk3NaaVyVZOL=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<HqqvZ0a_ACDXWc0RDmYyCON3cEZL3h7mf1KfpO2n=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<oqVW8pfo_r1ZeaL-zyVMaIJ40uWrOF_Xin3lKeNp=node-1>
NonDistributableTestCase.test:127 expected:<2> but was:<1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ia8teO0bP1vW5DM0pqEevfUE-brgUsdmBJlMnejs=node-1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ULQ3vjz743vvjnLJE7nLQDNTNeDJ2p02NS6qRGp0=node-1>
{noformat}
Out of total tests run: 54, Failures: 7, Errors: 0, Skipped: 3
All except for the non-distrubutable fails on line
org/jboss/as/test/clustering/cluster/web/ClusteredWebFailoverAbstractCase.java:164
which was introduced in WFLY-2774 via commit id:
c3902e26957f607983d81c7a8f3f18e358acf743
was (Author: rhusar):
Current list of failures is:
{noformat}
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<2ss7WTESS7lVo3Is6zP9Lq6HGLrsV7rMfbHJjIYV=node-1>
CoarseWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<Frmey6bDfZCM7e-2ScAc7AnFI6CSdk3NaaVyVZOL=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<HqqvZ0a_ACDXWc0RDmYyCON3cEZL3h7mf1KfpO2n=node-1>
GranularWebFailoverTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<oqVW8pfo_r1ZeaL-zyVMaIJ40uWrOF_Xin3lKeNp=node-1>
NonDistributableTestCase.test:127 expected:<2> but was:<1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulUndeployFailover:103->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ia8teO0bP1vW5DM0pqEevfUE-brgUsdmBJlMnejs=node-1>
ReplicationForNegotiationAuthenticatorTestCase>ClusteredWebFailoverAbstractCase.testGracefulSimpleFailover:83->ClusteredWebFailoverAbstractCase.testFailover:164 expected null, but was:<ULQ3vjz743vvjnLJE7nLQDNTNeDJ2p02NS6qRGp0=node-1>
Tests run: 54, Failures: 7, Errors: 0, Skipped: 3
{noformat}
All except for the non-distrubutable fails on line
org/jboss/as/test/clustering/cluster/web/ClusteredWebFailoverAbstractCase.java:164
which was introduced in WFLY-2774 via commit id:
c3902e26957f607983d81c7a8f3f18e358acf743
> Clustering integration tests fails once -Dnode0 and -Dnode1 are used
> --------------------------------------------------------------------
>
> Key: WFLY-4786
> URL: https://issues.jboss.org/browse/WFLY-4786
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Alpha3
> Reporter: Petr Kremensky
> Assignee: Radoslav Husar
> Fix For: 10.0.0.Beta2
>
> Attachments: maven.logs, results.zip, testsuite.clustering.logs.zip
>
>
> Tests from wildfly-ts-integ-clustering module fails once we change default binding interfaces by -Dnode0 and -Dnode1 properties.
> See https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-...
> * build 5 binds to localhost (no -Dnode*)
> * build 6 uses -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2
> Similar failures were addressed for EAP 6 by https://bugzilla.redhat.com/show_bug.cgi?id=1076015
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-851) Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-851?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-851:
------------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1248156|https://bugzilla.redhat.com/show_bug.cgi?id=1248156] from ASSIGNED to ON_QA
> Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-851
> URL: https://issues.jboss.org/browse/WFCORE-851
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Brad Maxwell
> Assignee: Filippe Spolti
> Fix For: 2.0.5.CR1
>
>
> Description of problem:
> EJB CLient was configured with DNS FQDN to configure access to a remote EJB. If run a simple test adding an entry in /etc/hosts file pointing that FQDN to localhost for tests everything works. However, after finish the tests and remove the entry, the client still connects to localhost instead of resolve the new IP address. Even adding networkaddress.cache.ttl=30 inside security settings didn't work too.
> How reproducible:
> Everytime you use DNS names to connect to a remote EJB.
> Steps to Reproduce:
> 1. Configure a simple client that connects to a remote EJB using dns name
> 2. add an entry in /etc/hosts mapping the dns name to localhost
> 3. run the client code
> 4. remove the entry in /etc/hosts
> 5. run the client code again
> Actual results:
> EJB remote is still reached from localhost
> Expected results:
> After changing DNS record EJB will be reached in this new address
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by George Turner (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
George Turner commented on WFLY-4769:
-------------------------------------
Can I get an answer on how to do this with a WildFly 10 JNDI client? If the only way to get this to work is non-JNDI, I am open to that, but the example posted here was incomplete and I cannot find a similar example to try with.
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-678) RichFaces 4 application fails with ELException
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-678?page=com.atlassian.jira.plugin.s... ]
Yeray Santana Borges updated WFLY-678:
--------------------------------------
Attachment: WILDFLY-678.zip
This issue can be closed.
The error doesn't come from wildfly, the problem here is a wrong configuration of rich:graphValidator. [link graphValidator vdldoc|http://docs.jboss.org/richfaces/latest_4_5_X/vdldoc/] the value of groups must evaluate to java.lang.Class[].
I have attached to the issue a sample maven project with a graphValidator correctly configured. No problems there
> RichFaces 4 application fails with ELException
> ----------------------------------------------
>
> Key: WFLY-678
> URL: https://issues.jboss.org/browse/WFLY-678
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Environment: Jenkins build 1402
> Reporter: Juergen Zimmermann
> Fix For: Awaiting Volunteers
>
> Attachments: testcase-src.zip, testcase.ear.zip, WILDFLY-678.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> at java.lang.Thread.run(Thread.java:662)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (LOGTOOL-96) Static & default interface methods in Logger interface require annotation
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-96?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGTOOL-96:
---------------------------------
Fix Version/s: 2.1.0.Alpha1
> Static & default interface methods in Logger interface require annotation
> -------------------------------------------------------------------------
>
> Key: LOGTOOL-96
> URL: https://issues.jboss.org/browse/LOGTOOL-96
> Project: Log Tool
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: James Perkins
> Fix For: 2.1.0.Alpha1
>
>
> When I want to add a static helper method to the interface used for message logger, I get an error about requiring the @Message annotation. I think that this should not be required for static methods.
> My usecase:
> {code}
> @MessageLogger(projectCode = "FOO")
> public interface FooMessageLogger extends BasicLogger {
> static FooMessageLogger getLog(Class clazz) {
> return Logger.getMessageLogger(FooMessageLogger.class, clazz.getName());
> }
> /* regular annotated logging methods */
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months