February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3664) Exceptions during download of webstart libraries

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3664?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3664: -------------------------------------- To repeat what I mentioned on the forum thread: I just tested this, and I see the same issue, however it does not really appear to be a bug in Undertow but rather a bug in the JnlpDownloadServet. The code in jnlp.sample.servlet.JnlpResource#getLastModified(ServletContext, java.net.URL, java.lang.String) does the following: {code} long getLastModified( ServletContext context, URL resource, String path ) { long lastModified = 0; URLConnection conn; try { // Get last modified time conn = resource.openConnection(); lastModified = conn.getLastModified(); } catch ( Exception e ) { // do nothing } {code} In this case the URL instance is a file:// URL and the resulting connection is a FileURLConnection. When FileUrlConnection.getLastModified() is called the URLConnection implementation opens a FileInputStream. The only way to close this stream is to do: conn.getInputStream().close(). The only part of this that really has anything to do with Undertow is that it returns a file based URL, which is perfectly legitimate. > Exceptions during download of webstart libraries > ------------------------------------------------ > > Key: WFLY-3664 > URL: https://issues.jboss.org/browse/WFLY-3664 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Windows 7 (64bit), Windows Server 2012 R2 (64bit) > Reporter: Markus Schwarz > Assignee: Tomaz Cerar > Priority: Minor > Attachments: demo-src.zip, lsof.log.gz, server.log, server.log.gz > > > I have a webstart application using the JnlpDownloadServlet. If the client cache is empty, launching the JNLP will download the libraries. The webstart application works as expected, but in the server logs there are many errors regarding download of the libraries. > Just to mention: Not always the same libraries are listed with erros in the logs files. Sometimes I even got now exceptions. > For my tests I used Wildfly 8.1.0.FINAL as well as a nightly build from 24. of July without any further changes of the configuration files (https://ci.jboss.org/hudson/job/WildFly-latest-master/). > I tested it under Windows 7 and Windows Server 2012 R2. The demo contains an older JnlpDownloadServlet, but I tested it also with the one coming with JDK 7u65. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4378) Infinispan/JGroups subsystem check for and correct diffs in the default config we ship vs. what we persist

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4378?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-4378: --------------------------------- Due Date: 27/Feb/15 > Infinispan/JGroups subsystem check for and correct diffs in the default config we ship vs. what we persist > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-4378 > URL: https://issues.jboss.org/browse/WFLY-4378 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > https://github.com/wildfly/wildfly/pull/7184#issuecomment-75439059 > Brian: > {quote}Semi-tangent: could you guys check for and correct diffs in the default config we ship vs. what we persist? E.g. > 1) Start a new server running standalone-full-ha.xml > 2) Use cli to add a system prop (just to force persistence) > 3) Diff standalone-full-ha.xml vs standalone/configuration/standalone_xml_history/standalone-full-ha.initial.xml > There shouldn't be changes other than the added system prop. Any changes mean either our default configs are wrong or the marshalling is wrong. Both should match xsd. I did this for another reason a couple weeks ago and saw some changes in the clustering subsystems. Perhaps this PR fixes the problem, but I have a feeling I saw something else besides this.{quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4378) Infinispan/JGroups subsystem check for and correct diffs in the default config we ship vs. what we persist

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-4378: ------------------------------------ Summary: Infinispan/JGroups subsystem check for and correct diffs in the default config we ship vs. what we persist Key: WFLY-4378 URL: https://issues.jboss.org/browse/WFLY-4378 Project: WildFly Issue Type: Task Components: Clustering Affects Versions: 9.0.0.Alpha1 Reporter: Radoslav Husar Assignee: Radoslav Husar https://github.com/wildfly/wildfly/pull/7184#issuecomment-75439059 Semi-tangent: could you guys check for and correct diffs in the default config we ship vs. what we persist? E.g. 1) Start a new server running standalone-full-ha.xml 2) Use cli to add a system prop (just to force persistence) 3) Diff standalone-full-ha.xml vs standalone/configuration/standalone_xml_history/standalone-full-ha.initial.xml There shouldn't be changes other than the added system prop. Any changes mean either our default configs are wrong or the marshalling is wrong. Both should match xsd. I did this for another reason a couple weeks ago and saw some changes in the clustering subsystems. Perhaps this PR fixes the problem, but I have a feeling I saw something else besides this. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4378) Infinispan/JGroups subsystem check for and correct diffs in the default config we ship vs. what we persist

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4378?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-4378: --------------------------------- Description: https://github.com/wildfly/wildfly/pull/7184#issuecomment-75439059 Brian: {quote}Semi-tangent: could you guys check for and correct diffs in the default config we ship vs. what we persist? E.g. 1) Start a new server running standalone-full-ha.xml 2) Use cli to add a system prop (just to force persistence) 3) Diff standalone-full-ha.xml vs standalone/configuration/standalone_xml_history/standalone-full-ha.initial.xml There shouldn't be changes other than the added system prop. Any changes mean either our default configs are wrong or the marshalling is wrong. Both should match xsd. I did this for another reason a couple weeks ago and saw some changes in the clustering subsystems. Perhaps this PR fixes the problem, but I have a feeling I saw something else besides this.{quote} was: https://github.com/wildfly/wildfly/pull/7184#issuecomment-75439059 Semi-tangent: could you guys check for and correct diffs in the default config we ship vs. what we persist? E.g. 1) Start a new server running standalone-full-ha.xml 2) Use cli to add a system prop (just to force persistence) 3) Diff standalone-full-ha.xml vs standalone/configuration/standalone_xml_history/standalone-full-ha.initial.xml There shouldn't be changes other than the added system prop. Any changes mean either our default configs are wrong or the marshalling is wrong. Both should match xsd. I did this for another reason a couple weeks ago and saw some changes in the clustering subsystems. Perhaps this PR fixes the problem, but I have a feeling I saw something else besides this. > Infinispan/JGroups subsystem check for and correct diffs in the default config we ship vs. what we persist > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-4378 > URL: https://issues.jboss.org/browse/WFLY-4378 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > https://github.com/wildfly/wildfly/pull/7184#issuecomment-75439059 > Brian: > {quote}Semi-tangent: could you guys check for and correct diffs in the default config we ship vs. what we persist? E.g. > 1) Start a new server running standalone-full-ha.xml > 2) Use cli to add a system prop (just to force persistence) > 3) Diff standalone-full-ha.xml vs standalone/configuration/standalone_xml_history/standalone-full-ha.initial.xml > There shouldn't be changes other than the added system prop. Any changes mean either our default configs are wrong or the marshalling is wrong. Both should match xsd. I did this for another reason a couple weeks ago and saw some changes in the clustering subsystems. Perhaps this PR fixes the problem, but I have a feeling I saw something else besides this.{quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-487) Instability in RespawnHttpTestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-487?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-487: ------------------------------------ Attachment: respawn-http-threads.txt This seems to be hanging regularly. Attached is a thread dump taken from a hang today: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=36482&tab=buil... It includes a dump of a ProcessController and a Server. Those were the running processes. > Instability in RespawnHttpTestCase > ----------------------------------- > > Key: WFCORE-487 > URL: https://issues.jboss.org/browse/WFCORE-487 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Affects Versions: 1.0.0.Alpha14 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > Attachments: respawn-http-threads.txt > > > We have the following error message in the traces: > 2014-12-15 19:19:53,574 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=32341&buildTyp...! -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3786) Validator interceptor does not work in 8.1 on EJBs

