[JBoss JIRA] (LOGMGR-119) Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-119?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-119:
--------------------------------------
That's a good point, but we can't do much about it short of writing our own date formatter unfortunately. We use the {{java.text.SimpleDateFormat}} to format the date so we're limited by it's abilities.
> Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
> ----------------------------------------------------------------------------
>
> Key: LOGMGR-119
> URL: https://issues.jboss.org/browse/LOGMGR-119
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 1.5.2.Final
> Reporter: Osamu Nagano
> Assignee: James Perkins
>
> When {{PeriodicRotatingFileHandler}} with suffix "yyyy-ww" rotates a log file over a year, file that belongs to the new year is incorrectly named using the previous year.
> Here is a demonstrating test code supposed to be pasted into {{src/test/java/org/jboss/logmanager/handlers/PeriodicSizeRotatingFileHandlerTests.java}}. It mimics a record started from 2014-12-24 and the resulting backup log file is named {{rotating-file-handler.log.2014-01}}. It should be 2015 instead.
> {code}
> /*
> * Run with the following command:
> * mvn compile test -Dtest=PeriodicSizeRotatingFileHandlerTests#testPeriodicRotateWeekOfYear
> */
> @Test
> public void testPeriodicRotateWeekOfYear() throws Exception {
> SimpleDateFormat fmt = periodFormatMap.get(Calendar.WEEK_OF_YEAR);
> Calendar cal = Calendar.getInstance(java.util.TimeZone.getTimeZone("GMT"));
>
> PeriodicRotatingFileHandler handler = new PeriodicRotatingFileHandler();
> handler.setAutoFlush(true);
> handler.setFormatter(new PatternFormatter("%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"));
> handler.setSuffix("." + fmt.toPattern());
> handler.setFile(logFile);
>
> cal.set(Calendar.YEAR, 2014);
> cal.set(Calendar.MONTH, 12 - 1);
> cal.set(Calendar.DAY_OF_MONTH, 24);
> cal.set(Calendar.HOUR_OF_DAY, 12);
>
> for (int i = 0; i < 14; i++) {
> long tim = cal.getTimeInMillis();
> String fdate = fmt.format(tim);
> ExtLogRecord record = createLogRecord("%02d th formatted date is %s", i, fdate);
> record.setMillis(tim);
> handler.publish(record);
>
> cal.add(Calendar.DAY_OF_MONTH, 1);
> }
>
> handler.close();
>
> for (String logFile : BASE_LOG_DIR.list()) {
> System.out.println(logFile);
> }
> Assert.assertTrue("Dummy.", true);
> }
> {code}
> And here is the result of the test method.
> {code}
> % ll logs
> total 12K
> -rw-r--r--. 1 onagano onagano 228 Dec 5 17:09 rotating-file-handler.log
> -rw-r--r--. 1 onagano onagano 532 Dec 5 17:09 rotating-file-handler.log.2014-01
> -rw-r--r--. 1 onagano onagano 0 Dec 5 17:09 rotating-file-handler.log.2014-49
> -rw-r--r--. 1 onagano onagano 304 Dec 5 17:09 rotating-file-handler.log.2014-52
> % cat logs/rotating-file-handler.log.2014-52
> 2014-12-24 21:09:43,921 INFO [null] (main) 00 th formatted date is 2014-52
> 2014-12-25 21:09:43,921 INFO [null] (main) 01 th formatted date is 2014-52
> 2014-12-26 21:09:43,921 INFO [null] (main) 02 th formatted date is 2014-52
> 2014-12-27 21:09:43,921 INFO [null] (main) 03 th formatted date is 2014-52
> % cat logs/rotating-file-handler.log.2014-01
> 2014-12-28 21:09:43,921 INFO [null] (main) 04 th formatted date is 2014-01
> 2014-12-29 21:09:43,921 INFO [null] (main) 05 th formatted date is 2014-01
> 2014-12-30 21:09:43,921 INFO [null] (main) 06 th formatted date is 2014-01
> 2014-12-31 21:09:43,921 INFO [null] (main) 07 th formatted date is 2014-01
> 2015-01-01 21:09:43,921 INFO [null] (main) 08 th formatted date is 2015-01
> 2015-01-02 21:09:43,921 INFO [null] (main) 09 th formatted date is 2015-01
> 2015-01-03 21:09:43,921 INFO [null] (main) 10 th formatted date is 2015-01
> % cat logs/rotating-file-handler.log
> 2015-01-04 21:09:43,921 INFO [null] (main) 11 th formatted date is 2015-02
> 2015-01-05 21:09:43,921 INFO [null] (main) 12 th formatted date is 2015-02
> 2015-01-06 21:09:43,921 INFO [null] (main) 13 th formatted date is 2015-02
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (DROOLS-686) Documentation build: Upgrade pressgang-tools from 2 to 3
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-686:
---------------------------------------
Summary: Documentation build: Upgrade pressgang-tools from 2 to 3
Key: DROOLS-686
URL: https://issues.jboss.org/browse/DROOLS-686
Project: Drools
Issue Type: Task
Reporter: Geoffrey De Smet
Assignee: Petr Široký
We're still using pressgang-tools 2:
https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom....
but some years ago pressgang-tools 3.x was build and released (by Steve Ebersole), which fixes some issues and enables some new features (such as topics in docbook):
https://github.com/pressgang/pressgang-tools
However, pressgang-tools 3.x has an important regression in combination with the maven-docbook-plugin 2.3.8, which prevents building offline, which is a blocker for us:
https://issues.jboss.org/browse/PRESSGANG-79
The interesting note is that the gradle-docbook-plugin does build offline, and that both plugins (maven and gradle) use the same jdocbook-core:
https://github.com/pressgang
Goal: Fix that jira in maven-docbook-plugin and/or pressgang-tools, so droolsjbpm can upgrade to pressgang-tools 3.x. This is probably not easy.
The reason that it doesn't build offline, is because the xslt's contain full-url imports, so it reaches out to download those, but the jdocbook-core is able to intercepts to calls and reroute them to the local resources in the pressgang-tools jar (instead of downloading them from the internet). For some reason that works (probably configured correctly) for the gradle plugin, but not for the maven plugin. It's also strange that the maven plugin does work correctly with pressgang 2 jars.
In any case, the build should work offline (and doing "mvn -o" alone doesn't suffice to prove it, because the -o is ignored for the xslt stuff), plug out the network cable to verify it builds offline.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JBAS-5849) java.lang.IllegalStateException: Cannot obtain endpoint meta data
by Biswajit Das (JIRA)
[ https://issues.jboss.org/browse/JBAS-5849?page=com.atlassian.jira.plugin.... ]
Biswajit Das commented on JBAS-5849:
------------------------------------
I am trying it in jboss6.0.0.1 and it gives the same error.Please suggest me which jar need to be copied in jboss 6?
> java.lang.IllegalStateException: Cannot obtain endpoint meta data
> -----------------------------------------------------------------
>
> Key: JBAS-5849
> URL: https://issues.jboss.org/browse/JBAS-5849
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Components: Web Services
> Affects Versions: JBossAS-4.2.3.GA
> Environment: JBOSS 4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417), jdk1.6.0_07
> Reporter: Hemant Satam
> Assignee: Alessio Soldano
> Labels: JAXB, JBOSS, WebService, endpoint
> Attachments: Output view on browser.jpg
>
>
> While trying to access a webservice on JBOSS 4.2.3.GA, I get the following message
> java.lang.IllegalStateException: Cannot obtain endpoint meta data
> at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleWSDLRequestFromServletContext(RequestHandlerImpl.java:607)
> at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleWSDLRequest(RequestHandlerImpl.java:580)
> at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doGet(RequestHandlerImpl.java:156)
> at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:138)
> at org.jboss.wsf.stack.jbws.EndpointServlet.service(EndpointServlet.java:84)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
> at java.lang.Thread.run(Unknown Source)
> 01:55:46,218 ERROR [[HelloServiceWS]] Servlet.service() for servlet HelloServiceWS threw exception
> java.lang.IllegalStateException: Cannot obtain endpoint meta data
> at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleWSDLRequestFromServletContext(RequestHandlerImpl.java:607)
> at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleWSDLRequest(RequestHandlerImpl.java:580)
> at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doGet(RequestHandlerImpl.java:156)
> at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:138)
> at org.jboss.wsf.stack.jbws.EndpointServlet.service(EndpointServlet.java:84)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
> at java.lang.Thread.run(Unknown Source)
> Source Code:
> HelloService.Java
> package com.app.services;
> public class HelloService {
> public String hello (String name){
> return "Hello JBOSS";
> }
> }
> IHelloService.java
> package com.app.services;
> import java.rmi.Remote;
> import java.rmi.RemoteException;
> public interface IHelloService extends Remote {
> public String hello (String name) throws RemoteException;
> }
> mapping.xml
> ------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <java-wsdl-mapping xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_jaxrpc_mapping_1_1.xsd">
> <package-mapping>
> <package-type>com.app.services</package-type>
> <namespaceURI>http://services.app.com/types</namespaceURI>
> </package-mapping>
> <package-mapping>
> <package-type>com.app.services</package-type>
> <namespaceURI>http://services.app.com/</namespaceURI>
> </package-mapping>
> <service-interface-mapping>
> <service-interface>com.app.services.HelloServiceWS</service-interface>
> <wsdl-service-name xmlns:serviceNS="http://services.app.com/">serviceNS:HelloServiceWS</wsdl-service-name>
> <port-mapping>
> <port-name>IHelloServicePort</port-name>
> <java-port-name>IHelloServicePort</java-port-name>
> </port-mapping>
> </service-interface-mapping>
> <service-endpoint-interface-mapping>
> <service-endpoint-interface>com.app.services.IHelloService</service-endpoint-interface>
> <wsdl-port-type xmlns:portTypeNS="http://services.app.com/">portTypeNS:IHelloService</wsdl-port-type>
> <wsdl-binding xmlns:bindingNS="http://services.app.com/">bindingNS:IHelloServiceBinding</wsdl-binding>
> <service-endpoint-method-mapping>
> <java-method-name>hello</java-method-name>
> <wsdl-operation>hello</wsdl-operation>
> <method-param-parts-mapping>
> <param-position>0</param-position>
> <param-type>java.lang.String</param-type>
> <wsdl-message-mapping>
> <wsdl-message xmlns:wsdlMsgNS="http://services.app.com/">wsdlMsgNS:IHelloService_hello</wsdl-message>
> <wsdl-message-part-name>String_1</wsdl-message-part-name>
> <parameter-mode>IN</parameter-mode>
> </wsdl-message-mapping>
> </method-param-parts-mapping>
> <wsdl-return-value-mapping>
> <method-return-value>java.lang.String</method-return-value>
> <wsdl-message xmlns:wsdlMsgNS="http://services.app.com/">wsdlMsgNS:IHelloService_helloResponse</wsdl-message>
> <wsdl-message-part-name>result</wsdl-message-part-name>
> </wsdl-return-value-mapping>
> </service-endpoint-method-mapping>
> </service-endpoint-interface-mapping>
> </java-wsdl-mapping>
> web.xml
> -----------
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="http://java.sun.com/xml/ns/j2ee"
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
> version="2.4">
>
> <servlet>
> <servlet-name>HelloServiceWS</servlet-name>
> <servlet-class>com.app.services.HelloService</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
>
> <servlet-mapping>
> <servlet-name>HelloServiceWS</servlet-name>
> <url-pattern>/HelloServiceWS</url-pattern>
> </servlet-mapping>
> <session-config>
> <session-timeout>30</session-timeout>
> </session-config>
> <welcome-file-list>
> <welcome-file>index.html</welcome-file>
> <welcome-file>index.htm</welcome-file>
> <welcome-file>index.jsp</welcome-file>
> <welcome-file>default.html</welcome-file>
> <welcome-file>default.htm</welcome-file>
> <welcome-file>default.jsp</welcome-file>
> </welcome-file-list>
> </web-app>
> webservices.xml
> ------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <webservices xmlns="http://java.sun.com/xml/ns/j2ee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://www.ibm.com/webservices/xsd/j2ee_web_services_1_1.xsd" version="1.1">
> <webservice-description>
> <webservice-description-name>HelloServiceWS</webservice-description-name>
> <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file>
> <jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file>
> <port-component>
> <port-component-name>Hello</port-component-name>
> <wsdl-port>HelloPort</wsdl-port>
> <service-endpoint-interface>com.app.services.IHelloService</service-endpoint-interface>
> <service-impl-bean>
> <servlet-link>HelloServiceWS</servlet-link>
> </service-impl-bean>
> </port-component>
> </webservice-description>
> </webservices>
> HelloWebserviceWS.wsdl
> ------------------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <definitions name="HelloServiceWS" targetNamespace="http://services.app.com/" xmlns:tns="http://services.app.com/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
> <types/>
> <message name="IHelloService_hello">
> <part name="String_1" type="xsd:string"/></message>
> <message name="IHelloService_helloResponse">
> <part name="result" type="xsd:string"/></message>
> <portType name="IHelloService">
> <operation name="hello" parameterOrder="String_1">
> <input message="tns:IHelloService_hello"/>
> <output message="tns:IHelloService_helloResponse"/></operation></portType>
> <binding name="IHelloServiceBinding" type="tns:IHelloService">
> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>
> <operation name="hello">
> <soap:operation soapAction=""/>
> <input>
> <soap:body use="literal" namespace="http://services.app.com/"/></input>
> <output>
> <soap:body use="literal" namespace="http://services.app.com/"/></output></operation></binding>
> <service name="HelloServiceWS">
> <port name="IHelloServicePort" binding="tns:IHelloServiceBinding">
> <soap:address location="http://localhost:8080/apps/HelloServiceWS?wsdl"/></port></service></definitions>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-502) Eliminate requirement for OperationStepHandler.execute to call completeStep/stepCompleted
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-502?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-502:
------------------------------------
Description:
The requirement that an OSH call completeStep/stepCompleted in its execute method dates from when we supported recursive step execution. It could have been eliminated when we dropped support for recursive step execution, but that didn't occur to me until yesterday.
All stepCompleted() does is register a default ResultHandler. AbstractOperationContext.executeStep could do the same thing after calling step.execute(...) if that call returns normally and it sees that no ResultHandler was registered with the step.
Even I fairly often make the mistake of forgetting to add a stepCompleted call.
was:
The requirement that an OSH call completeStep/stepCompleted in its execute method dates from when we supported recursive step execution. It could have been eliminated when we dropped support for recursive step execution.
All stepCompleted() does is register a default ResultHandler. AbstractOperationContext.executeStep could do the same thing after calling step.execute(...) if that call returns normally and it sees that no ResultHandler was registered with the step.
Even I fairly often make the mistake of forgetting to add a stepCompleted call.
> Eliminate requirement for OperationStepHandler.execute to call completeStep/stepCompleted
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-502
> URL: https://issues.jboss.org/browse/WFCORE-502
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
>
> The requirement that an OSH call completeStep/stepCompleted in its execute method dates from when we supported recursive step execution. It could have been eliminated when we dropped support for recursive step execution, but that didn't occur to me until yesterday.
> All stepCompleted() does is register a default ResultHandler. AbstractOperationContext.executeStep could do the same thing after calling step.execute(...) if that call returns normally and it sees that no ResultHandler was registered with the step.
> Even I fairly often make the mistake of forgetting to add a stepCompleted call.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-502) Eliminate requirement for OperationStepHandler.execute to call completeStep/stepCompleted
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-502:
---------------------------------------
Summary: Eliminate requirement for OperationStepHandler.execute to call completeStep/stepCompleted
Key: WFCORE-502
URL: https://issues.jboss.org/browse/WFCORE-502
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 1.0.0.Beta1
The requirement that an OSH call completeStep/stepCompleted in its execute method dates from when we supported recursive step execution. It could have been eliminated when we dropped support for recursive step execution.
All stepCompleted() does is register a default ResultHandler. AbstractOperationContext.executeStep could do the same thing after calling step.execute(...) if that call returns normally and it sees that no ResultHandler was registered with the step.
Even I fairly often make the mistake of forgetting to add a stepCompleted call.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4237) Disabling weld in wildfly strangely degrade JSF performance
by Mostafa Abdelkhalek (JIRA)
[ https://issues.jboss.org/browse/WFLY-4237?page=com.atlassian.jira.plugin.... ]
Mostafa Abdelkhalek updated WFLY-4237:
--------------------------------------
Environment:
Windows 7 64 bit,
Oracle JDK 1.7.60 64bit,
Wildfly 8.2.0.Final
JSF 2.2
was:
wildfly 8.2.0.Final
JSF 2.2
> Disabling weld in wildfly strangely degrade JSF performance
> -----------------------------------------------------------
>
> Key: WFLY-4237
> URL: https://issues.jboss.org/browse/WFLY-4237
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 64 bit,
> Oracle JDK 1.7.60 64bit,
> Wildfly 8.2.0.Final
> JSF 2.2
> Reporter: Mostafa Abdelkhalek
> Attachments: weld_disabled.png, weld_enabled.png
>
>
> The ajax response time dramatically increases by increasing the number of JSF components when weld is disabled.
> This doesn't make sense and I have no idea why does it occur
> *WELD ENABLED*
> !weld_enabled.png|thumbnail!
> *WELD DISABLED*
> !weld_disabled.png|thumbnail!
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4237) Disabling weld in wildfly strangely degrade JSF performance
by Mostafa Abdelkhalek (JIRA)
[ https://issues.jboss.org/browse/WFLY-4237?page=com.atlassian.jira.plugin.... ]
Mostafa Abdelkhalek updated WFLY-4237:
--------------------------------------
Summary: Disabling weld in wildfly strangely degrade JSF performance (was: Disabling weld in wildfly strangely degrad JSF performance)
> Disabling weld in wildfly strangely degrade JSF performance
> -----------------------------------------------------------
>
> Key: WFLY-4237
> URL: https://issues.jboss.org/browse/WFLY-4237
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: wildfly 8.2.0.Final
> JSF 2.2
> Reporter: Mostafa Abdelkhalek
> Attachments: weld_disabled.png, weld_enabled.png
>
>
> The ajax response time dramatically increases by increasing the number of JSF components when weld is disabled.
> This doesn't make sense and I have no idea why does it occur
> *WELD ENABLED*
> !weld_enabled.png|thumbnail!
> *WELD DISABLED*
> !weld_disabled.png|thumbnail!
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months