[JBoss JIRA] (AS7-4115) Jboss Web Connector resources max-threads data not available in ui or cli/json data
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/AS7-4115?page=com.atlassian.jira.plugin.s... ]
Jean-Frederic Clere edited comment on AS7-4115 at 4/11/12 4:35 AM:
-------------------------------------------------------------------
That is nearly impossible to fix the default is in jbossweb connector logic there is no way get it in the resource logic.
was (Author: jfclere):
That is impossible to fix the default is in jbossweb connector logic there is no way get it in the resource logic.
> Jboss Web Connector resources max-threads data not available in ui or cli/json data
> ------------------------------------------------------------------------------------
>
> Key: AS7-4115
> URL: https://issues.jboss.org/browse/AS7-4115
> Project: Application Server 7
> Issue Type: Bug
> Environment: Using JBEAP-6.0.0.ER1.
> Reporter: Simeon Pinder
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Labels: rhq
>
> Looks like max-threads is not currently exposed for JBoss Web Connectors.
> "connector" => {"http" => {
> "bytesReceived" => "0",
> "bytesSent" => "0",
> "enable-lookups" => false,
> "enabled" => true,
> "errorCount" => "0",
> "max-post-size" => 2097152,
> "max-save-post-size" => 4096,
> "maxTime" => "0",
> "processingTime" => "0",
> "protocol" => "HTTP/1.1",
> "redirect-port" => 8443,
> "requestCount" => "0",
> "scheme" => "http",
> "secure" => false,
> "socket-binding" => "http",
> "ssl" => undefined,
> "virtual-server" => undefined
> }}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4115) Jboss Web Connector resources max-threads data not available in ui or cli/json data
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/AS7-4115?page=com.atlassian.jira.plugin.s... ]
Jean-Frederic Clere edited comment on AS7-4115 at 4/11/12 4:35 AM:
-------------------------------------------------------------------
That is nearly impossible to fix the default is in jbossweb connector logic there is no easy way get it in the resource logic.
was (Author: jfclere):
That is nearly impossible to fix the default is in jbossweb connector logic there is no way get it in the resource logic.
> Jboss Web Connector resources max-threads data not available in ui or cli/json data
> ------------------------------------------------------------------------------------
>
> Key: AS7-4115
> URL: https://issues.jboss.org/browse/AS7-4115
> Project: Application Server 7
> Issue Type: Bug
> Environment: Using JBEAP-6.0.0.ER1.
> Reporter: Simeon Pinder
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Labels: rhq
>
> Looks like max-threads is not currently exposed for JBoss Web Connectors.
> "connector" => {"http" => {
> "bytesReceived" => "0",
> "bytesSent" => "0",
> "enable-lookups" => false,
> "enabled" => true,
> "errorCount" => "0",
> "max-post-size" => 2097152,
> "max-save-post-size" => 4096,
> "maxTime" => "0",
> "processingTime" => "0",
> "protocol" => "HTTP/1.1",
> "redirect-port" => 8443,
> "requestCount" => "0",
> "scheme" => "http",
> "secure" => false,
> "socket-binding" => "http",
> "ssl" => undefined,
> "virtual-server" => undefined
> }}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4115) Jboss Web Connector resources max-threads data not available in ui or cli/json data
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/AS7-4115?page=com.atlassian.jira.plugin.s... ]
Jean-Frederic Clere edited comment on AS7-4115 at 4/11/12 4:06 AM:
-------------------------------------------------------------------
That is impossible to fix the default is in jbossweb connector logic there is no way get it in the resource logic.
was (Author: jfclere):
That is impossible to fix the default is jbossweb connector logic there is no way get it in the resource logic.
> Jboss Web Connector resources max-threads data not available in ui or cli/json data
> ------------------------------------------------------------------------------------
>
> Key: AS7-4115
> URL: https://issues.jboss.org/browse/AS7-4115
> Project: Application Server 7
> Issue Type: Bug
> Environment: Using JBEAP-6.0.0.ER1.
> Reporter: Simeon Pinder
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Labels: rhq
>
> Looks like max-threads is not currently exposed for JBoss Web Connectors.
> "connector" => {"http" => {
> "bytesReceived" => "0",
> "bytesSent" => "0",
> "enable-lookups" => false,
> "enabled" => true,
> "errorCount" => "0",
> "max-post-size" => 2097152,
> "max-save-post-size" => 4096,
> "maxTime" => "0",
> "processingTime" => "0",
> "protocol" => "HTTP/1.1",
> "redirect-port" => 8443,
> "requestCount" => "0",
> "scheme" => "http",
> "secure" => false,
> "socket-binding" => "http",
> "ssl" => undefined,
> "virtual-server" => undefined
> }}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4115) Jboss Web Connector resources max-threads data not available in ui or cli/json data
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/AS7-4115?page=com.atlassian.jira.plugin.s... ]
Jean-Frederic Clere commented on AS7-4115:
------------------------------------------
That is impossible to fix the default is jbossweb connector logic there is no way get it in the resource logic.
> Jboss Web Connector resources max-threads data not available in ui or cli/json data
> ------------------------------------------------------------------------------------
>
> Key: AS7-4115
> URL: https://issues.jboss.org/browse/AS7-4115
> Project: Application Server 7
> Issue Type: Bug
> Environment: Using JBEAP-6.0.0.ER1.
> Reporter: Simeon Pinder
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Labels: rhq
>
> Looks like max-threads is not currently exposed for JBoss Web Connectors.
> "connector" => {"http" => {
> "bytesReceived" => "0",
> "bytesSent" => "0",
> "enable-lookups" => false,
> "enabled" => true,
> "errorCount" => "0",
> "max-post-size" => 2097152,
> "max-save-post-size" => 4096,
> "maxTime" => "0",
> "processingTime" => "0",
> "protocol" => "HTTP/1.1",
> "redirect-port" => 8443,
> "requestCount" => "0",
> "scheme" => "http",
> "secure" => false,
> "socket-binding" => "http",
> "ssl" => undefined,
> "virtual-server" => undefined
> }}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-3042) IPv6: Invalid redirect to Admin console (wrong IP address)
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/AS7-3042?page=com.atlassian.jira.plugin.s... ]
Jan Martiska commented on AS7-3042:
-----------------------------------
Is it really that difficult to find the actual address of the Admin Console? I mean, for example in the server's console output after start, this log appears:
{noformat}
09:06:52,341 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://[fe80:0:0:0:f2de:f1ff:fe41:23a4%2]:9990
{noformat}
This string beginning with http is actually (most likely always) the correct URL that will work if you put it in the browser (if you remove the %2 in the end of the address - Firefox will accept this anyway, but for example Chrome seems it will not). If EAP actually KNOWS the URL for the admin console, I think it should not be a serious problem to provide a valid redirect link. What do you think?
> IPv6: Invalid redirect to Admin console (wrong IP address)
> ----------------------------------------------------------
>
> Key: AS7-3042
> URL: https://issues.jboss.org/browse/AS7-3042
> Project: Application Server 7
> Issue Type: Bug
> Components: Console, Web
> Affects Versions: 7.1.0.Beta1b
> Reporter: Pavel Janousek
> Assignee: Darran Lofthouse
> Fix For: Open To Community
>
>
> This issue is some derivation from AS7-3040. Lets imagine starting server like this:
> {code}./standalone.sh -Djava.net.preferIPv4Stack=false -Djboss.bind.address=::1{code}
> So by default the admin/management is bound to _::ffff:127.0.0.1:9990_ and _::ffff:127.0.0.1:9999_, but it isn't accessible from Web WelcomePage at _::1:8080_ because the URL is specified as: {code}<a href="/console">{code} and so the next request is http://[::1]:8080/console which redirect requester to http://[::1]:9990, but there isn't any console because it is here - http://[::ffff:127.0.0.1]:9990.
> This is not good as it could lead to integration issues between components (X trying to connect to Y on ::1; Y listening on ::ffff:127.0.0.1).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4326) java.lang.StringIndexOutOfBoundsException jsf renderkit
by nimo stephan (JIRA)
nimo stephan created AS7-4326:
---------------------------------
Summary: java.lang.StringIndexOutOfBoundsException jsf renderkit
Key: AS7-4326
URL: https://issues.jboss.org/browse/AS7-4326
Project: Application Server 7
Issue Type: Bug
Components: JSF
Affects Versions: 7.1.1.Final
Reporter: nimo stephan
Assignee: Stan Silvert
I use this code (nothing special) which renders right:
<h:form>
<h:panelGroup id="area">
<h:selectOneRadio value="#{mybean.selectedValue}" valueChangeListener="#{myBean.onMySelect}">
<f:selectItems value="#{myBean.selectables}" var="_e" itemLabel="#{_e.name}" itemValue="#{_e.name}" />
<f:ajax render="area_2"/>
</h:selectOneRadio>
</h:panelGroup>
<h:panelGroup id="area_2">
<label>Name</label>
<h:inputText required="true" value="#{myBean.name}" />
</h:panelGroup>
<h:commandLink value="Save" action="#{bean.save}">
<f:ajax execute="@form" render="@form" />
</h:commandLink>
</h:panelGroup>
</h:form>
When selecting a item of selectOneRadio-component then the valueChangeEvent is fired without an error. However, when submitting the form by pressing the "Save"-Button, then this (full) stacktrace happens (the stacktrace is not cut):
10:02:42,920 Information [javax.enterprise.resource.webcontainer.jsf.context] (http-localhost-127.0.0.1-8080-1) java.lang.StringIndexOutOfBoundsException: String index out of range: -1: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1958) [rt.jar:1.7.0_01]
at com.sun.faces.renderkit.html_basic.SelectManyCheckboxListRenderer.isBehaviorSource(SelectManyCheckboxListRenderer.java:214) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.decodeBehaviors(HtmlBasicRenderer.java:213) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.renderkit.html_basic.MenuRenderer.decode(MenuRenderer.java:221) [jsf-impl-2.1.7-jbossorg-2.jar:]
at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:787) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at javax.faces.component.UIInput.decode(UIInput.java:757) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1181) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at javax.faces.component.UIInput.processDecodes(UIInput.java:662) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1176) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1176) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at com.sun.faces.context.PartialViewContextImpl$PhaseAwareVisitCallback.visit(PartialViewContextImpl.java:506) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.component.visit.PartialVisitContext.invokeVisitCallback(PartialVisitContext.java:183) [jsf-impl-2.1.7-jbossorg-2.jar:]
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1612) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at javax.faces.component.UIForm.visitTree(UIForm.java:362) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1623) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at com.sun.faces.context.PartialViewContextImpl.processComponents(PartialViewContextImpl.java:376) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.context.PartialViewContextImpl.processPartial(PartialViewContextImpl.java:252) [jsf-impl-2.1.7-jbossorg-2.jar:]
at org.richfaces.context.ExtendedPartialViewContextImpl.processPartial(ExtendedPartialViewContextImpl.java:199) [richfaces-core-impl-4.2.0.Final.jar:4.2.0.Final]
at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:931) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.7-jbossorg-2.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.7-jbossorg-2.jar:]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jboss-jsf-api_2.1_spec-2.0.1.Final.jar:2.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.jboss.solder.servlet.exception.CatchExceptionFilter.doFilter(CatchExceptionFilter.java:65) [solder-impl-3.1.0.Final.jar:3.1.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.jboss.solder.servlet.event.ServletEventBridgeFilter.doFilter(ServletEventBridgeFilter.java:74) [solder-impl-3.1.0.Final.jar:3.1.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_01]
I don't know where the failure lies, I guess, it is a bug in the JSF-Implementation.
The strange thing is, when deleting the <f:ajax render="area_2"/> and submitting again, then no stacktrace occurs (however, I need to use ajax within the component 'selectOneRadio'. The other strange thing is this: When I use this code for my 'selectOneRadio', then ALL works fine without any stacktrace:
<h:selectOneRadio value="#{mybean.selectedValue}" valueChangeListener="#{myBean.onMySelect}"
onchange="jsf.ajax.request(this, event, { render: 'area_2'}); return false">
<f:selectItems value="#{myBean.selectables}" var="_e" itemLabel="#{_e.name}" itemValue="#{_e.name}" />
</h:selectOneRadio>
So you see, I substitute this (VERSION 1):
<f:ajax render="area_2"/>
with this (VERSION 2):
onchange="jsf.ajax.request(this, event, { render: 'area_2'}); return false"
and now it works fine.
But why can I not use (VERSION 1)?
I have thought, (VERSION 1) and (VERSION 2) should be treated equal.
The other strange thing is, that the stacktrace with (VERSION 1) only occurs with the component 'selectOneRadio'. Using the same bean-properties of 'VERSION 1' with a other component (for example, 'selectOneMenu') all works right:
<h:selectOneMenu value="#{mybean.selectedValue}" valueChangeListener="#{myBean.onMySelect}">
<f:selectItems value="#{myBean.selectables}" var="_e" itemLabel="#{_e.name}" itemValue="#{_e.name}" />
<f:ajax render="area_2"/>
</h:selectOneMenu>
So I guess, it is a bug within the ajaxified selectOneRadio.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4340) raw input-fields in h:form breaks JSF-Application
by nimo stephan (JIRA)
nimo stephan created AS7-4340:
---------------------------------
Summary: raw input-fields in h:form breaks JSF-Application
Key: AS7-4340
URL: https://issues.jboss.org/browse/AS7-4340
Project: Application Server 7
Issue Type: Bug
Components: JSF
Affects Versions: 7.1.1.Final
Reporter: nimo stephan
Assignee: Stan Silvert
I have updated from JBOSS AS 7.1.0 FINAL to JBOSS AS 7.1.1 FINAL and after that a problem with its underlying JSF-Implementation occured.
The following two versions shows the problem:
When clicking the button 'my-btn' of VERSION 1,
then JSF do not send any data to the server.
It even does not say anything in my log or my facelets-debug-page. The error is totally silent!
However, using VERSION 1 with JBOSS AS 7.1.0 FINAL works without error !!
VERSION 2 does work both in JBOSS AS 7.1.0 FINAL and JBOSS AS 7.1.1 FINAL.
When clicking the button 'my-btn' of VERSION 2,
then JSF sends data to the server,
because I placed my input-field outside of the JSF-Form-Tag.
The input-field is NOT a JSF-component, I use it only for client-side-purpose (so no need for h:inputText).
Why I am forced to use a h:inputText, when not wanting it ?
VERSION 1:
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:a4j="http://richfaces.org/a4j">
<h:form id="overall-form" prependId="false">
<header id="my-hd">
<h:commandLink id="my-btn" value="get data " action="#{myBean.getData}">
<f:ajax render="@form" />
</h:commandLink>
</header>
<!-- I use a raw html-input-field only for client-side-purpose, so I do not want to use a <h:inputText /> , but this input-field breaks my JSF-Application !->
<div
<input type="text" value=""/>
</div>
</h:form>
VERSION 2:
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:a4j="http://richfaces.org/a4j">
<h:form id="overall-form" prependId="false">
<header id="my-hd">
<h:commandLink id="my-btn" value="get data " action="#{myBean.getData}">
<f:ajax render="@form" />
</h:commandLink>
</header>
</h:form>
<!-- I use a raw html-input-field only for client-side-purpose, so I do not want to use a <h:inputText /> , as it is no more included within a JSF-form-tag, my JSF-Application works without errors->
<div
<input type="text" value=""/>
</div>
I guess, it is a bug in JSF-lib which was upgraded in JBOSS AS 7.1.1 FINAL to JSF 2.1.7.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-3036) Remove OSGi bundles that cannot be supported
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-3036?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on AS7-3036:
-------------------------------------
Please go to the forum for discussions like this.
> Remove OSGi bundles that cannot be supported
> --------------------------------------------
>
> Key: AS7-3036
> URL: https://issues.jboss.org/browse/AS7-3036
> Project: Application Server 7
> Issue Type: Task
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.1.0.Final
>
>
> Currently we have:
> * Webconsole, provided by Felix (requires HttpService)
> * HttpService, provided by PaxWeb (runs on Jetty)
> * Webapp support, provided by PaxWeb (runs on Jetty)
> * LogService, provided by Felix
> * ConfigAdmin service, provided by Felix
> * JMX services, provided by Aries
> * EventAdmin, provided by Felix
> * DeclarativServices, provided by Felix
> * STOMP endpoints (Stilts), provided by JBoss
> * Blueprint, provided by Aries
> * XML parsing, provided by JBoss
> * JNDI support, provided by JBoss
> * JTA support, provided by JBoss
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (EJBTHREE-2279) Injection target type mismatch
by Arto Huusko (JIRA)
Arto Huusko created EJBTHREE-2279:
-------------------------------------
Summary: Injection target type mismatch
Key: EJBTHREE-2279
URL: https://issues.jboss.org/browse/EJBTHREE-2279
Project: EJB 3.0
Issue Type: Bug
Environment: JBoss AS 7.1.1.Final
Reporter: Arto Huusko
EJB 3 session deployment fails on AS 7.1.1 with error:
16:28:53,144 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.unit."example.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."example.jar".POST_MODULE: Failed to process phase POST_MODULE of deployment "example.jar"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011068: Injection target session2 on class Session1Bean is not compatible with the type of injection: interface Session2Local
at org.jboss.as.ee.component.deployers.AbstractDeploymentDescriptorBindingsProcessor.processInjectionTargets(AbstractDeploymentDescriptorBindingsProcessor.java:157)
at org.jboss.as.ejb3.deployment.processors.EjbRefProcessor.processDescriptorEntries(EjbRefProcessor.java:173)
at org.jboss.as.ee.component.deployers.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:105)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
... 5 more
Session2Local is the actual business interface of the injected bean. The field Session1Bean.session2 has type Session2 which is a superinteface of Session2Local. The injection is done using <ejb-local-ref> with <injection-target> in deployment descriptor.
The forum reference contains a failing example JAR with source code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months