[JBoss JIRA] (AS7-4490) max-active-sessions doesn't force min-idle sessions to passivate resulting in IllegalStateException
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4490:
-----------------------------------
Summary: max-active-sessions doesn't force min-idle sessions to passivate resulting in IllegalStateException
Key: AS7-4490
URL: https://issues.jboss.org/browse/AS7-4490
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: Paul Ferraro
When a new session is to be created but number of sessions already reached max-active-sessions, the sessions that are beyond min-idle are not forced to passivate.
{noformat}
<system-out>19:20:59,397 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/passivating].[org.jboss.as.test.clustering.single.web.SimpleServlet]] (http--127.0.0.1-8080-3) Servlet.service() for servlet org.jboss.as.test.clustering.single.web.SimpleServlet threw exception: java.lang.IllegalStateException: JBAS018075: Number of active sessions exceeds limit 20 trying to create session
at org.jboss.as.web.session.DistributableSessionManager.createSessionInternal(DistributableSessionManager.java:594) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager.createSession(DistributableSessionManager.java:559) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.apache.catalina.connector.Request.doGetSession(Request.java:2665) [jbossweb-7.0.14.Final.jar:]
at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.14.Final.jar:]
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.14.Final.jar:]
at org.jboss.as.test.clustering.single.web.SimpleServlet.doGet(SimpleServlet.java:47) [classes:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.14.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.14.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.14.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.14.Final.jar:]
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:67)
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:48)
at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:125) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.14.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.14.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.14.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.14.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.14.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.14.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.14.Final.jar:]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
{noformat}
--
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
13 years, 9 months
[JBoss JIRA] (AS7-4240) NameNotFoundException thrown when trying to read java:*/env context in Servlet container.
by Robert Edgecombe (JIRA)
Robert Edgecombe created AS7-4240:
-------------------------------------
Summary: NameNotFoundException thrown when trying to read java:*/env context in Servlet container.
Key: AS7-4240
URL: https://issues.jboss.org/browse/AS7-4240
Project: Application Server 7
Issue Type: Bug
Components: Naming
Affects Versions: 7.1.1.Final
Environment: Windows7 Enterprise x64
Intel Core 2 Duo
Oracle Java jdk1.6.0_29
Reporter: Robert Edgecombe
Assignee: John Bailey
We have many J2EE 1.4 apps that need to be migrated from Oracle Application Server
These applications rely on configuration using Environment Entries
Most of the answers to issues I have read indicate that this is done using jboss-web.xml but this is not an acceptable solutin as it requires repackaging of the deployment artifact for different servers and different environments and is therefor contrary to the spirit (and I believe the letter) of the JavaEE spec.
The documentation on this capability is either hidden or missing.
I was tasked with working out how to use the JBOSS tools to configure these values and have been unable to do so.
I modified the quickstart helloworld example to accept a value using the @Resource annotation and attempted to set this value using jboss-cli.
After several attempts to guess how to do this I modified the servlet to walk down the context tree.
This servlet throws a NameNotFoundException when trying to list the bindings at:
* java:comp/env
* java:app/env
* java:module/env
I have written the servlet to perform this walk in the following contexts:
* Ithe initial context
* java:
* java:jboss
* java:comp
* java:module
* java:app
* java:global
java:global seems to be able to accept values added using jboss-cli (not surprising)
java:comp, java:module and java:app seem to return some of the expected values (eg ModuleName and AppName) but throw the exception when trying to list entries under */env
The initial context and java: seem to display the entries added through jboss-cli
Adding a Deployment descriptor (web.xml), that provides values for these entries, results in no entries that are visible through jboss-cli or any of the contexts listed in the servlet.
I then ran the following command through jboss-cli and restarted the app
/profile=full/subsystem=naming/binding=\/java\:app\/jboss-as-helloworld-ear\/env\/GREETING_TEXT:add(binding-type="simple",value="RE")
This resulted in the same NameNotFoundException being thrown at java:app/env when walking the initial context as has been thrown all along when listing env in java:app
It also resulted in java:app appearing in the java: context but being empty.
Prior to running the add command, java:app did not appear in the initial context or java: context at all.
I then ran the following command through jboss-cli and restarted the app
/profile=full/subsystem=naming/binding=\/java\:module\/jboss-as-helloworld-ear\/jboss-as-helloworld\/env\/GREETING_TEXT:add(binding-type="simple",value="SJM")
This resulted in the same NameNotFoundException being thrown at java:module/env when walking the initial context as has been thrown all along when listing env in java:module
It also resulted in java:module appearing in the java: context but being empty.
Prior to running the add command, java:module did not appear in the initial context or java: context at all.
My conclusion is that my commands in jboss-cli may be the appropriate ones to add the correct entries but that the servlet cannot reach the java:module/env or java:app/env contexts that should be available to it according to the javaEE6 spec.
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5471) inbound RAR inside EAR: cannot redeploy
by Marcel Šebek (JIRA)
Marcel Šebek created AS7-5471:
---------------------------------
Summary: inbound RAR inside EAR: cannot redeploy
Key: AS7-5471
URL: https://issues.jboss.org/browse/AS7-5471
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
Reporter: Marcel Šebek
Assignee: Jesper Pedersen
There is a regression somewhere after 7.1.1.Final release regarding inbound resource adapters inside EAR. Previously, it was possible to redeploy EAR containing inbound RAR. Now, only the first attempt succeeds, and the subsequent deployments fail. It is reproducible in both latest git master snapshot, and in some older (about a month) snapshot of 7.1.3 branch. I have tested the issue using a very simple EAR containing a trivial inbound RAR, EJB-JAR with a MDB consuming messages from RAR, and a library JAR with listener interface (sources and binaries attached).
Here is the relevant part of server log:
{{
14:52:49,934 INFO [org.jboss.as.repository] (HttpManagementService-threads - 2) JBAS014900: Content added at location /home/marcel/compile/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/data/content/72/40a822f9ee326844575078a21f942890414c2b/content
14:53:01,460 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "test-ear.ear"
14:53:01,557 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "test-ejb-2.0.0-SNAPSHOT.jar"
14:53:01,557 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "test-rar-2.0.0-SNAPSHOT.rar"
14:53:02,015 INFO [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-2) IJ020002: Deployed: file:/home/marcel/compile/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/tmp/vfs/deploymentcae5cd1d0b6a9fb7/test-rar-2.0.0-SNAPSHOT.rar-ca312609764d3645/contents/
14:53:02,137 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) JBAS014142: Started message driven bean 'InboundMDB' with 'test-ear.ear#test-rar-2.0.0-SNAPSHOT' resource adapter
14:53:02,188 INFO [org.hibernate.validator.util.Version] (ServerService Thread Pool -- 64) Hibernate Validator 4.2.0.Final
14:53:02,381 INFO [org.jboss.as.server] (HttpManagementService-threads - 2) JBAS018559: Deployed "test-ear.ear"
14:53:06,898 INFO [stdout] (MSC service thread 1-4) TestRA stopped
14:53:06,923 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment test-ejb-2.0.0-SNAPSHOT.jar in 39ms
14:53:06,925 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment test-rar-2.0.0-SNAPSHOT.rar in 40ms
14:53:06,926 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment test-ear.ear in 42ms
14:53:06,997 INFO [org.jboss.as.server] (HttpManagementService-threads - 2) JBAS018558: Undeployed "test-ear.ear"
14:53:11,789 INFO [org.jboss.as.repository] (HttpManagementService-threads - 2) JBAS014901: Content removed from location /home/marcel/compile/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/data/content/72/40a822f9ee326844575078a21f942890414c2b/content
14:53:19,937 INFO [org.jboss.as.repository] (HttpManagementService-threads - 2) JBAS014900: Content added at location /home/marcel/compile/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/data/content/72/40a822f9ee326844575078a21f942890414c2b/content
14:53:25,438 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "test-ear.ear"
14:53:25,447 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "test-ejb-2.0.0-SNAPSHOT.jar"
14:53:25,447 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "test-rar-2.0.0-SNAPSHOT.rar"
14:53:25,604 INFO [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-2) IJ020002: Deployed: file:/home/marcel/compile/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/tmp/vfs/deploymentcae5cd1d0b6a9fb7/test-rar-2.0.0-SNAPSHOT.rar-26147c352a452c34/contents/
14:53:25,815 INFO [org.jboss.as.server] (HttpManagementService-threads - 2) JBAS015870: Deploy of deployment "test-ear.ear" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".moduleDeploymentRuntimeInformation Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.ejb3.timerService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.TimedObjectInvoker Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.VIEW.\"test.TestEventListener\".MESSAGE_ENDPOINT Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"test-ear.ear\".deploymentCompleteService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.START Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".deploymentCompleteService Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.subunit.\"test-ear.ear\".\"test-ejb-2.0.0-SNAPSHOT.jar\".component.InboundMDB.CREATE Missing[jboss.ra.\"test-ear.ear#test-rar-2.0.0-SNAPSHOT\"]"]}
14:53:25,823 INFO [stdout] (MSC service thread 1-3) TestRA stopped
14:53:25,861 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment test-ejb-2.0.0-SNAPSHOT.jar in 45ms
14:53:25,862 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment test-rar-2.0.0-SNAPSHOT.rar in 45ms
14:53:25,864 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment test-ear.ear in 48ms
}}
--
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, 9 months
[JBoss JIRA] (AS7-5581) Do not ignore security annotations and deployment descriptor configurations on EJBs in the absence of explicit security domain configuration
by jaikiran pai (JIRA)
jaikiran pai created AS7-5581:
---------------------------------
Summary: Do not ignore security annotations and deployment descriptor configurations on EJBs in the absence of explicit security domain configuration
Key: AS7-5581
URL: https://issues.jboss.org/browse/AS7-5581
Project: Application Server 7
Issue Type: Feature Request
Components: EJB
Affects Versions: 7.1.2.Final (EAP)
Reporter: jaikiran pai
Assignee: jaikiran pai
Fix For: 7.2.0.Alpha1
Consider the following example:
{code}
@Stateless
public class SecureBean
{
@RolesAllowed("role1")
public void restrictedRoles()
{
...
}
@DenyAll
public void denyEveryone()
{
...
}
}
{code}
Notice that the bean methods use EJB security annotations to restrict access *however* the bean doesn't have any explicit @SecurityDomain configured (not even in jboss-ejb3.xml). Right now, AS7 ignores the security restriction on that bean allows everyone to invoke on it, as if security wasn't configured for that bean. This has confused users who expect the invocations to fail since they have used the javax.ejb.* security annotations to restrict access. Many users have asked for a feature where the security domain is defaulted (if not explicitly specified) in cases like this.
This JIRA is expected to introduce this feature in AS 7.2.x
--
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, 9 months
[JBoss JIRA] (AS7-5172) cannot define service activator in WAR META-INF, must be in WAR WEB-INF/classes/META-INF
by John Mazzitelli (JIRA)
John Mazzitelli created AS7-5172:
------------------------------------
Summary: cannot define service activator in WAR META-INF, must be in WAR WEB-INF/classes/META-INF
Key: AS7-5172
URL: https://issues.jboss.org/browse/AS7-5172
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.1.Final
Reporter: John Mazzitelli
Priority: Minor
(note: I talked to dmlloyed on this in #jboss-as7 - he thinks its a bug, hence why I am filing this JIRA)
I have a WAR. I want it to have a service activator in it (I want it to install an MSC service). So, in the WAR's META-INF directory, I create a "services/org.jboss.msc.service.ServiceActivator" file with the appropriate content.
The service fails to activate.
However, if I put that same META-INF content in my WAR's WEB-INF/classes directory (that is, my WAR has a WEB-INF/classes/META-INF/services/org.jboss.msc.service.ServiceActivator), my service activates fine.
I will attach a .war file that you can use to test this. To see what I'm taking about, take the attached war and explode it inside the standalone/deployments directory in AS 7.1.1.Final. Run the app server - you will see in the output this:
INFO [stdout] (MSC service thread 1-5) $$$$$$$$$$$$$$$$ SERVICE ACTIVATING!
(this output comes from my ServiceActivator's activate() method - it does a System.out.println as soon as activate() is entered).
This shows the WEB-INF/classes/META-INF/services being honored. Now shutdown the app server, cd to the deployments directory and cd down into the exploded war directory. Now move that services/ content directly up to the WAR's own META-INF directory:
mv WEB-INF/classes/META-INF/services META-INF/
Now run the app server again. Notice you do NOT see the "SERVICE ACTIVATING" message.
So it appears the WAR's META-INF/services is ignored when looking for service activators, but when the same services marker file is in WEB-INF/classes/META-INF/services, it works fine.
--
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
13 years, 9 months