[JBoss JIRA] (AS7-3330) Allow configuring the EJB subsystem for disabling pass by value semantics for invocations on remote interfaces of beans
by jaikiran pai (JIRA)
jaikiran pai created AS7-3330:
---------------------------------
Summary: Allow configuring the EJB subsystem for disabling pass by value semantics for invocations on remote interfaces of beans
Key: AS7-3330
URL: https://issues.jboss.org/browse/AS7-3330
Project: Application Server 7
Issue Type: Enhancement
Components: EJB
Reporter: jaikiran pai
Assignee: jaikiran pai
Fix For: 7.1.0.Final
The EJB3 spec mandates that the params passed to beans during invocation on a remote interface of the bean, be treated with pass-by-value semantics. Currently we do allow individual applications to override this semantic by setting a per application level configuration which then uses pass-by-reference semantics for in-VM calls on the remote interfaces of the bean. The current setting is allowed in a jboss-ejb-client.xml of the application as follows:
{code}
<jboss-ejb-client xmlns="urn:jboss:ejb-client:1.0">
<client-context>
<ejb-receivers local-receiver-pass-by-value="false"/>
</client-context>
</jboss-ejb-client>
{code}
We should allow configuring this semantic at the EJB3 subsystem level so that it can be applicable to all EJB applications (unless overridden by the application) deployed on the server.
--
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-2611) Intermittent failures in CMP tests
by Stuart Douglas (Created) (JIRA)
Intermittent failures in CMP tests
----------------------------------
Key: AS7-2611
URL: https://issues.jboss.org/browse/AS7-2611
Project: Application Server 7
Issue Type: Bug
Components: EJB
Reporter: Stuart Douglas
Assignee: John Bailey
I am seeing what looks like a race condition in the CMP tests.
It appears that this may be caused by org.jboss.as.cmp.ejbql.Catalog not being synchronized, and if multiple org.jboss.as.cmp.jdbc.JdbcStoreManagerInitService start concurrently concurrent access may result. Not sure if this is the correct diagnosis though.
20:16:12,652 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-12) MSC00001: Failed to start service jboss.deployment.unit."cmp-relationship.jar".component.A_OneToMany_Uni_Table_EJB.jdbc.store-manager.RELATIONS: org.jboss.msc.service.StartException in service jboss.deployment.unit."cmp-relationship.jar".component.A_OneToMany_Uni_Table_EJB.jdbc.store-manager.RELATIONS: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1780) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_29]
Caused by: java.lang.RuntimeException: Related entity not found: entity=A_OneToMany_Uni_Table_EJB, cmrField=b, relatedEntity=B_OneToMany_Uni_Table_EJB
at org.jboss.as.cmp.jdbc.bridge.JDBCCMRFieldBridge.resolveRelationship(JDBCCMRFieldBridge.java:228)
at org.jboss.as.cmp.jdbc.bridge.JDBCEntityBridge.resolveRelationships(JDBCEntityBridge.java:257)
at org.jboss.as.cmp.jdbc.JDBCStoreManager.resolveRelationships(JDBCStoreManager.java:241)
at org.jboss.as.cmp.jdbc.JdbcStoreManagerRelationshipsService.start(JdbcStoreManagerRelationshipsService.java:41)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
... 3 more
--
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-2758) Changes host interface to any_address fails to bring up domain
by Heiko Braun (Created) (JIRA)
Changes host interface to any_address fails to bring up domain
--------------------------------------------------------------
Key: AS7-2758
URL: https://issues.jboss.org/browse/AS7-2758
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
Fix For: 7.1.0.CR1
{noformat}
[Server:server-one] 15:26:27,285 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.host.controller.channel: org.jboss.msc.service.StartException in service jboss.host.controller.channel: Failed to start service
[Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1780) [jboss-msc-1.0.1.GA.jar:]
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
[Server:server-one] at java.lang.Thread.run(Thread.java:680) [:1.6.0_29]
[Server:server-one] Caused by: java.lang.IllegalArgumentException: destination address may not be null
[Server:server-one] at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:92) [jboss-remoting-3.2.0.CR3.jar:]
[Server:server-one] at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:264) [jboss-remoting-3.2.0.CR3.jar:]
[Server:server-one] at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:246) [jboss-remoting-3.2.0.CR3.jar:]
[Server:server-one] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:353) [jboss-remoting-3.2.0.CR3.jar:]
[Server:server-one] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337) [jboss-remoting-3.2.0.CR3.jar:]
[Server:server-one] at org.jboss.as.protocol.ProtocolChannelClient.connect(ProtocolChannelClient.java:133) [jboss-as-protocol-7.1.0.CR1-SNAPSHOT.jar:]
[Server:server-one] at org.jboss.as.protocol.ProtocolChannelClient.connect(ProtocolChannelClient.java:108) [jboss-as-protocol-7.1.0.CR1-SNAPSHOT.jar:]
[Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:109) [jboss-as-server-7.1.0.CR1-SNAPSHOT.jar:]
{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
14 years, 2 months
[JBoss JIRA] (AS7-2493) Member names are not uniquely generated: Found member perf17/web in current view that duplicates us (perf17/web)
by Radoslav Husar (Created) (JIRA)
Member names are not uniquely generated: Found member perf17/web in current view that duplicates us (perf17/web)
----------------------------------------------------------------------------------------------------------------
Key: AS7-2493
URL: https://issues.jboss.org/browse/AS7-2493
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: No Release
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Priority: Blocker
Fix For: 7.1.0.Beta1
# If 2 servers are started on the same node
# and clustered application is deployed
# clustering fails with "Caused by: java.lang.IllegalStateException: JBAS010281: Found member perf17/web in current view that duplicates us (perf17/web). This node cannot join partition until duplicate member has been removed"
{code}
08:57:21,063 INFO [stdout] (MSC service thread 1-11)
08:57:21,063 INFO [stdout] (MSC service thread 1-11) -------------------------------------------------------------------
08:57:21,063 INFO [stdout] (MSC service thread 1-11) GMS: address=perf17/web, cluster=web, physical address=10.16.90.52:55200
08:57:21,063 INFO [stdout] (MSC service thread 1-11) -------------------------------------------------------------------
08:57:21,471 WARN [org.infinispan.config.ConfigurationValidatingVisitor] (MSC service thread 1-3) ISPN000152: Passivation configured without a valid eviction policy. This could mean that the cache store will never get used unless code calls Cache.evict() manually.
08:57:21,599 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups Channel
08:57:21,604 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000094: Received new cluster view: [perf17/web|1] [perf17/web, perf17/web]
08:57:21,605 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000079: Cache local address is perf17/web, physical addresses are [10.16.90.52:55200]
08:57:21,609 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0.BETA2
08:57:21,609 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0.BETA2
08:57:21,719 INFO [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-3) ISPN000031: MBeans were successfully registered to the platform mbean server.
08:57:21,860 INFO [org.jboss.as.clustering] (MSC service thread 1-3) JBAS010301: Started repl cache from web container
08:57:21,900 INFO [org.jboss.as.clustering.CoreGroupCommunicationService.web] (MSC service thread 1-3) JBAS010207: Number of cluster members: 2
08:57:21,902 WARN [org.jboss.as.web.deployment.JBossContextConfig] (MSC service thread 1-3) Clustering not supported, falling back to non-clustered session manager.: java.lang.IllegalStateException: JBAS010330: Unexpected exception while starting group communication service for web
at org.jboss.as.clustering.web.infinispan.DefaultLockManagerSource$LockManagerEntry.<init>(DefaultLockManagerSource.java:107)
at org.jboss.as.clustering.web.infinispan.DefaultLockManagerSource.getLockManager(DefaultLockManagerSource.java:74)
at org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory.getDistributedCacheManager(DistributedCacheManagerFactory.java:95)
at org.jboss.as.web.session.DistributableSessionManager.<init>(DistributableSessionManager.java:176) [jboss-as-web-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.as.web.session.DistributableSessionManager.<init>(DistributableSessionManager.java:144) [jboss-as-web-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.as.web.deployment.JBossContextConfig.processWebMetaData(JBossContextConfig.java:280) [jboss-as-web-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.as.web.deployment.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:164) [jboss-as-web-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:417) [jbossweb-7.0.3.Final.jar:7.1.0.Alpha2-SNAPSHOT]
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [jbossweb-7.0.3.Final.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.as.web.deployment.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:157) [jboss-as-web-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.3.Final.jar:7.1.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3790) [jbossweb-7.0.3.Final.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:77) [jboss-as-web-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
Caused by: java.lang.IllegalStateException: JBAS010281: Found member perf17/web in current view that duplicates us (perf17/web). This node cannot join partition until duplicate member has been removed
at org.jboss.as.clustering.CoreGroupCommunicationService.verifyNodeIsUnique(CoreGroupCommunicationService.java:1197)
at org.jboss.as.clustering.CoreGroupCommunicationService.startService(CoreGroupCommunicationService.java:915)
at org.jboss.as.clustering.CoreGroupCommunicationService.start(CoreGroupCommunicationService.java:805)
at org.jboss.as.clustering.web.infinispan.DefaultLockManagerSource$LockManagerEntry.<init>(DefaultLockManagerSource.java:105)
... 17 more
08:57:21,982 INFO [org.jboss.web] (MSC service thread 1-3) registering web context: /clusterbench-web
08:57:22,032 INFO [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "clusterbench-ear-1.0.0-SNAPSHOT.ear"
{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
[JBoss JIRA] (AS7-2877) Removing a connector does not wait for wait for requests to finish
by Radoslav Husar (Created) (JIRA)
Removing a connector does not wait for wait for requests to finish
------------------------------------------------------------------
Key: AS7-2877
URL: https://issues.jboss.org/browse/AS7-2877
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.1.0.Beta1
Reporter: Radoslav Husar
Assignee: Remy Maucherat
When you remove a AJP connector current requests end up with NullPointerException.
If the quiesce requirement has been dropped for 7.1 then please reschedule to open to community.
{code}
[JBossINF] 09:47:47,140 INFO [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-16) Pausing Coyote AJP/1.3 on ajp-perf20-10.16.90.58-8009
[JBossINF] 09:47:47,140 INFO [org.apache.coyote.ajp.AjpProtocol] (MSC service thread 1-16) Stopping Coyote AJP/1.3 on ajp-perf20-10.16.90.58-8009
[JBossINF] 09:47:47,144 ERROR [org.apache.catalina.connector.CoyoteAdapter] (ajp-perf20-10.16.90.58-8009-431) An exception or error occurred in the container during the request processing: java.lang.NullPointerException
[JBossINF] at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:524) [jbossweb-7.0.4.Final.jar:]
[JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:359) [jbossweb-7.0.4.Final.jar:]
[JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.4.Final.jar:]
[JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.4.Final.jar:]
[JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.4.Final.jar:]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
{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
[JBoss JIRA] (AS7-3282) HTTP Basic authentication fails due to changed JBossWebRealm defaults (AS6->AS7)
by Robert Reimann (JIRA)
Robert Reimann created AS7-3282:
-----------------------------------
Summary: HTTP Basic authentication fails due to changed JBossWebRealm defaults (AS6->AS7)
Key: AS7-3282
URL: https://issues.jboss.org/browse/AS7-3282
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.1.0.CR1b
Reporter: Robert Reimann
Assignee: Remy Maucherat
The change of the JBossWebRealm allRolesMode property from authOnly to strict leads to HTTP Basic authentication failures. Accessing HTTP Basic protected resources always returns a 403 forbidden response when using the security-constraint configuration below which worked well under (JBoss AS4 and AS6).
The security-constraint inside the web.xml is defined as follws:
{code}
<security-constraint>
<web-resource-collection>
<web-resource-name>protected resources</web-resource-name>
<url-pattern>/protected/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<description>any rolle allowed</description>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>
{code}
Activating trace logging revealed the following message:
{code}
13:35:59,019 TRACE [org.jboss.as.web.security.JBossWebRealm] (http-localhost-127.0.0.1-8080-1) hasRole:RealmBase says:false::Authz framework says:true:final=false
{code}
In AS6 the meaning of <role-name>*</role-name> was determined by the allRolesMode property of the JBossWebRealm which was configured in jbossweb.sar/server.xml and set to authOnly (= Allow any authenticated user) by default.
In AS7 the default of allRolesMode seems to be strict (= Use the strict servlet spec interpretation which requires that the user have one of the web-app/security-role/role-name).
The workaround to add all security-rolles in the web.xml described in one of the forum references (https://community.jboss.org/message/617196#617196) is no viable option for applications with a large number of dynamically changing roles.
So please provide a configuration option for the allRolesMode property to allow for changes of the default behavior and ease the migration from earlier JBoss AS versions.
--
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