[JBoss JIRA] (WFLY-6071) Mixed domain test suite should test using the legacy domain.xml files
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6071?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6071:
--------------------------------------
Assignee: Brian Stansberry
> Mixed domain test suite should test using the legacy domain.xml files
> ---------------------------------------------------------------------
>
> Key: WFLY-6071
> URL: https://issues.jboss.org/browse/WFLY-6071
> Project: WildFly
> Issue Type: Task
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The mixed domain testsuite is doing a lot of testing starting with the current release standard configs, then manipulating to get to something interoperable, and then launching a slave.
> This is fine, but we need explicit coverage of the primary use case: take a config that worked in the legacy release, install it on the DC, and then have the slave start, confirming that the slave was able to join.
> This is basically what users will do -- take profiles that worked and try and use them with a current DC and legacy slaves. Trying to take new profiles and adapt them to work on legacy slaves is more of a corner case. And testing that corner case as the primary coverage leads to holes, where the "correction" logic ends up hiding problems that shouldn't be hidden, e.g. WFCORE-1311.
> So, for each legacy release we should boot the current DC with the standard domain.xml for that release and then start a legacy slave from that release.
> We may need to apply some correction here too, but if we do it's a good opportunity to check why it's necessary, and whether a more user-friendly solution can be found.
> That's not 100% coverage as there are things that weren't in our standard domain.xml, but it's a good smoke test. Subsystem specific test suites can check for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1333) Editing of default deployment scanner's relative-to attribute can cause server crash
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1333?page=com.atlassian.jira.plugi... ]
Chao Wang moved JBEAP-3054 to WFCORE-1333:
------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1333 (was: JBEAP-3054)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Server)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.7.Final
(was: 7.0.0.ER4)
> Editing of default deployment scanner's relative-to attribute can cause server crash
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1333
> URL: https://issues.jboss.org/browse/WFCORE-1333
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.7.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Critical
>
> Setting value of {{relative-to}} attribute of default deployment scanner on standalone server to a path which does not exists in file system causes server crash.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6073) WFLY-3551 addition of bv subsystem breaks mixed domain
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-6073:
--------------------------------------
Summary: WFLY-3551 addition of bv subsystem breaks mixed domain
Key: WFLY-6073
URL: https://issues.jboss.org/browse/WFLY-6073
Project: WildFly
Issue Type: Bug
Components: Domain Management, EE
Affects Versions: 10.0.0.CR5
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 10.0.0.Final
Same problem as WFCORE-1311 -- to assist migration, a ProfileParsingCompletionHandler adds an extension that a legacy slave won't understand.
I'll do the same thing as I did with WFCORE-1311 -- only do this for a standalone server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5638) "Buffer was already freed" error from http request processing
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5638?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-5638.
----------------------------------
Resolution: Out of Date
> "Buffer was already freed" error from http request processing
> -------------------------------------------------------------
>
> Key: WFLY-5638
> URL: https://issues.jboss.org/browse/WFLY-5638
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.1.Final
> Reporter: Arto Huusko
> Assignee: Stuart Douglas
> Attachments: stacktrace.txt
>
>
> Undertow causes XNIO exception "Buffer was already freed" during response write, possibly due to premature client close.
> I suspect this may also cause the socket to leak, because the number of "Buffer was already freed" messages in widlfly server.log corresponds to the number of leaked sockets in the lsof command output for the wildfly process (seen as sockets with "can't identify protocol" description).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5932:
--------------------------------------
I think this should fix the problem: https://github.com/undertow-io/undertow/compare/master...stuartwdouglas:s...
Unfortunately I am having trouble getting a reproducer to work. [~rjanik] would you be able to see if this commit fixes it?
> Invalidating a session of an SSO on a different node than where the session was created does not logout the user
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5932
> URL: https://issues.jboss.org/browse/WFLY-5932
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Priority: Blocker
>
> See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate):
> * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2
> Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected):
> * Access A1, authenticate, invalidate session on A1, access A1
> * Access A1, authenticate, access A2, invalidate session on A1, access A1
> Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features
by Johno Crawford (JIRA)
[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ]
Johno Crawford commented on JGRP-2007:
--------------------------------------
Consider using the following pattern in hot path / high performance code areas instead of for loops.
{code}
final int size = futures.size();
for (int i = 0; i < size; i ++) {
futures.get(i).setFailure(cause);
...
{code}
using a for loop eg. for (ChannelFuture future : futures) { implicitly creates an Iterator, which will generate garbage to be collected. JIT's escape analysis should be able to get rid of it once it kicks in, but the first 10.000 iterations will get a penalty.
> Adapt code to use new Java 8 features
> -------------------------------------
>
> Key: JGRP-2007
> URL: https://issues.jboss.org/browse/JGRP-2007
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> E.g replace loops for forEach() etc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JASSIST-260) Stack frame corruption after writing to attribute on injected after method
by Rafael Campos (JIRA)
[ https://issues.jboss.org/browse/JASSIST-260?page=com.atlassian.jira.plugi... ]
Rafael Campos updated JASSIST-260:
----------------------------------
Steps to Reproduce:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Some how get the method hello from Animal into a var name methodHello
methodHello.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
"com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame."
!Image1.png|thumbnail!
Tried several work arounds but basically the problem is that the newly written data can not be read at the return statement. No workaround found so far.
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
Tried search the web for similar issues but with very little luck. Just some cryptic message with some weird workarounds that I could not get to work by any means.
was:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Somehow get the method hello from Animal into a var name methodHello
method.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
"com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame."
!Image1.png|thumbnail!
Tried several work arounds but basically the problem is that the newly written data can not be read at the return statement. No workaround found so far.
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
Tried search the web for similar issues but with very little luck. Just some cryptic message with some weird workarounds that I could not get to work by any means.
> Stack frame corruption after writing to attribute on injected after method
> --------------------------------------------------------------------------
>
> Key: JASSIST-260
> URL: https://issues.jboss.org/browse/JASSIST-260
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Using java 1.8, also tested with java 1.7 same behavior on eclipse Version: Mars.1 Release (4.5.1) on windows 7 x64 bits.
> Reporter: Rafael Campos
> Assignee: Shigeru Chiba
> Priority: Minor
> Attachments: Image1.png
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-678) RichFaces 4 application fails with ELException
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-678?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved WFLY-678.
-----------------------------------
Resolution: Rejected
Thanks, [~yersan]. I'm resolving this per your inputs.
> 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)
9 years, 11 months
[JBoss JIRA] (WFLY-678) RichFaces 4 application fails with ELException
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-678?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-678:
----------------------------------
Fix Version/s: (was: Awaiting Volunteers)
> 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
> 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)
9 years, 11 months