[JBoss JIRA] (WFLY-3890) Intermittent test failures due to 'Could not stop container' and 'Could not start container'
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3890?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-3890:
-----------------------------------
No! proper fix is to do proper cleanup of vault files as it usually breaks because of leftovers or some corrupt vault.dat stuff.
> Intermittent test failures due to 'Could not stop container' and 'Could not start container'
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-3890
> URL: https://issues.jboss.org/browse/WFLY-3890
> Project: WildFly
> Issue Type: Bug
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
>
> HTTPSConnectionWithCLITestCase and VaultPasswordsInCLITestCase.java secures management interface with SSL, but
> they sometimes fail to unsecure it due to problem mentioned in BZ1105003. We should use different standalone
> configuration to avoid breaking whole manual-mode module due to this. Also chenged tests to use :reload
> command instead of reload operation as Alexey suggested in BZ1136220#c11.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3890) Intermittent test failures due to 'Could not stop container' and 'Could not start container'
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3890?page=com.atlassian.jira.plugin.... ]
Petr Kremensky closed WFLY-3890.
--------------------------------
Resolution: Duplicate Issue
I already did an upstream issue a week ago :) WFLY-3862
> Intermittent test failures due to 'Could not stop container' and 'Could not start container'
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-3890
> URL: https://issues.jboss.org/browse/WFLY-3890
> Project: WildFly
> Issue Type: Bug
> Reporter: Petr Kremensky
> Assignee: Petr Kremensky
>
> HTTPSConnectionWithCLITestCase and VaultPasswordsInCLITestCase.java secures management interface with SSL, but
> they sometimes fail to unsecure it due to problem mentioned in BZ1105003. We should use different standalone
> configuration to avoid breaking whole manual-mode module due to this. Also chenged tests to use :reload
> command instead of reload operation as Alexey suggested in BZ1136220#c11.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3890) Intermittent test failures due to 'Could not stop container' and 'Could not start container'
by Petr Kremensky (JIRA)
Petr Kremensky created WFLY-3890:
------------------------------------
Summary: Intermittent test failures due to 'Could not stop container' and 'Could not start container'
Key: WFLY-3890
URL: https://issues.jboss.org/browse/WFLY-3890
Project: WildFly
Issue Type: Bug
Reporter: Petr Kremensky
Assignee: Petr Kremensky
HTTPSConnectionWithCLITestCase and VaultPasswordsInCLITestCase.java secures management interface with SSL, but
they sometimes fail to unsecure it due to problem mentioned in BZ1105003. We should use different standalone
configuration to avoid breaking whole manual-mode module due to this. Also chenged tests to use :reload
command instead of reload operation as Alexey suggested in BZ1136220#c11.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3796) org.jboss.weld.exceptions.IllegalArgumentException during HttpSession.invalidate
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-3796?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-3796:
------------------------------------------
Yes, @ViewScoped bean -> @ConversationScoped bean -> @RequestScoped bean (= LogoutModel)
> org.jboss.weld.exceptions.IllegalArgumentException during HttpSession.invalidate
> --------------------------------------------------------------------------------
>
> Key: WFLY-3796
> URL: https://issues.jboss.org/browse/WFLY-3796
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 9.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Martin Kouba
> Attachments: wfly-3796-reproducer.zip
>
>
> I'm using WildFly 9.0.0.Alpha1 snapshot. When I invoke HttpSession.invalidate() after PicketLink's logout method I'm getting a org.jboss.weld.exceptions.IllegalArgumentException (see stacktrace below). I also tried weld-core-impl-2.2.4.Final, but got the same stacktrace.
> The Session Bean "ListKundenModel" has these annotations:
> @Named
> @ViewScoped
> @Stateful
> {code}
> WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] #{logoutModel.logout}: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]: javax.faces.FacesException: #{logoutModel.logout}: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> Caused by: javax.faces.el.EvaluationException: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:101) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.8-jbossorg-1.jar:]
> ... 33 more
> Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]
> at org.jboss.weld.bean.SessionBean.destroy(SessionBean.java:155) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at com.sun.faces.application.view.ViewScopeContextManager.destroyBeans(ViewScopeContextManager.java:177) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.view.ViewScopeContextManager.sessionDestroyed(ViewScopeContextManager.java:339) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.view.ViewScopeManager.sessionDestroyed(ViewScopeManager.java:371) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.WebappLifecycleListener.sessionDestroyed(WebappLifecycleListener.java:181) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.ConfigureListener.sessionDestroyed(ConfigureListener.java:377) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:264) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(SessionListenerBridge.java:66) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.session.SessionListeners.sessionDestroyed(SessionListeners.java:56) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:395) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:381) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:197) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at de.shop.iam.web.LogoutModel.logout(LogoutModel.java:55) [classes:]
> at de.shop.iam.web.LogoutModel$Proxy$_$$_WeldSubclass.logout(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.weld.interceptor.proxy.SimpleInterceptionChain.interceptorChainCompleted(SimpleInterceptionChain.java:51) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:96) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:149) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at de.shop.util.interceptor.LogInterceptor.log(LogInterceptor.java:96) [classes:]
> at sun.reflect.GeneratedMethodAccessor2531.invoke(Unknown Source) [:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:149) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:92) [narayana-jts-jacorb-5.0.2.Final.jar:5.0.2.Final (revision: d1e56)]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.2.Final.jar:5.0.2.Final (revision: d1e56)]
> at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source) [:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at de.shop.iam.web.LogoutModel$Proxy$_$$_WeldSubclass.logout(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at com.sun.el.parser.AstValue.invoke(AstValue.java:292) [javax.el-impl-3.0.1-b05-jbossorg-1.jar:3.0.1-b05-jbossorg-1]
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-impl-3.0.1-b05-jbossorg-1.jar:3.0.1-b05-jbossorg-1]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> ... 34 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-950) RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-950?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-950:
----------------------------------------------
Katerina Novotna <kanovotn(a)redhat.com> changed the Status of [bug 899666|https://bugzilla.redhat.com/show_bug.cgi?id=899666] from ON_QA to ASSIGNED
> RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception
> ---------------------------------------------------------------------
>
> Key: WFLY-950
> URL: https://issues.jboss.org/browse/WFLY-950
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Reporter: Pavel Janousek
> Assignee: Weinan Li
>
> RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. The major one (also portable defined by JAX-RS standard) is _javax.ws.rs.Application_. When I set this parameter to empty content present behavior is raising exception "java.lang.StringIndexOutOfBoundsException: String index out of range: 0", it is not so good.
> I think, this is hard miss-configuration error and deployment description as this one should be rejected and a such application should not be deployed at all with appropriate error message, but not only by messed exception.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3369) Performance issue of jaxws-client on JDK 1.7.0_55
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3369?page=com.atlassian.jira.plugin.... ]
Jim Ma commented on WFLY-3369:
------------------------------
After some jdk code analysis , it turns this performance regression is introduced by [https://bugs.openjdk.java.net/browse/JDK-7199862] which is added to check if httpclient is still available for streaming post. From changeset [http://hg.openjdk.java.net/jdk7u/jdk7u40/jdk/rev/e6dc1d9bc70b], each time client connects to server , it will try to get inputstream from serverSocket and read to know if the connection is still alive. I am not sure if this is the ideal approach to check.
> Performance issue of jaxws-client on JDK 1.7.0_55
> -------------------------------------------------
>
> Key: WFLY-3369
> URL: https://issues.jboss.org/browse/WFLY-3369
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: JBoss AS7 7.1.1.Final
> Environment: Red Hat Enterprise 6.4, Solaris 10, JBoss AS 7.1.3
> Reporter: Zhang Boya
> Assignee: Jim Ma
>
> Assume that a JAX-WS deploys on somewhere else, developer generates the JAX-WS client side classes by using wsdl2java tools. These classes have been exported as 'exmaple-ws-client.jar'. When developer needs to access this JAX-WS in their web application, this JAR file would be published with WAR file together. By default, the JBoss AS would supply an instance of CXF's implementation for the JAX-WS client when web application be deployed to JBoss AS. The class name of this JAX-WS client would be 'org.apache.cxf.jaxws.JaxWsClientProxy'. The JAX-WS invocations of client side got a very bad performance since I upgraded JDK from 1.7.0_25 to 1.7.0_55, especially on Solaris.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3369) Performance issue of jaxws-client on JDK 1.7.0_55
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3369?page=com.atlassian.jira.plugin.... ]
Jim Ma resolved WFLY-3369.
--------------------------
Resolution: Won't Fix
> Performance issue of jaxws-client on JDK 1.7.0_55
> -------------------------------------------------
>
> Key: WFLY-3369
> URL: https://issues.jboss.org/browse/WFLY-3369
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: JBoss AS7 7.1.1.Final
> Environment: Red Hat Enterprise 6.4, Solaris 10, JBoss AS 7.1.3
> Reporter: Zhang Boya
> Assignee: Jim Ma
>
> Assume that a JAX-WS deploys on somewhere else, developer generates the JAX-WS client side classes by using wsdl2java tools. These classes have been exported as 'exmaple-ws-client.jar'. When developer needs to access this JAX-WS in their web application, this JAR file would be published with WAR file together. By default, the JBoss AS would supply an instance of CXF's implementation for the JAX-WS client when web application be deployed to JBoss AS. The class name of this JAX-WS client would be 'org.apache.cxf.jaxws.JaxWsClientProxy'. The JAX-WS invocations of client side got a very bad performance since I upgraded JDK from 1.7.0_25 to 1.7.0_55, especially on Solaris.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3866) Removing jndi entry which does not exist return success
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3866?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3866:
-----------------------------------------------
Miroslav Novak <mnovak(a)redhat.com> changed the Status of [bug 1142619|https://bugzilla.redhat.com/show_bug.cgi?id=1142619] from ON_QA to VERIFIED
> Removing jndi entry which does not exist return success
> -------------------------------------------------------
>
> Key: WFLY-3866
> URL: https://issues.jboss.org/browse/WFLY-3866
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 9.0.0.Alpha1
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
>
> Operation "remove-jndi" on queue/topic is successful when trying to remove non-existent JNDI entry:
> [standalone@localhost:9999 jms-queue=testQueue1] :read-resource
> {
> "outcome" => "success",
> "result" => {
> "durable" => true,
> "entries" => ["java:jboss/exported/jms/queue/testQueue2"],
> "selector" => undefined
> }
> }
> [standalone@localhost:9999 jms-queue=testQueue1] :remove-jndi(jndi-binding=java:jboss/exported/jms/queue/dummyQueue)
> {
> "outcome" => "success",
> "result" => undefined
> }
> We should return outcome "failed" with "failure-description" like "Can not remove JNDI name java:jboss/exported/jms/queue/dummyQueue. The resource does not contain such a JNDI name."
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month