Re: [JBoss-dev] TODO: client side interceptors
On Wed, 30 Jan 2002, marc fleury wrote: Bill got my hear yesterday where he pitched the interceptor design on the 3.0 client side. Instant love. We are not that far from it in fact, it a bit of renaming and factory game on the server. Essentially the client does Generic Proxy - Handler - EJB behavior - Transport In the transport layer we extract the Tx and Security information. The pitch was simple it had to do with moving GP-Handler-interceptor 1 (EJB behavior for example) -interceptor 2 (Tx extraction) - interceptor 3 (Security) - Transport (invoker). I'm glad to see, that jboss will support pluggable interceptors on the client side, now. You can do cool things with that. Think of: o tracing interceptor o profiling interceptor o caching interceptor (for getters) o invocation bundeling (send an array of method invocations and return an array of results .. all that in one user transaction) o exception discrimination for retry / reconnect (if not implemented in the transport already) o loadbalancing / failover for stateless sessionbeans (if not implemented in the transport already) o invocation recording and replaying (for restoring initial state after reconnect to a stateful sessionbean) o mobility !!! if the caller is a sessionbean, serialize it, move it to a container on the target, do local calls, return to the originating container o compression (zip the serialized invocations .. results are mostly disappointing, because reducing latency is much more importent than reducing data) o encryption / signing some of these interceptors add additional methods to the components interface / dynamic proxy: o ejb behaviour o recording o mobility o invocation bundeling invocations to these methods will be handled by the corresponding interceptors. Only the method invocations of the component's remote interface will reach the transport at the end of the interceptor chain. The (named) interceptor configuration should be chooseable for every ejb-ref. the interceptor configuration requirements of home interfaces might differ from that of the remote interfaces. Love it, Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TODO: client side interceptors
|OK. So that's the current state? What's the Handler in this context - is |that the JRMPInvokerProxy, for example? no we are talking about 3.0 the handler is one of the proxy classes with EJB behavior but disconnected from the transport (JRMP-Proxy was 2.0). The current state is that this has been factored and that the proxy should really be split in interceptors allowing for pluggability of writers to the payload. They expose invoke(Invocation) |So this is basically just moving the code that sets the security and |transaction contexts from the JRMPInvokerProxy and setting them in the |appropriate interceptors instead? yes, precisely. The trick is on the server setup and factories though. |What is the current situation with the IIOP transport and how will that |fit in with the generic proxy stuff and this stack of interceptors? you can use IIOP from the proxies. However most IIOP won't come from java clients hence no proxy. But yes the RMI/IIOP java invoker is kosher with that picture and will use the RMIIIOP port. |Presumably there will just be an IIOPInvoker instead, which will perform yes in the case of java client. | The factorization right behind it is on the server side. Where we | expose the ProxyFactory (already there in a primitive form) and | that PF can export any combination of (interfaces, stack of client | interceptors, transport) and generates the client for it. | |Do you mean the proxy.ejb.ProxyFactory? So this would provide a return a |proxy object which contained the appropriate client-side invocation |stack, based on the above jboss.xml configuration? yes precisely. |Would you be able to have multiple client-invocation stacks per container? sure we already have most of that behavior in place. (multiple invokers). note however that if there is an interceptor that is needed on the server then all clients must have it as well. Thus the invoker stack can only vary in transport, not in behavior introduced by the plugins. | This way for ANY MBean SAR that you deploy on the server you can | create proxies that exposes a pluggable behavior example you would | deploy your SAR and create clients with my proxy behavior that I | wrote for my client security ... no tx soap | | and the connectors on the server side will know to route your | message to the right mbean with the right security integration and | no tx for example. Voila instant framework distribution. | |Ummm. So here you're talking about deploying Mbeans as server components |which can be invoked by a remote client? I don't quite understand what |the advantage is. Why would you want to remotely invoke an Mbean rather |than just using an existing technology such as EJB to wrap it? You are correct we would need the transaction and security interceptors on the server side as well (which goes back to my call for real detached interceptors) but that is a bit early. I guess what I am saying is that the first example would be the EJB themselves (just rename the Proxy and split it up), then put the ProxyFactory that takes the stacks. It would provide a simple way for users to extend the client behavior by adding their custom information to the Invocation through interceptors they can easily configure. |Won't binding them into JNDI be sufficient? Are you likely to need |finders for MBeans? Are there many situations where you would have |keyed MBeans? I thought they were basically services - though I'm sure |Juha can come up with many other uses for them :). they are essentially singletons yes. But since the first application of this would be the EJBs themselves I think we don't need to worry about the registration. We only provide a ProxyFactory with externalized client interceptor stacks. That's all. It's an MBean people can use. It is pretty powerful, let them come and ask for the registration.. just the factory would be a huge step. |Sorry for all the questions, but I usually need things spelt out to get |an understanding of what's going on. aren't you supposed to be working on something else ;-) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-511164 ] persistent messages not being restored
Bugs item #511164, was opened at 2002-01-31 04:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511164group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Christian Riege (lqd) Assigned to: Nobody/Anonymous (nobody) Summary: persistent messages not being restored Initial Comment: Summary: Persistent messages sent to a Queue are not being restored upon server restart. How to reproduce: send a message to a pre-defined Queue (e.g. queue/A). Shutdown the server. Start the server. The message is still on the disk (in db/jbossmq/QUEUE.A) but it will not be sent to a MessageReceiver. I've only tested this with the file-based PM but the problem seems to be independent of the PM. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511164group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-511172 ] persistent messages not being restored
Bugs item #511172, was opened at 2002-01-31 04:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511172group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Christian Riege (lqd) Assigned to: Nobody/Anonymous (nobody) Summary: persistent messages not being restored Initial Comment: Summary: Persistent messages sent to a Queue are not being restored upon server restart. How to reproduce: send a message to a pre-defined Queue (e.g. queue/A). Shutdown the server. Start the server. The message is still on the disk (in db/jbossmq/QUEUE.A) but it will not be sent to a MessageReceiver. I've only tested this with the file-based PM but the problem seems to be independent of the PM. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511172group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-511172 ] persistent messages not being restored
Bugs item #511172, was opened at 2002-01-31 04:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511172group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: Duplicate Priority: 7 Submitted By: Christian Riege (lqd) Assigned to: Nobody/Anonymous (nobody) Summary: persistent messages not being restored Initial Comment: Summary: Persistent messages sent to a Queue are not being restored upon server restart. How to reproduce: send a message to a pre-defined Queue (e.g. queue/A). Shutdown the server. Start the server. The message is still on the disk (in db/jbossmq/QUEUE.A) but it will not be sent to a MessageReceiver. I've only tested this with the file-based PM but the problem seems to be independent of the PM. -- Comment By: Christian Riege (lqd) Date: 2002-01-31 04:53 Message: Logged In: YES user_id=176671 sorry for double entry -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511172group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file TxLog.java
User: lqd Date: 02/01/31 05:01:39 Removed: src/main/org/jboss/mq/pm/file Tag: Branch_2_4 TxLog.java Log: - this class is never used ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server QueueManager.java
User: lqd
Date: 02/01/31 05:14:42
Modified:src/main/org/jboss/mq/server Tag: Branch_2_4
QueueManager.java
Log:
- re-setup logger to use the Queue's name in logging output
Revision ChangesPath
No revision
No revision
1.2.2.2 +43 -16jbossmq/src/main/org/jboss/mq/server/QueueManager.java
Index: QueueManager.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/QueueManager.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- QueueManager.java 2001/08/23 03:57:12 1.2.2.1
+++ QueueManager.java 2002/01/31 13:14:41 1.2.2.2
@@ -21,6 +21,7 @@
import org.jboss.mq.*;
import org.jboss.util.ServiceMBeanSupport;
+import org.jboss.logging.Logger;
/**
* This class is a message queue which is stored (hashed by Destination) on the
@@ -29,36 +30,43 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
-public class QueueManager extends org.jboss.util.ServiceMBeanSupport implements
QueueManagerMBean {
+public class QueueManager
+ extends org.jboss.util.ServiceMBeanSupport
+ implements QueueManagerMBean
+{
JMSQueue destination;
SpyQueue queue;
String queueName;
- public String getName() {
+ public String getName()
+ {
return JBossMQQueue;
}
/**
-* Insert the method's description here. Creation date: (7/1/2001 11:30:33
-* AM)
+* Get the name of the Queue
*
* @returnjava.lang.String
*/
- public java.lang.String getQueueName() {
+ public java.lang.String getQueueName()
+ {
return queueName;
}
public int getQueueDepth()
- throws Exception {
+ throws Exception
+ {
return destination.queue.messages.size();
}
public void initService()
- throws Exception {
+ throws Exception
+ {
- if ( queueName == null || queueName.length() == 0 ) {
+ if ( queueName == null || queueName.length() == 0 )
+ {
throw new Exception( QueueName was not set );
}
@@ -67,20 +75,30 @@
queue = new SpyQueue( queueName );
destination = new JMSQueue( queue, null, server );
- server.addDestination( queue, destination );
+ try
+ {
+ server.addDestination( queue, destination );
+ // server.getPersistenceManager().restoreQueue( destination, queue );
+ } catch ( JMSException e )
+ {
+ log.warn( Couldn't add queue: + e.getMessage() );
+ }
- }
+ }
public void startService()
- throws Exception {
+ throws Exception
+ {
//Get an InitialContext
InitialContext ctx = new InitialContext();
javax.naming.Context subctx;
- try {
+ try
+ {
subctx = ( javax.naming.Context )ctx.lookup( queue );
- } catch ( javax.naming.NamingException e ) {
+ } catch ( javax.naming.NamingException e )
+ {
subctx = ctx.createSubcontext( queue );
}
subctx.rebind( queueName, queue );
@@ -88,11 +106,20 @@
}
protected ObjectName getObjectName( MBeanServer server, ObjectName name )
- throws javax.management.MalformedObjectNameException {
+ throws javax.management.MalformedObjectNameException
+ {
queueName = name.getKeyProperty( name );
- if ( queueName == null || queueName.length() == 0 ) {
+ if ( queueName == null || queueName.length() == 0 )
+ {
throw new MalformedObjectNameException( Property 'name' not provided );
}
+
+ // re-setup the logger with a more descriptive name
+ log = Logger.getLogger(getClass().getName() + # + queueName);
+
return name;
}
}
+/*
+vim:tabstop=3:expandtab:shiftwidth=3
+*/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-511172 ] persistent messages not being restored
Bugs item #511172, was opened at 2002-01-31 04:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511172group_id=22866 Category: JBossMQ Group: v2.4 (stable) Status: Open Resolution: Duplicate Priority: 7 Submitted By: Christian Riege (lqd) Assigned to: Nobody/Anonymous (nobody) Summary: persistent messages not being restored Initial Comment: Summary: Persistent messages sent to a Queue are not being restored upon server restart. How to reproduce: send a message to a pre-defined Queue (e.g. queue/A). Shutdown the server. Start the server. The message is still on the disk (in db/jbossmq/QUEUE.A) but it will not be sent to a MessageReceiver. I've only tested this with the file-based PM but the problem seems to be independent of the PM. -- Comment By: Christian Riege (lqd) Date: 2002-01-31 05:30 Message: Logged In: YES user_id=176671 sorry for double entry -- Comment By: Christian Riege (lqd) Date: 2002-01-31 04:53 Message: Logged In: YES user_id=176671 sorry for double entry -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511172group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-510397 ] PrimaryKey Classes and Marshalling
Bugs item #510397, was opened at 2002-01-29 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=510397group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: William A. Kaufman (wkaufman) Assigned to: Nobody/Anonymous (nobody) Summary: PrimaryKey Classes and Marshalling Initial Comment: The hashCode and equals methods implemented by PrimaryKey classes are not used by JBoss (at least by default - see the CacheKey class). Instead, the hashCode and equals of the MarshalledObject constructed from the PK is used. This is fine if the serialization is done correctly (ie readObject() has been implemented right). Unfortunately, the BigInteger implementation in jdk1.3.1 has a number of fields that either should have been declared transient, or ... (your solution here). The upshot is if you use BigInteger (or BigDecimal - it has a BigInteger inside it) as your PK class or as part of your PK class, you are not guaranteed that the MarshalledObject hashcode will be unique. This is bad news for the entity caching in JBoss 2.4.4 (haven't looked at 3.0, but I assume it's the same). Attached is a simple test to illustrate the problem. This problem bit us pretty hard. A bug report's been filed with Sun. -- Comment By: William A. Kaufman (wkaufman) Date: 2002-01-31 06:28 Message: Logged In: YES user_id=262957 I forgot to mention that this problem was introduced to maintain compatability with pre-1.3 jdk's. Here's a comment in the BigInteger readObject method: /* * In order to maintain compatibility with previous serialized forms, * the magnitude of a BigInteger is serialized as an array of bytes. * The magnitude field is used as a temporary store for the byte array * that is deserialized. The cached computation fields should be * transient but are serialized for compatibility reasons. */ A work-around is to serialize and de-serialize the BigInteger to ensure that cached computation fields of BigInteger (bitCount, bitLength, lowestSetBit, firstNonzeroByteNum, and firstNonzeroIntNum) have all been reset to their initial values. A kluge. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=510397group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TODO: client side interceptors
olger Engels wrote: I'm glad to see, that jboss will support pluggable interceptors on the client side, now. You can do cool things with that. Think of: ... o caching interceptor (for getters) How will that work in practice? Aren't the interceptors stateless, without being specific to a particular EJB/component instance? o invocation bundeling (send an array of method invocations and return an array of results .. all that in one user transaction) I don't quite get that either - interceptors are meant to be transparent to the client code. So how could a client make multiple (sequential) invocations and have them bundled into a single request? ... o mobility !!! if the caller is a sessionbean, serialize it, move it to a container on the target, do local calls, return to the originating container Eeek! ... o encryption / signing If the proxies and interceptor stack are dynamically downloaded, how is the security of the downloaded classes assured? Can the classes be loaded over SSL? Or can they be signed so the client can verify their origin? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [jetty-discuss] Re: [JBoss-dev] Jetty3.1.5, Axis Basic Authentication Problem
Greg, Jules, Luke! thx much for your replies. Indeed, the '*' role authentication constraint seems to match my issue very well if it also lets through null-authenticated/credential calls ... If I can help to patch SecurityHandler (jetty4 or backport to jetty3, perhaps), please let me know. Otherwise, I would be glad if you could send me a notification when it is available ... Thnx much, CGJ -Ursprüngliche Nachricht- Von: Greg Wilkins [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 31. Januar 2002 01:31 An: Luke Taylor Cc: 'Jboss-Development ([EMAIL PROTECTED])'; [EMAIL PROTECTED] Betreff: Re: [jetty-discuss] Re: [JBoss-dev] Jetty3.1.5, Axis Basic Authentication Problem Luke, I stand corrected. It is the '*' role behaviour that should be used. The lack of any role means no access.I knew the 2.3 spec had defined both these cases, but got them mixed up. Jetty4 will definitely support this style of security constraint soon. I think Jetty3 can also be made to support this without breaking any existing code (but I'll think about this a bit more before changing this). thanks Luke Taylor wrote: Greg Wilkins wrote: Cristoph, Eitherway, you do not want the semantics of NONE, you want the user to be authenticated, but you do not care what group they are in. Again, Jetty has an extension to the spec to support this. All users are in the role org.mortbay.http.User. However this is implemented in the HashUserRealm which is not used by JBoss. So for now, you must define a role that all your JBoss users are in and specify an AuthConstraint for that role. Hi Greg, Wouldn't this be the same as using * for the role-name? I had a brief look at the servlet 2.3 spec before replying previously and that's the syntax it uses for all roles. So it should then perform authentication and allow any user who has a role recognised by the application. Luke. -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAAS with MDB
It actually goes a little furthur than that. I first tried to take out
the security interceptor in the MDB interceptior chain. This works fine
util your message bean then tries to call another EJB. So it would seem
that the Security Interceptor needs to just act as a login for the MDB.
Scott M Stark wrote:
MDBs need a different SecurityInterceptor that does not attempt
to authenticate the caller as there is none defined. An extension
would allow the caller to be obtained from JMS message properties.
The properties could be specified in the jboss.xml descriptor in
the message-driven bean section.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Dave Smith [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 29, 2002 2:08 PM
Subject: [JBoss-dev] JAAS with MDB
I am trying to get a MDB working with JAAS. Currently when message
delivery is attempted it throws an error Authentication exception,
principal=null. Now in the jms-service.xml I have added
attribute name=PrincipalMappingProperties
UserName=jboss
Password=jboss1
/attribute
but this does not do anything. I can not find any refences to this in
either the free or purchased docs. Can some one point me in the right
direction.
time passes ...
After further investigation it looks like it is not implemented. In the
JMSContainerInvoker it creates the method invocation with principal and
credential = null. Then when the SecurityInterceptor gets a hold of it
barfs. The snip, line 976 of JMSContainerInvoker.java
invoker.invoke(id,
// Object id - where used?
ON_MESSAGE,
// Method to invoke
new Object[]{message},
// argument
tm.getTransaction(),
// Transaction
null,
// Principal
null);
// Cred
How should I go about getting this to work?
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TODO: client side interceptors
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Luke Taylor Sent: Thursday, January 31, 2002 9:32 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] TODO: client side interceptors olger Engels wrote: I'm glad to see, that jboss will support pluggable interceptors on the client side, now. You can do cool things with that. Think of: ... o caching interceptor (for getters) How will that work in practice? Aren't the interceptors stateless, without being specific to a particular EJB/component instance? Well, on the server side, the interceptor chain is uniquely attached to each container. On the client side, you could have a unique interceptor chain(instances in memory) attached to each and every proxy. I really like this idea for EntityBeans. Could be kinda cool. Of course, we'd have to expand on the metadata to describe this type of thing. o invocation bundeling (send an array of method invocations and return an array of results .. all that in one user transaction) I don't quite get that either - interceptors are meant to be transparent to the client code. So how could a client make multiple (sequential) invocations and have them bundled into a single request? You're right here. EJBs have no asynchronous interface like CORBA object do. Plus, in EJB the request is not exposed like in CORBA as well. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAAS with MDB
Which is what I mean by MDBs needing a different SecurityInterceptor. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dave Smith [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 7:47 AM Subject: Re: [JBoss-dev] JAAS with MDB It actually goes a little furthur than that. I first tried to take out the security interceptor in the MDB interceptior chain. This works fine util your message bean then tries to call another EJB. So it would seem that the Security Interceptor needs to just act as a login for the MDB. Scott M Stark wrote: MDBs need a different SecurityInterceptor that does not attempt to authenticate the caller as there is none defined. An extension would allow the caller to be obtained from JMS message properties. The properties could be specified in the jboss.xml descriptor in the message-driven bean section. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-511280 ] principal=null after bean passivation
Bugs item #511280, was opened at 2002-01-31 08:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511280group_id=22866 Category: JBossSX Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Annegret Sternagel (annegret) Assigned to: Nobody/Anonymous (nobody) Summary: principal=null after bean passivation Initial Comment: WindowsNT /Windows2000 JDK 1.3.0,Sun Microsystems Inc. jboss-2.4.3 I have two secured StatefulSessionBeans: bean1 (StatefulSession1) and bean2 (StatefulSession). Bean1 initializes and holds a reference of the RemoteInterface of bean2. After scheduled passivation of bean1 AND bean2 the SecurityAssociation of bean2 is lost: [Default] Bad password for username=null [StatefulSession] Authentication exception, principal=null [StatefulSession] TRANSACTION ROLLBACK EXCEPTION:checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null; nested exception is: java.rmi.RemoteException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null [StatefulSession] java.rmi.RemoteException: checkSecurityAssociation; nested exception is: [StatefulSession] java.lang.SecurityException: Authentication exception, principal=null [StatefulSession] java.lang.SecurityException: Authentication exception, principal=null [StatefulSession] at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurity Association(SecurityInterceptor.java:168) [StatefulSession] at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome (SecurityInterceptor.java:92) [StatefulSession] at org.jboss.ejb.plugins.StatefulSessionInstanceIntercepto r.invokeHome (StatefulSessionInstanceInterceptor.java:123) [StatefulSession] at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext (TxInterceptorCMT.java:135) [StatefulSession] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:307) [StatefulSession] at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome (TxInterceptorCMT.java:86) [StatefulSession] at org.jboss.ejb.plugins.LogInterceptor.invokeHome (LogInterceptor.java:106) [StatefulSession] at org.jboss.ejb.StatefulSessionContainer.invokeHome (StatefulSessionContainer.java:326) [StatefulSession] at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker. invokeHome(JRMPContainerInvoker.java:372) [StatefulSession] at java.lang.reflect.Method.invoke(Native Method) [StatefulSession] at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:241) [StatefulSession] at sun.rmi.transport.Transport$1.run(Transport.java:142) [StatefulSession] at java.security.AccessController.doPrivileged(Native Method) [StatefulSession] at sun.rmi.transport.Transport.serviceCall (Transport.java:139) [StatefulSession] at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:443) [StatefulSession] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru n(TCPTransport.java:643) [StatefulSession] at java.lang.Thread.run (Thread.java:484) [StatefulSession1] TRANSACTION ROLLBACK EXCEPTION:Could not activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackExceptio n: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null; nested exception is: java.rmi.RemoteException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null; nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.rmi.ServerException: Could not get EJBObject; nested exception is: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackExceptio n: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null; nested exception is: java.rmi.RemoteException: checkSecurityAssociation; nested exception is: java.lang.SecurityException: Authentication exception, principal=null [StatefulSession1] java.rmi.NoSuchObjectException: Could not activate; nested exception is: [StatefulSession1] java.rmi.ServerException: Could not get EJBObject; nested exception is: [StatefulSession1] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [StatefulSession1] javax.transaction.TransactionRolledbackExceptio n: checkSecurityAssociation; nested exception is: [StatefulSession1]
Re: [JBoss-dev] JAAS with MDB
So then in JMSContainerInvoker add the code to read the jboss metadata and then invoke the inteceptor chain with the appropreate princpal and credidentals? Or should the JMS message actually set properties in the message itself and a new Security Invoker to read this info and set the principal and credidents. I have some time today and tomorrow to take a crack at it. Scott M Stark wrote: Which is what I mean by MDBs needing a different SecurityInterceptor. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dave Smith [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 7:47 AM Subject: Re: [JBoss-dev] JAAS with MDB It actually goes a little furthur than that. I first tried to take out the security interceptor in the MDB interceptior chain. This works fine util your message bean then tries to call another EJB. So it would seem that the Security Interceptor needs to just act as a login for the MDB. Scott M Stark wrote: MDBs need a different SecurityInterceptor that does not attempt to authenticate the caller as there is none defined. An extension would allow the caller to be obtained from JMS message properties. The properties could be specified in the jboss.xml descriptor in the message-driven bean section. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TODO: client side interceptors
On Thu, 31 Jan 2002, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Luke Taylor Sent: Thursday, January 31, 2002 9:32 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] TODO: client side interceptors olger Engels wrote: I'm glad to see, that jboss will support pluggable interceptors on the client side, now. You can do cool things with that. Think of: ... o caching interceptor (for getters) How will that work in practice? Aren't the interceptors stateless, without being specific to a particular EJB/component instance? Well, on the server side, the interceptor chain is uniquely attached to each container. On the client side, you could have a unique interceptor chain(instances in memory) attached to each and every proxy. I really like this idea for EntityBeans. Could be kinda cool. Of course, we'd have to expand on the metadata to describe this type of thing. o invocation bundeling (send an array of method invocations and return an array of results .. all that in one user transaction) I don't quite get that either - interceptors are meant to be transparent to the client code. So how could a client make multiple (sequential) invocations and have them bundled into a single request? You're right here. EJBs have no asynchronous interface like CORBA object do. Plus, in EJB the request is not exposed like in CORBA as well. Some interceptors are transparent, others are not .. Let the dynamic proxy implement the remote interface and all additional interfaces of all interceptors, that add non transparent behaviour to the component. We have already three additional apis: o SecurityAssociation o UserTransaction o ejb methods only the last one is directly implemented by the dynamic proxy. security and transactions are somewhat transcendent/magic. A drawback of multiple interfaces is that you have to cast the object to these particular interfaces in order to use them. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAAS with MDB
Authentication and Authorization need to be two seperate security interceptors. Authentication needs to validate the principal and associate the Subject with the MethodInvocation. The Authorization interceptor will handle role based permissions and run-as identities. The default MDB interceptor chain should not include an Authentication interceptor. If the jboss.xml metadata is enchanced to allow for caller identity to be obtained from the JMS msg than the container invoker will associate this information with the call and the Authentication interceptor can be added to the interceptor chain. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dave Smith [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 8:56 AM Subject: Re: [JBoss-dev] JAAS with MDB So then in JMSContainerInvoker add the code to read the jboss metadata and then invoke the inteceptor chain with the appropreate princpal and credidentals? Or should the JMS message actually set properties in the message itself and a new Security Invoker to read this info and set the principal and credidents. I have some time today and tomorrow to take a crack at it. Scott M Stark wrote: Which is what I mean by MDBs needing a different SecurityInterceptor. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dave Smith [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 7:47 AM Subject: Re: [JBoss-dev] JAAS with MDB It actually goes a little furthur than that. I first tried to take out the security interceptor in the MDB interceptior chain. This works fine util your message bean then tries to call another EJB. So it would seem that the Security Interceptor needs to just act as a login for the MDB. Scott M Stark wrote: MDBs need a different SecurityInterceptor that does not attempt to authenticate the caller as there is none defined. An extension would allow the caller to be obtained from JMS message properties. The properties could be specified in the jboss.xml descriptor in the message-driven bean section. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-511343 ] WAR deployment error w/ JAR files in lib
Bugs item #511343, was opened at 2002-01-31 10:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511343group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Matt (mpetteys) Assigned to: Nobody/Anonymous (nobody) Summary: WAR deployment error w/ JAR files in lib Initial Comment: I am trying to deploy and EAR file which contains a WAR file which contains various JAR files in its WEB-INF/lib directory. When jboss, trying to deploy those jars it generates a FileNotFoundException and cannot deploy them.I can solve this by moving the jar files into the root of the WAR file and creating a META-INF\jboss-service.xml file that references them (like the following) but I believe the classloader is supposed to automatically pick up these jars for use in the web application. Attached is the server.log file. jboss-service.xml that can be used a ?xml version=1.0 encoding=UTF-8? server classpath archives=commons-beanutils.jar/ classpath archives=commons-collections.jar/ classpath archives=commons-digester.jar/ classpath archives=struts.jar/ /server -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511343group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Is WAR deployment broken?
Maybe I missed a message about this. But I am wondering, is war deployment broken? Here is all that gets logged about the war (when inside an EAR, or when placed directly in deploy) Auto deploying: file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war New UCL with url file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war Libraries adding UnifiedClassLoader -1615549336 key URL file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war NO DEPLOYER for url file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war Watching new file: file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war Done deploying proxeno.war To me this looks like the type of archive was unknown, so it will just watch, and attempt to re-deploy if it changes. But has no knowledge of the purpose of the file. With all these changes to the deployment scheme, does anyone have a short description of what is/isnot possible now. ie: Before the change, I was putting *.class in a sar, and making classless(descriptor only) EAR/war/jar. And this worked fine. Is this still possible? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAAS with MDB
No, the standard JMS Message interface needs to be used to obtain a configurable principal and credential property. Any JMS provider may be used with MDBs. - Original Message - From: Dave Smith [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 10:51 AM Subject: Re: [JBoss-dev] JAAS with MDB OK. So I had a quick peek at the SpyMessage and there is a field called producerClientId that should do the trick. So I add an interceptor in front of the security interceptor that takes the first argument of the invoke , casts to a SpyMessage, grabs the id and sets the Principal in the method invocation and continues along the chain. Will the only type of message delivered to the invoker be a SpyMessage? or can it handle other messages that could cause a class cast error? Scott M Stark wrote: Authentication and Authorization need to be two seperate security interceptors. Authentication needs to validate the principal and associate the Subject with the MethodInvocation. The Authorization interceptor will handle role based permissions and run-as identities. The default MDB interceptor chain should not include an Authentication interceptor. If the jboss.xml metadata is enchanced to allow for caller identity to be obtained from the JMS msg than the container invoker will associate this information with the call and the Authentication interceptor can be added to the interceptor chain. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAAS with MDB
OK. So I had a quick peek at the SpyMessage and there is a field called producerClientId that should do the trick. So I add an interceptor in front of the security interceptor that takes the first argument of the invoke , casts to a SpyMessage, grabs the id and sets the Principal in the method invocation and continues along the chain. Will the only type of message delivered to the invoker be a SpyMessage? or can it handle other messages that could cause a class cast error? Scott M Stark wrote: Authentication and Authorization need to be two seperate security interceptors. Authentication needs to validate the principal and associate the Subject with the MethodInvocation. The Authorization interceptor will handle role based permissions and run-as identities. The default MDB interceptor chain should not include an Authentication interceptor. If the jboss.xml metadata is enchanced to allow for caller identity to be obtained from the JMS msg than the container invoker will associate this information with the call and the Authentication interceptor can be added to the interceptor chain. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dave Smith [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 8:56 AM Subject: Re: [JBoss-dev] JAAS with MDB So then in JMSContainerInvoker add the code to read the jboss metadata and then invoke the inteceptor chain with the appropreate princpal and credidentals? Or should the JMS message actually set properties in the message itself and a new Security Invoker to read this info and set the principal and credidents. I have some time today and tomorrow to take a crack at it. Scott M Stark wrote: Which is what I mean by MDBs needing a different SecurityInterceptor. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dave Smith [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 7:47 AM Subject: Re: [JBoss-dev] JAAS with MDB It actually goes a little furthur than that. I first tried to take out the security interceptor in the MDB interceptior chain. This works fine util your message bean then tries to call another EJB. So it would seem that the Security Interceptor needs to just act as a login for the MDB. Scott M Stark wrote: MDBs need a different SecurityInterceptor that does not attempt to authenticate the caller as there is none defined. An extension would allow the caller to be obtained from JMS message properties. The properties could be specified in the jboss.xml descriptor in the message-driven bean section. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TODO: client side interceptors
Holger Engels wrote: On Thu, 31 Jan 2002, Bill Burke wrote: You're right here. EJBs have no asynchronous interface like CORBA object do. Arrgh! You mean the dreaded oneway keyword? I'd forgotten all about that. Plus, in EJB the request is not exposed like in CORBA as well. Some interceptors are transparent, others are not .. I think interceptors are transparent by definition. They modify the call after the client code has made it, or before it is received by the application code on the server side. Let the dynamic proxy implement the remote interface and all additional interfaces of all interceptors, that add non transparent behaviour to the component. We have already three additional apis: o SecurityAssociation o UserTransaction o ejb methods only the last one is directly implemented by the dynamic proxy. security and transactions are somewhat transcendent/magic. But the use of these takes place through standard interfaces on the client side and is again transparent to the client code, no? -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TODO: client side interceptors
|only the last one is directly implemented by the dynamic proxy. security |and transactions are somewhat transcendent/magic. A drawback of multiple |interfaces is that you have to cast the object to these particular |interfaces in order to use them. These apis are not exposed in the dynamic proxy, they are interceptors in the flow. Just invoke()... no need to cast are we sync on this holger? | |Holger | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TODO: client side interceptors
Guys, enough talking, To the slew of new developers looking for fame and glory... this is a neat little advanced assignement, make the interceptor stack for the EJB client real and configurable from jboss.xml OKA? shouldn't be that hard nor that simple. Couple of days. Bill you are banned from this, let a young eager mind prove he can do it. I don't want FactoryManagerLoaderProxies with 10,000 config files, the one who can make it in less classes wins, keep is simple stupid. Emphasis on the Simple Stupid. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Luke |Taylor |Sent: Thursday, January 31, 2002 10:56 AM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] TODO: client side interceptors | | |Holger Engels wrote: | | On Thu, 31 Jan 2002, Bill Burke wrote: | | | |You're right here. EJBs have no asynchronous interface like |CORBA object do. | | |Arrgh! You mean the dreaded oneway keyword? I'd forgotten all about that. | | |Plus, in EJB the request is not exposed like in CORBA as well. | | Some interceptors are transparent, others are not .. | | | |I think interceptors are transparent by definition. They modify the call |after the client code has made it, or before it is received by the |application code on the server side. | | | Let the dynamic proxy implement the remote interface and all additional | interfaces of all interceptors, that add non transparent |behaviour to the | component. We have already three additional apis: | | o SecurityAssociation | o UserTransaction | o ejb methods | | only the last one is directly implemented by the dynamic proxy. security | and transactions are somewhat transcendent/magic. | | |But the use of these takes place through standard interfaces on the |client side and is again transparent to the client code, no? | |-- | Luke Taylor. Monkey Machine Ltd. | PGP Key ID: 0x57E9523Chttp://www.mkeym.com | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAAS with MDB
Also, it should be the JMSContainerInvoker, not the Athorization interceptor that is dealing with obtaining the principal info from the JMS layer. - Original Message - From: Scott M Stark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 11:04 AM Subject: Re: [JBoss-dev] JAAS with MDB No, the standard JMS Message interface needs to be used to obtain a configurable principal and credential property. Any JMS provider may be used with MDBs. - Original Message - From: Dave Smith [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 10:51 AM Subject: Re: [JBoss-dev] JAAS with MDB OK. So I had a quick peek at the SpyMessage and there is a field called producerClientId that should do the trick. So I add an interceptor in front of the security interceptor that takes the first argument of the invoke , casts to a SpyMessage, grabs the id and sets the Principal in the method invocation and continues along the chain. Will the only type of message delivered to the invoker be a SpyMessage? or can it handle other messages that could cause a class cast error? Scott M Stark wrote: Authentication and Authorization need to be two seperate security interceptors. Authentication needs to validate the principal and associate the Subject with the MethodInvocation. The Authorization interceptor will handle role based permissions and run-as identities. The default MDB interceptor chain should not include an Authentication interceptor. If the jboss.xml metadata is enchanced to allow for caller identity to be obtained from the JMS msg than the container invoker will associate this information with the call and the Authentication interceptor can be added to the interceptor chain. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Is WAR deployment broken?
could be let me check marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Budworth |Sent: Thursday, January 31, 2002 10:55 AM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] Is WAR deployment broken? | | |Maybe I missed a message about this. But I am wondering, is war |deployment broken? | |Here is all that gets logged about the war (when inside an EAR, or when |placed directly in deploy) |Auto deploying: file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war |New UCL with url file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war |Libraries adding UnifiedClassLoader -1615549336 key URL |file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war |NO DEPLOYER for url file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war |Watching new file: file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war |Done deploying proxeno.war | |To me this looks like the type of archive was unknown, so it will just |watch, and attempt to re-deploy if it changes. But has no knowledge of |the purpose of the file. | | |With all these changes to the deployment scheme, does anyone have a |short description of what is/isnot possible now. | |ie: Before the change, I was putting *.class in a sar, and making |classless(descriptor only) EAR/war/jar. And this worked fine. | |Is this still possible? | | |-David | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: J2EE 1.3 app dtd
If you are having offline JBoss deploying Petstore, and getting error in regards to: (1) http://java.sun.com/dtd/application_1_3.dtd or (2) http://java.sun.com/dtds/web-app_2_3.dtd Make sure when you re-build PetStore to point the J2EE_HOME to version j2sdkee1.2.1 _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=6153 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] cvs lock on manual
why is there a lock on the cvs manual out there? it is from yesterday any ideas? it prevents me from updating the website marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] cvs lock on manual
It happens occasionally when a cvs client hangs. You have to ask the sourceforge admins to remove the lock. - Original Message - From: marc fleury [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 5:04 PM Subject: [JBoss-dev] cvs lock on manual why is there a lock on the cvs manual out there? it is from yesterday any ideas? it prevents me from updating the website marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Now I also see a lock
Why is cvs all locked up suddenly? I am also seeing a lock preventing a co of jboss-all currently. I have asked for this lock to be removed. cvs server: Updating jboss-all/server/src/etc/beaninfo cvs server: Updating jboss-all/server/src/etc/beaninfo/jaws cvs server: [14:30:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:30:38] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:31:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:31:38] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:32:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:32:38] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:33:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:33:38] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:34:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:34:38] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:35:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Now I also see a lock
cvs server: Updating manual/lib cvs server: [14:33:01] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:33:31] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:34:01] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:34:31] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:35:01] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:35:31] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:36:01] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:36:31] waiting for maximal's lock in /cvsroot/jboss/manual/lib cvs server: [14:37:01] waiting for maximal's lock in /cvsroot/jboss/manual/lib cvs server: [14:37:31] waiting for maximal's lock in /cvsroot/jboss/manual/lib cvs server: [14:38:01] waiting for maximal's lock in /cvsroot/jboss/manual/lib cvs server: [14:38:31] waiting for maximal's lock in /cvsroot/jboss/manual/lib cvs server: [14:39:01] waiting for maximal's lock in /cvsroot/jboss/manual/lib cvs server: [14:39:31] waiting for maximal's lock in /cvsroot/jboss/manual/lib cvs server: [14:40:01] waiting for maximal's lock in /cvsroot/jboss/manual/lib cvs server: [14:40:31] waiting for maximal's lock in /cvsroot/jboss/manual/lib cvs server: [14:41:01] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:41:31] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:42:01] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:42:31] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:43:01] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:43:31] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:44:01] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:44:31] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs server: [14:45:01] waiting for anoncvs_jboss's lock in /cvsroot/jboss/manual/lib cvs [update aborted]: received interrupt signal [jules@zeuglodon 3.0]$ Killed by signal 2. Me too, - I'm just trying to freshen up my tree. I'm having to update each top-level dir (except manual) individually Jules Scott M Stark wrote: Why is cvs all locked up suddenly? I am also seeing a lock preventing a co of jboss-all currently. I have asked for this lock to be removed. cvs server: Updating jboss-all/server/src/etc/beaninfo cvs server: Updating jboss-all/server/src/etc/beaninfo/jaws cvs server: [14:30:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:30:38] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:31:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:31:38] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:32:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:32:38] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:33:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:33:38] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:34:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:34:38] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ src/etc/beaninfo/jaws cvs server: [14:35:08] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-474977 ] run.sh fails on Mac OS X
Bugs item #474977, was opened at 2001-10-25 10:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=474977group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Matthew Bishop (mattbishop) Assigned to: Andreas Schaefer (schaefera) Summary: run.sh fails on Mac OS X Initial Comment: The run.sh script in JBoss 2.4.1a and 2.4.3 incorrectly identifies a HotSpot Server VM and then tries to instantiate the VM with the '-server' option. This fails if the VM is indeed a HotSpot Client VM and not the server variety. Mac OS X does not ship with a server HotSpot, so the run.sh script fails when it tries to instantiate the VM. Here is a sample output: [localhost:/J2EE-servers/jboss/bin] matt% sh run.sh Unrecognized option: -server Could not create the Java virtual machine. Here is the output from Mac OS X 10.1 when checking the version: [localhost:/J2EE-servers/jboss/bin] matt% java -version java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-root-010902-18:51) Java HotSpot(TM) Client VM (build 1.3.1, mixed mode) My workaround is to edit the run.sh script and remove the $HOTSPOT variable from the instantiation line. -- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-31 14:41 Message: Logged In: NO It doesn't look like this fix was ever committed to HEAD (JBoss 3). The version of the file as of yesterday didn't have this fix. -- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-19 12:44 Message: Logged In: NO Good! Will this code make it into the 3.0 alpha branch? I am running 3.0 with great success, once I fix the run.sh script. -- Comment By: Loren Rosen (lorenrosen) Date: 2002-01-15 12:22 Message: Logged In: YES user_id=387536 Perhaps run.sh should invoke 'java -help' and check the output for the string -server to verify that the option is supported. -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 15:23 Message: Logged In: YES user_id=70434 Current CVS Branch_2_4 contains the fix. Andy -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=474977group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Now I also see a lock
I have put a request as well, priority was bumped up by support |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Thursday, January 31, 2002 2:47 PM |To: JBoss Dev |Subject: [JBoss-dev] Now I also see a lock | | |Why is cvs all locked up suddenly? I am also seeing a lock preventing |a co of jboss-all currently. I have asked for this lock to be removed. | |cvs server: Updating jboss-all/server/src/etc/beaninfo |cvs server: Updating jboss-all/server/src/etc/beaninfo/jaws |cvs server: [14:30:08] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ |src/etc/beaninfo/jaws |cvs server: [14:30:38] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ |src/etc/beaninfo/jaws |cvs server: [14:31:08] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ |src/etc/beaninfo/jaws |cvs server: [14:31:38] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ |src/etc/beaninfo/jaws |cvs server: [14:32:08] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ |src/etc/beaninfo/jaws |cvs server: [14:32:38] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ |src/etc/beaninfo/jaws |cvs server: [14:33:08] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ |src/etc/beaninfo/jaws |cvs server: [14:33:38] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ |src/etc/beaninfo/jaws |cvs server: [14:34:08] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ |src/etc/beaninfo/jaws |cvs server: [14:34:38] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ |src/etc/beaninfo/jaws |cvs server: [14:35:08] waiting for anoncvs_jboss's lock in |/cvsroot/jboss/jboss/ | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JAAS with MDB
I don't see any of the mdb-xxx fields you are talking about in the current code so these are all elements you added? I'm looking at version 1.42 of the JMSContainerInvoker.java. What is needed is the names of the JMS properties from which the principal and credentials are obtained. The princpal name and credential value are not specified in the jboss.xml descriptor. Roles are also not defined in jboss.xml as they are a by-product of authenticating the obtained principal and credentials. - Original Message - From: Dave Smith [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 31, 2002 1:33 PM Subject: Re: [JBoss-dev] JAAS with MDB Ok. I have a hacked up version of JMSContainerInvoker working. Now currently we have mdb-user,mdb-password and mdb-subscription-id in the jboss.xml. These are used for durable subscriptions and are referenced in jbossmq-state.xml. Now should we add mdb-role and re-use this fields or should we add new elements say mdb-principal mdb-credentials and mdb-role? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ear/war deployment very broken....
I've just updated my tree (swerving around manual/lib and server/etc manually). cleaned and rebult from scratch. everything runs up nicely, but then I try to deploy an ear that deployed no problem a couple of weeks ago (last time I dared update my tree). I'm not sure what is going on. My ear is structured thus: fixed-jcheck.ear - servlet-tests.war - jsp-tests.war - WEB-INF - lib - tld_resource.jar It looks like MainDeployer is trying to find a jar INSIDE a WAR. I would expect the WAR to be passed straight to Jetty 00:07:33,568 INFO [Server] JBoss (MX MicroKernel) 3.0.0DR1(200201312358) [RABBIT-HOLE] Started in 1m:15s:500ms 00:10:14,364 INFO [MainDeployer] Auto deploying: file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/deploy/fixed-jcheck.ear 00:10:15,199 INFO [MainDeployer] Auto deploying: file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/deploy/jsp-tests.war 00:10:15,237 ERROR [MainDeployer] Error in subDeployment java.io.FileNotFoundException: /home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/deploy/WEB-INF/lib/tld_resource.jar (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:102) at java.io.FileOutputStream.init(FileOutputStream.java:62) at java.io.FileOutputStream.init(FileOutputStream.java:132) at org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:578) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) at org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:590) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:348) at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:254) at org.jboss.deployment.MainDeployer.run(MainDeployer.java:238) at java.lang.Thread.run(Thread.java:484) 00:10:15,274 ERROR [MainDeployer] Could not open the jar file org.jboss.deployment.DeploymentException: Could not deploy sub deployment WEB-INF/lib/tld_resource.jar of deployment file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/deploy/jsp-tests.war at org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:596) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) at org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:590) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:348) at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:254) at org.jboss.deployment.MainDeployer.run(MainDeployer.java:238) at java.lang.Thread.run(Thread.java:484) 00:10:15,276 ERROR [MainDeployer] Deployment failed: file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/deploy/jsp-tests.war org.jboss.deployment.DeploymentException: Could not open jar file file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/deploy/jsp-tests.war at org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:604) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) at org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:590) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:348) at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:254) at org.jboss.deployment.MainDeployer.run(MainDeployer.java:238) at java.lang.Thread.run(Thread.java:484) 00:10:15,279 INFO [MainDeployer] Cleaned Deployment file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/deploy/jsp-tests.war 00:10:15,641 INFO [MainDeployer] Auto deploying: file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/deploy/servlet-tests.war 00:10:15,752 INFO [MainDeployer] Done deploying servlet-tests.war 00:10:15,772 INFO [MainDeployer] Done deploying fixed-jcheck.ear _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/resources/jetty-plugin/META-INF jboss-service.xml
User: jules_gosnell Date: 02/01/31 16:32:24 Modified:jetty/src/resources/jetty-plugin/META-INF jboss-service.xml Log: some way further to configurable snapshot strategies and intervals, Revision ChangesPath 1.13 +4 -2 contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- jboss-service.xml 2002/01/22 21:03:04 1.12 +++ jboss-service.xml 2002/02/01 00:32:24 1.13 @@ -18,10 +18,12 @@ attribute name=WebDefaultwebdefault.xml/attribute attribute name=UnpackWarstrue/attribute attribute name=PublishMBeanstrue/attribute -attribute name=DistributedStoreorg.jboss.jetty.session.CoarseDistributedStore/attribute +attribute name=HttpSessionStorageStrategyorg.jboss.jetty.session.CoarseDistributedStore/attribute !-- -attribute name=DistributedStoreorg.jboss.jetty.session.ClusteredStore/attribute +attribute name=HttpSessionStorageStrategyorg.jboss.jetty.session.ClusteredStore/attribute -- +attribute name=HttpSessionSnapshotFrequencynever/num-seconds/idle/request/attribute +attribute name=HttpSessionSnapshotNotificationPolicyneither/attribute /mbean mbean code=org.mortbay.jetty.jmx.DebugMBean ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty/util NaiveTimeOutManager.java
User: jules_gosnell
Date: 02/01/31 16:32:24
Modified:jetty/src/main/org/jboss/jetty/util NaiveTimeOutManager.java
Log:
some way further to configurable snapshot strategies and intervals,
Revision ChangesPath
1.4 +5 -3
contrib/jetty/src/main/org/jboss/jetty/util/NaiveTimeOutManager.java
Index: NaiveTimeOutManager.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/util/NaiveTimeOutManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- NaiveTimeOutManager.java 2002/01/14 22:25:18 1.3
+++ NaiveTimeOutManager.java 2002/02/01 00:32:24 1.4
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: NaiveTimeOutManager.java,v 1.3 2002/01/14 22:25:18 jules_gosnell Exp $
+// $Id: NaiveTimeOutManager.java,v 1.4 2002/02/01 00:32:24 jules_gosnell Exp $
//--
@@ -40,10 +40,12 @@
class Entry
{
final Object _object;
+final long _timeRegistered;
final long _maxInactiveInterval;
-Entry(Object object, long maxInactiveInterval)
+Entry(Object object, long timeRegistered, long maxInactiveInterval)
{
_object=object;
+ _timeRegistered=timeRegistered;
_maxInactiveInterval=maxInactiveInterval;
}
@@ -66,7 +68,7 @@
if (maxInactiveInterval1)
return; // never timeout
- Entry entry=new Entry(object, maxInactiveInterval);
+ Entry entry=new Entry(object, timeRegistered, maxInactiveInterval);
synchronized (_entries) {
_entries.add(entry);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JBossWebApplicationContext.java Jetty.java JettyService.java JettyServiceMBean.java
User: jules_gosnell
Date: 02/01/31 16:32:24
Modified:jetty/src/main/org/jboss/jetty
JBossWebApplicationContext.java Jetty.java
JettyService.java JettyServiceMBean.java
Log:
some way further to configurable snapshot strategies and intervals,
Revision ChangesPath
1.18 +9 -3
contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java
Index: JBossWebApplicationContext.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- JBossWebApplicationContext.java 2002/01/22 21:03:03 1.17
+++ JBossWebApplicationContext.java 2002/02/01 00:32:24 1.18
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossWebApplicationContext.java,v 1.17 2002/01/22 21:03:03 jules_gosnell
Exp $
+// $Id: JBossWebApplicationContext.java,v 1.18 2002/02/01 00:32:24 jules_gosnell
Exp $
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -52,7 +52,9 @@
String warUrl,
String webDefaults,
boolean unpackWars,
-String distributedStoreImpl)
+String storageStrategy,
+String snapshotFrequency,
+String notificationPolicy)
throws java.io.IOException
{
super(httpServer, contextPathSpec, warUrl, webDefaults, unpackWars);
@@ -62,7 +64,11 @@
_webApp = webApp;
_parser = parser;
- getServletHandler().setSessionManager(new DistributedHttpSessionManager(this,
distributedStoreImpl));
+ getServletHandler().
+ setSessionManager(new DistributedHttpSessionManager(this,
+ storageStrategy,
+ snapshotFrequency,
+ notificationPolicy));
}
/* */
1.35 +46 -8 contrib/jetty/src/main/org/jboss/jetty/Jetty.java
Index: Jetty.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Jetty.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- Jetty.java2002/01/22 21:03:03 1.34
+++ Jetty.java2002/02/01 00:32:24 1.35
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: Jetty.java,v 1.34 2002/01/22 21:03:03 jules_gosnell Exp $
+// $Id: Jetty.java,v 1.35 2002/02/01 00:32:24 jules_gosnell Exp $
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -35,7 +35,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Julian Gosnell/a
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
- * @version $Revision: 1.34 $
+ * @version $Revision: 1.35 $
*
* pbRevisions:/b
*
@@ -147,21 +147,57 @@
// distributedStore property
//
- String _distributedStore;
+ String _storageStrategy;
public synchronized void
-setDistributedStore(String distributedStore)
+setHttpSessionStorageStrategy(String storageStrategy)
{
-_distributedStore=distributedStore;
+_storageStrategy=storageStrategy;
}
public synchronized String
-getDistributedStore()
+getHttpSessionStorageStrategy()
{
-return _distributedStore;
+return _storageStrategy;
}
//
+ // snapshotFrequency property
+ //
+
+ String _snapshotFrequency;
+
+ public synchronized void
+setHttpSessionSnapshotFrequency(String snapshotFrequency)
+ {
+_snapshotFrequency=snapshotFrequency;
+ }
+
+ public synchronized String
+getHttpSessionSnapshotFrequency()
+ {
+return _snapshotFrequency;
+ }
+
+ //
+ // snapshotNotificationPolicy property
+ //
+
+ String _snapshotNotificationPolicy;
+
+ public synchronized void
+setHttpSessionSnapshotNotificationPolicy(String snapshotNotificationPolicy)
+ {
+_snapshotNotificationPolicy=snapshotNotificationPolicy;
+ }
+
+ public synchronized String
+getHttpSessionSnapshotNotificationPolicy()
+ {
+return _snapshotNotificationPolicy;
+ }
+
+ //
// configuration
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty/session DistributedHttpSession.java DistributedHttpSessionManager.java
User: jules_gosnell
Date: 02/01/31 16:32:24
Modified:jetty/src/main/org/jboss/jetty/session
DistributedHttpSession.java
DistributedHttpSessionManager.java
Log:
some way further to configurable snapshot strategies and intervals,
Revision ChangesPath
1.5 +37 -17
contrib/jetty/src/main/org/jboss/jetty/session/DistributedHttpSession.java
Index: DistributedHttpSession.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/session/DistributedHttpSession.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- DistributedHttpSession.java 2002/01/16 00:36:51 1.4
+++ DistributedHttpSession.java 2002/02/01 00:32:24 1.5
@@ -46,7 +46,6 @@
final boolean _heldByValue =true; // attributes
are held in store by value, not reference
final boolean _accessDirties =true; // updating
_lastAccessedTime dirties session
- final boolean _snapshotNeedsActivation =true; // they will
not have been properly passivated
final boolean _isDistributed =true;
volatile boolean_isNew =true; // risky !
volatile boolean_isValid =true; // risky !
@@ -96,7 +95,7 @@
_attributes.putAll(data.getAttributes());
-boolean notify=data.getAttributesWerePassivated() || _snapshotNeedsActivation;
+boolean notify=data.getAttributesWerePassivated() ||
_manager.getSnapshotStrategy().getNotifyActivate();
// send activate events to listening attributes
if (notify _attributes.size()0)
@@ -426,10 +425,12 @@
{
if (attribute instanceof HttpSessionActivationListener)
{
- _log.warn(WARNING: About to activate a session attribute that was not
passivated: +attribute);
- _log.warn(WARNING: This was probably due to an uncontrolled server
shutdown.);
- ((HttpSessionActivationListener)attribute)
- .sessionDidActivate(event);
+ if (warn)
+ {
+ _log.warn(WARNING: About to activate a session attribute that was not
passivated: +attribute);
+ _log.warn(WARNING: This was probably due to an uncontrolled server
shutdown.);
+ }
+ ((HttpSessionActivationListener)attribute) .sessionDidActivate(event);
}
}
@@ -443,20 +444,20 @@
//
- protected void
-snapshot()
+ public void
+snapshot(boolean notifyActivate, boolean notifyPassivate)
{
-store(false, false);
+store(notifyActivate, notifyPassivate, false);
}
protected void
passivate()
{
-store(true, true);
+store(false, true, true);
}
protected synchronized void
-store(boolean notifyAttributes, boolean shutdown)
+store(boolean notifyActivate, boolean notifyPassivate, boolean shutdown)
{
// if there are no changes and this is not the final passivation
// during a controlled shutdown of webapp or webcontainer, we
@@ -469,10 +470,10 @@
{
// whilst this method is synchronized, _attributes may still be
// modified via their public access which only synchronise on
- // _attributes itself. In order to cause as little contention for
- // the _attributes map as possible I am going to try taking a copy
- // here - otherwise we will have to hang on to a ock on it for
- // ages.
+ // _attributes itself. In order to cause as little contention
+ // for the _attributes map as possible I am going to try taking
+ // a copy here - otherwise we will have to hang on to a lock on
+ // it for ages.
// copy is a shallow, not deep, copy. If attributes within it
// are being modified by another thread whilst being
@@ -489,7 +490,8 @@
}
}
- if (notifyAttributes copy!=null)
+ // about to passivate...
+ if (notifyPassivate copy!=null)
{
// send passivate events to listening attributes...
HttpSessionEvent event=new HttpSessionEvent(this);
@@ -516,8 +518,26 @@
// provided I slow down the collection of the stored state, it
// will never be collected before me
data.setMaxInactiveInterval(getMaxInactiveInterval()+5);
- data.setAttributesWerePassivated(notifyAttributes);
+ data.setAttributesWerePassivated(notifyPassivate);
store.put(getId(), data);
+
+ // about to activate...
+ if (notifyActivate copy!=null)
+ {
+ // send activate events to listening attributes...
+ HttpSessionEvent event=new HttpSessionEvent(this);
+ Iterator i =
RE: [JBoss-dev] ear/war deployment very broken....
yeah that is a bug I am seeing as well, I don't know what is going on but I got a reproducible case marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jules |Gosnell |Sent: Thursday, January 31, 2002 4:23 PM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: [JBoss-dev] ear/war deployment very broken | | |I've just updated my tree (swerving around manual/lib and server/etc |manually). | |cleaned and rebult from scratch. | |everything runs up nicely, but then I try to deploy an ear that deployed no |problem a couple of weeks ago (last time I dared update my tree). | |I'm not sure what is going on. | |My ear is structured thus: | |fixed-jcheck.ear | - servlet-tests.war | | - jsp-tests.war | - WEB-INF | - lib |- tld_resource.jar | | | |It looks like MainDeployer is trying to find a jar INSIDE a WAR. I would |expect the WAR to be passed straight to Jetty | |00:07:33,568 INFO [Server] JBoss (MX MicroKernel) 3.0.0DR1(200201312358) |[RABBIT-HOLE] Started in 1m:15s:500ms |00:10:14,364 INFO [MainDeployer] Auto deploying: |file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/deploy/f |ixed-jcheck.ear | |00:10:15,199 INFO [MainDeployer] Auto deploying: |file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/depl |oy/jsp-tests.war | |00:10:15,237 ERROR [MainDeployer] Error in subDeployment |java.io.FileNotFoundException: |/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/deploy/WE |B-INF/lib/tld_resource.jar |(No such file or directory) | at java.io.FileOutputStream.open(Native Method) | at java.io.FileOutputStream.init(FileOutputStream.java:102) | at java.io.FileOutputStream.init(FileOutputStream.java:62) | at java.io.FileOutputStream.init(FileOutputStream.java:132) | at |org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:578) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) | at |org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:590) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:348) | at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:254) | at org.jboss.deployment.MainDeployer.run(MainDeployer.java:238) | at java.lang.Thread.run(Thread.java:484) |00:10:15,274 ERROR [MainDeployer] Could not open the jar file |org.jboss.deployment.DeploymentException: Could not deploy sub deployment |WEB-INF/lib/tld_resource.jar of deployment |file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/depl |oy/jsp-tests.war | | at |org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:596) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) | at |org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:590) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:348) | at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:254) | at org.jboss.deployment.MainDeployer.run(MainDeployer.java:238) | at java.lang.Thread.run(Thread.java:484) |00:10:15,276 ERROR [MainDeployer] Deployment failed: |file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/depl |oy/jsp-tests.war | |org.jboss.deployment.DeploymentException: Could not open jar file |file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/depl |oy/jsp-tests.war | | at |org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:604) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) | at |org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:590) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:373) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:348) | at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:254) | at org.jboss.deployment.MainDeployer.run(MainDeployer.java:238) | at java.lang.Thread.run(Thread.java:484) |00:10:15,279 INFO [MainDeployer] Cleaned Deployment |file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/depl |oy/jsp-tests.war | |00:10:15,641 INFO [MainDeployer] Auto deploying: |file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0DR1/tmp/depl |oy/servlet-tests.war | |00:10:15,752 INFO [MainDeployer] Done deploying servlet-tests.war |00:10:15,772 INFO [MainDeployer] Done deploying fixed-jcheck.ear | | | |_ |Do You Yahoo!? |Get your free @yahoo.com address at http://mail.yahoo.com | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-511461 ] Deploying stale ear
Bugs item #511461, was opened at 2002-01-31 14:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511461group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Åsmund Hjulstad (ahjulsta) Assigned to: Nobody/Anonymous (nobody) Summary: Deploying stale ear Initial Comment: SuSE Linux 7.3 with kernel 2.4.16 JDK 1.4.0beta3 JBoss from CVS as of today. JBoss redeploys my stale .ear file. I do the following: Start JBoss (There are exceptions while starting, but these appear to be related to JmsXA, I don't recall seeing them when using JDK 1.3.1) Deploy application (with .jar, .war and application.xml) (Application is deployed, without any error messages.) Change something in the deployment-descriptor, such as comment out a session bean. Rebuild the .ear and redeploy. The application appears to be cycled, but the changes aren't there; the session bean commented out from the deployment-descriptor is still deployed. Restart of JBoss deploys the correct version. This is rather troublesome, as it makes developing on jboss a bit timeconsuming.. :-/ I experience the same problem when doing changes in the code of my beans. This bug turned up rather recently, I've been developing my application against the latest CVS for a while now, I can't recall experiencing similar problem some days ago. (It has worked after the Unified Deployer was committed.) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511461group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-511503 ] jboss 3.0 Performance
Bugs item #511503, was opened at 2002-01-31 16:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511503group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Ken Sipe (kensipe) Assigned to: Nobody/Anonymous (nobody) Summary: jboss 3.0 Performance Initial Comment: jboss group provided a tomcat-test.ear for evaluating the performance gained without the rmi stack. The average optimized speed was around .06 ms on jboss 2.4.4. In testing this with jboss 3.0. The average speed was .5 ms, this is the optimized number. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511503group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default standardjbosscmp-jdbc.xml
User: dsundstrom Date: 02/01/31 17:26:58 Modified:src/etc/conf/default standardjbosscmp-jdbc.xml Log: Changed type-mapping element in defaults to datasource-mapping as is required in the new dtd. Revision ChangesPath 1.15 +2 -2 jboss/src/etc/conf/default/standardjbosscmp-jdbc.xml Index: standardjbosscmp-jdbc.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjbosscmp-jdbc.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- standardjbosscmp-jdbc.xml 2002/01/15 23:17:09 1.14 +++ standardjbosscmp-jdbc.xml 2002/02/01 01:26:58 1.15 @@ -7,13 +7,13 @@ !-- -- !-- = -- -!-- $Id: standardjbosscmp-jdbc.xml,v 1.14 2002/01/15 23:17:09 dsundstrom Exp $ -- +!-- $Id: standardjbosscmp-jdbc.xml,v 1.15 2002/02/01 01:26:58 dsundstrom Exp $ -- jbosscmp-jdbc defaults datasourcejava:/DefaultDS/datasource - type-mappingHypersonic SQL/type-mapping + datasource-mappingHypersonic SQL/datasource-mapping create-tabletrue/create-table remove-tablefalse/remove-table ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/cmp2/ejbselect/META-INF jbosscmp-jdbc.xml
User: dsundstrom Date: 02/01/31 17:47:09 Modified:src/resources/cmp2/ejbselect/META-INF jbosscmp-jdbc.xml Log: Updated to new dtd. Revision ChangesPath 1.2 +14 -15 jbosstest/src/resources/cmp2/ejbselect/META-INF/jbosscmp-jdbc.xml Index: jbosscmp-jdbc.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/cmp2/ejbselect/META-INF/jbosscmp-jdbc.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jbosscmp-jdbc.xml 2001/12/21 18:42:51 1.1 +++ jbosscmp-jdbc.xml 2002/02/01 01:47:09 1.2 @@ -35,21 +35,20 @@ relationships ejb-relation ejb-relation-nameA-B/ejb-relation-name - foreign-key-mapping -ejb-relationship-role - ejb-relationship-role-nameB-has-an-A/ejb-relationship-role-name - foreign-key-fields - foreign-key-field - field-nameid/field-name - column-nameA_ID/column-name - /foreign-key-field - /foreign-key-fields -/ejb-relationship-role -ejb-relationship-role - ejb-relationship-role-nameA-has-Bs/ejb-relationship-role-name - foreign-key-fields/ -/ejb-relationship-role - /foreign-key-mapping + foreign-key-mapping/ + ejb-relationship-role +ejb-relationship-role-nameB-has-an-A/ejb-relationship-role-name +key-fields/ + /ejb-relationship-role + ejb-relationship-role +ejb-relationship-role-nameA-has-Bs/ejb-relationship-role-name +key-fields + key-field + field-nameid/field-name + column-nameA_ID/column-name + /key-field +/key-fields + /ejb-relationship-role /ejb-relation /relationships /jbosscmp-jdbc ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/cmp2/readonly/META-INF jbosscmp-jdbc.xml
User: dsundstrom Date: 02/01/31 17:47:09 Modified:src/resources/cmp2/readonly/META-INF jbosscmp-jdbc.xml Log: Updated to new dtd. Revision ChangesPath 1.2 +15 -16jbosstest/src/resources/cmp2/readonly/META-INF/jbosscmp-jdbc.xml Index: jbosscmp-jdbc.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/cmp2/readonly/META-INF/jbosscmp-jdbc.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jbosscmp-jdbc.xml 2001/12/12 20:10:58 1.1 +++ jbosscmp-jdbc.xml 2002/02/01 01:47:09 1.2 @@ -48,22 +48,21 @@ relationships ejb-relation ejb-relation-nameBook-Publisher/ejb-relation-name - foreign-key-mapping -read-onlytrue/read-only -ejb-relationship-role - ejb-relationship-role-namepublisher-has-books/ejb-relationship-role-name - foreign-key-fields/ -/ejb-relationship-role -ejb-relationship-role - ejb-relationship-role-namebook-has-a-publisher/ejb-relationship-role-name - foreign-key-fields - foreign-key-field - field-nameid/field-name - column-namepublisher/column-name - /foreign-key-field - /foreign-key-fields -/ejb-relationship-role - /foreign-key-mapping + foreign-key-mapping/ + read-onlytrue/read-only + ejb-relationship-role + ejb-relationship-role-namepublisher-has-books/ejb-relationship-role-name +key-fields + key-field + field-nameid/field-name + column-namepublisher/column-name + /key-field +/key-fields + /ejb-relationship-role + ejb-relationship-role + ejb-relationship-role-namebook-has-a-publisher/ejb-relationship-role-name +key-fields/ + /ejb-relationship-role /ejb-relation /relationships /jbosscmp-jdbc ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/cmp2/relationship/META-INF jbosscmp-jdbc.xml
User: dsundstrom Date: 02/01/31 17:47:09 Modified:src/resources/cmp2/relationship/META-INF jbosscmp-jdbc.xml Log: Updated to new dtd. Revision ChangesPath 1.3 +14 -14 jbosstest/src/resources/cmp2/relationship/META-INF/jbosscmp-jdbc.xml Index: jbosscmp-jdbc.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/cmp2/relationship/META-INF/jbosscmp-jdbc.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jbosscmp-jdbc.xml 2002/01/16 00:20:35 1.2 +++ jbosscmp-jdbc.xml 2002/02/01 01:47:09 1.3 @@ -16,9 +16,9 @@ relationships ejb-relation ejb-relation-nameAB_OneToOne_Bi_Table/ejb-relation-name - table-mapping + relation-table-mapping table-nameAB_OneToOneBi/table-name - /table-mapping + /relation-table-mapping /ejb-relation ejb-relation @@ -28,9 +28,9 @@ ejb-relation ejb-relation-nameAB_OneToOne_Uni_Table/ejb-relation-name - table-mapping + relation-table-mapping table-nameAB_OneToOneUni/table-name - /table-mapping + /relation-table-mapping /ejb-relation ejb-relation @@ -40,9 +40,9 @@ ejb-relation ejb-relation-nameAB_OneToMany_Bi_Table/ejb-relation-name - table-mapping + relation-table-mapping table-nameAB_OneToManyBi/table-name - /table-mapping + /relation-table-mapping /ejb-relation ejb-relation @@ -52,9 +52,9 @@ ejb-relation ejb-relation-nameAB_OneToMany_Uni_Table/ejb-relation-name - table-mapping + relation-table-mapping table-nameAB_OneToManyUni/table-name - /table-mapping + /relation-table-mapping /ejb-relation ejb-relation @@ -64,9 +64,9 @@ ejb-relation ejb-relation-nameAB_ManyToOne_Uni_Table/ejb-relation-name - table-mapping + relation-table-mapping table-nameAB_ManyToOneUni/table-name - /table-mapping + /relation-table-mapping /ejb-relation ejb-relation @@ -76,16 +76,16 @@ ejb-relation ejb-relation-nameAB_ManyToMany_Bi/ejb-relation-name - table-mapping + relation-table-mapping table-nameAB_ManyToManyBi/table-name - /table-mapping + /relation-table-mapping /ejb-relation ejb-relation ejb-relation-nameAB_ManyToMany_Uni/ejb-relation-name - table-mapping + relation-table-mapping table-nameAB_ManyToManyUni/table-name - /table-mapping + /relation-table-mapping /ejb-relation /relationships /jbosscmp-jdbc ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata JDBCRelationMetaData.java JDBCRelationshipRoleMetaData.java
User: dsundstrom
Date: 02/01/31 17:43:52
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCRelationMetaData.java
JDBCRelationshipRoleMetaData.java
Log:
Moved ejb-relationship-role element outside of the mapping element.
Changed foreign-keys-fields and table-key-fields fields to the generic
key-fields.
Revision ChangesPath
1.10 +148 -131
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCRelationMetaData.java
Index: JDBCRelationMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCRelationMetaData.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JDBCRelationMetaData.java 2001/12/05 05:07:17 1.9
+++ JDBCRelationMetaData.java 2002/02/01 01:43:52 1.10
@@ -25,7 +25,7 @@
* have set methods.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public final class JDBCRelationMetaData {
private final static int TABLE = 1;
@@ -58,7 +58,7 @@
private transient DataSource dataSource;
/** type mapping used for the relation table */
- private final JDBCTypeMappingMetaData typeMapping;
+ private final JDBCTypeMappingMetaData datasourceMapping;
/** the name of the table to use for this bean */
private final String tableName;
@@ -111,7 +111,7 @@
}
dataSourceName = null;
- typeMapping = null;
+ datasourceMapping = null;
createTable = false;
removeTable = false;
rowLocking = false;
@@ -128,7 +128,9 @@
this,
jdbcApplication,
rightRole);
-
+ left.init(right);
+ right.init(left);
+
if(mappingStyle == TABLE) {
tableName = createDefaultTableName();
} else {
@@ -156,76 +158,14 @@
JDBCRelationMetaData defaultValues) throws DeploymentException {
relationName = defaultValues.getRelationName();
-
- // get the mapping element; may be the defaults, table-mapping, or
- // foreign-key-mapping
- Element mappingElement;
- if(defaults.equals(element.getTagName())) {
- mappingElement = element;
-
- // set mapping style based on perferred-relation-mapping (if possible)
- String perferredRelationMapping = MetaData.getOptionalChildContent(
- element, preferred-relation-mapping);
-
- if(table.equals(perferredRelationMapping) ||
- defaultValues.isManyToMany()) {
-mappingStyle = TABLE;
- } else {
-mappingStyle = FOREIGN_KEY;
- }
- } else {
- // check for table mapping style
- mappingElement = MetaData.getOptionalChild(element, table-mapping);
- if(mappingElement != null) {
-mappingStyle = TABLE;
- } else {
-// check for foreign key mapping
-mappingElement = MetaData.getOptionalChild(
- element, foreign-key-mapping);
-if(mappingElement != null) {
- mappingStyle = FOREIGN_KEY;
- if(defaultValues.isManyToMany()) {
- throw new DeploymentException(Foreign key mapping-style +
-is not allowed for many-to-many relationsips.);
- }
-} else {
- // no mapping style element, will use defaultValues
- if(defaultValues.isForeignKeyMappingStyle()) {
- mappingStyle = FOREIGN_KEY;
- } else {
- mappingStyle = TABLE;
- }
-}
- }
- }
-
- // if no mapping element given, use defaultValues
- if(mappingElement == null) {
- dataSourceName = defaultValues.getDataSourceName();
- typeMapping = defaultValues.getTypeMapping();
- tableName = defaultValues.getTableName();
- createTable = defaultValues.getCreateTable();
- removeTable = defaultValues.getRemoveTable();
- rowLocking = defaultValues.hasRowLocking();
- primaryKeyConstraint = defaultValues.hasPrimaryKeyConstraint();
- readOnly = defaultValues.isReadOnly();
- readTimeOut = defaultValues.getReadTimeOut();
-
- left = new JDBCRelationshipRoleMetaData(
- this,
- jdbcApplication,
- element,
- defaultValues.getLeftRelationshipRole());
-
- right = new
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 259 Successful tests: 106 Errors:128 Failures: 25 [time of test: 1 February 2002 2:46 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-12] See http://lubega.com for full details 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] That flaming fireball in the sky...
I found this on the apache web site. I interpret this statement slightly different the Jakarta guys. To me it looks like the J2EE licensees are getting nervous about the high quality of the open source J2EE implementations (i.e., JBoss), and feel the only way to distinguish them selves in the marketplace is with some lame certification. - 30 January 2002 - That flaming fireball in the sky... In a recent article, Karen Tegan, Director of J2EE Compatibility and Platform Services for Sun Microsystems, had the following to say: The J2EE Compatible brand has achieved significant momentum over the past two years, and we want to make sure that any open source efforts don't impact the viability of that effort. In other words, Sun doesn't give a hoot about whether J2EE licensing restricts open source J2EE products (in case you missed it, it does). Thus, the Apache Software Foundation's involvement in the Java Community Process (JCP) is simply an advertising statement for Sun to claim that they have a 'vision which uses open standards and non-proprietary interfaces'. If you would like to express your opinions of Sun's licensing terms, feel free to contact [EMAIL PROTECTED] and let us know what you think. Thanks. Followup thread on Jakarta-General: J2EE considered harmful. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 259 Successful tests: 107 Errors:128 Failures: 24 [time of test: 1 February 2002 3:7 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 259 Successful tests: 107 Errors:128 Failures: 24 [time of test: 1 February 2002 3:39 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/bin run.sh
User: schaefera Date: 02/01/31 19:52:59 Modified:src/bin Tag: Branch_2_4 run.sh Log: Added Cygwin support Revision ChangesPath No revision No revision 1.19.4.1 +11 -0 jboss/src/bin/run.sh Index: run.sh === RCS file: /cvsroot/jboss/jboss/src/bin/run.sh,v retrieving revision 1.19 retrieving revision 1.19.4.1 diff -u -r1.19 -r1.19.4.1 --- run.sh2001/05/30 16:37:09 1.19 +++ run.sh2002/02/01 03:52:59 1.19.4.1 @@ -1,5 +1,11 @@ #!/bin/sh +# OS specific support. $var _must_ be set to either true or false. +cygwin=false; +case `uname` in + CYGWIN*) cygwin=true ;; +esac + # Minimal jar file to get JBoss started. JBOSS_CLASSPATH=$JBOSS_CLASSPATH:run.jar @@ -22,6 +28,11 @@ JBOSS_CLASSPATH=$JBOSS_CLASSPATH:../lib/crimson.jar JAXP=-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl JAXP=$JAXP -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl + +# For Cygwin, switch paths to Windows format before running java +if $cygwin; then + JBOSS_CLASSPATH=`cygpath --path --windows $JBOSS_CLASSPATH` +fi echo JBOSS_CLASSPATH=$JBOSS_CLASSPATH java $HOTSPOT $JAXP -classpath $JBOSS_CLASSPATH org.jboss.Main $@ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [jetty-discuss] Re: [JBoss-dev] Jetty3.1.5, Axis Basic Auth entication Problem
This is now implemented in both Jetty4 and Jetty3_1 CVS branches. Hopefully I'll get a release of both of these out in the next week cheers Jung , Dr. Christoph wrote: Greg, Jules, Luke! thx much for your replies. Indeed, the '*' role authentication constraint seems to match my issue very well if it also lets through null-authenticated/credential calls ... If I can help to patch SecurityHandler (jetty4 or backport to jetty3, perhaps), please let me know. Otherwise, I would be glad if you could send me a notification when it is available ... Thnx much, CGJ -Ursprüngliche Nachricht- Von: Greg Wilkins [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 31. Januar 2002 01:31 An: Luke Taylor Cc: 'Jboss-Development ([EMAIL PROTECTED])'; [EMAIL PROTECTED] Betreff: Re: [jetty-discuss] Re: [JBoss-dev] Jetty3.1.5, Axis Basic Authentication Problem Luke, I stand corrected. It is the '*' role behaviour that should be used. The lack of any role means no access.I knew the 2.3 spec had defined both these cases, but got them mixed up. Jetty4 will definitely support this style of security constraint soon. I think Jetty3 can also be made to support this without breaking any existing code (but I'll think about this a bit more before changing this). thanks Luke Taylor wrote: Greg Wilkins wrote: Cristoph, Eitherway, you do not want the semantics of NONE, you want the user to be authenticated, but you do not care what group they are in. Again, Jetty has an extension to the spec to support this. All users are in the role org.mortbay.http.User. However this is implemented in the HashUserRealm which is not used by JBoss. So for now, you must define a role that all your JBoss users are in and specify an AuthConstraint for that role. Hi Greg, Wouldn't this be the same as using * for the role-name? I had a brief look at the servlet 2.3 spec before replying previously and that's the syntax it uses for all roles. So it should then perform authentication and allow any user who has a role recognised by the application. Luke. -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 259 Successful tests: 107 Errors:128 Failures: 24 [time of test: 1 February 2002 4:9 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] That flaming fireball in the sky...
ignore the noise, focus on the work marcf PS: I agree with your analysis, the J2EE certified brand is weaker for every download we have and we are not certified. Having the most downloaded server not certified takes a lot of credibility out of the brand. I was reading the forum this was posted on and found interesting to hear that people say JBoss has become a defacto-standard of sorts. I believe that statement to be true at least for the development. Look at the download numbers we have 50k month weblogic has 3k for their free version. For the production I am waiting for a report that takes into account free and for pay and counts CPUs installed, I wouldn't be surprised the Apache story would repeat itself. But for now focus on the download numbers. The rest is noise. Noise, bla bla bla. |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Thursday, January 31, 2002 7:01 PM |To: Jboss-Development@Lists. Sourceforge. Net |Subject: [JBoss-dev] That flaming fireball in the sky... | | |I found this on the apache web site. I interpret this statement slightly |different the Jakarta guys. To me it looks like the J2EE licensees are |getting nervous about the high quality of the open source J2EE |implementations (i.e., JBoss), and feel the only way to distinguish them |selves in the marketplace is with some lame certification. | |- |30 January 2002 - That flaming fireball in the sky... | |In a recent article, Karen Tegan, Director of J2EE Compatibility and |Platform Services for Sun Microsystems, had the following to say: | |The J2EE Compatible brand has achieved significant momentum over the past |two years, and we want to make sure that any open source efforts don't |impact the viability of that effort. | |In other words, Sun doesn't give a hoot about whether J2EE licensing |restricts open source J2EE products (in case you missed it, it does). Thus, |the Apache Software Foundation's involvement in the Java Community Process |(JCP) is simply an advertising statement for Sun to claim that they have a |'vision which uses open standards and non-proprietary interfaces'. If you |would like to express your opinions of Sun's licensing terms, feel free to |contact [EMAIL PROTECTED] and let us know what you think. Thanks. | |Followup thread on Jakarta-General: J2EE considered harmful. | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
