[JBoss JIRA] (WFLY-3796) org.jboss.weld.exceptions.IllegalArgumentException during HttpSession.invalidate
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-3796?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-3796:
------------------------------------
I see. The code in {{LogoutModel}} seems to be fine. Would it be possible to create a simple reproducer?
Also, does it work on WildFly 8.1.0?
> org.jboss.weld.exceptions.IllegalArgumentException during HttpSession.invalidate
> --------------------------------------------------------------------------------
>
> Key: WFLY-3796
> URL: https://issues.jboss.org/browse/WFLY-3796
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 9.0.0.Beta1
> Reporter: Juergen Zimmermann
> Assignee: Martin Kouba
>
> 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-2344) undertow claims already registered
by Venkata Rammohan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2344?page=com.atlassian.jira.plugin.... ]
Venkata Rammohan commented on WFLY-2344:
----------------------------------------
Sure and thanks.
> undertow claims already registered
> ----------------------------------
>
> Key: WFLY-2344
> URL: https://issues.jboss.org/browse/WFLY-2344
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: miguel deanda
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:
> org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered
> I originally posted the question here:
> https://community.jboss.org/message/842352
> The relevant config section (standalone.xml) is the following:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> <buffer-caches>
> <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
> </buffer-caches>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" max-post-size="10485760"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> </host>
> <host name="other-host" alias="www.mysite.com" default-web-module="something.war">
> <location name="/" handler="welcome-content">
> <filter-ref name="connection-limit"/>
> </location>
> </host>
> </server>
> <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
> <jsp-config/>
> <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
> </handlers>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1877) System.nanoTime() may be in the future
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on JGRP-1877:
-----------------------------------
Of course for time periods greater than 292 years, that guarantee is lost.
> System.nanoTime() may be in the future
> --------------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1877) System.nanoTime() may be in the future
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on JGRP-1877:
-----------------------------------
No, eventually it may wrap around. The only guarantee is that t1 - t0 > 0. Because of twos complement math, this can be met even if t0 is very positive and t1 is very negative.
> System.nanoTime() may be in the future
> --------------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-2344) undertow claims already registered
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2344?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2344:
-----------------------------------
In that case please open forum discussion or jira and paste your undertow subsystem configuration and error you get.
As it would be different problem if it still occurs.
> undertow claims already registered
> ----------------------------------
>
> Key: WFLY-2344
> URL: https://issues.jboss.org/browse/WFLY-2344
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: miguel deanda
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:
> org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered
> I originally posted the question here:
> https://community.jboss.org/message/842352
> The relevant config section (standalone.xml) is the following:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> <buffer-caches>
> <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
> </buffer-caches>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" max-post-size="10485760"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> </host>
> <host name="other-host" alias="www.mysite.com" default-web-module="something.war">
> <location name="/" handler="welcome-content">
> <filter-ref name="connection-limit"/>
> </location>
> </host>
> </server>
> <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
> <jsp-config/>
> <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
> </handlers>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-2344) undertow claims already registered
by Venkata Rammohan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2344?page=com.atlassian.jira.plugin.... ]
Venkata Rammohan commented on WFLY-2344:
----------------------------------------
Might be , but I'm working on "wildfly-8.1.0.Final" , so I'm not sure in this version whether it is fixed or not.
I just posted my experience regarding that issue with "wildfly-8.1.0.Final".
> undertow claims already registered
> ----------------------------------
>
> Key: WFLY-2344
> URL: https://issues.jboss.org/browse/WFLY-2344
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: miguel deanda
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:
> org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered
> I originally posted the question here:
> https://community.jboss.org/message/842352
> The relevant config section (standalone.xml) is the following:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> <buffer-caches>
> <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
> </buffer-caches>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" max-post-size="10485760"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> </host>
> <host name="other-host" alias="www.mysite.com" default-web-module="something.war">
> <location name="/" handler="welcome-content">
> <filter-ref name="connection-limit"/>
> </location>
> </host>
> </server>
> <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
> <jsp-config/>
> <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
> </handlers>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3812) Package-private access doesn't work since Weld 2.2.4
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3812?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger updated WFLY-3812:
----------------------------------
Fix Version/s: 8.2.0.CR1
9.0.0.Beta1
Affects Version/s: (was: 9.0.0.Beta1)
> Package-private access doesn't work since Weld 2.2.4
> ----------------------------------------------------
>
> Key: WFLY-3812
> URL: https://issues.jboss.org/browse/WFLY-3812
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Reporter: Juergen Zimmermann
> Assignee: Jozef Hartinger
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
>
> The WildFly snapshot for 9.0.0.Alpha1 submits the serious warning below, when PicketLink is used. This warning is a result of upgrading to Weld 2.2.4. Please make the fix (at the bottom) before releasing WFLY 9. Thank you.
> {code}
> WARN [org.jboss.as.weld] WFLYWELD0052:
> Using deployment classloader to load proxy classes for module org.picketlink.core:main.
> Package-private access will not work. To fix this the module should declare dependencies on [org.jboss.weld.core, org.jboss.weld.spi]
> {code}
> The fix is:
> In file feature-pack/src/main/resources/modules/system/layers/base/org/picketlink/core/main/module.xml add these two lines within the <dependencies> block:
> {code}
> <module name="org.jboss.weld.core"/>
> <module name="org.jboss.weld.spi"/>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3812) Package-private access doesn't work since Weld 2.2.4
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3812?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3812:
------------------------------
Component/s: CDI / Weld
(was: Security)
> Package-private access doesn't work since Weld 2.2.4
> ----------------------------------------------------
>
> Key: WFLY-3812
> URL: https://issues.jboss.org/browse/WFLY-3812
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 9.0.0.Beta1
> Reporter: Juergen Zimmermann
> Assignee: Darran Lofthouse
>
> The WildFly snapshot for 9.0.0.Alpha1 submits the serious warning below, when PicketLink is used. This warning is a result of upgrading to Weld 2.2.4. Please make the fix (at the bottom) before releasing WFLY 9. Thank you.
> {code}
> WARN [org.jboss.as.weld] WFLYWELD0052:
> Using deployment classloader to load proxy classes for module org.picketlink.core:main.
> Package-private access will not work. To fix this the module should declare dependencies on [org.jboss.weld.core, org.jboss.weld.spi]
> {code}
> The fix is:
> In file feature-pack/src/main/resources/modules/system/layers/base/org/picketlink/core/main/module.xml add these two lines within the <dependencies> block:
> {code}
> <module name="org.jboss.weld.core"/>
> <module name="org.jboss.weld.spi"/>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3812) Package-private access doesn't work since Weld 2.2.4
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3812?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-3812:
---------------------------------
Assignee: Jozef Hartinger (was: Darran Lofthouse)
> Package-private access doesn't work since Weld 2.2.4
> ----------------------------------------------------
>
> Key: WFLY-3812
> URL: https://issues.jboss.org/browse/WFLY-3812
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 9.0.0.Beta1
> Reporter: Juergen Zimmermann
> Assignee: Jozef Hartinger
>
> The WildFly snapshot for 9.0.0.Alpha1 submits the serious warning below, when PicketLink is used. This warning is a result of upgrading to Weld 2.2.4. Please make the fix (at the bottom) before releasing WFLY 9. Thank you.
> {code}
> WARN [org.jboss.as.weld] WFLYWELD0052:
> Using deployment classloader to load proxy classes for module org.picketlink.core:main.
> Package-private access will not work. To fix this the module should declare dependencies on [org.jboss.weld.core, org.jboss.weld.spi]
> {code}
> The fix is:
> In file feature-pack/src/main/resources/modules/system/layers/base/org/picketlink/core/main/module.xml add these two lines within the <dependencies> block:
> {code}
> <module name="org.jboss.weld.core"/>
> <module name="org.jboss.weld.spi"/>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3812) Package-private access doesn't work since Weld 2.2.4
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created WFLY-3812:
----------------------------------------
Summary: Package-private access doesn't work since Weld 2.2.4
Key: WFLY-3812
URL: https://issues.jboss.org/browse/WFLY-3812
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 9.0.0.Beta1
Reporter: Juergen Zimmermann
Assignee: Darran Lofthouse
The WildFly snapshot for 9.0.0.Alpha1 submits the serious warning below, when PicketLink is used. This warning is a result of upgrading to Weld 2.2.4. Please make the fix (at the bottom) before releasing WFLY 9. Thank you.
{code}
WARN [org.jboss.as.weld] WFLYWELD0052:
Using deployment classloader to load proxy classes for module org.picketlink.core:main.
Package-private access will not work. To fix this the module should declare dependencies on [org.jboss.weld.core, org.jboss.weld.spi]
{code}
The fix is:
In file feature-pack/src/main/resources/modules/system/layers/base/org/picketlink/core/main/module.xml add these two lines within the <dependencies> block:
{code}
<module name="org.jboss.weld.core"/>
<module name="org.jboss.weld.spi"/>
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month