[JBoss JIRA] (AS7-6249) ServletContext.getResource() doesn't work correctly for files containing hash characters
by Christian Kaltepoth (JIRA)
[ https://issues.jboss.org/browse/AS7-6249?page=com.atlassian.jira.plugin.s... ]
Christian Kaltepoth updated AS7-6249:
-------------------------------------
Attachment: as7-url-bug.zip
Sample project to reproduce the issue
> ServletContext.getResource() doesn't work correctly for files containing hash characters
> ----------------------------------------------------------------------------------------
>
> Key: AS7-6249
> URL: https://issues.jboss.org/browse/AS7-6249
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Linux 3.2.0-30-generic Ubuntu SMP x86_64 GNU/Linux
> Reporter: Christian Kaltepoth
> Assignee: Remy Maucherat
> Attachments: as7-url-bug.zip
>
>
> {{ServletContext.getResource()}} returns an invalid URL if the file name contains {{#}} characters.
> Example:
> {code:java}
> URL url = servletContext.getResource("/file#1.txt");
> {code}
> The resulting URL object will be spitted at the {{#}} character like this:
> {code}
> url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
> url.getPath(): /default-host/tomcat-url-bug/file
> url.getRef(): 1.txt
> {code}
> Calling {{url.openStream()}} will throw a {{FileNotFoundException}}.
> This is a known Tomcat issue fixed in 7.0.28.
> References:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53257
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51584
> According to the discussion on the Tomcat issue tracker, there are also problems for other characters which have special meaning in URLs.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-6249) ServletContext.getResource() doesn't work correctly for files containing hash characters
by Christian Kaltepoth (JIRA)
[ https://issues.jboss.org/browse/AS7-6249?page=com.atlassian.jira.plugin.s... ]
Christian Kaltepoth updated AS7-6249:
-------------------------------------
Steps to Reproduce:
Deploy the attached sample project to JBoss AS 7.1.3.Final. A ServletContextListener will try to load a problematic file and print the results to the console. The console will show something like this:
{code}
15:34:00,036 INFO [stdout] (MSC service thread 1-2) =============================================================
15:34:00,039 INFO [stdout] (MSC service thread 1-2) url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getPath(): /default-host/tomcat-url-bug/file
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getRef(): 1.txt
15:34:00,041 INFO [stdout] (MSC service thread 1-2) url.openStream(): java.io.FileNotFoundException
15:34:00,042 INFO [stdout] (MSC service thread 1-2) =============================================================
{code}
Expected output:
{code}
15:34:10,382 INFO [stdout] (MSC service thread 1-1) =============================================================
15:34:10,383 INFO [stdout] (MSC service thread 1-1) url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
15:34:10,383 INFO [stdout] (MSC service thread 1-1) url.getPath(): /default-host/tomcat-url-bug/file1.txt
15:34:10,384 INFO [stdout] (MSC service thread 1-1) url.getRef(): null
15:34:10,384 INFO [stdout] (MSC service thread 1-1) url.openStream(): SUCCESS
15:34:10,385 INFO [stdout] (MSC service thread 1-1) =============================================================
{code}
was:
Deploy the attached sample project to JBoss AS 7.1.3.Final. A ServletContextListener will try to load a problematic file and print the results to the console. The console will show something like this:
{code}
15:34:00,036 INFO [stdout] (MSC service thread 1-2) =============================================================
15:34:00,039 INFO [stdout] (MSC service thread 1-2) url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getPath(): /default-host/tomcat-url-bug/file
15:34:00,040 INFO [stdout] (MSC service thread 1-2) url.getRef(): 1.txt
15:34:00,041 INFO [stdout] (MSC service thread 1-2) url.openStream(): java.io.FileNotFoundException
15:34:00,042 INFO [stdout] (MSC service thread 1-2) =============================================================
{code}
> ServletContext.getResource() doesn't work correctly for files containing hash characters
> ----------------------------------------------------------------------------------------
>
> Key: AS7-6249
> URL: https://issues.jboss.org/browse/AS7-6249
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Environment: Linux 3.2.0-30-generic Ubuntu SMP x86_64 GNU/Linux
> Reporter: Christian Kaltepoth
> Assignee: Remy Maucherat
> Attachments: as7-url-bug.zip
>
>
> {{ServletContext.getResource()}} returns an invalid URL if the file name contains {{#}} characters.
> Example:
> {code:java}
> URL url = servletContext.getResource("/file#1.txt");
> {code}
> The resulting URL object will be spitted at the {{#}} character like this:
> {code}
> url.toString(): jndi:/default-host/tomcat-url-bug/file#1.txt
> url.getPath(): /default-host/tomcat-url-bug/file
> url.getRef(): 1.txt
> {code}
> Calling {{url.openStream()}} will throw a {{FileNotFoundException}}.
> This is a known Tomcat issue fixed in 7.0.28.
> References:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53257
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51584
> According to the discussion on the Tomcat issue tracker, there are also problems for other characters which have special meaning in URLs.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-6246) Naming context read-only during legacy SAR deployment
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-6246?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins updated AS7-6246:
---------------------------------
Component/s: Naming
> Naming context read-only during legacy SAR deployment
> -----------------------------------------------------
>
> Key: AS7-6246
> URL: https://issues.jboss.org/browse/AS7-6246
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX, Naming
> Affects Versions: 7.2.0.Alpha1
> Reporter: Philippe Marschall
> Assignee: Eduardo Martins
> Labels: jmx, jndi, naming, sar
>
> When the {{#startService()}} and {{#stopService()}} methods of a sublass of {{ServiceMBeanSupport}} are invoked the JNDI context is read only.
> Consider the following MBean:
> {code}
> public class LegacySample extends ServiceMBeanSupport implements LegacySampleMBean {
> private static final String NAME = "java:global/env/foo/legacy";
> private static final String VALUE = "BAR";
> private static final Logger LOG = Logger.getLogger("sar-legacy");
> public LegacySample() {
> super();
> }
> @Override
> protected void startService() throws Exception {
> InitialContext ic = new InitialContext();
> ic.rebind(NAME, VALUE);
> LOG.info("started");
> }
> @Override
> protected void stopService() throws Exception {
> InitialContext ic = new InitialContext();
> ic.unbind(NAME);
> LOG.info("stopped");
> }
> @Override
> public String getMessage() {
> return "legacy";
> }
> }
> {code}
> This will fail.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5781) Filesystem deployment scanner for a managed domain
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5781?page=com.atlassian.jira.plugin.s... ]
SBS JIRA Integration updated AS7-5781:
--------------------------------------
Forum Reference: https://community.jboss.org/message/783928#783928
> Filesystem deployment scanner for a managed domain
> --------------------------------------------------
>
> Key: AS7-5781
> URL: https://issues.jboss.org/browse/AS7-5781
> Project: Application Server 7
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 7.1.0.Final
> Environment: Ubuntu 12.04 Os , JBOSS As 7.1.0 final
> Reporter: hitesh yadav
> Original Estimate: 1 day, 4 hours
> Remaining Estimate: 1 day, 4 hours
>
> Is there any folder or path at which if any .war is put, in such a way that when JBOSS AS 7.1.0 start in domain mode the .war file deploy in Master node and it's related slave Node.
> For Example......... In standalone mode if we put .war file in /jboss-as-7.1.0.Final/standalone/deployments/ folder and start the JBOSS AS 7.1.0 in standalone mode ,the .war deploy properly.......i want same thing domain mode, in other-server-group .....
> Means the requirement is that the .war file should put in one folder and when JBOSS AS 7.1.0 start in domain mode the .war file should deploy in other-server-group .............
--
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
11 years, 7 months
[JBoss JIRA] (AS7-6248) Missing file from Nexus preventing build of Arquillian TestNG Integration
by Michael Van Geertruy (JIRA)
[ https://issues.jboss.org/browse/AS7-6248?page=com.atlassian.jira.plugin.s... ]
Michael Van Geertruy edited comment on AS7-6248 at 12/23/12 4:44 AM:
---------------------------------------------------------------------
This file is created by the spec-api module, which is built much later in the build process. The way I see it, there are two possible solutions:
1) Move the arquillian modules to after the spec-api module (destructive), or
2) Create a module specifically for arquillian-testng at a peer level to spec-api in the source-tree and move the contents of arquillian-testng to the new module. In the project's parent pom.xml, create an entry for arquillian-testng immediately after spec-api in the modules section.
The only other module that has a dependency on jboss-as-arquillian-testng-integration is test-suite which runs after spec-api. Also, all of the other Arquillian modules build fine, and there are numerous dependencies on the other arquillian modules in the build process. With this in mind, I think option 2 is probably best.
I can implement whichever solution you folks would like and submit a patch after a decision is made.
The only reason I found this was because I started the build with a blank .m2/repository. If Jenkins isn't clearing out the .m2/repository prior to the build that then this would have only shown up the first time a build was done. After that, the file produced by spec-api would be installed into the repository and the problem would have gone away.
was (Author: mikevan):
This file is created by the spec-api module, which is built much later in the build process. The way I see it, there are two possible solutions:
1) Move the arquillian modules to after the spec-api module.
2) Create a module specifically for arquillian-testng at a peer level to spec-api in the source-tree and move the contents of arquillian-testng to the new module. In the project's parent pom.xml, create an entry for arquillian-testng immediately after spec-api in the modules section.
The only other module that has a dependency on jboss-as-arquillian-testng-integration is test-suite which runs after spec-api. Also, all of the other Arquillian modules build fine, and there are numerous dependencies on the other arquillian modules in the build process. With this in mind, I think option 2 is probably best.
I can implement whichever solution you folks would like and submit a patch after a decision is made.
The only reason I found this was because I started the build with a blank .m2/repository. If Jenkins isn't clearing out the .m2/repository prior to the build that then this would have only shown up the first time a build was done. After that, the file produced by spec-api would be installed into the repository and the problem would have gone away.
> Missing file from Nexus preventing build of Arquillian TestNG Integration
> -------------------------------------------------------------------------
>
> Key: AS7-6248
> URL: https://issues.jboss.org/browse/AS7-6248
> Project: Application Server 7
> Issue Type: Bug
> Components: Build System
> Affects Versions: 7.2.0.Alpha1
> Environment: CentOS 6.3, Intel X86-64
> Reporter: Michael Van Geertruy
> Assignee: Paul Gier
> Labels: Arquillian
>
> After downloading the most recent codebase from git for jbossAS 7.2.0.SNAPSHOT, I recieved the following error:
> [INFO] ------------------------------------------------------------------------
> [INFO] Building JBoss Application Server: Arquillian TestNG Integration 7.2.0.Alpha1-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> [WARNING] The POM for org.jboss.as:jboss-as-spec-api:pom:7.2.0.Alpha1-SNAPSHOT is missing, no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] JBoss Application Server: Arquillian .............. SUCCESS [3.091s]
> [INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [7.331s]
> [INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [7.461s]
> [INFO] JBoss Application Server: Arquillian Embedded Container SUCCESS [18.654s]
> [INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [3.766s]
> [INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [19.634s]
> [INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [2.147s]
> [INFO] JBoss Application Server: Arquillian TestNG Integration FAILURE [3.535s]
> [INFO] JBoss Application Server: Arquillian Common Domain SKIPPED
> [INFO] JBoss Application Server: Arquillian Remote Domain Container SKIPPED
> [INFO] JBoss Application Server: Arquillian Managed Domain Container SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1:08.150s
> [INFO] Finished at: Sat Dec 22 23:43:21 PST 2012
> [INFO] Final Memory: 51M/317M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project jboss-as-arquillian-testng-integration: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-testng-integration:jar:7.2.0.Alpha1-SNAPSHOT
> Indeed after looking at the jboss nexus repository I came across this link:
> https://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbo...
> There do not appear to be any entries for 7.2.0.Alpha1-SNAPSHOT.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-6248) Missing file from Nexus preventing build of Arquillian TestNG Integration
by Michael Van Geertruy (JIRA)
[ https://issues.jboss.org/browse/AS7-6248?page=com.atlassian.jira.plugin.s... ]
Michael Van Geertruy commented on AS7-6248:
-------------------------------------------
This file is created by the spec-api module, which is built much later in the build process. The way I see it, there are two possible solutions:
1) Move the arquillian modules to after the spec-api module.
2) Create a module specifically for arquillian-testng at a peer level to spec-api in the source-tree and move the contents of arquillian-testng to the new module. In the project's parent pom.xml, create an entry for arquillian-testng immediately after spec-api in the modules section.
The only other module that has a dependency on jboss-as-arquillian-testng-integration is test-suite which runs after spec-api. Also, all of the other Arquillian modules build fine, and there are numerous dependencies on the other arquillian modules in the build process. With this in mind, I think option 2 is probably best.
I can implement whichever solution you folks would like and submit a patch after a decision is made.
The only reason I found this was because I started the build with a blank .m2/repository. If Jenkins isn't clearing out the .m2/repository prior to the build that then this would have only shown up the first time a build was done. After that, the file produced by spec-api would be installed into the repository and the problem would have gone away.
> Missing file from Nexus preventing build of Arquillian TestNG Integration
> -------------------------------------------------------------------------
>
> Key: AS7-6248
> URL: https://issues.jboss.org/browse/AS7-6248
> Project: Application Server 7
> Issue Type: Bug
> Components: Build System
> Affects Versions: 7.2.0.Alpha1
> Environment: CentOS 6.3, Intel X86-64
> Reporter: Michael Van Geertruy
> Assignee: Paul Gier
> Labels: Arquillian
>
> After downloading the most recent codebase from git for jbossAS 7.2.0.SNAPSHOT, I recieved the following error:
> [INFO] ------------------------------------------------------------------------
> [INFO] Building JBoss Application Server: Arquillian TestNG Integration 7.2.0.Alpha1-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
> [WARNING] The POM for org.jboss.as:jboss-as-spec-api:pom:7.2.0.Alpha1-SNAPSHOT is missing, no dependency information available
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] JBoss Application Server: Arquillian .............. SUCCESS [3.091s]
> [INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [7.331s]
> [INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [7.461s]
> [INFO] JBoss Application Server: Arquillian Embedded Container SUCCESS [18.654s]
> [INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [3.766s]
> [INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [19.634s]
> [INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [2.147s]
> [INFO] JBoss Application Server: Arquillian TestNG Integration FAILURE [3.535s]
> [INFO] JBoss Application Server: Arquillian Common Domain SKIPPED
> [INFO] JBoss Application Server: Arquillian Remote Domain Container SKIPPED
> [INFO] JBoss Application Server: Arquillian Managed Domain Container SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 1:08.150s
> [INFO] Finished at: Sat Dec 22 23:43:21 PST 2012
> [INFO] Final Memory: 51M/317M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project jboss-as-arquillian-testng-integration: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-testng-integration:jar:7.2.0.Alpha1-SNAPSHOT
> Indeed after looking at the jboss nexus repository I came across this link:
> https://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbo...
> There do not appear to be any entries for 7.2.0.Alpha1-SNAPSHOT.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-6248) Missing file from Nexus preventing build of Arquillian TestNG Integration
by Michael Van Geertruy (JIRA)
Michael Van Geertruy created AS7-6248:
-----------------------------------------
Summary: Missing file from Nexus preventing build of Arquillian TestNG Integration
Key: AS7-6248
URL: https://issues.jboss.org/browse/AS7-6248
Project: Application Server 7
Issue Type: Bug
Components: Build System
Affects Versions: 7.2.0.Alpha1
Environment: CentOS 6.3, Intel X86-64
Reporter: Michael Van Geertruy
Assignee: Paul Gier
After downloading the most recent codebase from git for jbossAS 7.2.0.SNAPSHOT, I recieved the following error:
[INFO] ------------------------------------------------------------------------
[INFO] Building JBoss Application Server: Arquillian TestNG Integration 7.2.0.Alpha1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
Downloading: http://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbos...
[WARNING] The POM for org.jboss.as:jboss-as-spec-api:pom:7.2.0.Alpha1-SNAPSHOT is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: Arquillian .............. SUCCESS [3.091s]
[INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [7.331s]
[INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [7.461s]
[INFO] JBoss Application Server: Arquillian Embedded Container SUCCESS [18.654s]
[INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [3.766s]
[INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [19.634s]
[INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [2.147s]
[INFO] JBoss Application Server: Arquillian TestNG Integration FAILURE [3.535s]
[INFO] JBoss Application Server: Arquillian Common Domain SKIPPED
[INFO] JBoss Application Server: Arquillian Remote Domain Container SKIPPED
[INFO] JBoss Application Server: Arquillian Managed Domain Container SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:08.150s
[INFO] Finished at: Sat Dec 22 23:43:21 PST 2012
[INFO] Final Memory: 51M/317M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project jboss-as-arquillian-testng-integration: Could not resolve dependencies for project org.jboss.as:jboss-as-arquillian-testng-integration:jar:7.2.0.Alpha1-SNAPSHOT
Indeed after looking at the jboss nexus repository I came across this link:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/as/jbo...
There do not appear to be any entries for 7.2.0.Alpha1-SNAPSHOT.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5871) The default redirect port for the 8080 connector is current 8433. Should be 8443 instead.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5871?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5871:
----------------------------------
Fix Version/s: 7.2.0.Alpha1
> The default redirect port for the 8080 connector is current 8433. Should be 8443 instead.
> ------------------------------------------------------------------------------------------
>
> Key: AS7-5871
> URL: https://issues.jboss.org/browse/AS7-5871
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Fix For: 7.2.0.Alpha1
>
>
> The default redirect port for the 8080 connector is 8433. Seems that this is wrong as socket-bindings use 8443 (and former releases also)
> [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource
> {
> "outcome" => "success",
> "result" => {
> ...,
> "name" => "http",
> "protocol" => "HTTP/1.1",
> "redirect-port" => 8433,
> "scheme" => "http",
> "secure" => false,
> "socket-binding" => "http",
> "ssl" => undefined,
> "virtual-server" => undefined
> }
> }
> The pre-configured "https" socket binding conversely is 8443:
> [standalone@localhost:9999 socket-binding=https] /socket-binding-group=standard-sockets/socket-binding=https:read-resource
> {
> "outcome" => "success",
> "result" => {
> "client-mappings" => undefined,
> "fixed-port" => false,
> "interface" => undefined,
> "multicast-address" => undefined,
> "multicast-port" => undefined,
> "name" => "https",
> "port" => 8443
> }
> }
--
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
11 years, 7 months