[JBoss JIRA] Created: (JBAS-3426) Fix org.jboss.test.jacc.test.WebIntegrationUnitTestCase in HEAD
by Anil Saldhana (JIRA)
Fix org.jboss.test.jacc.test.WebIntegrationUnitTestCase in HEAD
---------------------------------------------------------------
Key: JBAS-3426
URL: http://jira.jboss.com/jira/browse/JBAS-3426
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security, Web (Tomcat) service
Environment: org.jboss.test.jacc.test.WebIntegrationUnitTestCase(JACC)
as well as org.jboss.test.jacc.test.WebIntegrationUnitTestCase
Reporter: Anil Saldhana
Assigned To: Scott M Stark
Fix For: JBossAS-5.0.0.Beta
There is privileges related exception that is showing up in HEAD whereas in Branch_4_0, does not show up.
=======================================================================================
10:37:07,843 INFO [ENCServlet] InitialContext.env:
10:37:07,843 INFO [ENCServlet] Key: java.naming.factory.initial, value: org.jnp.interfaces.NamingContextFactory
10:37:07,843 INFO [ENCServlet] Key: java.naming.factory.url.pkgs, value: org.jboss.naming:org.jnp.interfaces:org.jboss.naming:org.jnp.interfaces
10:37:07,890 ERROR [[invoker]] Allocate exception for servlet invoker
java.lang.SecurityException: Servlet of class org.apache.catalina.servlets.Invok
erServlet is privileged and cannot be loaded by this web application
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.
java:1114)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:784)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:174)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
=========================================================================================
Something changed in TC6 as to how web apps can invoke the container servlets?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Created: (JBAS-4314) A deadlock condition in DistributedReplicantManagerImpl
by Bernd Köcke (JIRA)
A deadlock condition in DistributedReplicantManagerImpl
-------------------------------------------------------
Key: JBAS-4314
URL: http://jira.jboss.com/jira/browse/JBAS-4314
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: JBossAS-4.0.2 Final
Environment: Linux 2.6.x, Sun-JVM 1.5.0_11-b03, 1.6.0-b105, JBoss 4.0.2.final.
Reporter: Bernd Köcke
Assigned To: Brian Stansberry
While working on JBAS-4313 I found a deadlock condition in DistributedReplicantManagerImpl. All methods are using the lock order localReplicants -> replicants. But method purgeDeadMembers uses replicants -> localReplicants. To solve the problem I moved the notifyKeyListeners out of the synchronized(replicants)-block.
Newer versions of JBoss are using maps from the concurrent-package and not the normal java.util.HashMap. Maybe this solves the problem, too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Created: (JBAOP-347) ClassCastException in MarshalledValue.java
by Tim McCune (JIRA)
ClassCastException in MarshalledValue.java
------------------------------------------
Key: JBAOP-347
URL: http://jira.jboss.com/jira/browse/JBAOP-347
Project: JBoss AOP
Issue Type: Patch
Security Level: Public (Everyone can see)
Affects Versions: 1.5.3.GA
Environment: JBoss 4.0.4, Whatever version of JBossAOP is bundled in with JBoss EJB 3.0-RC9-FD, JDK 1.6
Reporter: Tim McCune
I tried enabling JBoss serialization with EJB 3 remoting for the first time today, by changing the line
<attribute name="InvokerLocator">socket://${jboss.bind.address}:3873</attribute>
to
<attribute name="InvokerLocator">socket://${jboss.bind.address}:3873/?serializationtype=jboss</attribute>
in ejb3.deployer/META-INF/jboss-service.xml. When I do this, any remote call to my EJB results in the following exception on the client:
java.lang.ClassCastException: org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput
at org.jboss.aop.util.MarshalledValue.writeExternal(MarshalledValue.java:190)
at org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:202)
at org.jboss.aop.metadata.SimpleMetaData.writeExternal(SimpleMetaData.java:226)
at org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:202)
at org.jboss.aop.joinpoint.MethodInvocation.writeExternal(MethodInvocation.java:321)
at org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:202)
at org.jboss.serial.persister.RegularObjectPersister.writeSlotWithFields(RegularObjectPersister.java:182)
at org.jboss.serial.persister.RegularObjectPersister.defaultWrite(RegularObjectPersister.java:90)
at org.jboss.serial.persister.RegularObjectPersister.writeData(RegularObjectPersister.java:62)
at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)
at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:202)
at org.jboss.serial.io.JBossObjectOutputStream.writeObjectOverride(JBossObjectOutputStream.java:181)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298)
at org.jboss.remoting.serialization.impl.jboss.JBossSerializationManager.sendObject(JBossSerializationManager.java:87)
at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:84)
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:273)
at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
at org.jboss.remoting.Client.invoke(Client.java:525)
at org.jboss.remoting.Client.invoke(Client.java:488)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.remoting.ClusterChooserInterceptor.invoke(ClusterChooserInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessClusteredProxy.invoke(StatelessClusteredProxy.java:100)
...
Looking at the code for MarshalledValue.java in the writeExternal method, the following line casts the ObjectOutput parameter to an OutputStream in order to take advantage of ByteArrayOutputStream's writeTo method:
baos.writeTo((OutputStream)out);
However, the assumption that the "out" parameter may be cast to an OutputStream in not a valid one. When using jboss serialization instead of java serialization, the "out" parameter that is passed in is of type org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput, which implements ObjectOutput, but does not extends OutputStream. A simple fix is to change the line above to:
out.write(baos.toByteArray());
I don't know if the writeTo method gives noticeably better performance. If it does, it might be worth it to do an instanceof check first.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Created: (JBMICROCONT-158) Non-existent manifest Class-Path refs produce vfs IllegalStateException
by Scott M Stark (JIRA)
Non-existent manifest Class-Path refs produce vfs IllegalStateException
-----------------------------------------------------------------------
Key: JBMICROCONT-158
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-158
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Affects Versions: JBossMC_2_0_0 Beta3
Reporter: Scott M Stark
Assigned To: Scott M Stark
When the structure deployers parse a top-level jboss-test-entity.jar with a manifest like:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_09-b01 (Sun Microsystems Inc.)
Class-Path: ejb.jar jnp-client.jar jboss-client.jar jndi.jar jboss-jmx
.jar junit.jar deploy.jar
it fails with:
Caused by: java.lang.IllegalStateException: JarHandler@28271403[path= context=file:/C:/home/svn/JBossHead/jboss-head/testsuite/output/lib/jboss-test-entity.jar
real=file:/C:/home/svn/JBossHead/jboss-head/testsuite/output/lib/jboss-test-entity.jar] has no parent.
at org.jboss.virtual.VFSUtils.addManifestLocations(VFSUtils.java:116)
at org.jboss.deployers.plugins.structure.DefaultStructureBuilder.processContext(DefaultStructureBuilder.java:131)
at org.jboss.deployers.plugins.structure.DefaultStructureBuilder.populateContext(DefaultStructureBuilder.java:89)
The invalid references should at most produce debug level warnings.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month