by John Ament (JIRA)

[ https://issues.jboss.org/browse/WFLY-3786?page=com.atlassian.jira.plugin.... ] John Ament commented on WFLY-3786: ---------------------------------- [~jason.greene] this is fixed in WildFly 8.2. Can this ticket be resolved? > Validator interceptor does not work in 8.1 on EJBs > -------------------------------------------------- > > Key: WFLY-3786 > URL: https://issues.jboss.org/browse/WFLY-3786 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: John Ament > Assignee: Jason Greene > > Take a look at the following git repo > https://github.com/johnament/hornetq-jms-issue > Run the test ValidationTest. When you execute, you'll see the following error: > Caused by: org.jboss.arquillian.test.spi.ArquillianProxyException: org.jboss.weld.exceptions.IllegalArgumentException : WELD-001456: Argument bean must not be null [Proxied because : Original exception caused: class java.lang.ClassNotFoundException: org.jboss.weld.exceptions.IllegalArgumentException] > Looking at it at first, you might think it's the result of validation execution (since the bean's @notNull). What's actually happening is the interceptor is trying to get a reference to the validator and failing, hence the "argument bean must not be null" part. > It seems like the validation extension doesn't get activated properly when I'm dealing with a JAR within a WAR file. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-719) KIE Server: enable automated testing on WebSphere

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-719?page=com.atlassian.jira.plugin... ] Petr Široký updated DROOLS-719: ------------------------------- Component/s: kie server > KIE Server: enable automated testing on WebSphere > ------------------------------------------------- > > Key: DROOLS-719 > URL: https://issues.jboss.org/browse/DROOLS-719 > Project: Drools > Issue Type: Task > Components: kie server > Affects Versions: 6.2.0.CR4 > Reporter: Petr Široký > Assignee: Petr Široký > > The `kie-server-tests` module does not have Cargo config for WebSphere. Cargo supports this container, so we should add the `was8x` profile to enable easy testing of the KIE Server also on WebSphere. > I have an working PoC of this, so it should not be hard to port this into the sources. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-720) KIE Server: enable automated testing on WebLogic 12

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-720?page=com.atlassian.jira.plugin... ] Petr Široký updated DROOLS-720: ------------------------------- Component/s: kie server > KIE Server: enable automated testing on WebLogic 12 > --------------------------------------------------- > > Key: DROOLS-720 > URL: https://issues.jboss.org/browse/DROOLS-720 > Project: Drools > Issue Type: Task > Components: kie server > Affects Versions: 6.2.0.CR4 > Reporter: Petr Široký > Assignee: Petr Široký > > The `kie-server-tests` module does not have Cargo config for WebLogic. Cargo supports this container, so we should add the `wlc12x` profile to enable easy testing of the KIE Server also on WebLogic. > http://cargo.codehaus.org/WebLogic+12.x -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4377) Add support for Infinispan partition handling

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-4377: ---------------------------------- Summary: Add support for Infinispan partition handling Key: WFLY-4377 URL: https://issues.jboss.org/browse/WFLY-4377 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 9.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro Only applies to DIST mode. Add management operations to get and set the AvailabilityMode of a cache. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-725) ClassCastException on malformed accumulate

