[JBoss JIRA] Created: (AS7-782) Hudson/Jenkins won't work in AS7b3
by Fred Bricon (JIRA)
Hudson/Jenkins won't work in AS7b3
----------------------------------
Key: AS7-782
URL: https://issues.jboss.org/browse/AS7-782
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.0.0.Beta3
Environment: Fedora 14, JDK 1.6.0_24, JBoss AS7 beta 3
Reporter: Fred Bricon
Assignee: Jason Greene
After patching AS7b3 with the latest jboss-vfs from github/master and
deploying hudson ( http://search.maven.org/remotecontent?filepath=org/jvnet/hudson/main/huds...) or jenkins on AS7, an exception is thrown when accessing the homepage (or any page) :
{noformat}
17:39:33,429 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/hudson-war-2.0.0].[Stapler]] (http-localhost.localdomain-127.0.0.1-8080-2) "Servlet.service()" pour la servlet Stapler a généré une exception: java.net.MalformedURLException: unknown protocol: jndi
at java.net.URL.<init>(URL.java:574) [:1.6.0_24]
at java.net.URL.<init>(URL.java:464) [:1.6.0_24]
at java.net.URL.<init>(URL.java:413) [:1.6.0_24]
at org.kohsuke.stapler.Stapler.selectResourceByLocale(Stapler.java:227) [stapler-1.155.jar:]
at org.kohsuke.stapler.Stapler.openResourcePathByLocale(Stapler.java:203) [stapler-1.155.jar:]
at org.kohsuke.stapler.Stapler.service(Stapler.java:145) [stapler-1.155.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94) [hudson-core-2.0.0.jar:]
at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86) [hudson-core-2.0.0.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) [hudson-core-2.0.0.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:162) [hudson-core-2.0.0.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) [hudson-core-2.0.0.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:388) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:658) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
{noformat}
I first mentioned this issur on irc (see http://echelog.matzon.dk/logs/browse/jboss-as7/1305151200 [13:42:43] -> [13:48:58])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
3 days
[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender
by Bela Ban (JIRA)
Optimization: make threads return immediately if NAKACK has another active thread for the same sender
-----------------------------------------------------------------------------------------------------
Key: JGRP-457
URL: http://jira.jboss.com/jira/browse/JGRP-457
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Minor
Fix For: 2.5
In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up.
If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock.
The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3 months
[JBoss JIRA] (DROOLS-702) Rule Inheritance fired the sub rule even the condition doen't match
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-702?page=com.atlassian.jira.plugin... ]
Davide Sottara edited comment on DROOLS-702 at 1/31/15 9:54 AM:
----------------------------------------------------------------
When a rule extends another, patterns will not be merged.
If you have:
{code} rule "parent" when $p : Person() then end {code}
and
{code} rule "child" when Person() then end {code}
the engine cannot safely infer that those two patterns should match the
SAME fact, so you end up with a cross-product of two patterns.
In your reproducer, the number of firings is consistent with the cross
product of the facts you inserted, so I don't see any bug here.
As an alternative to "from", you can use unification:
{code} $p := Person() {code}
in both rules (parent and child) to ensure the two patterns are linked.
[Edit: clarification: "from" ensures the pattern applied to the same object,
while ":=" is still affected by equality]
was (Author: dsotty):
When a rule extends another, patterns will not be merged.
If you have:
{code} rule "parent" when $p : Person() then end {code}
and
{code} rule "child" when Person() then end {code}
the engine cannot safely infer that those two patterns should match the
SAME fact, so you end up with a cross-product of two patterns.
In your reproducer, the number of firings is consistent with the cross
product of the facts you inserted, so I don't see any bug here.
As an alternative to "from", you can use unification:
{code} $p := Person() {code}
in both rules (parent and child) to ensure the two patterns are linked.
> Rule Inheritance fired the sub rule even the condition doen't match
> -------------------------------------------------------------------
>
> Key: DROOLS-702
> URL: https://issues.jboss.org/browse/DROOLS-702
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Environment: Windows, Java6.0.29
> Reporter: Yacine Jaber
> Assignee: Davide Sottara
> Priority: Critical
> Attachments: wod-drools-test.7z
>
>
> You can find the attached a simple maven project that shows this error.
> You can run ExampleDrools class as main java application.
> The sub rules are fired even if the condition is not matched.
> There are a work arround by using <from $fact> into a sub rule to avoid firing this one.
> This simple project shows the failed and work arround test.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (ELY-139) Appending into ByteStringBuilder fail if initial array blank
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-139:
---------------------------
Description:
-ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it.-
-(Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)-
Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101
*UPDATE:*
ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F.
Problem is only in appending into ByteStringBuilder constructed as:
{code:xml}
new ByteStringBuilder(new byte[]{});
{code}
was:
-ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it.
(Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)-
Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101
*UPDATE:*
ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F.
Problem is only in appending into ByteStringBuilder constructed as:
{code:xml}
new ByteStringBuilder(new byte[]{});
{code}
> Appending into ByteStringBuilder fail if initial array blank
> ------------------------------------------------------------
>
> Key: ELY-139
> URL: https://issues.jboss.org/browse/ELY-139
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> -ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it.-
> -(Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)-
> Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101
> *UPDATE:*
> ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F.
> Problem is only in appending into ByteStringBuilder constructed as:
> {code:xml}
> new ByteStringBuilder(new byte[]{});
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (ELY-139) Appending into ByteStringBuilder fail if initial array blank
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-139:
---------------------------
Summary: Appending into ByteStringBuilder fail if initial array blank (was: ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates)
Description:
-ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it.
(Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)-
Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101
*UPDATE:*
ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F.
Problem is only in appending into ByteStringBuilder constructed as:
{code:xml}
new ByteStringBuilder(new byte[]{});
{code}
was:
ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it.
(Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)
Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101
*UPDATE:*
ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F.
Problem is only in appending into ByteStringBuilder constructed as:
{code:xml}
new ByteStringBuilder(new byte[]{});
{code}
> Appending into ByteStringBuilder fail if initial array blank
> ------------------------------------------------------------
>
> Key: ELY-139
> URL: https://issues.jboss.org/browse/ELY-139
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> -ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it.
> (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)-
> Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101
> *UPDATE:*
> ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F.
> Problem is only in appending into ByteStringBuilder constructed as:
> {code:xml}
> new ByteStringBuilder(new byte[]{});
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
