[JBoss JIRA] (WFLY-658) Complete support for OSGi webapps in JBossWeb
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-658?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler reopened WFLY-658:
---------------------------------
> Complete support for OSGi webapps in JBossWeb
> ---------------------------------------------
>
> Key: WFLY-658
> URL: https://issues.jboss.org/browse/WFLY-658
> Project: WildFly
> Issue Type: Feature Request
> Components: OSGi
> Reporter: Thomas Diesler
> Labels: roadmap
> Attachments: webapp-1.0.pdf
>
>
> Following initial support for WAB please review the spec and implement missing functionality.
> h5. 128.3.1 WAB Definition
> The web.xml must be found with the Bundle findEntries method. The findEntries method includes fragments, allowing the web.xml to be provided by a fragment.
> h5. 128.3.2 Starting the Web Application Bundle
> The Web Extender should ensure that serving static content from the WAB does not activate the WAB when it has a lazy activation policy.
> Validate that the Web-ContextPath manifest header does not match the Context Path of any other currently deployed web application.
> h5. 128.3.4 Publishing the Servlet Context
> The Web Extender must register the Servlet Context of the WAB as a service, using the Bundle Context of the WAB.
> h5. 128.3.5 Static Content
> For confidentiality reasons, a Web Runtime must not return any static content for paths that start with one of the following prefixes:
> WEB-INF/
> OSGI-INF/
> META-INF/
> OSGI-OPT/
> h5. 128.3.8 Stopping the Web Application Bundle
> It is possible that there are one or more colliding WABs because they had the same Context Path as this stopped WAB. If such colliding WABs exists then the Web Extender must attempt to deploy the colliding WAB with the lowest bundle id.
> h5. 128.5 Events
> * org/osgi/service/web/DEPLOYING The Web Extender has accepted a WAB and started the process of deploying a Web Application.
> * org/osgi/service/web/DEPLOYED The Web Extender has finished deploying a Web Application, and the Web Application is now available for web requests on its Context Path.
> * org/osgi/service/web/UNDEPLOYING The web extender started undeploying the Web Application in response to its corresponding WAB being stopped or the Web Extender is stopped.
> * org/osgi/service/web/UNDEPLOYED The Web Extender has undeployed the Web Application. The application is no longer available for web requests.
> * org/osgi/service/web/FAILED The Web Extender has failed to deploy the Web Application, this event can be fired after the DEPLOYING event has fired and indicates that no DEPLOYED event will be fired.
> h5. 128.6.1 Bundle Context Access
> A Servlet can obtain a Bundle Context as follows:
> {code}
> BundleContext ctxt = (BundleContext)
> servletContext.getAttribute(osgi-bundlecontext);
> {code}
> h5. 128.6.3 Resource Lookup
> The getResource and getResourceAsStream methods of the ServletContext interface are used to access resources in the web application. For a WAB, these resources must be found according to the findEntries method, this method includes fragments.
> The getResourcePaths method must map to the Bundle getEntryPaths method, its return type is a Set and can not handle multiples. However, the paths from the getEntryPaths method are relative while the methods of the getResourcePaths must be absolute.
> h5. 128.6.5 JavaServer Pages Support
> The Web Runtime can construct a special class loader to load generated JSP
> classes such that classes from the bundle class path are visible to newly compiled JSP classes.
> This issue is complete when the TCK passes
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (AS7-4932) CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4932?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-4932:
----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
Jitka,
Can you validate that this commit fixes this issue?
https://github.com/pferraro/jboss-eap/commit/f4b710931da30a401cdd2b3aada1...
> CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
> -------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4932
> URL: https://issues.jboss.org/browse/AS7-4932
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP)
>
>
> NPE is thrown in roughly 0.36% of HTTP session request processing in the test.
> This results in response code 503 returned to the client with the exception.
> The test is using passivation-enabled WAR of clusterbench
> https://github.com/rhusar/clusterbench
> Here is a shorter soak test run that uncovered the issue
> https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Clustering-Soak/jo...
> {noformat}
> [JBossINF] 19:52:10,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20/10.16.90.58:8009-2570) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (WFLY-1430) Create clustering subsystem
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1430 at 7/4/13 4:40 PM:
-------------------------------------------------------------------
Implementation of attributes for name=*
{noformat}
[standalone@localhost:9990 /] /subsystem=cluster/name=web:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"rpc-stats" => [
("barney/web" => "unicasts: 6, multicasts: 0, anycasts: 0"),
("lenovo/web" => "unicasts: 8, multicasts: 0, anycasts: 0")
],
"view" => [
("barney/web" => "[barney/web|1] [barney/web, lenovo/web]"),
("lenovo/web" => "[barney/web|1] [barney/web, lenovo/web]")
],
"view-history" => [
("barney/web" => "Thu Jul 04 16:26:18 EDT 2013: [barney/web|0] [barney/web], Thu Jul 04 16:26:25 EDT 2013: [barney/web|1] [barney/web, lenovo/web]
"),
("lenovo/web" => "Thu Jul 04 16:26:25 EDT 2013: [barney/web|1] [barney/web, lenovo/web]
")
],
"deployment" => {
"default-host/distributable" => undefined,
"___defaultcache" => undefined,
"repl" => undefined
}
}
}
{noformat}
The view-history can probably be improved by making the value of the property a LIST, so that the management interface displays it better.
was (Author: rachmato):
Implementation of attributes for name=*
{noformat}
[standalone@localhost:9990 /] /subsystem=cluster/name=web:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"rpc-stats" => [
("barney/web" => "unicasts: 6, multicasts: 0, anycasts: 0"),
("lenovo/web" => "unicasts: 8, multicasts: 0, anycasts: 0")
],
"view" => [
("barney/web" => "[barney/web|1] [barney/web, lenovo/web]"),
("lenovo/web" => "[barney/web|1] [barney/web, lenovo/web]")
],
"view-history" => [
("barney/web" => "Thu Jul 04 16:26:18 EDT 2013: [barney/web|0] [barney/web], Thu Jul 04 16:26:25 EDT 2013: [barney/web|1] [barney/web, lenovo/web]
"),
("lenovo/web" => "Thu Jul 04 16:26:25 EDT 2013: [barney/web|1] [barney/web, lenovo/web]
")
],
"deployment" => {
"default-host/distributable" => undefined,
"___defaultcache" => undefined,
"repl" => undefined
}
}
}
{noformat}
> Create clustering subsystem
> ---------------------------
>
> Key: WFLY-1430
> URL: https://issues.jboss.org/browse/WFLY-1430
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.0.0.Alpha2
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (WFLY-1430) Create clustering subsystem
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1430:
-------------------------------------------
Implementation of attributes for deployment=*
{noformat}
[standalone@localhost:9990 /] /subsystem=cluster/name=web/deployment=default-host\/distributable:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"cache-view" => [
("barney/web" => "[barney/web, lenovo/web]"),
("lenovo/web" => "[barney/web, lenovo/web]")
],
"distribution" => [
("barney/web" => "entries: 0"),
("lenovo/web" => "entries: 0")
],
"operation-stats" => [
("barney/web" => "get hits: 0 get misses: 0, puts 0, remove hits: 0 remove misses: 0"),
("lenovo/web" => "get hits: 0 get misses: 0, puts 0, remove hits: 0 remove misses: 0")
],
"rpc-stats" => [
("barney/web" => "RPC count: 1, RPC misses: 0"),
("lenovo/web" => "RPC count: 2, RPC misses: 0")
],
"txn-stats" => [
("barney/web" => "prepares: 0, commits: 0, rollbacks: 0"),
("lenovo/web" => "prepares: 0, commits: 0, rollbacks: 0")
]
}
}
{noformat}
> Create clustering subsystem
> ---------------------------
>
> Key: WFLY-1430
> URL: https://issues.jboss.org/browse/WFLY-1430
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.0.0.Alpha2
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (WFLY-1430) Create clustering subsystem
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1430:
-------------------------------------------
Implementation of attributes for name=*
{noformat}
[standalone@localhost:9990 /] /subsystem=cluster/name=web:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"rpc-stats" => [
("barney/web" => "unicasts: 6, multicasts: 0, anycasts: 0"),
("lenovo/web" => "unicasts: 8, multicasts: 0, anycasts: 0")
],
"view" => [
("barney/web" => "[barney/web|1] [barney/web, lenovo/web]"),
("lenovo/web" => "[barney/web|1] [barney/web, lenovo/web]")
],
"view-history" => [
("barney/web" => "Thu Jul 04 16:26:18 EDT 2013: [barney/web|0] [barney/web], Thu Jul 04 16:26:25 EDT 2013: [barney/web|1] [barney/web, lenovo/web]
"),
("lenovo/web" => "Thu Jul 04 16:26:25 EDT 2013: [barney/web|1] [barney/web, lenovo/web]
")
],
"deployment" => {
"default-host/distributable" => undefined,
"___defaultcache" => undefined,
"repl" => undefined
}
}
}
{noformat}
> Create clustering subsystem
> ---------------------------
>
> Key: WFLY-1430
> URL: https://issues.jboss.org/browse/WFLY-1430
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.0.0.Alpha2
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (AS7-3343) Concurrency issues in ReferenceCountingEntityCache
by francesco benvadi (JIRA)
[ https://issues.jboss.org/browse/AS7-3343?page=com.atlassian.jira.plugin.s... ]
francesco benvadi updated AS7-3343:
-----------------------------------
Attachment: EJBsrc.zip
Tables.zip
test.ear.zip
> Concurrency issues in ReferenceCountingEntityCache
> --------------------------------------------------
>
> Key: AS7-3343
> URL: https://issues.jboss.org/browse/AS7-3343
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.CR1b
> Reporter: Alexey Makhmutov
> Assignee: Stuart Douglas
> Fix For: 7.1.0.Final
>
> Attachments: cacheProblemTC.zip, EJBsrc.zip, Tables.zip, test.ear.zip
>
>
> While running multithreaded workload against AS 7.1Beta/CR1 for application with Entity EJB 2.x we've faced a lot of following errors:
> * Instance for PK [XXX] already registerd.
> * Instance [YYY] not found in cache
> It seems, that these errors are caused by synchronization issues in ReferenceCountingEntityCache:
> * If two threads are trying to access the cache and there is no ready instance for particular PK in the cache, then both threads are trying to get some instance from the pool and put it into the cache -- as result, the second thread can get 'already registered' exception. We were able to compose a minimal test case application which reproduces this kind of problem (see below).
> * There is a gap in time between the call to Associate interceptor (which puts instance in cache - via 'get' method) and Synchronization interceptor (which calls 'reference' method). During this time instance is not referenced, so it seems it can be removed by some other thread which finish its invocation at the same time. Probably this is the root cause of 'not found in cache' error, however it's hard to create a syntetic test case for it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (AS7-3343) Concurrency issues in ReferenceCountingEntityCache
by francesco benvadi (JIRA)
[ https://issues.jboss.org/browse/AS7-3343?page=com.atlassian.jira.plugin.s... ]
francesco benvadi commented on AS7-3343:
----------------------------------------
Hi All,
I believe I found a simple way to get the issue. I ot the error every time I execute the jsp in the attached ear.
To get the error create the 2 tables in Tables.zip
Deploy in a server EAP 6.1.0 and launch the AddFatherSimple.jsp.
You'll get immediately the error.
Attached you can also find the ejb 2.1 involved in the test case
Hope this helps to fix the issue
Best Regards
Francesco Benvadi
> Concurrency issues in ReferenceCountingEntityCache
> --------------------------------------------------
>
> Key: AS7-3343
> URL: https://issues.jboss.org/browse/AS7-3343
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.CR1b
> Reporter: Alexey Makhmutov
> Assignee: Stuart Douglas
> Fix For: 7.1.0.Final
>
> Attachments: cacheProblemTC.zip
>
>
> While running multithreaded workload against AS 7.1Beta/CR1 for application with Entity EJB 2.x we've faced a lot of following errors:
> * Instance for PK [XXX] already registerd.
> * Instance [YYY] not found in cache
> It seems, that these errors are caused by synchronization issues in ReferenceCountingEntityCache:
> * If two threads are trying to access the cache and there is no ready instance for particular PK in the cache, then both threads are trying to get some instance from the pool and put it into the cache -- as result, the second thread can get 'already registered' exception. We were able to compose a minimal test case application which reproduces this kind of problem (see below).
> * There is a gap in time between the call to Associate interceptor (which puts instance in cache - via 'get' method) and Synchronization interceptor (which calls 'reference' method). During this time instance is not referenced, so it seems it can be removed by some other thread which finish its invocation at the same time. Probably this is the root cause of 'not found in cache' error, however it's hard to create a syntetic test case for it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (WFLY-557) Complete support for Bundle update
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-557?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler reopened WFLY-557:
---------------------------------
Assignee: (was: Thomas Diesler)
> Complete support for Bundle update
> ----------------------------------
>
> Key: WFLY-557
> URL: https://issues.jboss.org/browse/WFLY-557
> Project: WildFly
> Issue Type: Sub-task
> Components: OSGi, Server
> Reporter: Thomas Diesler
>
> A Bundle can have multiple revisions. A call to Bundle.update(…) creates a new revision. There is only ever one current revision (the latest update) associated with a Bundle. Stale revisions continue to exist in the runtime until an explicit refresh of the transitive dependency graph.
> Approach #1 - bundle revisions are represented as individual deployments
> Each bundle update deploys the revision as a new deployment
> The association of revisions to bundle happens in the OSGi layer only
> Management sees disconnected deployments with no notion of stale/current or belonging together
> Approach #2 - deployment API supports the notion of multiple revisions
> deployments, their revisions and respective mapping would be modelled more closely on OSGi requirements
> some deployment types might not support revisions
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years