[JBoss JIRA] (WFCORE-1974) Inconsistency in resource description
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1974?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1974.
--------------------------------------
Resolution: Won't Fix
I'm rejecting this just to be honest. We're never going to devote resources to making this 'full stop' thing consistent so I'm not going to pretend otherwise.
Upstream patches fixing stuff like the "enables" are welcome. No need for a WFCORE JIRA; a PR is fine.
> Inconsistency in resource description
> --------------------------------------
>
> Key: WFCORE-1974
> URL: https://issues.jboss.org/browse/WFCORE-1974
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Radim Hatlapatka
> Assignee: Brian Stansberry
> Priority: Trivial
> Labels: user_experience
>
> The description format is inconsistent in relation to starting with camel case and in relation to ending with full stop. This should be ideally consistent.
> There are some inconsistencies noted with Undertow subsystem that I've noted, still the issue is general:
> # Start with uppercase/lowercase >>"description" => "*_+enables+_* x-for ... "<< {noformat}"proxy-address-forwarding" => {
> "type" => BOOLEAN,
> "description" => "enables x-forwarded-host and similar headers and set a remote ip address and hostname",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => false,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> {noformat} vs {noformat}"url-charset" => {
> "type" => STRING,
> "description" => "URL charset",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => "UTF-8",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"{noformat}
> # End with dot/no dot {noformat}"url-charset" => {
> "type" => STRING,
> "description" => "URL charset",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => "UTF-8",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"{noformat} vs {noformat}"receive-buffer" => {
> "type" => INT,
> "description" => "The receive buffer size, in bytes.",
> "expressions-allowed" => true,
> "nillable" => true,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6744) Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6744?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6744:
------------------------------------
[~ggam] True. HttpServletRequest.getSession(false) should return null if the associated session is not valid.
"If create is false and the request has no valid HttpSession, this method returns null."
Technically, a concurrent request can invalidate the session at any time, thus the request listener logic in JSF should still be reactive to ISEs.
> Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6744
> URL: https://issues.jboss.org/browse/WFLY-6744
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.CR1
> Environment: Create a cluster with two nodes using standalone-ha.xml (default configuration), create an application with <distributable/> in the web.xml and it must have around 300 requests per seconds and I'm using SSO.
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> I reproduced the bug on Wildfly master (https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/artifact/...) . The problem is intermittent, sometimes it works but others not.
> {noformat}
> 2016-06-17 11:37:32,366 ERROR [io.undertow.servlet.request] (default task-3) UT015005: Error invoking method requestDestroyed on listener class com.sun.faces.config.ConfigureListener: javax.faces.FacesException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS
> at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:136)
> at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:122)
> at com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:346)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:257)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS
> at org.wildfly.clustering.web.undertow.session.DistributableSession.validate(DistributableSession.java:56)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.getAttributeNames(DistributableSession.java:134)
> at io.undertow.servlet.spec.HttpSessionImpl.getFilteredAttributeNames(HttpSessionImpl.java:140)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttributeNames(HttpSessionImpl.java:135)
> at com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:405)
> at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:116)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7659) Undertow allows to deploy duplicated URLs on Servlets
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7659?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero updated WFLY-7659:
-----------------------------------------------
Description:
A deployment with two Servlets, each one with the same mapping: "/test2". The deployment finishes correctly. When accessing the path, just one Servlet answers, without errors.
A deployment with two Servlets, with the following paths:
* /test1
* test1
The deployment succeeds, but a 500 error is shown when trying to access any page (not just /test1). See also WFLY-7658.
Servlet Spec 3.1 says in point 12.2:
{quote}
If the effective web.xml (after merging information from fragments and annotations) contains any url-patterns that are mapped to multiple servlets then the deployment must fail.
{quote}
was:
A deployment with two Servlets, each one with the same mapping: "/test2". The deployment finishes correctly. When accessing the path, just one Servlet answers, without errors.
A deployment with two Servlets, with the following paths:
* /test1
* test1
The deployment succeeds, but a 500 error is shown when trying to access any page (not just /test1).
Servlet Spec 3.1 says in point 12.2:
{quote}
If the effective web.xml (after merging information from fragments and annotations) contains any url-patterns that are mapped to multiple servlets then the deployment must fail.
{quote}
> Undertow allows to deploy duplicated URLs on Servlets
> -----------------------------------------------------
>
> Key: WFLY-7659
> URL: https://issues.jboss.org/browse/WFLY-7659
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
> Attachments: duplicated-servlet-1.0-SNAPSHOT.war, src.zip
>
>
> A deployment with two Servlets, each one with the same mapping: "/test2". The deployment finishes correctly. When accessing the path, just one Servlet answers, without errors.
> A deployment with two Servlets, with the following paths:
> * /test1
> * test1
> The deployment succeeds, but a 500 error is shown when trying to access any page (not just /test1). See also WFLY-7658.
> Servlet Spec 3.1 says in point 12.2:
> {quote}
> If the effective web.xml (after merging information from fragments and annotations) contains any url-patterns that are mapped to multiple servlets then the deployment must fail.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7658) Undertow allows invalid URL patterns for Servlets
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7658?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero updated WFLY-7658:
-----------------------------------------------
Affects Version/s: 10.1.0.Final
> Undertow allows invalid URL patterns for Servlets
> -------------------------------------------------
>
> Key: WFLY-7658
> URL: https://issues.jboss.org/browse/WFLY-7658
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
>
> Point 12.1 says:
> {quote}
> The path used for mapping to a servlet is the request URL from the request object minus the context path and the path parameters. The URL path mapping rules below are used in order. The first successful match is used with no further matches attempted:
> {quote}
> Given this, the string used to compare match will always start with "/".
> Point 12.2 of the Servlet 3.1 spec states the following conditions for the URL patterns of a Servlet:
> {quote}
> * A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping.
> * A string beginning with a ‘*.’ prefix is used as an extension mapping.
> * The empty string ("") is a special URL pattern that exactly maps to the application's context root, i.e., requests of the form http://host:port/<context-root>/. In this case the path info is ’/’ and the servlet path and context path is empty string (““).
> * A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
> * *All other strings are used for exact matches only.*
> {quote}
> If only exact matches are allowed, then an url pattern like "users" is unmatchable and thus invalid.
> However, Undertow is treating the url the same way as if it was prefixed with "/". While the spec doesn't mandate to cancel deployment in case of invalid url pattern (at least I haven't found it), at least a warning to the user saying the deployment has unmatchable url patterns would be appreciated.
> A Servlet with this path fails to deploy on Tomcat and Glassfish/Payara. Curiously, it works on Jetty.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1366) Cannot access remote KIE maven repo - Unauthorized access 401
by Sambhaji Biradar (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1366?page=com.atlassian.jira.plugi... ]
Sambhaji Biradar commented on DROOLS-1366:
------------------------------------------
Hi,
we tried with 6.5 only. This is what we are doing.
1. we have a rule project created on work bench. There are few rules and its build and deploy on work bench. The project jar is exposed to client using a url with username and password of tomcat.
2. we have a client code running remotely. Below is the client code :
HttpURLConnection httpURLConnection;
String url = "http://10.205.77.200:8080/kie-drools-wb/maven2/com/capitalone/cerberus/fr...";
KieServices ks = KieServices.Factory.get();
KieRepository kr = ks.getRepository();
String userpassword = "tomcat:tomcat";
httpURLConnection = (HttpURLConnection)new URL(url).openConnection();
String authEnc = new Base64Encoder().encode(userpassword.getBytes());
httpURLConnection.setRequestProperty("Authorization", "Basic "+ authEnc);
InputStream is = httpURLConnection.getInputStream();
KieModule kModule = kr.addKieModule(ks.getResources().newInputStreamResource(is));
KieContainer kContainer = ks.newKieContainer(kModule.getReleaseId());
//kContainer.newStatelessKieSession();
// ks.getRepository().addKieModule(ks.getResources().newInputStreamResource(stream));
//
// KieContainer kieContainer = ks.newKieContainer(releaseId);
//
KieScanner kieScanner = ks.newKieScanner(kContainer);
kieScanner.start(5000L);
// // alternatively:
kieScanner.scanNow();
runRule(kContainer);
// Scanner scanner = new Scanner(System.in);
// while (true) {
// runRule(kieContainer);
// System.out.println("Press enter in order to run the test again....");
// scanner.nextLine();
// }
}
private static void runRule(KieContainer kieKontainer) {
try {
KieSession kSession = kieKontainer.newKieSession();
AuthorizationRequest authr = new AuthorizationRequest();
//authr.setAuthKey("test");
authr.setPosEntryMode("79"); //90 in request, valid value 80, 79
authr.setChipConditionCode("31"); //5 in request
authr.setAccountNumber("4000000000000001");
authr.setResponseCode("");
kSession.insert(authr);
//kSession.setGlobal("out", System.out);
System.out.println(kSession.fireAllRules());
System.out.println(authr.getResponseCode());
}catch(Exception e){
e.printStackTrace();
}
// System.out.println(authr.getRequestCode());
}
3. The client code is working good for url whatever we have given. But KieScanner is not doing continuous scan on repo updates. so, if I re-build the project and create next version, client does not load the latest artifects automatically.
we do see 401 error in the file client maven repo. But same works good if work bench and client code both is running on same machine.
Hope this gives enough details.
> Cannot access remote KIE maven repo - Unauthorized access 401
> -------------------------------------------------------------
>
> Key: DROOLS-1366
> URL: https://issues.jboss.org/browse/DROOLS-1366
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Reporter: Sambhaji Biradar
> Assignee: Mario Fusco
>
> Using the latest 6.5 version, we are getting unauthorized access error. From the other posts I see that this issue was resolved in earlier versions but wondering if this issue was introduced again in 6.5. I tried this solution with no success - https://issues.jboss.org/browse/DROOLS-436.
> Could someone help resolving the issue please?
>
> #NOTE: This is an Aether internal implementation file, its format can be changed without prior notice.
> #Mon Nov 21 19:20:51 EST 2016
> maven-metadata-central.xml.error=Could not transfer metadata com.xxx.xxx.ruleengine\:fraudrules\:1.1-SNAPSHOT/maven-metadata.xml from/to central (http\://repo1.maven.org/maven2/)\: Connect to repo1.maven.org\:80 timed out
> maven-metadata-guvnor-m2-repo.xml.error=Could not transfer metadata com.xxx.xxx.ruleengine\:rules\:1.1-SNAPSHOT/maven-metadata.xml from/to guvnor-m2-repo (http\://10.xxx.77.xxx\:8080/kie-drools-wb/maven2/)\: Unauthorized (401)
> maven-metadata-workbench.xml.lastUpdated=1479774051131
> maven-metadata-guvnor-m2-repo.xml/@default-guvnor-m2-repo-http\://10.xxx.77.xxx\:8080/kie-drools-wb/maven2/.lastUpdated=1479774051096
> maven-metadata-central.xml/@default-central-http\://repo1.maven.org/maven2/.lastUpdated=1479774050359
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7659) Undertow allows to deploy duplicated URLs on Servlets
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-7659:
--------------------------------------------------
Summary: Undertow allows to deploy duplicated URLs on Servlets
Key: WFLY-7659
URL: https://issues.jboss.org/browse/WFLY-7659
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Reporter: Guillermo González de Agüero
Assignee: Stuart Douglas
Attachments: duplicated-servlet-1.0-SNAPSHOT.war, src.zip
A deployment with two Servlets, each one with the same mapping: "/test2". The deployment finishes correctly. When accessing the path, just one Servlet answers, without errors.
A deployment with two Servlets, with the following paths:
* /test1
* test1
The deployment succeeds, but a 500 error is shown when trying to access any page (not just /test1).
Servlet Spec 3.1 says in point 12.2:
{quote}
If the effective web.xml (after merging information from fragments and annotations) contains any url-patterns that are mapped to multiple servlets then the deployment must fail.
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7658) Undertow allows invalid URL patterns for Servlets
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7658?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero updated WFLY-7658:
-----------------------------------------------
Summary: Undertow allows invalid URL patterns for Servlets (was: Undertow allows to invalid URL patterns for Servlets)
> Undertow allows invalid URL patterns for Servlets
> -------------------------------------------------
>
> Key: WFLY-7658
> URL: https://issues.jboss.org/browse/WFLY-7658
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
>
> Point 12.1 says:
> {quote}
> The path used for mapping to a servlet is the request URL from the request object minus the context path and the path parameters. The URL path mapping rules below are used in order. The first successful match is used with no further matches attempted:
> {quote}
> Given this, the string used to compare match will always start with "/".
> Point 12.2 of the Servlet 3.1 spec states the following conditions for the URL patterns of a Servlet:
> {quote}
> * A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping.
> * A string beginning with a ‘*.’ prefix is used as an extension mapping.
> * The empty string ("") is a special URL pattern that exactly maps to the application's context root, i.e., requests of the form http://host:port/<context-root>/. In this case the path info is ’/’ and the servlet path and context path is empty string (““).
> * A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
> * *All other strings are used for exact matches only.*
> {quote}
> If only exact matches are allowed, then an url pattern like "users" is unmatchable and thus invalid.
> However, Undertow is treating the url the same way as if it was prefixed with "/". While the spec doesn't mandate to cancel deployment in case of invalid url pattern (at least I haven't found it), at least a warning to the user saying the deployment has unmatchable url patterns would be appreciated.
> A Servlet with this path fails to deploy on Tomcat and Glassfish/Payara. Curiously, it works on Jetty.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7658) Undertow allows to invalid URL patterns for Servlets
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-7658:
--------------------------------------------------
Summary: Undertow allows to invalid URL patterns for Servlets
Key: WFLY-7658
URL: https://issues.jboss.org/browse/WFLY-7658
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Guillermo González de Agüero
Assignee: Stuart Douglas
Point 12.1 says:
{quote}
The path used for mapping to a servlet is the request URL from the request object minus the context path and the path parameters. The URL path mapping rules below are used in order. The first successful match is used with no further matches attempted:
{quote}
Given this, the string used to compare match will always start with "/".
Point 12.2 of the Servlet 3.1 spec states the following conditions for the URL patterns of a Servlet:
{quote}
* A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping.
* A string beginning with a ‘*.’ prefix is used as an extension mapping.
* The empty string ("") is a special URL pattern that exactly maps to the application's context root, i.e., requests of the form http://host:port/<context-root>/. In this case the path info is ’/’ and the servlet path and context path is empty string (““).
* A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
* *All other strings are used for exact matches only.*
{quote}
If only exact matches are allowed, then an url pattern like "users" is unmatchable and thus invalid.
However, Undertow is treating the url the same way as if it was prefixed with "/". While the spec doesn't mandate to cancel deployment in case of invalid url pattern (at least I haven't found it), at least a warning to the user saying the deployment has unmatchable url patterns would be appreciated.
A Servlet with this path fails to deploy on Tomcat and Glassfish/Payara. Curiously, it works on Jetty.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months