by Davide Angelocola (JIRA)

Davide Angelocola created DROOLS-725: ---------------------------------------- Summary: ClassCastException on malformed accumulate Key: DROOLS-725 URL: https://issues.jboss.org/browse/DROOLS-725 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.2.0.CR4, 6.1.0.Final Environment: java version "1.7.0_60" Java(TM) SE Runtime Environment (build 1.7.0_60-b19) Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode) Reporter: Davide Angelocola Assignee: Mario Fusco Priority: Minor Given a rule like: rule "test case" when Number() from accumulate( not Number(), init( double total = 0; ), action( ), reverse( ), result( new Double( total ) ) ) then // no op end the following exception is thrown: java.lang.ClassCastException: org.drools.compiler.lang.descr.NotDescr cannot be cast to org.drools.compiler.lang.descr.PatternDescr at org.drools.compiler.lang.descr.AccumulateDescr.getInputPattern(AccumulateDescr.java:194) at org.drools.compiler.rule.builder.util.PackageBuilderUtil.isReadLocalsFromTuple(PackageBuilderUtil.java:21) at org.drools.compiler.rule.builder.dialect.java.JavaAccumulateBuilder.build(JavaAccumulateBuilder.java:93) at org.drools.compiler.rule.builder.dialect.java.JavaAccumulateBuilder.build(JavaAccumulateBuilder.java:66) at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:320) at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:138) at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66) at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:89) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1652) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:968) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:844) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:279) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:103) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:91) at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:220) at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:43) at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:208) at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:177) at regressions.DroolsCompilerBugTest.bug(DroolsCompilerBugTest.java:26) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2015