[JBoss JIRA] (WFLY-1132) TS: Maven plugin for executing testsuite asynchronously in Jenkins.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1132?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-1132.
------------------------------------
Resolution: Rejected
This sounds interesting but is not an aspect of WildFly.
> TS: Maven plugin for executing testsuite asynchronously in Jenkins.
> -------------------------------------------------------------------
>
> Key: WFLY-1132
> URL: https://issues.jboss.org/browse/WFLY-1132
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Jakub Senko
> Assignee: Jakub Senko
>
> *Maven plugin to facilitate testing of local development git branches using distributed execution on Jenkins CI.*
> Currently, adding a feature or resolving a bug in large open source projects requires several steps:
> - getting the latest sources
> - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue
> - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions
> - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run
> - and if the job is successful, the problem is marked as resolved and the JIRA page updated
> Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. If there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful.
> This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins instance. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers.
> Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects.
> *Technical description (in progress, suggestions are welcome)*
> The maven plugin currently consists of two goals:
> The first goal will parse the job configuration from pom.xml a when executed, it will create new Job on the given Jenkins instance.
> Configuration to create a simple maven-based job may look as simple as:
> {code:xml|title=pom.xml|borderStyle=solid}
> <configuration>
> <url>${jenkins.url}</url>
> <jobs>
> <job>
> <id>test</id>
> <name>test-job</name>
> <scm>
> <git>${git.url}</git>
> </scm>
> <rootPom>myapp/pom.xml</rootPom>
> <ifExists>skip</ifExists>
> </job>
> </jobs>
> </configuration>
> {code}
> The second goal will execute the job, and optionally performs some cleanup:
> {code:xml|title=pom.xml|borderStyle=solid}
> <configuration>
> <url>${jenkins.url}</url>
> <runs>
> <run>
> <id>test</id>
> <name>test-${maven.build.timestamp}</name>
> <results> <!-- this describes which type of results and how are collected -->
> <result>
> <type>progress</type> <!-- simple progress bar is drawn while running the build remotely -->
> </result>
> <result>
> <type>shorttest</type> <!-- then a summary of the test results is displayed -->
> </result>
> <result>
> <type>shorttest</type> <!-- and it is also saved to a file -->
> <file>shorttest.txt</file>
> </result>
> </results>
> <failLocally>true</failLocally> <!-- fail the local maven execution when the remote Jenkins job fails -->
> </run>
> </runs>
> </configuration>
> {code}
>
--
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
12 years, 5 months
[JBoss JIRA] (WFLY-1013) Can't set attribute "suffix" on web access-log
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1013?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-1013:
-----------------------------------
Component/s: Web (JBoss Web)
> Can't set attribute "suffix" on web access-log
> ----------------------------------------------
>
> Key: WFLY-1013
> URL: https://issues.jboss.org/browse/WFLY-1013
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Environment: N/A
> Reporter: Ed Roberts
> Assignee: Remy Maucherat
> Labels: logging, suffix, web
>
> In JBoss 5.x you used to be able to specify a suffix attribute value for the JBossWeb access log file, which would be appended to generated log file names.
> In JBoss 7.x you can only specify a prefix. For the logging handlers you can specify both a prefix and a suffix, which is inconsistent.
> Please add the suffix attribute to the access-log element within the parent virtual-server element of the web subsystem xml configuration.
--
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
12 years, 5 months
[JBoss JIRA] (WFLY-897) Lifecycle and injections ignored in @ManagedBean dynamic Servlet
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-897?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-897:
----------------------------------
Component/s: Web (JBoss Web)
> Lifecycle and injections ignored in @ManagedBean dynamic Servlet
> ----------------------------------------------------------------
>
> Key: WFLY-897
> URL: https://issues.jboss.org/browse/WFLY-897
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Reporter: Cheng Fang
> Assignee: Remy Maucherat
>
> These classes are annotated with javax.annotation.ManagedBean, and added as dynamic servlet. The regular request processing works, but all lifecycle callback methods and resource injectsions in this dynamic servlet class are ignored.
> Since this class is a managed bean, these annotations need to be honored, though dynamic servelt itself does not require so.
> {quote}
> 4.4.3.5 Annotation processing requirements for programmatically added Servlets, Filters and Listeners
> Resource injection on all components (Servlets, Filters and Listeners) added programmatically or created programmatically, other than the ones added via the methods that takes an instance, will only be supported when the component is a Managed Bean.
> {quote}
--
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
12 years, 5 months
[JBoss JIRA] (WFLY-868) New instance of the filter in always created
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-868?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-868:
----------------------------------
Component/s: Web (JBoss Web)
> New instance of the filter in always created
> --------------------------------------------
>
> Key: WFLY-868
> URL: https://issues.jboss.org/browse/WFLY-868
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Reporter: Martin Vanek
> Assignee: Remy Maucherat
> Labels: filter
> Attachments: filtertest-0.0.1-SNAPSHOT.war, filtertest.zip
>
>
> I have created Servlet 3.0 filter in WebApplicationInitializer.onStartup() for example the following way:
> public void onStartup(ServletContext servletContext) throws ServletException {
> String servletName = "someServlet";
> String[] mappings = new String[] {"*.html"};
> Servlet servlet = FooServlet();
> ServletRegistration.Dynamic s = servletContext.addServlet(servletName, servlet);
> s.setLoadOnStartup(1);
> s.addMapping(mappings);
> Filter filter = new FooFilter("argument");
> String[] servletNames = new String[] {servletName};
> FilterRegistration.Dynamic f = servletContext.addFilter("fooFilter", filter);
> f.addMappingForServletNames(null, false, servletNames);
> }
> My problem is that jboss-web implemntation 7.0.13+ in StartdardContext.filterStart() along with ApplicationFilterConfig.getFilter() always tries to create new instance of the Filter via default constructor.
> My FooFilter does not have default constructor and therefore my application cannot be deployed.
> Please, check current implementation in Tomcat 7.0.32, which does not contain this problem.
> Also I have found that ApplicationFilterConfig has two similar atributes named filter and filterInstance. I guess it is quite wrong implementation and it is related to my problem.
--
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
12 years, 5 months
[JBoss JIRA] (WFLY-941) Dynamic servlet filter destroy method not called
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-941?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-941:
----------------------------------
Component/s: Web (JBoss Web)
> Dynamic servlet filter destroy method not called
> ------------------------------------------------
>
> Key: WFLY-941
> URL: https://issues.jboss.org/browse/WFLY-941
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Reporter: Cheng Fang
> Assignee: Remy Maucherat
>
> I added a servlet filter by calling ServletContext.addFilter(name, filterInstance)
> the init method of filterInstance (the instance I created and registered) is called, but its destroy method is not called throughout the life of the webapp, even after undeploy.
> I would expect the init/destroy methods to be symmetric; if one is called, the other should be called too, to release any resources and clean things up.
> For the container-managed filter instance (see AS7-5802), init and destroyed are correctly called.
--
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
12 years, 5 months
[JBoss JIRA] (WFLY-977) Servlet AsyncListener PreDestroy method not called
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-977?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-977:
----------------------------------
Component/s: Web (JBoss Web)
> Servlet AsyncListener PreDestroy method not called
> ---------------------------------------------------
>
> Key: WFLY-977
> URL: https://issues.jboss.org/browse/WFLY-977
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Reporter: Cheng Fang
> Assignee: Remy Maucherat
> Attachments: asynccontext.zip
>
>
> The PostConstruct method of an AsyncListener is called, but the PreDestroy method is not called.
> For example, the listener is created and registered as follows:
> {code:java}
> AsyncContext ac = request.startAsync();
>
> ac.addListener(ac.createListener(MyAsyncListener.class));
> {code}
> AsyncListener is considered a web event listener and Java EE component, and its PreDestroy method should be called when the current request terminates.
--
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
12 years, 5 months
[JBoss JIRA] (WFLY-796) Servlet response contains DOS-style EOL characters
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-796?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-796:
----------------------------------
Component/s: Web (JBoss Web)
> Servlet response contains DOS-style EOL characters
> --------------------------------------------------
>
> Key: WFLY-796
> URL: https://issues.jboss.org/browse/WFLY-796
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Environment: Mac OS
> Reporter: Cheng Fang
> Assignee: Remy Maucherat
> Attachments: test.war
>
>
> I'm running AS7 on Mac, but found sometimes my servlet PrintWriter produces output with dos-style eol. When opening the output in vi, there are a couple of ^M at end of line.
> This does not always happen. After trying out a few samples, I found if the line already contains line.separator, then its eol will be ^M. For example,
> {code:java}
> PrintWriter out = response.getWriter();
> out.println("From " + System.getProperty("line.separator") + this);
> {code}
> {noformat}
> From
> test.TestServlet@180ab18^M
> {noformat}
> If line.separator is not used when constructing servlet output, then everything looks normal.
> My guess is the servlet container may first apply a dos-style eol, then does some sort of replacing with native eol by searching for the first occurrence of line.separator.
--
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
12 years, 5 months
[JBoss JIRA] (WFLY-862) Shutdown process hangs using thread pool executor
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-862?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-862:
----------------------------------
Component/s: Web (JBoss Web)
> Shutdown process hangs using thread pool executor
> -------------------------------------------------
>
> Key: WFLY-862
> URL: https://issues.jboss.org/browse/WFLY-862
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Reporter: Eiichi Nagai
> Assignee: Remy Maucherat
>
> When AJP connecotr uses thread pool executor configuration[1], AJP's worker thread is waited by AjpProcessor.read()[2]. QueueExecuter recognizes it as active thread. Therefor, unless httpd server shut down, EAP server shutdown process does not finish forever.
> [1] standalone.xml
> <subsystem xmlns="urn:jboss:domain:threads:1.1">
> <bounded-queue-thread-pool name="http-executor">
> <queue-length count="1"/>
> <max-threads count="1"/>
> </bounded-queue-thread-pool>
> </subsystem>
> --- snip ---
> <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false">
> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp" executor="http-executor"/>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> [2]
> "http-executor-threads - 1" prio=6 tid=0x55515000 nid=0x20c0 runnable [0x5590f000]
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:1131)
> at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:1213)
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:451)
> at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452)
> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:519)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821)
> at java.lang.Thread.run(Thread.java:662)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
--
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
12 years, 5 months