You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Apache Hudson Server <hu...@hudson.apache.org> on 2010/11/18 16:26:08 UTC
Build failed in Hudson: River-trunk-QA-windows #6
See <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/6/changes>
Changes:
[sijskes] explicitly stated amount of memory during compile qa
[sijskes] explicitly stated amount of memory during compile qa, disabled
------------------------------------------
[...truncated 598 lines...]
sun-util.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib\sun-util.jar>
[jar] com/sun/jini/admin/DestroyAdmin.class already added, skipping
river.jars:
tools.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib\tools.jar>
[java] Warning: Nested class ServerContext$1 has different preferred state than outer class ServerContext
[java] Warning: Nested class UuidFactory$Impl has different preferred state than outer class UuidFactory
[java] Warning: Nested class ConfigurationFile$Parser has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$ThisRef has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$ConstructorCall has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class Configuration$1 has different preferred state than outer class Configuration
[java] Warning: Nested class Configuration$2 has different preferred state than outer class Configuration
[java] Warning: Nested class ConfigurationFile$Cast has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$Call has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$NameRef has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationProvider$1 has different preferred state than outer class ConfigurationProvider
[java] Warning: Nested class ConfigurationFile$StringConcatenation has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$Literal has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationProvider$2 has different preferred state than outer class ConfigurationProvider
[java] Warning: Nested class ConfigurationFile$1 has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$Entry has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$PushbackStreamTokenizer has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$ClassLiteral has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$ParseNode has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$ArrayConstructor has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$StringLiteral has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class ConfigurationFile$MethodCall has different preferred state than outer class ConfigurationFile
[java] Warning: Nested class HttpmdUtil$1 has different preferred state than outer class HttpmdUtil
[java] Warning: Nested class ConstrainableLookupLocator$1 has different preferred state than outer class ConstrainableLookupLocator
[java] Warning: Nested class MarshalledInstance$FromMOInputStream has different preferred state than outer class MarshalledInstance
[java] Warning: Nested class MarshalledInstance$MarshalledInstanceInputStream has different preferred state than outer class MarshalledInstance
[java] Warning: Nested class MarshalledInstance$ToMOInputStream has different preferred state than outer class MarshalledInstance
[java] Warning: Nested class MarshalledInstance$1 has different preferred state than outer class MarshalledInstance
[java] Warning: Nested class MarshalledInstance$MarshalledInstanceOutputStream has different preferred state than outer class MarshalledInstance
[java] Warning: Nested class BasicMethodConstraints$1 has different preferred state than outer class BasicMethodConstraints
[java] Warning: Nested class ClassLoading$1 has different preferred state than outer class ClassLoading
[java] Warning: Nested class ClassLoading$2 has different preferred state than outer class ClassLoading
[java] Warning: Nested class PreferredClassProvider$4 has different preferred state than outer class PreferredClassProvider
[java] Warning: Nested class PreferredClassLoader$2 has different preferred state than outer class PreferredClassLoader
[java] Warning: Nested class PreferredClassProvider$2 has different preferred state than outer class PreferredClassProvider
[java] Warning: Nested class PreferredClassProvider$LoaderKey has different preferred state than outer class PreferredClassProvider
[java] Warning: Nested class PreferredClassLoader$1 has different preferred state than outer class PreferredClassLoader
[java] Warning: Nested class PreferredClassProvider$LoaderEntry has different preferred state than outer class PreferredClassProvider
[java] Warning: Nested class PreferredClassLoader$4 has different preferred state than outer class PreferredClassLoader
[java] Warning: Nested class PreferredClassProvider$3 has different preferred state than outer class PreferredClassProvider
[java] Warning: Nested class PreferredClassProvider$5 has different preferred state than outer class PreferredClassProvider
[java] Warning: Nested class PreferredClassProvider$1 has different preferred state than outer class PreferredClassProvider
[java] Warning: Nested class PreferredClassLoader$3 has different preferred state than outer class PreferredClassLoader
[java] Warning: Nested class Security$1 has different preferred state than outer class Security
[java] Warning: Nested class GrantPermission$Implier has different preferred state than outer class GrantPermission
[java] Warning: Nested class BasicUntrustedObjectSecurityContext$2 has different preferred state than outer class BasicUntrustedObjectSecurityContext
[java] Warning: Nested class ProxyTrustExporter$WeakRef has different preferred state than outer class ProxyTrustExporter
[java] Warning: Nested class ProxyTrustVerifier$MOStream has different preferred state than outer class ProxyTrustVerifier
[java] Warning: Nested class ProxyTrustExporter$ProxyTrustImpl has different preferred state than outer class ProxyTrustExporter
[java] Warning: Nested class ProxyTrustVerifier$6 has different preferred state than outer class ProxyTrustVerifier
[java] Warning: Nested class ProxyTrustVerifier$2 has different preferred state than outer class ProxyTrustVerifier
[java] Warning: Nested class ProxyTrustVerifier$5 has different preferred state than outer class ProxyTrustVerifier
[java] Warning: Nested class BasicUntrustedObjectSecurityContext$Combiner has different preferred state than outer class BasicUntrustedObjectSecurityContext
[java] Warning: Nested class ProxyTrustExporter$Reaper has different preferred state than outer class ProxyTrustExporter
[java] Warning: Nested class ProxyTrustVerifier$4 has different preferred state than outer class ProxyTrustVerifier
[java] Warning: Nested class ProxyTrustVerifier$1 has different preferred state than outer class ProxyTrustVerifier
[java] Warning: Nested class BasicUntrustedObjectSecurityContext$1 has different preferred state than outer class BasicUntrustedObjectSecurityContext
[java] Warning: Nested class ProxyTrustVerifier$3 has different preferred state than outer class ProxyTrustVerifier
[java] Warning: Nested class ProxyTrustVerifier$7 has different preferred state than outer class ProxyTrustVerifier
[java] Warning: Nested class Security$3 has different preferred state than outer class Security
[java] Warning: Nested class DynamicPolicyProvider$1 has different preferred state than outer class DynamicPolicyProvider
[java] Warning: Nested class DynamicPolicyProvider$2 has different preferred state than outer class DynamicPolicyProvider
[java] Warning: Nested class DynamicPolicyProvider$WeakGroup has different preferred state than outer class DynamicPolicyProvider
[java] Warning: Nested class PolicyFileProvider$1 has different preferred state than outer class PolicyFileProvider
[java] Warning: Nested class DynamicPolicyProvider$Grants has different preferred state than outer class DynamicPolicyProvider
[java] Warning: Nested class DynamicPolicyProvider$DomainPermissions has different preferred state than outer class DynamicPolicyProvider
[java] Warning: Nested class DynamicPolicyProvider$3 has different preferred state than outer class DynamicPolicyProvider
[java] Warning: Nested class Security$6 has different preferred state than outer class Security
[java] Warning: Nested class Security$Context has different preferred state than outer class Security
[java] Warning: Nested class Security$4 has different preferred state than outer class Security
[java] Warning: Nested class Security$8 has different preferred state than outer class Security
[java] Warning: Nested class Security$7 has different preferred state than outer class Security
[java] Warning: Nested class AuthenticationPermission$Data has different preferred state than outer class AuthenticationPermission
[java] Warning: Nested class GrantPermission$PermissionInfo has different preferred state than outer class GrantPermission
[java] Warning: Nested class Security$2 has different preferred state than outer class Security
[java] Warning: Nested class Security$5 has different preferred state than outer class Security
[java] Warning: Nested class Security$ClassContextAccess has different preferred state than outer class Security
[java] Warning: Nested class GrantPermission$1 has different preferred state than outer class GrantPermission
[java] Warning: Nested class BasicInvocationDispatcher$2 has different preferred state than outer class BasicInvocationDispatcher
[java] Warning: Nested class BasicObjectEndpoint$1 has different preferred state than outer class BasicObjectEndpoint
[java] Warning: Nested class BasicJeriExporter$ImplContainer has different preferred state than outer class BasicJeriExporter
[java] Warning: Nested class BasicObjectEndpoint$DgcBatchContext has different preferred state than outer class BasicObjectEndpoint
[java] Warning: Nested class BasicJeriTrustVerifier$1 has different preferred state than outer class BasicJeriTrustVerifier
[java] Warning: Nested class HttpEndpoint$5 has different preferred state than outer class HttpEndpoint
[java] Warning: Nested class HttpEndpoint$Connection has different preferred state than outer class HttpEndpoint
[java] Warning: Nested class HttpEndpoint$6 has different preferred state than outer class HttpEndpoint
[java] Warning: Nested class HttpEndpoint$SocketFactoryAdapter has different preferred state than outer class HttpEndpoint
[java] Warning: Nested class HttpEndpoint$3 has different preferred state than outer class HttpEndpoint
[java] Warning: Nested class HttpServerEndpoint$LH has different preferred state than outer class HttpServerEndpoint
[java] Warning: Nested class HttpEndpoint$1 has different preferred state than outer class HttpEndpoint
[java] Warning: Nested class HttpEndpoint$2 has different preferred state than outer class HttpEndpoint
[java] Warning: Nested class HttpServerEndpoint$1 has different preferred state than outer class HttpServerEndpoint
[java] Warning: Nested class HttpEndpoint$4 has different preferred state than outer class HttpEndpoint
[java] Warning: Nested class HttpEndpoint$ConnectionAction has different preferred state than outer class HttpEndpoint
[java] Warning: Nested class HttpServerEndpoint$LE has different preferred state than outer class HttpServerEndpoint
[java] Warning: Nested class BasicObjectEndpoint$AckListener has different preferred state than outer class BasicObjectEndpoint
[java] Warning: Nested class HttpsEndpoint$HttpClient has different preferred state than outer class HttpsEndpoint
[java] Warning: Nested class HttpsEndpoint$EndpointInfo has different preferred state than outer class HttpsEndpoint
[java] Warning: Nested class HttpsEndpoint$HttpsConnection has different preferred state than outer class HttpsEndpoint
[java] Warning: Nested class HttpsEndpoint$HttpsEndpointImpl has different preferred state than outer class HttpsEndpoint
[java] Warning: Nested class HttpsEndpoint$HttpsOutboundRequest has different preferred state than outer class HttpsEndpoint
[java] Warning: Nested class HttpsServerEndpoint$1 has different preferred state than outer class HttpsServerEndpoint
[java] Warning: Nested class HttpsEndpoint$1 has different preferred state than outer class HttpsEndpoint
[java] Warning: Nested class SslEndpoint$SslEndpointInternals has different preferred state than outer class SslEndpoint
[java] Warning: Nested class HttpsServerEndpoint$HttpsServerEndpointImpl has different preferred state than outer class HttpsServerEndpoint
[java] Warning: Nested class HttpsEndpoint$Reaper has different preferred state than outer class HttpsEndpoint
[java] Warning: Nested class BasicInvocationDispatcher$1 has different preferred state than outer class BasicInvocationDispatcher
[java] Warning: Nested class ServerConnectionManager$Inbound has different preferred state than outer class ServerConnectionManager
[java] Warning: Nested class ConnectionManager$Outbound has different preferred state than outer class ConnectionManager
[java] Warning: Nested class ServerConnectionManager$Dispatcher has different preferred state than outer class ServerConnectionManager
[java] Warning: Nested class ServerConnectionManager$InboundMux has different preferred state than outer class ServerConnectionManager
[java] Warning: Nested class ConnectionManager$OutboundMux has different preferred state than outer class ConnectionManager
[java] Warning: Nested class ConnectionManager$ReqIterator has different preferred state than outer class ConnectionManager
[java] Warning: Nested class ConnectionManager$Reaper has different preferred state than outer class ConnectionManager
[java] Warning: Nested class BasicInvocationHandler$1 has different preferred state than outer class BasicInvocationHandler
[java] Warning: Nested class AbstractILFactory$1 has different preferred state than outer class AbstractILFactory
[java] Warning: Nested class TcpEndpoint$ConnectionImpl has different preferred state than outer class TcpEndpoint
[java] Warning: Nested class TcpServerEndpoint$LE has different preferred state than outer class TcpServerEndpoint
[java] Warning: Nested class TcpServerEndpoint$1 has different preferred state than outer class TcpServerEndpoint
[java] Warning: Nested class TcpEndpoint$Handle has different preferred state than outer class TcpEndpoint
[java] Warning: Nested class TcpServerEndpoint$LH has different preferred state than outer class TcpServerEndpoint
[java] Warning: Nested class TcpEndpoint$ConnectionEndpointImpl has different preferred state than outer class TcpEndpoint
[java] Warning: Nested class TcpServerEndpoint$LH$ServerConnectionImpl$1 has different preferred state than outer class TcpServerEndpoint$LH$ServerConnectionImpl
[java] Warning: Nested class TcpEndpoint$1 has different preferred state than outer class TcpEndpoint
[java] Warning: Nested class BasicInvocationHandler$Failure has different preferred state than outer class BasicInvocationHandler
[java] Warning: Nested class KerberosEndpoint$CacheKey has different preferred state than outer class KerberosEndpoint
[java] Warning: Nested class KerberosServerEndpoint$ServerConnectionImpl has different preferred state than outer class KerberosServerEndpoint
[java] Warning: Nested class KerberosServerEndpoint$1 has different preferred state than outer class KerberosServerEndpoint
[java] Warning: Nested class KerberosServerEndpoint$ListenHandleImpl has different preferred state than outer class KerberosServerEndpoint
[java] Warning: Nested class KerberosUtil$SoftCache$ValueCell has different preferred state than outer class KerberosUtil$SoftCache
[java] Warning: Nested class KerberosServerEndpoint$2 has different preferred state than outer class KerberosServerEndpoint
[java] Warning: Nested class KerberosEndpoint$ConnectionImpl has different preferred state than outer class KerberosEndpoint
[java] Warning: Nested class KerberosServerEndpoint$ListenCookieImpl has different preferred state than outer class KerberosServerEndpoint
[java] Warning: Nested class KerberosServerEndpoint$ConnectionHandler$1$1 has different preferred state than outer class KerberosServerEndpoint$ConnectionHandler$1
[java] Warning: Nested class KerberosEndpoint$ConnectionEndpointImpl has different preferred state than outer class KerberosEndpoint
[java] Warning: Nested class KerberosEndpoint$1 has different preferred state than outer class KerberosEndpoint
[java] Warning: Nested class KerberosServerEndpoint$ListenEndpointImpl has different preferred state than outer class KerberosServerEndpoint
[java] Warning: Nested class KerberosUtil$SoftCache$LRUHashMap has different preferred state than outer class KerberosUtil$SoftCache
[java] Warning: Nested class KerberosServerEndpoint$ConnectionHandler has different preferred state than outer class KerberosServerEndpoint
[java] Warning: Nested class KerberosEndpoint$KerberosEndpointInternals has different preferred state than outer class KerberosEndpoint
[java] Warning: Nested class KerberosEndpoint$RequestHandleImpl has different preferred state than outer class KerberosEndpoint
[java] Warning: Nested class KerberosServerEndpoint$3 has different preferred state than outer class KerberosServerEndpoint
[java] Warning: Nested class ActivatableInvocationHandler$Failure has different preferred state than outer class ActivatableInvocationHandler
[java] Warning: Nested class ActivationGroup$1 has different preferred state than outer class ActivationGroup
[java] Warning: Nested class ActivatableInvocationHandler$1 has different preferred state than outer class ActivatableInvocationHandler
[java] Warning: Nested class ActivatableInvocationHandler$2 has different preferred state than outer class ActivatableInvocationHandler
[java] Warning: Nested class LookupLocator$1 has different preferred state than outer class LookupLocator
[java] Warning: Nested class Server$ServerImpl has different preferred state than outer class Server
[java] Warning: Nested class Client$ClientImpl has different preferred state than outer class Client
[java] Warning: Nested class Client$ClientImpl has different preferred state than outer class Client
[java] Warning: Nested class Server$ServerImpl has different preferred state than outer class Server
[java] Warning: Nested class DiscoveryV2$DatagramBuffers$DatagramInfo has different preferred state than outer class DiscoveryV2$DatagramBuffers
[java] Warning: Nested class Server$ServerImpl has different preferred state than outer class Server
[java] Warning: Nested class Client$ClientImpl has different preferred state than outer class Client
[java] Warning: Nested class DiscoveryConstraints$ConnectionAbsoluteTimeReducer has different preferred state than outer class DiscoveryConstraints
[java] Warning: Nested class DiscoveryConstraints$MulticastMaxPacketSizeReducer has different preferred state than outer class DiscoveryConstraints
[java] Warning: Nested class Server$ServerImpl has different preferred state than outer class Server
[java] Warning: Nested class Client$ClientImpl has different preferred state than outer class Client
[java] Warning: Nested class DiscoveryConstraints$ConstraintReducer has different preferred state than outer class DiscoveryConstraints
[java] Warning: Nested class DiscoveryConstraints$MaxValueReducer has different preferred state than outer class DiscoveryConstraints
[java] Warning: Nested class LogManager$Probe has different preferred state than outer class LogManager
jarwrapper.jar:
checkconfigurationfile.jar:
checkser.jar:
classdep.jar:
classserver.jar:
computedigest.jar:
computehttpmdcodebase.jar:
jsk-debug-policy.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib\jsk-debug-policy.jar>
preferredlistgen.jar:
envcheck.jar:
[jar] Updating jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib\envcheck.jar>
toolswrappers.jars:
destroy.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib\destroy.jar>
fiddler.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib\fiddler.jar>
fiddler-dl.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib-dl\fiddler-dl.jar>
group.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib\group.jar>
group-dl.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib-dl\group-dl.jar>
mahalo.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib\mahalo.jar>
mahalo-dl.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib-dl\mahalo-dl.jar>
mercury.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib\mercury.jar>
mercury-dl.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib-dl\mercury-dl.jar>
norm.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib\norm.jar>
norm-dl.jar:
[jar] Building jar: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\lib-dl\norm-dl.jar>
[java] Command line error: Proxy class was not found: com.sun.jini.norm.SetProxy
[java] args:
[java] -tell <class>
[java] -print
[java] -noreplace
[java] -nonpublic
[java] -nomerge
[java] -cp <class path>
[java] -default <true|false>
[java] -jar <jar file name>
[java] -classes <file containing class list>
[java] -api <path>
[java] -impl <path>
[java] -proxy <classname>
BUILD FAILED
<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\build.xml>:1568: The following error occurred while executing this line:
<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\common.xml>:214: Java returned: 1
Total time: 6 minutes 51 seconds
Publishing Javadoc
Archiving artifacts
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Peter Firmstone <ji...@zeus.net.au>.
Patricia Shanahan wrote:
> On 11/21/2010 11:05 AM, Sim IJskes - QCG wrote:
>> On 11/21/2010 08:03 PM, Sim IJskes - QCG wrote:
>>> On 11/21/2010 06:14 PM, Patricia Shanahan wrote:
>>>>>>>> does not have required permission:
>>>>>>>>>> (com.sun.jini.start.SharedActivationPolicyPermission
>>>>>>>>>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
>>>
>>>> In any case, I have some good questions, and this is a promising
>>>> line of
>>>> inquiry, because file: URL construction interacts with file path name
>>>> construction, which is different between Windows and the other systems
>>>> on which River has been tested.
>>>
>>> Could the code in SharedActivationPolicyPermission.init() be the
>>> culprit?
>>>
>>> What about a test for scheme = 'file' and then take a separate path
>>> through code constructed with:
>>>
>>> new File(url.toURI()).getName().getAbsolutePath() ?
>>
>> Without the getName() call.... :]
>>
>
> This approach seems good. The test I'm currently working on passes if
> I use the following to get the FilePermission object:
>
> new FilePermission(new File(new
> URL(policy).getPath()).getAbsolutePath(),"read")
>
> However, I am not sure about the correctness, relative to general
> River policies, of the exception handling in the init method. If it
> gets a MalformedUrlException it just goes ahead and tries to use the
> unmodified policy String in the FilePermission constructor.
>
> In addition to that case, I need to decide what to do if the policy
> String is a well formed URL, but does not have a file path component.
> Presumably a FilePermission does not make sense in that case???
>
> Note that the mapping is not just for file: URLs. The comment at the
> start of the init method uses an http: example for the reason for
> doing the mapping.
>
> Patricia
>
It's worth noting, that the UnresolvedPermissions had not been resolved,
meaning that their path string had not yet been converted as
SharedActivationPolicyPermission.init() had not been called, for any
permissions that remained unresolved.
If these permissions had been resolved, their resolved form would appear
in the ProtectionDomain.toString() output, when a Permission is
resolved all belonging to the same class are resolved and added to a
PermissionCollection on which implies(Permission) is called, this is
done, in case two Permission's combined imply the checked Permission.
There are two things to check, did the policy successfully resolve the
permission? See UnresolvedPermission.resolve If not, why? If it did, why
didn't it imply. You'll need to set some breakpoints in
UnresolvedPermission.resolve.
Cheers,
Peter.
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/22/2010 12:53 AM, Patricia Shanahan wrote:
> This approach seems good. The test I'm currently working on passes if I
> use the following to get the FilePermission object:
>
> new FilePermission(new File(new
> URL(policy).getPath()).getAbsolutePath(),"read")
>
> However, I am not sure about the correctness, relative to general River
> policies, of the exception handling in the init method. If it gets a
> MalformedUrlException it just goes ahead and tries to use the unmodified
> policy String in the FilePermission constructor.
>
> In addition to that case, I need to decide what to do if the policy
> String is a well formed URL, but does not have a file path component.
> Presumably a FilePermission does not make sense in that case???
Exactly. We can verify it in river sense, by including logoutput and a
exception in this case.
Also we should make sure the File is not checked for existance, not the
least because of the /* /- ends.
> Note that the mapping is not just for file: URLs. The comment at the
> start of the init method uses an http: example for the reason for doing
> the mapping.
Yes, totally confusing. Where can we find an example in the JDK that
explains the meaning of the FilePermission? If we can be sure it can
only be a real filepath and not a jar or http reference, we could
include assert like checks.
Gr. Sim
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/22/2010 06:05 PM, Sim IJskes - QCG wrote:
> On 11/22/2010 06:02 PM, Sim IJskes - QCG wrote:
>> Hmm, how can we be sure what a FilePermission string looks like on a
>> future system? It is a bug to pass a URL, but i'm back peddling on
>> throwing an exception. A warning maybe, or a logging statement?
>
> Something that we can enable during testing, and will never cause
> problems in production environments, was my line of thinking.
Stripping '*' and '-' from the end, and then new File(str).getPath()
will cause FileSystem.normalize(), would this check for illegal file
specification? FileSystem is package private so no direct access.
Gr. Sim
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/22/2010 06:02 PM, Sim IJskes - QCG wrote:
> Hmm, how can we be sure what a FilePermission string looks like on a
> future system? It is a bug to pass a URL, but i'm back peddling on
> throwing an exception. A warning maybe, or a logging statement?
Something that we can enable during testing, and will never cause
problems in production environments, was my line of thinking.
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/22/2010 05:39 PM, Patricia Shanahan wrote:
> After looking at all this, I'm thinking in terms of pushing the problem
> up a layer, and requiring a File argument instead of a String. That
> makes the idea of local File'ness explicit.
That doesnt look right to me. A File with a name ending in - or * is not
a true File.
> There is only one use of SharedActivationPolicyPermission in the River
> production code, in ActivateWrapper. The remaining calls are all tests
> which we can modify or drop as appropriate. I'm inclined to the view
> that a test that passes a string that does not conform to FilePermission
> policy string semantics should expect an IllegalArgumentException from
> the constructor.
Hmm, how can we be sure what a FilePermission string looks like on a
future system? It is a bug to pass a URL, but i'm back peddling on
throwing an exception. A warning maybe, or a logging statement?
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/22/2010 05:39 PM, Patricia Shanahan wrote:
> I think I understand what you are saying, but I'm not 100% sure, so I'm
> going to repeat back the message I'm getting:
>
> The implementation of SharedActivationPolicyPermission depends on
> FilePermission. Its Javadoc comment requires a policy string argument
> that conforms to the FilePermission policy string semantics.
>
> A URL, in general, is not a valid FilePermission policy string. On the
> other hand, a File path is. Incidentally, I've tested handling of the
> FilePermission wildcards in the File class, and it all works.
>
> File can do the "/" conversion correctly and automatically for the
> system on which it is run. Doing the conversion on the file path portion
> of the URL makes the test case I've been working on pass on both Windows
> and Ubuntu.
>
> Even if we make no change in the actual interface,
> SharedActivationPolicyPermission should enforce its stated requirement
> that the policy string constructor argument conform to FilePermssion
> policy semantics.
Yes! RST 559!
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/22/2010 7:22 AM, Sim IJskes - QCG wrote:
>>> There are a lot of
>>> new SharedActivationPolicyPermission("http://resendes:8080/policy.all");
>>> calls and a lot of
>>> new SharedActivationPolicyPermission( fs + "vob" + fs + "jive" + fs +
>>> "policy" + fs + "policy.all");
>>> calls.
>>
>> I think we established earlier that "resendes" is used to represent a
>> non-existent host.
>
> Yes, i hadn't forgotten, but is it a bug or intentional.
>
> The second one is a relative url, the first one isn't.
>
> When we look at the javadocs for SharedActivationPolicyPermission the
> policy string argument has the same semantics as FilePermission.
> FilePermission has no URL, so SharedActivationPolicyPermission should
> not be a URL.
>
> Flawed reasoning? Either the testcases with URL were undetected bugs, or
> the javadoc for SharedActivationPolicyPermission is a bug.
>
> The URL stuff in init() is just enlisted to do some FileSeparator
> conversion, if the javadoc is right.
>
> Gr. Sim
>
> P.S. Bob? Any change that little birdie you talked about will tell us
> the solution?
>
I think I understand what you are saying, but I'm not 100% sure, so I'm
going to repeat back the message I'm getting:
The implementation of SharedActivationPolicyPermission depends on
FilePermission. Its Javadoc comment requires a policy string argument
that conforms to the FilePermission policy string semantics.
A URL, in general, is not a valid FilePermission policy string. On the
other hand, a File path is. Incidentally, I've tested handling of the
FilePermission wildcards in the File class, and it all works.
File can do the "/" conversion correctly and automatically for the
system on which it is run. Doing the conversion on the file path portion
of the URL makes the test case I've been working on pass on both Windows
and Ubuntu.
Even if we make no change in the actual interface,
SharedActivationPolicyPermission should enforce its stated requirement
that the policy string constructor argument conform to FilePermssion
policy semantics.
After looking at all this, I'm thinking in terms of pushing the problem
up a layer, and requiring a File argument instead of a String. That
makes the idea of local File'ness explicit.
There is only one use of SharedActivationPolicyPermission in the River
production code, in ActivateWrapper. The remaining calls are all tests
which we can modify or drop as appropriate. I'm inclined to the view
that a test that passes a string that does not conform to FilePermission
policy string semantics should expect an IllegalArgumentException from
the constructor.
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
>> There are a lot of
>> new SharedActivationPolicyPermission("http://resendes:8080/policy.all");
>> calls and a lot of
>> new SharedActivationPolicyPermission( fs + "vob" + fs + "jive" + fs +
>> "policy" + fs + "policy.all");
>> calls.
>
> I think we established earlier that "resendes" is used to represent a
> non-existent host.
Yes, i hadn't forgotten, but is it a bug or intentional.
The second one is a relative url, the first one isn't.
When we look at the javadocs for SharedActivationPolicyPermission the
policy string argument has the same semantics as FilePermission.
FilePermission has no URL, so SharedActivationPolicyPermission should
not be a URL.
Flawed reasoning? Either the testcases with URL were undetected bugs, or
the javadoc for SharedActivationPolicyPermission is a bug.
The URL stuff in init() is just enlisted to do some FileSeparator
conversion, if the javadoc is right.
Gr. Sim
P.S. Bob? Any change that little birdie you talked about will tell us
the solution?
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/22/2010 6:45 AM, Sim IJskes - QCG wrote:
> On 22-11-10 00:53, Patricia Shanahan wrote:
>> In addition to that case, I need to decide what to do if the policy
>> String is a well formed URL, but does not have a file path component.
>> Presumably a FilePermission does not make sense in that case???
>>
>> Note that the mapping is not just for file: URLs. The comment at the
>> start of the init method uses an http: example for the reason for doing
>> the mapping.
>
> I think we need to stick to the JDK definition of a FilePermission, and
> that is a path. There are references in the docs how a FilePermission is
> used. And also a clear use in the FileInputStream(File file) method.
>
> It calls the File.getPath() method there, in order to do a
> SecurityManager.checkRead(String file).
>
> What i can see, is that in the specific qatest, it gets always be called
> with a file: url.
>
> There are a lot of
> new SharedActivationPolicyPermission("http://resendes:8080/policy.all");
> calls and a lot of
> new SharedActivationPolicyPermission( fs + "vob" + fs + "jive" + fs +
> "policy" + fs + "policy.all");
> calls.
I think we established earlier that "resendes" is used to represent a
non-existent host.
> the resendes seems wrong, the ones starting with fs look right (although
> a driveletter spec is missing).
>
> Did we find a (non-related) bug?
I'm not sure. I'm currently running a QA test with a simple form of the
fix to use File to convert the path to system dependent form. So far, it
has passed 1215 tests, skipped 42, and failed 2. The change has
definitely fixed multiple failures. Interestingly, the two failures are
new, but do not superficially look related to the permission change.
I will go through some basic checks - rebooting my system, reverting the
change and running the failing tests etc. - before starting detailed
debug on them.
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 22-11-10 00:53, Patricia Shanahan wrote:
> In addition to that case, I need to decide what to do if the policy
> String is a well formed URL, but does not have a file path component.
> Presumably a FilePermission does not make sense in that case???
>
> Note that the mapping is not just for file: URLs. The comment at the
> start of the init method uses an http: example for the reason for doing
> the mapping.
I think we need to stick to the JDK definition of a FilePermission, and
that is a path. There are references in the docs how a FilePermission is
used. And also a clear use in the FileInputStream(File file) method.
It calls the File.getPath() method there, in order to do a
SecurityManager.checkRead(String file).
What i can see, is that in the specific qatest, it gets always be called
with a file: url.
There are a lot of
new SharedActivationPolicyPermission("http://resendes:8080/policy.all");
calls and a lot of
new SharedActivationPolicyPermission( fs + "vob" + fs + "jive" + fs +
"policy" + fs + "policy.all");
calls.
the resendes seems wrong, the ones starting with fs look right (although
a driveletter spec is missing).
Did we find a (non-related) bug?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/21/2010 11:05 AM, Sim IJskes - QCG wrote:
> On 11/21/2010 08:03 PM, Sim IJskes - QCG wrote:
>> On 11/21/2010 06:14 PM, Patricia Shanahan wrote:
>>>>>>> does not have required permission:
>>>>>>>>> (com.sun.jini.start.SharedActivationPolicyPermission
>>>>>>>>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
>>
>>> In any case, I have some good questions, and this is a promising line of
>>> inquiry, because file: URL construction interacts with file path name
>>> construction, which is different between Windows and the other systems
>>> on which River has been tested.
>>
>> Could the code in SharedActivationPolicyPermission.init() be the culprit?
>>
>> What about a test for scheme = 'file' and then take a separate path
>> through code constructed with:
>>
>> new File(url.toURI()).getName().getAbsolutePath() ?
>
> Without the getName() call.... :]
>
This approach seems good. The test I'm currently working on passes if I
use the following to get the FilePermission object:
new FilePermission(new File(new
URL(policy).getPath()).getAbsolutePath(),"read")
However, I am not sure about the correctness, relative to general River
policies, of the exception handling in the init method. If it gets a
MalformedUrlException it just goes ahead and tries to use the unmodified
policy String in the FilePermission constructor.
In addition to that case, I need to decide what to do if the policy
String is a well formed URL, but does not have a file path component.
Presumably a FilePermission does not make sense in that case???
Note that the mapping is not just for file: URLs. The comment at the
start of the init method uses an http: example for the reason for doing
the mapping.
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/21/2010 08:03 PM, Sim IJskes - QCG wrote:
> On 11/21/2010 06:14 PM, Patricia Shanahan wrote:
>>>>>> does not have required permission:
>>>>>>>> (com.sun.jini.start.SharedActivationPolicyPermission
>>>>>>>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
>
>> In any case, I have some good questions, and this is a promising line of
>> inquiry, because file: URL construction interacts with file path name
>> construction, which is different between Windows and the other systems
>> on which River has been tested.
>
> Could the code in SharedActivationPolicyPermission.init() be the culprit?
>
> What about a test for scheme = 'file' and then take a separate path
> through code constructed with:
>
> new File(url.toURI()).getName().getAbsolutePath() ?
Without the getName() call.... :]
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/21/2010 06:14 PM, Patricia Shanahan wrote:
>>>>> does not have required permission:
>>>>>>> (com.sun.jini.start.SharedActivationPolicyPermission
>>>>>>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
> In any case, I have some good questions, and this is a promising line of
> inquiry, because file: URL construction interacts with file path name
> construction, which is different between Windows and the other systems
> on which River has been tested.
Could the code in SharedActivationPolicyPermission.init() be the culprit?
What about a test for scheme = 'file' and then take a separate path
through code constructed with:
new File(url.toURI()).getName().getAbsolutePath() ?
Gr. Sim
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/21/2010 8:29 AM, Jonathan Costers wrote:
> 2010/11/21 Patricia Shanahan<pa...@acm.org>
>
>> Patricia Shanahan wrote:
>>
>>> Jonathan Costers wrote:
>>> ...
>>>
>>>> does not have required permission:
>>>>>> (com.sun.jini.start.SharedActivationPolicyPermission
>>>>>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
>>>>>>
>>>>> ...
>>>
>>>> What this means is that it has no permission to use file:*/*C:/.... , the
>>>> policies only give permission to file:C:\... Note extra / between file:
>>>> and
>>>> C:
>>>>
>>>
>>> Well spotted! Thanks.
>>>
>> ...
>>
>> I did a quick scan of the log,
>> http://www.patriciashanahan.com/apache/failingTest.txt, and the first
>> appearance of an extra "/" is in the first "-D" parameter on the test start
>> command:
>>
>> [java] Starting test in separate process with command:
>> [java] 'C:\Program Files (x86)\Java\jdk1.6.0_22\jre\bin\java'
>> -Djava.security.policy=file:/C:/apache2/River/qa/harness/policy/defaulttest.policy
>> ...
>>
>> This may not be the direct cause of the failures, but is certainly worth
>> investigating. Making all file: URIs correct, even with Windows' annoying
>> path structure, seems like a reasonable objective for avoiding Windows-only
>> bugs. At some point, I'll probably find some idiom or shared method that
>> really is the root cause of the failures.
>>
>>
> Line 146 in qa/src/com/sun/jini/qa/resources/qaDefaults.properties is
> probably the "root cause".
> The<url> tag translates a relative path into an URL.
> However, one could argue that this (file:/C:/...) is a correct URL and that
> the policy files really should accept it.
I'll investigate this by experimenting with java.net.URI, as well as
re-reading the relevant documents. If the "/" before the drive letter is
required - to indicate absolute rather than relative path in the URL -
then the problem may be in how the permissions were originally set up.
Incidentally, Firefox accepts from 0 through 3 "/" characters between
the "file:" and the drive letter, but browsers often accept things that
are not strictly correct.
In any case, I have some good questions, and this is a promising line of
inquiry, because file: URL construction interacts with file path name
construction, which is different between Windows and the other systems
on which River has been tested.
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/11/21 Patricia Shanahan <pa...@acm.org>
> Patricia Shanahan wrote:
>
>> Jonathan Costers wrote:
>> ...
>>
>>> does not have required permission:
>>>>> (com.sun.jini.start.SharedActivationPolicyPermission
>>>>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
>>>>>
>>>> ...
>>
>>> What this means is that it has no permission to use file:*/*C:/.... , the
>>> policies only give permission to file:C:\... Note extra / between file:
>>> and
>>> C:
>>>
>>
>> Well spotted! Thanks.
>>
> ...
>
> I did a quick scan of the log,
> http://www.patriciashanahan.com/apache/failingTest.txt, and the first
> appearance of an extra "/" is in the first "-D" parameter on the test start
> command:
>
> [java] Starting test in separate process with command:
> [java] 'C:\Program Files (x86)\Java\jdk1.6.0_22\jre\bin\java'
> -Djava.security.policy=file:/C:/apache2/River/qa/harness/policy/defaulttest.policy
> ...
>
> This may not be the direct cause of the failures, but is certainly worth
> investigating. Making all file: URIs correct, even with Windows' annoying
> path structure, seems like a reasonable objective for avoiding Windows-only
> bugs. At some point, I'll probably find some idiom or shared method that
> really is the root cause of the failures.
>
>
Line 146 in qa/src/com/sun/jini/qa/resources/qaDefaults.properties is
probably the "root cause".
The <url> tag translates a relative path into an URL.
However, one could argue that this (file:/C:/...) is a correct URL and that
the policy files really should accept it.
> Patricia
>
>
>
>
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
Patricia Shanahan wrote:
> Jonathan Costers wrote:
> ...
>>>> does not have required permission:
>>>> (com.sun.jini.start.SharedActivationPolicyPermission
>>>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
> ...
>> What this means is that it has no permission to use file:*/*C:/.... , the
>> policies only give permission to file:C:\... Note extra / between
>> file: and
>> C:
>
> Well spotted! Thanks.
...
I did a quick scan of the log,
http://www.patriciashanahan.com/apache/failingTest.txt, and the first
appearance of an extra "/" is in the first "-D" parameter on the test
start command:
[java] Starting test in separate process with command:
[java] 'C:\Program Files (x86)\Java\jdk1.6.0_22\jre\bin\java'
-Djava.security.policy=file:/C:/apache2/River/qa/harness/policy/defaulttest.policy
...
This may not be the direct cause of the failures, but is certainly worth
investigating. Making all file: URIs correct, even with Windows'
annoying path structure, seems like a reasonable objective for avoiding
Windows-only bugs. At some point, I'll probably find some idiom or
shared method that really is the root cause of the failures.
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
Jonathan Costers wrote:
...
>>> does not have required permission:
>>> (com.sun.jini.start.SharedActivationPolicyPermission
>>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
...
> What this means is that it has no permission to use file:*/*C:/.... , the
> policies only give permission to file:C:\... Note extra / between file: and
> C:
Well spotted! Thanks.
I would probably have seen it once I started looking closely at the
permission checking, but that saves me some time.
My current guess is that something is being done as String manipulation
that should be done using API classes such as File, which knows about
the different path naming rules. However, I'll know better once I find
where that extra "/" is coming from.
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/11/21 Peter Firmstone <ji...@zeus.net.au>
> Peter Firmstone wrote:
>
>> Patricia Shanahan wrote:
>>
>>> On 11/20/2010 2:40 PM, Peter Firmstone wrote:
>>>
>>>> Peter Firmstone wrote:
>>>>
>>>>> Patricia Shanahan wrote:
>>>>>
>>>>>> On 11/19/2010 10:06 AM, Sim IJskes - QCG wrote:
>>>>>>
>>>>>>> On 11/19/2010 06:20 PM, Apache Hudson Server wrote:
>>>>>>>
>>>>>>>> See<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
>>>>>>>>
>>>>>>>
>>>>>>> [java] # of tests started = 1410
>>>>>>>> [java] # of tests completed = 1410
>>>>>>>> [java] # of tests skipped = 46
>>>>>>>> [java] # of tests passed = 1363
>>>>>>>> [java] # of tests failed = 47
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk/trunk/qa/result/index.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Some tests failed on policy permissions (so it looks), any change
>>>>>>> that
>>>>>>> this is windows related? slash vs backslash and driveletter?
>>>>>>>
>>>>>>
>>>>>> I have run the first failing test,
>>>>>> com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest.td,
>>>>>> under WindowsXP, and reproduced the failure. The test passes on an
>>>>>> identical checkout, compiled and run with the same JDK version, on a
>>>>>> Ubuntu VirtualBox.
>>>>>>
>>>>>> That creates a strong presumption that we are indeed dealing with a
>>>>>> Windows related issue, such as the horrible Windows file naming.
>>>>>>
>>>>>> The first error in the log is:
>>>>>>
>>>>>> [java] com.sun.jini.qa.harness.TestException: Unexpected exception
>>>>>> starting service; nested exception is:
>>>>>> [java] Problem creating service for sharedGroupImpl; nested exception
>>>>>> is:
>>>>>> [java] exception constructing object; nested exception is:
>>>>>> [java] java.lang.SecurityException: ProtectionDomain ProtectionDomain
>>>>>> (file:/C:/apache2/River/lib/group.jar <no signer certificates>)
>>>>>> [java] null
>>>>>> [java] <no principals>
>>>>>>
>>>>>> The failure is during set-up, so it is quite likely that a lot of
>>>>>> tests are affected by the same problem.
>>>>>>
>>>>>> Any advice on how to check the signer certificates?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Patricia
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Your failure isn't caused by <no signer certificates>, that's just
>>>>> information printed from the ProtectionDomain, did the failing
>>>>> ProtectionDomain list the Permissions?
>>>>>
>>>>> What was the Permission that failed?
>>>>>
>>>>> When ProtectionDomain.toString is called, it merges the dynamic
>>>>> Permissions from the policy with the static Permissions in the
>>>>> ProtectionDomain and prints them all out, useful for debugging.
>>>>>
>>>>
>>> I'm not 100% sure how to answer the question, so I've uploaded the output
>>> as http://www.patriciashanahan.com/apache/failingTest.txt
>>>
>>> I wonder if the policy file has a Permission grant with a bad path? That
>>>> might explain the missing permission.
>>>>
>>>>
>>> Are path comparisons done using the File equals method, or String equals?
>>>
>>> Patricia
>>>
>>>
>>>
> Neither, it uses FilePermission.implies(Permission) internally.
>
> Cheers,
>
> Peter.
>
>
>
>
>> The permission that's failing is:
>>
>> does not have required permission:
>> (com.sun.jini.start.SharedActivationPolicyPermission
>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
>>
>> Interestingly the policy has not resolved:
>>
>> (unresolved com.sun.jini.start.SharedActivationPolicyPermission
>> file:C:\apache2\River\qa\harness\policy\defaultgroup.policy null)
>> [java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission
>> file:C:\apache2\River\qa\harness\policy\policy.all null)
>> [java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission
>> file:C:\apache2\River\qa\harness\policy\all.policy null)
>> [java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission
>> file:C:\apache2\River\qa\harness\policy\sec-jeri-group.policy null)
>> [java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission
>> jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/defaultgroup.policy
>> null)
>> [java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission
>> jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/policy.all
>> null)
>> [java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission
>> jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/all.policy
>> null)
>> [java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission
>> jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/sec-jeri-group.policy
>> null)
>>
>>
What this means is that it has no permission to use file:*/*C:/.... , the
policies only give permission to file:C:\... Note extra / between file: and
C:
> This means that the class
>> com.sun.jini.start.SharedActivationPolicyPermission was not visible to the
>> policy file implementation, which is normal, since it is loaded by the
>> parent java extension classloader.
>>
>> What isn't normal however is the SharedActivationPolicyPermission should
>> later be resolved when Policy.implies(ProtectionDomain, Permission) is
>> called.
>>
>> As you can see from the output, the policy has been read correctly and has
>> the needed permission, albeit unresolved.
>>
>> This tends to indicate that there may be a class path issue with start.jar
>>
>> Hope this helps.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Patricia Shanahan wrote:
>> On 11/20/2010 2:40 PM, Peter Firmstone wrote:
>>> Peter Firmstone wrote:
>>>> Patricia Shanahan wrote:
>>>>> On 11/19/2010 10:06 AM, Sim IJskes - QCG wrote:
>>>>>> On 11/19/2010 06:20 PM, Apache Hudson Server wrote:
>>>>>>> See<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
>>>>>>
>>>>>>> [java] # of tests started = 1410
>>>>>>> [java] # of tests completed = 1410
>>>>>>> [java] # of tests skipped = 46
>>>>>>> [java] # of tests passed = 1363
>>>>>>> [java] # of tests failed = 47
>>>>>>
>>>>>> https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk/trunk/qa/result/index.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Some tests failed on policy permissions (so it looks), any change
>>>>>> that
>>>>>> this is windows related? slash vs backslash and driveletter?
>>>>>
>>>>> I have run the first failing test,
>>>>> com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest.td,
>>>>> under WindowsXP, and reproduced the failure. The test passes on an
>>>>> identical checkout, compiled and run with the same JDK version, on a
>>>>> Ubuntu VirtualBox.
>>>>>
>>>>> That creates a strong presumption that we are indeed dealing with a
>>>>> Windows related issue, such as the horrible Windows file naming.
>>>>>
>>>>> The first error in the log is:
>>>>>
>>>>> [java] com.sun.jini.qa.harness.TestException: Unexpected exception
>>>>> starting service; nested exception is:
>>>>> [java] Problem creating service for sharedGroupImpl; nested exception
>>>>> is:
>>>>> [java] exception constructing object; nested exception is:
>>>>> [java] java.lang.SecurityException: ProtectionDomain ProtectionDomain
>>>>> (file:/C:/apache2/River/lib/group.jar <no signer certificates>)
>>>>> [java] null
>>>>> [java] <no principals>
>>>>>
>>>>> The failure is during set-up, so it is quite likely that a lot of
>>>>> tests are affected by the same problem.
>>>>>
>>>>> Any advice on how to check the signer certificates?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Patricia
>>>>>
>>>>>
>>>>>
>>>>
>>>> Your failure isn't caused by <no signer certificates>, that's just
>>>> information printed from the ProtectionDomain, did the failing
>>>> ProtectionDomain list the Permissions?
>>>>
>>>> What was the Permission that failed?
>>>>
>>>> When ProtectionDomain.toString is called, it merges the dynamic
>>>> Permissions from the policy with the static Permissions in the
>>>> ProtectionDomain and prints them all out, useful for debugging.
>>
>> I'm not 100% sure how to answer the question, so I've uploaded the
>> output as http://www.patriciashanahan.com/apache/failingTest.txt
>>
>>> I wonder if the policy file has a Permission grant with a bad path?
>>> That
>>> might explain the missing permission.
>>>
>>
>> Are path comparisons done using the File equals method, or String
>> equals?
>>
>> Patricia
>>
>>
Neither, it uses FilePermission.implies(Permission) internally.
Cheers,
Peter.
>
> The permission that's failing is:
>
> does not have required permission:
> (com.sun.jini.start.SharedActivationPolicyPermission
> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
>
> Interestingly the policy has not resolved:
>
> (unresolved com.sun.jini.start.SharedActivationPolicyPermission
> file:C:\apache2\River\qa\harness\policy\defaultgroup.policy null)
> [java] (unresolved
> com.sun.jini.start.SharedActivationPolicyPermission
> file:C:\apache2\River\qa\harness\policy\policy.all null)
> [java] (unresolved
> com.sun.jini.start.SharedActivationPolicyPermission
> file:C:\apache2\River\qa\harness\policy\all.policy null)
> [java] (unresolved
> com.sun.jini.start.SharedActivationPolicyPermission
> file:C:\apache2\River\qa\harness\policy\sec-jeri-group.policy null)
> [java] (unresolved
> com.sun.jini.start.SharedActivationPolicyPermission
> jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/defaultgroup.policy
> null)
> [java] (unresolved
> com.sun.jini.start.SharedActivationPolicyPermission
> jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/policy.all
> null)
> [java] (unresolved
> com.sun.jini.start.SharedActivationPolicyPermission
> jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/all.policy
> null)
> [java] (unresolved
> com.sun.jini.start.SharedActivationPolicyPermission
> jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/sec-jeri-group.policy
> null)
>
> This means that the class
> com.sun.jini.start.SharedActivationPolicyPermission was not visible to
> the policy file implementation, which is normal, since it is loaded by
> the parent java extension classloader.
>
> What isn't normal however is the SharedActivationPolicyPermission
> should later be resolved when Policy.implies(ProtectionDomain,
> Permission) is called.
>
> As you can see from the output, the policy has been read correctly and
> has the needed permission, albeit unresolved.
>
> This tends to indicate that there may be a class path issue with
> start.jar
>
> Hope this helps.
>
> Cheers,
>
> Peter.
>
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Peter Firmstone <ji...@zeus.net.au>.
Patricia Shanahan wrote:
> On 11/20/2010 2:40 PM, Peter Firmstone wrote:
>> Peter Firmstone wrote:
>>> Patricia Shanahan wrote:
>>>> On 11/19/2010 10:06 AM, Sim IJskes - QCG wrote:
>>>>> On 11/19/2010 06:20 PM, Apache Hudson Server wrote:
>>>>>> See<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
>>>>>
>>>>>> [java] # of tests started = 1410
>>>>>> [java] # of tests completed = 1410
>>>>>> [java] # of tests skipped = 46
>>>>>> [java] # of tests passed = 1363
>>>>>> [java] # of tests failed = 47
>>>>>
>>>>> https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk/trunk/qa/result/index.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Some tests failed on policy permissions (so it looks), any change
>>>>> that
>>>>> this is windows related? slash vs backslash and driveletter?
>>>>
>>>> I have run the first failing test,
>>>> com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest.td,
>>>> under WindowsXP, and reproduced the failure. The test passes on an
>>>> identical checkout, compiled and run with the same JDK version, on a
>>>> Ubuntu VirtualBox.
>>>>
>>>> That creates a strong presumption that we are indeed dealing with a
>>>> Windows related issue, such as the horrible Windows file naming.
>>>>
>>>> The first error in the log is:
>>>>
>>>> [java] com.sun.jini.qa.harness.TestException: Unexpected exception
>>>> starting service; nested exception is:
>>>> [java] Problem creating service for sharedGroupImpl; nested exception
>>>> is:
>>>> [java] exception constructing object; nested exception is:
>>>> [java] java.lang.SecurityException: ProtectionDomain ProtectionDomain
>>>> (file:/C:/apache2/River/lib/group.jar <no signer certificates>)
>>>> [java] null
>>>> [java] <no principals>
>>>>
>>>> The failure is during set-up, so it is quite likely that a lot of
>>>> tests are affected by the same problem.
>>>>
>>>> Any advice on how to check the signer certificates?
>>>>
>>>> Thanks,
>>>>
>>>> Patricia
>>>>
>>>>
>>>>
>>>
>>> Your failure isn't caused by <no signer certificates>, that's just
>>> information printed from the ProtectionDomain, did the failing
>>> ProtectionDomain list the Permissions?
>>>
>>> What was the Permission that failed?
>>>
>>> When ProtectionDomain.toString is called, it merges the dynamic
>>> Permissions from the policy with the static Permissions in the
>>> ProtectionDomain and prints them all out, useful for debugging.
>
> I'm not 100% sure how to answer the question, so I've uploaded the
> output as http://www.patriciashanahan.com/apache/failingTest.txt
>
>> I wonder if the policy file has a Permission grant with a bad path? That
>> might explain the missing permission.
>>
>
> Are path comparisons done using the File equals method, or String equals?
>
> Patricia
>
>
The permission that's failing is:
does not have required permission: (com.sun.jini.start.SharedActivationPolicyPermission file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
Interestingly the policy has not resolved:
(unresolved com.sun.jini.start.SharedActivationPolicyPermission file:C:\apache2\River\qa\harness\policy\defaultgroup.policy null)
[java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission file:C:\apache2\River\qa\harness\policy\policy.all null)
[java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission file:C:\apache2\River\qa\harness\policy\all.policy null)
[java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission file:C:\apache2\River\qa\harness\policy\sec-jeri-group.policy null)
[java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/defaultgroup.policy null)
[java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/policy.all null)
[java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/all.policy null)
[java] (unresolved com.sun.jini.start.SharedActivationPolicyPermission jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/sec-jeri-group.policy null)
This means that the class
com.sun.jini.start.SharedActivationPolicyPermission was not visible to
the policy file implementation, which is normal, since it is loaded by
the parent java extension classloader.
What isn't normal however is the SharedActivationPolicyPermission should
later be resolved when Policy.implies(ProtectionDomain, Permission) is
called.
As you can see from the output, the policy has been read correctly and
has the needed permission, albeit unresolved.
This tends to indicate that there may be a class path issue with start.jar
Hope this helps.
Cheers,
Peter.
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/20/2010 2:40 PM, Peter Firmstone wrote:
> Peter Firmstone wrote:
>> Patricia Shanahan wrote:
>>> On 11/19/2010 10:06 AM, Sim IJskes - QCG wrote:
>>>> On 11/19/2010 06:20 PM, Apache Hudson Server wrote:
>>>>> See<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
>>>>
>>>>> [java] # of tests started = 1410
>>>>> [java] # of tests completed = 1410
>>>>> [java] # of tests skipped = 46
>>>>> [java] # of tests passed = 1363
>>>>> [java] # of tests failed = 47
>>>>
>>>> https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk/trunk/qa/result/index.html
>>>>
>>>>
>>>>
>>>> Some tests failed on policy permissions (so it looks), any change that
>>>> this is windows related? slash vs backslash and driveletter?
>>>
>>> I have run the first failing test,
>>> com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest.td,
>>> under WindowsXP, and reproduced the failure. The test passes on an
>>> identical checkout, compiled and run with the same JDK version, on a
>>> Ubuntu VirtualBox.
>>>
>>> That creates a strong presumption that we are indeed dealing with a
>>> Windows related issue, such as the horrible Windows file naming.
>>>
>>> The first error in the log is:
>>>
>>> [java] com.sun.jini.qa.harness.TestException: Unexpected exception
>>> starting service; nested exception is:
>>> [java] Problem creating service for sharedGroupImpl; nested exception
>>> is:
>>> [java] exception constructing object; nested exception is:
>>> [java] java.lang.SecurityException: ProtectionDomain ProtectionDomain
>>> (file:/C:/apache2/River/lib/group.jar <no signer certificates>)
>>> [java] null
>>> [java] <no principals>
>>>
>>> The failure is during set-up, so it is quite likely that a lot of
>>> tests are affected by the same problem.
>>>
>>> Any advice on how to check the signer certificates?
>>>
>>> Thanks,
>>>
>>> Patricia
>>>
>>>
>>>
>>
>> Your failure isn't caused by <no signer certificates>, that's just
>> information printed from the ProtectionDomain, did the failing
>> ProtectionDomain list the Permissions?
>>
>> What was the Permission that failed?
>>
>> When ProtectionDomain.toString is called, it merges the dynamic
>> Permissions from the policy with the static Permissions in the
>> ProtectionDomain and prints them all out, useful for debugging.
I'm not 100% sure how to answer the question, so I've uploaded the
output as http://www.patriciashanahan.com/apache/failingTest.txt
> I wonder if the policy file has a Permission grant with a bad path? That
> might explain the missing permission.
>
Are path comparisons done using the File equals method, or String equals?
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Peter Firmstone <ji...@zeus.net.au>.
Peter Firmstone wrote:
> Patricia Shanahan wrote:
>> On 11/19/2010 10:06 AM, Sim IJskes - QCG wrote:
>>> On 11/19/2010 06:20 PM, Apache Hudson Server wrote:
>>>> See<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
>>>
>>>> [java] # of tests started = 1410
>>>> [java] # of tests completed = 1410
>>>> [java] # of tests skipped = 46
>>>> [java] # of tests passed = 1363
>>>> [java] # of tests failed = 47
>>>
>>> https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk/trunk/qa/result/index.html
>>>
>>>
>>>
>>> Some tests failed on policy permissions (so it looks), any change that
>>> this is windows related? slash vs backslash and driveletter?
>>
>> I have run the first failing test,
>> com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest.td,
>> under WindowsXP, and reproduced the failure. The test passes on an
>> identical checkout, compiled and run with the same JDK version, on a
>> Ubuntu VirtualBox.
>>
>> That creates a strong presumption that we are indeed dealing with a
>> Windows related issue, such as the horrible Windows file naming.
>>
>> The first error in the log is:
>>
>> [java] com.sun.jini.qa.harness.TestException: Unexpected
>> exception starting service; nested exception is:
>> [java] Problem creating service for sharedGroupImpl; nested
>> exception is:
>> [java] exception constructing object; nested exception is:
>> [java] java.lang.SecurityException: ProtectionDomain
>> ProtectionDomain (file:/C:/apache2/River/lib/group.jar <no signer
>> certificates>)
>> [java] null
>> [java] <no principals>
>>
>> The failure is during set-up, so it is quite likely that a lot of
>> tests are affected by the same problem.
>>
>> Any advice on how to check the signer certificates?
>>
>> Thanks,
>>
>> Patricia
>>
>>
>>
>
> Your failure isn't caused by <no signer certificates>, that's just
> information printed from the ProtectionDomain, did the failing
> ProtectionDomain list the Permissions?
>
> What was the Permission that failed?
>
> When ProtectionDomain.toString is called, it merges the dynamic
> Permissions from the policy with the static Permissions in the
> ProtectionDomain and prints them all out, useful for debugging.
>
> Peter.
>
I wonder if the policy file has a Permission grant with a bad path?
That might explain the missing permission.
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Peter Firmstone <ji...@zeus.net.au>.
Patricia Shanahan wrote:
> On 11/19/2010 10:06 AM, Sim IJskes - QCG wrote:
>> On 11/19/2010 06:20 PM, Apache Hudson Server wrote:
>>> See<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
>>
>>> [java] # of tests started = 1410
>>> [java] # of tests completed = 1410
>>> [java] # of tests skipped = 46
>>> [java] # of tests passed = 1363
>>> [java] # of tests failed = 47
>>
>> https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk/trunk/qa/result/index.html
>>
>>
>>
>> Some tests failed on policy permissions (so it looks), any change that
>> this is windows related? slash vs backslash and driveletter?
>
> I have run the first failing test,
> com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest.td, under
> WindowsXP, and reproduced the failure. The test passes on an identical
> checkout, compiled and run with the same JDK version, on a Ubuntu
> VirtualBox.
>
> That creates a strong presumption that we are indeed dealing with a
> Windows related issue, such as the horrible Windows file naming.
>
> The first error in the log is:
>
> [java] com.sun.jini.qa.harness.TestException: Unexpected
> exception starting service; nested exception is:
> [java] Problem creating service for sharedGroupImpl; nested
> exception is:
> [java] exception constructing object; nested exception is:
> [java] java.lang.SecurityException: ProtectionDomain
> ProtectionDomain (file:/C:/apache2/River/lib/group.jar <no signer
> certificates>)
> [java] null
> [java] <no principals>
>
> The failure is during set-up, so it is quite likely that a lot of
> tests are affected by the same problem.
>
> Any advice on how to check the signer certificates?
>
> Thanks,
>
> Patricia
>
>
>
Your failure isn't caused by <no signer certificates>, that's just
information printed from the ProtectionDomain, did the failing
ProtectionDomain list the Permissions?
What was the Permission that failed?
When ProtectionDomain.toString is called, it merges the dynamic
Permissions from the policy with the static Permissions in the
ProtectionDomain and prints them all out, useful for debugging.
Peter.
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/19/2010 10:06 AM, Sim IJskes - QCG wrote:
> On 11/19/2010 06:20 PM, Apache Hudson Server wrote:
>> See<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
>
>> [java] # of tests started = 1410
>> [java] # of tests completed = 1410
>> [java] # of tests skipped = 46
>> [java] # of tests passed = 1363
>> [java] # of tests failed = 47
>
> https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk/trunk/qa/result/index.html
>
>
> Some tests failed on policy permissions (so it looks), any change that
> this is windows related? slash vs backslash and driveletter?
I have run the first failing test,
com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest.td, under
WindowsXP, and reproduced the failure. The test passes on an identical
checkout, compiled and run with the same JDK version, on a Ubuntu
VirtualBox.
That creates a strong presumption that we are indeed dealing with a
Windows related issue, such as the horrible Windows file naming.
The first error in the log is:
[java] com.sun.jini.qa.harness.TestException: Unexpected exception
starting service; nested exception is:
[java] Problem creating service for sharedGroupImpl; nested
exception is:
[java] exception constructing object; nested exception is:
[java] java.lang.SecurityException: ProtectionDomain
ProtectionDomain (file:/C:/apache2/River/lib/group.jar <no signer
certificates>)
[java] null
[java] <no principals>
The failure is during set-up, so it is quite likely that a lot of tests
are affected by the same problem.
Any advice on how to check the signer certificates?
Thanks,
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/19/2010 06:20 PM, Apache Hudson Server wrote:
> See<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
> [java] # of tests started = 1410
> [java] # of tests completed = 1410
> [java] # of tests skipped = 46
> [java] # of tests passed = 1363
> [java] # of tests failed = 47
https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk/trunk/qa/result/index.html
Some tests failed on policy permissions (so it looks), any change that
this is windows related? slash vs backslash and driveletter?
Gr. Sim
Build failed in Hudson: River-trunk-QA-windows #7
Posted by Apache Hudson Server <hu...@hudson.apache.org>.
See <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
------------------------------------------
[...truncated 10876 lines...]
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeIfExistsTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeIfExistsWaitTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeNO_WAITTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeReadTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeWaitTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteLeaseANYTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteLeaseFOREVERTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteNegativeLeaseTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteTakeIfExistsNotifyTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteTakeIfExistsTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteTakeNotifyTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteTakeTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotWriteLeaseANYTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotWriteLeaseFOREVERTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotWriteNegativeLeaseTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotWriteTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/AdminIFShutdownTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/AdminIFTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/LeaseExpireCancelTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/LeaseExpireRenewTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/LeaseMapTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/LeaseTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/MahaloCreateShutdownTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/MahaloIFTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/MahaloImplReadyStateTest.td
[java] Test Skipped: verifiers are: com.sun.jini.test.impl.mercury.ActivatableMercuryVerifier com.sun.jini.qa.harness.SkipConfigTestVerifier
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/NestableServerTransactionCreatedToStringTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/NestableTransactionCreatedToStringTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/PrepareAndCommitExceptionTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/PrepareAndCommitExceptionTest2.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/PrepareAndCommitExceptionTest3.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/PrepareAndCommitExceptionTest4.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/PrepareAndCommitExceptionTest5.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/RandomStressTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/ServerTransactionEqualityTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/ServerTransactionToStringTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TransactionCreatedToStringTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TransactionManagerCreatedToStringTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TxnMgrImplNullActivationConfigEntries.td
[java] Test Skipped: verifiers are: com.sun.jini.test.impl.mahalo.ActivatableMahaloVerifier
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TxnMgrImplNullConfigEntries.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TxnMgrImplNullRecoveredLocators.td
[java] Test Skipped: verifiers are: com.sun.jini.test.impl.mahalo.ActivatableMahaloVerifier
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TxnMgrProxyEqualityTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/AsynchAbortOnCommitTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/AsynchAbortOnPrepareTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/CommitExpiredTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/CommitTimeoutTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/GetStateTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/JoinIdempotentTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/JoinWhileActiveTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/ManyParticipantsTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/PrepareTimeoutTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/RollBackErrorTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/RollForwardErrorTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/TwoPhaseTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java]
[java] # of tests started = 1410
[java] # of tests completed = 1410
[java] # of tests skipped = 46
[java] # of tests passed = 1363
[java] # of tests failed = 47
[java]
[java] -----------------------------------------
[java]
[java] Date finished:
[java] Fri Nov 19 17:16:51 GMT 2010
[java] Time elapsed:
[java] 90295 seconds
[java]
[java] Java Result: 1
collect-result:
[copy] Copying 1 file to <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\qa\result>
[copy] Copying 1 file to <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\qa\result>
[zip] Building zip: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\qa\result\qaresults-amd64-Windows> Server 2008-1.6.0_17.zip
BUILD FAILED
<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\build.xml>:2065: The following error occurred while executing this line:
<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\qa\build.xml>:341: The following error occurred while executing this line:
<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\qa\build.xml>:315: condition satisfied
Total time: 1542 minutes 54 seconds
Publishing Javadoc
Archiving artifacts