[JBoss JIRA] (WFLY-2593) Memory leak in JBoss AS / Hibernate JPA integration
by Michael Kozak (JIRA)
[ https://issues.jboss.org/browse/WFLY-2593?page=com.atlassian.jira.plugin.... ]
Michael Kozak updated WFLY-2593:
--------------------------------
Description:
The leak exists in AS integration code with Hibernate JPA.
When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.
was:
The leak exists in AS integration code with Hibernate JPA.
When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
Workaround Description: Disable statistics in the persistence unit. (was: Disable statistics globally or for query cache in the persistence unit.)
> Memory leak in JBoss AS / Hibernate JPA integration
> ---------------------------------------------------
>
> Key: WFLY-2593
> URL: https://issues.jboss.org/browse/WFLY-2593
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Affects Versions: No Release
> Environment: JBoss 7.1.1
> JBoss EAP 6.2 beta
> Reporter: Michael Kozak
> Assignee: Scott Marlow
> Priority: Critical
> Fix For: No Release
>
> Attachments: jmxp.ear.ear, jmxp.tar.gz
>
>
> The leak exists in AS integration code with Hibernate JPA.
> When a persistence unit is deployed which has 2nd level cache and statistics enabled each query for "query-cache" elements produces new elements.
> The issue lies in org.jboss.as.jpa.hibernate4.management.HibernateStatisticsResource. getQueryNames() method requests query names from Hibernate and applies QueryName.queryName(query).getDisplayName() to change names. Then for all queries hasQuery() is called which invokes stats.getQueryStatistics(). Within this method Hibernate creates a new object to track the statistics because the name is not found.
> Possible solution is to reverse the work done by getDisplayName() but I'm not sure if it's the right thing to do.
> This issue arised when we deployed jmxproxy application which was queried from Zabbix installation. For some MBean queries the implementation visits all MBeans deployed on the server. This kills the JVM after about 7 days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2594) Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-2594?page=com.atlassian.jira.plugin.... ]
Stan Silvert reassigned WFLY-2594:
----------------------------------
Assignee: Farah Juma (was: Stan Silvert)
Farah, can you look at this?
> Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-2594
> URL: https://issues.jboss.org/browse/WFLY-2594
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JSF
> Environment: WildFly Beta2-SNAPSHOT from 2013-12-02
> Reporter: Tomas Remes
> Assignee: Farah Juma
>
> When you deploy more than one JSF application and then you undeploy one of them, you'll face following message in server log:
> {noformat}
> SEVERE [javax.faces] (MSC service thread 1-2) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
> SEVERE [javax.faces] (MSC service thread 1-2) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?
> {noformat}
> I think javax.faces.FactoryFinder.FactoryManagerCache.getApplicationFactoryManager(ClassLoader) shouldn't try to create new instance of FactoryManager in this case. I am not really sure, what is special initialization case, but it seems to me that this should evaluate to true in this case (btw Does this javax.faces.FactoryFinder.FactoryManagerCache.detectSpecialInitializationCase(FacesContext) ever evaluate as true?).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JGRP-1742) BARRIER: minimize closing time
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1742?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1742:
--------------------------------
Not really: in {{NAKACK2.removeAndPassUp()}}, we take the highest seqno of the message batch *after it's been pushed up and returned* and set the highest application digest seqno to it.
> BARRIER: minimize closing time
> ------------------------------
>
> Key: JGRP-1742
> URL: https://issues.jboss.org/browse/JGRP-1742
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> During a state transfer, BARRIER.up() waits until all incoming threads (delivering messages to the application) are done, and blocks further incoming messages. This is done to get the digest and the state.
> However, duing the block, the following messages are not sent up:
> * Views !
> * STABLE messages, triggering retransmissions
> This is bad, so we should try to minimize the time BARRIER is closed. This can be done with JGRP-1352.
> However, we could also do the following:
> * A state request is received
> * Close BARRIER and flush all pending threads. This ensures that any message which updated the *digest* also updated the *application state*
> * Get the digest D
> * *Open* BARRIER. Messages will now be delivered and thus applied to the state
> * Get the application state S
> * When done, return D and S to the state requester
> The difference to JGRP-1352 is that we don't queue messages during state transfer. How does this work ? It is critical to ensure that all mesages which updated the digest D also updated the state S, or else messages present in D but not in S would not be retransmitted. However, if there are more messages in S than in D, this is not an issue as they will be retransmitted again.
> Example:
> * BARRIER is closed and pending threads are flushed
> * Digest D is (only for a given member P) 5, state S is 5 as well
> * Now we open BARRIER
> * P sends a few more messages (6, 7 and 8)
> * The digest is now 8, but the copy we have is still 5
> * State S is 8
> * We return D=5 and S=8
> * The state requester closes BARRIER and sets its digest to 5 and its state to 8
> * Since the digest is only 5 for P, the state requester asks P for retransmission of messages 6, 7 and 8
> * Messages 6, 7 and 8 from P are received and applied to the state
> * The assumption here is that if messages 6, 7 and 8 are applied twice, the state doesn't change (idempotency). This should be the case with Infinispan.
> The advantage of this issue over JGRP-1352 is that we don't need to queue messages for a long time if the state is large.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2594) Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps
by Tomas Remes (JIRA)
Tomas Remes created WFLY-2594:
---------------------------------
Summary: Undeploy of JSF application is throwing SEVERE messages, when there were deployed more JSF apps
Key: WFLY-2594
URL: https://issues.jboss.org/browse/WFLY-2594
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: JSF
Environment: WildFly Beta2-SNAPSHOT from 2013-12-02
Reporter: Tomas Remes
Assignee: Stan Silvert
When you deploy more than one JSF application and then you undeploy one of them, you'll face following message in server log:
{noformat}
SEVERE [javax.faces] (MSC service thread 1-2) Unable to obtain InjectionProvider from init time FacesContext. Does this container implement the Mojarra Injection SPI?
SEVERE [javax.faces] (MSC service thread 1-2) Unable to call @PreDestroy annotated methods because no InjectionProvider can be found. Does this container implement the Mojarra Injection SPI?
{noformat}
I think javax.faces.FactoryFinder.FactoryManagerCache.getApplicationFactoryManager(ClassLoader) shouldn't try to create new instance of FactoryManager in this case. I am not really sure, what is special initialization case, but it seems to me that this should evaluate to true in this case (btw Does this javax.faces.FactoryFinder.FactoryManagerCache.detectSpecialInitializationCase(FacesContext) ever evaluate as true?).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2533) Add ability to set default character encoding on a subsystem level
by Norbert Kozłowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-2533?page=com.atlassian.jira.plugin.... ]
Norbert Kozłowski commented on WFLY-2533:
-----------------------------------------
{code:title=jboss-web.xml}
<jboss-web version="8.0" xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd" >
<security-domain>java:jboss/jaas/business_alerts</security-domain>
<default-encoding>UTF-8</default-encoding>
</jboss-web>
{code}
Stack trace
{code}
15:54:38,366 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "business_alerts.war" (runtime-name: "business_alerts.war")
15:54:38,865 INFO [org.jboss.as.jpa] (MSC service thread 1-3) JBAS011401: Read persistence.xml for MySQL
15:54:38,955 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 90) JBAS011409: Starting Persistence Unit (phase 1 of 2) Service 'business_alerts.war#MySQL'
15:54:38,955 INFO [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 90) HHH000204: Processing PersistenceUnitInfo [
name: MySQL
...]
15:54:38,997 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016002: Processing weld deployment business_alerts.war
15:54:39,003 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named AuthService in deployment unit deployment "business_alerts.war" are as follows:
[...]
15:54:39,096 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016005: Starting Services for CDI deployment: business_alerts.war
15:54:39,100 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-7) JBWS024061: Adding service endpoint metadata: id=com.intenso.carlos.crawler.web.wsserver.CarlaWSItfImpl
address=http://localhost:8080/business_alerts/CarlosWebService
implementor=com.intenso.carlos.crawler.web.wsserver.CarlaWSItfImpl
serviceName={http://carlos.intenso.com.pl}CarlosWebService
portName={http://carlos.intenso.com.pl}CarlosWebServicePort
annotationWsdlLocation=classpath:wsdl/CarlosCrawlerService.wsdl
wsdlLocationOverride=null
mtomEnabled=false
15:54:39,153 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-7) Creating Service {http://carlos.intenso.com.pl}CarlosWebService from WSDL: classpath:wsdl/CarlosCrawlerService.wsdl
15:54:39,219 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-7) Setting the server's publish address to be http://localhost:8080/business_alerts/CarlosWebService
15:54:39,227 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/home/nkozlowski/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/data/wsdl/business_alerts.war/CarlosWebService.wsdl
15:54:39,231 INFO [org.jboss.as.webservices] (MSC service thread 1-6) JBAS015539: Starting service jboss.ws.endpoint."business_alerts.war"."com.intenso.carlos.crawler.web.wsserver.CarlaWSItfImpl"
15:54:39,234 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016008: Starting weld service for deployment business_alerts.war
15:54:39,242 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 90) JBAS011409: Starting Persistence Unit (phase 2 of 2) Service 'business_alerts.war#MySQL'
15:54:39,248 INFO [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 90) HHH000400: Using dialect: org.hibernate.dialect.MySQLDialect
15:54:39,268 INFO [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] (ServerService Thread Pool -- 90) HHH000397: Using ASTQueryTranslatorFactory
15:54:39,346 INFO [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 90) HHH000400: Using dialect: org.hibernate.dialect.MySQLDialect
15:54:43,473 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: java.lang.NullPointerException
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:765)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
... 3 more
15:54:43,479 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-11) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "business_alerts.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService: Failed to start service
Caused by: java.lang.NullPointerException"}}
15:54:43,480 ERROR [org.jboss.as.server] (XNIO-1 task-11) JBAS015870: Deploy of deployment "business_alerts.war" was rolled back with the following failure message:
{"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService: Failed to start service
Caused by: java.lang.NullPointerException"}}
15:54:43,483 INFO [org.jboss.as.webservices] (MSC service thread 1-5) JBAS015540: Stopping service jboss.ws.endpoint."business_alerts.war"."com.intenso.carlos.crawler.web.wsserver.CarlaWSItfImpl"
[...]
JBAS014777: Services which failed to start: service jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService
{code}
Without encoding attribute it works fine.
> Add ability to set default character encoding on a subsystem level
> ------------------------------------------------------------------
>
> Key: WFLY-2533
> URL: https://issues.jboss.org/browse/WFLY-2533
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> Stuart: the charset one should be pretty simple, just an attribute on <servlet-container?
> Stuart: ideally we would also have it in jboss-web.xml as well
> Stuart: I should also add an option to use the connector encoding
> Stuart: as connectors have their own encoding set
> Stuart: that is used to decode the URL
> Stuart: we should have an option to use the connector encoding as the default encoding
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2533) Add ability to set default character encoding on a subsystem level
by Norbert Kozłowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-2533?page=com.atlassian.jira.plugin.... ]
Norbert Kozłowski edited comment on WFLY-2533 at 12/2/13 9:54 AM:
------------------------------------------------------------------
It produces such error:
{code}
{"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService: Failed to start service
Caused by: java.lang.NullPointerException"}}
{code}
was (Author: khozzy):
It produces such error:
{code:title= jboss-web.xml}
{"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService: Failed to start service
Caused by: java.lang.NullPointerException"}}
{code}
> Add ability to set default character encoding on a subsystem level
> ------------------------------------------------------------------
>
> Key: WFLY-2533
> URL: https://issues.jboss.org/browse/WFLY-2533
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> Stuart: the charset one should be pretty simple, just an attribute on <servlet-container?
> Stuart: ideally we would also have it in jboss-web.xml as well
> Stuart: I should also add an option to use the connector encoding
> Stuart: as connectors have their own encoding set
> Stuart: that is used to decode the URL
> Stuart: we should have an option to use the connector encoding as the default encoding
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-409) JPA should allow for a bean validator factory per persistence unit or per application deployment
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-409?page=com.atlassian.jira.plugin.s... ]
Scott Marlow commented on WFLY-409:
-----------------------------------
This issue was tied to the way we used to create the bean validator (at the persistence unit level). We are now deferring to org.jboss.as.ee.beanvalidation.BeanValidationFactoryDeployer which can create multiple org.jboss.as.ee.beanvalidation.LazyValidatorFactory instances for a single deployment (e.g. one per contained war).
> JPA should allow for a bean validator factory per persistence unit or per application deployment
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-409
> URL: https://issues.jboss.org/browse/WFLY-409
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Labels: open_to_community
> Fix For: 8.0.0.Beta1
>
>
> Currently, a new bean validator factory instance is associated with each deployed persistence unit. This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).
> This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPARe...]).
> The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.
> Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2533) Add ability to set default character encoding on a subsystem level
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2533?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2533:
-----------------------------------
Do you have full stacktrace?
> Add ability to set default character encoding on a subsystem level
> ------------------------------------------------------------------
>
> Key: WFLY-2533
> URL: https://issues.jboss.org/browse/WFLY-2533
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> Stuart: the charset one should be pretty simple, just an attribute on <servlet-container?
> Stuart: ideally we would also have it in jboss-web.xml as well
> Stuart: I should also add an option to use the connector encoding
> Stuart: as connectors have their own encoding set
> Stuart: that is used to decode the URL
> Stuart: we should have an option to use the connector encoding as the default encoding
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2533) Add ability to set default character encoding on a subsystem level
by Norbert Kozłowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-2533?page=com.atlassian.jira.plugin.... ]
Norbert Kozłowski commented on WFLY-2533:
-----------------------------------------
It produces such error:
{code:title= jboss-web.xml}
{"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./business_alerts.UndertowDeploymentInfoService: Failed to start service
Caused by: java.lang.NullPointerException"}}
{code}
> Add ability to set default character encoding on a subsystem level
> ------------------------------------------------------------------
>
> Key: WFLY-2533
> URL: https://issues.jboss.org/browse/WFLY-2533
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> Stuart: the charset one should be pretty simple, just an attribute on <servlet-container?
> Stuart: ideally we would also have it in jboss-web.xml as well
> Stuart: I should also add an option to use the connector encoding
> Stuart: as connectors have their own encoding set
> Stuart: that is used to decode the URL
> Stuart: we should have an option to use the connector encoding as the default encoding
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months