[JBoss-dev] cvs RH hangs if I am not dialled up....
at : 10:07:34,030 INFO [AutoDeployer] Auto deploying: file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0alpha/deploy/cluster-service.xml 10:07:34,222 INFO [JRMPInvokerHA] JRMP Invoker MBean online 10:07:34,300 INFO [ClusterPartition] Initializing 10:07:34,320 INFO [ClusterPartition] Creating JavaGroups JChannel 10:07:34,999 INFO [ClusterPartition] Creating HAPartition... 10:07:35,126 INFO [ClusterPartition] ...Initing HAPartition... 10:07:35,160 INFO [HAPartition:DefaultPartition] creating SubcontextHAPartition 10:07:35,174 INFO [HAPartition:DefaultPartition] done initing.. 10:07:35,184 INFO [ClusterPartition] ...HAPartition initialized. 10:07:35,194 INFO [ClusterPartition] Initialized 10:07:35,203 WARN [ServiceController] jboss:service=HASessionState does not implement any Service methods 10:07:35,213 WARN [ServiceController] jboss:service=HAJNDI does not implement any Service methods 10:07:35,223 INFO [JRMPInvokerHA] creating 10:07:35,224 INFO [JRMPInvokerHA] created 10:07:35,233 WARN [ServiceController] jboss:service=HASessionState does not implement any Service methods 10:07:35,234 WARN [ServiceController] jboss:service=HAJNDI does not implement any Service methods 10:07:35,243 INFO [ClusterPartition] Starting 10:07:35,246 INFO [ClusterPartition] Starting ClusterPartition: DefaultPartition 10:07:35,247 INFO [ClusterPartition] Connecting to channel This has been happening for a few days now. I found that a 'cvs update -P -d -D 'December 31, 2001 09:00 GMT'' takes me back to a version that doesn't do this.. but it would be more convenient if HEAD ran for me Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: scheduler bug?
have you read my message about that?
maybe does it not work (possible
since my code is a variant of schedule)
anyway check recent version, and also check the archive in jboss-user or in
the forum, or in jboss-dev
since people here have already answered me that
it was solved...
anyway, you can correct it the DIY way :
if it is the addnotification dynamic call that
fails, check the signature of the addNotification,
and modify the dynamic call so that it
match, the number of arguments, the dynamic
values, and the dynamic types names...
don't forget that basic types have no .class field
(they ar not classes indeed!), but use the .TYPE
fies of the corresponding holding class, eg:
Long.TYPE.getName()
unlike usual
String.class.getName() because String is a class...
also pass the holder type as the dynamic parameters
since the value parameters list is an array of Object,
and basic type are not Object !
depending on the code you have, you should obtain something like
mActualSchedule = ( (Integer) getServer().invoke(
mTimer,
addNotification,
new Object[] {
Schedule,
Scheduler Notification,
null,
new Date( new Date().getTime() + 1000 ),
new Long( mActualSchedulePeriod ),
new Long( mRemainingRepetitions )
},
new String[] {
.getClass().getName(),
.getClass().getName(),
Object.class.getName(),
Date.class.getName(),
Long.TYPE.getName(),
Long.TYPE.getName()
}
) ).intValue();
note that, I repeat, this is not the good mailing list...
this is the jboss internal developers list.
I may even be flammed to death for giving an answer here.
jboss-user was the good one but is officialy (not really)
shut-down
forums on jboss.org are the good place, but to be honnest
I don't read it (an old debate about push/pull
that take place
when jboss-user was shut-down)...
anyway read the archives in forums
-Message d'origine-
De: rajeshwarraov [mailto:[EMAIL PROTECTED]]
Date: vendredi 4 janvier 2002 08:16
À: [EMAIL PROTECTED]
Objet: [JBoss-dev] Re: scheduler bug?
I am also facing same problem...I need the solution
urgently..anybody out there to help me
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: TR: one more thing
From the Servlet 2.3 spec. SRV.7.7.2 Distributed Environments Within an application marked as distributable, all requests that are part of a session must handled by one virtual machine at a time. The container must be able to handle all objects placed into instances of the HttpSession class using the setAttribute or putValue methods appropriately. The following restrictions are imposed to meet these conditions: The container must accept objects that implement the Serializable interface The container may choose to support storage of other designated objects in the HttpSession, such as references to Enterprise JavaBean components and transactions. Migration of sessions will be handled by container-specific facilities. The servlet container may throw an IllegalArgumentException if an object is placed into the session that is not Serializable or for which specific support has not been made available. The IllegalArgumentException must be thrown for objects where the container cannot support the mechanism necessary for migration of a session storing them. These restrictions mean that the Developer is ensured that there are no additional concurrency issues beyond those encountered in a non-distributed container. The Container Provider can ensure scalability and quality of service features like load-balancing and failover by having the ability to move a session object, and its contents, from any active node of the distributed system to a different node of the system. If distributed containers persist or migrate sessions to provide quality of service features, they are not restricted to using the native JVM Serialization mechanism for serializing HttpSessions and their attributes. Developers are not guaranteed that containers will call readObject and writeObject methods on session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved. Containers must notify any session attributes implementing the HttpSessionActivationListener during migration of a session. They must notify listeners of passivation prior to serialization of a session, and of activation after deserialization of a session. Application Developers writing distributed applications should be aware that since the container may run in more than one Java virtual machine, the developer cannot depend on static variables for storing an application state. They should store such states using an enterprise bean or a database. So, the spec takes the simple route out. Ensuring that all requests forming part of a single session/conversation are routed to the same node avoids all the thorny issues which Marc is eager to overcome. I was going for a staggered solution. Firstly - Implement simply what the spec says, in a coarse grained way - i.e. passivate a session into distributed store on Jetty shutdown and re-activate it as-and-when needed in another Jetty instance. The only problem I forsee with this is garbage collection of orphanned (i.e. the Jetty instance that created them is gone, and the client that initiated their conversation has stopped talking) distributed sessions. This would work fine provided that Jetty shutdown was controlled. If not, the whole session is lost. Secondly - Like (1) - but more fine grained, and tunable. Distribute changes to the session according to some parameter e.g. every time an attribute is changed, at the end of every request, every minute etc... This approach could subsume all the fn-ality of the first, at it's most coarse grained, and also, at it's most fine-grained, ensure that if a node failed all conversational state up to that point would be preserved. But the cost would be higher in trips to the distributed store. Thirdly (the Holy Grail) Take (2) at it's most fine grained and relax the constraint on all requests for the same session going to the same node. This would allow any request to be routed to any cluster node, but at what cost ??? This seems to be Marc's dream ! Your point pokes a bit of a hole through (2) and (3). I think it would be fair enough to assume that, as the spec says, Application Developers writing distributed applications should be aware that since the container may run in more than one Java virtual machine.. Therefore they should do another setAttribute() after the setField(). Requiring this, whilst possibly being seen as a change of semantics by existing apps would allow us to be much more thrifty with our network ! Of course this doesn't exclude having a fourth implementation which attempts to stick to the old semantics and insists that we can't rely on this second setAttribute(). It just gives the developer the chance to speed up his app by giving us more help - without introducing a new API and without sacrificing any portability of his app. I am working on the first solution at the moment. I shall have a good look at various other app-server's approaches to these issues over the next few weeks. I think
Re: [JBoss-dev] more jmx domain structure
Does this mean that there are hard-coded references between mbeans? I think it would be a good idea to convert these to depends elements in the mbean configuration (formerly mbean-ref elements) to make these dependencies more explicit. What do you think? Good and bad, don't make it a default (which is what I am reading here). The truth is that while we use JMX to loosely create and configure objects, some islands of objects just live together should we hardcode the links in there (inside the island) or should we expose these links *at the same level of management as we do the rest of the configuration*? the answer is no.. don't, keep the real configuration (that that will change) configurable. These links are explicit in normal java code as we compile against them and pass reference. In JMX we configure objectnames as string, but the fact is that the code flow is mostly always the same and (for example) an EJBDeployer and a SARDeployer will always use the MainDeployer (in the new deployer codebase I will commit when I get back to Atlanta). Should we expose that reference for *users* to see and configure? *NO* Hardcoding JMX Object Names references (through the use of MyInterface.OBJECT_NAME as we do today) is in fact the better, more useable solution. Don't expose kernel configuration knowledge in a file that users are supposed to read and configure... marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5570 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: scheduler bug? probably...
I've read the current (latest) 2.4.4
source of the scheduler
this is not the old bug I was talking about, but
another I had forgotten til now, and corrected by the way...
note that it is still present in CVS, in last version 1.4.4.1 of the 2.4.4
branch
and in last 1.12 version of the 3.0* head branch...
summary:
in 2 of the 4 dynamic invocation of the timer addnotification method,
the user object parameter is forgotten...
I've attached a version of Scheduler.java that should work
I've not tested myself (it works on my variant of Scheduler )...
if it correct the problem it should be integrated in 2.4.4 and 3.0 CVS
branch
you can now :
- either:
-make the change according to my hypothesis,
-or take my code if you are confident
- then either :
-compile (with jboss.jar, withou the scheduler*.class), rebuild, and
deploy jboss.jar,
-compile the class, create a jar patch, and refer it in jboss startup
options
-change the package name, compile as usual, make a jar,put it in lib/ext,
and use it instead of org.jboss.util.Scheduler
then if ok, could you tell everybody that it works
(if not, tell me, and if all fails, I'll make my public self-criticism here
8 )
if it works this mail could be a patch proposal to jboss-dev community
(IMHO, a good reason to talk about that here)
hope I'm not wrong,
and hope it will help...
--- long version
I've read the code the addNotification refers
to JMX standard MBean interface Timer.
(could you send me the exact error messages...)
the official signatures of addNotification on
javax.management.timer.Timer
http://dyade.inrialpes.fr/aaa/public/java/jmx/jmx_instr_agent_snmp_javadoc/j
mx/index.html
java.lang.Integer addNotification(java.lang.String type, java.lang.String
message, java.lang.Object userData, java.util.Date date)
java.lang.Integer addNotification(java.lang.String type, java.lang.String
message, java.lang.Object userData, java.util.Date date, long period)
java.lang.Integer addNotification(java.lang.String type, java.lang.String
message, java.lang.Object userData, java.util.Date date, long period, long
nbOccurences)
but in the 3rd and 4th dynamic invocation of addNotification there is no
proposed userData object (which is not used here), despite the fact it is
needed in all version of the addNotification
one should propose a null object as 3rd parameter like it is done in the 1st
and 2nd invocation
you should change the callsto
// Add an initial call
mActualSchedule = ( (Integer) getServer().invoke(
mTimer,
addNotification,
new Object[]
{
Schedule,
Scheduler Notification,
null, /* user object */
mStartDate
},
new String[]
{
String.class.getName(),
String.class.getName(),
Object.class.getName(), /* user object
*/
Date.class.getName(),
}
) ).intValue();
and
// Add regular schedule
mActualSchedule = ( (Integer) getServer().invoke(
mTimer,
addNotification,
new Object[]
{
Schedule,
Scheduler Notification,
null, /* user object */
new Date( new Date().getTime() + 1000 ),
new Long( mActualSchedulePeriod ),
new Long( getRemainingRepetitions() )
},
new String[]
{
.getClass().getName(),
.getClass().getName(),
Object.class.getName(), /* user object
*/
Date.class.getName(),
Long.TYPE.getName(),
Long.TYPE.getName()
}
) ).intValue();
so, get the source of 2.4.4, modify them accordingly,
or use the version I've attached
and then rebuild jboss.jar...
if you don't want to change it
you can :
- get a copy of jboss.jar
- remove Scheduler.class (and Scheduler$SchedulableExample.jar and
Scheduler$Listenr.class) from this jboss.jar
- recompile your version of Scheduler with this jboss.jar
and add the compiled classes to this jboss.jar now, and put it in place of
the former jboss.jar
you can also begin like before with a copy of the jboss.jar, and then
build a scheduler-patch.jar with scheduler.class, ad put them in a patch
directory
that you indicate with the -p option (I've never tested that)
finally the most easy is to copy the Scheduler.java, correct the bug, change
the
package name (eg: package
Re: [JBoss-dev] JRMPInvokerHA - Invalid remote object?
The bits have been rewritten and updated so you probably are trying to return a newer version while you still have an old version on the client. Something like that. marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6593 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Australia training, please read
Folks, it is a bit disapointing that after recieving 7 requests to go down under with the training we only have 3 people registered. Boston is selling well and already London has outsold Australia despite the fact that London is a month later and we lowered the price on the Australia training. We are truly sorry that there is such a difference in purchasing power between continents but it is just not worth it for us to take the training down under if more of you don't sign up. We will wait until the 15th of January and if we have not sold at least 10 places we will cancel and refund anyone that has already paid. We apologize for those that have already commited to the training and will give them the discounted price for any US or European training if we have to cancel Sydney. Cheers mates, marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6614 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] test again
sorry. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Container.java
User: ejort
Date: 02/01/04 09:59:57
Modified:src/main/org/jboss/ejb Container.java
Log:
Temprory Hack to allow servlets to create user transactions.
This should be fixed when local invocations are no longer
marshalled.
Revision ChangesPath
1.67 +41 -22jboss/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.66
retrieving revision 1.67
diff -u -r1.66 -r1.67
--- Container.java2002/01/03 04:00:57 1.66
+++ Container.java2002/01/04 17:59:57 1.67
@@ -40,6 +40,7 @@
import javax.naming.StringRefAddr;
import javax.naming.RefAddr;
import javax.naming.NameNotFoundException;
+import javax.transaction.Transaction; // tmp
import javax.transaction.TransactionManager;
import org.jboss.deployment.DeploymentException;
@@ -67,17 +68,17 @@
*
* pThe ContainerFactory creates instances of subclasses of this class
*and calls the appropriate initialization methods.
- *
+ *
* pA Container does not perform any significant work, but instead delegates
*to the plugins to provide for all kinds of algorithmic functionality.
*
* @see ContainerFactory
- *
+ *
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
* @author a href=[EMAIL PROTECTED]Bill Burke/a
- * @version $Revision: 1.66 $
+ * @version $Revision: 1.67 $
*
* pbRevisions:/b
*
@@ -172,7 +173,7 @@
/** ObjectName of the JSR-77 EJB representation **/
protected String mEJBObjectName;
-
+
/**
* The name of the Remote invoker dedicated to this container,
* the type is set through deployment
@@ -422,7 +423,7 @@
localHomeInterface = classLoader.loadClass(metaData.getLocalHome());
if (metaData.getLocal() != null)
localInterface = classLoader.loadClass(metaData.getLocal());
-
+
localContainerInvoker.setContainer( this );
localContainerInvoker.create();
if (localHomeInterface != null)
@@ -572,7 +573,7 @@
// FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE INTEGRATED
log.debug(METHOD REMOTE INVOKE
+mi.getContainer()+||+mi.getMethod().getName()+||);
-}
+}
// FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE INTEGRATED
else if
(!mi.getMethod().getDeclaringClass().isAssignableFrom(remoteInterface))
{
@@ -585,61 +586,79 @@
// FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE INTEGRATED
log.debug(WARNING: YOU ARE RUNNING NON-OPTIMIZED);
}
+
+ // TEMP FIXME HACK This makes user transactions on the server work
until
+ // local invocations stop going through Marshalled Invocation
+ Transaction hack = mi.getTransaction();
+
// FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE INTEGRATED
//Serialize deserialize
mi = (Invocation) new MarshalledObject(new
MarshalledInvocation(mi.payload)).get();
-
+
+ // TEMP FIXME HACK This makes user transactions on the server work
until
+ // local invocations stop going through Marshalled Invocation
+ mi.setTransaction(hack);
+
// FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE INTEGRATED
((MarshalledInvocation)
mi).setMethodMap(marshalledInvocationMapping);
-
+
// FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE INTEGRATED
return new MarshalledObject(invoke(mi));
}
-
+
value = invoke(mi);
}
-
+
else if( actionName.equals(local) )
{
throw new MBeanException(new UnsupportedOperationException(local is
not supported yet));
}
else if( actionName.equals(home) )
{
-
-if (mi instanceof MarshalledInvocation)
+
+if (mi instanceof MarshalledInvocation)
{
-
+
((MarshalledInvocation)
mi).setMethodMap(marshalledInvocationMapping);
-
+
if (log.isDebugEnabled())
// FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE INTEGRATED
log.debug(METHOD HOME INVOKE
+mi.getContainer()+||+mi.getMethod().getName()+||+mi.getArguments().toString());
-
-}
+
+}
// FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE INTEGRATED
[JBoss-dev] RE: TR: one more thing
Hello, Firstly - Implement simply what the spec says, in a coarse grained way - i.e. passivate a session into distributed store on Jetty shutdown and re-activate it as-and-when needed in another Jetty instance. The only problem I forsee with this is garbage collection of orphanned (i.e. the Jetty instance that created them is gone, and the client that initiated their conversation has stopped talking) distributed sessions. This would work fine provided that Jetty shutdown was controlled. If not, the whole session is lost. Well, this does not really provide fail-over or load-balancing anyway. Secondly - Like (1) - but more fine grained, and tunable. Distribute changes to the session according to some parameter e.g. every time an attribute is changed, at the end of every request, every minute etc... This approach could subsume all the fn-ality of the first, at it's most coarse grained, and also, at it's most fine-grained, ensure that if a node failed all conversational state up to that point would be preserved. But the cost would be higher in trips to the distributed store. This is the solution that I have already implemented: please take a look at my recent post on jboss-dev: a distributed store, an entity bean, and an MBEAN for you. But you need to *always* call getSession and setSession: you can't managed the session cache yourself in jetty. Thirdly (the Holy Grail) Take (2) at it's most fine grained and relax the constraint on all requests for the same session going to the same node. This would allow any request to be routed to any cluster node, but at what cost ??? This seems to be Marc's dream ! If all requests for the same session (sticky load-balancers in front-end) go to the same node, we have an optimisation: the httpsession is cached in an Entity bean (see my post on jboss-dev) Your point pokes a bit of a hole through (2) and (3). I think it would be fair enough to assume that, as the spec says, Application Developers writing distributed applications should be aware that since the container may run in more than one Java virtual machine.. Therefore they should do another setAttribute() after the setField(). Requiring this, whilst possibly being seen as a change of semantics by existing apps would allow us to be much more thrifty with our network ! I agree but existing applications would fail. Of course this doesn't exclude having a fourth implementation which attempts to stick to the old semantics and insists that we can't rely on this second setAttribute(). It just gives the developer the chance to speed up his app by giving us more help - without introducing a new API and without sacrificing any portability of his app. OK, so let's make it an optional behaviour to be there as an optimisation. I am working on the first solution at the moment. I shall have a good look at various well... solution 2-3 is already implemented! I've sent an e-mail to jboss-dev recently (and to you) with the details of the implementation and how jetty should use it. Have you seen/read it? Cheers, Sacha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] more jmx domain structure
Jason, Sorry to come late on this... but what about jboss.cluster for clustering? cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Jason Dillon Envoye : jeudi, 3 janvier 2002 05:26 A : [EMAIL PROTECTED]; [EMAIL PROTECTED] Objet : RE: [JBoss-dev] more jmx domain structure I just finished commiting this. I was unable to change the 'SingleJBoss' or the 'JMImplementation' domains, so I left them as they were. I don't know where the later even gets set. I tried changing SingleJBoss, but it is not as straight forward as the others I changed. Currently the default build has the follwing domains: JMImplementation SingleJBoss jboss.j2ee jboss.jca jboss.jmx jboss.mq jboss.mq.destination jboss.security jboss.system jboss.system.classloader jboss.web jboss ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: TR: one more thing
Sacha, I saw your stuff. I had the idea from Marc that I would write a CMP bean, and you would provide a clever CMP implementation which would be of benefit not just to HttpSessions, but to anyone with similar requirements. Thus I figured I would write the bean and then work with you to swap the CMP implementation as a later optimisation. It looks like a misunderstanding. I will go back and reread your mails. It should be trivial to unplug my CMP bean and replace it with your store. No Problemo ! I'll check in what I've got first. Jules Sacha Labourey wrote: Hello, Firstly - Implement simply what the spec says, in a coarse grained way - i.e. passivate a session into distributed store on Jetty shutdown and re-activate it as-and-when needed in another Jetty instance. The only problem I forsee with this is garbage collection of orphanned (i.e. the Jetty instance that created them is gone, and the client that initiated their conversation has stopped talking) distributed sessions. This would work fine provided that Jetty shutdown was controlled. If not, the whole session is lost. Well, this does not really provide fail-over or load-balancing anyway. Secondly - Like (1) - but more fine grained, and tunable. Distribute changes to the session according to some parameter e.g. every time an attribute is changed, at the end of every request, every minute etc... This approach could subsume all the fn-ality of the first, at it's most coarse grained, and also, at it's most fine-grained, ensure that if a node failed all conversational state up to that point would be preserved. But the cost would be higher in trips to the distributed store. This is the solution that I have already implemented: please take a look at my recent post on jboss-dev: a distributed store, an entity bean, and an MBEAN for you. But you need to *always* call getSession and setSession: you can't managed the session cache yourself in jetty. Thirdly (the Holy Grail) Take (2) at it's most fine grained and relax the constraint on all requests for the same session going to the same node. This would allow any request to be routed to any cluster node, but at what cost ??? This seems to be Marc's dream ! If all requests for the same session (sticky load-balancers in front-end) go to the same node, we have an optimisation: the httpsession is cached in an Entity bean (see my post on jboss-dev) Your point pokes a bit of a hole through (2) and (3). I think it would be fair enough to assume that, as the spec says, Application Developers writing distributed applications should be aware that since the container may run in more than one Java virtual machine.. Therefore they should do another setAttribute() after the setField(). Requiring this, whilst possibly being seen as a change of semantics by existing apps would allow us to be much more thrifty with our network ! I agree but existing applications would fail. Of course this doesn't exclude having a fourth implementation which attempts to stick to the old semantics and insists that we can't rely on this second setAttribute(). It just gives the developer the chance to speed up his app by giving us more help - without introducing a new API and without sacrificing any portability of his app. OK, so let's make it an optional behaviour to be there as an optimisation. I am working on the first solution at the moment. I shall have a good look at various well... solution 2-3 is already implemented! I've sent an e-mail to jboss-dev recently (and to you) with the details of the implementation and how jetty should use it. Have you seen/read it? Cheers, Sacha _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: thirdparty/mortbay/jetty/lib org.mortbay.jetty.jar
User: jules_gosnell Date: 02/01/04 10:21:15 Modified:mortbay/jetty/lib org.mortbay.jetty.jar Log: first cut of distributed HttpSession stuff Revision ChangesPath 1.10 +236 -239 thirdparty/mortbay/jetty/lib/org.mortbay.jetty.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty DistributedSessionManager.java
User: jules_gosnell
Date: 02/01/04 10:21:15
Modified:jetty/src/main/org/jboss/jetty
DistributedSessionManager.java
Log:
first cut of distributed HttpSession stuff
Revision ChangesPath
1.2 +216 -19
contrib/jetty/src/main/org/jboss/jetty/DistributedSessionManager.java
Index: DistributedSessionManager.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/DistributedSessionManager.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- DistributedSessionManager.java2002/01/03 20:51:05 1.1
+++ DistributedSessionManager.java2002/01/04 18:21:15 1.2
@@ -5,15 +5,32 @@
* See terms of license at gnu.org.
*/
-// $Id: DistributedSessionManager.java,v 1.1 2002/01/03 20:51:05 jules_gosnell Exp $
+// $Id: DistributedSessionManager.java,v 1.2 2002/01/04 18:21:15 jules_gosnell Exp $
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
package org.jboss.jetty;
+import java.rmi.RemoteException;
+import java.util.ArrayList;
import java.util.EventListener;
+import java.util.HashMap;
+import java.util.Iterator;
+import javax.ejb.CreateException;
+import javax.ejb.FinderException;
+import javax.ejb.ObjectNotFoundException;
+import javax.ejb.RemoveException;
+import javax.naming.InitialContext;
+import javax.naming.NamingException;
+import javax.rmi.PortableRemoteObject;
import javax.servlet.http.HttpSession;
+import javax.servlet.http.HttpSessionListener;
+import javax.servlet.http.HttpSessionActivationListener;
+import javax.servlet.http.HttpSessionEvent;
+import org.jboss.jetty.interfaces.CoarseHttpSession;
+import org.jboss.jetty.interfaces.CoarseHttpSessionHome;
+import org.jboss.jetty.interfaces.CoarseHttpSessionData;
import org.jboss.logging.Logger;
import org.mortbay.jetty.servlet.ServletHandler;
import org.mortbay.util.LifeCycle;
@@ -21,15 +38,30 @@
/* - */
/**
*
- * @version $Id: DistributedSessionManager.java,v 1.1 2002/01/03 20:51:05
jules_gosnell Exp $
+ * @version $Id: DistributedSessionManager.java,v 1.2 2002/01/04 18:21:15
jules_gosnell Exp $
* @author [EMAIL PROTECTED]
*/
public class DistributedSessionManager
extends org.mortbay.jetty.servlet.HashSessionManager
{
+ static InitialContext _jndiContext;
+
+ static
+ {
+try
+{
+ _jndiContext=new InitialContext();
+}
+catch (NamingException e)
+{
+ Logger.getLogger(DistributedSessionManager).
+ warn(WARNING: could not get JNDI Context - DistributedSessions are DISABLED);
+}
+ }
+
Logger _log;
JBossWebApplicationContext _context;
- // CoarseHttpSessionHome _home;
+ CoarseHttpSessionHome _home;
DistributedSessionManager(JBossWebApplicationContext context)
{
@@ -37,10 +69,71 @@
_context=context;
_log= Logger.getLogger(getClass().getName()+# +_context.getContextPath());
+
+try
+{
+ if (_jndiContext!=null)
+ {
+ Object o=_jndiContext.lookup(ejb/jetty/CoarseHttpSession); // TODO -
parameterise
+ _home=(CoarseHttpSessionHome)PortableRemoteObject.narrow(o,
CoarseHttpSessionHome.class);
+ _log.info(Support for Distributed HttpSessions loaded: +_home);
+ }
+}
+catch (NamingException e)
+{
+ _log.warn(WARNING: Support for Distributed HttpSessions does not appear to
be loaded);
+}
+ }
+
+ public HttpSession
+getHttpSession(String id)
+ {
+// 1. check local store
+HttpSession s = (HttpSession)_sessions.get(id);
+
+// 2. check distributed store
+if (s==null _home!=null)
+{
+ try
+ {
+ CoarseHttpSession ejb=_home.findByPrimaryKey(id);
+ s=new DistributedSession(id, ejb);
+ }
+ catch (RemoteException e)
+ {
+ }
+ catch (FinderException e)
+ {
+ }
+ catch (Exception e)
+ {
+ }
+}
+
+return s;
+ }
+
+ // we have to create a DistributedSession instead of a standard Session
+ public synchronized HttpSession
+newHttpSession()
+ {
+DistributedSession session = new DistributedSession();
+session.setMaxInactiveInterval(_dftMaxIdleSecs);
+_sessions.put(session.getId(),session);
+
+for(int i=0;i_sessionListeners.size();i++)
+ ((HttpSessionListener)_sessionListeners.get(i))
+ .sessionCreated(session.getHttpSessionEvent());
+return session;
}
- // public HttpSession getHttpSession(String id) {}
- // public synchronized HttpSession newHttpSession() {}
+ // {
+ // HttpSession
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty/ejb CoarseHttpSessionBean.java
User: jules_gosnell
Date: 02/01/04 10:21:15
Modified:jetty/src/main/org/jboss/jetty/ejb
CoarseHttpSessionBean.java
Log:
first cut of distributed HttpSession stuff
Revision ChangesPath
1.2 +92 -44
contrib/jetty/src/main/org/jboss/jetty/ejb/CoarseHttpSessionBean.java
Index: CoarseHttpSessionBean.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/ejb/CoarseHttpSessionBean.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CoarseHttpSessionBean.java2002/01/03 20:51:05 1.1
+++ CoarseHttpSessionBean.java2002/01/04 18:21:15 1.2
@@ -9,15 +9,16 @@
import javax.ejb.RemoveException;
import org.apache.log4j.Category;
import org.jboss.jetty.interfaces.CoarseHttpSession;
+import org.jboss.jetty.interfaces.CoarseHttpSessionData;
/**
* The Entity bean represents an HttpSession.
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
* @ejb:bean name=jetty/CoarseHttpSession type=CMP
jndi-name=ejb/jetty/CoarseHttpSession primkey-field=id
- * @ejb:pk class=java.lang.Integer
+ * @ejb:pk class=java.lang.String
*
* @jboss:table-name Jetty_CoarseHttpSession
* @jboss:create-table true
@@ -36,22 +37,22 @@
// Home
//
-// /**
-//* Transfer money
-//*
-//* @ejb:home-method
-//*/
-// public void ejbHomeTransfer(HttpSession from, HttpSession to, float amount)
-// {
-// try
-// {
-// from.withdraw(amount);
-// to.deposit(amount);
-// } catch (java.rmi.RemoteException e)
-// {
-// throw new EJBException(e);
-// }
-// }
+ // /**
+ //* Transfer money
+ //*
+ //* @ejb:home-method
+ //*/
+ // public void ejbHomeTransfer(HttpSession from, HttpSession to, float amount)
+ // {
+ // try
+ // {
+ // from.withdraw(amount);
+ // to.deposit(amount);
+ // } catch (java.rmi.RemoteException e)
+ // {
+ // throw new EJBException(e);
+ // }
+ // }
//
// Lifecycle
@@ -63,12 +64,13 @@
* @ejb:create-method
* @ejb:permission role-name=Administrator
*/
- public Integer ejbCreate(Integer id)
+ public Integer ejbCreate(CoarseHttpSessionData data)
throws CreateException
{
-_log.info(ejbCreate(+id+));
+_log.info(ejbCreate(+data.getId()+));
-setId(id);
+setId(data.getId());
+setData(data);
return null;
}
@@ -77,10 +79,10 @@
* Create httpSession.
*
*/
- public void ejbPostCreate(Integer id)
+ public void ejbPostCreate(CoarseHttpSessionData data)
throws CreateException
{
-_log.info(ejbPostCreate(+id+));
+_log.info(ejbPostCreate(+data.getId()+));
}
public void
@@ -140,7 +142,7 @@
*
* @jboss:column-name pk
*/
- public abstract Integer getId();
+ public abstract String getId();
/**
* @ejb:pk-field
@@ -148,7 +150,7 @@
*
* @jboss:column-name pk
*/
- public abstract void setId(Integer id);
+ public abstract void setId(String id);
//
// Attributes
@@ -219,23 +221,69 @@
setAttributes(attrs);
}
-// /**
-//* Generated bulk accessor.
-//*
-//* Not remote, but could be.
-//*
-//*/
-// public abstract void setData(HttpSessionData data);
-//
-// /**
-//* Generated bulk accessor.
-//*
-//* This is set as remote to allow clients to
-//* get all data in one call.
-//*
-//* @ejb:interface-method
-//* @ejb:permission role-name=Administrator
-//* @ejb:transaction type=Supports
-//*/
-// public abstract HttpSessionData getData();
+ //
+ // CreationTime
+
+ /**
+ * @ejb:interface-method
+ * @ejb:persistent-field
+ * @ejb:transaction type=Supports
+ */
+ public abstract long getCreationTime();
+
+ /**
+ * @ejb:interface-method
+ * @ejb:persistent-field
+ * @ejb:transaction type=Supports
+ */
+ public abstract void setCreationTime(long creationTime);
+
+ //
+ // LastAccessedTime
+
+ /**
+ * @ejb:interface-method
+ * @ejb:persistent-field
+ * @ejb:transaction type=Supports
+ */
+ public abstract long getLastAccessedTime();
+
+ /**
+ * @ejb:interface-method
+ * @ejb:persistent-field
+ * @ejb:transaction type=Supports
+ */
+ public abstract void setLastAccessedTime(long lastAccessedTime);
[JBoss-dev] RE: TR: one more thing
Hello Julian, I had the idea from Marc that I would write a CMP bean, and you would provide a clever CMP implementation which would be of benefit not just to HttpSessions, but to anyone with similar requirements. You are right. But then, I did a CMP bean and a JMX service you could use to make things more abstracted (i.e. subject to modifications without impacting the jetty side any more) Thus I figured I would write the bean and then work with you to swap the CMP implementation as a later optimisation. Right, but I put the turbo ;) It looks like a misunderstanding. yes. I will go back and reread your mails. great. It should be trivial to unplug my CMP bean and replace it with your store. sure. But in my case, you should simply use the JMX service which has about 3 methods: - getSession - setSession - removeSession Yours to see ;) cheers, Sacha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MinimumSize ignored in AbstractInstancePool?
Why is MinimumSize a required sub-element of container-pool-conf when AbstractInstancePool doesn't even look at it? Could we a) make it optional and b) implement it? When MinimumSize is present, it should populate the pool with the minimum amount of instances. A simple loop over minSize with pool.push(get()); should do it. Thanks, Michael ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] standardjbosscmp-jdbc.xml
Could someone please add the numeric type to PostgreSQL in standardjbosscmp-jdbc.xml mapping java-typejava.math.BigDecimal/java-type jdbc-typeNUMERIC/jdbc-type sql-typeNUMERIC/sql-type /mapping ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MinimumSize ignored in AbstractInstancePool?
Should use add() instead of pool.push(get());. Just now discovered that method. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 3:33 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] MinimumSize ignored in AbstractInstancePool? Why is MinimumSize a required sub-element of container-pool-conf when AbstractInstancePool doesn't even look at it? Could we a) make it optional and b) implement it? When MinimumSize is present, it should populate the pool with the minimum amount of instances. A simple loop over minSize with pool.push(get()); should do it. Thanks, Michael ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] more jmx domain structure
I agree that we probably don't want to expose the configuration of the primary kernel services, but it would be nice if we could not hard code them still. Perhaps a helper object which would take the servers default domain and then use that to construct the actual object name for these components. Ahhh... but then that object would need a reference to the server and components a reference to the helper. If the helper was static then it would be forced to find a server which might not return the correct server if there were more than one. Could have the helper take the server from the component and use that to generate names. Doesn't really seem worth it though... not sure. I would prefer scoped names, but in short of that, why not expose the kernel names via config? Most of this would be done in jboss-serivce.xml or in core kernel components so I would not expect users to have to or want to change those. ... --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of marc fleury Sent: Friday, January 04, 2002 6:44 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] more jmx domain structure Does this mean that there are hard-coded references between mbeans? I think it would be a good idea to convert these to depends elements in the mbean configuration (formerly mbean-ref elements) to make these dependencies more explicit. What do you think? Good and bad, don't make it a default (which is what I am reading here). The truth is that while we use JMX to loosely create and configure objects, some islands of objects just live together should we hardcode the links in there (inside the island) or should we expose these links *at the same level of management as we do the rest of the configuration*? the answer is no.. don't, keep the real configuration (that that will change) configurable. These links are explicit in normal java code as we compile against them and pass reference. In JMX we configure objectnames as string, but the fact is that the code flow is mostly always the same and (for example) an EJBDeployer and a SARDeployer will always use the MainDeployer (in the new deployer codebase I will commit when I get back to Atlanta). Should we expose that reference for *users* to see and configure? *NO* Hardcoding JMX Object Names references (through the use of MyInterface.OBJECT_NAME as we do today) is in fact the better, more useable solution. Don't expose kernel configuration knowledge in a file that users are supposed to read and configure... marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5570 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JRMPInvokerHA - Invalid remote object?
Has the new client be checked in? I have been working off of fresh repositories each time (to make sure I haven't forgotten to check something in or add some local inconsistency). --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of marc fleury Sent: Friday, January 04, 2002 6:54 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JRMPInvokerHA - Invalid remote object? The bits have been rewritten and updated so you probably are trying to return a newer version while you still have an old version on the client. Something like that. marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6593 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] bin/privatekeys bin/BeanCacheMonitor*.jar
Is there source anywhere in cvs directly? Do they belong in bin/ or in client/? I was trying to clean up the release tree for the 3.0 release (when ever that might happen). --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of Simone Bordet Sent: Friday, January 04, 2002 1:17 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] bin/privatekeys bin/BeanCacheMonitor*.jar Hi Jason, bin/BeanCacheMonitor* are 2 client jars used to monitor bean cache activity, one through JMX and one through JMS. The JMX way is always accessible, while the JMS way must be enabled setting the proper flag in the container factory, then it's possible to get JMS messages on cache activity. It was very useful for debugging, and may be very useful to collect server performance; however they're very old, I don't know if they still work, especially the JMS one since the topics may have moved. Source code is inside the jar. Cheers Simon __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6582 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] standardjbosscmp-jdbc.xml
Done. -Original Message- From: Dave Smith [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 2:51 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] standardjbosscmp-jdbc.xml Could someone please add the numeric type to PostgreSQL in standardjbosscmp-jdbc.xml mapping java-typejava.math.BigDecimal/java-type jdbc-typeNUMERIC/jdbc-type sql-typeNUMERIC/sql-type /mapping ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default standardjbosscmp-jdbc.xml
User: dsundstrom Date: 02/01/04 14:39:47 Modified:src/etc/conf/default standardjbosscmp-jdbc.xml Log: Added BigDecimal mapping for PostgreSQL. Revision ChangesPath 1.13 +7 -2 jboss/src/etc/conf/default/standardjbosscmp-jdbc.xml Index: standardjbosscmp-jdbc.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjbosscmp-jdbc.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- standardjbosscmp-jdbc.xml 2001/12/30 19:09:39 1.12 +++ standardjbosscmp-jdbc.xml 2002/01/04 22:39:46 1.13 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: standardjbosscmp-jdbc.xml,v 1.12 2001/12/30 19:09:39 dsundstrom Exp $ -- +!-- $Id: standardjbosscmp-jdbc.xml,v 1.13 2002/01/04 22:39:46 dsundstrom Exp $ -- jbosscmp-jdbc @@ -542,11 +542,16 @@ sql-typeTIMESTAMP/sql-type /mapping mapping + java-typejava.math.BigDecimal/java-type + jdbc-typeNUMERIC/jdbc-type + sql-typeNUMERIC/sql-type + /mapping + mapping java-typejava.lang.Object/java-type jdbc-typeJAVA_OBJECT/jdbc-type sql-typeOID/sql-type /mapping - /type-mapping + /type-mapping type-mapping nameHypersonic SQL/name ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] bin/privatekeys bin/BeanCacheMonitor*.jar
Hi Jason, Is there source anywhere in cvs directly? No, the single source file is directly inside the jar; the only presence in CVS is the jar itself, that's the reason why they might be very old: they are not built. It was a simple example of how it is possible to monitor the bean cache, still useful IMHO if JBoss will provide the monitoring capability of the server. Juha was working on a nice gui for monitoring, the admin package under contrib if I remember well... Do they belong in bin/ or in client/? Well, under client/ I normally think of jars required by client to use JBoss; I did not want the users to copy these jars in their clients, thinking that they are necessary to use JBoss :) That's why they're under bin/. Maybe a better place would be examples/monitoring/. Feel free to move them. I was trying to clean up the release tree for the 3.0 release (when ever that might happen). Yes, I guessed so :) Cheers Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/invocation/jrmp/server JRMPInvoker.java
User: patriot1burke Date: 02/01/04 15:15:22 Modified:src/main/org/jboss/invocation/jrmp/server JRMPInvoker.java Log: moved some fields to protected for HA stuff Revision ChangesPath 1.3 +4 -4 jboss/src/main/org/jboss/invocation/jrmp/server/JRMPInvoker.java Index: JRMPInvoker.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/invocation/jrmp/server/JRMPInvoker.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- JRMPInvoker.java 2001/12/31 20:49:45 1.2 +++ JRMPInvoker.java 2002/01/04 23:15:22 1.3 @@ -53,7 +53,7 @@ * * @author a href=mailto:[EMAIL PROTECTED]Marc Fleury/a * -* @version $Revision: 1.2 $ +* @version $Revision: 1.3 $ */ public class JRMPInvoker @@ -84,8 +84,8 @@ protected MBeanServer server; protected ObjectName serviceName; - private int state; - private int id = 0; + protected int state; + protected int id = 0; // Static @@ -149,7 +149,7 @@ log.debug(Container Invoker Client SocketFactory='+(clientSocketFactory == null ? Default : clientSocketFactory.toString())+'); log.debug(Container Invoker Server SocketFactory='+(serverSocketFactory == null ? Default : serverSocketFactory.toString())+'); log.debug(Container Invoker Server SocketAddr='+(serverAddress == null ? Default : serverAddress)+'); - + log.info(created); } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/invocation/jrmp/server JRMPInvokerHA.java
User: patriot1burke
Date: 02/01/04 15:16:37
Modified:src/main/org/jboss/invocation/jrmp/server JRMPInvokerHA.java
Log:
don't bind invoker to JNDI and override start and stop methods
Revision ChangesPath
1.2 +53 -0
jbossmx/src/main/org/jboss/invocation/jrmp/server/JRMPInvokerHA.java
Index: JRMPInvokerHA.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/invocation/jrmp/server/JRMPInvokerHA.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JRMPInvokerHA.java2001/12/31 20:43:30 1.1
+++ JRMPInvokerHA.java2002/01/04 23:16:37 1.2
@@ -6,6 +6,8 @@
*/
package org.jboss.invocation.jrmp.server;
+import java.rmi.ServerException;
+
import javax.naming.InitialContext;
import javax.management.ObjectName;
import javax.management.MBeanException;
@@ -35,7 +37,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED]Bill Burke/a
*
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class JRMPInvokerHA
@@ -89,6 +91,57 @@
}
// Public
+
+ public void start()
+ throws Exception
+ {
+ if (getState() != STOPPED getState() != FAILED)
+ return;
+
+ state = STARTING;
+ log.info(Starting);
+
+ try
+ {
+ // Export CI
+ exportCI();
+ }
+ catch (Exception e)
+ {
+ state = FAILED;
+ log.error(Failed, e);
+ throw new ServerException(Could not bind HA JRMP invoker, e);
+ }
+
+ state = STARTED;
+ log.info(Started);
+ }
+
+ public void stop()
+ {
+ if (getState() != STARTED)
+ return;
+
+ state = STOPPING;
+ log.info(Stopping);
+
+ try
+ {
+ unexportCI();
+ }
+ catch (Throwable e)
+ {
+ state = FAILED;
+ log.error(Failed, e);
+ return;
+ }
+ state = STOPPED;
+ log.info(Stopped);
+ }
+
+ public void destroy()
+ {
+ }
// Package protected -
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-499624 ] if wrapped log.debug() calls
Patches item #499624, was opened at 2002-01-04 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=499624group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Scott Sanders (stonecobra) Assigned to: Nobody/Anonymous (nobody) Summary: if wrapped log.debug() calls Initial Comment: on the jboss-all module, I updated the log.debug() calls to bew wrapped with an if (log.isDebugEnabled()). I did not do the jetty directory or the jbossmx directory. The patch is a zipped copy of the output from cvs diff -u Scott Sanders -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=499624group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] bin/privatekeys bin/BeanCacheMonitor*.jar
I would prefer to drop this as the JMS monitoring is not being maintained, is not implemented consistently across all interceptors, and unecessarily propagates a dependency on JMS. A better way to achieve the same effect is to use trace level logging with the statistics objects as the msg and use a JMS appender to collect this information. - Original Message - From: Bordet, Simone [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 04, 2002 2:43 PM Subject: RE: [JBoss-dev] bin/privatekeys bin/BeanCacheMonitor*.jar Hi Jason, Is there source anywhere in cvs directly? No, the single source file is directly inside the jar; the only presence in CVS is the jar itself, that's the reason why they might be very old: they are not built. It was a simple example of how it is possible to monitor the bean cache, still useful IMHO if JBoss will provide the monitoring capability of the server. Juha was working on a nice gui for monitoring, the admin package under contrib if I remember well... Do they belong in bin/ or in client/? Well, under client/ I normally think of jars required by client to use JBoss; I did not want the users to copy these jars in their clients, thinking that they are necessary to use JBoss :) That's why they're under bin/. Maybe a better place would be examples/monitoring/. Feel free to move them. I was trying to clean up the release tree for the 3.0 release (when ever that might happen). Yes, I guessed so :) Cheers Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server DistributedReplicantManagerImpl.java HAPartitionImpl.java HARMIServerImpl.java
User: ejort
Date: 02/01/04 17:12:46
Modified:src/main/org/jboss/ha/framework/server
DistributedReplicantManagerImpl.java
HAPartitionImpl.java HARMIServerImpl.java
Log:
Guarded debug logging.
Revision ChangesPath
1.10 +4 -3
jbossmx/src/main/org/jboss/ha/framework/server/DistributedReplicantManagerImpl.java
Index: DistributedReplicantManagerImpl.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/DistributedReplicantManagerImpl.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- DistributedReplicantManagerImpl.java 2001/11/26 12:24:07 1.9
+++ DistributedReplicantManagerImpl.java 2002/01/05 01:12:46 1.10
@@ -27,7 +27,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a.
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a.
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*
* pbRevisions:/bbr
* pb2001/10/31: marcf/b
@@ -336,7 +336,8 @@
return;
}
- log.debug(notifying + listeners.size() + listeners for key change:
+ key);
+ if (log.isDebugEnabled())
+ log.debug(notifying + listeners.size() + listeners for key change:
+ key);
for (int i = 0; i listeners.size(); i++)
{
DistributedReplicantManager.ReplicantListener listener =
(DistributedReplicantManager.ReplicantListener)listeners.get(i);
@@ -344,7 +345,7 @@
}
}
}
-
+
// Group membership API
1.13 +4 -3
jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java
Index: HAPartitionImpl.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- HAPartitionImpl.java 2001/12/31 20:40:50 1.12
+++ HAPartitionImpl.java 2002/01/05 01:12:46 1.13
@@ -33,7 +33,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a.
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a.
- * @version $Revision: 1.12 $
+ * @version $Revision: 1.13 $
*
* pbRevisions:/bbr
*/
@@ -136,7 +136,7 @@
// Update the initial view id
//
this.currentViewId = view.GetVid().GetId();
-
+
// We must now syncrhonize new state transfer subscriber
//
boolean rc = channel.GetState(null, 8000);
@@ -183,7 +183,8 @@
{
String key = (String)keys.next();
HAPartition.HAPartitionStateTransfer subscriber =
(HAPartition.HAPartitionStateTransfer)stateHandlers.get(key);
-log.debug(GetState for + key);
+if (log.isDebugEnabled())
+ log.debug(GetState for + key);
state.put(key, subscriber.getCurrentState());
}
return state;
1.12 +3 -2
jbossmx/src/main/org/jboss/ha/framework/server/HARMIServerImpl.java
Index: HARMIServerImpl.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/HARMIServerImpl.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- HARMIServerImpl.java 2002/01/03 04:00:52 1.11
+++ HARMIServerImpl.java 2002/01/05 01:12:46 1.12
@@ -33,7 +33,7 @@
*
* @author [EMAIL PROTECTED]
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.11 $
+ * @version $Revision: 1.12 $
*
* pbRevisions:/bbr
* pb2001/11/09: Sacha Labourey/b
@@ -199,7 +199,8 @@
public void replicantsChanged(String key, ArrayList newReplicants)
{
- log.debug(replicantsChanged ' + key + ' to + newReplicants.size());
+ if (log.isDebugEnabled())
+log.debug(replicantsChanged ' + key + ' to + newReplicants.size());
synchronized(replicants)
{
// client has reference to replicants so it will automatically get
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/jndi HANamingService.java
User: ejort
Date: 02/01/04 17:12:46
Modified:src/main/org/jboss/ha/jndi HANamingService.java
Log:
Guarded debug logging.
Revision ChangesPath
1.19 +3 -2 jbossmx/src/main/org/jboss/ha/jndi/HANamingService.java
Index: HANamingService.java
===
RCS file: /cvsroot/jboss/jbossmx/src/main/org/jboss/ha/jndi/HANamingService.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- HANamingService.java 2001/12/31 20:44:58 1.18
+++ HANamingService.java 2002/01/05 01:12:46 1.19
@@ -38,7 +38,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
* @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a
- * @version $Revision: 1.18 $
+ * @version $Revision: 1.19 $
*
* pbRevisions:/bbr
* pb2001/11/19 bill burke:/b
@@ -374,7 +374,8 @@
try
{
DatagramPacket p = new DatagramPacket (ipAddress, ipAddress.length,
packet.getAddress(), packet.getPort());
-log.debug(Sending AutomaticDiscovery answer: + p);
+if (log.isDebugEnabled())
+ log.debug(Sending AutomaticDiscovery answer: + p);
socket.send (p);
log.debug(AutomaticDiscovery answer sent.);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/mq/il/ha HAServerILService.java
User: ejort
Date: 02/01/04 17:12:46
Modified:src/main/org/jboss/mq/il/ha HAServerILService.java
Log:
Guarded debug logging.
Revision ChangesPath
1.5 +5 -4 jbossmx/src/main/org/jboss/mq/il/ha/HAServerILService.java
Index: HAServerILService.java
===
RCS file: /cvsroot/jboss/jbossmx/src/main/org/jboss/mq/il/ha/HAServerILService.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- HAServerILService.java2001/11/12 05:32:00 1.4
+++ HAServerILService.java2002/01/05 01:12:46 1.5
@@ -26,7 +26,7 @@
* object to make the object HA via the jboss cluster.
*
* @author Hiram Chirino ([EMAIL PROTECTED])
- * @version$Revision: 1.4 $
+ * @version$Revision: 1.5 $
*/
public class HAServerILService extends org.jboss.mq.il.ServerILJMXService
implements HAServerILServiceMBean {
@@ -95,8 +95,9 @@
serverIL.setHaServerILProxy(serverILProxy);
bindJNDIReferences();
-
- log.debug(HAServerILProxy= + serverILProxy);
+
+ if (log.isDebugEnabled())
+log.debug(HAServerILProxy= + serverILProxy);
}
/**
@@ -148,4 +149,4 @@
this.loadBalancePolicy = loadBalancePolicy;
}
-}
\ No newline at end of file
+}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 258 Successful tests: 256 Errors:0 Failures: 2 [time of test: 5 January 2002 2:52 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource ConnectionManagerFactoryLoader.java
User: ejort
Date: 02/01/04 18:51:02
Modified:src/main/org/jboss/resource
ConnectionManagerFactoryLoader.java
Log:
Guarded debug logging
Revision ChangesPath
1.10 +3 -2
jbosscx/src/main/org/jboss/resource/ConnectionManagerFactoryLoader.java
Index: ConnectionManagerFactoryLoader.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/ConnectionManagerFactoryLoader.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ConnectionManagerFactoryLoader.java 2001/11/26 03:24:52 1.9
+++ ConnectionManagerFactoryLoader.java 2002/01/05 02:51:02 1.10
@@ -36,7 +36,7 @@
*
* @author Toby Allsopp ([EMAIL PROTECTED])
* @author a href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version$Revision: 1.9 $
+ * @version$Revision: 1.10 $
*/
public class ConnectionManagerFactoryLoader
extends ServiceMBeanSupport
@@ -200,7 +200,8 @@
Hashtable environment)
{
// Return the connection manager factory with the requested name
- log.debug(ConnectionManagerLoader.getObjectInstance, name = ' +
+ if (log.isDebugEnabled())
+ log.debug(ConnectionManagerLoader.getObjectInstance, name = ' +
name + ');
synchronized (cmfs)
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - kill -9 See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] more jmx domain structure
on 04-01-2 23.28, Jason Dillon at [EMAIL PROTECTED] wrote: I would not expect users to have to or want to change those. I think this defines well the semantic func going on ... I am a user ( proud user, that is ( ... ) ( so are U ( ...( proud that is ) ) ) ... ) ... I am a dev ... I am I ... sematics ... lets use ( ... ) in a market drive ... instead of ... in a *censor* ... Yoprs ... or how U like spel it ... while meaning is the same ... /peter_f Languages task specifies which language resources should get included in the installer. By default, all Core and Western languages (Latin languages) are built into the installer. (Note: To build installers for Eastern languages, you must make sure you are bundling an internationalized virtual machine with your installer. See the InstallAnywhere Users' Guide for additional information.) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] more jmx domain structure
Yah that's it... or not... can't really tell. I have no clue what this means. --jason -Original Message- From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 7:03 PM To: Jason Dillon; 'marc fleury'; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] more jmx domain structure on 04-01-2 23.28, Jason Dillon at [EMAIL PROTECTED] wrote: I would not expect users to have to or want to change those. I think this defines well the semantic func going on ... I am a user ( proud user, that is ( ... ) ( so are U ( ...( proud that is ) ) ) ... ) ... I am a dev ... I am I ... sematics ... lets use ( ... ) in a market drive ... instead of ... in a *censor* ... Yoprs ... or how U like spel it ... while meaning is the same ... /peter_f Languages task specifies which language resources should get included in the installer. By default, all Core and Western languages (Latin languages) are built into the installer. (Note: To build installers for Eastern languages, you must make sure you are bundling an internationalized virtual machine with your installer. See the InstallAnywhere Users' Guide for additional information.) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] more jmx domain structure
I have two possibly relevant ideas: 1. I think there are only a few object names it is reasonable to hardcode - such as ServiceController. If we adopted the idea of creating namespaces by including a namespace=xxx attribute in every object name, the appropriate e.g. ServiceController object name can be constructed from a hardcoded name (missing the namespace attribute) by including the namespace from the current mbean. This kind of equates namespace with jboss instance in a vm, in case you want to have several jboss instances running in the same vm. 2. Maybe a proliferation of depends tags could be sidestepped by an alternate xml config structure -- where mbean confs could be nested instead of having refs. So instead of mbean code=... name=jboss.example:name=example1 /mbean mbean code=... name=jboss.example:name=example2 depends optional-attribute-name=parentjboss.example:name=example1/depends /mbean we'd have mbean code=... name=jboss.example:name=example1 mbean code=... name=jboss.example:name=example2 /mbean /mbean David Jencks n 2002.01.04 17:28:32 -0500 Jason Dillon wrote: I agree that we probably don't want to expose the configuration of the primary kernel services, but it would be nice if we could not hard code them still. Perhaps a helper object which would take the servers default domain and then use that to construct the actual object name for these components. Ahhh... but then that object would need a reference to the server and components a reference to the helper. If the helper was static then it would be forced to find a server which might not return the correct server if there were more than one. Could have the helper take the server from the component and use that to generate names. Doesn't really seem worth it though... not sure. I would prefer scoped names, but in short of that, why not expose the kernel names via config? Most of this would be done in jboss-serivce.xml or in core kernel components so I would not expect users to have to or want to change those. ... --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of marc fleury Sent: Friday, January 04, 2002 6:44 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] more jmx domain structure Does this mean that there are hard-coded references between mbeans? I think it would be a good idea to convert these to depends elements in the mbean configuration (formerly mbean-ref elements) to make these dependencies more explicit. What do you think? Good and bad, don't make it a default (which is what I am reading here). The truth is that while we use JMX to loosely create and configure objects, some islands of objects just live together should we hardcode the links in there (inside the island) or should we expose these links *at the same level of management as we do the rest of the configuration*? the answer is no.. don't, keep the real configuration (that that will change) configurable. These links are explicit in normal java code as we compile against them and pass reference. In JMX we configure objectnames as string, but the fact is that the code flow is mostly always the same and (for example) an EJBDeployer and a SARDeployer will always use the MainDeployer (in the new deployer codebase I will commit when I get back to Atlanta). Should we expose that reference for *users* to see and configure? *NO* Hardcoding JMX Object Names references (through the use of MyInterface.OBJECT_NAME as we do today) is in fact the better, more useable solution. Don't expose kernel configuration knowledge in a file that users are supposed to read and configure... marcf __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=5570 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - kill -9 See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 258 Successful tests: 257 Errors:0 Failures: 1 [time of test: 5 January 2002 3:23 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Shutdown - NOT The Automated message
Hi, Since yesterday the automated testsuite won't shutdown again. The problem is org.jboss.Shutdown no longer lives in lib/ext/jboss.jar it is now only in bin/shutdown.jar The classpath in jboss_init_redhat.sh needs updating. I'd do this myself, but if somebody already has the /usr/local/jdk and /usr/local/jboss already configured it might be easier for them to test it. :-) Regards, Adrian __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6656 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 258 Successful tests: 257 Errors:0 Failures: 1 [time of test: 5 January 2002 4:11 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - kill -9 See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 258 Successful tests: 257 Errors:0 Failures: 1 [time of test: 5 January 2002 5:3 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss org.jboss.Shutdown does not work
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE Hello, The org.jboss.Shutdown class does not seem to work. That is, the jboss_redhat_init.sh script called it and the jboss server did not stop... Please could we get this fixed... Or tell me what I should be calling to get the server shutdown... Now I will return to the old faithful method - kill -9 See ya, Chris PS This is automated - just to make it really annoying... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/bin jboss_init_redhat.sh
User: user57
Date: 02/01/04 21:16:22
Modified:src/bin jboss_init_redhat.sh
Log:
o changed classpath for using Shutdown to bin/shutdown.jar
Revision ChangesPath
1.5 +1 -1 jboss/src/bin/jboss_init_redhat.sh
Index: jboss_init_redhat.sh
===
RCS file: /cvsroot/jboss/jboss/src/bin/jboss_init_redhat.sh,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- jboss_init_redhat.sh 2001/12/10 09:38:14 1.4
+++ jboss_init_redhat.sh 2002/01/05 05:16:22 1.5
@@ -29,7 +29,7 @@
JAVAPTH=${JAVAPTH:-/usr/local/jdk/bin}
#define the classpath for the shutdown class
-JBOSSCP=${JBOSSCP:-$JBOSS_HOME/lib/ext/jboss.jar}
+JBOSSCP=${JBOSSCP:-$JBOSS_HOME/bin/shutdown.jar}
#define the script to use to start jboss
JBOSSSH=${JBOSSSH:-$JBOSS_HOME/bin/run.sh}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java PersistenceManager.java
User: ejort
Date: 02/01/04 22:38:13
Modified:src/main/org/jboss/mq/pm/file CacheStore.java
PersistenceManager.java
Log:
Guarded debug logging
Revision ChangesPath
1.3 +7 -4 jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java
Index: CacheStore.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- CacheStore.java 2002/01/03 04:00:53 1.2
+++ CacheStore.java 2002/01/05 06:38:13 1.3
@@ -25,7 +25,7 @@
* This class manages the persistence needs of the MessageCache
*
* @author Hiram Chirino
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
public class CacheStore extends ServiceMBeanSupport implements
org.jboss.mq.pm.CacheStore, CacheStoreMBean {
String dataDirectory;
@@ -95,10 +95,12 @@
* This gets called to start the service.
*/
protected void startService() throws Exception {
+ boolean debug = log.isDebugEnabled();
log.warn(using jboss.system.home property);
File jbossHome = new File(System.getProperty(jboss.system.home));
dataFile = new File(jbossHome, dataDirectory);
- log.debug(Data directory set to: + dataFile.getCanonicalPath());
+ if (debug)
+ log.debug(Data directory set to: + dataFile.getCanonicalPath());
dataFile.mkdirs();
if (!dataFile.isDirectory())
@@ -106,7 +108,8 @@
// Clean out the directory of any previous files.
File files[] = dataFile.listFiles();
- log.debug(Removing + files.length + file(s) from: +
dataFile.getCanonicalPath());
+ if (debug)
+ log.debug(Removing + files.length + file(s) from: +
dataFile.getCanonicalPath());
for (int i = 0; i files.length; i++) {
files[i].delete();
}
@@ -120,4 +123,4 @@
return this;
}
-}
\ No newline at end of file
+}
1.14 +25 -27jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- PersistenceManager.java 2002/01/03 04:00:53 1.13
+++ PersistenceManager.java 2002/01/05 06:38:13 1.14
@@ -6,14 +6,6 @@
*/
package org.jboss.mq.pm.file;
-
-
-
-
-
-
-
-
import java.io.File;
import java.io.FileFilter;
import java.io.IOException;
@@ -45,7 +37,7 @@
* persistence.
*
* @author Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.13 $
+ * @version$Revision: 1.14 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager
{
@@ -172,6 +164,8 @@
*/
private void restoreTransactions() throws javax.jms.JMSException
{
+ boolean debug = log.isDebugEnabled();
+
TreeSet txs = new TreeSet();
File[] transactFiles = dataDirFile.listFiles();
int queueNameOffset = dataDirFile.toString().length()+1;
@@ -180,12 +174,12 @@
for (int i = 0; i transactFiles.length; i++)
{
// Set up a messageLog for each queue data directory.
-if( transactFiles[i].isDirectory() )
+if( transactFiles[i].isDirectory() )
{
String dirName = transactFiles[i].toString();
String key = dirName.substring(queueNameOffset);
- MessageLog log = new MessageLog(messageCache, transactFiles[i]);
- LogInfo info = new LogInfo(log, null);
+ MessageLog msgLog = new MessageLog(messageCache, transactFiles[i]);
+ LogInfo info = new LogInfo(msgLog, null);
synchronized (messageLogs)
{
messageLogs.put(key, info);
@@ -193,7 +187,7 @@
transactFiles[i] = null;
continue;
}
-
+
try
{
Long tx = new Long(Long.parseLong(transactFiles[i].getName()));
@@ -227,11 +221,12 @@
clone = (HashMap)messageLogs.clone();
}
- for (Iterator i = clone.keySet().iterator(); i.hasNext();)
+ for (Iterator i = clone.keySet().iterator(); i.hasNext();)
{
Object key = i.next();
LogInfo logInfo = (LogInfo)clone.get(key);
- log.debug(Recovered messages destined for: +key);
+ if (debug)
+log.debug(Recovered messages destined for: +key);
[JBoss-dev] CVS update: contrib/varia/src/main/org/jboss/jdo/castor CastorJDOImpl.java
User: ejort
Date: 02/01/04 22:39:42
Modified:varia/src/main/org/jboss/jdo/castor CastorJDOImpl.java
Log:
Guarded debug logging
Revision ChangesPath
1.9 +25 -12contrib/varia/src/main/org/jboss/jdo/castor/CastorJDOImpl.java
Index: CastorJDOImpl.java
===
RCS file:
/cvsroot/jboss/contrib/varia/src/main/org/jboss/jdo/castor/CastorJDOImpl.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CastorJDOImpl.java2001/12/07 15:50:55 1.8
+++ CastorJDOImpl.java2002/01/05 06:39:42 1.9
@@ -48,7 +48,7 @@
* Castor JDO support
*
* @author Oleg Nitz ([EMAIL PROTECTED])
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
public class CastorJDOImpl extends ServiceMBeanSupport
implements DataObjects, ObjectFactory, Referenceable, Serializable,
@@ -103,6 +103,8 @@
int pos;
Method m;
+boolean debug = log.isDebugEnabled();
+
// Bind in JNDI
bind(new InitialContext(), java:/ + _jndiName, this);
@@ -124,7 +126,8 @@
new Class[] {boolean.class});
m.invoke(_jdo, new Object[] {new Boolean(_autoStore)});
} catch (Exception ex) {
-log.debug(couldn't invoke setAutoStore());
+if (debug)
+ log.debug(couldn't invoke setAutoStore());
}
try {
@@ -133,10 +136,12 @@
new Class[] {boolean.class});
m.invoke(_jdo, new Object[] {new Boolean(_dbPooling)});
} catch (Exception ex) {
-log.debug(couldn't invoke setDatabasePooling());
+if (debug)
+ log.debug(couldn't invoke setDatabasePooling());
}
_instances.put(_jndiName, this);
-log.debug(DataObjects factory for + _dataSourceName + bound to +
_jndiName);
+if (debug)
+ log.debug(DataObjects factory for + _dataSourceName + bound to +
_jndiName);
}
public void stopService() {
@@ -281,43 +286,51 @@
// LogInterceptor implementation for Castor 0.8 --
public void loading(Class objClass, Object identity) {
-log.debug( Loading + objClass.getName() + ( + identity + ) );
+if (log.isDebugEnabled())
+ log.debug( Loading + objClass.getName() + ( + identity + ) );
}
public void creating(Class objClass, Object identity) {
-log.debug( Creating + objClass.getName() + ( + identity + ) );
+if (log.isDebugEnabled())
+ log.debug( Creating + objClass.getName() + ( + identity + ) );
}
public void removing(Class objClass, Object identity) {
-log.debug( Removing + objClass.getName() + ( + identity + ) );
+if (log.isDebugEnabled())
+ log.debug( Removing + objClass.getName() + ( + identity + ) );
}
public void storing(Class objClass, Object identity) {
-log.debug( Storing + objClass.getName() + ( + identity + ) );
+if (log.isDebugEnabled())
+ log.debug( Storing + objClass.getName() + ( + identity + ) );
}
// LogInterceptor implementation for Castor 0.9 --
public void loading(Object objClass, Object identity) {
-log.debug( Loading + objClass + ( + identity + ) );
+if (log.isDebugEnabled())
+ log.debug( Loading + objClass + ( + identity + ) );
}
public void creating(Object objClass, Object identity) {
-log.debug( Creating + objClass + ( + identity + ) );
+if (log.isDebugEnabled())
+ log.debug( Creating + objClass + ( + identity + ) );
}
public void removing(Object objClass, Object identity) {
-log.debug( Removing + objClass + ( + identity + ) );
+if (log.isDebugEnabled())
+ log.debug( Removing + objClass + ( + identity + ) );
}
public void storing(Object objClass, Object identity) {
-log.debug( Storing + objClass + ( + identity + ) );
+if (log.isDebugEnabled())
+ log.debug( Storing + objClass + ( + identity + ) );
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server JMSServer.java MessageCache.java StateManager.java
User: ejort
Date: 02/01/04 22:38:13
Modified:src/main/org/jboss/mq/server JMSServer.java
MessageCache.java StateManager.java
Log:
Guarded debug logging
Revision ChangesPath
1.12 +9 -5 jbossmq/src/main/org/jboss/mq/server/JMSServer.java
Index: JMSServer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/JMSServer.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JMSServer.java2001/11/26 06:33:12 1.11
+++ JMSServer.java2002/01/05 06:38:13 1.12
@@ -37,7 +37,7 @@
* @authorNorbert Lataille ([EMAIL PROTECTED])
* @authorHiram Chirino ([EMAIL PROTECTED])
* @authorDavid Maplesden ([EMAIL PROTECTED])
- * @version $Revision: 1.11 $
+ * @version $Revision: 1.12 $
*/
public class JMSServer
{
@@ -691,7 +691,8 @@
*/
public synchronized Queue createQueue(ConnectionToken dc, String name) throws
JMSException
{
- log.debug(createQueue( + name + ));
+ if (log.isDebugEnabled())
+ log.debug(createQueue( + name + ));
SpyQueue newQueue = new SpyQueue(name);
if (!destinations.containsKey(newQueue))
@@ -711,7 +712,8 @@
*/
public synchronized Topic createTopic(ConnectionToken dc, String name) throws
JMSException
{
- log.debug(createTopic( + name + ));
+ if (log.isDebugEnabled())
+ log.debug(createTopic( + name + ));
SpyTopic newTopic = new SpyTopic(name);
if (!destinations.containsKey(newTopic))
@@ -729,7 +731,8 @@
*/
public synchronized void deleteTemporaryDestination(ConnectionToken dc,
SpyDestination dest)
{
- log.debug(deleteDestination(dest= + dest.toString() + ));
+ if (log.isDebugEnabled())
+ log.debug(deleteDestination(dest= + dest.toString() + ));
synchronized (destinations)
{
@@ -765,7 +768,8 @@
*/
public void addDestination(SpyDestination topic, JMSDestination queue) throws
JMSException
{
- log.debug(addDestination: + topic + , + queue);
+ if (log.isDebugEnabled())
+ log.debug(addDestination: + topic + , + queue);
if (destinations.containsKey(topic))
{
throw new JMSException(This destination already exists !);
1.12 +8 -15 jbossmq/src/main/org/jboss/mq/server/MessageCache.java
Index: MessageCache.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/MessageCache.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- MessageCache.java 2002/01/02 17:06:53 1.11
+++ MessageCache.java 2002/01/05 06:38:13 1.12
@@ -25,7 +25,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Hiram Chirino/a
* @author a href=mailto:[EMAIL PROTECTED];David Maplesden/a
- * @version$Revision: 1.11 $
+ * @version$Revision: 1.12 $
*/
public class MessageCache extends ServiceMBeanSupport implements MessageCacheMBean,
MBeanRegistration, Runnable
{
@@ -63,8 +63,7 @@
*/
public MessageReference add(SpyMessage message) throws javax.jms.JMSException
{
- if (log.isTraceEnabled())
-log.trace(add lock aquire);
+ log.trace(add lock aquire);
synchronized (this)
{
MessageReference mh = new MessageReference();
@@ -73,8 +72,7 @@
totalCacheSize++;
validateSoftReferenceDepth();
- if (log.isTraceEnabled())
- log.trace(add lock release);
+ log.trace(add lock release);
return mh;
}
}
@@ -84,15 +82,13 @@
*/
public void remove(MessageReference mr) throws JMSException
{
- if (log.isTraceEnabled())
-log.trace(remove lock aquire);
+ log.trace(remove lock aquire);
synchronized (this)
{
mr.clear();
lruCache.remove(mr);
totalCacheSize--;
- if (log.isTraceEnabled())
- log.trace(remove lock release);
+ log.trace(remove lock release);
}
}
@@ -141,8 +137,7 @@
{
// Signal to exit the thread.
}
- if (log.isDebugEnabled())
-log.debug(Thread exiting.);
+ log.debug(Thread exiting.);
}
/**
@@ -197,16 +192,14 @@
*/
synchronized public void messageReferenceUsedEvent(MessageReference mh, boolean
wasHard)
{
- if (log.isTraceEnabled())
-log.trace(messageReferenceUsedEvent lock aquire);
+ log.trace(messageReferenceUsedEvent lock aquire);
synchronized (this)
{
if (wasHard)
lruCache.makeMostRecent(mh);
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq Connection.java SpyConnectionConsumer.java
User: ejort
Date: 02/01/04 22:38:13
Modified:src/main/org/jboss/mq Connection.java
SpyConnectionConsumer.java
Log:
Guarded debug logging
Revision ChangesPath
1.15 +5 -4 jbossmq/src/main/org/jboss/mq/Connection.java
Index: Connection.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/Connection.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Connection.java 2001/12/09 05:56:36 1.14
+++ Connection.java 2002/01/05 06:38:13 1.15
@@ -36,7 +36,7 @@
*
* @authorNorbert Lataille ([EMAIL PROTECTED])
* @authorHiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
* @created August 16, 2001
*/
public class Connection implements java.io.Serializable, javax.jms.Connection
@@ -509,8 +509,9 @@
{
throw new IllegalStateException(The connection is closed);
}
-
- log.debug(SpyConnection: deleteDestination(dest= + dest.toString() + ));
+
+ if (log.isDebugEnabled())
+ log.debug(SpyConnection: deleteDestination(dest= + dest.toString() +
));
try
{
@@ -934,7 +935,7 @@
}
Subscription req = consumer.getSubscription();
- if( log.isTraceEnabled() )
+ if( log.isDebugEnabled() )
log.debug(Connection: removeSession(dest= + req.destination + ));
try
1.8 +3 -2 jbossmq/src/main/org/jboss/mq/SpyConnectionConsumer.java
Index: SpyConnectionConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyConnectionConsumer.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- SpyConnectionConsumer.java2001/12/13 15:23:19 1.7
+++ SpyConnectionConsumer.java2002/01/05 06:38:13 1.8
@@ -20,7 +20,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public class SpyConnectionConsumer
implements javax.jms.ConnectionConsumer, SpyConsumer, Runnable
@@ -222,7 +222,8 @@
if ( spySession.sessionConsumer == null )
{
- log.debug( + this + Session did not have a set MessageListner
);
+ if (log.isDebugEnabled())
+ log.debug( + this + Session did not have a set
MessageListner );
}
else
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/main/org/jboss/web/catalina EmbeddedCatalinaServiceSX.java
User: ejort
Date: 02/01/04 22:39:42
Modified:catalina/src/main/org/jboss/web/catalina
EmbeddedCatalinaServiceSX.java
Log:
Guarded debug logging
Revision ChangesPath
1.3 +16 -8
contrib/catalina/src/main/org/jboss/web/catalina/EmbeddedCatalinaServiceSX.java
Index: EmbeddedCatalinaServiceSX.java
===
RCS file:
/cvsroot/jboss/contrib/catalina/src/main/org/jboss/web/catalina/EmbeddedCatalinaServiceSX.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- EmbeddedCatalinaServiceSX.java2001/09/30 21:06:07 1.2
+++ EmbeddedCatalinaServiceSX.java2002/01/05 06:39:42 1.3
@@ -63,7 +63,7 @@
@see org.apache.catalina.startup.Embedded
@author [EMAIL PROTECTED]
- @version $Revision: 1.2 $
+ @version $Revision: 1.3 $
*/
public class EmbeddedCatalinaServiceSX extends AbstractWebContainer implements
EmbeddedCatalinaServiceSXMBean
{
@@ -183,6 +183,8 @@
public void startService() throws Exception
{
+ trace = category.isTraceEnabled();
+ debug = category.isDebugEnabled();
category.info(Starting + NAME + );
// Start create the embeded catalina container but don't let it overwrite the
thread class loader
@@ -190,18 +192,21 @@
URLClassLoader parent = cl;
while( parent != null )
{
- category.trace(parent);
+ if (trace)
+category.trace(parent);
URL[] urls = parent.getURLs();
for(int u = 0; u urls.length; u ++)
-category.trace( +urls[u]);
+if (trace)
+ category.trace( +urls[u]);
parent = (URLClassLoader) parent.getParent();
}
// Determine the catalina debug level from the enabled priority
debugLevel = 0;
- if( category.isTraceEnabled() )
+ if(trace)
debugLevel = 2;
- category.debug(Setting catalina debug level to: +debugLevel);
+ if (debug)
+ category.debug(Setting catalina debug level to: +debugLevel);
try
{
@@ -211,7 +216,8 @@
String homePath = catalinaHome.getFile();
File homeDir = new File(homePath, ../../..);
homePath = homeDir.getCanonicalPath();
- category.debug(Setting catalina.home to: + homePath);
+ if (debug)
+category.debug(Setting catalina.home to: + homePath);
System.setProperty(catalina.home, homePath);
System.setProperty(catalina.base, homePath);
initCatalina(cl);
@@ -248,7 +254,8 @@
URL url = new URL(warUrl);
WebApplication appInfo = createWebContext(ctxPath, url, webAppParser);
- category.debug(Initialized: +appInfo);
+ if (category.isDebugEnabled())
+ category.debug(Initialized: +appInfo);
return appInfo;
}
@@ -337,7 +344,8 @@
Object source = event.getSource();
if( source == context
event.getType().equals(Lifecycle.START_EVENT) )
{
- category.debug(Context.lifecycleEvent, event=+event);
+ if (category.isDebugEnabled())
+ category.debug(Context.lifecycleEvent, event=+event);
contextInit(context, appInfo, webAppParser);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/main/org/jboss/pool PoolGCThread.java
User: ejort
Date: 02/01/04 22:46:32
Modified:src/main/org/jboss/pool PoolGCThread.java
Log:
Guarded debug logging
Revision ChangesPath
1.7 +11 -7 jbosspool/src/main/org/jboss/pool/PoolGCThread.java
Index: PoolGCThread.java
===
RCS file: /cvsroot/jboss/jbosspool/src/main/org/jboss/pool/PoolGCThread.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- PoolGCThread.java 2001/12/07 03:40:39 1.6
+++ PoolGCThread.java 2002/01/05 06:46:32 1.7
@@ -29,24 +29,28 @@
}
public void run() {
- log.debug(Started gc thread);
-
+ boolean debug = log.isDebugEnabled();
+ if (debug)
+ log.debug(Started gc thread);
+
while ( true ) {
// Don't do anything while there's nothing to do
waitForPools();
- log.debug(gc thread waited for pools);
+ if (debug)
+log.debug(gc thread waited for pools);
// Figure out how long to sleep
long delay = getDelay();
- log.debug(gc thread delay: + delay);
-
+ if (debug)
+log.debug(gc thread delay: + delay);
+
// Sleep
if ( delay 0l ) {
try {
sleep( delay );
} catch ( InterruptedException ignore ) {}
}
-
+
// Run garbage collection on eligible pools
runGC();
}
@@ -96,7 +100,7 @@
if (debug) {
log.debug(gc thread running gc);
}
-
+
for ( Iterator it = pools.iterator(); it.hasNext(); ) {
ObjectPool pool = ( ObjectPool )it.next();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/main/org/jboss/web EmbeddedCatalinaServiceSX.java
User: ejort
Date: 02/01/04 22:39:41
Modified:catalina/src/main/org/jboss/web
EmbeddedCatalinaServiceSX.java
Log:
Guarded debug logging
Revision ChangesPath
1.2 +11 -5
contrib/catalina/src/main/org/jboss/web/EmbeddedCatalinaServiceSX.java
Index: EmbeddedCatalinaServiceSX.java
===
RCS file:
/cvsroot/jboss/contrib/catalina/src/main/org/jboss/web/EmbeddedCatalinaServiceSX.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- EmbeddedCatalinaServiceSX.java2001/12/12 02:27:14 1.1
+++ EmbeddedCatalinaServiceSX.java2002/01/05 06:39:41 1.2
@@ -69,7 +69,7 @@
@see org.apache.catalina.startup.Embedded
@author [EMAIL PROTECTED]
- @version $Revision: 1.1 $
+ @version $Revision: 1.2 $
*/
public class EmbeddedCatalinaServiceSX extends AbstractWebContainer implements
EmbeddedCatalinaServiceSXMBean
{
@@ -210,6 +210,8 @@
public void startService() throws Exception
{
+ debug = log.isDebugEnabled();
+
log.info(Starting + NAME + );
// Start create the embeded catalina container but don't let it overwrite the
thread class loader
@@ -228,7 +230,8 @@
debugLevel = 0;
if( log.isTraceEnabled() )
debugLevel = 2;
- log.debug(Setting catalina debug level to: +debugLevel);
+ if (debug)
+ log.debug(Setting catalina debug level to: +debugLevel);
try
{
@@ -238,7 +241,8 @@
String homePath = catalinaHome.getFile();
File homeDir = new File(homePath, ../../..);
homePath = homeDir.getCanonicalPath();
- log.debug(Setting catalina.home to: + homePath);
+ if (debug)
+log.debug(Setting catalina.home to: + homePath);
System.setProperty(catalina.home, homePath);
System.setProperty(catalina.base, homePath);
initCatalina(cl);
@@ -280,7 +284,8 @@
URL url = new URL(warUrl);
WebApplication appInfo = createWebContext(ctxPath, url, webAppParser);
- log.debug(Initialized: +appInfo);
+ if (log.isDebugEnabled())
+ log.debug(Initialized: +appInfo);
return appInfo;
}
@@ -416,7 +421,8 @@
Object source = event.getSource();
if( source == context
event.getType().equals(Lifecycle.START_EVENT) )
{
- log.debug(Context.lifecycleEvent, event=+event);
+ if (log.isDebugEnabled())
+ log.debug(Context.lifecycleEvent, event=+event);
contextInit(context, appInfo, webAppParser);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/cluster/transport/udp UDPStream.java UDPTransport.java
User: ejort
Date: 02/01/04 23:52:21
Modified:src/main/org/jboss/mq/cluster/transport/udp UDPStream.java
UDPTransport.java
Log:
Guarded debug logging
Revision ChangesPath
1.3 +3 -2
jbossmq/src/main/org/jboss/mq/cluster/transport/udp/UDPStream.java
Index: UDPStream.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/transport/udp/UDPStream.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- UDPStream.java2001/08/17 03:04:03 1.2
+++ UDPStream.java2002/01/05 07:52:21 1.3
@@ -34,7 +34,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
class UDPStream implements Runnable {
// The name this stream. Used to ease debugging.
@@ -406,7 +406,8 @@
UDPNodeId senderId = dg.getSenderId();
int id = dg.getId();
short fragmentId = dg.getFragmentId();
- cat.debug( [ + this + ] Processing datagram: + id );
+ if (cat.isDebugEnabled())
+ cat.debug( [ + this + ] Processing datagram: + id );
NodeState nodeState = getNodeState( senderId );
MessageState ds = getMessageState( nodeState, id );
1.3 +27 -13
jbossmq/src/main/org/jboss/mq/cluster/transport/udp/UDPTransport.java
Index: UDPTransport.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/transport/udp/UDPTransport.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- UDPTransport.java 2001/08/17 03:04:03 1.2
+++ UDPTransport.java 2002/01/05 07:52:21 1.3
@@ -38,7 +38,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
public class UDPTransport implements Transport {
// Receives the multicast messages
@@ -126,7 +126,8 @@
adminSocket = new DatagramSocket();
nodeId.adminPort = adminSocket.getLocalPort();
-cat.debug( [ + this + ] Local NodeId: + nodeId );
+if (cat.isDebugEnabled())
+ cat.debug( [ + this + ] Local NodeId: + nodeId );
clusterId.address = group;
clusterId.port = port;
@@ -202,7 +203,8 @@
data.length );
dg.setId( adminStream.getNextDatagramId() );
- cat.debug( [ + this + ] Sending admin datagram: + dg.getId() );
+ if (cat.isDebugEnabled())
+ cat.debug( [ + this + ] Sending admin datagram: + dg.getId() );
DatagramPacket packet = new java.net.DatagramPacket( dg.data, dg.data.length,
dest.address, dest.adminPort );
adminStream.socket.send( packet );
}
@@ -285,7 +287,9 @@
void datagramArrived( Datagram dg )
throws InterruptedException {
- cat.debug( [ + this + ] A datagram arrived );
+ boolean debug = cat.isDebugEnabled();
+ if (debug)
+ cat.debug( [ + this + ] A datagram arrived );
if ( dg.isMessageFlagsSet( Datagram.ADMIN_FLAG ) ) {
try {
@@ -300,13 +304,15 @@
ResendAdminDatagram radg = ( ResendAdminDatagram )o;
for ( int i = 0; i radg.datagramIds.length; i++ ) {
- cat.debug( [ + this + ] RESEND REQUEST ARRIVED: +
radg.datagramIds[i] );
+ if (debug)
+ cat.debug( [ + this + ] RESEND REQUEST ARRIVED: +
radg.datagramIds[i] );
resendDatagram( dg.getSenderId(), radg.datagramIds[i],
radg.broadcast );
}
} else if ( o instanceof ResendErrorAdminDatagram ) {
ResendErrorAdminDatagram readg = ( ResendErrorAdminDatagram )o;
- cat.debug( [ + this + ] RESEND REQUEST FAILED: +
readg.datagramId );
+ if (debug)
+ cat.debug( [ + this + ] RESEND REQUEST FAILED: +
readg.datagramId );
if ( readg.broadcast ) {
broadcastStream.removeFromDatagramStream( dg.getSenderId(),
readg.datagramId );
} else {
@@ -351,24 +357,29 @@
void resendDatagram( UDPNodeId requestor, int messageId, boolean broadcast )
throws InterruptedException, java.io.IOException {
+ boolean debug = cat.isDebugEnabled();
slowDownSendRate();
if ( broadcast ) {
Datagram dg = broadcastStream.getFromSentCache( messageId );
if ( dg != null ) {
-cat.debug( [ + this + ] BROADCAST RESEND REQUEST SERVICED: +
messageId );
+if (debug)
+ cat.debug( [ + this + ]
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpySession.java
User: ejort
Date: 02/01/04 23:52:20
Modified:src/main/org/jboss/mq SpySession.java
Log:
Guarded debug logging
Revision ChangesPath
1.9 +4 -4 jbossmq/src/main/org/jboss/mq/SpySession.java
Index: SpySession.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpySession.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- SpySession.java 2001/12/13 22:22:09 1.8
+++ SpySession.java 2002/01/05 07:52:20 1.9
@@ -33,7 +33,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.8 $
+ * @version$Revision: 1.9 $
*/
public abstract class SpySession
implements Session, XASession {
@@ -224,8 +224,7 @@
public synchronized void close()
throws JMSException {
- if( cat.isDebugEnabled() )
- cat.debug(Session closing.);
+ cat.debug(Session closing.);
synchronized ( runLock ) {
@@ -341,7 +340,8 @@
public void deleteTemporaryDestination( SpyDestination dest )
throws JMSException {
- cat.debug( SpySession: deleteDestination(dest= + dest.toString() + ) );
+ if (cat.isDebugEnabled())
+ cat.debug( SpySession: deleteDestination(dest= + dest.toString() + ) );
synchronized ( consumers ) {
HashSet newMap = ( HashSet )consumers.clone();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/main/org/jboss/web/catalina/security JBossSecurityMgrRealm.java
User: ejort
Date: 02/01/04 23:53:43
Modified:catalina/src/main/org/jboss/web/catalina/security
JBossSecurityMgrRealm.java
Log:
Guarded debug logging
Revision ChangesPath
1.2 +14 -6
contrib/catalina/src/main/org/jboss/web/catalina/security/JBossSecurityMgrRealm.java
Index: JBossSecurityMgrRealm.java
===
RCS file:
/cvsroot/jboss/contrib/catalina/src/main/org/jboss/web/catalina/security/JBossSecurityMgrRealm.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JBossSecurityMgrRealm.java2001/09/26 03:11:30 1.1
+++ JBossSecurityMgrRealm.java2002/01/05 07:53:43 1.2
@@ -53,7 +53,7 @@
@see org.jboss.security.SubjectSecurityManager
@author [EMAIL PROTECTED]
-@version $Revision: 1.1 $
+@version $Revision: 1.2 $
*/
public class JBossSecurityMgrRealm extends RealmBase implements Realm, Valve
{
@@ -238,6 +238,8 @@
return null;
}
+boolean debug = category.isDebugEnabled();
+
try
{
// Get the JBoss security manager from the ENC context
@@ -248,13 +250,15 @@
passwordChars = credentials.toCharArray();
if( securityMgr.isValid(principal, passwordChars) )
{
-category.debug(User: +username+ is authenticated);
+if (debug)
+ category.debug(User: +username+ is authenticated);
SecurityAssociation.setPrincipal(principal);
SecurityAssociation.setCredential(passwordChars);
}
else
{
-category.debug(User: +username+ is NOT authenticated);
+if (debug)
+ category.debug(User: +username+ is NOT authenticated);
}
}
catch(NamingException e)
@@ -287,7 +291,9 @@
*/
public boolean hasRole(Principal principal, String role)
{
- boolean hasRole = false;
+boolean debug = category.isDebugEnabled();
+
+boolean hasRole = false;
try
{
Set requiredRoles = new HashSet();
@@ -306,11 +312,13 @@
if( hasRole )
{
-category.debug(User: +principal+ is authorized);
+if (debug)
+ category.debug(User: +principal+ is authorized);
}
else
{
-category.debug(User: +principal+ is NOT authorized,
requiredRoles=+requiredRoles);
+if (debug)
+ category.debug(User: +principal+ is NOT authorized,
requiredRoles=+requiredRoles);
}
}
catch(NamingException e)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/main/org/jboss/tomcat EmbeddedTomcatServiceSX.java
User: ejort Date: 02/01/04 23:53:43 Modified:tomcat/src/main/org/jboss/tomcat EmbeddedTomcatServiceSX.java Log: Guarded debug logging Revision ChangesPath 1.4 +3 -2 contrib/tomcat/src/main/org/jboss/tomcat/EmbeddedTomcatServiceSX.java Index: EmbeddedTomcatServiceSX.java === RCS file: /cvsroot/jboss/contrib/tomcat/src/main/org/jboss/tomcat/EmbeddedTomcatServiceSX.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- EmbeddedTomcatServiceSX.java 2001/07/03 16:52:18 1.3 +++ EmbeddedTomcatServiceSX.java 2002/01/05 07:53:43 1.4 @@ -44,7 +44,7 @@ @see org.jboss.web.AbstractWebContainer @author [EMAIL PROTECTED] -@version $Revision: 1.3 $ +@version $Revision: 1.4 $ */ public class EmbeddedTomcatServiceSX extends AbstractWebContainer implements EmbeddedTomcatServiceSXMBean @@ -149,7 +149,8 @@ appInfo.setWebApp(webXml); appInfo.setJbossWeb(jbossWebXml); appInfo.setAppData(servletCtx); -category.debug(Initialized: +appInfo); +if (category.isDebugEnabled()) + category.debug(Initialized: +appInfo); return appInfo; } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/main/org/jboss/tomcat/security JBossSecurityMgrRealm.java
User: ejort
Date: 02/01/04 23:53:43
Modified:tomcat/src/main/org/jboss/tomcat/security
JBossSecurityMgrRealm.java
Log:
Guarded debug logging
Revision ChangesPath
1.9 +15 -8
contrib/tomcat/src/main/org/jboss/tomcat/security/JBossSecurityMgrRealm.java
Index: JBossSecurityMgrRealm.java
===
RCS file:
/cvsroot/jboss/contrib/tomcat/src/main/org/jboss/tomcat/security/JBossSecurityMgrRealm.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JBossSecurityMgrRealm.java2001/07/28 18:28:46 1.8
+++ JBossSecurityMgrRealm.java2002/01/05 07:53:43 1.9
@@ -37,7 +37,7 @@
@see org.jboss.security.SubjectSecurityManager
@author [EMAIL PROTECTED]
-@version $Revision: 1.8 $
+@version $Revision: 1.9 $
*/
public class JBossSecurityMgrRealm extends BaseInterceptor
{
@@ -80,6 +80,7 @@
public int authenticate(Request request, Response response)
{
+boolean debug = category.isDebugEnabled();
/* Get the username credentials from the request. We dont check
that they are null as the security domain may consider this
a valid indication of an unauthenticated user requesting
@@ -97,7 +98,7 @@
*/
ClassLoader cl = Thread.currentThread().getContextClassLoader();
ClassLoader scl = request.getContext().getServletLoader().getClassLoader();
-if( category.isDebugEnabled() )
+if (debug)
{
category.debug(Authenticating access, username: + username +
+request);
category.debug(ClassLoader: +cl.toString()+':'+cl.hashCode());
@@ -130,7 +131,8 @@
org.apache.tomcat.core.Context ctx = request.getContext();
if (ctx != null)
request.setAuthType(ctx.getAuthMethod());
-category.debug(User: +username+ is authenticated);
+if (debug)
+ category.debug(User: +username+ is authenticated);
SecurityAssociation.setPrincipal(principal);
SecurityAssociation.setCredential(passwordChars);
if( useJAAS == true securityMgr instanceof
SubjectSecurityManager )
@@ -142,7 +144,8 @@
}
else
{
-category.debug(User: +username+ is NOT authenticated);
+if (debug)
+ category.debug(User: +username+ is NOT authenticated);
}
}
catch(NamingException e)
@@ -165,10 +168,12 @@
return 0;
}
-String username = request.getRemoteUser();
+String username = request.getRemoteUser();
if( username == null )
return 401;
+boolean debug = category.isDebugEnabled();
+
/* Make sure the thread context class loader it set ot the servlet
class loader. The Jdk12Interceptor should be handling this but
it does not do it for the authenticate/authorize phases of a
@@ -176,7 +181,7 @@
*/
ClassLoader cl = Thread.currentThread().getContextClassLoader();
ClassLoader scl = request.getContext().getServletLoader().getClassLoader();
-if( category.isDebugEnabled() )
+if (debug)
{
category.debug(Authorizing access, username: + username +
+request);
category.debug(ClassLoader: +cl.toString()+':'+cl.hashCode());
@@ -209,11 +214,13 @@
// Need to get roles from the security mgr. Needs updated
interface...
String userRoles[] = {};
request.setUserRoles( userRoles );
-category.debug(User: +username+ is authorized);
+if (debug)
+ category.debug(User: +username+ is authorized);
}
else
{
-category.debug(User: +username+ is NOT authorized,
requiredRoles=+requiredRoles);
+if (debug)
+ category.debug(User: +username+ is NOT authorized,
requiredRoles=+requiredRoles);
code = 401;
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
