Re: [JBoss-dev] [Fwd: "run-as" servlet directive and JBoss]
> We've been looking into implementing the servlet "run-as" tag for > Jetty/JBoss. > > So far, Greg has added the following methods to the > org.mortbay.http.UserRealm interface: > > >public UserPrincipal pushRole(UserPrincipal user, String role); >public UserPrincipal popRole(UserPrincipal user); > > The intention being to create a "new" principal, based on the old, > with a role added. The new principle is associated with the request > while it is within the run-as servlet. The popRole call ends this > association and should return either the original principal or another > equivalent principal stripped of the role (assuming it did not have it > in the first place). > This is not my interpretation of the run-as behavior. Rather, there needs to be a seperate principal identity that has only the run-as role. Below are sections from the servlet 2.3 and ejb 2.0 spec that talk about the run-as behavior. My interpretation is that the user defines the role to use for authorization, and the deployer has to configure the principal which will be used as the caller identity. There will need to be a jboss specific element that defines the principal to which the run-as role is associated. This principal and role are pushed as the thread of control security identity on entrace into the servlet and popped on exit. Only the current thread is affected for the scope the servlet request. The current change in UserRealm is probably fine. The security information available to the UserRealm implementation needs to be augmented to provide a servlet context to run-as information mapping. SRV.12.7 Propagation of Security Identity in EJB Calls A security identity, or principal, must always be provided for use in a call to an enterprise bean. The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the EJB container. In other scenarios, web containers are required to allow web users that are not known to the web container or to the EJB container to make calls: . Web containers are required to support access to web resources by clients that have not authenticated themselves to the container. This is the common mode of access to web resources on the Internet. . Application code may be the sole processor of signon and customization of data based on caller identity. In these scenarios, a web application deployment descriptor may specify a run-as element. When it is specified, the container must propagate the security identity of the caller to the EJB layer in terms of the security role name defined in the run-as element. The security role name must [be] one of the security role names defined for the web application. For web containers running as part of a J2EE platform, the use of run-as elements must be supported both for calls to EJB components within the same J2EE application, and for calls to EJB components deployed in other J2EE applications. The security principal under which a method invocation is performed is typically that of the component's caller. By specifying a run-as identity, however, it is possible to specify that a different principal be substituted for the execution of the methods of the bean's home and component interfaces and any methods of other enterprise beans that the bean may call. The Application Assembler specifies in the deployment descriptor whether the caller's security identity or a run-as security identity should be used for the execution of the bean's methods. See section 21.3.4. The Application Assembler should specify the requirements for the caller's principal management of enterprise bean invocations by means of the security-identity deployment descriptor element and as part of the description. If use-caller-identity is specified as the value of the security- identity element, the caller principal is propagated from the caller to the callee. (That is, the called enterprise bean will see the same returned value of the EJBContext.getCallerPrincipal() as the calling enterprise bean.) If the run-as element is specified, a security principal that has been assigned to the specified security role will be used for the execution of the bean's methods and will be visible as the caller principal in the callee. ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[2]: [JBoss-dev] ClassCastException for Stateful Session Bean
This error doesn't exist in the current CVS version. Thank you.
DJ> Please check if this is a problem against current cvs.
DJ> david jencks
DJ> On 2002.05.07 09:15:05 -0400 Alex Loubyansky wrote:
>> I have stateless session bean PublicSessionBean with ejb-ref to
>> stateful
>> session bean PrivateSessionBean. Like in JAAS example. (JAAS works
>> fine and I removed all security related stuff)
>> They have the same remote and home interfaces Session and
>> SessionHome (I tried also to define PrivateSession and
>> PrivateSessionHome for PrivateSessionBean)
>>
>> Method PublicSessionBean.echo(String arg):
>> public String echo(String arg) {
>> cat.info("call to echo(), arg=" + arg);
>> try {
>> InitialContext ctx = new InitialContext();
>> SessionHome home = (SessionHome)ctx.lookup("java:comp/env/ejb/PrivateSession");
>> Session bean = home.create();
>> cat.info("call to echo(), created PrivateSession");
>> arg = bean.echo(arg);
>> } catch(Exception e) {
>> cat.info("Exc while creating/invoking PrivateSession: " + e, e);
>> }
>> return arg;
>> }
>>
>> When it's deployed first time it works fine. But when I undeploy the
>> jar and then deploy it again I get this exception:
>> 2002-05-07 15:55:16,355 INFO [org.jboss.docs.jaas.howto.PublicSessionBean]
>> ejbCreate() called
>> 2002-05-07 15:55:16,365 INFO [org.jboss.docs.jaas.howto.PublicSessionBean]
>> call to echo(), arg=Hello
>> 2002-05-07 15:55:16,386 INFO [org.jboss.docs.jaas.howto.PublicSessionBean]
>> Exc while creating/invoking PrivateSession: java.lang.ClassCastException:
>> $Proxy22
>> java.lang.ClassCastException: $Proxy22
>> at
>org.jboss.docs.jaas.howto.PublicSessionBean.echo(PublicSessionBean.java:85)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:324)
>> at
>org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:653)
>> at
>org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:147)
>> at
>org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
>> at
>org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96)
>> at
>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167)
>> at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61)
>> at
>org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129)
>> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166)
>> at
>org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
>> at org.jboss.ejb.Container.invoke(Container.java:706)
>> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492)
>> at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:364)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:324)
>> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
>> at sun.rmi.transport.Transport$1.run(Transport.java:148)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
>> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
>> at
>sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
>> at java.lang.Thread.run(Thread.java:536)
>>
>> Environment: JBoss-3.1.0alpha checked about month ago, Win2000, JDK1.4
>>
>> Is it a bug? Was it reported?
>> What is the right place to post such errors users' list, developers'
>> list, bug report?
--
Best regards,
Alexmailto:[EMAIL PROTECTED]
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [Fwd: "run-as" servlet directive and JBoss]
Will this run-as thing replace thie PrivelegedAction - method of calling EJBs? On Tue, 2002-05-07 at 12:24, Jan Bartel wrote: > > The spec says: > "When it is specified, the container must propagate the security > identity of the caller to the EJB layer in terms of the security role > name defined in the run-as element." > > Hhhhmmm. Yep, you're right, it sounds like it should be a replace rather > than an augment (which is how I was thinking of it). > > Any comments Greg/Scott/Jules? > > Jan > > Luke Taylor wrote: > > Jan Bartel wrote: > > > >> > >> The intention being to create a "new" principal, based on the old, > >> with a role added. The new principle is associated with the request > >> while it is within the run-as servlet. The popRole call ends this > >> association and should return either the original principal or another > >> equivalent principal stripped of the role (assuming it did not have it > >> in the first place). > >> > > > > Is this the correct behaviour for "run-as"? I thought it was intended to > > replace the access rights of the delegated principal for the call rather > > than extending them? > > > > Luke. > > > > > > > > > ___ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ClassCastException for Stateful Session Bean
Please check if this is a problem against current cvs.
david jencks
On 2002.05.07 09:15:05 -0400 Alex Loubyansky wrote:
> I have stateless session bean PublicSessionBean with ejb-ref to
> stateful
> session bean PrivateSessionBean. Like in JAAS example. (JAAS works
> fine and I removed all security related stuff)
> They have the same remote and home interfaces Session and
> SessionHome (I tried also to define PrivateSession and
> PrivateSessionHome for PrivateSessionBean)
>
> Method PublicSessionBean.echo(String arg):
> public String echo(String arg) {
> cat.info("call to echo(), arg=" + arg);
> try {
> InitialContext ctx = new InitialContext();
> SessionHome home = (SessionHome)ctx.lookup("java:comp/env/ejb/PrivateSession");
> Session bean = home.create();
> cat.info("call to echo(), created PrivateSession");
> arg = bean.echo(arg);
> } catch(Exception e) {
> cat.info("Exc while creating/invoking PrivateSession: " + e, e);
> }
> return arg;
> }
>
> When it's deployed first time it works fine. But when I undeploy the
> jar and then deploy it again I get this exception:
> 2002-05-07 15:55:16,355 INFO [org.jboss.docs.jaas.howto.PublicSessionBean]
> ejbCreate() called
> 2002-05-07 15:55:16,365 INFO [org.jboss.docs.jaas.howto.PublicSessionBean]
> call to echo(), arg=Hello
> 2002-05-07 15:55:16,386 INFO [org.jboss.docs.jaas.howto.PublicSessionBean]
> Exc while creating/invoking PrivateSession: java.lang.ClassCastException:
> $Proxy22
> java.lang.ClassCastException: $Proxy22
> at
>org.jboss.docs.jaas.howto.PublicSessionBean.echo(PublicSessionBean.java:85)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at
>org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:653)
> at
>org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:147)
> at
>org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
> at
>org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96)
> at
>org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61)
> at
>org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166)
> at
>org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
> at org.jboss.ejb.Container.invoke(Container.java:706)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492)
> at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:364)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> at sun.rmi.transport.Transport$1.run(Transport.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> at
>sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> at java.lang.Thread.run(Thread.java:536)
>
> Environment: JBoss-3.1.0alpha checked about month ago, Win2000, JDK1.4
>
> Is it a bug? Was it reported?
> What is the right place to post such errors users' list, developers'
> list, bug report?
>
> TIA,
> Alex
>
>
>
> ___
>
> Have big pipes? SourceForge.net is looking for download mirrors. We
> supply
> the hardware. You get the recognition. Email Us:
> [EMAIL PROTECTED]
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug: Dynamic Topic not being destroyed in all cases
Please log a bug report at http://sf.net/projects/jboss >From: mary <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: [JBoss-dev] Bug: Dynamic Topic not being destroyed in all cases >Date: Mon, 6 May 2002 17:58:43 -0500 > >What I'm seeing appears to be a bug: > >I have a message listener listening on a dynamically created topic, a MDB >publishing to that same topic, and a session bean that comes along and >deletes the topic. When the session bean tries to delete the dynamically >created topic however, the topic is only removed from JNDI and NOT >destroyed. This exception is thrown when deleting the topic fails: >"Stopping failed: javax.jms.JMSException: The destination is being used." > >Further messages in the server log say the topics been destroyed, but >listing the topics from the jmx web viewer verifies it has not been. > >I found this because I was trying to recreate the topic. JNDI lookups >failed, but createTopic() gave an InstanceAlreadyExistsException. > >Do I need to log this bug somewhere, or is this post good enough? > >Thanks, >Mary > >* * * > >View thread online: >http://jboss.org/forums/thread.jsp?forum=66&thread=14975 > >___ > >Have big pipes? SourceForge.net is looking for download mirrors. We supply >the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ClassCastException for Stateful Session Bean
I have stateless session bean PublicSessionBean with ejb-ref to stateful
session bean PrivateSessionBean. Like in JAAS example. (JAAS works
fine and I removed all security related stuff)
They have the same remote and home interfaces Session and
SessionHome (I tried also to define PrivateSession and
PrivateSessionHome for PrivateSessionBean)
Method PublicSessionBean.echo(String arg):
public String echo(String arg) {
cat.info("call to echo(), arg=" + arg);
try {
InitialContext ctx = new InitialContext();
SessionHome home = (SessionHome)ctx.lookup("java:comp/env/ejb/PrivateSession");
Session bean = home.create();
cat.info("call to echo(), created PrivateSession");
arg = bean.echo(arg);
} catch(Exception e) {
cat.info("Exc while creating/invoking PrivateSession: " + e, e);
}
return arg;
}
When it's deployed first time it works fine. But when I undeploy the
jar and then deploy it again I get this exception:
2002-05-07 15:55:16,355 INFO [org.jboss.docs.jaas.howto.PublicSessionBean]
ejbCreate() called
2002-05-07 15:55:16,365 INFO [org.jboss.docs.jaas.howto.PublicSessionBean] call to
echo(), arg=Hello
2002-05-07 15:55:16,386 INFO [org.jboss.docs.jaas.howto.PublicSessionBean] Exc while
creating/invoking PrivateSession: java.lang.ClassCastException: $Proxy22
java.lang.ClassCastException: $Proxy22
at org.jboss.docs.jaas.howto.PublicSessionBean.echo(PublicSessionBean.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:653)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:147)
at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166)
at
org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313)
at org.jboss.ejb.Container.invoke(Container.java:706)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:364)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:536)
Environment: JBoss-3.1.0alpha checked about month ago, Win2000, JDK1.4
Is it a bug? Was it reported?
What is the right place to post such errors users' list, developers'
list, bug report?
TIA,
Alex
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [Fwd: "run-as" servlet directive and JBoss]
The spec says: "When it is specified, the container must propagate the security identity of the caller to the EJB layer in terms of the security role name defined in the run-as element." Hhhhmmm. Yep, you're right, it sounds like it should be a replace rather than an augment (which is how I was thinking of it). Any comments Greg/Scott/Jules? Jan Luke Taylor wrote: > Jan Bartel wrote: > >> >> The intention being to create a "new" principal, based on the old, >> with a role added. The new principle is associated with the request >> while it is within the run-as servlet. The popRole call ends this >> association and should return either the original principal or another >> equivalent principal stripped of the role (assuming it did not have it >> in the first place). >> > > Is this the correct behaviour for "run-as"? I thought it was intended to > replace the access rights of the delegated principal for the call rather > than extending them? > > Luke. > > ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 7-May-2002
Number of tests run: 756 Successful tests: 593 Errors:149 Failures: 14 [time of test: 7 May 2002 9:26 GMT] [java.version: 1.4.0] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.0-b92] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_j2sdk140 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 7-May-2002
Number of tests run: 747 Successful tests: 584 Errors:150 Failures: 13 [time of test: 7 May 2002 8:21 GMT] [java.version: 1.3.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_02-b02] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131_02 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
