[JBoss-dev] jboss-head Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-head?log=log20050531040607 BUILD FAILEDAnt Error Message:/home/cruisecontrol/work/scripts/build-jboss-head.xml:63: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-jboss-head.xml:37: Exit code: 1 See compile.log in Build Artifacts for details. JAVA_HOME=/opt/j2sdk1.4.2_05/Date of build:05/31/2005 04:06:07Time to build:13 minutes 0 secondsLast changed:05/31/2005 03:53:02Last log entry:Added DistributedState impl using TreeCache, contributed by a user Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(6)1.1addedbwangcluster/src/main/org/jboss/ha/framework/server/ClusterPartitionTreeCache.javaAdded DistributedState impl using TreeCache, contributed by a user1.1addedbwangcluster/src/main/org/jboss/ha/framework/server/ClusterPartitionTreeCacheMBean.javaAdded DistributedState impl using TreeCache, contributed by a user1.1addedbwangcluster/src/main/org/jboss/ha/framework/server/DistributedStateTreeCacheImpl.javaAdded DistributedState impl using TreeCache, contributed by a user1.1addedbwangcluster/src/main/org/jboss/ha/framework/server/DistributedStateTreeCacheImplMBean.javaAdded DistributedState impl using TreeCache, contributed by a user1.1addedbwangcluster/src/main/org/jboss/ha/framework/server/HAPartitionTreeCacheImpl.javaAdded DistributedState impl using TreeCache, contributed by a user1.61modifiedbwangcluster/build.xmlAdded JBossCache class path
Re: [JBoss-dev] NonSerializableFactory doesn't seem usable with java:comp
If you do that, I'll bet you'll cause memory leaks due to NonSerializableFactory - context - object - class - undeployed classloader because some places aren't getting tidied correctly. I put a TODO in the WebDeployer, because it never gets tidied up (it is left to garbage collection) See AbstractWebDeployer.parseWebAppDescriptors() On Tue, 2005-05-31 at 19:58, Bill Burke wrote: I guess what Im saying is, shouldn't NSF be keyed on Context instance and base String name? Bill Burke wrote: I'm finding that I want to bind a non-serializable into java:comp/EntityManager. The problem is that NonSerializableFactory keys on the Name.toString() not on any other type of key so this is not viable for things put in java:comp with the same name across EJBs/servlets. -- Adrian Brock Chief Scientist JBoss Inc. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] NonSerializableFactory doesn't seem usable withjava:comp
Alternate bindENC/rebindENC could be added that uses a custom RefAddr to key the bindings to the context and relative binding using a different reference address type such as enc. All of the java:comp/env contexts are lazily cleaned up as there is no standard api for removing content from the java:comp ObjectFactory binding. The ENCFactory would have to be used directly to remove the bindings. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Tuesday, May 31, 2005 5:44 PM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] NonSerializableFactory doesn't seem usable withjava:comp If you do that, I'll bet you'll cause memory leaks due to NonSerializableFactory - context - object - class - undeployed classloader because some places aren't getting tidied correctly. I put a TODO in the WebDeployer, because it never gets tidied up (it is left to garbage collection) See AbstractWebDeployer.parseWebAppDescriptors() --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-4.0-testsuite Build Failed
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite?log=log20050531201143 BUILD FAILEDAnt Error Message:/home/cruisecontrol/work/scripts/build-jboss-head.xml:66: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-jboss-head.xml:37: Exit code: 1 See tests.log in Build Artifacts for details. JAVA_HOME=/opt/j2sdk1.4.2_05/Date of build:05/31/2005 20:11:43Time to build:216 minutes 54 secondsLast changed:05/31/2005 19:49:28Last log entry:When there is a run-as identity, the current authenticated subject context must be duplicated to ensure consistency when the subject context and run-as identity are unconditionally popped. Unit Tests: (0) Total Errors and Failures: (0) Modifications since last build:(16)1.2.4.6modifiedstarksmserver/src/main/org/jboss/ejb/plugins/JaasAuthenticationInterceptor.javaWhen there is a run-as identity, the current authenticated subject context must be duplicated to ensure consistency when the subject context and run-as identity are unconditionally popped.1.46.4.8modifiedstarksmserver/src/main/org/jboss/ejb/plugins/SecurityInterceptor.javaWhen there is a run-as identity, the current authenticated subject context must be duplicated to ensure consistency when the subject context and run-as identity are unconditionally popped.1.5.2.7modifiedstarksmserver/src/main/org/jboss/ejb/plugins/SecurityActions.javaAdd an action for the SecurityAssociation.dupSubjectContext method.1.78.2.2modifiedstarksmserver/src/main/org/jboss/ejb/EnterpriseContext.javaWith the removal of the check for a run-as principal in the SecurityAssociation.getPrincipal, the getCallerPrincipal implementation must check for an incoming run-as principal.1.1.4.2modifiedstarksmserver/src/main/org/jboss/security/plugins/NoAccessSecurityManager.javaUpdate the javadoc to refer to the isValid(Principal, Object, Subject) version.1.7.4.2modifiedstarksmserver/src/main/org/jboss/security/plugins/NullSecurityManager.javaUpdate the javadoc to refer to the isValid(Principal, Object, Subject) version.1.1.2.1modifiedstarksmsecurity/src/main/org/jboss/security/propertyeditor/SecurityDomainEditor.javaExplicitly pass in a null Subject to make it clear we don't need a subject after the authentication call.1.27.2.8modifiedstarksmsecurity/src/main/org/jboss/security/plugins/JaasSecurityManagerService.javaExplicitly pass in a null Subject to make it clear we don't need a subject after the authentication call.1.19.2.6modifiedstarksmserver/src/main/org/jboss/security/SecurityAssociation.java- Remove the look to the run-as principal stack from within the getPrincipal()/getCredential() methods as these have nothing to do with the run-as context. Resolves (JBAS-1852) Unexpected Principal (Security Identity) Propagation Switch.- Add a dupSubjectContext method to duplicate the current authenticated subject context. Resolves (JBAS-1862) SecurityInterceptor is not managing subject context stack correctly when run-as is seen.1.7.6.5modifiedstarksmtestsuite/src/resources/security-spec/META-INF/ejb-jar.xmlExtend the run-as interaction tests1.11.6.6modifiedstarksmtestsuite/src/resources/security-spec/META-INF/jboss.xmlExtend the run-as interaction tests1.2.16.4modifiedstarksmtestsuite/src/main/org/jboss/test/security/ejb/CallerBean.javaExtend the run-as interaction tests1.24.4.8modifiedstarksmtestsuite/src/main/org/jboss/test/security/test/EJBSpecUnitTestCase.javaExtend the run-as interaction tests1.2.2.13modifiedtdieslerjaxrpc/build.xmlAdd manifest information1.25.2.2modifiednrochercluster/src/main/org/jboss/ha/framework/server/DistributedReplicantManagerImpl.java[JBCLUSTER-38] - localReplicant shutdown at destroy() instead of stop()1.43.2.4modifiednrochercluster/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java[JBCLUSTER-38] - localReplicant shutdown at destroy() instead of stop()
