[JBoss JIRA] (ELY-221) Implement a better X.500 principal mapper
by David Lloyd (JIRA)
David Lloyd created ELY-221:
-------------------------------
Summary: Implement a better X.500 principal mapper
Key: ELY-221
URL: https://issues.jboss.org/browse/ELY-221
Project: WildFly Elytron
Issue Type: Feature Request
Reporter: David Lloyd
We can provide something better than a flat string mapping. Some thoughts on requirements:
* Require that a minimum set of keys are present, else return {{null}}
* Allow piecewise assembly of principal names with the following components:
** Static string
** Single attribute value e.g. {{dc[0]}}
** Joined attribute value (with optional subrange) e.g. {{dc:"."}} would convert {{dc=example,dc=com}} to {{example.com}}
** Joined attribute value in reverse (with optional subrange)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4827) Network Connection leak on client abort connection
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4827?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4827:
--------------------------------------
Can you try building the latest version of the undertow 1.1.x branch?
to build:
{code}
git clone git@github.com:undertow-io/undertow.git
cd undertow
mvn install
{code}
> Network Connection leak on client abort connection
> --------------------------------------------------
>
> Key: WFLY-4827
> URL: https://issues.jboss.org/browse/WFLY-4827
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Sockets
> Affects Versions: 8.2.0.Final
> Environment: On Windows Server 2012, JDK 1.8.0_45, Wildfly 8.2.0.Final in standalone mode.
> Reporter: Andrea Bertolini
> Assignee: Stuart Douglas
>
> We have a classic client-server application, all written in Java. Each client is installed on a forklift which can move all around a large area. This area is under wi-fi coverage.
> Sometimes the clients can have a bad connection quality and the client-server communication is interrupted; in such a case it takes too many seconds to be restored.
> To fix this situation, we add a timeout client-side. After 5 seconds it aborts the call and tries again a second time.
> To achieve this call we use apache httpcomponents library (version 4.4). We use the abort method of httppost to interrupt this call.
> Server-side, we have a group of web-servlets which listen to the incoming calls, manage requests and send a response.
> It appears that sometimes a communication remains stuck in reading or writing from/to the stream. When the client aborts the communication, an exception is thrown on the server caused by the channel being closed.
> It happens that a large number of connections remains stuck in connection status 'established' (only server-side) even if the real connection is actually closed (client doesn't have that connection active anymore).
> When the number of established connections grows up to 200, server stops responding on port 8080, so it cannot accept more connections and it seems to freeze.
> We tried to add tcp-keep-alive=true and no-request-timeout=120000 on http-listener in undertow subsystem, but sometimes it removes idle connections after any incoming requests are received for 2 minutes, some other times it keep connections as established and doesn't close them.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (ELY-220) Add a RegExSplittingNameRewriter
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-220?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse resolved ELY-220.
----------------------------------
Resolution: Rejected
Thanks, that last example does the trick ;-)
> Add a RegExSplittingNameRewriter
> ---------------------------------
>
> Key: ELY-220
> URL: https://issues.jboss.org/browse/ELY-220
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Utils
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha2
>
>
> The existing implementations allow for replacing a portion of a name based on a regular expression or validating a name based on a regular expression - however we do not have a form that allows you to easily extract a portion of a name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4766) Filter matching static resource confuses servlet matching logic
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4766?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4766.
----------------------------------
Fix Version/s: 9.0.0.Final
10.0.0.Beta1
Resolution: Done
> Filter matching static resource confuses servlet matching logic
> ---------------------------------------------------------------
>
> Key: WFLY-4766
> URL: https://issues.jboss.org/browse/WFLY-4766
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.CR2, 10.0.0.Alpha2
> Reporter: Peter Major
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Final, 10.0.0.Beta1
>
> Attachments: hello.war
>
>
> Imagine the following setup:
> * There are static files stored under the servlet context in the helloworld folder
> * there is a servlet mapped to /hello/*
> * there is a filter configured to match /helloworld/index.html
> For some reason with this set up the end result is that when I request /helloworld or /helloworld/index.html then the servlet is displayed instead of my static files (note that welcome-file-list was configured for index.html). As /hello/* *really* shouldn't match /helloworld I can only think that this is a bug in wildfly, possibly somewhere in undertow.
> Oddly enough, once the filter mapping is removed, suddenly the static file is served correctly, so the filter must have some role in this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (ELY-220) Add a RegExSplittingNameRewriter
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-220?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-220:
---------------------------------
However this case is better solved by a better PrincipalDecoder that handles structure less naively than simply flattening the X.500 principal to a string. Maybe something that allows you to select components out of the principal, and perhaps require certain components in order to successfully decode.
> Add a RegExSplittingNameRewriter
> ---------------------------------
>
> Key: ELY-220
> URL: https://issues.jboss.org/browse/ELY-220
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Utils
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha2
>
>
> The existing implementations allow for replacing a portion of a name based on a regular expression or validating a name based on a regular expression - however we do not have a form that allows you to easily extract a portion of a name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (ELY-220) Add a RegExSplittingNameRewriter
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-220?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-220:
---------------------------------
Ah yes, my mistake:
{code}
NameRewriter transformingRewriter = new RegexNameRewriter(Pattern.compile("^.*?\\bdc=([^,]++).*$"), "$1", false);
{code}
> Add a RegExSplittingNameRewriter
> ---------------------------------
>
> Key: ELY-220
> URL: https://issues.jboss.org/browse/ELY-220
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Utils
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha2
>
>
> The existing implementations allow for replacing a portion of a name based on a regular expression or validating a name based on a regular expression - however we do not have a form that allows you to easily extract a portion of a name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (ELY-220) Add a RegExSplittingNameRewriter
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-220?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-220:
--------------------------------------
If I do that I get "cn=John Doe,dc=example,dc=com" converted to "cn=John Doe,example,dc=com"
> Add a RegExSplittingNameRewriter
> ---------------------------------
>
> Key: ELY-220
> URL: https://issues.jboss.org/browse/ELY-220
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Utils
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Alpha2
>
>
> The existing implementations allow for replacing a portion of a name based on a regular expression or validating a name based on a regular expression - however we do not have a form that allows you to easily extract a portion of a name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (AS7-3736) javax.el.BeanELResolver.properties keeps references to undeployed classes (Class Loader leak)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-3736?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-3736:
----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1207583|https://bugzilla.redhat.com/show_bug.cgi?id=1207583] from ASSIGNED to CLOSED
> javax.el.BeanELResolver.properties keeps references to undeployed classes (Class Loader leak)
> ---------------------------------------------------------------------------------------------
>
> Key: AS7-3736
> URL: https://issues.jboss.org/browse/AS7-3736
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: 7.1.0.CR1b
> Environment: Seam 2.2.2 application
> Reporter: Philippe Guinot
> Assignee: Stuart Douglas
> Labels: BeanELResolver, classloader, leak,, memory
> Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> This is another Class Loader leak memory issue. When class are loaded into the properties map, they don't get unloaded at undeploy. This cause the whole application's class loader not being garbage collected and so will result in OutOfMemoryError: PermGen space after a few deployments.
> The solution would be to call the purgeBeanClasses method at undeploy with each of the class loader of all sub-modules of the application.
> For the moment, the work around I've done was to change
> {code}private static final ConcurrentHashMap<Class, BeanProperties> properties =
> new ConcurrentHashMap<Class, BeanProperties>(CACHE_SIZE);
> {code}to{code}
> private static final Map<Class<?>, SoftReference<BeanProperties>> properties =
> Collections.synchronizedMap(new WeakHashMap<Class<?>, SoftReference<BeanProperties>>(CACHE_SIZE));
> {code}
> But I'm not really sure if that's a good idea to replace the ConcurrentHashMap with a SynchronizedMap and I had to change
> {code}properties.putIfAbsent(baseClass, bps);{code}
> By{code}
> synchronized(properties) {
> if (!properties.containsKey(baseClass))
> properties.put(baseClass, new SoftReference<BeanProperties>(bps));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4839) annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4839?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4839:
-----------------------------------------------
Tomas Hofman <thofman(a)redhat.com> changed the Status of [bug 1235627|https://bugzilla.redhat.com/show_bug.cgi?id=1235627] from ASSIGNED to POST
> annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4839
> URL: https://issues.jboss.org/browse/WFLY-4839
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha4
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> {noformat}
> ### Description of problem:
> Annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true.
> Note that Servlet 3.0 specification clearly states the following:
> ~~~
> 1.6.2 Processing annotations
> In Servlet 2.5, metadata-complete only affected the scanning of annotations at
> deployment time. The notion of web-fragments did not exist in servlet 2.5. However
> in servlet 3.0 metadata-complete affects scanning of all annotations and web-
> fragments at deployment time. The version of the descriptor MUST not affect which
> annotations you scan for in a web application. An implementation of a particular
> version of the specification MUST scan for all annotations supported in that
> configuration, unless metadata-complete is specified.
> ~~~
> ### How reproducible:
> Anytime
> ### Steps to Reproduce:
> 1. Create a library jar which contains a servlet filter using @WebFilter
> 2. Put the jar under WEB-INF/lib of the web application which web.xml version is 2.3 or 2.4
> 3. Start JBoss EAP 6
> 4. Access the web application and see if the servlet filter works
> ### Actual results:
> The servlet filter is not invoked
> ### Expected results:
> The servlet filter is invoked
> ### Additional info:
> It works when the version of web.xml is 2.5 or 3.0
> [reply] [−]
> Private
> Comment 1 Masafumi Miura 2015-06-25 07:18:17 EDT
> RED HAT CONFIDENTIAL
> It looks metadata-complete is always set to true when the version of web.xml is 2.3 or 2.4 at the line 96 of web/src/main/java/org/jboss/as/web/deployment/WarMetaDataProcessor.java.
> Though Servlet 2.3/2.3 specification does not have metadata-complete attribute, Servlet 3.0 specification states the following. I think it means that the metadata-complete attribute default to false if it is not specified.
> ~~~
> 8.1 Annotations and pluggability
> if the metadata-complete attribute is not specified or is set to "false", the
> deployment tool must examine the class files of the application for annotations, and
> scan for web fragments.
> ~~~
> * web/src/main/java/org/jboss/as/web/deployment/WarMetaDataProcessor.java
> 76 public class WarMetaDataProcessor implements DeploymentUnitProcessor {
> 77
> 78 @Override
> 79 public void deploy(DeploymentPhaseContext phaseContext) throws DeploymentUnitProcessingException {
> ...
> 87 boolean isComplete = false;
> 88 WebMetaData specMetaData = warMetaData.getWebMetaData();
> 89 if (specMetaData != null) {
> 90 if (specMetaData instanceof Web25MetaData) {
> 91 isComplete |= ((Web25MetaData) specMetaData).isMetadataComplete();
> 92 } else if (specMetaData instanceof Web30MetaData) {
> 93 isComplete |= ((Web30MetaData) specMetaData).isMetadataComplete();
> 94 } else {
> 95 // Any web.xml 2.4 or earlier deployment is metadata complete
> 96 isComplete = true;
> 97 }
> 98 }
> 99
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years