[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
[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
[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
[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
[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
[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
[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