[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss.jcml
User: schaefera Date: 01/06/10 23:38:19 Modified:src/etc/conf/default jboss.jcml Log: Adjusted the constructor parameter for the SchedulableExample to show how to use the constructor parameters. Revision ChangesPath 1.38 +4 -4 jboss/src/etc/conf/default/jboss.jcml Index: jboss.jcml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss.jcml,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- jboss.jcml2001/06/10 07:47:47 1.37 +++ jboss.jcml2001/06/11 06:38:19 1.38 @@ -420,19 +420,19 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Fwd: [JBoss-dev] New: Scheduler Service
Hi Andy, mad sunday-working peope! I found your mail this morning in my folder and wonder how things grow in parallel. In the last days, I developed a similar solution because we need to schedule some processes in our project and I wants to publish and contrib our solution to the jboss project - but now you are faster. Nevertheless, I'll descripe our solution sinci it is a little bit different in doing the scheduling. I.e. I designed a more general scheduler MBean to manage many scheduled process which can be configured in a seperate scheduler.jobs file. There you can set the initial startpoint, repetition period (optional) and repetition counter(optional). Since we use topics to communicate between the scheduler and the scheduled process, there is no need to include any classes of the scheduled process in the classpath of the MBeans. This seems me to be a more flexible solution. A (optional) message, which can be configured within your defined jobs makes it possible to start the same job with different parameters in different timings. Interested ?? If yes, how can I submit the code and description ?? (This would be my first contribution to jBoss). best regards tom PS: please reply also to [EMAIL PROTECTED], I'm here in a project and not subscribed to the JBoss-dev list -- THETA - Consulting Kommuniktionsanalyse - Anwendungsentwicklung - LINUX-Systeme Thomas Hagedorn Tel. 07231-472108 Rainstr. 12 Tel. 0172-7642398 75217 Birkenfeld [EMAIL PROTECTED] Jesus inside - where do you want to go forever ? On Mon, 11 Jun 2001, you wrote: > Hi Geeks > > After some requests for a JMX Timer example and using BEA Weblogic's > Scheduler (@ work, of course) I came up with the idea of having a similar > Scheduling Service but better because we do it right, right ? > > In jboss.jcml (default) is an example MBean definition. To use it on your > own just do: > - uncomment the example in jboss.jcml > - create your own instance of a Schedulable taks by implementing the > Schedulable interface > - Replace the fully qualified class name with the > Scheduler$SchedulableExample - Adjust the constructor values: > 1) Name of the MBean > 2) Fully qualified class name of your Schedulable Task class > 3) Comma separated list of Constructor Values (NOT SUPPORTED yet) > 4) Comma separated list of Constructor Data Types (NOT SUPPORTED yet) > 5) Date of the initial call in milliseconds (0 = now) (except 0 NOT > SUPPORTED yet) 6) Period between two calls in milliseconds > 7) Number of repetitions where -1 means forever > - Make your Schedulable Task class available for the Scheduling MBean > (classpath extension etc.) > > I think that's it. Have fun and tell me what you think. > > Please note that this is a alpa version and is not finished. Your comment > will help to make it better. > > Mad Andy / Better Pizza > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Reason for abstract methods in jboss-j2ee
Hi. Is there a reason for declaring the interface methods in jboss-j2ee for abstract ? If not I'll clean it up and add JavaDoc ;) Cheers, Jesper -- Jesper Pedersen, M.Sc. C.S.E Open Source Solution Manager Sun Certified Java 2 Developer IT+ A/S Phone: +45 86 78 21 00 Brendstrupgårdsvej 7 Fax: +45 86 78 21 02 8200 Århus N Direct:+45 87 40 08 49 Denmark Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util Schedulable.java Scheduler.java SchedulerMBean.java
User: schaefera
Date: 01/06/10 23:32:31
Modified:src/main/org/jboss/util Schedulable.java Scheduler.java
SchedulerMBean.java
Log:
Adjusted the Scheduler to run as a real MBean able to be started,
managed and stopped at runtime (JMX HTML-Adaptor) etc.
Revision ChangesPath
1.2 +1 -1 jboss/src/main/org/jboss/util/Schedulable.java
Index: Schedulable.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/Schedulable.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Schedulable.java 2001/06/10 07:50:58 1.1
+++ Schedulable.java 2001/06/11 06:32:31 1.2
@@ -35,6 +35,6 @@
**/
public void perform(
Date pTimeOfCall,
- int pRemainingRepetitions
+ long pRemainingRepetitions
);
}
1.4 +279 -81 jboss/src/main/org/jboss/util/Scheduler.java
Index: Scheduler.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/Scheduler.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Scheduler.java2001/06/11 00:52:23 1.3
+++ Scheduler.java2001/06/11 06:32:31 1.4
@@ -14,6 +14,8 @@
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
+import java.util.StringTokenizer;
+import java.util.Vector;
import javax.management.MalformedObjectNameException;
import javax.management.MBeanServer;
@@ -54,24 +56,28 @@
// Members
// -
- private MBeanServer mServer;
private String mName;
- private long mSchedulePeriod;
- private int mRemainingRepetitions = 0;
+ private long mActualSchedulePeriod;
+ private long mRemainingRepetitions = 0;
private int mActualSchedule = -1;
- private boolean mScheduleIsStarted = false;
- private boolean mWaitForNextCallToStop = false;
private ObjectName mTimer;
private Schedulable mSchedulable;
+ private boolean mScheduleIsStarted = false;
+ private boolean mWaitForNextCallToStop = false;
private boolean mStartOnStart = false;
- private String mSchedulableClass;
- private Object[] mInitArguments;
- private String[] mInitTypes;
+ private boolean mIsRestartPending = true;
+
+ // Pending values which can be different to the actual ones
+ private Class mSchedulableClass;
+ private String mSchedulableArguments;
+ private String[] mSchedulableArgumentList = new String[ 0 ];
+ private String mSchedulableArgumentTypes;
+ private Class[] mSchedulableArgumentTypeList = new Class[ 0 ];
private Date mStartDate;
- private long mPeriod;
- private int mRepetitions;
+ private long mSchedulePeriod;
+ private long mInitialRepetitions;
// -
// Constructors
@@ -111,53 +117,86 @@
) {
mName = pName;
mStartOnStart = true;
- mSchedulableClass = pSchedulableClass;
-// if( pInitArguments == null || pInitArguments.equals( "" ) ) {
- mInitArguments = new Object[ 0 ];
-// }
-// if( pInitTypes == null || pInitTypes.equals( "" ) ) {
- mInitArguments = new String[ 0 ];
-// }
+ setSchedulableClass( pSchedulableClass );
+ setSchedulableArguments( pInitArguments );
+ setSchedulableArgumentTypes( pInitTypes );
mStartDate = new Date( pInitialStartDate );
- mPeriod = pSchedulePeriod;
- mRepetitions = (int) pNumberOfRepetitions;
+ setSchedulePeriod( pSchedulePeriod );
+ setInitialRepetitions( pNumberOfRepetitions );
}
// -
// SchedulerMBean Methods
// -
- public void startSchedule(
- String pSchedulableClass,
- Object[] pInitArguments,
- String[] pInitTypes,
- Date pInitialStartDate,
- long pSchedulePeriod,
- int pNumberOfRepetitions
- ) {
+ public void startSchedule() {
// Check if not already started
if( !isStarted() ) {
try {
-// Try to load the Schedulable Class
-Class lSchedulableClass =
Thread.currentThread().getContextClassLoader().loadClass( pSchedulableClass );
-// Create an instance of it
-if( pInitArguments == null ) {
- pInitArguments = new Object[ 0 ];
-}
-if( pInitTypes == null ) {
- pInitTypes = new String[ 0 ];
-}
-if( pInitArguments.length != pInitTypes.
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins JaasSecurityManager.java
User: starksm
Date: 01/06/10 23:23:39
Modified:src/main/org/jboss/security/plugins JaasSecurityManager.java
Log:
Update userHasRole implementation to accept a Set rather
than Principal names
Revision ChangesPath
1.6 +5 -6
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java
Index: JaasSecurityManager.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JaasSecurityManager.java 2001/04/11 02:04:21 1.5
+++ JaasSecurityManager.java 2001/06/11 06:23:39 1.6
@@ -51,7 +51,7 @@
@author Oleg Nitz
@author [EMAIL PROTECTED]
-@version $Revision: 1.5 $
+@version $Revision: 1.6 $
*/
public class JaasSecurityManager implements SubjectSecurityManager, RealmMapping
{
@@ -226,12 +226,12 @@
a member of the Roles group, then the user has the role.
@param principal, ignored. The current authenticated Subject determines
the active user and assigned user roles.
-@param roleNames, a set of String names for the roles to check.
+@param rolePrincipals, a Set of Principals for the roles to check.
@see java.security.acl.Group;
@see Subject#getPrincipals()
*/
-public boolean doesUserHaveRole(Principal principal, Set roleNames)
+public boolean doesUserHaveRole(Principal principal, Set rolePrincipals)
{
boolean hasRole = false;
Subject subject = getActiveSubject();
@@ -269,11 +269,10 @@
roles = info.roles;
if( roles != null )
{
-Iterator iter = roleNames.iterator();
+Iterator iter = rolePrincipals.iterator();
while( hasRole == false && iter.hasNext() )
{
-String name = (String) iter.next();
-SimplePrincipal role = new SimplePrincipal(name);
+Principal role = (Principal) iter.next();
hasRole = roles.isMember(role);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/test NestableGroupTest.java NestablePrincipalTest.java
User: starksm
Date: 01/06/10 23:22:22
Modified:src/main/org/jboss/test NestableGroupTest.java
NestablePrincipalTest.java
Log:
Update tests for anybody and nobody principals
Revision ChangesPath
1.3 +22 -1 jbosssx/src/main/org/jboss/test/NestableGroupTest.java
Index: NestableGroupTest.java
===
RCS file: /cvsroot/jboss/jbosssx/src/main/org/jboss/test/NestableGroupTest.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- NestableGroupTest.java2001/03/22 09:40:03 1.2
+++ NestableGroupTest.java2001/06/11 06:22:22 1.3
@@ -7,6 +7,8 @@
import java.util.Enumeration;
import junit.framework.*;
+import org.jboss.security.AnybodyPrincipal;
+import org.jboss.security.NobodyPrincipal;
import org.jboss.security.NestableGroup;
import org.jboss.security.SimpleGroup;
import org.jboss.security.SimplePrincipal;
@@ -16,7 +18,7 @@
@see org.jboss.security.NestableGroup
@author [EMAIL PROTECTED]
-@version $Revision: 1.2 $
+@version $Revision: 1.3 $
*/
public class NestableGroupTest extends TestCase
{
@@ -48,6 +50,8 @@
suite.addTest(new NestableGroupTest("testEquals"));
suite.addTest(new NestableGroupTest("testAddMember"));
suite.addTest(new NestableGroupTest("testRemoveMember"));
+suite.addTest(new NestablePrincipalTest("testAnybody"));
+suite.addTest(new NestablePrincipalTest("testNobody"));
return suite;
}
@@ -96,6 +100,23 @@
catch(IllegalArgumentException e)
{
}
+}
+
+public void testAnybody()
+{
+System.out.println("testAnybody");
+group.addMember(groups[0]);
+assert("AnybodyPrincipal.isMember",
group.isMember(AnybodyPrincipal.ANYBODY_PRINCIPAL));
+}
+
+public void testNobody()
+{
+System.out.println("testNobody");
+SimpleGroup nobodyGroup = new SimpleGroup("");
+SimplePrincipal nobody = new SimplePrincipal("");
+nobodyGroup.addMember(nobody);
+group.addMember(nobodyGroup);
+assert("AnybodyPrincipal.isMember",
group.isMember(NobodyPrincipal.NOBODY_PRINCIPAL) == false);
}
/** Test of members method, of class org.jboss.security.NestableGroup. */
1.2 +22 -3 jbosssx/src/main/org/jboss/test/NestablePrincipalTest.java
Index: NestablePrincipalTest.java
===
RCS file: /cvsroot/jboss/jbosssx/src/main/org/jboss/test/NestablePrincipalTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- NestablePrincipalTest.java2001/03/21 08:47:44 1.1
+++ NestablePrincipalTest.java2001/06/11 06:22:22 1.2
@@ -6,7 +6,9 @@
import java.util.Enumeration;
import junit.framework.*;
+import org.jboss.security.AnybodyPrincipal;
import org.jboss.security.NestablePrincipal;
+import org.jboss.security.NobodyPrincipal;
import org.jboss.security.SimpleGroup;
import org.jboss.security.SimplePrincipal;
@@ -15,7 +17,7 @@
@see org.jboss.security.NestablePrincipal
@author [EMAIL PROTECTED]
-@version $Revision: 1.1 $
+@version $Revision: 1.2 $
*/
public class NestablePrincipalTest extends TestCase
{
@@ -39,6 +41,8 @@
suite.addTest(new NestablePrincipalTest("testEquals"));
suite.addTest(new NestablePrincipalTest("testAddMember"));
suite.addTest(new NestablePrincipalTest("testRemoveMember"));
+suite.addTest(new NestablePrincipalTest("testAnybody"));
+suite.addTest(new NestablePrincipalTest("testNobody"));
return suite;
}
@@ -59,7 +63,7 @@
/** Test of removeMember method, of class org.jboss.security.NestablePrincipal.
*/
public void testRemoveMember()
{
-System.out.println("testRemoveMember, this="+this.hashCode());
+System.out.println("testRemoveMember");
for(int p = principals.length -1; p >= 0; p --)
{
assert("Remove "+principals[p], principal.removeMember(principals[p]));
@@ -70,7 +74,7 @@
/** Test of addMember method, of class org.jboss.security.NestablePrincipal. */
public void testAddMember()
{
-System.out.println("testAddMember, this="+this.hashCode());
+System.out.println("testAddMember");
for(int p = 0; p < principals.length; p ++)
{
@@ -79,6 +83,21 @@
assert("AddMember "+user, principal.isMember(user));
testMembers();
}
+}
+
+public void testAnybody()
+{
+System.out.println("testAnybody");
+principal.addMember(principals[0]);
+assert("AnybodyPrin
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata BeanMetaData.java
User: starksm
Date: 01/06/10 23:16:50
Modified:src/main/org/jboss/metadata BeanMetaData.java
Log:
Implement the EJB 2.0 unchecked and exclude-list method permission
related elements
Revision ChangesPath
1.22 +74 -19jboss/src/main/org/jboss/metadata/BeanMetaData.java
Index: BeanMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/BeanMetaData.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- BeanMetaData.java 2001/06/10 20:51:23 1.21
+++ BeanMetaData.java 2001/06/11 06:16:50 1.22
@@ -18,6 +18,9 @@
import org.w3c.dom.NodeList;
import org.jboss.ejb.DeploymentException;
+import org.jboss.security.AnybodyPrincipal;
+import org.jboss.security.NobodyPrincipal;
+import org.jboss.security.SimplePrincipal;
/** A common meta data class for the entity, message-driven and session beans.
*
@@ -25,7 +28,7 @@
* @author Peter Antman ([EMAIL PROTECTED])
* @author Daniel OConnor ([EMAIL PROTECTED])
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.21 $
+ * @version $Revision: 1.22 $
*/
public abstract class BeanMetaData extends MetaData {
// Constants -
@@ -181,8 +184,13 @@
transactionMethods.add(method);
}
- public void addPermissionMethod(MethodMetaData method) {
- permissionMethods.add(method);
+ public void addPermissionMethod(MethodMetaData method)
+{
+// Insert unchecked methods into the front of the list to speed up their
validation
+if( method.isUnchecked() )
+permissionMethods.add(0, method);
+else
+permissionMethods.add(method);
}
public void addExcludedMethod(MethodMetaData method) {
excludedMethods.add(method);
@@ -207,23 +215,70 @@
return result;
}
- // d.s.> PERFORMANCE !!!
- public Set getMethodPermissions(String methodName, Class[] params, boolean
remote) {
- Set result = new HashSet ();
- Iterator iterator = getPermissionMethods();
- while (iterator.hasNext()) {
- MethodMetaData m = (MethodMetaData)iterator.next();
- if (m.patternMatches(methodName, params, remote))
- {
-Iterator i = m.getRoles().iterator ();
-while (i.hasNext ())
- result.add (i.next ());
- }
+/** A somewhat tedious method that builds a Set of the roles
+ that have been assigned permission to execute the indicated method. The
+ work performed is tedious because of the wildcard style of declaring
+ method permission allowed in the ejb-jar.xml descriptor. This method is
+ called by the Container.getMethodPermissions() when it fails to find the
+ prebuilt set of method roles in its cache.
+ @return The Set for the application domain roles that
+caller principal's are to be validated against.
+ @see org.jboss.ejb.Container#getMethodPermissions(Method, boolean)
+*/
+ public Set getMethodPermissions(String methodName, Class[] params, boolean
remote)
+{
+ Set result = new HashSet();
+// First check the excluded method list as this takes priority over all
other assignments
+Iterator iterator = getExcludedMethods();
+while( iterator.hasNext() )
+{
+ MethodMetaData m = (MethodMetaData) iterator.next();
+ if( m.patternMatches(methodName, params, remote) )
+{
+/* No one is allowed to execute this method so add a role that
+ fails to equate to any Principal or Principal name and return.
+ We don't return null to differentiate between an explicit
+ assignment of no access and no assignment information.
+*/
+result.add(NobodyPrincipal.NOBODY_PRINCIPAL);
+return result;
+}
+}
+
+// Check the permissioned methods list
+iterator = getPermissionMethods();
+while( iterator.hasNext() )
+{
+ MethodMetaData m = (MethodMetaData) iterator.next();
+ if( m.patternMatches(methodName, params, remote) )
+{
+/* If this is an unchecked method anyone can access it so
+ set the result set to a role that equates to any Principal or
+ Principal name and return.
+*/
+if( m.isUnchecked() )
+{
+result.clear();
+result.add(AnybodyPrincipal.ANYBODY_PRIN
[JBoss-dev] CVS update: jboss/src/main/org/jboss/security AnybodyPrincipal.java NobodyPrincipal.java
User: starksm
Date: 01/06/10 23:15:57
Added: src/main/org/jboss/security AnybodyPrincipal.java
NobodyPrincipal.java
Log:
Utility principal implementations
Revision ChangesPath
1.1 jboss/src/main/org/jboss/security/AnybodyPrincipal.java
Index: AnybodyPrincipal.java
===
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.security;
import java.security.Principal;
/** An implementation of Principal and Comparable that represents any role.
Any Principal or name of a Principal when compared to an AnybodyPrincipal
using {@link #equals(Object) equals} or {@link #compareTo(Object) compareTo}
will always be found equals to the AnybodyPrincipal.
@author [EMAIL PROTECTED]
@version $Revision: 1.1 $
*/
public class AnybodyPrincipal implements Comparable, Principal
{
public static final String ANYBODY = "";
public static final AnybodyPrincipal ANYBODY_PRINCIPAL = new AnybodyPrincipal();
public int hashCode()
{
return ANYBODY.hashCode();
}
/**
@return ""
*/
public String getName()
{
return ANYBODY;
}
public String toString()
{
return ANYBODY;
}
/** This method always returns 0 to indicate equality for any argument.
This is only meaningful when comparing against other Principal objects
or names of Principals.
@return true to indicate equality for any argument.
*/
public boolean equals(Object another)
{
return true;
}
/** This method always returns 0 to indicate equality for any argument.
This is only meaningful when comparing against other Principal objects
or names of Principals.
@return 0 to indicate equality for any argument.
*/
public int compareTo(Object o)
{
return 0;
}
}
1.1 jboss/src/main/org/jboss/security/NobodyPrincipal.java
Index: NobodyPrincipal.java
===
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.security;
import java.security.Principal;
/** An implementation of Principal and Comparable that represents no role.
Any Principal or name of a Principal when compared to an NobodyPrincipal
using {@link #equals(Object) equals} or {@link #compareTo(Object) compareTo}
will always be found not equal to the NobodyPrincipal.
@author [EMAIL PROTECTED]
@version $Revision: 1.1 $
*/
public class NobodyPrincipal implements Comparable, Principal
{
public static final String NOBODY = "";
public static final NobodyPrincipal NOBODY_PRINCIPAL = new NobodyPrincipal();
public int hashCode()
{
return NOBODY.hashCode();
}
/**
@return ""
*/
public String getName()
{
return NOBODY;
}
public String toString()
{
return NOBODY;
}
/** This method always returns 0 to indicate equality for any argument.
This is only meaningful when comparing against other Principal objects
or names of Principals.
@return false to indicate inequality for any argument.
*/
public boolean equals(Object another)
{
return false;
}
/** This method always returns 1 to indicate inequality for any argument.
This is only meaningful when comparing against other Principal objects
or names of Principals.
@return 1 to indicate inequality for any argument.
*/
public int compareTo(Object o)
{
return 1;
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Busy wait on one thread
Marc, I've rewritten EntityInstanceInterceptor a little(see my race condition fix email please) and put it some code so that LOCKING-WAITING isn't printed a zillion times. I also added a Thread.yield() before continue; in the lock-do-while-loop. I've also started looking into ditching the do..while loop in favor of wait/notify. It's much more complicated than I originally anticipated, but I'm making progress. IMHO, the whole locking business should be ditched when you have commit-option-C. Let the database to the synching for you with the select-for-update feature(CMP) or make the BMP developers handle the locking. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Sunday, June 10, 2001 10:05 PM > To: Jboss-Development@Lists. Sourceforge. Net > Subject: [JBoss-dev] FW: Busy wait on one thread > > > busy wait problem, see original message below > > we are on top of it, as of may 10... > > again vinay, please pay my (due) respects to matt, do say that it is NOT a > full busy wait (I.e. n-1 threads go to sleep) but one thread ALWAYS goes > through and therefore under high load it can become a problem... > > I will try to fix this this week as simone is visiting napa valley and 17 > miles drives (btw he is a VERY nice guy)... > > marcf > > |-Original Message- > |From: Bordet, Simone [mailto:[EMAIL PROTECTED]] > |Sent: Thursday, May 10, 2001 5:59 PM > |To: 'marc fleury' > |Subject: R: Busy wait on one thread > | > | > |Hi Marc, > | > |> Simone, > |> > |> ok the semaphore stuff lets' one go through but you release > |> the semaphore > |> before you do the execution of the code. Therefore we lock > |> the instance and > |> then release the semaphore mutex and the next thread comes in. > |> > |> If you have 2 threads, one comes in passes the mutex, > |> acquires the ctx lock > |> and releases the mutex. It then goes on to execute an update > |> that takes, > |> for example, one minute. > |> > |> The second thread comes in, passes the mutex (no one is > |> there), try to get > |> the ctx lock but sees it is locked and just goes on logging > |> "LOCKING-WAITING" and TRIES AGAIN. > |> > |> This gives rise to tons of LW messages with 2 threads > |> > |> This is a busy wait for one thread, you do not sync on the > |> state of the > |> target context since your release is just on the mutex. > |> > |> Unless I am missing something, we need to rethink this a bit. > |> I will make > |> the time to fix it > | > |Correct. > |I already had heavy sessions on it say one month ago, but did > not finished, > |and then got damn busy at work. > |FYI, I changed the busy wait to a wait-notify (I already commited the > |utility class WaitSemaphore under jboss/util for that, but not the > |interceptor), then run into troubles with the instance pool and the > |transactions (commit C), finally I thought "I should debug one thing at a > |time", and eventually run out of time. I'm a bit upset for this, > I'd really > |like to spend much more time on JBoss... > |After June I should have more time, at work the pressure should lighten. > |Anyway I'm open to help anyone wants to take a cranck on that > code, or fix > |it myself when I'll have more time, just let me know. > |Oh, I will spend 3 weeks (summer holidays) in US after JavaOne, > |maybe we can > |keep in touch and have a beer together, why not ? > | > |Regards, > | > |Simon > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] (no subject)
ÊÖ»ú£¬ÊýÂëÓ°µú»ú + 200ÍòÉÏÍøСʱ ¡¡ ¾«²ÊÅÉËÍ£¡¿ì¿ìµã»÷ >> http://win.163.com Á¢¼´²ÎÓë »ú»á¶à¶à £¡£¡£¡ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Using of JBoss in the real world
PLEASE PUT THIS IN A FORMAT WE CAN USE ON THE WEBSITE (and send it to me directly :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill |Burke |Sent: Monday, June 04, 2001 1:30 PM |To: K.V. Vinay Menon |Cc: Jboss-Development@Lists. Sourceforge. Net; Jay Walters |Subject: RE: [JBoss-dev] Using of JBoss in the real world | | |Vinay, | |We're curious on your specs as well, please get back to us?Anyways, |here's ours. | |We're an e-marketing service for small to mid-sized ecommerce merchants. |The most data intensive thing we do is collect click and order |data from our |registered merchants so our transactional data access outnumbers read-only |at least 2 to 1, maybe even 3, 4 to 1. Luckily most of our transactions |come in batch, so we have to worry less about too many concurrent users. |About 10% of our traffic will come from actual merchants hitting our UI |through JSPs. | |We're using Jetty3.0.6 and JBoss 2.2.1 with CMP(Container Managed |Persistence and Transactions) in an integrated stack. We |synchronize access |to Entity beans across JBoss instances via the select-for-update CMP |feature(that we added :-) ) | |We've done load testing with 4, 600Mgz, 256Meg ram, Single CPU Intel boxes |running Linux, one running Oracle only, 3 running Jetty/Jboss. We found we |can support 4K-5K merchants(500 clicks per day per merchant 2 inserts, 2 |updates, 2 reads per click on average) with these crappy machines. In |production, we'll have 3 dual CPU 800Mgz Intel Boxes with 512Meg RAM each |running Jetty/JBoss, and one dual processor Sun Sparc with 1 or 2 gig RAM |running Oracle. HTTP(S) traffic is load-balanced to the 3 Jetty/JBoss |machines via an ArrowPoint Cisco load balancer. We haven't done any |load-testing with this configuration, but hope to be able to handle 40K-50K |merchants. | |Another interesting point is that we switched from using Weblogic 5.1 after |9 months development. We switched for budgetary reasons (DotCom woes). |Those budgetary reasons are no longer a problem, but we've found no reason |to switch back to WebLogic. We really like having the source code around. | |Regards, |Bill | |> -Original Message- |> From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]] |> Sent: Monday, June 04, 2001 10:50 AM |> To: [EMAIL PROTECTED] |> Subject: Re: [JBoss-dev] Using of JBoss in the real world |> |> |> Bill, |> We are also planning to use Tomcat-JBoss in production pretty soon. |> Would really appreciate if you could send details of the kind of |> applications you have deployed, the kind of database access it does |> [proportion of read only vs transactional data] and the application |> architecture overall. |> |> Cheers, |> |> Vinay |> - Original Message - |> From: "Bill Burke" <[EMAIL PROTECTED]> |> To: <[EMAIL PROTECTED]> |> Sent: Monday, June 04, 2001 2:47 PM |> Subject: RE: [JBoss-dev] Using of JBoss in the real world |> |> |> > Hey, |> > |> > We've been using Jetty3.0.6/JBoss 2.2.1 since March on Linux |> and have been |> > in early access mode since then and plan to fully release this |> month. We |> > plan to scale up to 2 million DB transaction per day by |> Christmas, if not |> > more. We are running multiple instances of JBoss, on multiple |machines, |> > hooking into one large DB server running Oracle on a Sun box. |> If you want |> > more info, send me an email. |> > |> > |> > Regards, |> > Bill Burke |> > Senior Software Engineer |> > Mercantec |> > |> > |> > > -Original Message- |> > > From: [EMAIL PROTECTED] |> > > [mailto:[EMAIL PROTECTED]]On |Behalf Of Per |> > > Nyfelt |> > > Sent: Saturday, June 02, 2001 9:18 AM |> > > To: [EMAIL PROTECTED] |> > > Subject: RE: [JBoss-dev] Using of JBoss in the real world |> > > |> > > |> > > How would you like to collect this information? If we want |to get some |> > > accuracy of how many sites/systems are out there running |> JBoss i think a |> > > simple registration procedure should exist and then do a polling dev, |> user |> > > and business lists (at least) pointing to the registration place. |> > > |> > > Best regards, |> > > Per Nyfelt |> > > (In production with JBoss-Tomcat since March 5 2001 at |> www.resourcing.se) |> > > |> > > -Original Message- |> > > From: [EMAIL PROTECTED] |> > > [mailto:[EMAIL PROTECTED]]On Behalf Of |> Andreas |> > > Schaefer |> > > Sent: den 1 juni 2001 05:15 |> > > To: [EMAIL PROTECTED]; |> > > [EMAIL PROTECTED] |> > > Subject: [JBoss-dev] Using of JBoss in the real world |> > > |> > > |> > > Hi Geeks |> > > |> > > Lately I was trying to convince colleques to use JBoss instead |> > > of the other App. Servers and most of them just asked me who |> > > does use JBoss in production (and I had no anwser). |> > > |> > > Therefore my call to all of you please tell who is using JBoss in |> > > production. Thus we maybe can use this on the JBoss website |> > > (if we get the OK from Marc) tell me also if this could be list
RE: [JBoss-dev] JMSContainerInvoker.java
|I do like simplicity of management (that why I redo every JBoss |distribution so I can configure it with a single property file - Ant, |copy and filter). what do you mean, what do you redo? | |# Here some code | |set_my_variable(11); |print get_my_variable; | |What do you think one will get, yes 1. Do you get any warnings? NO. Is |it hard to debug? Oh, yes. Verry hard. | |I think automatic creation of destinations for MDB suffers the same of |problems. geez you guys are all banging on this feature... you know what? two peas in a bucket f*ck it! (as my father in law will say (deep south))... we will see if people complain |What happens when a created destination is suddenly destroyed when the |MDB is undeployed (perhaps for a redeploy because of code change)? Well, |all publisher to that destination will bark and be gone (if they was not |coded to be failsafe). Suddenly we do not have a loosly coupled system |any more, but the destination becomes just another remote interface |against the bean (answer: use stateless sessions instead of MDB). uh tell me how is that related to the fact that we create it at deployment time? if you remove a destination (period) then all clients will be barking... if not then create a "durable topic" in the right JMS stuff... we are not out to solve the world problems, if you want a durable topic then you need to tell us. I still stick to my guns (and I could be wrong) |Ok,ok,ok. The only (I say only) acceptable thing a can think of is that |it *might* be OK if the jboss.xml is completly missing. Then we might do |somethink like automatic creation, *but only then*. ah... look at me in the eye... yes I do see that gleam in the corner of your eye... you still see it don't you? yeah..ease of use for management, the "dirty step child" of J2EE we are squarely competing at the low end with very high end features for management... yeah you know it! yeah that gleam... (drunk) marcf | |2. Is it a good think to implement it in JMSContainerInvoker? | |Well, maybe not. The container invoker is designed to be agnostic about |the underlying JMS provider. All its ways to communicate with the JMS |provider is done through indirection and interfaces. If this is placed |in JMSContainerInvoker it should not be dependand on any special JBossMQ |features, such as being able to create destinations on the fly through |JMX. Or perhaps to be more correct, if this is done, is must be a part |of the org.jboss.jms package that a JMX based destination creator is |part of the JMSContainerInvoker contact. | |Was that clear, or am I just babling around? | |Chers |Peter | | |On 1 Jun, Hiram Chirino wrote: |> My vote on the issue is turn the feature OFF by default. |> |> A JMS queue is like a database table: I don't want the thing getting |> created and destroyed every time I deploy and undeploy a bean. This is |> mainly doe to the time indepenent processing "feature" JMS usually gives |> you. If you are creating and destroying a destination, the publisher |> becomes time dependent on when the bean is deployed (does this |make sense?). |> |> Regards, |> Hiram |> |> |> - Original Message - |> From: "Juha-P Lindfors" <[EMAIL PROTECTED]> |> To: <[EMAIL PROTECTED]> |> Sent: Friday, June 01, 2001 6:34 PM |> Subject: RE: [JBoss-dev] JMSContainerInvoker.java |> |> j |>> |>> |>> On Fri, 1 Jun 2001, marc fleury wrote: |>> > to clear fuck-ups... yet if you screw up it doesn't hide the mistake, |> your |>> > application won't work. |>> |>> yes... but I want to know exactly *WHY* it doesn't work :) |>> |>> > |I'd much rather see the lookup fail than have the server hide my fuck |> ups. |>> > |Because that very clearly indicates something's wrong in the |>> > |configuration. |>> > |>> > and by doing so you prevent those that didn't fuck up from having a |>> > convenient feature. Design by exception. |>> |>> hey, I just like my errors pointed out to me in a clear and unambiguous |>> matter. It's because I make lots of them and have rarely fun time trying |>> to find them... :P |>> |>> |>> > |The proposed implementation requires me to go clean up the |jbossmq.xml |>> > |unless I like to have the naming space cluttered with stuff |that wasn't |>> > |supposed to go there. It also allows the application to |silently fail, |> as |>> > |Peter pointed out. |>> > |>> > Please read my mails, point 7. |>> |>> you make too many, and they're repetitive and become boring :) |>> |>> |>> > Also, I don't see the "silently" point, if you don't have the |right name |> you |>> > get 2 things from us |>> > 1- A "Creating topic" |>> > 2- An exception in your application |>> |>> I mean, where I create a MDB and lookup 'bob' which isnt right |>> or configured and the server then creates it, and then have a client |>> that *correctly* looks up 'Bob' which was probably configured |by some guy |>> three years ago. Everyone's happy, except I'm tearing |>> my hair out wondering why the fuck my messages arent getting throu
[JBoss-dev] FW: Busy wait on one thread
busy wait problem, see original message below we are on top of it, as of may 10... again vinay, please pay my (due) respects to matt, do say that it is NOT a full busy wait (I.e. n-1 threads go to sleep) but one thread ALWAYS goes through and therefore under high load it can become a problem... I will try to fix this this week as simone is visiting napa valley and 17 miles drives (btw he is a VERY nice guy)... marcf |-Original Message- |From: Bordet, Simone [mailto:[EMAIL PROTECTED]] |Sent: Thursday, May 10, 2001 5:59 PM |To: 'marc fleury' |Subject: R: Busy wait on one thread | | |Hi Marc, | |> Simone, |> |> ok the semaphore stuff lets' one go through but you release |> the semaphore |> before you do the execution of the code. Therefore we lock |> the instance and |> then release the semaphore mutex and the next thread comes in. |> |> If you have 2 threads, one comes in passes the mutex, |> acquires the ctx lock |> and releases the mutex. It then goes on to execute an update |> that takes, |> for example, one minute. |> |> The second thread comes in, passes the mutex (no one is |> there), try to get |> the ctx lock but sees it is locked and just goes on logging |> "LOCKING-WAITING" and TRIES AGAIN. |> |> This gives rise to tons of LW messages with 2 threads |> |> This is a busy wait for one thread, you do not sync on the |> state of the |> target context since your release is just on the mutex. |> |> Unless I am missing something, we need to rethink this a bit. |> I will make |> the time to fix it | |Correct. |I already had heavy sessions on it say one month ago, but did not finished, |and then got damn busy at work. |FYI, I changed the busy wait to a wait-notify (I already commited the |utility class WaitSemaphore under jboss/util for that, but not the |interceptor), then run into troubles with the instance pool and the |transactions (commit C), finally I thought "I should debug one thing at a |time", and eventually run out of time. I'm a bit upset for this, I'd really |like to spend much more time on JBoss... |After June I should have more time, at work the pressure should lighten. |Anyway I'm open to help anyone wants to take a cranck on that code, or fix |it myself when I'll have more time, just let me know. |Oh, I will spend 3 weeks (summer holidays) in US after JavaOne, |maybe we can |keep in touch and have a beer together, why not ? | |Regards, | |Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test results
JBoss daily test results SUMMARY Number of tests run: 80 Successful tests: 61 Errors:9 Failures: 10 [time of test: 11 June 2001 2:48] See http://lubega.com for full details DETAILS OF ERRORS Suite: org.jboss.test.cts.test.AllJUnitTests Test:testRemoveSessionObject Type:failure Exception: junit.framework.AssertionFailedError Message: [EJB 1.1, p42, section 5.3.2] Expected 'RemoveException' when remove-ing a session object, detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory) Stack Trace: junit.framework.AssertionFailedError: [EJB 1.1, p42, section 5.3.2] Expected 'RemoveException' when remove-ing a session object, detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory) at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testRemoveSessionObject(StatefulSessionTest.java:188) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342) - Suite: org.jboss.test.cts.test.AllJUnitTests Test:testProbeBeanContext Type:failure Exception: junit.framework.AssertionFailedError Message: Caught an unknown exception in testProbeBeanContex Stack Trace: junit.framework.AssertionFailedError: Caught an unknown exception in testProbeBeanContex at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testProbeBeanContext(StatefulSessionTest.java:467) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342) - Suite: org.jboss.test.cts.test.AllJUnitTests Test:testEjbRemove Type:failure Exception: junit.framework.AssertionFailedError Message: Got Exception: expecting NoSuchObjectExceptionjava.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Instance 007 not found in database.; nested exception is: javax.ejb.NoSuchEntityException: Instance 007 not found in database. Stack Trace: junit.framework.AssertionFailedError: Got Exception: expecting NoSuchObjectExceptionjava.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Instance 007 not found in database.; nested exception is: javax.ejb.NoSuchEntityException: Instance 007 not found in database. at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.BmpTest.testEjbRemove(BmpTest.java:224) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155)
RE: [JBoss-dev] Caching - Locking - Server Dies!
|Oops, I didn't expect that! Not that I really have a deep |understanding of the code, but the problem seems not to be with |the locking of the context, but with your beans not beeing marked it is in the mutex... it is a JBOSS bug... marc |as reentrant, thus only one client can access a bean at any given |time. | |The code there does not distinguish between a method executing in |the right transaction and a method executing without a |transaction at all. I just can't remember if the EJB specs are |clear about non reentrant beans accessed outside a transaction |(have to read that thing even once more :-(), but the implemented |behaviour is on the safe side. | |Not beeing 'reentrant' allows the bean provider to write simple |code without synchronizing and all the complicated issues, that |arise when you must consider concurrent access (and synchronizing |etc. is forbidden anyway in EJBs). See spec 1.1 9.1.12. Only when |you have 'callback' in mind, you should allow reentrant beans. | |In your case, I'm pretty sure, that the conflict is NOT caused by |callbacks, but by several clients attempting to concurrently |access your beans. Within a transaction this clearly must be |blocked (or, as the specs require, 'solved' with a |RemoteException). | |But in your case, only reading the beans outside a TX, where the |gotten state must be considered invalid, wrong, old, outdated |anyway, it should be no problem at all to allow concurrent |access. | |So, to continue your tests, declare your beans as 'reentrant'! | |What's not nice with this workaround is, that a reentrant bean |might get accessed inside one and the same transaction from |different clients (in the rare case, where a superclient starts a |transaction, then spawns new threads (inheriting the TX) for |different activities, do you know other scenarios?). So it might |be better, to change the code to sort out access outside a TX |allowing concurrency even when the bean is not reentrant?? | |And, besides, the code suffers from the same problems as I told |you in my last mail to this thread: not waiting and thus going |into a tight loop with tons of messages and eating up CPU time; |maybe, it would be better to throw the RemoteException the spec |asks for? | |> Why is it locking for readonly bean? Why does it need to do it? | |For the transactional case I told you already; for |nontransactional access I propose ignoring the reentrant flag |(only if the spec does not explicitely disallow it or someone can |point out the danger with it). | |> The effects are only marginal and hardly detectable at low loads. |> It is more pronounced at higher loads and as the table size |> increase it goes into a real amplifying loop where the beans wait |> and take longer to return and that in turn cause the lock to be |> longer and so on. | |Would be 'solved' by an Exception and should be considerably |better, when the server actually would wait instead of going into |the tight loop. | |> Strange that the method does not check for read-only attribute |> either? Why is that? | |As of the spec there is no 'readonly' method, name it: the spec |sucks? | |best regards |Georg | ___ ___ || + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg ||_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Application.getName() equals Application.getURL()
Hi Roland When you have a look at the JMX HTML-Adaptor (http://localhost:8082 by default) you will find under domain: managment a DataCollector MBean. This MBean (in the near future) is the one delivering the management data inclusive the Applications with the EJBs, Servelts/JSPs and Connectors etc. I hope this will be up and running by tomorrow. See ya - Andy - Original Message - From: "Ronald van Kuijk" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 10, 2001 6:00 PM Subject: [JBoss-dev] Application.getName() equals Application.getURL() > Hi, > > I'd like to start implementing a web based user-interface for JBoss. Kinda like Bea WLS. I'll be using MBeans for that, but my first problem is that the application name (the display-name in the application.xml) is not available. I thougt it would be Application.getName(), but that always seems to be equal to Application.getURL(). I've looked into the source of several files but Application.setName(String) never seems to be called (besides from setURL() where it is made equal to the url ) The 'problem' is that the name is not available at the moment setURL is called, so no separate setName can be performed. > > Am I correct this is not possible? I could start a complex workaround by looking op a 'Deployment' based on the URL and then do a setName(Deployment.name). > > Any other ideas? > __ > Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Caching - Locking - Server Dies!
|but there actually is NO sleep in the code, causing the thread |to go into a tight loop, producing tons of LOCKING-WAITING |messages and consuming up to 90% of processor time. I don't know |why the wait was left out, maybe it was a planned feature and |forgotten about? There was a patch suggested some month (!) well, credit to Simone for good and bad. good is that we have a better cache, bad is that he fucked up that mutex with a "busy wait on ONE thread" bug. no biggy. |ago to reduce the amount of messages to one start message and |one end message; this patch wasn't picked up by any developer, |I think, because it would tigthen the loop even more (as it is, |I believe the massive message amount leaves 10% CPU because of |waiting for IO). that is bad again fixable... actually I will try to jump to the end of the stack of messages you sent see if it is fixed... it is a tricky one as the passivation can be a b**ch to fix... the first version of the cache did behave correctly and that is what we tested JBOSS with on the high end solaris machine... when I came back from London I did read this code and saw the bug, notified Simone, he said he was aware of it, just no time to work on it ... will work on it... |So the correct solution for this issue would be a wait there |and the accompanying notify/notifyAll at the place, where the |lock is released. With that correction the LOCKING-WAITING relax... |message would only appear once before the wait, making the |suggested patch unneccessary, and not eat up CPU anymore. |I believe that this would drastically change your response |times even when accessing the beans inside a transaction. | |As I havn't digged deep enough into JBoss code (and have no |write access to CVS) I only can hope, that one of the gurus |sees this, picks it up and fixes it. Georg... you seem to have a good understanding... relax... marc | |hope this helps |Georg | ___ ___ || + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg ||_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 | |PS: Please report your stress test results on this list, I think |both, performance for accessing the beans inside and outside |a transaction, are very interesting. | |PS2: Besides, that cited code mentiones a possible deadlock in | another comment, but there seems to be no deadlock resolving |code. I think, this too should be addressed soon, in a real app |with heavy load it's really likely, that deadlock can happen. |If your test clients i.e. access the same beans in random order |in ONE transaction (via session bean facade for instance) you |easily should be able to run into a deadlock. | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Fw: Caching - Locking - Server Dies!
no the
code is the mutex stuff that always lets one thread through, and even though one
is working below on the code (outside the mutex) you can't get the real lock
since your current thread is actually second ..
marcf
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
Vinay MenonSent: Monday, June 04, 2001 1:19 PMTo: User @
JBoss; Dev @ JBossSubject: [JBoss-dev] Fw: Caching - Locking -
Server Dies!
Hi,
The following seems to be the code,
// Get
context
ctx = cache.get(key);
// Do we have a running transaction with the
context
Transaction tx =
ctx.getTransaction();
if (tx != null
&&
// And are we trying to enter with another
transaction
!tx.equals(mi.getTransaction()))
{
// Let's put the thread to sleep a lock release will wake the
thread
// Possible
deadlock
Logger.debug("LOCKING-WAITING (TRANSACTION) for id "+ctx.getId()+" ctx.hash
"+ctx.hashCode()+" tx:"+((tx == null) ? "null" : tx.toString()));
// Try your luck
again
ctx =
null;
continue;
for the EntityInstanceInterceptor that actually causes this condition. I
have NOT specified any assembly descriptors in my ejb-jar.xml. What
transaction mode does JBoss then default to?
Vinay
- Original Message -
From: K.V. Vinay Menon
To: User @ JBoss ; Dev @ JBoss
Sent: Monday, June 04, 2001 5:58 PM
Subject: Caching - Locking - Server Dies!
Hello Folks,
Continuing with my load test
I find something strange. I have a test harness that simulates 100 clients
hitting the server at 100ms. They all retrieve the same data - 150 odd
records - from the database. The cache size has been set to 10.
Commit option is A. Am not doing any write operations.
1. The retrieve for the first client is high as
expected.
2. This then falls rapidly to about 90ms.
3. However the response time then rises to aout
20 seconds.
On checking the server log, I am getting loads
of 'LOCKING-WAITING (TRANSACTION)' messages. And its due to this locking
I presume that the response time takes a beating.
a) Why is it not just reading data from
cache?
b) Why is it locking for read only
opertions?
Why is this so? All this seems very strange.
Either I am missing something or the caching is not working for high loads.
Regards,
Vinay
RE: [JBoss-dev] Caching - Locking - Server Dies!
Vinay see below, --- On checking the server log, I am getting loads of 'LOCKING-WAITING (TRANSACTION)' messages. And its due to this locking I presume that the response time takes a beating. a) Why is it not just reading data from cache? b) Why is it locking for read only opertions? Why is this so? All this seems very strange. Either I am missing something or the caching is not working for high loads. Regards, Vinay PLEASE TURN OFF THE FREAKING HTML Ok this is a known bug (at least to me), I have sent emails to Simone privately when I read his code. The issue is that the logic for the lock is a busy-wait on one thread. You will present my apologies to Matt, while it is not a fully busy wait (i.e. not ALL threads go in busy wait) we do have ONE thread that ALWAYS goes in busy wait... that is REALLY bad. It is fixable though. I did talk to SImone over the week (we spent most of JavaONE talking) but he will be gone for the month, he is visiting the US and training for yet another triathlon... I see that people are answering this, if it is not yet fixed let me know, I believe I know the solution to that one. marc ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Mail!
Just turn off the f***ing Html and you will see that it will work :) marc -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of K.V. Vinay MenonSent: Monday, June 04, 2001 12:15 PMTo: User @ JBoss; Dev @ JBossSubject: [JBoss-dev] Mail! Is it just me or is the mailiing list not working! Don't seem to get any of my mails! [And yes, I have chosen to receive copies of my mails] Vinay
RE: [JBoss-dev] CVS update: jboss-j2ee/src/build build.xml
| Modified:src/build build.xml | Log: | Complete set of changes for EJB 2.0 PFD 2.0. | Thanks to Jasper Pedersen - [EMAIL PROTECTED] hehe, just when I bang on Jasper, for not contributing, there seems to be stuff he gives... ok then, apologies, marcf | | Revision ChangesPath | 1.8 +1 -1 jboss-j2ee/src/build/build.xml | | Index: build.xml | === | RCS file: /cvsroot/jboss/jboss-j2ee/src/build/build.xml,v | retrieving revision 1.7 | retrieving revision 1.8 | diff -u -r1.7 -r1.8 | --- build.xml2001/04/29 11:39:13 1.7 | +++ build.xml2001/06/04 15:57:17 1.8 | @@ -35,7 +35,7 @@ | | | | - | + | |
RE: [JBoss-dev] Logging Cache Hits
proves I should really go back and review most of the code :) I wasn't aware of this "topnotch" feature, a simone-juha feature I take it marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Bordet, Simone |Sent: Monday, June 04, 2001 11:29 AM |To: '[EMAIL PROTECTED]' |Subject: RE: [JBoss-dev] Logging Cache Hits | | |Hey Vinay, | |There is no way to track cache hits, but there is the possibility to track |cache misses (and almost every other cache activity). You have to set the |BeanCacheJMSMonitoringEnabled flag to true in the container factory MBean |(jboss.jcml), and then write a client that listen for the wanted |messages on |the "beancache" topic. |See the 2 jars in dist/bin (sources are included) for monitoring the cache |using JMX and/or JMS (beware that may be out of date, especially the JMS |one, because of topic name changes). See also the code in |AbstractInstanceCache and LRUEnterpriseContextCachePolicy for JMS messages |sent on cache activity. | |Hope helped, | |Simon | |-Original Message- |From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]] |Sent: lunedì 4 giugno 2001 13:07 |To: User @ JBoss; Dev @ JBoss |Subject: [JBoss-dev] Logging Cache Hits | | |Hi, | Does anyone know how to turn on cache hit tracking in JBoss without |recompiling the code!? Is this possible? I am trying to stress JBoss to |about as far as it can get [it has not yet fallen over!!! ] but |the time for |queries seem a bit odd. I have large intial retrieval times and then they |fall off [as expected I guess dues to cache hits - want to confirm this |though]. But I do get spikes in the middle [probably because the number of |beans has reached a stage where passivation kicks in]. What I'd |like to know |is whether successive queries actually hit the database or work [as |promised] by hitting the cache even under very high loads. I am |testing with |about 1 client threads hitting the application server any where between |10milliseconds to about 1000 milliseconds on a huge Tru64 box. The queries |could return 1,15,150,1250 records depending on the type of client. The |underlying table has about half a million records and is an Oracle 8i |database. | |Regards, | |Vinay | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Using of JBoss in the real world
what do you mean "if you want more info, send me an email"... YOU SEND ME A COMPLETE DESCRIPTION RIGHT NOW OF THE NUMBER OF CLIENTS YOU CAN SCALE WITH OUR STUFF, SO WE CAN BRAG, BRAG, BRAG, BRAG about it! please? :) marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill |Burke |Sent: Monday, June 04, 2001 9:47 AM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Using of JBoss in the real world | | |Hey, | |We've been using Jetty3.0.6/JBoss 2.2.1 since March on Linux and have been |in early access mode since then and plan to fully release this month. We |plan to scale up to 2 million DB transaction per day by Christmas, if not |more. We are running multiple instances of JBoss, on multiple machines, |hooking into one large DB server running Oracle on a Sun box. If you want |more info, send me an email. | | |Regards, |Bill Burke |Senior Software Engineer |Mercantec | | |> -Original Message- |> From: [EMAIL PROTECTED] |> [mailto:[EMAIL PROTECTED]]On Behalf Of Per |> Nyfelt |> Sent: Saturday, June 02, 2001 9:18 AM |> To: [EMAIL PROTECTED] |> Subject: RE: [JBoss-dev] Using of JBoss in the real world |> |> |> How would you like to collect this information? If we want to get some |> accuracy of how many sites/systems are out there running JBoss i think a |> simple registration procedure should exist and then do a polling |dev, user |> and business lists (at least) pointing to the registration place. |> |> Best regards, |> Per Nyfelt |> (In production with JBoss-Tomcat since March 5 2001 at www.resourcing.se) |> |> -Original Message- |> From: [EMAIL PROTECTED] |> [mailto:[EMAIL PROTECTED]]On Behalf |Of Andreas |> Schaefer |> Sent: den 1 juni 2001 05:15 |> To: [EMAIL PROTECTED]; |> [EMAIL PROTECTED] |> Subject: [JBoss-dev] Using of JBoss in the real world |> |> |> Hi Geeks |> |> Lately I was trying to convince colleques to use JBoss instead |> of the other App. Servers and most of them just asked me who |> does use JBoss in production (and I had no anwser). |> |> Therefore my call to all of you please tell who is using JBoss in |> production. Thus we maybe can use this on the JBoss website |> (if we get the OK from Marc) tell me also if this could be listed |> on the JBoss website (if not mentioned I will assume that you |> don't want it). |> |> Have fun - Andy |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> http://lists.sourceforge.net/lists/listinfo/jboss-development |> | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Logging Cache Hits
wow 10,000 client threads in parallel gezus... and do you run that from teh same box? glad you can't bring JBOSS down to it's knees... hehe... (also please turn off HTML when posting to this list) You might want to try turning OFF the cache completely (by specifying the nopassivation cache in the standardjboss.xml stuff). Also keep in mind that if you are retrieving 1250 records then we need to serialize 1250 proxies which should take 100 times more than 12,5 proxies :) so if you see 1000 millisecond (e.g. a second :) with the cache turned OFF then you really have a large query being returned. Other than that, just very proud that you can't crash our stuff (your stuff now vinay ;-)... what is the VM on Tru64? marc -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of K.V. Vinay MenonSent: Monday, June 04, 2001 7:07 AMTo: User @ JBoss; Dev @ JBossSubject: [JBoss-dev] Logging Cache Hits Hi, Does anyone know how to turn on cache hit tracking in JBoss without recompiling the code!? Is this possible? I am trying to stress JBoss to about as far as it can get [it has not yet fallen over!!! ] but the time for queries seem a bit odd. I have large intial retrieval times and then they fall off [as expected I guess dues to cache hits - want to confirm this though]. But I do get spikes in the middle [probably because the number of beans has reached a stage where passivation kicks in]. What I'd like to know is whether successive queries actually hit the database or work [as promised] by hitting the cache even under very high loads. I am testing with about 1 client threads hitting the application server any where between 10milliseconds to about 1000 milliseconds on a huge Tru64 box. The queries could return 1,15,150,1250 records depending on the type of client. The underlying table has about half a million records and is an Oracle 8i database. Regards, Vinay
RE: [JBoss-dev] [OT] EJBCreator 0.1.1 released
Jesper, until your really contribute something to JBOSS, your announcements are not really welcome on this list, regards marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Jesper Pedersen |Sent: Friday, June 08, 2001 9:59 AM |To: [EMAIL PROTECTED] |Cc: [EMAIL PROTECTED] |Subject: [JBoss-dev] [OT] EJBCreator 0.1.1 released | | |EJBCreator 0.1.1 has been released on our site: | |EJBCreator is able to generate source code skeletons for: | o Entity beans | o Session beans | o Message-driven beans | o Value objects | |EJBCreator doesn't depend on a specific J2EE application server, since all |code is generated based on the Enterprise JavaBeans specification |standard. | |Changelog: | o Bug fix for synchronized session EJBs in GUI | |EJBCreator can be downloaded from: | | http://opensource.itplus.dk/EJBCreator/ | |or | | ftp://ftp.itplus.dk/pub/EJBCreator/ | |Have fun ! | |Kind Regards, | | Jesper Pedersen | Open Source Solution Manager | |-- |Jesper Pedersen, M.Sc. C.S.E |Open Source Solution Manager | |Sun Certified Java 2 Developer | |IT+ A/S Phone: +45 86 78 21 00 |Brendstrupgårdsvej 7 Fax: +45 86 78 21 02 |DK-8200 Aarhus N Direct:+45 87 40 08 49 |Denmark Email: [EMAIL PROTECTED] | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Application.getName() equals Application.getURL()
Hi, I'd like to start implementing a web based user-interface for JBoss. Kinda like Bea WLS. I'll be using MBeans for that, but my first problem is that the application name (the display-name in the application.xml) is not available. I thougt it would be Application.getName(), but that always seems to be equal to Application.getURL(). I've looked into the source of several files but Application.setName(String) never seems to be called (besides from setURL() where it is made equal to the url ) The 'problem' is that the name is not available at the moment setURL is called, so no separate setName can be performed. Am I correct this is not possible? I could start a complex workaround by looking op a 'Deployment' based on the URL and then do a setName(Deployment.name). Any other ideas? __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Local interfaces prototype
|With (much appreciated) help from Jay Walters, I've added a |prototype for support of local interfaces to CVS. There are many |aspects of this I haven't tested (e.g. a bean with both local and |remote interfaces, functionality of the EnterpriseContext, etc.), so I |was hoping that some of you familiar with the EJB 2.0 spec could |use them a little and post problems to this list or Sourceforge bug |tracker... or, of course, fix problems yourself. :-) ok let's move this to JBOSS 3.0 branch... |I'm not posting this announcement to jboss-user because local |interface support definitely needs a little time to cook before it |enters general use. Please help me to cook it. Anyone who |disagrees with this may go ahead and cross post without further |discussion. :-) Oh come on Dan you are more of an old timer than that you know you are on your own (pretty much). |Just a quick design note for the code reviewers: I modeled local |interface support on the JRMP container invoker whenever |possible, so that someone familiar with that code base would |instantly understand what I was doing. However, I thought it better |not to add local interface support to the existing pluggable |ContainerInvoker system. This is because the local interfaces |implementation can remain constant as the distribution mechanism |(e.g. RMI/JRMP, CORBA, whatever...) changes. So local interfaces |are broken out. , I am not sure I understand the thought fully but the CI stuff is going to be fully detached from the invocation layer (part of Rabbit hole). I have a pretty clear idea on how to do that so the local interface should just be a plug in teh container directly, bypassing all invocation, and definitely independent of RMI, Corba, SOAP etc etc... |Also, you'll notice that I do not publish the home interface in our |JNDI system, except in a component name space when a bean |uses an ejb-local-ref. There is no reason to make the home globally |available, since local interfaces will only work for components |within an application. So instead, I publish the interfaces to the |application class. yep. |Finally, I made a small change to the verifier so it doesn't throw an |exception when a bean without remote interfaces is deployed. |However, you should know the local interfaces are not verified. |(Quick reminder: don't throw java.rmi.RemoteException.) Pardon my ignorance of teh 2.0 spec but the whole stack of interceptors still needs to be there for the local stuff right? in other words, the only thing you bypass is the RemoteContainerInvoker stuff right? I am going to remove that in the near future anyway... Finally, I thought that a bean could be Remote or Local and that it was transparent to the container, and we could use the same chain of invocations I understand that this is a separate container stack instanciated? so that you only have one mode of operation? marcf | |-Dan O'Connor | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util Scheduler.java
User: schaefera
Date: 01/06/10 17:52:23
Modified:src/main/org/jboss/util Scheduler.java
Log:
Accidentely I cleared this file.
Revision ChangesPath
1.3 +521 -0jboss/src/main/org/jboss/util/Scheduler.java
Index: Scheduler.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/Scheduler.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Scheduler.java2001/06/10 18:40:21 1.2
+++ Scheduler.java2001/06/11 00:52:23 1.3
@@ -0,0 +1,521 @@
+/*
+ * JBoss, the OpenSource EJB server
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
+ */
+package org.jboss.util;
+
+import java.lang.reflect.Constructor;
+import java.security.InvalidParameterException;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Date;
+import java.util.Hashtable;
+import java.util.Iterator;
+import java.util.Map;
+
+import javax.management.MalformedObjectNameException;
+import javax.management.MBeanServer;
+import javax.management.Notification;
+import javax.management.NotificationListener;
+import javax.management.ObjectName;
+import javax.naming.Context;
+import javax.naming.InitialContext;
+import javax.naming.Name;
+import javax.naming.NamingException;
+import javax.naming.NameNotFoundException;
+import javax.naming.Reference;
+import javax.naming.StringRefAddr;
+
+import org.jboss.logging.Log;
+import org.jboss.naming.NonSerializableFactory;
+import org.jboss.util.ServiceMBeanSupport;
+
+/**
+ * Scheduler Instance to allow clients to run this as a
+ * scheduling service for any Schedulable instances.
+ *
+ * @author Andreas Schaefer ([EMAIL PROTECTED])
+ **/
+public class Scheduler
+ extends ServiceMBeanSupport
+ implements SchedulerMBean
+{
+
+ // -
+ // Constants
+ // -
+
+ public static String JNDI_NAME = "scheduler:domain";
+ public static String JMX_NAME = "scheduler";
+
+ // -
+ // Members
+ // -
+
+ private MBeanServer mServer;
+ private String mName;
+
+ private long mSchedulePeriod;
+ private int mRemainingRepetitions = 0;
+ private int mActualSchedule = -1;
+ private boolean mScheduleIsStarted = false;
+ private boolean mWaitForNextCallToStop = false;
+ private ObjectName mTimer;
+ private Schedulable mSchedulable;
+
+ private boolean mStartOnStart = false;
+ private String mSchedulableClass;
+ private Object[] mInitArguments;
+ private String[] mInitTypes;
+ private Date mStartDate;
+ private long mPeriod;
+ private int mRepetitions;
+
+ // -
+ // Constructors
+ // -
+
+ /**
+* Default (no-args) Constructor
+**/
+ public Scheduler()
+ {
+ mName = null;
+ }
+
+ /**
+* Constructor with the necessary attributes to be set
+*
+* @param pName Name of the MBean
+**/
+ public Scheduler( String pName )
+ {
+ mName = pName;
+ }
+
+ /**
+* Constructor with the necessary attributes to be set
+*
+* @param pName Name of the MBean
+**/
+ public Scheduler(
+ String pName,
+ String pSchedulableClass,
+ String pInitArguments,
+ String pInitTypes,
+ long pInitialStartDate,
+ long pSchedulePeriod,
+ long pNumberOfRepetitions
+ ) {
+ mName = pName;
+ mStartOnStart = true;
+ mSchedulableClass = pSchedulableClass;
+// if( pInitArguments == null || pInitArguments.equals( "" ) ) {
+ mInitArguments = new Object[ 0 ];
+// }
+// if( pInitTypes == null || pInitTypes.equals( "" ) ) {
+ mInitArguments = new String[ 0 ];
+// }
+ mStartDate = new Date( pInitialStartDate );
+ mPeriod = pSchedulePeriod;
+ mRepetitions = (int) pNumberOfRepetitions;
+ }
+
+ // -
+ // SchedulerMBean Methods
+ // -
+
+ public void startSchedule(
+ String pSchedulableClass,
+ Object[] pInitArguments,
+ String[] pInitTypes,
+ Date pInitialStartDate,
+ long pSchedulePeriod,
+ int pNumberOfRepetitions
+ ) {
+ // Check if not already started
Re: [JBoss-dev] Container Management MBean problem...
Hi Geeks I fix the NPE caused by the destroying of the MBean within postRegister(). Now I only have to investigate why this happens. Andy - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 10, 2001 4:01 PM Subject: Re: [JBoss-dev] Container Management MBean problem... > I think this is the same problem. I am seeing sporadic failures on > redeploy with just the JBoss core without any servlet container. > > - Original Message - > From: "Andreas Schaefer" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, June 10, 2001 3:33 PM > Subject: Re: [JBoss-dev] Container Management MBean problem... > > > > Jules > > > > I made some changes to the ContainerFactory but I tested it to redeploy > > but only with Tomcat. > > > > Can you catch the RuntimeMBeanException and print out the Target > > Exception. I think Scott has or had a similar problem. > > > > Andy > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util ServiceMBeanSupport.java
User: schaefera
Date: 01/06/10 17:40:26
Modified:src/main/org/jboss/util ServiceMBeanSupport.java
Log:
Added a fix when the MBeanServer returns "false" to postRegister() then
the ServiceMBean will call destroy() which needs an instance of Log but
this is not created until init() is called.
Now the postRegister() will check if the Log instance is there and if not
create one.
Revision ChangesPath
1.13 +10 -2 jboss/src/main/org/jboss/util/ServiceMBeanSupport.java
Index: ServiceMBeanSupport.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/ServiceMBeanSupport.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ServiceMBeanSupport.java 2001/04/24 23:25:11 1.12
+++ ServiceMBeanSupport.java 2001/06/11 00:40:26 1.13
@@ -30,7 +30,7 @@
@author Rickard Öberg ([EMAIL PROTECTED])
@author [EMAIL PROTECTED]
-@version $Revision: 1.12 $
+@version $Revision: 1.13 $
*/
public abstract class ServiceMBeanSupport
extends NotificationBroadcasterSupport
@@ -172,8 +172,16 @@
public void postRegister(java.lang.Boolean registrationDone)
{
- if (!registrationDone.booleanValue())
+ if (!registrationDone.booleanValue()) {
+ if( category == null ) {
+category = Category.getInstance(getName());
+ }
+ if( log == null ) {
+log = new LogToCategory(category);
+ }
+ log.log( "Registration is not done -> destroy" );
destroy();
+ }
}
public void preDeregister()
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS ok again, sorry about that
ts ts ts you watch it young man... I know the feeling though, I plan on coming back to development this week and I believe I forgot the cvs commands... marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dan |OConnor |Sent: Sunday, June 03, 2001 3:44 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] CVS ok again, sorry about that | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Container Management MBean problem...
Hi I create a MBean wrapper instance for each EJB container created in ContainerFactory. It seems that this can cause the problem. The exception is catched and shouldn't hurt the application, does it ? I will investigate the problem and see if there is a race condition or a problem with my MBean wrapper. Andy - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 10, 2001 4:01 PM Subject: Re: [JBoss-dev] Container Management MBean problem... > I think this is the same problem. I am seeing sporadic failures on > redeploy with just the JBoss core without any servlet container. > > - Original Message - > From: "Andreas Schaefer" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, June 10, 2001 3:33 PM > Subject: Re: [JBoss-dev] Container Management MBean problem... > > > > Jules > > > > I made some changes to the ContainerFactory but I tested it to redeploy > > but only with Tomcat. > > > > Can you catch the RuntimeMBeanException and print out the Target > > Exception. I think Scott has or had a similar problem. > > > > Andy > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Local interfaces prototype
I can't seem to find how the current interceptor architecture plugs into the local interfaces method invocation. Does this exist? - Original Message - From: "Dan OConnor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 04, 2001 3:39 PM Subject: [JBoss-dev] Local interfaces prototype > Hi, > > With (much appreciated) help from Jay Walters, I've added a > prototype for support of local interfaces to CVS. There are many > aspects of this I haven't tested (e.g. a bean with both local and > remote interfaces, functionality of the EnterpriseContext, etc.), so I > was hoping that some of you familiar with the EJB 2.0 spec could > use them a little and post problems to this list or Sourceforge bug > tracker... or, of course, fix problems yourself. :-) > > I'm not posting this announcement to jboss-user because local > interface support definitely needs a little time to cook before it > enters general use. Please help me to cook it. Anyone who > disagrees with this may go ahead and cross post without further > discussion. :-) > > Just a quick design note for the code reviewers: I modeled local > interface support on the JRMP container invoker whenever > possible, so that someone familiar with that code base would > instantly understand what I was doing. However, I thought it better > not to add local interface support to the existing pluggable > ContainerInvoker system. This is because the local interfaces > implementation can remain constant as the distribution mechanism > (e.g. RMI/JRMP, CORBA, whatever...) changes. So local interfaces > are broken out. > > Also, you'll notice that I do not publish the home interface in our > JNDI system, except in a component name space when a bean > uses an ejb-local-ref. There is no reason to make the home globally > available, since local interfaces will only work for components > within an application. So instead, I publish the interfaces to the > application class. > > Finally, I made a small change to the verifier so it doesn't throw an > exception when a bean without remote interfaces is deployed. > However, you should know the local interfaces are not verified. > (Quick reminder: don't throw java.rmi.RemoteException.) > > -Dan O'Connor > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Container Management MBean problem...
Can you catch the RuntimeMBeanException and print out the Target Exception. I made some changes to ContainerFactory but tested it on JBoss/Tomcat (redeploy as well). Have fun - Andy - Original Message - From: "Julian Gosnell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 10, 2001 4:12 PM Subject: [JBoss-dev] Container Management MBean problem... > CVS of ~22:30GMT 10/6/2001 > > Trying to redeploy the same EAR, results in a pair of nasty exceptions: > > Just in case whoever is hacking on this is not aware of this one. > > Thanks, > > Jules > > > [J2EE Deployer Default] Deploy J2EE application: > file:/home/jules/cvs/JBoss/tomcat-test.ear > [J2EE Deployer Default] Create application tomcat-test.ear > [J2EE Deployer Default] inflate and install module tomcat-test.war > [J2EE Deployer Default] install module tomcat-test.jar > [J2EE Deployer Default] add all ejb jar files to the common classpath > [Container factory] > Deploying:file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Def ault/tomcat-test.ear > > [Verifier] Verifying > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear/ejb1002.jar > > [Container factory] Deploying Optimized > [Container Management Proxy] Initializing > [Container Management Proxy] Initialized > [Container Management Proxy] Starting > [Container Management Proxy] Started > [Container factory] Deploying NonOptimized > [Container Management Proxy] Initializing > [Container Management Proxy] Initialized > [Container Management Proxy] Starting > [Container Management Proxy] Started > [Default] Added ClassLoader: org.jboss.web.WebClassLoader@6b67e8 URL: > http://megalodon:8083/WebClassLoader@7038952/ > [Container factory] Deployed application: > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear > > [J2EE Deployer Default] Starting module tomcat-test.war > [Jetty] Registered > com.mortbay.Jetty:name=Jetty,Jetty=0,context=/jboss,WebApplicationContext=0 > > [Jetty] resolving -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN > : http://java.sun.com/j2ee/dtds/web-app_2_2.dtd > [Jetty] resolved -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN > : > jar:file:/home/jules/cvs/JBoss/contrib/jetty/dist/jetty/lib/com.mortbay.jett y.jar!/com/mortbay/Jetty/Servlet/web.dtd > > [Jetty] no jboss-web.xml found > [Jetty] Started SecurityHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] JSP: init > [Jetty] Started ServletHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] Started WebInfProtect > [Jetty] ResourceHandler started in > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear/web1001/ > > [Jetty] Started ResourceHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] Stopped SetupHandler in null > [Jetty] successfully deployed > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear/web1001/ > to /jboss > [J2EE Deployer Default] J2EE application: > file:/home/jules/cvs/JBoss/tomcat-test.ear is deployed. > [J2EE Deployer Default] Checking module tomcat-test.ear > [J2EE Deployer Default] Checking module tomcat-test.war > [J2EE Deployer Default] Stopping module tomcat-test.war > [Jetty] Stopped SecurityHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] Stopped ServletHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] Stopped WebInfProtect > [Jetty] Stopped ResourceHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] Deregister > com.mortbay.Jetty:name=Jetty,Jetty=0,context=/jboss,WebApplicationContext=0 > > [Jetty] successfully undeployed > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear/web1001/ > > [J2EE Deployer Default] Stopping module tomcat-test.ear > [Container factory] > Undeploying:file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/D efault/tomcat-test.ear > > [Container factory] Undeployed application: > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear > > [J2EE Deployer Default] Destroying application tomcat-test.ear > [J2EE Deployer Default] Deploy J2EE application: > file:/home/jules/cvs/JBoss/tomcat-test.ear > [J2EE Deployer Default] Create application tomcat-test.ear > [J2EE Deployer Default] inflate and install module tomcat-test.war > [J2EE Deployer Default] install module tomcat-test.jar > [J2EE Deployer Default] add
[JBoss-dev] Attn Juha: new JBoss-2.2.2_Jetty-3.1.RC5-2.tgz
Juha, I'm just uploading this into sf/incoming. It will be 10,235,051 bytes when finished. I would really appreciate it if you would do the necessary, or failing that tell me what to do. Thanks for all your help, Jules P.S. Here is the README : --- JBoss-2.2.2-Jetty-3.1.RC5 --- This is second shot at this release, hopefully fixing the following problems with the first release: - The dreaded "null null null" on making a request to a Servlet - Preliminary JAAS integration now included - Thanks Scott - The need to get the tools.jar into you CLASSPATH for JSPs - The lack of Jetty javadoc - A missing DTD resolution --- For some Jetty doc and Demos run up JBoss-Jetty and hit: http://my-jboss-host:8080 You can look around the MBeans running within Jetty by hitting : http://my-jboss-host:8082 and looking at the com.mortbay.Jetty links... --- This release comprises: JBoss-2.2.2 Jetty-3.1.RC5 (+ a few changes - actually CVS of 10/6/2001) Jetty3Extra-0.0.5 (ditto) contrib/jetty (cvs of 10/6/2001) Un*x users: run ./run.sh in this dir. MS Users: cd to ./jboss/bin and 'run.bat jetty' (please send me the equiv run.bat for this dir) N.B. Please post any problems to jboss-user with 'Jetty' in the subject line and I shall deal with them ASAP. Thanks for using JBoss-Jetty, Jules (JBoss-Jetty maintainer) - [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty SetupHandler.java
User: jules_gosnell
Date: 01/06/10 15:57:54
Modified:jetty/src/main/org/jboss/jetty SetupHandler.java
Log:
temporarily walk around the "null null null" problem
Revision ChangesPath
1.3 +2 -2 contrib/jetty/src/main/org/jboss/jetty/SetupHandler.java
Index: SetupHandler.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/SetupHandler.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SetupHandler.java 2001/06/10 21:38:28 1.2
+++ SetupHandler.java 2001/06/10 22:57:53 1.3
@@ -18,7 +18,7 @@
is sees the correct class loader and security realm name.
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class SetupHandler extends NullHandler
{
@@ -39,7 +39,7 @@
ClassLoader loader = getHandlerContext().getClassLoader();
Element webAppDD = webApp.getWebApp();
Element jbossDD = webApp.getJbossWeb();
-webApp.setClassLoader(loader);
+ //webApp.setClassLoader(loader);
descriptorParser.parseWebAppDescriptors(loader, webAppDD, jbossDD);
// Add the JBoss security realm
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Container Management MBean problem...
I think this is the same problem. I am seeing sporadic failures on redeploy with just the JBoss core without any servlet container. - Original Message - From: "Andreas Schaefer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 10, 2001 3:33 PM Subject: Re: [JBoss-dev] Container Management MBean problem... > Jules > > I made some changes to the ContainerFactory but I tested it to redeploy > but only with Tomcat. > > Can you catch the RuntimeMBeanException and print out the Target > Exception. I think Scott has or had a similar problem. > > Andy > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Container Management MBean problem...
Jules I made some changes to the ContainerFactory but I tested it to redeploy but only with Tomcat. Can you catch the RuntimeMBeanException and print out the Target Exception. I think Scott has or had a similar problem. Andy - Original Message - From: "Julian Gosnell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 10, 2001 4:12 PM Subject: [JBoss-dev] Container Management MBean problem... > CVS of ~22:30GMT 10/6/2001 > > Trying to redeploy the same EAR, results in a pair of nasty exceptions: > > Just in case whoever is hacking on this is not aware of this one. > > Thanks, > > Jules > > > [J2EE Deployer Default] Deploy J2EE application: > file:/home/jules/cvs/JBoss/tomcat-test.ear > [J2EE Deployer Default] Create application tomcat-test.ear > [J2EE Deployer Default] inflate and install module tomcat-test.war > [J2EE Deployer Default] install module tomcat-test.jar > [J2EE Deployer Default] add all ejb jar files to the common classpath > [Container factory] > Deploying:file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Def ault/tomcat-test.ear > > [Verifier] Verifying > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear/ejb1002.jar > > [Container factory] Deploying Optimized > [Container Management Proxy] Initializing > [Container Management Proxy] Initialized > [Container Management Proxy] Starting > [Container Management Proxy] Started > [Container factory] Deploying NonOptimized > [Container Management Proxy] Initializing > [Container Management Proxy] Initialized > [Container Management Proxy] Starting > [Container Management Proxy] Started > [Default] Added ClassLoader: org.jboss.web.WebClassLoader@6b67e8 URL: > http://megalodon:8083/WebClassLoader@7038952/ > [Container factory] Deployed application: > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear > > [J2EE Deployer Default] Starting module tomcat-test.war > [Jetty] Registered > com.mortbay.Jetty:name=Jetty,Jetty=0,context=/jboss,WebApplicationContext=0 > > [Jetty] resolving -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN > : http://java.sun.com/j2ee/dtds/web-app_2_2.dtd > [Jetty] resolved -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN > : > jar:file:/home/jules/cvs/JBoss/contrib/jetty/dist/jetty/lib/com.mortbay.jett y.jar!/com/mortbay/Jetty/Servlet/web.dtd > > [Jetty] no jboss-web.xml found > [Jetty] Started SecurityHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] JSP: init > [Jetty] Started ServletHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] Started WebInfProtect > [Jetty] ResourceHandler started in > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear/web1001/ > > [Jetty] Started ResourceHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] Stopped SetupHandler in null > [Jetty] successfully deployed > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear/web1001/ > to /jboss > [J2EE Deployer Default] J2EE application: > file:/home/jules/cvs/JBoss/tomcat-test.ear is deployed. > [J2EE Deployer Default] Checking module tomcat-test.ear > [J2EE Deployer Default] Checking module tomcat-test.war > [J2EE Deployer Default] Stopping module tomcat-test.war > [Jetty] Stopped SecurityHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] Stopped ServletHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] Stopped WebInfProtect > [Jetty] Stopped ResourceHandler in > WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/j boss/tmp/deploy/Default/tomcat-test.ear/web1001/] > > [Jetty] Deregister > com.mortbay.Jetty:name=Jetty,Jetty=0,context=/jboss,WebApplicationContext=0 > > [Jetty] successfully undeployed > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear/web1001/ > > [J2EE Deployer Default] Stopping module tomcat-test.ear > [Container factory] > Undeploying:file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/D efault/tomcat-test.ear > > [Container factory] Undeployed application: > file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomca t-test.ear > > [J2EE Deployer Default] Destroying application tomcat-test.ear > [J2EE Deployer Default] Deploy J2EE application: > file:/home/jules/cvs/JBoss/tomcat-test.ear > [J2EE Deployer Default] Create application tomcat-test.ear > [J2EE Deployer Default] inflate and install module tomcat-test.war > [J2EE Deployer Default] install module t
[JBoss-dev] Container Management MBean problem...
CVS of ~22:30GMT 10/6/2001 Trying to redeploy the same EAR, results in a pair of nasty exceptions: Just in case whoever is hacking on this is not aware of this one. Thanks, Jules [J2EE Deployer Default] Deploy J2EE application: file:/home/jules/cvs/JBoss/tomcat-test.ear [J2EE Deployer Default] Create application tomcat-test.ear [J2EE Deployer Default] inflate and install module tomcat-test.war [J2EE Deployer Default] install module tomcat-test.jar [J2EE Deployer Default] add all ejb jar files to the common classpath [Container factory] Deploying:file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear [Verifier] Verifying file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/ejb1002.jar [Container factory] Deploying Optimized [Container Management Proxy] Initializing [Container Management Proxy] Initialized [Container Management Proxy] Starting [Container Management Proxy] Started [Container factory] Deploying NonOptimized [Container Management Proxy] Initializing [Container Management Proxy] Initialized [Container Management Proxy] Starting [Container Management Proxy] Started [Default] Added ClassLoader: org.jboss.web.WebClassLoader@6b67e8 URL: http://megalodon:8083/WebClassLoader@7038952/ [Container factory] Deployed application: file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear [J2EE Deployer Default] Starting module tomcat-test.war [Jetty] Registered com.mortbay.Jetty:name=Jetty,Jetty=0,context=/jboss,WebApplicationContext=0 [Jetty] resolving -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN : http://java.sun.com/j2ee/dtds/web-app_2_2.dtd [Jetty] resolved -//Sun Microsystems, Inc.//DTD Web Application 2.2//EN : jar:file:/home/jules/cvs/JBoss/contrib/jetty/dist/jetty/lib/com.mortbay.jetty.jar!/com/mortbay/Jetty/Servlet/web.dtd [Jetty] no jboss-web.xml found [Jetty] Started SecurityHandler in WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/web1001/] [Jetty] JSP: init [Jetty] Started ServletHandler in WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/web1001/] [Jetty] Started WebInfProtect [Jetty] ResourceHandler started in file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/web1001/ [Jetty] Started ResourceHandler in WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/web1001/] [Jetty] Stopped SetupHandler in null [Jetty] successfully deployed file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/web1001/ to /jboss [J2EE Deployer Default] J2EE application: file:/home/jules/cvs/JBoss/tomcat-test.ear is deployed. [J2EE Deployer Default] Checking module tomcat-test.ear [J2EE Deployer Default] Checking module tomcat-test.war [J2EE Deployer Default] Stopping module tomcat-test.war [Jetty] Stopped SecurityHandler in WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/web1001/] [Jetty] Stopped ServletHandler in WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/web1001/] [Jetty] Stopped WebInfProtect [Jetty] Stopped ResourceHandler in WebApplicationContext[/jboss,file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/web1001/] [Jetty] Deregister com.mortbay.Jetty:name=Jetty,Jetty=0,context=/jboss,WebApplicationContext=0 [Jetty] successfully undeployed file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/web1001/ [J2EE Deployer Default] Stopping module tomcat-test.ear [Container factory] Undeploying:file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear [Container factory] Undeployed application: file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear [J2EE Deployer Default] Destroying application tomcat-test.ear [J2EE Deployer Default] Deploy J2EE application: file:/home/jules/cvs/JBoss/tomcat-test.ear [J2EE Deployer Default] Create application tomcat-test.ear [J2EE Deployer Default] inflate and install module tomcat-test.war [J2EE Deployer Default] install module tomcat-test.jar [J2EE Deployer Default] add all ejb jar files to the common classpath [Container factory] Deploying:file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear [Verifier] Verifying file:/home/jules/cvs/JBoss/contrib/jetty/dist/jboss/tmp/deploy/Default/tomcat-test.ear/ejb1004.jar [Container factory] Deploying Optimized [Default] javax.management.RuntimeMBeanException: RuntimeException thrown in postRegister method [Default] at com.sun.management.jmx.MBeanServerImpl.postRegisterInvoker(MBeanServerImpl.java:2277) [Default] [Default] at com.sun.management.jmx.MBeanSer
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb LocalContainerInvoker.java
Hi Marc,
The LocalContainerInvoker class is parallel to the ContainerInvoker
class. The ContainerInvoker interface must be implemented by
Container plugins so that remote home and component interfaces
can be retrieved. The LocalContainerInvoker interface must be
implemented by containers so that local home and component
interfaces can be retrieved.
There was no existing functionality that allowed these interfaces to
be retrieved. (These interface types didn't even exist before EJB 2.0
PFD2.)
-Dan
On 10 Jun 01, at 16:42, marc fleury wrote:
> Isn't there already a "local container invoker"? the one we set on the proxy
> ?
>
> marc
>
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of
> |[EMAIL PROTECTED]
> |Sent: Sunday, June 03, 2001 12:25 PM
> |To: [EMAIL PROTECTED]
> |Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb
> |LocalContainerInvoker.java
> |
> |
> | User: docodan
> | Date: 01/06/03 09:24:53
> |
> | Modified:src/main/org/jboss/ejb LocalContainerInvoker.java
> | Log:
> | Local and remote interfaces should be separate, because local
> |interfaces do not benefit from pluggable distribution mechanisms &
> |add unnecessary complexity.
> |
> | Revision ChangesPath
> | 1.2 +1 -1
> |jboss/src/main/org/jboss/ejb/LocalContainerInvoker.java
> |
> | Index: LocalContainerInvoker.java
> | ===
> | RCS file:
> |/cvsroot/jboss/jboss/src/main/org/jboss/ejb/LocalContainerInvoker.java,v
> | retrieving revision 1.1
> | retrieving revision 1.2
> | diff -u -r1.1 -r1.2
> | --- LocalContainerInvoker.java 2001/06/02 19:40:38 1.1
> | +++ LocalContainerInvoker.java 2001/06/03 16:24:53 1.2
> | @@ -22,7 +22,7 @@
> |*@author Daniel OConnor ([EMAIL PROTECTED])
> |*/
> | public interface LocalContainerInvoker
> | - extends ContainerInvoker
> | + extends ContainerPlugin
> | {
> | // Public
> |
> |
> |
> |
> |
> |___
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty SetupHandler.java
User: jules_gosnell
Date: 01/06/10 14:38:28
Modified:jetty/src/main/org/jboss/jetty SetupHandler.java
Log:
hook in Scott's new JAAS stuff
Revision ChangesPath
1.2 +3 -3 contrib/jetty/src/main/org/jboss/jetty/SetupHandler.java
Index: SetupHandler.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/SetupHandler.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SetupHandler.java 2001/06/04 23:28:32 1.1
+++ SetupHandler.java 2001/06/10 21:38:28 1.2
@@ -18,7 +18,7 @@
is sees the correct class loader and security realm name.
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class SetupHandler extends NullHandler
{
@@ -44,8 +44,8 @@
// Add the JBoss security realm
HttpServer server = getHandlerContext().getHttpServer();
- //String realmName = getHandlerContext().getRealm();
- //server.addRealm(new JBossUserRealm(realmName));
+ String realmName = getHandlerContext().getRealm();
+ server.addRealm(new JBossUserRealm(realmName));
}
public void handle(String pathInContext, HttpRequest request, HttpResponse
response)
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty Jetty.java
User: jules_gosnell
Date: 01/06/10 14:36:10
Modified:jetty/src/main/org/jboss/jetty Jetty.java
Log:
hardwire (yeugh!!) another DTD resolution that seems to be needed
Revision ChangesPath
1.8 +1 -0 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.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Jetty.java2001/06/04 23:33:11 1.7
+++ Jetty.java2001/06/10 21:36:10 1.8
@@ -87,6 +87,7 @@
URL jbossWeb=findResourceInJar("org.jboss.jetty.JettyService","jboss-web.dtd");
_resolver.put("-//jBoss//DTD Web Application 2.2//EN", jbossWeb);
+_resolver.put("-//JBoss//DTD Web Application 2.2//EN", jbossWeb);
}
//
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JBossUserRealm.java
User: jules_gosnell
Date: 01/06/10 14:37:45
Added: jetty/src/main/org/jboss/jetty JBossUserRealm.java
Log:
Scott's new JAAS integration - first cut - thanks Scott!
Revision ChangesPath
1.1 contrib/jetty/src/main/org/jboss/jetty/JBossUserRealm.java
Index: JBossUserRealm.java
===
package org.jboss.jetty;
import java.util.HashSet;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import com.mortbay.HTTP.HttpRequest;
import com.mortbay.HTTP.UserPrincipal;
import com.mortbay.HTTP.UserRealm;
import org.jboss.security.EJBSecurityManager;
import org.jboss.security.RealmMapping;
import org.jboss.security.SimplePrincipal;
import org.jboss.security.SecurityAssociation;
import org.jboss.security.SubjectSecurityManager;
/** An implementation of UserRealm that integrates with the JBossSX security
manager associted with the web application.
* @author [EMAIL PROTECTED]
* @version $Revision: 1.1 $
*/
public class JBossUserRealm implements UserRealm
{
private String realmName;
class User extends SimplePrincipal implements UserPrincipal
{
HttpRequest request;
User(String name, HttpRequest request)
{
super(name);
this.request = request;
}
public boolean authenticate(String password)
{
boolean authenticated = false;
String username = this.getName();
System.out.println("Authenticating access, username: " + username + " "
+request);
try
{
// Get the JBoss security manager from the ENC context
InitialContext iniCtx = new InitialContext();
EJBSecurityManager securityMgr = (EJBSecurityManager)
iniCtx.lookup("java:comp/env/security/securityMgr");
if( securityMgr.isValid(this, password) )
{
authenticated = true;
request.setAttribute(UserPrincipal.__ATTR, this);
System.out.println("User: "+username+" is authenticated");
SecurityAssociation.setPrincipal(this);
SecurityAssociation.setCredential(password.toCharArray());
/*
if( useJAAS == true && securityMgr instanceof
SubjectSecurityManager )
{
SubjectSecurityManager subjectMgr = (SubjectSecurityManager)
securityMgr;
Subject subject = subjectMgr.getActiveSubject();
request.setAttribute(subjectAttributeName, subject);
}
*/
}
else
{
System.out.println("User: "+username+" is NOT authenticated");
}
}
catch(NamingException e)
{
System.err.println("Error during authenticate");
e.printStackTrace();
}
return authenticated;
}
public boolean isUserInRole(String role)
{
boolean isUserInRole = false;
String username = this.getName();
System.out.println("Authorizing access, username: " + username + " "
+request);
try
{
// Get the JBoss security manager from the ENC context
InitialContext iniCtx = new InitialContext();
RealmMapping securityMgr = (RealmMapping)
iniCtx.lookup("java:comp/env/security/realmMapping");
HashSet requiredRoles = new HashSet();
requiredRoles.add(role);
if( securityMgr.doesUserHaveRole(this, requiredRoles) )
{
isUserInRole = true;
System.out.println("User: "+username+" is authorized");
}
else
{
System.out.println("User: "+username+" is NOT authorized,
requiredRoles="+requiredRoles);
}
}
catch(NamingException e)
{
System.err.println("Error during authorization");
e.printStackTrace();
}
return isUserInRole;
}
public UserRealm getUserRealm()
{
return JBossUserRealm.this;
}
}
/** Creates new JBossUserRealm */
public JBossUserRealm(String realmName)
{
this.realmName = realmName;
System.out.println("+++ Created JBossUserRealm, realmName="+realmName);
}
public String getName()
{
return realmName;
}
public UserPrincipal g
[JBoss-dev] CVS update: contrib/jetty/src/build build.sh
User: jules_gosnell Date: 01/06/10 14:34:22 Modified:jetty/src/build build.sh Log: add necessary jars to CLASSPATH for Scott's new JAAS stuff to compile Revision ChangesPath 1.4 +3 -1 contrib/jetty/src/build/build.sh Index: build.sh === RCS file: /cvsroot/jboss/contrib/jetty/src/build/build.sh,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- build.sh 2001/06/04 23:26:02 1.3 +++ build.sh 2001/06/10 21:34:22 1.4 @@ -1,5 +1,5 @@ #! /bin/sh -# $Id: build.sh,v 1.3 2001/06/04 23:26:02 jules_gosnell Exp $ +# $Id: build.sh,v 1.4 2001/06/10 21:34:22 jules_gosnell Exp $ if [ ! -f "$JBOSS_HOME/bin/run.jar" ] then @@ -28,6 +28,8 @@ CLASSPATH=$CLASSPATH:../../../tomcat/lib/javac.jar CLASSPATH=$CLASSPATH:$JBOSS_HOME/lib/crimson.jar CLASSPATH=$CLASSPATH:$JBOSS_HOME/lib/jaxp.jar +CLASSPATH=$CLASSPATH:$JBOSS_HOME/lib/jboss-jaas.jar +CLASSPATH=$CLASSPATH:$JBOSS_HOME/lib/ext/jbosssx.jar CLASSPATH=$CLASSPATH:$JETTY_EXTRA/jmx/lib/com.mortbay.jetty.jmx.jar exec java\ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/build build.xml
User: jules_gosnell Date: 01/06/10 14:32:57 Modified:jetty/src/build build.xml Log: copy javac.jar into jboss/lib/ext so it is available for compilation of JSPs Revision ChangesPath 1.6 +5 -2 contrib/jetty/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jetty/src/build/build.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.xml 2001/05/21 22:03:44 1.5 +++ build.xml 2001/06/10 21:32:57 1.6 @@ -1,5 +1,5 @@ - + @@ -69,11 +69,14 @@ - + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.mgt.ContainerMgt RuntimeException
Its an NPE in ServiceMBeanSupport.destroy which appears to be happening because
the bean is attempting to invoke destroy() before init() has been called and the
log instance variable initialized.
[Default] java.lang.NullPointerException
[Default] at org.jboss.util.ServiceMBeanSupport.destroy(ServiceMBeanSupport.java:151)
[Default] at
org.jboss.util.ServiceMBeanSupport.postRegister(ServiceMBeanSupport.java:176)
[Default] at
com.sun.management.jmx.MBeanServerImpl.postRegisterInvoker(MBeanServerImpl.java:2274)
[Default] at
com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2356)
[Default] at
com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:388)
[Default] at
org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java:691)
[Default] at
org.jboss.ejb.ContainerFactory.createStatelessSessionContainer(ContainerFactory.java:614)
[Default] at org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:565)
[Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:446)
[Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:341)
[Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:280)
[Default] at java.lang.reflect.Method.invoke(Native Method)
[Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
[Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
[Default] at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489)
[Default] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:467)
[Default] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211)
[Default] at java.lang.reflect.Method.invoke(Native Method)
[Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
[Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
[Default] at org.jboss.jmx.server.JMXAdaptorImpl.invoke(JMXAdaptorImpl.java:69)
[Default] at java.lang.reflect.Method.invoke(Native Method)
[Default] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
[Default] at sun.rmi.transport.Transport$1.run(Transport.java:142)
[Default] at java.security.AccessController.doPrivileged(Native Method)
[Default] at sun.rmi.transport.Transport.serviceCall(Transport.java:139)
[Default] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:443)
[Default] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:643)
[Default] at java.lang.Thread.run(Thread.java:484)
[Default]
- Original Message -
From: "Andreas Schaefer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, June 10, 2001 1:54 PM
Subject: Re: [JBoss-dev] org.jboss.mgt.ContainerMgt RuntimeException
> Hi Scott
>
> To get more info about the Exception catch the RuntimeMBeanException
> and get is Target Exception which is the RuntimeException. This gives maybe
> some inside to the exception.
>
> Andy
>
> - Original Message -
> From: "Scott M Stark" <[EMAIL PROTECTED]>
> To: "JBoss Dev" <[EMAIL PROTECTED]>
> Sent: Sunday, June 10, 2001 12:02 PM
> Subject: [JBoss-dev] org.jboss.mgt.ContainerMgt RuntimeException
>
>
> > Periodically on redeploy of an ejb jar via the JMX connector I am seeing
> the
> > following exception related to creation of the org.jboss.mgt.ContainerMgt
> bean
> > in the ContainerFactory.registerContainer method. This is an exception I
> have
> > not seen before.
> >
> > private void registerContainer( Container container ) {
> > ...
> > getServer().createMBean( "org.jboss.mgt.ContainerMgt", name );
> <- Line 690 of ContainerFactory.java
> >
> > --- server.log:
> >
> > [Container factory] Deploying ENCBean
> > [Container factory] Container Invoker RMI Port=''
> > [Container factory] Container Invoker Client SocketFactory='Default'
> > [Container factory] Container Invoker Server SocketFactory='Default'
> > [Container factory] Container Invoker Optimize='true'
> > [Default] javax.management.RuntimeMBeanException: RuntimeException thrown
> in postRegister method
> > [Default] at
> com.sun.management.jmx.MBeanServerImpl.postRegisterInvoker(MBeanServerImpl.j
> ava:2277)
> > [Default]
> > [Default] at
> com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.ja
> va:2356)
> > [Default]
> > [Default] at
> com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:388)
> > [Default]
> > [Default] at
> org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java:690)
> > [Default]
> > [Default] at
> org.jboss.ejb.ContainerFactory.createStatelessSessionContainer(ContainerFact
> ory.java:613)
> > [Default]
> > [Default] at
> org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:564)
> > [Default]
> > [Default] at
> org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:445)
> > [Default]
> > [Default] at
> or
[JBoss-dev] Thinking about a change to the ENC factory
Each JNDI enterprise naming context(ENC) has to be unique for a J2EE component(ejb, war). We establish the uniqueness of the ENC context by creating a new ClassLoader for each component. This works fine for EJBs, but a few issues have show up for web components for a number of reasons. Example issues are some hacking of the Tomcat and Jetty web container mbeans to get hold of the right ClassLoader and Cocoon creating its own ClassLoader that breaks access to the java:comp/env setup by the Tomcat mbean. To make access to the ENC more usable I would like to change the org.jboss.naming.ENCFactory to walk up the ClassLoader delegation chain to try to find a parent ClassLoader which has a valid ENC binding so that descendent ClassLoaders of the parent in which the ENC was created work transparently. Anyone have any objections/concerns? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.mgt.ContainerMgt RuntimeException
Hi Scott
To get more info about the Exception catch the RuntimeMBeanException
and get is Target Exception which is the RuntimeException. This gives maybe
some inside to the exception.
Andy
- Original Message -
From: "Scott M Stark" <[EMAIL PROTECTED]>
To: "JBoss Dev" <[EMAIL PROTECTED]>
Sent: Sunday, June 10, 2001 12:02 PM
Subject: [JBoss-dev] org.jboss.mgt.ContainerMgt RuntimeException
> Periodically on redeploy of an ejb jar via the JMX connector I am seeing
the
> following exception related to creation of the org.jboss.mgt.ContainerMgt
bean
> in the ContainerFactory.registerContainer method. This is an exception I
have
> not seen before.
>
> private void registerContainer( Container container ) {
> ...
> getServer().createMBean( "org.jboss.mgt.ContainerMgt", name );
<- Line 690 of ContainerFactory.java
>
> --- server.log:
>
> [Container factory] Deploying ENCBean
> [Container factory] Container Invoker RMI Port=''
> [Container factory] Container Invoker Client SocketFactory='Default'
> [Container factory] Container Invoker Server SocketFactory='Default'
> [Container factory] Container Invoker Optimize='true'
> [Default] javax.management.RuntimeMBeanException: RuntimeException thrown
in postRegister method
> [Default] at
com.sun.management.jmx.MBeanServerImpl.postRegisterInvoker(MBeanServerImpl.j
ava:2277)
> [Default]
> [Default] at
com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.ja
va:2356)
> [Default]
> [Default] at
com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:388)
> [Default]
> [Default] at
org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java:690)
> [Default]
> [Default] at
org.jboss.ejb.ContainerFactory.createStatelessSessionContainer(ContainerFact
ory.java:613)
> [Default]
> [Default] at
org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:564)
> [Default]
> [Default] at
org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:445)
> [Default]
> [Default] at
org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:340)
> [Default]
> [Default] at
org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:279)
> [Default]
> [Default] at java.lang.reflect.Method.invoke(Native Method)
> [Default]
> [Default] at
com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
> [Default]
> [Default] at
com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
> [Default]
> [Default] at
org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489)
> [Default]
> [Default] at
org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:467)
> [Default]
> [Default] at
org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211)
> [Default]
> [Default] at java.lang.reflect.Method.invoke(Native Method)
> [Default]
> [Default] at
com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
> [Default]
> [Default] at
com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
> [Default]
> [Default] at
org.jboss.jmx.server.JMXAdaptorImpl.invoke(JMXAdaptorImpl.java:69)
> [Default]
> [Default] at java.lang.reflect.Method.invoke(Native Method)
> [Default]
> [Default] at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
> [Default]
> [Default] at sun.rmi.transport.Transport$1.run(Transport.java:142)
> [Default]
> [Default] at java.security.AccessController.doPrivileged(Native Method)
> [Default]
> [Default] at sun.rmi.transport.Transport.serviceCall(Transport.java:139)
> [Default]
> [Default] at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:443)
> [Default]
> [Default] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:6
43)
> [Default]
> [Default] at java.lang.Thread.run(Thread.java:484)
> [Default]
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jboss.dtd
User: starksm Date: 01/06/10 13:54:48 Modified:src/resources/org/jboss/metadata jboss.dtd Log: Use the same resource-env-ref-name in the resource-env-ref element as is used in the ejb-jar descriptor Revision ChangesPath 1.10 +9 -2 jboss/src/resources/org/jboss/metadata/jboss.dtd Index: jboss.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jboss.dtd,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- jboss.dtd 2001/06/10 06:00:39 1.9 +++ jboss.dtd 2001/06/10 20:54:48 1.10 @@ -221,9 +221,16 @@ Used in: session, entity, message-driven --> - + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata BeanMetaData.java
User: starksm
Date: 01/06/10 13:51:23
Modified:src/main/org/jboss/metadata BeanMetaData.java
Log:
Implement support for EJB 2.0 resource-env-ref element
Revision ChangesPath
1.21 +4 -3 jboss/src/main/org/jboss/metadata/BeanMetaData.java
Index: BeanMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/BeanMetaData.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- BeanMetaData.java 2001/06/10 07:46:16 1.20
+++ BeanMetaData.java 2001/06/10 20:51:23 1.21
@@ -25,7 +25,7 @@
* @author Peter Antman ([EMAIL PROTECTED])
* @author Daniel OConnor ([EMAIL PROTECTED])
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.20 $
+ * @version $Revision: 1.21 $
*/
public abstract class BeanMetaData extends MetaData {
// Constants -
@@ -136,7 +136,8 @@
public Iterator getSecurityRoleReferences() { return
securityRoleReferences.iterator(); }
public Iterator getResourceReferences() { return
resourceReferences.values().iterator(); }
-
+ public Iterator getResourceEnvReferences() { return
resourceEnvReferences.values().iterator(); }
+
public String getJndiName() {
// jndiName may be set in jboss.xml
if (jndiName == null) {
@@ -354,7 +355,7 @@
while( iterator.hasNext() )
{
Element resourceRef = (Element) iterator.next();
- String resRefName =
getElementContent(getUniqueChild(resourceRef, "res-ref-name"));
+ String resRefName =
getElementContent(getUniqueChild(resourceRef, "resource-env-ref-name"));
ResourceEnvRefMetaData refMetaData = (ResourceEnvRefMetaData)
resourceEnvReferences.get(resRefName);
if( refMetaData == null)
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Container.java ContainerFactory.java EnterpriseContext.java
User: starksm
Date: 01/06/10 13:50:31
Modified:src/main/org/jboss/ejb Container.java ContainerFactory.java
EnterpriseContext.java
Log:
Implement support for EJB 2.0 resource-env-ref element
Revision ChangesPath
1.43 +51 -50jboss/src/main/org/jboss/ejb/Container.java
Index: Container.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -r1.42 -r1.43
--- Container.java2001/06/03 20:59:40 1.42
+++ Container.java2001/06/10 20:50:31 1.43
@@ -49,6 +49,7 @@
import org.jboss.metadata.EjbRefMetaData;
import org.jboss.metadata.EjbLocalRefMetaData;
import org.jboss.metadata.ResourceRefMetaData;
+import org.jboss.metadata.ResourceEnvRefMetaData;
import org.jboss.metadata.ApplicationMetaData;
import org.jnp.interfaces.Naming;
@@ -71,7 +72,8 @@
* @see ContainerFactory
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author Marc Fleury
- * @version $Revision: 1.42 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.43 $
*/
public abstract class Container
{
@@ -326,7 +328,7 @@
localContainerInvoker.init();
if (localHomeInterface != null)
application.addLocalHome(this, localContainerInvoker.getEJBLocalHome() );
- // Setup "java:" namespace
+ // Setup "java:comp/env" namespace
setupEnvironment();
}
@@ -401,7 +403,7 @@
* setupEnvironment
*
* This method sets up the naming environment of the bean.
- * We create the java: namespace with properties, EJB-References, and
+ * We create the java:comp/env namespace with properties, EJB-References, and
* DataSource ressources.
*
*/
@@ -410,56 +412,36 @@
{
try
{
+ BeanMetaData beanMetaData = getBeanMetaData();
+ Logger.debug("Begin java:comp/env for EJB: "+beanMetaData.getEjbName());
+ Logger.debug("TCL: "+Thread.currentThread().getContextClassLoader());
// Since the BCL is already associated with this thread we can start using
the java: namespace directly
Context ctx = (Context) new InitialContext().lookup("java:comp");
- ctx = ctx.createSubcontext("env");
+ Context envCtx = ctx.createSubcontext("env");
+ Logger.debug("java:comp/env: "+envCtx);
// Bind environment properties
{
-Iterator enum = getBeanMetaData().getEnvironmentEntries();
+Iterator enum = beanMetaData.getEnvironmentEntries();
while(enum.hasNext())
{
EnvEntryMetaData entry = (EnvEntryMetaData)enum.next();
- if (entry.getType().equals("java.lang.Integer"))
+ try
{
- bind(ctx, entry.getName(), new Integer(entry.getValue()));
+ Logger.debug("Binding env-entry: "+entry.getName()+" of type:
"+entry.getType()+" to value:"+entry.getValue());
+ EnvEntryMetaData.bindEnvEntry(envCtx, entry);
}
- else if (entry.getType().equals("java.lang.Long"))
+ catch(ClassNotFoundException e)
{
- bind(ctx, entry.getName(), new Long(entry.getValue()));
+ Logger.exception(e);
+ throw new DeploymentException("Could not set up environment", e);
}
- else if (entry.getType().equals("java.lang.Double"))
- {
- bind(ctx, entry.getName(), new Double(entry.getValue()));
- }
- else if (entry.getType().equals("java.lang.Float"))
- {
- bind(ctx, entry.getName(), new Float(entry.getValue()));
- }
- else if (entry.getType().equals("java.lang.Byte"))
- {
- bind(ctx, entry.getName(), new Byte(entry.getValue()));
- }
- else if (entry.getType().equals("java.lang.Short"))
- {
- bind(ctx, entry.getName(), new Short(entry.getValue()));
- }
- else if (entry.getType().equals("java.lang.Boolean"))
- {
- bind(ctx, entry.getName(), new Boolean(entry.getValue()));
- }
- else
- {
- // Unknown type
- // Default is string
- bind(ctx, entry.getName(), entry.getValue());
- }
}
}
// Bind EJB references
{
-Iterator enum = getBeanMetaData().getEjbReferences();
+Iterator enum = beanMetaData.getEjbR
[JBoss-dev] CVS update: jbosstest/src/resources/naming/META-INF ejb-jar.xml jboss.xml
User: starksm Date: 01/06/10 13:49:28 Modified:src/resources/naming/META-INF ejb-jar.xml jboss.xml Log: Add test of EJB 2.0 resource-env-ref element Revision ChangesPath 1.5 +6 -0 jbosstest/src/resources/naming/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/META-INF/ejb-jar.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- ejb-jar.xml 2001/06/10 18:29:06 1.4 +++ ejb-jar.xml 2001/06/10 20:49:28 1.5 @@ -114,6 +114,12 @@ java.net.URL Container + + +A test of the resource-env-ref tag +res/aQueue +javax.jms.Queue + 1.4 +6 -0 jbosstest/src/resources/naming/META-INF/jboss.xml Index: jboss.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/META-INF/jboss.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jboss.xml 2001/05/11 05:11:28 1.3 +++ jboss.xml 2001/06/10 20:49:28 1.4 @@ -36,6 +36,12 @@ url/SourceforgeHomePage SourceforgeHomePage + + +res/aQueue +queue/testQueue + + ENCBean1 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/naming/ejb TestENCBean.java
User: starksm
Date: 01/06/10 13:49:28
Modified:src/main/org/jboss/test/naming/ejb TestENCBean.java
Log:
Add test of EJB 2.0 resource-env-ref element
Revision ChangesPath
1.5 +13 -2 jbosstest/src/main/org/jboss/test/naming/ejb/TestENCBean.java
Index: TestENCBean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/naming/ejb/TestENCBean.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TestENCBean.java 2001/06/10 18:28:30 1.4
+++ TestENCBean.java 2001/06/10 20:49:28 1.5
@@ -12,7 +12,7 @@
to test ENC usage.
@author [EMAIL PROTECTED]
-@version $Revision: 1.4 $
+@version $Revision: 1.5 $
*/
public class TestENCBean implements SessionBean
{
@@ -44,7 +44,9 @@
Context initCtx = new InitialContext();
Context myEnv = (Context) initCtx.lookup("java:comp/env");
Boolean hasFullENC = (Boolean) myEnv.lookup("hasFullENC");
-if( hasFullENC == Boolean.TRUE )
+System.out.println("ThreadContext CL =
"+Thread.currentThread().getContextClassLoader());
+System.out.println("hasFullENC = "+hasFullENC);
+if( hasFullENC.equals(Boolean.TRUE) )
{
// This bean should have the full ENC setup of the ENCBean
testEnvEntries(initCtx, myEnv);
@@ -53,6 +55,7 @@
testMail(initCtx, myEnv);
testJMS(initCtx, myEnv);
testURL(initCtx, myEnv);
+testResourceEnvEntries(initCtx, myEnv);
}
else
{
@@ -138,6 +141,14 @@
System.out.println("url/SourceforgeHomePage = "+obj);
obj = myEnv.lookup("url/SourceforgeHomePage");
System.out.println("url/SourceforgeHomePage = "+obj);
+}
+
+private void testResourceEnvEntries(Context initCtx, Context myEnv) throws
NamingException
+{
+Object obj = myEnv.lookup("res/aQueue");
+if( (obj instanceof javax.jms.Queue) == false )
+throw new NamingException("res/aQueue is not a javax.jms.Queue");
+System.out.println("res/aQueue = "+obj);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb LocalContainerInvoker.java
Isn't there already a "local container invoker"? the one we set on the proxy
?
marc
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|[EMAIL PROTECTED]
|Sent: Sunday, June 03, 2001 12:25 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb
|LocalContainerInvoker.java
|
|
| User: docodan
| Date: 01/06/03 09:24:53
|
| Modified:src/main/org/jboss/ejb LocalContainerInvoker.java
| Log:
| Local and remote interfaces should be separate, because local
|interfaces do not benefit from pluggable distribution mechanisms &
|add unnecessary complexity.
|
| Revision ChangesPath
| 1.2 +1 -1
|jboss/src/main/org/jboss/ejb/LocalContainerInvoker.java
|
| Index: LocalContainerInvoker.java
| ===
| RCS file:
|/cvsroot/jboss/jboss/src/main/org/jboss/ejb/LocalContainerInvoker.java,v
| retrieving revision 1.1
| retrieving revision 1.2
| diff -u -r1.1 -r1.2
| --- LocalContainerInvoker.java 2001/06/02 19:40:38 1.1
| +++ LocalContainerInvoker.java 2001/06/03 16:24:53 1.2
| @@ -22,7 +22,7 @@
|* @author Daniel OConnor ([EMAIL PROTECTED])
|*/
| public interface LocalContainerInvoker
| - extends ContainerInvoker
| + extends ContainerPlugin
| {
| // Public
|
|
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] org.jboss.mgt.ContainerMgt RuntimeException
Periodically on redeploy of an ejb jar via the JMX connector I am seeing the
following exception related to creation of the org.jboss.mgt.ContainerMgt bean
in the ContainerFactory.registerContainer method. This is an exception I have
not seen before.
private void registerContainer( Container container ) {
...
getServer().createMBean( "org.jboss.mgt.ContainerMgt", name ); <- Line 690
of ContainerFactory.java
--- server.log:
[Container factory] Deploying ENCBean
[Container factory] Container Invoker RMI Port=''
[Container factory] Container Invoker Client SocketFactory='Default'
[Container factory] Container Invoker Server SocketFactory='Default'
[Container factory] Container Invoker Optimize='true'
[Default] javax.management.RuntimeMBeanException: RuntimeException thrown in
postRegister method
[Default] at
com.sun.management.jmx.MBeanServerImpl.postRegisterInvoker(MBeanServerImpl.java:2277)
[Default]
[Default] at
com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2356)
[Default]
[Default] at
com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:388)
[Default]
[Default] at
org.jboss.ejb.ContainerFactory.registerContainer(ContainerFactory.java:690)
[Default]
[Default] at
org.jboss.ejb.ContainerFactory.createStatelessSessionContainer(ContainerFactory.java:613)
[Default]
[Default] at org.jboss.ejb.ContainerFactory.createContainer(ContainerFactory.java:564)
[Default]
[Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:445)
[Default]
[Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:340)
[Default]
[Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:279)
[Default]
[Default] at java.lang.reflect.Method.invoke(Native Method)
[Default]
[Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
[Default]
[Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
[Default]
[Default] at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:489)
[Default]
[Default] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:467)
[Default]
[Default] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:211)
[Default]
[Default] at java.lang.reflect.Method.invoke(Native Method)
[Default]
[Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628)
[Default]
[Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523)
[Default]
[Default] at org.jboss.jmx.server.JMXAdaptorImpl.invoke(JMXAdaptorImpl.java:69)
[Default]
[Default] at java.lang.reflect.Method.invoke(Native Method)
[Default]
[Default] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
[Default]
[Default] at sun.rmi.transport.Transport$1.run(Transport.java:142)
[Default]
[Default] at java.security.AccessController.doPrivileged(Native Method)
[Default]
[Default] at sun.rmi.transport.Transport.serviceCall(Transport.java:139)
[Default]
[Default] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:443)
[Default]
[Default] at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:643)
[Default]
[Default] at java.lang.Thread.run(Thread.java:484)
[Default]
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util Scheduler.java
User: schaefera Date: 01/06/10 11:40:21 Modified:src/main/org/jboss/util Scheduler.java Log: Fixed a problem with a wrong import. Revision ChangesPath 1.2 +0 -523jboss/src/main/org/jboss/util/Scheduler.java <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Interesting newsletter *was* WG: 2001-06-07 TJSN [022] - Classloaders Revisited: "Hotdeploy"
|Alternatively, if you are a bit lazy, nevertheless curious, i.e., |your are a system programmer, you can have a look at the latest |org.jboss.deployment.scope.* sources of the JBoss Open Source |application server (http://www.jboss.org) whose ingenious |mastermind, Marc Fleury, has been the originator of the presented |classloading semantics. Besides clustering support, the goal for |the next major release of Jboss (3.0 - Project Rabbit Hole) is to |have a deployer that can manage multiple scopes, i.e., "virtual |applications" such as we have today constructed out of stock.* |and sales.* Dr Jung, I appreciated the credit (I always do) since it did take me 1 full week of deep research to understand the weakness of the Delegation model. But I certainly did not come up with the ugly thread group repository. I believe it is weak to keep the CLs in the threads it is very indirected and for all practical purposes keep it in explicit even if scoped application class loaders. |He, he! | |[hk: hihi] marcf: niark, niark! | | | |Thanks for taking the time to read this newsletter, please also |take the time to give us feedback, we always appreciate it. | |Heinz |-- |Dr. Heinz M. Kabutz |Maximum Solutions - The Java(tm) Specialists |mailto:[EMAIL PROTECTED] |tel:+27 (083) 340-5633 |- |To join the newsletter, please click on: |mailto:[EMAIL PROTECTED]?subject=SubscribeJavaSpecialists22 |To unsubscribe from the newsletter, please click on: |mailto:[EMAIL PROTECTED]?subject=UnsubscribeJavaSpecialists22 |To get a zipped archive of past issues, please click on: |mailto:[EMAIL PROTECTED]?subject=SendArchive ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/naming/META-INF ejb-jar.xml
User: starksm Date: 01/06/10 11:29:06 Modified:src/resources/naming/META-INF ejb-jar.xml Log: Add tests of bean ENC isolation Revision ChangesPath 1.4 +21 -3 jbosstest/src/resources/naming/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/META-INF/ejb-jar.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ejb-jar.xml 2001/05/11 05:11:28 1.3 +++ ejb-jar.xml 2001/06/10 18:29:06 1.4 @@ -16,6 +16,12 @@ +A flag indicating if the bean should perform the full ENC testsuite +hasFullENC +java.lang.Boolean +true + + Integer0 Ints/i0 java.lang.Integer @@ -57,7 +63,7 @@ ejb/bean0 Session ENCBean0 -org.jboss.test.naming.interfaces.TestENCHome +org.jboss.test.naming.interfaces.TestENCHome2 org.jboss.test.naming.interfaces.TestENC @@ -111,13 +117,19 @@ -Referenced Bean0 +Referenced Bean0 Create by TestENCHome2 ENCBean0 org.jboss.test.naming.ejb.TestENCBean -org.jboss.test.naming.interfaces.TestENCHome +org.jboss.test.naming.interfaces.TestENCHome2 org.jboss.test.naming.interfaces.TestENC Stateless Container + +This bean should NOT have the same ENC as ENCBean +hasFullENC +java.lang.Boolean +false + Referenced Bean1 @@ -127,6 +139,12 @@ org.jboss.test.naming.interfaces.TestENC Stateless Container + +This bean should NOT have the same ENC as ENCBean +hasFullENC +java.lang.Boolean +false + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/naming/test TestENC.java
User: starksm
Date: 01/06/10 11:28:30
Modified:src/main/org/jboss/test/naming/test TestENC.java
Log:
Add tests of bean ENC isolation
Revision ChangesPath
1.2 +14 -0 jbosstest/src/main/org/jboss/test/naming/test/TestENC.java
Index: TestENC.java
===
RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/naming/test/TestENC.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestENC.java 2001/04/18 19:48:29 1.1
+++ TestENC.java 2001/06/10 18:28:30 1.2
@@ -13,6 +13,7 @@
import org.jboss.test.util.Deploy;
import org.jboss.test.naming.interfaces.TestENCHome;
+import org.jboss.test.naming.interfaces.TestENCHome2;
/** Tests of the secure access to EJBs.
@author [EMAIL PROTECTED]
@@ -41,6 +42,19 @@
EJBObject bean = home.create();
System.out.println("Created ENCBean");
+bean.remove();
+}
+
+public void testENC2() throws Exception
+{
+InitialContext jndiContext = new InitialContext();
+Object obj = jndiContext.lookup("ENCBean0");
+obj = PortableRemoteObject.narrow(obj, TestENCHome2.class);
+TestENCHome2 home = (TestENCHome2) obj;
+System.out.println("Found TestENCHome2");
+
+EJBObject bean = home.create();
+System.out.println("Created ENCBean0");
bean.remove();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/naming/ejb TestENCBean.java
User: starksm
Date: 01/06/10 11:28:30
Modified:src/main/org/jboss/test/naming/ejb TestENCBean.java
Log:
Add tests of bean ENC isolation
Revision ChangesPath
1.4 +26 -8 jbosstest/src/main/org/jboss/test/naming/ejb/TestENCBean.java
Index: TestENCBean.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/naming/ejb/TestENCBean.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- TestENCBean.java 2001/05/11 05:11:28 1.3
+++ TestENCBean.java 2001/06/10 18:28:30 1.4
@@ -12,11 +12,11 @@
to test ENC usage.
@author [EMAIL PROTECTED]
-@version $Revision: 1.3 $
+@version $Revision: 1.4 $
*/
public class TestENCBean implements SessionBean
{
-SessionContext sessionContext;
+private SessionContext sessionContext;
public void ejbCreate() throws CreateException
{
@@ -43,12 +43,30 @@
// Obtain the enterprise beans environment naming context.
Context initCtx = new InitialContext();
Context myEnv = (Context) initCtx.lookup("java:comp/env");
-testEnvEntries(initCtx, myEnv);
-testEjbRefs(initCtx, myEnv);
-testJdbcDataSource(initCtx, myEnv);
-testMail(initCtx, myEnv);
-testJMS(initCtx, myEnv);
-testURL(initCtx, myEnv);
+Boolean hasFullENC = (Boolean) myEnv.lookup("hasFullENC");
+if( hasFullENC == Boolean.TRUE )
+{
+// This bean should have the full ENC setup of the ENCBean
+testEnvEntries(initCtx, myEnv);
+testEjbRefs(initCtx, myEnv);
+testJdbcDataSource(initCtx, myEnv);
+testMail(initCtx, myEnv);
+testJMS(initCtx, myEnv);
+testURL(initCtx, myEnv);
+}
+else
+{
+// This bean should only have the hasFullENC env entry
+try
+{
+Integer i = (Integer) myEnv.lookup("Ints/i0");
+throw new EJBException("Was able to find java:comp/env/Ints/i0
in bean with hasFullENC = false");
+}
+catch(NamingException e)
+{
+// This is what we expect
+}
+}
}
catch(NamingException e)
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/naming/interfaces TestENCHome2.java
User: starksm
Date: 01/06/10 11:28:30
Added: src/main/org/jboss/test/naming/interfaces TestENCHome2.java
Log:
Add tests of bean ENC isolation
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/naming/interfaces/TestENCHome2.java
Index: TestENCHome2.java
===
package org.jboss.test.naming.interfaces;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
/**
@author [EMAIL PROTECTED]
@version $Revision: 1.1 $
*/
public interface TestENCHome2 extends EJBHome
{
public TestENC create() throws CreateException, RemoteException;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] New: Scheduler Service
Hi Scott Thanx, I will fix it right away. Andy - Original Message - From: Scott M Stark To: [EMAIL PROTECTED] Sent: Sunday, June 10, 2001 11:04 AM Subject: Re: [JBoss-dev] New: Scheduler Service There is either a bad import or a missing class in Scheduler.java: compile: [javac] Compiling 1 source file to D:\usr\local\src\cvsroot\jBoss\jboss\build\classes [javac] D:\usr\local\src\cvsroot\jBoss\jboss\src\main\org\jboss\util\Scheduler.java:35: Class management.J2EEApplication not found in import. [javac] import management.J2EEApplication; [javac] ^ This class is not used anywhere in the Scheduler class that I can see. - Original Message - From: Andreas Schaefer To: [EMAIL PROTECTED] Sent: Sunday, June 10, 2001 12:56 AM Subject: [JBoss-dev] New: Scheduler Service Hi Geeks After some requests for a JMX Timer example and using BEA Weblogic's Scheduler (@ work, of course) I came up with the idea of having a similar Scheduling Service but better because we do it right, right ? In jboss.jcml (default) is an example MBean definition. To use it on your own just do: - uncomment the example in jboss.jcml - create your own instance of a Schedulable taks by implementing the Schedulable interface - Replace the fully qualified class name with the Scheduler$SchedulableExample - Adjust the constructor values: 1) Name of the MBean 2) Fully qualified class name of your Schedulable Task class 3) Comma separated list of Constructor Values (NOT SUPPORTED yet) 4) Comma separated list of Constructor Data Types (NOT SUPPORTED yet) 5) Date of the initial call in milliseconds (0 = now) (except 0 NOT SUPPORTED yet) 6) Period between two calls in milliseconds 7) Number of repetitions where -1 means forever - Make your Schedulable Task class available for the Scheduling MBean (classpath extension etc.) I think that's it. Have fun and tell me what you think. Please note that this is a alpa version and is not finished. Your comment will help to make it better. Mad Andy / Better Pizza
[JBoss-dev] [ jboss-Change Notes-431864 ] Scheduler Service
Change Notes item #431864, was updated on 2001-06-10 11:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=431864&group_id=22866 Category: None Group: v2.2.3 Status: Open Priority: 5 Submitted By: Andreas Schaefer (schaefera) Assigned to: Nobody/Anonymous (nobody) Summary: Scheduler Service Initial Comment: Creation of a Scheduler Service allowing the client to specify a schedule with then calls the client's schedulable Task class. The scheduler service should work from "jboss.jcml", any JMX Adaptors or by using the MBeanServer or a Connector to create the instance. Attributes and Operations: - Schedulable: schedulable Task which could be either created on the fly or refer to another MBean. - Initial Start Date: when the first scheduled call is made. - Schedule Period: the time between to scheduled calls - Repetitions: number of scheduled calls (also unlimited) - startSchedule(): start the schedule if not started yet. - stopSchedule(): stops the schedule if started - restartSchedule(): stop and start the Schedule - isStart(): true if started - isUpdatePending(): true if attributes have changed but schedule is not restarted Andy -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=431864&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/build build.xml
User: starksm Date: 01/06/10 11:04:49 Modified:src/build build.xml Log: Set the classpath in the xmlbeans taskdef Revision ChangesPath 1.74 +3 -2 jboss/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/src/build/build.xml,v retrieving revision 1.73 retrieving revision 1.74 diff -u -r1.73 -r1.74 --- build.xml 2001/05/22 22:12:56 1.73 +++ build.xml 2001/06/10 18:04:49 1.74 @@ -15,8 +15,6 @@ - - @@ -55,6 +53,9 @@ + +
Re: [JBoss-dev] New: Scheduler Service
There is either a bad import or a missing class in Scheduler.java: compile: [javac] Compiling 1 source file to D:\usr\local\src\cvsroot\jBoss\jboss\build\classes [javac] D:\usr\local\src\cvsroot\jBoss\jboss\src\main\org\jboss\util\Scheduler.java:35: Class management.J2EEApplication not found in import. [javac] import management.J2EEApplication; [javac] ^ This class is not used anywhere in the Scheduler class that I can see. - Original Message - From: Andreas Schaefer To: [EMAIL PROTECTED] Sent: Sunday, June 10, 2001 12:56 AM Subject: [JBoss-dev] New: Scheduler Service Hi Geeks After some requests for a JMX Timer example and using BEA Weblogic's Scheduler (@ work, of course) I came up with the idea of having a similar Scheduling Service but better because we do it right, right ? In jboss.jcml (default) is an example MBean definition. To use it on your own just do: - uncomment the example in jboss.jcml - create your own instance of a Schedulable taks by implementing the Schedulable interface - Replace the fully qualified class name with the Scheduler$SchedulableExample - Adjust the constructor values: 1) Name of the MBean 2) Fully qualified class name of your Schedulable Task class 3) Comma separated list of Constructor Values (NOT SUPPORTED yet) 4) Comma separated list of Constructor Data Types (NOT SUPPORTED yet) 5) Date of the initial call in milliseconds (0 = now) (except 0 NOT SUPPORTED yet) 6) Period between two calls in milliseconds 7) Number of repetitions where -1 means forever - Make your Schedulable Task class available for the Scheduling MBean (classpath extension etc.) I think that's it. Have fun and tell me what you think. Please note that this is a alpa version and is not finished. Your comment will help to make it better. Mad Andy / Better Pizza
Re: [JBoss-dev] New: Scheduler Service
Hi Andreas! Can we have a ChangeNote on SF for this please ? It would help us not to forget to write some docu about this at the time this becomes part of the offical distro. Thx! Ciao, Tobi > Andreas Schaefer wrote: > > Hi Geeks > > After some requests for a JMX Timer example and using BEA Weblogic's > Scheduler (@ work, of course) I came up with the idea of having a > similar > Scheduling Service but better because we do it right, right ? > > In jboss.jcml (default) is an example MBean definition. To use it on > your > own just do: > - uncomment the example in jboss.jcml > - create your own instance of a Schedulable taks by implementing the > Schedulable interface > - Replace the fully qualified class name with the > Scheduler$SchedulableExample > - Adjust the constructor values: > 1) Name of the MBean > 2) Fully qualified class name of your Schedulable Task class > 3) Comma separated list of Constructor Values (NOT SUPPORTED yet) > 4) Comma separated list of Constructor Data Types (NOT SUPPORTED > yet) > 5) Date of the initial call in milliseconds (0 = now) (except 0 NOT > SUPPORTED yet) > 6) Period between two calls in milliseconds > 7) Number of repetitions where -1 means forever > - Make your Schedulable Task class available for the Scheduling MBean > (classpath > extension etc.) > > I think that's it. Have fun and tell me what you think. > > Please note that this is a alpa version and is not finished. Your > comment will help > to make it better. > > Mad Andy / Better Pizza ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Code: Stable RowID For Fast Updates
Hello Dan, Georg and all.
Here is the code update for the Fast RowID based
updates and deletes.
1. I have NOT modified the insert for insert into
as I am trying to avoid Oracle specified code [at least until JAWS becomes
completetly pluggable and all].
2. The only issue with this is that if the user
specified using the rowid and the rowid is null [say in ejbPostCreate, and when
else]. Given appropriate usage guidelines I think this can be
avoided.
3. I could have added code [in fact I did but
thought otherwise after that for defaulting back to the primary key IF the rowid
is null but that means we'd have to change the sql on the fly [ and during
setParameters since that is where the field values are actually read] which made
the code look rather clumsy.
To use this the user needs to specify the
stable-rowid-column value in the jaws.xml and a matching cmp field in the
bean.
Regards
Vinay
1. To the JawsEntityMetaData file
added
//Get
row id for fast stable row id based updates/deletes and inserts
stableRowIdColumn = getElementContent(getOptionalChild(element,
"stable-rowid-column"));
2. JDBCCreateEntityCommand.java
a) Constructor
/** * Don't include
the rowid column in the insert. That is something
the * database manages
for you.
*/
if(!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
{
fieldSql += (first ? "" : ",")
+
cmpField.getColumnName();
valueSql += first ? "?" :
",?";
first = false; }b)
setParameters
/** * Don't use the
rowid column as that is something the
dbms * manages for
you.
*/
if(!cmpField.getColumnName().equalsIgnoreCase(rowIDColumn))
{
Object value = getCMPFieldValue(ctx.getInstance(),
cmpField);
setParameter(stmt, idx++, cmpField.getJDBCType(),
value);
}3.JDBCStoreEntityCommand
a) setParameters
String
stableRowIdColumn = jawsEntity.getStableRowIdColumn();
/** * Will store the actual value for
the stable row id column * and the JDBC
type for this column
*/ Object
stableRowIdColumnValue=null; int
stableRowIdColumnType=0;
while
(iter.hasNext())
{ CMPFieldMetaData cmpField
= (CMPFieldMetaData)iter.next();
/** * If the stable
row id column was specified in jaws.xml and the
current * column being
processed is the stable rowid coulmn, then save the
value * and datatype
as we will need it to set the parameters in the
WHERE *
clause
*/
if(stableRowIdColumn!=null &&
cmpField.getColumnName().equalsIgnoreCase(stableRowIdColumn))
{
stableRowIdColumnValue =
es.currentState[i];
stableRowIdColumnType =
cmpField.getJDBCType();
}
else
{ if
(!tuned ||
es.dirtyField[i])
{
setParameter(stmt, idx++, cmpField.getJDBCType(),
es.currentState[i]);
} }
i++; }
/** * Alright, we've set all the
parameters now and lets set the parameters
for * the WHERE clause. If the stable
row id was specified in the jaws.xml *
then set the parameter for that alone, else set the usual primary
key * parameters to update based on
that.
*/
if(stableRowIdColumn!=null)
{
setParameter(stmt,idx,stableRowIdColumnType,stableRowIdColumnValue);
} else
{
setPrimaryKeyParameters(stmt, idx,
es.ctx.getId()); }b) makeSQL
String
stableRowIdColumn =
jawsEntity.getStableRowIdColumn();
if(stableRowIdColumn==null)
{
/** * If it isn't there then
just set it to an empty string to avoid
checking * for null in a
loop.
*/ stableRowIdColumn =
""; }
String sql =
"UPDATE "+jawsEntity.getTableName()+" SET ";
Iterator iter = jawsEntity.getCMPFields(); int
i = 0; boolean first =
true; while
(iter.hasNext())
{ CMPFieldMetaData cmpField
= (CMPFieldMetaData)iter.next();
if(!(cmpField.getColumnName().equalsIgnoreCase(stableRowIdColumn) ||
cmpField.getName().equalsIgnoreCase(stableRowIdColumn)))
{ if
(!tuned ||
es.dirtyField[i++])
{
sql += (first?"":",")
+
cmpField.getColumnName() +
"=?";
first =
false;
}
} }
sql += " WHERE
";
//Construct the
WHERE clause - either based on the stable row id or the
PK if(stableRowIdColumn.trim().length()>1
&& (!overrideRowId))
{ sql +=
stableRowIdColumn+" =?";
} else
{ sql +=
getPkColumnWhereList(); }
4. JDBCRemoveEntityCommand
a) Constructor
Strin
RE: [JBoss-dev] CMP fields XML Serialization
Hi, > Hi, > Since the nature of the type mapping isn't specified much in the spec, I > don't see how implementing this in jaws would be not spec compliant, > although it would be non portable to other app servers. I understand why > you would want to do this in the bean. I for one would like to see the > jaws code in whatever state you take it to. > What I did is add a attribute to of jaws.xml This goes up to CMPFieldMetaData. It has a type of MappingInterface and is instanciated at deployment. It has two method Object get(Object) and Object set(Object) These methods do the transformation from and to the database. The get() is used in the getValue of CMPFieldMetaData. The set() ... I am not there yet... To make a XML transformation, I would have a XMLMapper that implements MapperInterface by calling a method on the Object itself. That suppose my java Object cmp-field implement a XMLLoadable interface with an importXML and an exportXML. Really, nothing very special... Oh yes, another thing, I use nested properties for these kind of mapping whenever I CAN. I was thinking of this fetaure to Map special objects like Collection,Tree , ... Vincent. > I think an eventual goal must be to make jaws more modular. There are > several ideas that seem database specific (such as the stable > rowid stuff), > and I think it might be good to have optional abilities to do things like > > --use a jca resource.cci.connection with interactionspecs instead of jdbc > > --use stored procedures for insert, update, delete instead of semi-dynamic > sql. > > david jencks > > On 2001.06.09 09:52:32 -0400 Vincent Harcq wrote: > > Well, > > I think it is not spec compliant because this fetaure is not > supported by > > other appservers. For them I will have to serialize my object to the > > database. An my original problem was that if the version (serialization > > speaking) of this object change, I may have problem with old records in > > the > > database. Then if I implement a jboss specific feature and abuse of it, > > I > > will have to find another trick if I want to deploy my application on > > another ejb server. > > That said, I have the trick for these other appserver(explained in last > > mail) so if you think JBoss could gain by imlementing such a feature, I > > am > > still ready to implement it. > > In fact I have almost finish programming it. > > > > BTW, I was also thinking about a XML-Jaws that could use JAXB to store > > entity beans in XML databases. Just an idea, I have not really think > > about > > it. > > > > Vincent. > > > > > > > -Message d'origine- > > > De : [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]De la part de > > > David Jencks > > > Envoyé : samedi 9 juin 2001 15:30 > > > À : [EMAIL PROTECTED] > > > Objet : RE: [JBoss-dev] CMP fields XML Serialization > > > > > > > > > Hi, > > > I thought you had a great idea. I'm very curious about why this was a > > bad > > > idea and how it is not spec compliant. > > > > > > Thanks > > > david jencks > > > > > > On 2001.06.09 03:52:17 -0400 Vincent Harcq wrote: > > > > Forget it. > > > > I find it more spec compliant to have a String cmp field containing > > my > > > > XML > > > > respresentation. > > > > a getter method that do XML-->Object > > > > a setter method that do Object-->XML > > > > > > > > Anyway, make the storage of cmp field to db field in Jaws is not > > > > difficult > > > > but finally I don't think it's a good idea. > > > > > > > > Vincent. > > > > > -Message d'origine- > > > > > De : [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]]De > la part de > > > > > Vincent Harcq > > > > > Envoyé : vendredi 8 juin 2001 17:47 > > > > > À : [EMAIL PROTECTED] > > > > > Objet : RE: [JBoss-dev] CMP fields XML Serialization > > > > > > > > > > > > > > > Hi, > > > > > I will look at this idea, by having a new jdbc-type in > jaws.xml for > > > > which > > > > > parameters can be set that tells Jaws how to insert/retrieve > > > > > attribute/field. > > > > > But I still want to keep it simple and keep the constraint one cmp > > > > field / > > > > > one database field. > > > > > Regards. > > > > > Vincent. > > > > > > > > > > > -Message d'origine- > > > > > > De : [EMAIL PROTECTED] > > > > > > [mailto:[EMAIL PROTECTED]]De la part > > de > > > > Bill > > > > > > Burke > > > > > > Envoyé : vendredi 8 juin 2001 16:51 > > > > > > À : [EMAIL PROTECTED] > > > > > > Objet : RE: [JBoss-dev] CMP fields XML Serialization > > > > > > > > > > > > > > > > > > Can you plug-in how a CMP field is stored in the database? If > > not, > > > > this > > > > > > would be the best first step. > > > > > > > > > > > > Bill > > > > > > > > > > > > > -Original Message- > > > > > > > From: [EMAIL PROTECTED] > > > > > > > > [mailto:[EMAIL PROTECTED]]On Behalf > > Of > > > > > > > Vincent Harcq > > > > > > > Sent: Friday, June 08, 2001 3:23 AM > > > > > > > To: Dev JBoss > > > > > > > Subject: [JBoss-dev] CMP fields XML Serialization >
[JBoss-dev] New: Scheduler Service
Hi Geeks After some requests for a JMX Timer example and using BEA Weblogic's Scheduler (@ work, of course) I came up with the idea of having a similar Scheduling Service but better because we do it right, right ? In jboss.jcml (default) is an example MBean definition. To use it on your own just do: - uncomment the example in jboss.jcml - create your own instance of a Schedulable taks by implementing the Schedulable interface - Replace the fully qualified class name with the Scheduler$SchedulableExample - Adjust the constructor values: 1) Name of the MBean 2) Fully qualified class name of your Schedulable Task class 3) Comma separated list of Constructor Values (NOT SUPPORTED yet) 4) Comma separated list of Constructor Data Types (NOT SUPPORTED yet) 5) Date of the initial call in milliseconds (0 = now) (except 0 NOT SUPPORTED yet) 6) Period between two calls in milliseconds 7) Number of repetitions where -1 means forever - Make your Schedulable Task class available for the Scheduling MBean (classpath extension etc.) I think that's it. Have fun and tell me what you think. Please note that this is a alpa version and is not finished. Your comment will help to make it better. Mad Andy / Better Pizza
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util Schedulable.java Scheduler.java SchedulerMBean.java
User: schaefera
Date: 01/06/10 00:50:58
Added: src/main/org/jboss/util Schedulable.java Scheduler.java
SchedulerMBean.java
Log:
Added a Scheduler Service for JBoss to let run a Task at a given date/time
for a given number (also unlimited) of repeats.
Revision ChangesPath
1.1 jboss/src/main/org/jboss/util/Schedulable.java
Index: Schedulable.java
===
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.util;
import java.util.Date;
/**
* This interface defines the manageable interface for a Scheduler Service
* allowing the client to create a Schedulable instance which is then run
* by this service at given times.
*
* @author Andreas Schaefer ([EMAIL PROTECTED])
**/
public interface Schedulable
{
// -
// Constants
// -
// -
// Methods
// -
/**
* This method is called from the Scheduler Service
*
* @param pTimeOfCall Date/Time of the scheduled call
* @param pRemainingRepetitions Number of the remaining repetitions which
* is -1 if there is an unlimited number of
* repetitions.
**/
public void perform(
Date pTimeOfCall,
int pRemainingRepetitions
);
}
1.1 jboss/src/main/org/jboss/util/Scheduler.java
Index: Scheduler.java
===
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.util;
import java.lang.reflect.Constructor;
import java.security.InvalidParameterException;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Date;
import java.util.Hashtable;
import java.util.Iterator;
import java.util.Map;
import javax.management.MalformedObjectNameException;
import javax.management.MBeanServer;
import javax.management.Notification;
import javax.management.NotificationListener;
import javax.management.ObjectName;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.Name;
import javax.naming.NamingException;
import javax.naming.NameNotFoundException;
import javax.naming.Reference;
import javax.naming.StringRefAddr;
import org.jboss.logging.Log;
import org.jboss.naming.NonSerializableFactory;
import org.jboss.util.ServiceMBeanSupport;
import management.J2EEApplication;
/**
* Scheduler Instance to allow clients to run this as a
* scheduling service for any Schedulable instances.
*
* @author Andreas Schaefer ([EMAIL PROTECTED])
**/
public class Scheduler
extends ServiceMBeanSupport
implements SchedulerMBean
{
// -
// Constants
// -
public static String JNDI_NAME = "scheduler:domain";
public static String JMX_NAME = "scheduler";
// -
// Members
// -
private MBeanServer mServer;
private String mName;
private long mSchedulePeriod;
private int mRemainingRepetitions = 0;
private int mActualSchedule = -1;
private boolean mScheduleIsStarted = false;
private boolean mWaitForNextCallToStop = false;
private ObjectName mTimer;
private Schedulable mSchedulable;
private boolean mStartOnStart = false;
private String mSchedulableClass;
private Object[] mInitArguments;
private String[] mInitTypes;
private Date mStartDate;
private long mPeriod;
private int mRepetitions;
// -
// Constructors
// -
/**
* Default (no-args) Constructor
**/
public Scheduler()
{
mName = null;
}
/**
* Constructor with the necessary attributes to be set
*
* @param pName Name of the MBean
**/
public Scheduler( String pName )
{
mName = pName;
}
/**
* Constructor with the necessary attributes to be set
*
[JBoss-dev] CVS update: jboss/src/main/org/jboss/configuration ConfigurationService.java
User: schaefera
Date: 01/06/10 00:49:09
Modified:src/main/org/jboss/configuration ConfigurationService.java
Log:
Added primitive value support for Constructor Arguments. As type just enter
the same as you use as data type ("int", "long" etc.).
Revision ChangesPath
1.29 +37 -3 jboss/src/main/org/jboss/configuration/ConfigurationService.java
Index: ConfigurationService.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/configuration/ConfigurationService.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- ConfigurationService.java 2001/05/04 22:47:14 1.28
+++ ConfigurationService.java 2001/06/10 07:49:09 1.29
@@ -45,7 +45,7 @@
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author [EMAIL PROTECTED]
* @author Jason Dillon mailto:[EMAIL PROTECTED]";><[EMAIL PROTECTED]>
- * @version $Revision: 1.28 $
+ * @version $Revision: 1.29 $
*/
public class ConfigurationService
extends ServiceMBeanSupport
@@ -462,8 +462,42 @@
//
// NOTE: should coerce value to the correct type??
//
-info.signature[j] = arg.getAttribute("type");
-info.params[j] = arg.getAttribute("value");
+// Add support for primitive Data Types
+String signature = arg.getAttribute("type");
+String value = arg.getAttribute("value");
+Object realValue = value;
+if( signature != null ) {
+ if( signature.equals( "int" ) ) {
+ signature = Integer.TYPE.getName();
+ realValue = new Integer( value );
+ } else
+ if( signature.equals( "long" ) ) {
+ signature = Long.TYPE.getName();
+ realValue = new Long( value );
+ } else
+ if( signature.equals( "byte" ) ) {
+ signature = Byte.TYPE.getName();
+ realValue = new Byte( value );
+ } else
+ if( signature.equals( "char" ) ) {
+ signature = Character.TYPE.getName();
+ realValue = new Character( value.charAt( 0 ) );
+ } else
+ if( signature.equals( "float" ) ) {
+ signature = Float.TYPE.getName();
+ realValue = new Float( value );
+ } else
+ if( signature.equals( "double" ) ) {
+ signature = Double.TYPE.getName();
+ realValue = new Double( value );
+ } else
+ if( signature.equals( "boolean" ) ) {
+ signature = Boolean.TYPE.getName();
+ realValue = new Boolean( value );
+ }
+}
+info.signature[j] = signature;
+info.params[j] = realValue;
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default jboss.jcml
User: schaefera Date: 01/06/10 00:47:47 Modified:src/etc/conf/default jboss.jcml Log: Added the example for a scheduling Task supported by the new Scheduler. Revision ChangesPath 1.37 +17 -0 jboss/src/etc/conf/default/jboss.jcml Index: jboss.jcml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss.jcml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- jboss.jcml2001/06/04 22:55:12 1.36 +++ jboss.jcml2001/06/10 07:47:47 1.37 @@ -418,6 +418,23 @@ + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ResourceEnvRefMetaData.java SecurityIdentityMetaData.java ApplicationMetaData.java BeanMetaData.java EntityMetaData.java MessageDrivenMetaData.java MethodMetaData.java ResourceRefMetaData.java SecurityRoleRefMetaData.java SessionMetaData.java
User: starksm
Date: 01/06/10 00:46:17
Modified:src/main/org/jboss/metadata ApplicationMetaData.java
BeanMetaData.java EntityMetaData.java
MessageDrivenMetaData.java MethodMetaData.java
ResourceRefMetaData.java
SecurityRoleRefMetaData.java SessionMetaData.java
Added: src/main/org/jboss/metadata ResourceEnvRefMetaData.java
SecurityIdentityMetaData.java
Log:
Add missing meta data types for new EJB2.0 elements
Update existing meta data types for changes in EJB2.0
Revision ChangesPath
1.16 +63 -11jboss/src/main/org/jboss/metadata/ApplicationMetaData.java
Index: ApplicationMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- ApplicationMetaData.java 2001/04/17 19:52:21 1.15
+++ ApplicationMetaData.java 2001/06/10 07:46:16 1.16
@@ -28,7 +28,7 @@
* @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
* @author Peter Antman ([EMAIL PROTECTED])
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.15 $
+ * @version $Revision: 1.16 $
*/
public class ApplicationMetaData extends MetaData {
// Constants -
@@ -42,6 +42,7 @@
private HashMap resources = new HashMap();
private HashMap plugins = new HashMap();
private String securityDomain;
+private boolean enforceEjbRestrictions;
// Static
@@ -98,6 +99,10 @@
{
return securityDomain;
}
+public boolean getEnforceEjbRestrictions()
+{
+return enforceEjbRestrictions;
+}
public void importEjbJarXml (Element element) throws DeploymentException {
@@ -146,7 +151,8 @@
// read the assembly descriptor (optional)
Element assemblyDescriptor = getOptionalChild(element,
"assembly-descriptor");
- if (assemblyDescriptor != null) {
+ if (assemblyDescriptor != null)
+ {
// set the security roles (optional)
iterator = getChildrenByTagName(assemblyDescriptor, "security-role");
@@ -165,14 +171,25 @@
try {
while (iterator.hasNext()) {
Element methodPermission = (Element)iterator.next();
-
- // find the list of roles
- Set roles = new HashSet();
- Iterator rolesIterator = getChildrenByTagName(methodPermission,
"role-name");
- while (rolesIterator.hasNext()) {
- roles.add(getElementContent((Element)rolesIterator.next()));
+ // Look for the unchecked element
+ Element unchecked = getOptionalChild(methodPermission, "unchecked");
+ boolean isUnchecked = false;
+ Set roles = null;
+ if( unchecked != null )
+ isUnchecked = true;
+ else
+ {
+ // Get the role-name elements
+ roles = new HashSet();
+ Iterator rolesIterator = getChildrenByTagName(methodPermission,
"role-name");
+ while (rolesIterator.hasNext())
+ {
+ roles.add(getElementContent((Element)rolesIterator.next()));
+ }
+ if( roles.size() == 0 )
+ throw new DeploymentException("An unchecked element or one or
more role-name elements must be specified in method-permission");
}
-
+
// find the methods
Iterator methods = getChildrenByTagName(methodPermission, "method");
while (methods.hasNext()) {
@@ -180,7 +197,10 @@
// load the method
MethodMetaData method = new MethodMetaData();
method.importEjbJarXml((Element)methods.next());
- method.setRoles(roles);
+ if( isUnchecked )
+ method.setUnchecked();
+ else
+method.setRoles(roles);
// give the method to the right bean
BeanMetaData bean = getBeanByEjbName(method.getEjbName());
@@ -240,15 +260,47 @@
} catch (DeploymentException e) {
throw new DeploymentException("Error in ejb-jar.xml, in
container-transaction: " + e.getMessage());
}
+
+// Get the exclude-list methods
+Element excludeList = getOptionalChild(assemblyDescriptor,
"exclude-list");
+
