[JBoss-dev] [Fwd: [jetty-discuss] HttpSession flushing?]
Anyone interested ? This stuff is never simple ! Jules --- Begin Message --- jules, If you want this for fault tolerance, then I would say that the only reasonable points that you can distribute/persist a session would be: + When there are no requests for that session active. + When explicitly requested by a knowing application. I also think it would be better to have an old consistent session snapshot rather than a recent inconsistent one. Thus I believe that the weak reference implementation is probably ideal. Soon after a session is idle, you can passivate it (protecting against new requests by a sync withing getSession()). I think you had best always do passivation/activation events otherwise you are outside of the spec - in which case why use Sessions at all for your persistent data? You'd be better off using them as a standard event source and using some other fault tolerant data layer. If passivation/activation is too expensive, you can configure timeouts: + When session goes idle, wait n secs before passivation to see if it becomes active again. + After m secs, always passivate an idle session (so that it does not get too old if frequently active). This will give you a mechanism that will moderately frequently take a snap shot of a session that has at least some chance of being consistent. It is also fully compliant with the specification. The only provision is that users should not store a reference to the session anywhere, which I think is a reasonable thing to require. cheers Jules Gosnell wrote: > I've considered granularities of various levels > > 1. only flush on SessionManager shutdown. > > This is what the 2.3 servlet spec mandates. It simply gives you enough fn-ality to > migrate sessions between instances of your webapp or webcontainer. > My first cut did this. > > 2. flush every time any change occurs > > Could be done - may be too expensive > > 3. flush at some other interval e.g. request, a certain number of changes, a certain > time interval etc... > > I just picked on request simply because it seemed like the most meaningful >granularity. > At some point there will be a lull in requests and the final flush() will bring the > stored state back to something that might be meaningful ! > > > Once you step away from (1) you open several cans of worms. However it is important >to > the JBoss guys to provide some sort of fail-over. (1) does not do this because >sessions > are only flushed if the shutdown was controlled. > > Worm 1 : > > If the attribute you are storing implements HttpSessionActivationListener you are >meant > to send an event notifying it of passivations and activations, since it may wrap an > expensive resource that needs to be allocated/freed. This is not the sort of thing >that > you want to do on every request. I propose to only send passivation events on >shutdown > and activation events on the following access. > > In the case of an uncontrolled shutdown and access no passivation event will be sent, > but an activation one will. In this case I print out a warning. > > I suppose I should allow the user to configure that they want the events every time. > > Worm 2 : > > Attributes are stored by value, not reference. This means that if you put an object >into > a session then alter it's contents the session has no way of knowing that it should > update it's copy of the object. A final passivation during controlled shutdown will > update the store properly, but fail-over stores may be inconsistent. I have taken the > approach that if the user wants changes like this reflected in the store, they must >call > setAttribute() again after each such change. > > If the attribute implements HttpSessionBindingListener it expects to be notified of > changes in it's bindings value. I am currently not notifying of apparent re-bindings >in > this case, although, once again this should probably be configurable. > > > That's enough worms for the moment. > > Anyone feel strongly about any of this. I figure it is good just to braindump on the > lists like this occasionally anyway - in case I am hit by a bus :-) > > > Jules > > > Greg Wilkins wrote: > > >>Jules, >> >>I have moved this to jetty-discuss as I think it would be good >>to get some feedback on the suggestions I'm about to make. >> >>Jules Gosnell wrote: >> >> >>>I need to arrange for someone to call my SessionManager after each request >>>has been processed so that I can flush changes to Session state out to a >>>distributed store. I figured I could do this with a handler - but I've had a >>>quick look through the src and now think that handlers are like 'before' >>>methods, whereas I need an 'around' or 'after' method. Have I missed the >>>point ? How should i best achieve my goal ? >>> >>I don't know if flushing session state on request boundaries is really the >>right thing to do as: >> >> + There may be multiple requests outstanding and the end of a s
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 258 Successful tests: 257 Errors:0 Failures: 1 [time of test: 7 January 2002 4:52 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
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 258 Successful tests: 257 Errors:0 Failures: 1 [time of test: 7 January 2002 4:5 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] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 258 Successful tests: 257 Errors:0 Failures: 1 [time of test: 7 January 2002 3:20 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: 258 Successful tests: 256 Errors:0 Failures: 2 [time of test: 7 January 2002 2:52 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] CVS update: contrib/jetty/src/main/org/jboss/jetty/ejb CoarseHttpSessionBean.java
User: jules_gosnell
Date: 02/01/06 15:54:17
Modified:jetty/src/main/org/jboss/jetty/ejb
CoarseHttpSessionBean.java
Log:
abstract out the pieces that need to plug into Sacha's JMX Session stuff
fix up javadoc for generated code too
Revision ChangesPath
1.3 +23 -2
contrib/jetty/src/main/org/jboss/jetty/ejb/CoarseHttpSessionBean.java
Index: CoarseHttpSessionBean.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/ejb/CoarseHttpSessionBean.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CoarseHttpSessionBean.java2002/01/04 18:21:15 1.2
+++ CoarseHttpSessionBean.java2002/01/06 23:54:17 1.3
@@ -8,17 +8,21 @@
import javax.ejb.EntityContext;
import javax.ejb.RemoveException;
import org.apache.log4j.Category;
+import org.jboss.jetty.AbstractHttpSessionData;
import org.jboss.jetty.interfaces.CoarseHttpSession;
import org.jboss.jetty.interfaces.CoarseHttpSessionData;
+//
+
/**
* The Entity bean represents an HttpSession.
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*
* @ejb:bean name="jetty/CoarseHttpSession" type="CMP"
jndi-name="ejb/jetty/CoarseHttpSession" primkey-field="id"
* @ejb:pk class="java.lang.String"
+ * @ejb:data-object implements="org.jboss.jetty.AbstractHttpSessionData"
*
* @jboss:table-name "Jetty_CoarseHttpSession"
* @jboss:create-table "true"
@@ -28,7 +32,7 @@
**/
public abstract class CoarseHttpSessionBean
- implements EntityBean
+ implements EntityBean, AbstractHttpSessionData
{
Category _log=Category.getInstance(getClass().getName());
@@ -271,6 +275,23 @@
* @ejb:transaction type="Supports"
*/
public abstract void setMaxInactiveInterval(int maxInactiveInterval);
+
+ //
+ // AttributesWerePassivated
+
+ /**
+ * @ejb:interface-method
+ * @ejb:persistent-field
+ * @ejb:transaction type="Supports"
+ */
+ public abstract boolean getAttributesWerePassivated();
+
+ /**
+ * @ejb:interface-method
+ * @ejb:persistent-field
+ * @ejb:transaction type="Supports"
+ */
+ public abstract void setAttributesWerePassivated(boolean
attributesWerePassivated);
//
// Bulk accessor
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty build.xml
User: jules_gosnell Date: 02/01/06 15:54:16 Modified:jettybuild.xml Log: abstract out the pieces that need to plug into Sacha's JMX Session stuff fix up javadoc for generated code too Revision ChangesPath 1.19 +1 -1 contrib/jetty/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jetty/build.xml,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- build.xml 2002/01/04 18:21:15 1.18 +++ build.xml 2002/01/06 23:54:16 1.19 @@ -467,7 +467,7 @@ https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty AbstractHttpSessionData.java DistributedSessionManager.java
User: jules_gosnell
Date: 02/01/06 15:54:16
Modified:jetty/src/main/org/jboss/jetty
DistributedSessionManager.java
Added: jetty/src/main/org/jboss/jetty AbstractHttpSessionData.java
Log:
abstract out the pieces that need to plug into Sacha's JMX Session stuff
fix up javadoc for generated code too
Revision ChangesPath
1.3 +213 -97
contrib/jetty/src/main/org/jboss/jetty/DistributedSessionManager.java
Index: DistributedSessionManager.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/DistributedSessionManager.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DistributedSessionManager.java2002/01/04 18:21:15 1.2
+++ DistributedSessionManager.java2002/01/06 23:54:16 1.3
@@ -5,11 +5,18 @@
* See terms of license at gnu.org.
*/
-// $Id: DistributedSessionManager.java,v 1.2 2002/01/04 18:21:15 jules_gosnell Exp $
+// $Id: DistributedSessionManager.java,v 1.3 2002/01/06 23:54:16 jules_gosnell Exp $
-// A Jetty HttpServer with the interface expected by JBoss'
-// J2EEDeployer...
+// TODO
+// 1. abstract out ID allocation and move into DistributedStore
+// 2. keep all state in HttpSessionState objects
+// 3. keep all HttpSessionState instances in DistributedStore
+// 4. we need to know when the data is dirty - will DAOs do this for us ?
+// 5. we need a handler to flush dirty state to the DistributedStore after each
request
+// 6. choice of DistributedStore and frequency of flushing should be parameterisable
+// 7. remember whether attributes were properly passivated
+
package org.jboss.jetty;
import java.rmi.RemoteException;
@@ -35,56 +42,148 @@
import org.mortbay.jetty.servlet.ServletHandler;
import org.mortbay.util.LifeCycle;
-/* - */
+//
+
+
/**
+ * An abstraction of a manager for the distributed store of HttpSessions
*
- * @version $Id: DistributedSessionManager.java,v 1.2 2002/01/04 18:21:15
jules_gosnell Exp $
- * @author [EMAIL PROTECTED]
+ * @author mailto:jules_gosnell@@yahoo.com";>Jules Gosnell
+ * @version 1.0
+ * @since 1.0
*/
-public class DistributedSessionManager
- extends org.mortbay.jetty.servlet.HashSessionManager
+interface AbstractDistributedStore
+{
+ public String nextId();
+ public AbstractHttpSessionData make();
+ public AbstractHttpSessionData get(String id);
+ public void set(String id, AbstractHttpSessionData data);
+}
+
+//
+
+/**
+ * An implementation of a manager of a CMP based distributed store of HttpSessions
+ *
+ * @author mailto:jules_gosnell@@yahoo.com";>Jules Gosnell
+ * @version 1.0
+ * @since 1.0
+ * @see AbstractDistributedStore
+ */
+class EJBDistributedStore
+ implements AbstractDistributedStore
{
- static InitialContext _jndiContext;
+ Logger_log = Logger.getLogger(getClass().getName());
+ InitialContext_jndiContext;
+ CoarseHttpSessionHome _home;
+ String_name="ejb/jetty/CoarseHttpSession"; // TODO - parameterise
- static
+ EJBDistributedStore()
{
try
{
_jndiContext=new InitialContext();
+ Object o=_jndiContext.lookup(_name);
+ _home=(CoarseHttpSessionHome)PortableRemoteObject.narrow(o,
CoarseHttpSessionHome.class);
+ _log.info("Support for EJB-based Distributed HttpSessions loaded: "+_home);
}
catch (NamingException e)
{
- Logger.getLogger("DistributedSessionManager").
- warn("WARNING: could not get JNDI Context - DistributedSessions are DISABLED");
+ _log.warn("WARNING: Support for EJB-based Distributed HttpSessions does not
appear to be loaded");
}
}
-
- Logger _log;
- JBossWebApplicationContext _context;
- CoarseHttpSessionHome _home;
- DistributedSessionManager(JBossWebApplicationContext context)
+ /**
+ * create a new HttpSessionData instance, of the correct type for
+ * this distributed store
+ *
+ */
+ public AbstractHttpSessionData
+make()
{
-super(context.getServletHandler());
+return new CoarseHttpSessionData();
+ }
-_context=context;
-_log= Logger.getLogger(getClass().getName()+"#" +_context.getContextPath());
+ /**
+ * retrieve HttpSessionData from a distributed store
+ *
+ * @param id a String value
+ */
+ public AbstractHttpSessionData
+get(String id)
+ {
+AbstractHttpSessionData data=null;
try
{
- if (_jndiContext!=null)
- {
- Object o=_jndiContext.lookup("ejb/jetty/CoarseHttpSession"); // TODO
[JBoss-dev] Re: (RH 3.0) Holding connections over transaction boundaries...
I reread the spec and what I discuss seems to be a requirement (section 6.11), however little I like it. I think the specs are a little contradictory on this point however, so I asked for clarification from sun and the connector interest list. __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66&thread=6705 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Unclear requirements on connection association and cleanup.
I'm having a little trouble understanding exactly what the spec requires with regards to connection association. I think that the following is supposed to be a requirement: scenario: mc1 is a ManagedConnection from ManagedConnectionFactory mcf Object c = mc.getConnection(subject, cri) c is not "closed" by the application component (i.e., if it is a javax.resource.cci.Connection, the application component did not call close() on it). App server calls mc.cleanup(), so now c can not be used to do any work on the EIS. mc2 is another ManagedConnection, also from mcf. App server calls mc.associateConnection(c) I think this call should succeed and that c can then be used to do work on the EIS through mc2. --- Arguments against: spec p 32, section 5.5.4 The method ManagedConnection.cleanup initiates a cleanup of any client-specific state maintained by a ManagedConnection instance. The cleanup is required to invalidate all con- nection handles created using this ManagedConnection instance. Any attempt by an applica-tion component to use associated connection handle after cleanup of the underlying ManagedConnection should result in an exception. (This does not specify that the now-invalid connection handle may be resuscitated by associating it with a different ManagedConnection). Arguments for: spec p. 76, section 6.10.3 * When the business method invocation on the EJB A instance completes successfully without any application error, the container starts the completion protocol for the local transaction. The container calls the LocalTransaction.commit method to commit the transaction. * After the local transaction completes, the container initiates a cleanup (now there is no active local transaction) of the physical connection instance by calling ManagedConnection.cleanup method. Note: The container should initiate cleanup of the ManagedConnection instance in the case where EJB A does not call close on the connection handle before returning. The container identifies this need for cleanup of ManagedConnection based on the scope of connection sharing. * On the cleanup method invocation, the ManagedConnection instance does a cleanup of its local transaction related state and resets itself to a default state. * The container returns the physical connection to the pool for handling subsequent connection requests. spec p.77, section 6.11 In this scenario, entity bean C instance obtains an application-level connection handle (using the method getConnection on the ConnectionFactory) during its creation. Entity bean C in- stance holds the connection handle during its lifetime. Even without the scenario in section 6.11 involving 3 ejbs, I believe this requires the following sequence of events: ejb C created, gets a connection handle c. It stores it in an instance variable during its lifetime. This is initially associated with ManagedConnection mc1. Method called on C, on its return container must call mc1.cleanup(), according to section 6.10.3. According to the description of cleanup(), c is now invalid. Method called again on C. Section 6.11 implicitly assumes that the call should succeed, which obviously means that c is no longer invalid. Therefore, I believe the container must associate c with some appropriate managed connection, say mc2, before control is passed to the method implementation in C. --- Conclusion: I think it would be more accurate to specify in section 5.5.4 The method ManagedConnection.cleanup initiates a cleanup of any client-specific state maintained by a ManagedConnection instance. The cleanup is required to invalidate all con- nection handles created using this ManagedConnection instance. Invalid connection handles may be restored to usability by associating them with appropriate ManagedConnection instances by calling the ManagedConnection associateConnection(Object connection) method. Any attempt by an applica-tion component to use associated connection handle after cleanup of the underlying ManagedConnection and before re-association with a ManagedConnection instance should result in an exception. Am I correct? Thanks David Jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jndi props in testsuite
No, the unit tests run out of the build.classes directory and do not use the output jars. You would need to load the testcase specific jndi.properties and use an explicit env in the construction of the InitialContext. You could try setting the System.properties from the testcase jndi.properties and this should take precedence over the values found in the classpath, but I'm not sure of the load ordering. - Original Message - From: Bill Burke To: [EMAIL PROTECTED] Sent: Sunday, January 06, 2002 7:06 AM Subject: [JBoss-dev] jndi props in testsuite If I add a jndi.properties file to a testsuite jar, will it use that file for InitialContext? InitialContext looks for jndi.properties in the CLASSPATH correct? Thanks, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jndi props in testsuite
I'm not at all sure... I think that the testcase classes are not packaged into a jar at the moment, and there is one jndi.properties on the classpath that gets used for all of them by default. This is very handy for non-cluster tests, but obviously may not work for you. Could you create an initial context from an explicitly found jndi-cluster.properties on the classpath so as not to disturb the non cluster testcases? thanks david jencks On 2002.01.06 10:06:06 -0500 Bill Burke wrote: > If I add a jndi.properties file to a testsuite jar, will it use that file > for InitialContext? InitialContext looks for jndi.properties in the > CLASSPATH correct? > > Thanks, > > Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/httpsession/server ClusteredHTTPSessionService.java
User: slaboure
Date: 02/01/06 08:05:19
Modified:src/main/org/jboss/ha/httpsession/server
ClusteredHTTPSessionService.java
Log:
local home lookup was wrong
Revision ChangesPath
1.3 +3 -4
jbossmx/src/main/org/jboss/ha/httpsession/server/ClusteredHTTPSessionService.java
Index: ClusteredHTTPSessionService.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/httpsession/server/ClusteredHTTPSessionService.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ClusteredHTTPSessionService.java 2002/01/06 12:05:32 1.2
+++ ClusteredHTTPSessionService.java 2002/01/06 16:05:19 1.3
@@ -29,7 +29,7 @@
* @see org.jboss.ha.httpsession.server.ClusteredHTTPSessionServiceMBean
*
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*
* Revisions:
*
@@ -54,7 +54,7 @@
protected LocalClusteredHTTPSessionHome localHttpSessionHome = null;
protected ClusteredHTTPSessionService.CleanupDaemon cleanup = null;
protected long sessionTimeout = 15*60*1000;
- protected boolean useLocalBean = true;
+ protected boolean useLocalBean = false;
// Static
@@ -190,9 +190,8 @@
InitialContext jndiContext = new InitialContext ();
if (useLocalBean)
{
- Object ref = jndiContext.lookup (LocalClusteredHTTPSessionHome.JNDI_NAME);
localHttpSessionHome = (LocalClusteredHTTPSessionHome)
- PortableRemoteObject.narrow (ref, LocalClusteredHTTPSessionHome.class);
+jndiContext.lookup (LocalClusteredHTTPSessionHome.JNDI_NAME);
}
else
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ejb/plugins CMPClusteredInMemoryPersistenceManager.java
User: slaboure
Date: 02/01/06 08:04:22
Modified:src/main/org/jboss/ejb/plugins
CMPClusteredInMemoryPersistenceManager.java
Log:
Bug in findAll when no beans in store
Revision ChangesPath
1.4 +9 -2
jbossmx/src/main/org/jboss/ejb/plugins/CMPClusteredInMemoryPersistenceManager.java
Index: CMPClusteredInMemoryPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ejb/plugins/CMPClusteredInMemoryPersistenceManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CMPClusteredInMemoryPersistenceManager.java 2002/01/03 04:00:52 1.3
+++ CMPClusteredInMemoryPersistenceManager.java 2002/01/06 16:04:22 1.4
@@ -11,6 +11,7 @@
import java.lang.reflect.Method;
import java.io.IOException;
import java.util.ArrayList;
+import java.util.Collection;
import javax.ejb.EJBException;
@@ -29,7 +30,7 @@
* @see org.jboss.ha.framework.interfaces.DistributedState
*
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey.
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*
* Revisions:
*
@@ -303,7 +304,13 @@
{
if (finderMethod.getName ().equals ("findAll"))
{
- ArrayList result = new ArrayList (this.ds.getAllKeys (DS_CATEGORY));
+ Collection tmpColl = this.ds.getAllKeys (DS_CATEGORY);
+
+ ArrayList result = null;
+ if (tmpColl == null)
+result = new ArrayList ();
+ else
+result = new ArrayList (tmpColl);
return new FinderResults (result,null,null,null);
} else
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF jboss.xml
User: slaboure Date: 02/01/06 08:03:12 Modified:src/resources/ClusteredHTTPSessionBean/META-INF jboss.xml Log: forgot container-configurations tag Revision ChangesPath 1.3 +2 -0 jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF/jboss.xml Index: jboss.xml === RCS file: /cvsroot/jboss/jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF/jboss.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jboss.xml 2002/01/06 11:46:57 1.2 +++ jboss.xml 2002/01/06 16:03:11 1.3 @@ -1,4 +1,5 @@ + Clustered in-memory CMP EntityBean false @@ -40,6 +41,7 @@ A + ClusteredHTTPSession ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF ejb-jar.xml
User: slaboure Date: 02/01/06 08:02:35 Modified:src/resources/ClusteredHTTPSessionBean/META-INF ejb-jar.xml Log: Added abstract-schema-name tag and reference to correct DTD on SUN web site (had moved) Revision ChangesPath 1.3 +2 -1 jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF/ejb-jar.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ejb-jar.xml 2002/01/06 11:46:57 1.2 +++ ejb-jar.xml 2002/01/06 16:02:35 1.3 @@ -2,7 +2,7 @@ http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd";> + "http://java.sun.com/dtd/ejb-jar_2_0.dtd";> @@ -13,6 +13,7 @@ org.jboss.ha.httpsession.interfaces.LocalClusteredHTTPSessionHome org.jboss.ha.httpsession.interfaces.LocalClusteredHTTPSession org.jboss.ha.httpsession.ejb.ClusteredHTTPSessionBeanCmp11 +ClusteredHTTPSession Container java.lang.String False ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jndi props in testsuite
If I add a jndi.properties file to a testsuite jar, will it use that file for InitialContext? InitialContext looks for jndi.properties in the CLASSPATH correct? Thanks, Bill
[JBoss-dev] CVS update: jbossmx/src/resources/ClusteredHTTPSessionService/META-INF jboss-service.xml
User: slaboure Date: 02/01/06 05:17:53 Added: src/resources/ClusteredHTTPSessionService/META-INF jboss-service.xml Log: Clustered HTTP session JMX service Revision ChangesPath 1.1 jbossmx/src/resources/ClusteredHTTPSessionService/META-INF/jboss-service.xml Index: jboss-service.xml === jboss:service=DefaultPartition ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/resources/ClusteredHTTPSessionService/META-INF - New directory
User: slaboure Date: 02/01/06 05:16:12 jbossmx/src/resources/ClusteredHTTPSessionService/META-INF - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/admin/client/lib [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/admin/client/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/admin/components [copy] Copying 2 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/admin/components [execmodules] == == Executing 'most' in module 'cluster'... == _buildmagic:init: _buildmagic:init:child: _buildmagic:init:local-properties: _buildmagic:init:buildlog: configure: _buildmagic:init:show-environment: init: compile-classes: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/classes [javac] Compiling 59 source files to /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/classes compile-rmi: [rmic] Verify has been turned on. [rmic] RMI Compiling 2 classes to /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/classes compile-etc: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/etc [copy] Copying 2 files to /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/etc compile: jars: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib [jar] Building jar: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib/jbossmx.jar [jar] Building jar: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib/jbossha.jar [jar] Building jar: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib/jbossha-client.jar [jar] Building jar: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib/jbossmqha.jar [jar] Building jar: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib/ClusteredHttpSessionEB.jar BUILD FAILED /disk/orig/home/lubega/jbossro/jboss-all/cluster/build.xml:386: /disk/orig/home/lubega/jbossro/jboss-all/cluster/src/resources/ClusteredHTTPSessionService not found. Total time: 2 minutes 6 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/httpsession/server ClusteredHTTPSessionService.java ClusteredHTTPSessionServiceMBean.java
User: slaboure
Date: 02/01/06 04:05:32
Modified:src/main/org/jboss/ha/httpsession/server
ClusteredHTTPSessionService.java
ClusteredHTTPSessionServiceMBean.java
Log:
Added local interfaces support and generation of session-id available cluster-wide
(simple implementation)
Revision ChangesPath
1.2 +84 -13
jbossmx/src/main/org/jboss/ha/httpsession/server/ClusteredHTTPSessionService.java
Index: ClusteredHTTPSessionService.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/httpsession/server/ClusteredHTTPSessionService.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ClusteredHTTPSessionService.java 2001/12/31 15:19:49 1.1
+++ ClusteredHTTPSessionService.java 2002/01/06 12:05:32 1.2
@@ -17,8 +17,10 @@
import org.jboss.system.ServiceMBeanSupport;
import org.jboss.ha.httpsession.interfaces.ClusteredHTTPSession;
+import org.jboss.ha.httpsession.interfaces.LocalClusteredHTTPSession;
import org.jboss.ha.httpsession.interfaces.ClusteredHTTPSessionBusiness;
import org.jboss.ha.httpsession.interfaces.ClusteredHTTPSessionHome;
+import org.jboss.ha.httpsession.interfaces.LocalClusteredHTTPSessionHome;
import org.jboss.ha.httpsession.interfaces.SerializableHttpSession;
/**
@@ -27,7 +29,7 @@
* @see org.jboss.ha.httpsession.server.ClusteredHTTPSessionServiceMBean
*
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey.
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
* Revisions:
*
@@ -49,11 +51,15 @@
// Attributes
protected ClusteredHTTPSessionHome httpSessionHome = null;
+ protected LocalClusteredHTTPSessionHome localHttpSessionHome = null;
protected ClusteredHTTPSessionService.CleanupDaemon cleanup = null;
protected long sessionTimeout = 15*60*1000;
+ protected boolean useLocalBean = true;
// Static
+ protected static String NODE_ID = null;
+
// Constructors --
public ClusteredHTTPSessionService ()
@@ -73,8 +79,16 @@
{
try
{
- ClusteredHTTPSession sessionBean = httpSessionHome.findByPrimaryKey
(sessionId);
- sessionBean.setSession (session);
+ if (useLocalBean)
+ {
+LocalClusteredHTTPSession sessionBean =
localHttpSessionHome.findByPrimaryKey (sessionId);
+sessionBean.setSession (session);
+ }
+ else
+ {
+ClusteredHTTPSession sessionBean = httpSessionHome.findByPrimaryKey
(sessionId);
+sessionBean.setSession (session);
+ }
}
catch (Exception e)
{
@@ -86,8 +100,16 @@
{
try
{
- ClusteredHTTPSession sessionBean = httpSessionHome.findByPrimaryKey
(sessionId);
- return sessionBean.getSession ();
+ if (useLocalBean)
+ {
+LocalClusteredHTTPSession sessionBean =
localHttpSessionHome.findByPrimaryKey (sessionId);
+return sessionBean.getSession ();
+ }
+ else
+ {
+ClusteredHTTPSession sessionBean = httpSessionHome.findByPrimaryKey
(sessionId);
+return sessionBean.getSession ();
+ }
}
catch (Exception e)
{
@@ -99,7 +121,14 @@
{
try
{
- httpSessionHome.remove (sessionId);
+ if (useLocalBean)
+ {
+localHttpSessionHome.remove (sessionId);
+ }
+ else
+ {
+httpSessionHome.remove (sessionId);
+ }
}
catch (Exception e)
{
@@ -110,11 +139,35 @@
public long getSessionTimeout () { return this.sessionTimeout; }
public void setSessionTimeout (long miliseconds) { this.sessionTimeout =
miliseconds; }
+ public synchronized String getSessionId ()
+ {
+ return NODE_ID + Long.toString (System.currentTimeMillis ());
+ }
+
+ public void setUseLocalBean (boolean useLocal)
+ {
+ int state = this.getState ();
+ if (state == this.STARTED || state == this.STARTING)
+ return;
+ else
+ this.useLocalBean = useLocal;
+ }
+
+ public boolean getUseLocalBean ()
+ {
+ return this.useLocalBean;
+ }
+
// ServiceMBeanSupport overrides
---
public void startService ()
throws Exception
{
+ // Dummy session id implementation: we generate our node id
+ //
+ if (NODE_ID == null)
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/httpsession/interfaces LocalClusteredHTTPSession.java LocalClusteredHTTPSessionHome.java
User: slaboure
Date: 02/01/06 04:04:37
Added: src/main/org/jboss/ha/httpsession/interfaces
LocalClusteredHTTPSession.java
LocalClusteredHTTPSessionHome.java
Log:
Added local interfaces support
Revision ChangesPath
1.1
jbossmx/src/main/org/jboss/ha/httpsession/interfaces/LocalClusteredHTTPSession.java
Index: LocalClusteredHTTPSession.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ha.httpsession.interfaces;
/**
* Local interface for clustered HTTP sessions.
*
* @see org.jboss.ha.httpsession.interfaces.ClusteredHTTPSessionBusiness
*
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey.
* @version $Revision: 1.1 $
*
* Revisions:
*
* 20020105 Sacha Labourey:
*
* First implementation
*
*/
public interface LocalClusteredHTTPSession extends ClusteredHTTPSessionBusiness,
javax.ejb.EJBLocalObject
{
}
1.1
jbossmx/src/main/org/jboss/ha/httpsession/interfaces/LocalClusteredHTTPSessionHome.java
Index: LocalClusteredHTTPSessionHome.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ha.httpsession.interfaces;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.FinderException;
import java.util.Collection;
/**
* Local Home interface for clustered HTTP session.
*
* @see org.jboss.ha.httpsession.interfaces.ClusteredHTTPSession
*
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey.
* @version $Revision: 1.1 $
*
* Revisions:
*
* 20020105 Sacha Labourey:
*
* First implementation
*
*/
public interface LocalClusteredHTTPSessionHome extends javax.ejb.EJBLocalHome
{
public static String JNDI_NAME = "clustering/LocalHTTPSession";
// Constructors
//
public LocalClusteredHTTPSession create (String sessionId) throws
RemoteException, CreateException;
public LocalClusteredHTTPSession create (String sessionId,
SerializableHttpSession session) throws RemoteException, CreateException;
// Finders
//
public LocalClusteredHTTPSession findByPrimaryKey (String sessionId) throws
RemoteException, FinderException;
// Returns a collection of known HttpSession instances
//
public Collection findAll() throws RemoteException, FinderException;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/admin/client/lib [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/admin/client/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/admin/components [copy] Copying 2 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/admin/components [execmodules] == == Executing 'most' in module 'cluster'... == _buildmagic:init: _buildmagic:init:child: _buildmagic:init:local-properties: _buildmagic:init:buildlog: configure: _buildmagic:init:show-environment: init: compile-classes: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/classes [javac] Compiling 57 source files to /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/classes compile-rmi: [rmic] Verify has been turned on. [rmic] RMI Compiling 2 classes to /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/classes compile-etc: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/etc [copy] Copying 2 files to /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/etc compile: jars: [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib [jar] Building jar: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib/jbossmx.jar [jar] Building jar: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib/jbossha.jar [jar] Building jar: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib/jbossha-client.jar [jar] Building jar: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib/jbossmqha.jar [jar] Building jar: /disk/orig/home/lubega/jbossro/jboss-all/cluster/output/lib/ClusteredHttpSessionEB.jar BUILD FAILED /disk/orig/home/lubega/jbossro/jboss-all/cluster/build.xml:386: /disk/orig/home/lubega/jbossro/jboss-all/cluster/src/resources/ClusteredHTTPSessionService not found. Total time: 2 minutes 13 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF ejb-jar.xml jboss.xml
User: slaboure Date: 02/01/06 03:46:57 Modified:src/resources/ClusteredHTTPSessionBean/META-INF ejb-jar.xml jboss.xml Log: Added local interfaces support Revision ChangesPath 1.2 +5 -1 jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF/ejb-jar.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ejb-jar.xml 2001/12/31 15:11:44 1.1 +++ ejb-jar.xml 2002/01/06 11:46:57 1.2 @@ -1,6 +1,8 @@ -http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd";> +http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd";> @@ -8,6 +10,8 @@ ClusteredHTTPSession org.jboss.ha.httpsession.interfaces.ClusteredHTTPSessionHome org.jboss.ha.httpsession.interfaces.ClusteredHTTPSession + org.jboss.ha.httpsession.interfaces.LocalClusteredHTTPSessionHome + org.jboss.ha.httpsession.interfaces.LocalClusteredHTTPSession org.jboss.ha.httpsession.ejb.ClusteredHTTPSessionBeanCmp11 Container java.lang.String 1.2 +3 -2 jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF/jboss.xml Index: jboss.xml === RCS file: /cvsroot/jboss/jbossmx/src/resources/ClusteredHTTPSessionBean/META-INF/jboss.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jboss.xml 2001/12/31 15:11:44 1.1 +++ jboss.xml 2002/01/06 11:46:57 1.2 @@ -1,5 +1,5 @@ - - + + Clustered in-memory CMP EntityBean false org.jboss.proxy.ejb.ProxyFactory @@ -44,6 +44,7 @@ ClusteredHTTPSession clustering/HTTPSession +clustering/LocalHTTPSession Clustered in-memory CMP EntityBean ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/resources/ClusteredHTTPSessionService - New directory
User: slaboure Date: 02/01/06 03:46:18 jbossmx/src/resources/ClusteredHTTPSessionService - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx build.xml
User: slaboure Date: 02/01/06 03:45:46 Modified:.build.xml Log: Now compiles the clustered HttpSession and creates .jar and .sar. THEY HAVE NOT YET BEEN TESTED! Revision ChangesPath 1.21 +50 -16jbossmx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbossmx/build.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- build.xml 2001/12/31 20:50:47 1.20 +++ build.xml 2002/01/06 11:45:46 1.21 @@ -12,7 +12,7 @@ - + @@ -35,7 +35,7 @@ @@ -48,9 +48,9 @@ @@ -122,6 +122,13 @@ + + + + + + + @@ -131,6 +138,7 @@ + @@ -181,6 +189,7 @@ + @@ -247,7 +256,7 @@ --> @@ -271,7 +280,7 @@ - + @@ -340,7 +349,7 @@ - + @@ -362,6 +371,31 @@ + + + + + + + + + + + + + + + + + + + + + + + + + @@ -440,21 +474,21 @@ - - - - @@ -468,13 +502,13 @@ - - @@ -487,16 +521,16 @@ - + - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Proposal: separate cvs update from Dev?
That is true and it seems that SF will not be implementing the cvs history feature. > But where on SF do you have a synthetized list of recent CVS commits? The > site simply says, in the CVS section, "No CVS History Available". > > Cheers, > > > Sacha > > > > Seperate them as they can be merged by any decent mail client > > if desired. Do we really need a cvs forum? This info is available > > through a browser interface from sourceforge in a much more > > sophisticated manner than the forum would offer. > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal: separate cvs update from Dev?
Hello Scott, But where on SF do you have a synthetized list of recent CVS commits? The site simply says, in the CVS section, "No CVS History Available". Cheers, Sacha > Seperate them as they can be merged by any decent mail client > if desired. Do we really need a cvs forum? This info is available > through a browser interface from sourceforge in a much more > sophisticated manner than the forum would offer. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where to put Principal Mappings for resource adapters?
We need to get away from usernames and passwords in the config files. I'm thinking the resource adapators should be associated with a security domain the same as ejbs and web content. A security domain is an MBean(org.jboss.security.plugins.JaasSecurityDomain in security) and an interface(org.jboss.security.SecurityDomain in server) I would call impersonation propagation of the current caller as your relying on identity and credentials previously submitted. These can be obtained from the current authenticated Subject. Principal mapping would be the result of executing a JAAS login against the security domain for the resource adapator. This would execute the mapping login modules for that domain and augment the current authenticated Subject with the resource adaptor mapped credentials. I'll have to go over the JCA spec JAAS usage examples again to see what if any policy is recommended. - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 05, 2002 1:25 PM Subject: [JBoss-dev] Where to put Principal Mappings for resource adapters? > --RH 3.0 only-- > > I want to implement the other 2 principal mappings we need for resource adapters -- impersonation (using the j2e logon as the adapter login) and mapping (mapping the j2ee logons to more than one adapter login) (I think I got the names right ;-)) > > Scott mentioned a while back that he wanted to move these security aspects out of the connector code and into the security domain. > > So, I'm wondering how to proceed. The simplest solution I have thought of is to make the principal mapper an mbean separate from a ConnectionFactoryLoader, and include a (depends) reference in the ConnectionFactoryLoader to the PrincipalMapping mbean it needs. > > So the configuration would look like this: > > >... >jboss.security:name=myPrincipalMa pping > > > and one of > > > me > MySecret > > > or > > > > > or > > > > me > MySecret > > > me > MySecret > > > you > yourSecret > > > > > > > Any comments? Is there a better way to do this? Is there any chance someone would use an explicit map like this with all the resource passwords in a plain text file? Where else could they come from? Does the jaas spec explain enough about Kerberos in java to make implementing that reasonably straightforward? > > Thanks > david jencks > > __ > View this jboss-dev thread in the online forums: > http://jboss.org/forums/thread.jsp?forum=66&thread=6703 > > ___ > 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] JNDI View
JNDIView should not depend on anything other than the naming serivce. It needs a mechanism to query for the ObjectNames of the deployers from which it attempts to obtain the deployed application info from, or this needs to be available in a different manner. - Original Message - From: "Adrian Brock" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 05, 2002 7:03 PM Subject: [JBoss-dev] JNDI View > JNDI View is broken due to the JMX Domain changes. > > The container factory is now registered in domain > "jboss.j2ee" but ContainerFactoryMBean has no domain > so the default "jboss" is used. > > Two points: > 1) Shouldn't it be possible to run jboss without > j2ee, so why does it barf when it can't find this > service? One line saying j2ee is not present would > be better. The log can contain the full exception > trace as a warning. > 2) If it really does depend on this service, this > could be configured with a > jboss.j2ee:service=ContainerF actory > > Regards, > Adrian > __ > View this jboss-dev thread in the online forums: > http://jboss.org/forums/thread.jsp?forum=66&thread=6719 > > ___ > 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
