[JBoss-dev] JDK 1.4 is official
Well, in case no one pays attention to Sun's site. JDK 1.4.0 has been made official (Linux/Solaris/Windows). I saw a bunch of patches a while ago to fix naming problems for JDK 1.4 (assert), did those ever get fixed? Does JBoss work on 1.4 currently? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/etc/conf/default standardjbosscmp-jdbc.xml
Should we have this mapping for all DB's? Whenever I rebuild JBoss, I have to go add java.util.Date mapping myself back in. -David On Tue, 12 Feb 2002, Dain Sundstrom wrote: User: dsundstrom Date: 02/02/12 07:12:13 Modified:src/etc/conf/default standardjbosscmp-jdbc.xml Log: Added java.util.Data mapping for PostgreSQL Revision ChangesPath 1.16 +6 -1 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.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- standardjbosscmp-jdbc.xml 1 Feb 2002 01:26:58 - 1.15 +++ standardjbosscmp-jdbc.xml 12 Feb 2002 15:12:11 - 1.16 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: standardjbosscmp-jdbc.xml,v 1.15 2002/02/01 01:26:58 dsundstrom Exp $ -- +!-- $Id: standardjbosscmp-jdbc.xml,v 1.16 2002/02/12 15:12:11 dsundstrom Exp $ -- jbosscmp-jdbc @@ -531,6 +531,11 @@ java-typejava.lang.String/java-type jdbc-typeVARCHAR/jdbc-type sql-typeTEXT/sql-type +/mapping +mapping + java-typejava.util.Date/java-type + jdbc-typeTIMESTAMP/jdbc-type + sql-typeTIMESTAMP/sql-type /mapping mapping java-typejava.sql.Date/java-type ___ 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: dbudworth Date: 02/02/12 16:29:40 Modified:src/etc/conf/default standardjbosscmp-jdbc.xml Log: Added java.util.Date type mapping for Oracle7 and Oracle8 Revision ChangesPath 1.17 +11 -1 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.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- standardjbosscmp-jdbc.xml 12 Feb 2002 15:12:11 - 1.16 +++ standardjbosscmp-jdbc.xml 13 Feb 2002 00:29:40 - 1.17 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: standardjbosscmp-jdbc.xml,v 1.16 2002/02/12 15:12:11 dsundstrom Exp $ -- +!-- $Id: standardjbosscmp-jdbc.xml,v 1.17 2002/02/13 00:29:40 dbudworth Exp $ -- jbosscmp-jdbc @@ -260,6 +260,11 @@ sql-typeVARCHAR2(255)/sql-type /mapping mapping + java-typejava.util.Date/java-type + jdbc-typeTIMESTAMP/jdbc-type + sql-typeTIMESTAMP/sql-type + /mapping + mapping java-typejava.sql.Date/java-type jdbc-typeDATE/jdbc-type sql-typeDATE/sql-type @@ -357,6 +362,11 @@ java-typejava.lang.String/java-type jdbc-typeVARCHAR/jdbc-type sql-typeVARCHAR2(255)/sql-type + /mapping + mapping + java-typejava.util.Date/java-type + jdbc-typeTIMESTAMP/jdbc-type + sql-typeTIMESTAMP/sql-type /mapping mapping java-typejava.sql.Date/java-type ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] java.util.Date in PostgreSQL DB
The problem here is that java.util.Date holds an actualy time/date. If you don't map it to TIMESTAMP, then you have a dataloss. If you want a real SQL DATE field, then use java.sql.Date (which is a java.util.Date with the time suppressed) I think it would be bad policy to make the default data storage mechanism lose data upon storage. Think about: Date d = new Date(); ejb = Home.create(d); if (ejb.getDate().equals(d))// this is true doSomething(); else doSomethingElse(); ejb = Home.find(PKOFEJB); if (ejb.getDate().equals(d))// no longer true since you dropped time doSomething(); else doSomethingElse(); So you would, in effect, be breaking application logic. The user would expect both .equals() to be true. Or does PostgreSQL DATE/TIMESTAMP exactly the same? I know oracle will drop the time portion if the column type is DATE. -David On Tue, 12 Feb 2002, Adam Heath wrote: On Tue, 12 Feb 2002, Dain Sundstrom wrote: This is for anyone who knows Postgres out there, There is a patch at sf that suggest adding the following mapping: mapping java-typejava.util.Date/java-type jdbc-typeTIMESTAMP/jdbc-type sql-typeTIMESTAMP/sql-type /mapping There is currently no mapping for java.util.Date, but there is a mapping for java.sql.Date, which is: mapping java-typejava.sql.Date/java-type jdbc-typeDATE/jdbc-type sql-typeDATE/sql-type /mapping I prefer the latter. My reasoning, is that if java.util.Date is mapped to TIMESTAMP, then how does someone make a DATE in the database? They could use java.sql.Timestamp to accomplish that. This is what I have done for my debian packages. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] java.util.Date in PostgreSQL DB
Hmm, weird. Because I have actually used Date before, and had the time dropped off. Maybe it has something to do with the JDBC drivers conversion of java.util.Date - jdbc type DATE - SQL type DATE? Ohwell, it works as timestamp, so I won't worry about it for now. Thanks for the info, -David On Tue, 12 Feb 2002, Victor Langelo wrote: David Budworth wrote: Or does PostgreSQL DATE/TIMESTAMP exactly the same? I know oracle will drop the time portion if the column type is DATE. -David Actually Oracle will not drop the time protion if the column type is DATE. The following is from the Oracle 8 manual. Oracle 7 says essentially the same thing. The DATE datatype stores date and time information. Although date and time information can be represented in both CHAR and NUMBER datatypes, the DATE datatype has special associated properties. For each DATE value, Oracle stores the following information: century, year, month, day, hour, minute, and second. You need to use TRUNC(date) in order to remove the time portion (or more accurately set it to 0). --Victor ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCStartCommand.java
User: dbudworth
Date: 02/02/05 12:31:23
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCStartCommand.java
Log:
Fixed typo in log message
Revision ChangesPath
1.18 +2 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStartCommand.java
Index: JDBCStartCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStartCommand.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- JDBCStartCommand.java 2002/01/28 19:54:41 1.17
+++ JDBCStartCommand.java 2002/02/05 20:31:23 1.18
@@ -40,7 +40,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.17 $
+ * @version $Revision: 1.18 $
*/
public class JDBCStartCommand {
@@ -278,7 +278,7 @@
cmrField.getRelatedEntity().getPrimaryKeyFields());
}
} else {
- log.debug(Foreign key constaint not added as requested: +
+ log.debug(Foreign key constraint not added as requested: +
relationshipRolename= +
cmrField.getMetaData().getRelationshipRoleName());
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata JDBCRelationshipRoleMetaData.java
User: dbudworth
Date: 02/02/04 13:03:21
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCRelationshipRoleMetaData.java
Log:
Added rolename to exception being thrown when key-fields detected on a multiplicity
of many
Revision ChangesPath
1.14 +2 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCRelationshipRoleMetaData.java
Index: JDBCRelationshipRoleMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCRelationshipRoleMetaData.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- JDBCRelationshipRoleMetaData.java 2002/02/01 01:43:52 1.13
+++ JDBCRelationshipRoleMetaData.java 2002/02/04 21:03:20 1.14
@@ -23,7 +23,7 @@
* the ejb-jar.xml file's ejb-relation elements.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.14 $
*/
public final class JDBCRelationshipRoleMetaData {
/**
@@ -349,7 +349,7 @@
return Collections.EMPTY_MAP;
} else if(relationMetaData.isForeignKeyMappingStyle()
isMultiplicityMany()) {
- throw new DeploymentException(A role with multiplicity many using +
+ throw new DeploymentException(Role: +relationshipRoleName+ with
multiplicity many using +
foreign-key mapping is not allowed to have key-fields);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Is WAR deployment broken?
Maybe I missed a message about this. But I am wondering, is war deployment broken? Here is all that gets logged about the war (when inside an EAR, or when placed directly in deploy) Auto deploying: file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war New UCL with url file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war Libraries adding UnifiedClassLoader -1615549336 key URL file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war NO DEPLOYER for url file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war Watching new file: file:/home/david/proxeno/jboss/tmp/deploy/proxeno.war Done deploying proxeno.war To me this looks like the type of archive was unknown, so it will just watch, and attempt to re-deploy if it changes. But has no knowledge of the purpose of the file. With all these changes to the deployment scheme, does anyone have a short description of what is/isnot possible now. ie: Before the change, I was putting *.class in a sar, and making classless(descriptor only) EAR/war/jar. And this worked fine. Is this still possible? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] need help with deadlock detection
I don't think you can clone() a hashmap in a threadsafe way without
locking it. Of course you could sync{ clone() }, which is faster than
sync{ walk map, check for conflicts }.
Which maybe what Dain was suggesting in the first place.
-David
On Sat, 12 Jan 2002, Bill Burke wrote:
Good thought. Doesn't this make things really slow? Maybe a clone isn't so
expensive.
- Original Message -
From: Dain Sundstrom
To: 'Bill Burke' ; [EMAIL PROTECTED]
Sent: Saturday, January 12, 2002 4:12 PM
Subject: RE: [JBoss-dev] need help with deadlock detection
A thought on the performance issue.
You could copy the hash map, and then do the detection. If you detect a deadlock,
then synchronize the entire map and run it again. This way you only force a lock on
the whole map when you really think there is a deadlock.
-dain
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 12, 2002 2:33 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] need help with deadlock detection
Can somebody look at server/src/.../ejb/plugins/lock/BeanLockSupport.java and
QueuedPessimisticEJBLock.java for me? I added an application deadlock detection
algorithm and need another set of eyeballs to make sure that I didn't do anything too
drastic. Don't worry, the code is very simple.
Here are my concerns:
- could I detect phantom deadlocks?
- A static HashMap is used to store tx's that are waiting on other tx's. I
synchronize on this object whenver I do a deadlock detection. This may be a
performance hit because every thread that needs to detect for deadlock(it is waiting
on a tx) will need to synch on it. I thought it may be ok since the algorithm should
be pretty quick.
All and all this detection algorithm should greatly help out with debugging and
improve throughput of applications that have application deadlock(they won't wait for
a tx timeout, instead, the rollback will happen immediately). I really need your
concerns, comments and questions.
Thanks,
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Why are we using RollingFileAppender in RH?
I am curious, why we are using the RollingFileAppender in JBoss 3 alpha? With the amount of logging that happens by default, the log fills up very quickly, and the logfile gets rolled over. The problem is, since log4j actually renames the file, and creates a new one, any instance of tail server.log running, will still be watching the old inode (the backed up version). So you have to re-tail the file every few minutes. I understand using it for production purposes to save disk space, but in the Alpha version it seems kind of silly, and a pain to the developer trying to watch what's going on. Anyone mind if I switch it over? (just comment out the rolling stuff, so people who want it could put it back) I assume who ever made it this way was on windows, where the cygwin tail would have no problem watching the new file. But that doesn't work on *NIX machines. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean depends, I'm not getting how it works
Yes, I just verified that my little test works now. Sorry to alarm, I missed your commit of ServiceDeployer, and assumed I was using CVS HEAD when I mentioned it. -David On Thu, 20 Dec 2001, David Jencks wrote: The depends and depends-list features now work correctly and all deployment tests (jmx) pass. __ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66thread=6069 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Bug in EntityContainer ?
EntityContainer:859
protected void setupMarshalledInvocationMapping()
{
try
{// Create method mappings for container invoker
Method [] m = homeInterface.getMethods();// line 859
I assume we setup marshalled invocations for remote interfaces only?
This code does not map local interfaces.
All of my beans have local interfaces only, no remote ones, so when this
code runs, it get's a NPE.
Is it safe to just check for null and not do the mapping? Or are local
interfaces supposed to be mapped also in this function?
-David
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug in EntityContainer ?
Nevermind, I just answered my own question. We step on the exception
(but log it's stack trace twice). The ejbs deploy just fine.
I'll just add the check to avoid the stack traces (which is what threw
me off in the first place)
On Thu, 20 Dec 2001, David Budworth wrote:
EntityContainer:859
protected void setupMarshalledInvocationMapping()
{
try
{// Create method mappings for container invoker
Method [] m = homeInterface.getMethods();// line 859
I assume we setup marshalled invocations for remote interfaces only?
This code does not map local interfaces.
All of my beans have local interfaces only, no remote ones, so when this
code runs, it get's a NPE.
Is it safe to just check for null and not do the mapping? Or are local
interfaces supposed to be mapped also in this function?
-David
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EntityContainer.java StatefulSessionContainer.java StatelessSessionContainer.java
User: dbudworth
Date: 01/12/20 10:26:44
Modified:src/main/org/jboss/ejb EntityContainer.java
StatefulSessionContainer.java
StatelessSessionContainer.java
Log:
Modified: setupMarshalledInvocationMapping()
Added check for remote home/bean interfaces to be valid before attempting to map
their methods
Removed extra exception stack trace in the catch clause, log.error(String,Exception)
will do
the stack trace on it's own, so there was no need for e.printStackTrace()
Revision ChangesPath
1.61 +14 -9 jboss/src/main/org/jboss/ejb/EntityContainer.java
Index: EntityContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EntityContainer.java,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- EntityContainer.java 2001/12/19 05:17:07 1.60
+++ EntityContainer.java 2001/12/20 18:26:44 1.61
@@ -44,7 +44,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Daniel OConnor/a
* @author a href=[EMAIL PROTECTED]Bill Burke/a
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
-* @version $Revision: 1.60 $
+* @version $Revision: 1.61 $
*
* pbRevisions:/b
*
@@ -282,7 +282,7 @@
homeInterface = classLoader.loadClass(metaData.getHome());
if (metaData.getRemote() != null)
remoteInterface = classLoader.loadClass(metaData.getRemote());
-
+
// Call default init
super.create();
@@ -853,15 +853,21 @@
{
try
{// Create method mappings for container invoker
- Method [] m = homeInterface.getMethods();
- for (int i = 0 ; im.length ; i++)
+ if (homeInterface != null)
{
-marshalledInvocationMapping.put( new
Long(MarshalledInvocation.calculateHash(m[i])), m[i]);
+Method [] m = homeInterface.getMethods();
+for (int i = 0 ; im.length ; i++)
+{
+ marshalledInvocationMapping.put( new
Long(MarshalledInvocation.calculateHash(m[i])), m[i]);
+}
}
- m = remoteInterface.getMethods();
- for (int j = 0 ; jm.length ; j++)
+ if (remoteInterface != null)
{
-marshalledInvocationMapping.put( new
Long(MarshalledInvocation.calculateHash(m[j])), m[j]);
+Method [] m = remoteInterface.getMethods();
+for (int j = 0 ; jm.length ; j++)
+{
+ marshalledInvocationMapping.put( new
Long(MarshalledInvocation.calculateHash(m[j])), m[j]);
+}
}
// Get the getEJBObjectMethod
@@ -872,7 +878,6 @@
}
catch (Exception e)
{
- e.printStackTrace();
log.error(getEJBObject failed, e);
}
}
1.40 +14 -9 jboss/src/main/org/jboss/ejb/StatefulSessionContainer.java
Index: StatefulSessionContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/StatefulSessionContainer.java,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- StatefulSessionContainer.java 2001/12/19 05:30:04 1.39
+++ StatefulSessionContainer.java 2001/12/20 18:26:44 1.40
@@ -31,7 +31,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Daniel OConnor/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
-* @version $Revision: 1.39 $
+* @version $Revision: 1.40 $
*
* pbRevisions/b
* pb20010704/b
@@ -605,17 +605,23 @@
{
try
{// Create method mappings for container invoker
- Method [] m = homeInterface.getMethods();
- for (int i = 0 ; im.length ; i++)
+ if (homeInterface != null)
{
-marshalledInvocationMapping.put( new
Long(MarshalledInvocation.calculateHash(m[i])), m[i]);
+Method [] m = homeInterface.getMethods();
+for (int i = 0 ; im.length ; i++)
+{
+ marshalledInvocationMapping.put( new
Long(MarshalledInvocation.calculateHash(m[i])), m[i]);
+}
}
- m = remoteInterface.getMethods();
- for (int j = 0 ; jm.length ; j++)
+
+ if (remoteInterface != null)
{
-marshalledInvocationMapping.put( new
Long(MarshalledInvocation.calculateHash(m[j])), m[j]);
+Method [] m = remoteInterface.getMethods();
+for (int j = 0 ; jm.length ; j++)
+{
+ marshalledInvocationMapping.put( new
Long(MarshalledInvocation.calculateHash(m[j])), m[j]);
+}
}
-
// Get the
[JBoss-dev] Are proxy instances cached somewhere?
When I redeploy my EJB, I get class cast exceptions when looking up the remote home objects. Even though the home has not changed or been recompiled. I deploy with all my classes in a SAR (proxeno01.sar), and then deploy a descriptor only EAR (proxeno02.ear). I am re-deploying by first deleting the EAR, waiting 5 sec, then deleting the SAR, wait 5 sec, and re-copy the sar/ear files. I can see that all the undeploys finish with no problems before the re-deploy happens. And I can see the code changed because the services reflect new changes on the re-deploy. So it's not like the classes are left around. It's almost like the proxy gets cached and the cached instance depends on the deployment directory (where we unpack all the ear/sar files) not to change or something like that. I don't know enough about how the new deployment stuff works, so I don't know where to look to find out whats wrong. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Are proxy instances cached somewhere?
proxeno.sar \- META-INF \- jboss-service.xml \- com/proxeno/blah blah blah, all my classes proxeno.ear \- META-INF \- application.xml \- proxeno.jar \- META-INF \- ejb-jar.xml \- jboss.xml \- proxeno.war \- WEB-INF \- web.xml \- index.html So, for deployment, I deploy proxeno.sar first. Then I deploy proxeno.ear, which picks up the classes from proxeno.sar And for undeployment, I just delete in reverse order (delaying between deletes to give time for things to get undeployed) Is that what you were looking for? On Thu, 20 Dec 2001, marc fleury wrote: I deploy with all my classes in a SAR (proxeno01.sar), and then deploy a descriptor only EAR (proxeno02.ear). Can you show me this structure? it is unclear what do you mean by a descriptor only ear, only the xml files? give a layout. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Is CVS HEAD sorta stable?
Marc, are you still checking in you changes? Or are you in bug fix mode? If so, there is no way to undeploy a service xxx-service.xml It seems as though ServiceDeployer.java:694 attempts to call ServiceController.undeploy(ObjectName) But ServiceController has no function named undeploy. It does have remove(ObjectName), and destroy(ObjectName). But no undeploy(ObjectName) I'd be happy to fix this if I knew that remove() is indeed the one to call instead of undeploy. If you are still checking this stuff in, just ignore me please. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MBean depends, I'm not getting how it works
I have 2 MBeans, server mbean code=mypackage.MBean2 name=Test:name=mbean2 dependsTest:name=mbean1/depends /mbean mbean code=mypackage.MBean1 name=Test:name=mbean1/ /server Problem is, they are started in defined order. So mbean2 starts before mbean1 even though mbean2 depends on mbean1 Is this as expected? Is the depends mechanism used for init order only? I ask, since I define Queue's in my SAR, and make my mbeans that listen on those queues depend on the queue being started. Which of course fails since the dependant mbeans actually have their start() called first. Am I just missing something here? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) startup levels proposal and questions.
I like the idea of site \- default \- conf \- deploy \- logs \- whatever \- cluster \- conf \- deploy \- logs \- whatever Having the named deploy dirs like system/user/etc still doesn't give the user an instant clue as to what runs first. I would guess, making it more simple: 1) for all files in deploy, deploy each one in sorted order 2) for all directories (in sorted order), deploy each file in it (and walk the dir tree for as much depth as you want) so, order of execution deploy/aaa-service.xml deploy/a/aaa-service.xml deploy/b/aaa-service.xml Still maintaining the depends or ejb-ref system for dependancies. But make site/default/deploy be exactly as it is today. So, to the un-initiated, the only real change from 2.4 is the fact that we made the conf/deploy/whatever as a single unit, easily backed up, or CVS controlled. But, when someone needs some kind of I need to deploy after EVERYTHING else is deployed, they just name the file deploy/ZZ-whatver-service.xml And if they want to get more fancy with runlevel type stuff, they can move it all around as much as they want. Then, jboss-init could really just be as simple as a shutdown/restart with new config. ie: run.sh does #make sure to clean up old state in case we crashed when restarting if [ -f newconf.cfg ] ; then rm newconf.cfg; fi if [ -z $1 ]; then CONF=default else CONF=$1 fi while (true); do java -Dconfig=$CONF if [ -f newconf.cfg ]; then CONF=`cat newconf.cfg` rm newconf.cfg continue fi echo JBoss Shutdown exit done This would allow admins to get pseudo uptime of jboss by checking the start time of run.sh, and you'd be ensured no funky leaks when switching configs. And you don't have to worry about KXXX scripts, since the server bounces each runlevel change. Ok, maybe this is overkill. But it allows more control of deployment, while still allowing the current directory layout, and doesn't add a bunch of complexity to the code. Just add to the payfor-docs the description, or maybe even examples of ways you can use this. -David On Sun, 11 Nov 2001, Allen Fogleson wrote: Actually what if the deploy directory was a subdir of the conf directory? That doesnt seem like it would be too confusing to even a new user. Al [EMAIL PROTECTED] wrote: Hiram, I don't understand your problem with deploy dirs and different configurations. Can't you have directories deploy/conf1/lib deploy/conf1 deploy/conf2/lib deploy/conf2 ? Yes, that would be nice. Since the default layout is setup to support multiple conf dirs, it makes sense to my to have multiple deploy dirs too. Would that be too confusing for a beginer. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Anyone mind if I rename build.bat to Build.bat?
Does anyone mind if I rename build.bat to Build.bat? Windows boxes aren't case sensitive, so they'll never see the change, and for unix types, we can do: ./b[TAB] to get build.sh to expand, as it is now, it stops at ./build. (because .bat and .sh are both executable). It's a little thing, but it is indeed annyoying. And you know how us unix types hate typing. :) Just wanted to check with everyone in case build.bat is REQUIRED to be lowercase for some reason. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Redeployment of ear/sars (problem)
Hi peoples, First off, this is not related to my previous posts about CL, so don't start off in flame mode Marc. To avoid the duplicate class in archive problems I restructured my app to be: SAR - Contains my services + all my classes EAR - Contains everything but classes in the WAR, and EJB jar, the classes come from the SAR. This works perfectly. And my build process goes super fast (since I don't need to stuff classes in WAR/EJBjar/SAR. Ok, that being said, now, when I want to upgrade the classes I: 1) Delete the EAR from deploy 2) Wait for it to undeploy completely 3) Delete SAR from deploy 4) Wait for it to undeploy completely 5) Copy new SAR 6) Wait for it to deploy 7) Copy new EAR Looking at the logs, this deploys just fine, in the 8082 UI I can see everything went away and came back. I hit a method on a service, and it's the new code. I hit a web page that I define, and I can see the servlet is the new version. But when the servlet attempts to create my SLSB, it gets an error. On first deploy, it worked fine, but on the second deploy, it fails. The exception stack is below. Line 46 of com.proxeno.servlet.WMServlet is the invocation of create(). I don't know enough about the auto-deployer to find where this is getting broken. I do know my lookup of the EJBHome is working (to a degree) since what get's returned I check it's non-null (although I'm really only checking that the proxy is non-null, so it may be pointing to something that doesn't exist). Is this a known problem? Anyone have any pointers as to where I should start looking to fix this? In the mean time, this is easily solved by stopping/starting jboss for each change, but I assume this should work without the restart. Thanks, -David Exception: java.lang.reflect.InvocationTargetException: java.lang.reflect.UndeclaredThrowableException: java.rmi.ServerException: null; nested exception is: java.lang.NullPointerException java.lang.NullPointerException at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invokeHome(StatelessSessionContainer.java:513) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invokeHome(StatelessSessionInstanceInterceptor.java:53) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:98) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:155) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:55) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:102) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:109) at org.jboss.ejb.StatelessSessionContainer.invokeHome(StatelessSessionContainer.java:267) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invokeHome(BaseLocalContainerInvoker.java:239) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker$HomeProxy.invoke(BaseLocalContainerInvoker.java:390) at $Proxy10.create(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at com.proxeno.servlet.WMServlet.doGet(WMServlet.java:46) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:289) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:541) at org.mortbay.http.HttpContext.handle(HttpContext.java:1145) at org.mortbay.http.HttpContext.handle(HttpContext.java:1099) at org.mortbay.http.HttpServer.service(HttpServer.java:725) at org.mortbay.http.HttpConnection.service(HttpConnection.java:745) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:918) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:760) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:138) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) at java.lang.Thread.run(Thread.java:484) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How to get EJBs to redeploy when they share code with SARs?
Yes, that works perfectly fine. I just made my build.xml do delete, sleep 5, install, to get the auto-redeploy type thing you get with EJBs. But, in the newer thread I created, you'll see that something is still wrong, where EJBs that use the code from the SAR, can't be re-deployed anymore (even though the EJB.jar has no classes in it and gets all it's code from the SAR) -David On Mon, 10 Dec 2001, David Jencks wrote: Back to your original question--- can't you undeploy and redeploy the sar, with the changed classes in it? This should work OK in current jboss. Note you have to explicitly undeploy sars at the moment-- updating them doesn't do anything. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: A State of the Machine Running
Can someone send me the procmail filter that makes Peter's messages readable? -David On Mon, 10 Dec 2001, Dain Sundstrom wrote: huh? Do you every use full sentences? -dain -Original Message- From: Peter Fagerlund [mailto:[EMAIL PROTECTED]] Sent: Monday, December 10, 2001 8:40 PM To: Jason Dillon Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] Re: A State of the Machine Running on 1-12-11 03.35, Jason Dillon at [EMAIL PROTECTED] wrote: Ok, one more time... Huh? Two times -heh *** We need a state -spine thing : --to deploy on ---then Auto/level/grade/scope/... deloyer() has a state ... /peter_f --jason On Tue, 11 Dec 2001, Peter Fagerlund wrote: Is it me or U that have the -clockoff ? ... /peter_f on 1-12-11 03.28, Jason Dillon at [EMAIL PROTECTED] wrote: Huh? --jason On Tue, 11 Dec 2001, Peter Fagerlund wrote: Starting Suspended Stopping returning anything else means running ? ... ;-) /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) startup levels proposal and questions.
I would also like to make sure that any docs, don't refer to this (assuming it gets implemented) as being like SysV runlevels (like Linux,Solaris,etc..) runlevels aren't even remotely working like this. Each runlevel in a SysV init style is a self contained state. Meaning, init 5 does not do init 1,2,3,4,5. Runlevel 5, contains every thing that should/should not be running when at level 5. That's why they have S01xxx S02yyy K01zzz The K??* scripts run first, then all S??* run, in sorted order. I do wonder though, will splitting the directories up make administration more difficult? If you want guaranteed deployment order, you could always name all the items in deploy/* with numbers at the start. ie: 00hsqldb-service.xml 00blah-service.xml 01cluster-service.xml Then just have the deployer always ensure to sort the dir list, and process in order. That way, in Bill's case, he could just call his SAR (or whatever), 99Bill.sar Guaranteed to deploy after the ones that sort first. Having the whole runlevel type thing might just confuse people (especially unix admins, if you don't give them SysV type runlevels) Just a thought, -David On Mon, 10 Dec 2001, Jason Dillon wrote: Everything in level1 will be deployed, then everything in level2, etc. I think this will give enough control over deployment order for almost all circumstances. (I'd like examples of anything it won't work for). I think we might want to use different names, as level1-6 might get a little confusing. Perhaps we could assign these levels meaningful names: bootstrap system user Could also nest the structure for better naming too: system/ bootstrap/ core/ db/ cluster/ jms/ user/ whatever/ samesame/ Now, in Linux you can init 3 or init 6. So far you can't do this here. Is that a valuable feature for jboss? (i.e. being able to say deploy levels 1,2,3. Now deploy 4,5,6. Now undeploy 6, 5, 4, 3) How would it be used? Yikes, I hope there aren't any Linux systems that will init 6 and do anything short of boot... I hope you mean init 5 (X11). Would this be more or less convenient to use than a deployment script facility where each script basically had a list of what is in one of these level directories? I don't think that the actual notion of levels makes sence for the AD, but seperating things for ordering certainly does. --jason ___ 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] How to get EJBs to redeploy when they share code with SARs?
Hi all, I have one big codebase, and I repackage the compiled classes with different DDs to get my ejb.jar, war, sar, ear files. What I'm seeing now is, if I deploy my sar (which has all my classes, including the EJB implementation classes). Then deploy my EAR file. Subsequent re-deployes of the EAR, look as though they are re-deploying, but when I access the EJBs, they are using the old classes (from the SAR I assume). The SAR isn't changing, just the EJBs in the EAR, so in effect, I have multiple versions of the same class under deploy. It seems as though the CL is finding the SAR copy of the file, and ignoring my re-deployment. This requires that I restart jboss to see my new EJB code. Can someone tell me which descriptor/auto-deployer/hot-deployer I need to wave a dead chicken over to get it to work? Restarting jboss in between little 1 line fixes to my code seriously sucks. Do I have to remove the EJB code from my SAR to make this all work? I have a lot of common code between EJBs and MBeans, so getting rid of the EJB files from the SAR is only a little fix. I thought this used to work (but I could be wrong on that one). -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How to get EJBs to redeploy when they share code with SARs?
If the EAR doesn't get preference as to which classes to load then there are bigger problems here. Example: I have a SuperMap class that implements Map, plus has a bunch of other stuff in it. Both the SAR, and the EJBs int he EAR use it. If I update SuperMap, and change the EJBs to use the new functionality, even though the ejb.jar has the new version in it, it won't see it's new version of the class. It will get the SARs version, and crash with NSME. Is there some standard way to deploy common code in JBoss 3? Maybe a SAR that defines no services in the xml? and contains all the non-EJB non-Service code? Maybe package up all my classes into that service-less sar, and then just deploy descriptors? Re-deploying the serviceless sar would auto-redeploy the EJBs and Services? I'm confused here. I would expect that a deployed ejb.jar, or EAR file would use it's logically closest implementation of classes. And not one that it found from another SAR/EAR. Or are we only talking about EJB implementation classes that will exibit this behavior? And when you say 3.x will do away with it, do you have a timeframe on that? If it's soon, I can just restart jboss for every code change. If it's not expected until 3.0 final, I'll work at re-packaging everything (which means re-factoring 80% of my code, since my impl/interfaces are all in the same package) I don't mean to be a pest. I just got caught off guard with this. My company asked for a demo of my stuff for next week, and I had just assumed all along that the CLs would always find the classes defined in the same archive as the DD. -David On Sat, 08 Dec 2001, marc fleury wrote: What I'm seeing now is, if I deploy my sar (which has all my classes, including the EJB implementation classes). The SAR classes will see EJB ones from the SAR. do you have the *implementation* class in there as well? if so remove that. Then deploy my EAR file. Subsequent re-deployes of the EAR, look as though they are re-deploying, but when I access the EJBs, they are using the old classes (from the SAR I assume). That is normal, you packaged static classes in the SAR. When you deploy an ear, since we still use the delegation model from 2.x. the CL for the EJB has SAR CL has parent and sees the classes in the SAR. BTW 3.x will do away with this delegate app-service. Don't package the implementation classes with the SAR marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] How to get EJBs to redeploy when they share code with SARs?
I fully understand. And I was not demanding it to be by Monday. I just was asking if it's on the list of stuff to do, or on the list of stuff to test/commit. I wasn't expecting anyone to rush right out at do it. And, yes, I do know that that's the CL delegation model for 1.2, I just saw messages about that being worked around for 3.0, and I had no idea if it was already done. I'm relaxed (as much as someone who drinks as much cafine as I do can be). I am curious though, is there a todo list for JBoss 3.0 somewhere? It would help dumbasses like me know what is/isn't done already before we ask, as well as help those of us who want to help know what needs to be done. -David On Sat, 08 Dec 2001, marc fleury wrote: |I don't mean to be a pest. I just got caught off guard with this. My |company asked for a demo of my stuff for next week, and I had just |assumed all along that the CLs would always find the classes defined in |the same archive as the DD. Being a pest here doesn't really get you anywhere. I don't really care. You will always find the class from the parent CL per the java 1.2 delegation model, you assumed wrong this is jdk behavior. Only in 3.0 do we go boldly where no CL has ever gone so as to bypass the JDK delegation model and that behavior you are describing will be possible when I integrate the CL. If you need it by monday you know the drill, I need money, otherwise this is the bruce wayne syndrome at play and I am not batman. If you want work done that doesn't fall in my schedule, you will either have to pay to prioritize it or do it yourself. This isn't personal I said the same thing to a larger company that had spent upwards of $20k on training with us (CPW in the UK). I hope you understand. Relax, and enjoy the show marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: ServiceMBeanSupport init and destroy commented out
Marc, init/destroy are never called on a ServiceMBean. (At least they aren't called on mine) So uncommenting them does nothing. I assume they were commented out when David J made the change from two stage init/destroy to 1 stage. (Which, BTW, broke every serivce I had written previously since I used start/stop to pause/unpause, and init/destroy to create/destroy expensive resources. But, that's a different thread) On Fri, 07 Dec 2001, marc fleury wrote: Revision 1.5 / (download) / (as text) - annotate - [select for diffs] , Mon Nov 12 06:52:17 2001 UTC (3 weeks, 4 days ago) by d_jencks Branch: MAIN CVS Tags: Rel_2_4_4_15 Changes since 1.4: +15 -15 lines Diff to previous 1.4 Changes to move toward eliminating init and destroy from Service interface, and make J2eeDeployer use mbean-refs. (2nd try at committing - is cvs acting weird? ?:|, David, I am not up for a 50 mail thread on that one but I think it was an oversight, I will uncomment, write if you want to discuss so we have something to fight over during the weekend __ View: http://jboss.org/forums/thread.jsp?forum=66thread=5197 ___ 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] DTDs are missing from website?
Did anyone know that the DTDs are missing from the website? Make's it really hard to run xmllint on your descriptors. Or is it just me that can't get to them? (Something I don't doubt with my funky netgear router thingie) -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] build system updates coming
Ok, condensed version for Marc. (david@dolj)-(05:58pm Wed Dec 5)-(~) (503)$ cat jboss-all/makefile all: javac -d output -classpath `find . -name *.jar | tr ' ' ':'` `find . -name *.java` jar czf big.fucking.jar -C output . Now, soon as the xml only deployment of every module works. You're set. -David p.s. For the humor impaired / Unix impared / SourceForge-bug-happy, this was a joke. On Wed, 05 Dec 2001, marc fleury wrote: I am reducing the size of all build.xml files. please don't check in any major structural changes to any build.xml for a bit. minor changes should be ok, but anything too complex will freak out cvs update and cause nasty conflicts, which are a bitch to fix. --jason Tell me about it I have about 50 files to check in and it is going to be a bitch... the simplification is most welcome Jason, to be polite and all I would say, Jason, my heart, would you _please_ simplify the fucking build.xml file down from 1300 lines ? please? :D ___ 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] jboss build failed
I thought it was just me (that didn't understand). Ok, I don't feel so dumb now. Thanks, -David On Tue, 04 Dec 2001, Jason Dillon wrote: I totally don't understand any of the emails you send. I don't mean to be offensive, I just don't get it. --jason On Wed, 5 Dec 2001, Peter Fagerlund wrote: on 1-12-04 21.52, Julian Gosnell at [EMAIL PROTECTED] wrote: I updated my RH tree 1/2 an hour ago, made clen and rebuilt - no problems. Yes that is the way - build - no probs - but there seems to be some slack here -and that is counterproductive inbeetwen - i build now - hurray ... IMNSHO /peter_f *wordthatarelonger*thenthisisnogood = clear ! *counterproductive* ___ 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] jboss build failed
Peter, If you want good CVS comments (comments that actually apply to the changes in the file), then changes must be committed on the per file (or per logical change) base. If someone has to commit 5 unrelated changes, or each file needs different checkin messages for each, then they must be commited seperately. And if you do a cvs update during that period, the build will fail. There is no way around that, multiple commits can't be done atomicly in CVS. I'm guilty of the same problem of doing a cvs update; build.sh, and when it breaks, complaining about it (Scott S. can testify to that). But, when you see something like that, you need to wait an hour or so, before complaining, to let the developer form good checkin messages. Without those, we have no way of determining what happened when. -David On Wed, 05 Dec 2001, Peter Fagerlund wrote: MAN - let me spell it out then ! -heh Do not check in -if it do not build ! ... Clear ... /peter_f on 1-12-05 01.22, Jason Dillon at [EMAIL PROTECTED] wrote: I totally don't understand any of the emails you send. I don't mean to be offensive, I just don't get it. --jason On Wed, 5 Dec 2001, Peter Fagerlund wrote: on 1-12-04 21.52, Julian Gosnell at [EMAIL PROTECTED] wrote: I updated my RH tree 1/2 an hour ago, made clen and rebuilt - no problems. Yes that is the way - build - no probs - but there seems to be some slack here -and that is counterproductive inbeetwen - i build now - hurray ... IMNSHO /peter_f *wordthatarelonger*thenthisisnogood = clear ! *counterproductive* ___ 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] Changes to State-Management in ServiceMBeanSupport
Just something to keep in mind, as I look through various MBeans (of my own, and ones in JBoss), it seems that everyone steps on any exception throws in stop(), since the ServiceMBean interface forbids exceptions in stop(). So if your plan is FAILED being set by the controller when a start()/stop() throws an exception, you may want to change ServiceMBean to allow throwing from stop(). And have those responsible update their MBeans (if need be). Just a reminder, in case you didn't think of / forgot about it. -David On Mon, 03 Dec 2001, Andreas Schaefer wrote: Hi Still, when your service did not start or couldn't be stopped you should go and consult your LOG. Then you will see if this happened during starting or stopping phase. What you are asking for makes for me only sense when you have a management tool (HTML-Adaptor is hardly a management tool). This tool would then get the STATE change event and can determine in which phase it happened. When you really won't go there with the two different states of FAILED then the service also has to provide some information about the exception which is not available in the ServiceMBean right now. But when you have information about the exception then you now if it happens in start or stop. Andy - Original Message - From: Hiram Chirino [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 03, 2001 8:22 PM Subject: Re: [JBoss-dev] Changes to State-Management in ServiceMBeanSupport From: Andreas Schaefer [EMAIL PROTECTED] To: Hiram Chirino [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Changes to State-Management in ServiceMBeanSupport Date: Mon, 3 Dec 2001 20:14:11 -0800 That depends. When you have a JNDI service which does not release its port then it is as serious as if it does not start because you cannot start another JNDI service (sorry for this ugly example). Still the resolution to the problem will allways depend on what state you came from. If it did not start, then you have a high % that you have something miss configured. Is something does not stop. Then you have a high % chance you need to restart the server to fix the problem. Knowing if we were stopping or starting would help to trouble shoot the problem. Regards, Hiram ___ 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/main/org/jboss/naming JNDIView.java
User: dbudworth
Date: 01/12/03 10:16:40
Modified:src/main/org/jboss/naming JNDIView.java
Log:
Fixed StringOutOfBounds OB1 bug when building buffer
Revision ChangesPath
1.12 +2 -2 jboss/src/main/org/jboss/naming/JNDIView.java
Index: JNDIView.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/naming/JNDIView.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JNDIView.java 2001/11/28 19:15:57 1.11
+++ JNDIView.java 2001/12/03 18:16:40 1.12
@@ -37,7 +37,7 @@
@author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
@author Vladimir Blagojevic [EMAIL PROTECTED]
-@version $Revision: 1.11 $
+@version $Revision: 1.12 $
*/
public class JNDIView extends ServiceMBeanSupport implements JNDIViewMBean
{
@@ -393,7 +393,7 @@
buffer.append(ifaces[i]);
buffer.append(',');
}
-buffer.setCharAt(buffer.length(), ')');
+buffer.setCharAt(buffer.length()-1, ')');
}
else
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RequiredModelMBean.java? / general rantings
Ahh. ok. Well, it's obvious to me (as well as everyone else I assume). That you know a lot more about this stuff than I do. So, I'll leave it to the experts. Thanks for replying. -David On Sun, 02 Dec 2001, Juha-P Lindfors wrote: Hi, Marc / everyone, When you asked about this Dynamic mbean thing I'm working on, were you thinking of me applying it to RequiredModelMBean? I wrote a ModelMBean implementation for the book and will commit an implementation based on it (with some other stuff) in the next couple of days. If I read correctly, we are required to supply an implementation of that class, no? Just implementing the ModelMBean interface will be enough. 1) What are the expectations for determining the MBeanInfo? Should we expect a XYZMBean interface to match the XYZ implementation the user provides? (similar to regular MBeans) This would be easy to add. Since I already have the code that walks the methods of any specified interface to compose the operation/attribute info structures. The metadata can be built using introspection on the resource class, read from a database, read from a file, looked up from the JNDI. The rules for introspection can follow the standard MBean rules, or you can create your own naming rules for a specific resource type. 2) What should be the rules for determining the operations/attributes? I have written and re-written this logic in my own code about 15 times, never really happy with it. Example, how to handle: int getXYZ(); void setXYZ(float); Do you consider the get to be a RO attribute and one to be an operation? Or throw an exception for non-compliant naming? I see nothing in the spec regarding naming standards on dynamic mbean oper/attr or int getXYZ(); void setXYZ(int); void setXYZ(float); Do we consider get/set(int) to be a RW attr, and set(float) to be an operation? Or throw again? If you are talking about the Standard MBean behaviour, that would cause a NotCompliantMBeanException to be thrown. However, for ModelMBeans you could build your own resource types that allow this kind of interface to be handled differently. As for persistence, have you finished rolling on the floor laughing at my idea of using EJBs to store? I have noticed that no other components use EJBs for their JDBC based persistence. Is there a reason for this? The MMBean persistence can be abstracted behind a simple PersistenceManager interface with load and store operations. The persistence implementation may then be file based, direct JDBC, JDO or EJB. -- Juha ___ 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] RequiredModelMBean.java? / general rantings
You are correct sir! (doing my best Ed McMahon impression) JBoss is providing most of the infrustructure (we use JMX/JMS/EJB). And, we are planning on selling by January. So it may even be the first JBoss 3.0 based thing in commercial use. This is why I go on these little mini-rants about administration. At my previous job (eloan.com), the biggest cause for downtime was from administration mistakes. And that was in no way the fault of the actual admins. The admins were the best I've seen. It really came from having too many different non-connected pieces to manage. Every developer rolled their own for config data, file location, a thousand little cron jobs, etc.. Which is why I fully believe that central and *easy* administration is going to be the winner in this space. And JBoss has all the parts required to make this happen. No other app server can touch us here. But, I think I'm preaching to the choir here, as far as JBoss being the Kwisatz Haderach of app servers. (Dune reference, but I don't know a geek who hasn't seen Dune, so you probably already knew that) -David On Sun, 02 Dec 2001, marc fleury wrote: So much the better, you get to work on stuff that Juha wrote for the book and will save you some time. You even get to use it in your application if you want, seems like JBoss3.0 is providing a lot of infrastructure for you. Your help will be much appreciated on that base, marcf |-Original Message- |From: David Budworth [mailto:[EMAIL PROTECTED]] |Sent: Sunday, December 02, 2001 4:50 AM |To: Juha-P Lindfors |Cc: David Budworth; [EMAIL PROTECTED]; |[EMAIL PROTECTED] |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |Ahh. ok. | |Well, it's obvious to me (as well as everyone else I assume). That you |know a lot more about this stuff than I do. | |So, I'll leave it to the experts. | |Thanks for replying. | |-David | | |On Sun, 02 Dec 2001, Juha-P Lindfors wrote: | | | | Hi, | | Marc / everyone, | | When you asked about this Dynamic mbean thing I'm working on, were you | thinking of me applying it to RequiredModelMBean? | | I wrote a ModelMBean implementation for the book and will commit an | implementation based on it (with some other stuff) in the next couple of | days. | | | If I read correctly, we are required to supply an |implementation of that | class, no? | | Just implementing the ModelMBean interface will be enough. | | | 1) What are the expectations for determining the MBeanInfo? Should we | expect a XYZMBean interface to match the XYZ implementation the user | provides? (similar to regular MBeans) | | This would be easy to add. Since I already have the code that |walks the | methods of any specified interface to compose the operation/attribute | info structures. | | The metadata can be built using introspection on the resource class, read | from a database, read from a file, looked up from the JNDI. The | rules for introspection can follow the standard MBean rules, or you can | create your own naming rules for a specific resource type. | | | 2) What should be the rules for determining the operations/attributes? | I have written and re-written this logic in my own code about 15 times, | never really happy with it. Example, how to handle: | | int getXYZ(); | void setXYZ(float); | | Do you consider the get to be a RO attribute and one to be an |operation? Or | throw an exception for non-compliant naming? I see nothing in the spec | regarding naming standards on dynamic mbean oper/attr | | or | | int getXYZ(); | void setXYZ(int); | void setXYZ(float); | | Do we consider get/set(int) to be a RW attr, and set(float) to be an | operation? Or throw again? | | If you are talking about the Standard MBean behaviour, that would cause a | NotCompliantMBeanException to be thrown. However, for ModelMBeans you | could build your own resource types that allow this kind of interface to | be handled differently. | | As for persistence, have you finished rolling on the floor laughing at | my idea of using EJBs to store? I have noticed that no other |components | use EJBs for their JDBC based persistence. Is there a reason for this? | | The MMBean persistence can be abstracted behind a | simple PersistenceManager interface with load and store operations. The | persistence implementation may then be file based, direct JDBC, JDO or | EJB. | | | -- Juha | | | ___ | 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
[JBoss-dev] CVS Head fails to build due to no com.sun.net.ssl.* package
I just updated my tree after a few days, and SecurityDomain fails to build now. It seems as though it can't find com.sun.net.ssl.* classes. And when looking in every jar file in the jdk, I can't find any package containing ssl in it. Is there some other sun library we must install now? -David Below is one of the errors I get. /home/david/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java:12: cannot resolve symbol symbol : class KeyManagerFactory location: package ssl import com.sun.net.ssl.KeyManagerFactory; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RequiredModelMBean.java? / general rantings
Marc / everyone, When you asked about this Dynamic mbean thing I'm working on, were you thinking of me applying it to RequiredModelMBean? If I read correctly, we are required to supply an implementation of that class, no? If not, ignore the rest. I'd be happy convert my stuff over to be the implementation of that, since mainly the only difference with what I wrote and this is the persistent storage stuff. I do have a few questions on how it should be done. 1) What are the expectations for determining the MBeanInfo? Should we expect a XYZMBean interface to match the XYZ implementation the user provides? (similar to regular MBeans) This would be easy to add. Since I already have the code that walks the methods of any specified interface to compose the operation/attribute info structures. 2) What should be the rules for determining the operations/attributes? I have written and re-written this logic in my own code about 15 times, never really happy with it. Example, how to handle: int getXYZ(); void setXYZ(float); Do you consider the get to be a RO attribute and one to be an operation? Or throw an exception for non-compliant naming? I see nothing in the spec regarding naming standards on dynamic mbean oper/attr or int getXYZ(); void setXYZ(int); void setXYZ(float); Do we consider get/set(int) to be a RW attr, and set(float) to be an operation? Or throw again? In my stuff, there is a protected Class[] getInterfaces() so an mbean can specify which interfaces it want's to expose to management. But, if that returns null(default impl), I just use all public methods not defined in the base or java.lang.Object to be a managed UI. Would you want that in the JBoss RequiredModelMBean? What I have now, basically allows the subclasses to specify any part of the MBeanInfo (ie, via protected MBeanAttributeInfo[] getAttributeInfo()), so the subclass can 'break the rules' that are defined in the base class. I wonder, is this too much complexity to offer in a generic base class to be supplied with JBoss? As for persistence, have you finished rolling on the floor laughing at my idea of using EJBs to store? I have noticed that no other components use EJBs for their JDBC based persistence. Is there a reason for this? soapbox Assuming Dain's engine has nothing to persist (MBean wise), there is no reason not to use it. If we don't believe in EJBs enough to use them ourselves, how can we tell others to use JBoss for their projects. Hell, configuration persistence is something that happens so rarely (in the application sense), I don't think performance is really an issue. /soapbox As for clustering stuff, keeping in mind I haven't looked at it yet. Does anyone know if hypersonic get's clustered as well? I see that to get the EJBs mass deployed there is the farm directory, so that kind of implies that there is a master server somewhere (unless everyones farm propogates to everyone else). If hypersonic doesn't cluster, then is there the ability to add to a DD something like: if (master) use local DB else use master DB We store the JMS stuff (and maybe others, I haven't looked) on disk now. With the option of using JDBC. I understand that there is a performance issue, but from the admin point of view, they'd be much happier if everything was all in one place, that was remotely viewable (ie. whatever DefaultDS points to). I've heard Marc mention several times that the winner in this space is going to be the ones with the best ease of management. And I fully agree. Knowing what it took to manage eloan.com's website, and all the problems with what files are where, all the little cron jobs on different machines to make sure the old stuff gets nuked to avoid running out of disk space. I think that a system, with a single point of management (ie: everything in single DB) would have made our lives easier. Keep in mind, my view may be tainted. Our admins pretty much all came from Oracle (or oracle based companies). So to them, having a DB be the front for everything was nirvana. My current project has all my custom config info in the database. So I can easily make changes that all servers can see, as well as perform atomic changes (update 20 config items, then commit, rather than calling setXXX, setYYY and having each change propgate one at a time). But hey, maybe that's just me. Is my view of how things should work just completely misguided? I'll shut up (again) now. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RequiredModelMBean.java? / general rantings
I hadn't thought of that. I have always viewed JBoss as an overall platform with replacable elements. It hadn't occured to me that you may want to run only one element of it. I saw it more like the JDK. If you don't want to use JDBC, don't use it. But you wouldn't go removing the java.sql.* classes from the jars. I didn't realize that was a goal of JBoss. -David On Sat, 01 Dec 2001, Dain Sundstrom wrote: You are making 2 bold assumptions. 1. JBoss will always run with the EJB service installed. 2. JBoss will always have a database available. Neither of these hold. As a quick example, I may want JBossMQ with out a database or EJB services. -dain -Original Message- From: David Budworth [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 01, 2001 6:04 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] RequiredModelMBean.java? / general rantings Marc / everyone, When you asked about this Dynamic mbean thing I'm working on, were you thinking of me applying it to RequiredModelMBean? If I read correctly, we are required to supply an implementation of that class, no? If not, ignore the rest. I'd be happy convert my stuff over to be the implementation of that, since mainly the only difference with what I wrote and this is the persistent storage stuff. I do have a few questions on how it should be done. 1) What are the expectations for determining the MBeanInfo? Should we expect a XYZMBean interface to match the XYZ implementation the user provides? (similar to regular MBeans) This would be easy to add. Since I already have the code that walks the methods of any specified interface to compose the operation/attribute info structures. 2) What should be the rules for determining the operations/attributes? I have written and re-written this logic in my own code about 15 times, never really happy with it. Example, how to handle: int getXYZ(); void setXYZ(float); Do you consider the get to be a RO attribute and one to be an operation? Or throw an exception for non-compliant naming? I see nothing in the spec regarding naming standards on dynamic mbean oper/attr or int getXYZ(); void setXYZ(int); void setXYZ(float); Do we consider get/set(int) to be a RW attr, and set(float) to be an operation? Or throw again? In my stuff, there is a protected Class[] getInterfaces() so an mbean can specify which interfaces it want's to expose to management. But, if that returns null(default impl), I just use all public methods not defined in the base or java.lang.Object to be a managed UI. Would you want that in the JBoss RequiredModelMBean? What I have now, basically allows the subclasses to specify any part of the MBeanInfo (ie, via protected MBeanAttributeInfo[] getAttributeInfo()), so the subclass can 'break the rules' that are defined in the base class. I wonder, is this too much complexity to offer in a generic base class to be supplied with JBoss? As for persistence, have you finished rolling on the floor laughing at my idea of using EJBs to store? I have noticed that no other components use EJBs for their JDBC based persistence. Is there a reason for this? soapbox Assuming Dain's engine has nothing to persist (MBean wise), there is no reason not to use it. If we don't believe in EJBs enough to use them ourselves, how can we tell others to use JBoss for their projects. Hell, configuration persistence is something that happens so rarely (in the application sense), I don't think performance is really an issue. /soapbox As for clustering stuff, keeping in mind I haven't looked at it yet. Does anyone know if hypersonic get's clustered as well? I see that to get the EJBs mass deployed there is the farm directory, so that kind of implies that there is a master server somewhere (unless everyones farm propogates to everyone else). If hypersonic doesn't cluster, then is there the ability to add to a DD something like: if (master) use local DB else use master DB We store the JMS stuff (and maybe others, I haven't looked) on disk now. With the option of using JDBC. I understand that there is a performance issue, but from the admin point of view, they'd be much happier if everything was all in one place, that was remotely viewable (ie. whatever DefaultDS points to). I've heard Marc mention several times that the winner in this space is going to be the ones with the best ease of management. And I fully agree. Knowing what it took to manage eloan.com's website, and all the problems with what files are where, all the little cron jobs on different machines to make sure the old stuff gets nuked to avoid running out of disk space. I think that a system, with a single point of management (ie: everything in single DB) would have made our lives easier. Keep in mind, my view may be tainted. Our admins pretty much all came from Oracle (or oracle based companies). So
[JBoss-dev] Service MBeans questions
First off, thanks David J. for adding the test case. Anyway, For my own project, I have made a base Dynamic MBean for my own code that all my MBeans are based on. Mainly to avoid the whole MyClass.java must have a MyClassMBean.java type thing that really doesn't work for me given what I use my custom mbeans for. And to allow the subclasses to define their own descriptions of methods/params etc.. I added to my base class start() and stop(), which JBoss sees and does indeed call. I don't (yet) however, define Name, State, StateString attributes that are in ServiceMBean. Just start() and stop() Does JBoss make use of the ServiceMBean attributes? Or are they just for informational purposes? And, are start()/stop() JBoss-isms? Or some kind of standard thing? I couldn't find them in the JMX spec. Would I magically get better managability by making my dynamic base implement ServiceMBean, and make them work like ServiceMBeanSupport? -David ___ 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 MessageLog.java PersistenceManager.java
User: dbudworth
Date: 01/11/30 10:43:16
Modified:src/main/org/jboss/mq/pm/file MessageLog.java
PersistenceManager.java
Log:
Reverted my non-fs-neutral additions to the file PM
Will try creating a mapping mechanism instead.
Revision ChangesPath
1.9 +1 -4 jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java
Index: MessageLog.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- MessageLog.java 2001/11/28 00:55:29 1.8
+++ MessageLog.java 2001/11/30 18:43:15 1.9
@@ -29,7 +29,7 @@
*
* @createdAugust 16, 2001
* @author:Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.8 $
+ * @version$Revision: 1.9 $
*/
public class MessageLog {
@@ -83,9 +83,6 @@
try {
File[] files = queueName.listFiles();
for ( int i = 0; i files.length; i++ ) {
-// If it's a subdirectory, it's a different queue, PM will restore that
also, so ignore it here
-if (files[i].isDirectory())
- continue;
String fileName = files[i].getName();
int extIndex = fileName.indexOf( . );
if ( extIndex 0 ) {
1.12 +2 -33 jbossmq/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.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- PersistenceManager.java 2001/11/28 00:55:29 1.11
+++ PersistenceManager.java 2001/11/30 18:43:15 1.12
@@ -45,7 +45,7 @@
* persistence.
*
* @author Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.11 $
+ * @version$Revision: 1.12 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager
{
@@ -161,37 +161,6 @@
}
/**
-* The codegetDirTreecode function takes a directory and
-* looks for all subdirectories below it (recursively)
-*
-* Note: Recursive function, REALLY deep queues WILL cause stack fault
-* Note: Possible bug if someone implements an unused queue cleanup
-*and it attempts to remove the parent dir of a deep queue
-*without verifying that it's really just a parent dir
-*
-* @param parent The directory to look in
-*
-* @return The deep list of subdirectories
-*/
- private final File[] getDirTree(File parent)
- {
- final ArrayList dirs = new ArrayList(); //must be final
- parent.listFiles(new FileFilter()
- {
- public final boolean accept(File file)
- {
-if (file.isDirectory())
-{
- dirs.add(file); //add to list of all dirs
- file.listFiles(this);
-}
-return false; //avoid File.listFiles doing extra work
- }
- });
- return (File[])dirs.toArray(new File[dirs.size()]);
- }
-
- /**
* The coderestoreTransactions/code method is called when the
* PersistenceManager service is started. It reads all transaction log
* files, and pre-restores all messages that are committed and not read.
@@ -203,7 +172,7 @@
private void restoreTransactions() throws javax.jms.JMSException
{
TreeSet txs = new TreeSet();
- File[] transactFiles = getDirTree(dataDirFile);
+ File[] transactFiles = dataDirFile.listFiles();
int queueNameOffset = dataDirFile.toString().length()+1;
if(transactFiles != null)
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS queue names (again)
The JDBC PM uses a single table to store all messages in. It does, however, have a problem with it's table definitions/jdbc access. But that's a different issue. And AFAIK, all DBs allow any printable char to be stored in a varchar. So, I guess my point is, I don't know that we need to abstract the mapping, rather than just let the PM itself decide if it needs to map queuename-validPMname Or do you see a need to standardize mapping? Just trying avoid adding extra complexity when some PMs don't need a mapper. -David On Thu, 29 Nov 2001, Scott M Stark wrote: Ok, but this is a name mapping problem that is a function of the persistent store. Database columns/tables will also only allow certain names. We should simply have a name mapping interface that can be specified as an attribute of the persistence manager so that the PMs can externalize how the queue name is mapped onto a valid name for their deployment environment specific store. I don't see this problem as an issue that should force naming restrictions on the queues and topics. - Original Message - From: David Budworth [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 6:25 PM Subject: Re: [JBoss-dev] JMS queue names (again) The current problem is that the queue name specified in the mbean descriptor (Or created via the 8082 interface), get's taken literally and used as the directory to store the persistent messages. So: mbean code=org.jboss.mq.server.QueueManager name=JBossMQ:service=Queue,name=myCompany/myQueue mbean-ref name=JBossMQServiceJBossMQ:service=Server/mbean-ref /mbean attempts to create a directory: db/jbossmq/file/QUEUE.myCompany/myQueue Which would not be valid except on unix FSs This deploy fine, but the real problem comes on restart of jboss. The file PM attempts to pre-restore all queues before they are deployed, and to do this, it does a db/jbossmq/file/.listFiles() and assume that those were the actual queue names (minus the QUEUE.). Which would fail to restore the message log since ...file/QUEUE.myCompany is in fact just the parent dir for the message store for myCompany/myQueue I added code that recognized this. But of course I wasn't thinking of the non-unix folks, where using the queuename literally as the dir name might not be valid for their fs. Personally, I don't like having the queuename map directly to the FS names, I'd much rather have generated dir names, and a map file. But that makes human administration of the FS a little more complex, and I didn't get a response from anyone if that was ok to do. And not knowning if the queuename-dirname mapping was for a reason, I didn't want to change it. I don't know what are valid FS chars for each OS, which is why I suggested making is alpha-numeric restricted. (example, can you have a comma in a AS400 filename?) -David On Thu, 29 Nov 2001, Scott M Stark wrote: That would seem to be a little too restrictive a naming requirement. Using isJavaIdentifierPart may be more acceptable. What is the current naming problem? - Original Message - From: David Budworth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 5:22 PM Subject: [JBoss-dev] JMS queue names (again) Ok, now that we have the ability to set the JNDI name on a queue/topic, I would like to fix the bug (that I put in) in regards to deep queue names. For simplicities sake, I'll just revert the file PM back to the way it was. But, since there was (and will be when I revert) a bug there that if you create a queue/topic with depth (ie: mycompany/queues/q1) The File PM will fail at next startup. So, I'd like to add some name validation. Is anyone uncomfortable if I enforce the queue names to be alpha-numeric only? (via, Character.isLetterOrDigit()) JBoss (as it ships), doesn't define any topics/queues that would violate that rule right now. Opinions? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Service MBeans questions
I'd be happy to contribute what I wrote. I'll give you the lowdown on
how it works so you can see if it may even be usefull:
Implements:
DynamicMBean, MBeanRegistration, NotificationBroadcaster,
and ServiceMBean (if it's going to be in spec, might as well prepare)
But not ModelMBean, so there is no persistent config. But after reading
your message, I think I'll be making it into a MMBean.
Normal deployment config is done via the mbeanattribute tags in the XML. Just
like any other mbean.
I had already planned on making the attributes persist.
But not in a way that would be acceptable for generic JBoss uses (I
suppose).
I was going to add a MBeanConfigEJB (CMP bean), that basically had 3
fields.
String pk = ObjectName.toString();
Object data; //explained below
Date lastModified;
Basically, load() would grab the EJB based on ObjectName.
And store() would would update the ejb.
For clustering, I would post a JMS message for each change, to avoid the
other instances from hitting the database when something changes.
This would all be done using select-for-update turned on. So other
instances in the cluster would have serialized access to the row, to
avoid them stepping on each others changes.
basically:
store(){
ut = getUserTransaction();
config = ConfigLocalHome.findByPk(objName.toString());
if ( config.lastMod != localLastMod )
//handle out of date resolution (ie. reload and
//re-apply my modified fields)
else
config.setData(getData(this));
}
load(){
ut = getUserTransaction();
config = ConfigHome.findByPk(objName.toString());
setData(config.getData());
}
getData(){
Map data;
ObjectInputStream ois = ... (byte[] reader, whatever)
String name = ois.readString();
Object val = ois.readObject();
data.put(name,val);
//loop mbean attribute info, restoring each field via it's set.
//that way attributes can be removed without failing to restore
//object
//Probably also want a state=LOADING, to avoid change notifications
//from being fired off when calling the setXXX()
}
setData(){
//loop attributeinfo[], and store name+serialized(val)
}
The idea here being someone can override getData() setData() to change
the storage format.
And since the EJB to perform storage would be configurable in the base
class (or maybe a more generic PM type class), the user could switch
datastore depending on needs of the specific mbean instance.
And if they want the CMP type store, they could always re-define the DD,
and deploy it under a different name to get different performance
abilities.
I also don't require a seperate interface to define the mbeans external
interface.
I have a Class[] getInterfaces method, that by default returns just
getClass()
So, if you want to take any stand alone class and make it an MBean, you
only need to extend my dynamic base class. I just publish any public
method as a operation/attribute (depending on name/params).
And was planning to add a dynamic mbean proxy type thing, where you just
pass it a class, and it reflects on that class. So if there is already
an existing object that extends something else, you can just MBeanify it
by specifing the class name, and constructor params (optional).
ok. That is probably a shit load more than you wanted to hear. But,
after a pot of coffee, and a 2 liter bottle of diet coke, I get a little
type-happy.
I'll shut up now.
-David
On Fri, 30 Nov 2001, marc fleury wrote:
Upon re-reading your email I realize you already implemented the dmbean
approach yourself, so keep that on the warmer and you could be making a
significant contribution next week :)
My question is how do you feed data to that dmbean? how do you configure it?
where are your files? how do you persist them? do you persist changes? do
you cluster them easily? that is part of what we are trying with the
mmbeans... post snippets if you can
marcf
|-Original Message-
|From: marc fleury [mailto:[EMAIL PROTECTED]]
|Sent: Friday, November 30, 2001 1:34 PM
|To: David Budworth; [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] Service MBeans questions
|
|
|funny you mention, I am actually looking at this right this minute.
|
|The state stuff as part of the serviceMBean was defined by Rickard.
|
|It makes total sense. It is going to be part of the JSR77 spec the
|state stuff is. I know the Iona guy and myself pushed for the
|adoption of the state stuff, just give you a runtime view of who
|is active and all.
|
|So it is going to be a part of the spec to be sure whether you
|need or not I don't know.
|
|What I have a problem with is with the implementation of
|ServiceMBeanSupport, it gives a lot of generic code but eats up
|the extends bit obviously and I am stuck with a current
|implementation of the invokers that need to do a Remote and this
|extends... so I need to rewrite the code in there.
|
|Bottom line, we could argue that Service should only have
Re: [JBoss-dev] Service MBeans questions
oops, I reversed getData() / setData() pseudo-implementations.
Man, I really need to start proofreading.
On Fri, 30 Nov 2001, David Budworth wrote:
I'd be happy to contribute what I wrote. I'll give you the lowdown on
how it works so you can see if it may even be usefull:
Implements:
DynamicMBean, MBeanRegistration, NotificationBroadcaster,
and ServiceMBean (if it's going to be in spec, might as well prepare)
But not ModelMBean, so there is no persistent config. But after reading
your message, I think I'll be making it into a MMBean.
Normal deployment config is done via the mbeanattribute tags in the XML. Just
like any other mbean.
I had already planned on making the attributes persist.
But not in a way that would be acceptable for generic JBoss uses (I
suppose).
I was going to add a MBeanConfigEJB (CMP bean), that basically had 3
fields.
String pk = ObjectName.toString();
Object data; //explained below
Date lastModified;
Basically, load() would grab the EJB based on ObjectName.
And store() would would update the ejb.
For clustering, I would post a JMS message for each change, to avoid the
other instances from hitting the database when something changes.
This would all be done using select-for-update turned on. So other
instances in the cluster would have serialized access to the row, to
avoid them stepping on each others changes.
basically:
store(){
ut = getUserTransaction();
config = ConfigLocalHome.findByPk(objName.toString());
if ( config.lastMod != localLastMod )
//handle out of date resolution (ie. reload and
//re-apply my modified fields)
else
config.setData(getData(this));
}
load(){
ut = getUserTransaction();
config = ConfigHome.findByPk(objName.toString());
setData(config.getData());
}
getData(){
Map data;
ObjectInputStream ois = ... (byte[] reader, whatever)
String name = ois.readString();
Object val = ois.readObject();
data.put(name,val);
//loop mbean attribute info, restoring each field via it's set.
//that way attributes can be removed without failing to restore
//object
//Probably also want a state=LOADING, to avoid change notifications
//from being fired off when calling the setXXX()
}
setData(){
//loop attributeinfo[], and store name+serialized(val)
}
The idea here being someone can override getData() setData() to change
the storage format.
And since the EJB to perform storage would be configurable in the base
class (or maybe a more generic PM type class), the user could switch
datastore depending on needs of the specific mbean instance.
And if they want the CMP type store, they could always re-define the DD,
and deploy it under a different name to get different performance
abilities.
I also don't require a seperate interface to define the mbeans external
interface.
I have a Class[] getInterfaces method, that by default returns just
getClass()
So, if you want to take any stand alone class and make it an MBean, you
only need to extend my dynamic base class. I just publish any public
method as a operation/attribute (depending on name/params).
And was planning to add a dynamic mbean proxy type thing, where you just
pass it a class, and it reflects on that class. So if there is already
an existing object that extends something else, you can just MBeanify it
by specifing the class name, and constructor params (optional).
ok. That is probably a shit load more than you wanted to hear. But,
after a pot of coffee, and a 2 liter bottle of diet coke, I get a little
type-happy.
I'll shut up now.
-David
On Fri, 30 Nov 2001, marc fleury wrote:
Upon re-reading your email I realize you already implemented the dmbean
approach yourself, so keep that on the warmer and you could be making a
significant contribution next week :)
My question is how do you feed data to that dmbean? how do you configure it?
where are your files? how do you persist them? do you persist changes? do
you cluster them easily? that is part of what we are trying with the
mmbeans... post snippets if you can
marcf
|-Original Message-
|From: marc fleury [mailto:[EMAIL PROTECTED]]
|Sent: Friday, November 30, 2001 1:34 PM
|To: David Budworth; [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] Service MBeans questions
|
|
|funny you mention, I am actually looking at this right this minute.
|
|The state stuff as part of the serviceMBean was defined by Rickard.
|
|It makes total sense. It is going to be part of the JSR77 spec the
|state stuff is. I know the Iona guy and myself pushed for the
|adoption of the state stuff, just give you a runtime view of who
|is active and all.
|
|So it is going to be a part of the spec to be sure whether you
|need or not I don't know.
|
|What I have a problem with is with the implementation of
|ServiceMBeanSupport
Re: [JBoss-dev] Service MBeans questions
I was wondering about RequiredModelMBean. Why is it called Required? Just so the JMX agent creators know it must be implemented? It seems kinda weird that they would force the prefix Required. -David On Fri, 30 Nov 2001, Trevor Squires wrote: On Fri, 30 Nov 2001, marc fleury wrote: On the point of MBean not being declared, we are moving to the dynamic mbean route, well in fact the ModelMBean and since juha is almost done with Interesting about the ModelMBean direction. I recently spent some time trying to use RequierdModelMBean and ran into some severe issues (which I haven't had time to revisit). Namely that I couldn't get RMMB to expose attributes without exposing the getter/setter operations for the attributes as well. Apart from it seeming a bit lame (and I think contrary to the spec) it also meant that attribute change notifications weren't getting fired if you did an invoke() on the exposed operation. Just a head's-up I guess, that RMMB may be a bit goofy (or just easy to use incorrectly (!)). Trev ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-service.xml naming in SAR files
Is there a reason why your SAR must call the file jboss-service.xml? If we deploy services as XML only, any name *-service.xml works, but in a sar we require it to be jboss-service.xml It seems kind of inconsistent. It seems usefull to be able to make a sar contain multiple *-service.xml files for people who (for deployment ease), repackage several sars into one. Right now, we would require them to actually merge the xml to do that. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server QueueManager.java QueueManagerMBean.java TopicManager.java TopicManagerMBean.java
User: dbudworth
Date: 01/11/29 15:10:09
Modified:src/main/org/jboss/mq/server QueueManager.java
QueueManagerMBean.java TopicManager.java
TopicManagerMBean.java
Log:
Added JNDI name property.
Defaults to [topic|queue]/[topicname|queuename]
It doesn't enforce topics or queues to be listed under topic/* | queue/*, so that
may need to be changed (I don't know if that's a requirement, but testing seemed to
work out ok).
Revision ChangesPath
1.7 +39 -14jbossmq/src/main/org/jboss/mq/server/QueueManager.java
Index: QueueManager.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/QueueManager.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- QueueManager.java 2001/11/28 00:55:29 1.6
+++ QueueManager.java 2001/11/29 23:10:09 1.7
@@ -29,13 +29,16 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author a href=[EMAIL PROTECTED]Hiram Chirino/a
- * @version$Revision: 1.6 $
+ * @version$Revision: 1.7 $
*/
public class QueueManager extends ServiceMBeanSupport implements QueueManagerMBean
{
JMSQueue destination;
SpyQueue queue;
String queueName;
+ String jndiName;
+ boolean jndiBound = false;
+
private ObjectName jbossMQService;
/**
@@ -111,19 +114,10 @@
server.addDestination(queue, destination);
//server.getPersistenceManager().initQueue(destination);
server.getPersistenceManager().restoreQueue(destination, queue);
- //Get an InitialContext
- InitialContext ctx = new InitialContext();
- javax.naming.Context subctx;
- try
- {
- subctx = (javax.naming.Context)ctx.lookup(queue);
- }
- catch (javax.naming.NamingException e)
- {
- subctx = ctx.createSubcontext(queue);
- }
- Util.rebind(subctx,queueName,queue);
-
+ if (jndiName == null)
+ setJNDIName(queue/+queueName);
+ else
+ setJNDIName(jndiName); //in config phase, all we did was store the name,
and not actually bind
}
protected void stopService()
@@ -139,5 +133,36 @@
throw new MalformedObjectNameException(Property 'name' not provided);
}
return name;
+ }
+
+ /**
+* Sets the JNDI name for this queue
+* @param name Name to bind this queue to in the JNDI tree
+*/
+ public synchronized void setJNDIName(String name) throws Exception{
+ if (queue == null){ //nothing to bind yet, startService will recall us
+ jndiName = name;
+ return;
+ }
+ if (name == null)
+ throw new InvalidAttributeValueException(Queue JNDI names can't be null);
+ InitialContext ic = new InitialContext();
+ if (jndiName != null jndiBound){
+ Util.unbind(ic,jndiName); //Remove old jndi name
+ jndiName = null;
+ jndiBound = false;
+ }
+ Util.rebind(ic,name,queue);
+ jndiName = name;
+ jndiBound = true;
+ log.info(Bound queue '+queueName+' to JNDI name '+jndiName+');
+ }
+
+ /**
+* Gets the JNDI name use by this queue
+* @return The JNDI name currently in use
+*/
+ public String getJNDIName(){
+ return jndiName;
}
}
1.6 +13 -1 jbossmq/src/main/org/jboss/mq/server/QueueManagerMBean.java
Index: QueueManagerMBean.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/QueueManagerMBean.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- QueueManagerMBean.java2001/11/10 21:38:05 1.5
+++ QueueManagerMBean.java2001/11/29 23:10:09 1.6
@@ -15,7 +15,7 @@
* @author a href=[EMAIL PROTECTED]Hiram Chirino/a
* @author a href=mailto:[EMAIL PROTECTED];david jencks/a
* @seerelated
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public interface QueueManagerMBean
extends ServiceMBean
@@ -46,4 +46,16 @@
* @param v Value to assign to JBossMQService.
*/
void setJBossMQService(ObjectName jbossMQService);
+
+ /**
+* Sets the JNDI name for this queue
+* @param name Name to bind this queue to in the JNDI tree
+*/
+ void setJNDIName(String name) throws Exception;
+
+ /**
+* Gets the JNDI name use by this queue
+* @return The JNDI name currently in use
+*/
+ String getJNDIName();
}
1.7 +40 -13jbossmq/src/main/org/jboss/mq/server/TopicManager.java
Index: TopicManager.java
===
RCS file:
Re: [JBoss-dev] SQL table constraints name unique?
Depends on the DBMS I suppose. But I believe that constraints are in the same namespace as the tables in most (if not all) DMBSs so your example should work fine. (Of course assuming the DBA didn't happen to create a PKPRODUCT table somewhere) As for if they need to be universally unique, that's really a DMBS issue. Example: PGSQL has one namespace for the database instance. So there can only be one table/constraint/object with a specific name. Users tom and bob share the single namespace. ORACLE on the other hand, has a seperate namespace for each user. So, if you logged in as tom, and created Product/pkProduct What actually gets created is tom.Product and tom.pkProduct But if bob logs in, it's bob.Product and bob.pkProduct So, I guess i'd say that you only need to be unique in a single DB pool (assuming there aren't 2 pools with the same credentials/connection props) I'm not sure with other DBMSs, but with oracle, you can leave out the constraint name, and it will generate it for you. So you don't have to worry about uniqueness. But I'm not sure that's universal to all DBMSs. -David On Thu, 29 Nov 2001, Dain Sundstrom wrote: Does a table constraint name need to be universally unique, unique within the table, or not unique at all? By constraint name, I mean pkProduct and fkCategory in the SQL that follow: CREATE TABLE product (id VARCHAR(40), name VARCHAR(100), category VARCHAR(40), ... CONSTRAINT pkProduct PRIMARY KEY (id), CONSTRAINT fkCategory FOREIGN KEY (category) REFERENCES categroy(id)) -dain ___ 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] JMS queue names (again)
Ok, now that we have the ability to set the JNDI name on a queue/topic, I would like to fix the bug (that I put in) in regards to deep queue names. For simplicities sake, I'll just revert the file PM back to the way it was. But, since there was (and will be when I revert) a bug there that if you create a queue/topic with depth (ie: mycompany/queues/q1) The File PM will fail at next startup. So, I'd like to add some name validation. Is anyone uncomfortable if I enforce the queue names to be alpha-numeric only? (via, Character.isLetterOrDigit()) JBoss (as it ships), doesn't define any topics/queues that would violate that rule right now. Opinions? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS queue names (again)
After taking a shot at implementing this, by way of making the QueueManager and TopicManager's startService() function do the validation and throw if it fails, I find that the MBean get's stuck in the JMX tree. Is this a MBeanServer bug? (where a bean doesn't go away when an exception is thrown by start())? I've seen this before. So I think it is. But I don't want to commit my code just in case it's my bug. (since it requires a jboss restart to make it go away). -David On Thu, 29 Nov 2001, David Budworth wrote: Ok, now that we have the ability to set the JNDI name on a queue/topic, I would like to fix the bug (that I put in) in regards to deep queue names. For simplicities sake, I'll just revert the file PM back to the way it was. But, since there was (and will be when I revert) a bug there that if you create a queue/topic with depth (ie: mycompany/queues/q1) The File PM will fail at next startup. So, I'd like to add some name validation. Is anyone uncomfortable if I enforce the queue names to be alpha-numeric only? (via, Character.isLetterOrDigit()) JBoss (as it ships), doesn't define any topics/queues that would violate that rule right now. Opinions? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] lib/ext into CLASSPATH
hmm, it never occured to me to do that. Much better solution. (When I wrote the script, it was when I started using RH, so I didn't yet know about *service.xml). I am curious though, is there a reason you don't just add lib/ext/*.jar automagically? (as though they were specified with *service.xml) -David On Thu, 29 Nov 2001, David Jencks wrote: I suggest that you make a budworth-service.xml file with no mbeans, only including a classpath element with the jars you want. Put this in deploy, and voila, they will be loaded automatically. No messing with startup classpath necessary. They can be redeployed while the server is running. This won't clean hypersonic for you, though, david jencks On 2001.11.29 15:28:44 -0500 David Budworth wrote: I know what he's talking about. And you are correct Hunter, lib/ext/*.jar is no longer in the class path. For support classes for your EJBs (ie webmacro.jar, whatever), you need to add them to the classpath at startup (ie JBOSS_CLASSPATH) Or, unrolltem into you ejb.jar file and war file before you deploy. Prior to 3.0, everything from lib/ext was auto-added to the CP. I believe that the plan is to allow people to drop the standalone jars into deploy, but that is not implemented yet (or maybe I missed the CVS update message and it's already there) To make my stuff work, I made my own jboss starter script called sjboss: #!/bin/bash cd ~/jboss/bin PLIB=$HOME/proxeno/lib PACKAGE_PREFIX=proxeno CP=$PLIB/webmacro.jar CP=$CP:$PLIB/jakarta-oro-2.0.4.jar CP=$CP:$PLIB/oracle9i.jar if [ $1 != -noclean ]; then if [ -d ../db/hypersonic ]; then echo Purging Hypersonc DB rm -r ../db/hypersonic mkdir ../db/hypersonic fi FILES=`find ../deploy -name $PACKAGE_PREFIX*` for F in $FILES; do echo Removing $F rm $F done fi export JBOSS_CLASSPATH=$CP exec ./run.sh Note, I just use this for development, as nuking your database/jars at startup in production would be a bad thing. But you get the idea. -David On Thu, 29 Nov 2001, Julian Gosnell wrote: --- David Jencks [EMAIL PROTECTED] wrote: On 2001.11.29 01:01:57 -0500 Hunter Hillegas wrote: Am I incorrect that RH adds every jar in lib/ext to the CLASSPATH? yes I'm having trouble with my app locating stuff from a jar in that location so I'm wondering if I'm wrong about this... You need to put it into a *service.xml classpath element or pack the jar into a deployed sar. david jencks Hunter I might have missed something here - but it sounds like you are talking at cross-purposes. Hunter has a problem with an ear/war/jar. David is describing a solution for a sar. Hunter, could you be a little more specific ? What is the class/jar ? Are you trying to use it from the web-tier or the ejb-tier. Am I just confusing matters ? Jules ___ 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 __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS queue names (again)
The current problem is that the queue name specified in the mbean descriptor (Or created via the 8082 interface), get's taken literally and used as the directory to store the persistent messages. So: mbean code=org.jboss.mq.server.QueueManager name=JBossMQ:service=Queue,name=myCompany/myQueue mbean-ref name=JBossMQServiceJBossMQ:service=Server/mbean-ref /mbean attempts to create a directory: db/jbossmq/file/QUEUE.myCompany/myQueue Which would not be valid except on unix FSs This deploy fine, but the real problem comes on restart of jboss. The file PM attempts to pre-restore all queues before they are deployed, and to do this, it does a db/jbossmq/file/.listFiles() and assume that those were the actual queue names (minus the QUEUE.). Which would fail to restore the message log since ...file/QUEUE.myCompany is in fact just the parent dir for the message store for myCompany/myQueue I added code that recognized this. But of course I wasn't thinking of the non-unix folks, where using the queuename literally as the dir name might not be valid for their fs. Personally, I don't like having the queuename map directly to the FS names, I'd much rather have generated dir names, and a map file. But that makes human administration of the FS a little more complex, and I didn't get a response from anyone if that was ok to do. And not knowning if the queuename-dirname mapping was for a reason, I didn't want to change it. I don't know what are valid FS chars for each OS, which is why I suggested making is alpha-numeric restricted. (example, can you have a comma in a AS400 filename?) -David On Thu, 29 Nov 2001, Scott M Stark wrote: That would seem to be a little too restrictive a naming requirement. Using isJavaIdentifierPart may be more acceptable. What is the current naming problem? - Original Message - From: David Budworth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 29, 2001 5:22 PM Subject: [JBoss-dev] JMS queue names (again) Ok, now that we have the ability to set the JNDI name on a queue/topic, I would like to fix the bug (that I put in) in regards to deep queue names. For simplicities sake, I'll just revert the file PM back to the way it was. But, since there was (and will be when I revert) a bug there that if you create a queue/topic with depth (ie: mycompany/queues/q1) The File PM will fail at next startup. So, I'd like to add some name validation. Is anyone uncomfortable if I enforce the queue names to be alpha-numeric only? (via, Character.isLetterOrDigit()) JBoss (as it ships), doesn't define any topics/queues that would violate that rule right now. Opinions? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS queue names (again)
Ok, I did some research. On my machine (linux), I can't create a bad queue name to make it throw an exception (all chars are valid in file names). I had already nuked my validation code, so I'll have to test a bit more to make queue creation fail. What I suspect is, when the new queue mbean fails to start (due to validation errors), and the MBean is left around, that you can't destroy the topic via Queue manager anymore (but that's a hunch). When I say fail on bad name, I mean when creating it via the JMX server mbean on 8082. But in what I did test, I found that mbean code=some.crashing.class name=Domain:name=ThisCrashesAtStart/ and mbean code=some.noncrashing.class name=Domain:name=ThisDoesntCrash mbean-refDomain:name=ThisCrashesAtStartmbean-ref /mbean What will happen is you start the first one and, as expected, it crashes. But since it's left in the JMX tree, you have satisfied MBean #2 dependancy, so it starts. I think this is bad since #2 assumes #1 is a working MBean. Since start() is called automatically on and service mbean, I would expect start() to be a requirement for deployment. And if it fails to start, it fails to deploy. As it is now, you have a reference to a broken bean. Or am I totally missing the point of MBean refs in general? The way I look at the whole service mbeans + mbean refs is like unix init scripts. I understand that if you programatically add a mbean, and it's start fails you may want to attempt to fix it, and restart. But that idea doesn't make sense from the auto-deployer point of view. No one is going to fix it on the fly (unless JBoss gets a new fancy code generating AI engine in it) I haven't tried this, but if you create an mbean from code, does it's start() get called automatically?, or do you have to manually call start() after you get back the ObjectInstance? If it's called automatically, and providing you can specify initial attribute values when you create the mbean, then I don't see why you shouldn't fail to attach the mbean to the JNDI tree on start() failure. Actually, I would expect: 1) Create object instace 2) bind to JMX tree (because maybe start tries to look itself up) 3) call start 4a) if start failed, remove from tree 4b) if not, go poke all waiting mbeans for reference resoltion Keep in mind here, I haven't read the JMX spec, so if bind it to the tree is not something that makes sense, or is something we have no control of, then slap me with a fish. -David On Thu, 29 Nov 2001, David Jencks wrote: On 2001.11.29 21:06:27 -0500 David Budworth wrote: After taking a shot at implementing this, by way of making the QueueManager and TopicManager's startService() function do the validation and throw if it fails, I find that the MBean get's stuck in the JMX tree. Is this a MBeanServer bug? (where a bean doesn't go away when an exception is thrown by start())? I've seen this before. So I think it is. But I don't want to commit my code just in case it's my bug. (since it requires a jboss restart to make it go away). Looking harder at the code Does undeploy(objectName) really not work, and undeploying the package that created the mbean doesn't work? What is the exception start throws? I'm reluctant to make a start() failure destroy the mbean, because not all mbeans are created through ServiceDeployer and reading xml. Furthermore mbeans can be started long after they are created... after dependencies are resolved. The guy who created the mbean might want an opportunity to fix the config if start fails. Do you have a little example? david jencks -David On Thu, 29 Nov 2001, David Budworth wrote: Ok, now that we have the ability to set the JNDI name on a queue/topic, I would like to fix the bug (that I put in) in regards to deep queue names. For simplicities sake, I'll just revert the file PM back to the way it was. But, since there was (and will be when I revert) a bug there that if you create a queue/topic with depth (ie: mycompany/queues/q1) The File PM will fail at next startup. So, I'd like to add some name validation. Is anyone uncomfortable if I enforce the queue names to be alpha-numeric only? (via, Character.isLetterOrDigit()) JBoss (as it ships), doesn't define any topics/queues that would violate that rule right now. Opinions? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] org.jboss.naming.Util feature question
I was just wondering if anyone would like org.jboss.naming.Util to have an unbind feature. Unbinding by hand is easy enough, but I need (and am using in a subclass of Util for my own project) the ability to make unbind remove the intermediate contexts if they are empty. ie: A/B/C/val1 A/B/C/val2 A/D/val3 unbind(A/B/C/val1) would only remove val1 from the A/B/C context then doing unbind(A/B/C/val2) // after you already unbound val1 wiht remove val2, C, B contexts (but not A since it had more than one subcontext) I'd like to add this to the Util class, but wasn't sure if anyone else thought it was usefull, or what it should be called. I call mine unbind, because it's the opposite of bind() which creates subctx. But the unweary may not realize that it nukes intermediates. So maybe call it unbindTree ? -David p.s. Do people normally just add stuff and wait for someone to complain? If so, I'll stop posting questions about these little mods, and just implement them, and fix em if someone bitches. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.naming.Util feature question
You can do that already with a normal context. You can nuke any context and all children go away. The reason I am using this, is because my JNDI names for JMS queues are deep. And when a queue gets undeployed, I think we shouldn't leave the parent contexts sitting around for no reason. But yes, my unbind function does indeed remove the specified name, and all subcontexts. On Wed, 28 Nov 2001, Scott M Stark wrote: This doesn't sound too useful unless given: A/B/C/val1 A/B/C/val2 A/D/val3 I can do Util.unbind(A) to wipe out A and its entire tree in one call similar to rm -rf on a directory. If that is what you indicating then its a useful option. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Budworth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 28, 2001 12:39 PM Subject: [JBoss-dev] org.jboss.naming.Util feature question I was just wondering if anyone would like org.jboss.naming.Util to have an unbind feature. Unbinding by hand is easy enough, but I need (and am using in a subclass of Util for my own project) the ability to make unbind remove the intermediate contexts if they are empty. ie: A/B/C/val1 A/B/C/val2 A/D/val3 unbind(A/B/C/val1) would only remove val1 from the A/B/C context then doing unbind(A/B/C/val2) // after you already unbound val1 wiht remove val2, C, B contexts (but not A since it had more than one subcontext) I'd like to add this to the Util class, but wasn't sure if anyone else thought it was usefull, or what it should be called. I call mine unbind, because it's the opposite of bind() which creates subctx. But the unweary may not realize that it nukes intermediates. So maybe call it unbindTree ? -David p.s. Do people normally just add stuff and wait for someone to complain? If so, I'll stop posting questions about these little mods, and just implement them, and fix em if someone bitches. ___ 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] CVS update: jboss/src/main/org/jboss/naming Util.java
User: dbudworth
Date: 01/11/28 17:48:48
Modified:src/main/org/jboss/naming Util.java
Log:
Added unbind(ctx,name), which removed all parents provided they are empty
after the named node is unbound.
May want to rename this to unbindTree if people get confused with the
parental removal
Revision ChangesPath
1.8 +32 -1 jboss/src/main/org/jboss/naming/Util.java
Index: Util.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/naming/Util.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Util.java 2001/11/07 01:58:21 1.7
+++ Util.java 2001/11/29 01:48:48 1.8
@@ -14,7 +14,7 @@
/** A static utility class for common JNDI operations.
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.7 $
+ * @version $Revision: 1.8 $
*/
public class Util
{
@@ -106,5 +106,36 @@
String atom = name.get(size-1);
Context parentCtx = createSubcontext(ctx, name.getPrefix(size-1));
parentCtx.rebind(atom, value);
+}
+
+/** Unbinds a name from ctx, and removes parents if they are empty
+ @param ctx, the parent JNDI Context under which the name will be unbound
+ @param name, The name to unbind
+ */
+public static void unbind(Context ctx, String name)
+throws NamingException
+{
+unbind(ctx,ctx.getNameParser().parse(name));
+}
+
+/** Unbinds a name from ctx, and removes parents if they are empty
+ @param ctx, the parent JNDI Context under which the name will be unbound
+ @param name, The name to unbind
+ */
+public static void unbind(Context ctx, Name name)
+ throws NamingException
+{
+ ctx.unbind(name); //unbind the end node in the name
+ int sz = name.size();
+ //walk the list backwards, stopping at the domain since I don't know if
+ //a domain can be unbound this way.
+ while (--sz 0) //walk the tree backwards, stopping at the domain
+ {
+ Name pname = name.getPrefix(sz);
+ if (ctx.listBindings(pname).hasMore()) //if we have more children stop now
+ break;
+ else
+ ctx.unbind(pname); //must be no children, nuke it and continue
+ }
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David On Tue, 27 Nov 2001, Hiram Chirino wrote: From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Date: Mon, 26 Nov 2001 23:26:02 -0500 On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! Sounds about right. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? I feel like I've seen 10 or twenty implementations of this, but its probably just 3 or 4;-) They are often in Deployers. Could we put one version in either DeployerMBeanSupport or ServiceMBeanSupport? The MBean classes don't seem to ME to be the right place for the kind of code. Maybe a new JNDISupport in the org.jboss.util?? Regards, Hiram David Jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ 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] JMS issues re: stopservice, jndi names
Sorry to follow up my own message, but I need another question answered. Note: In the previous message, I was incorrectly saying db/messaging, it's really db/jbossmq/file Is it possible to have queues named: companyA companyA/myqueue1 companyA/myqueue2 I'm changing (in anticipation that deep queues are valid), the file pm for queues. It currently just get's a list of all files in db/jbossmq/file/ Then attempts to restore the MessageLogs for each file in that list. When MessageLog attempts to restore, it just looks for a . in the name (ie: QUEUE.bob), and restores all messages files in that dir, if no . is there it assumes the file is a message log and attempts to restore it directly, which is why my stuff is failing, because it looks like QUEUE.companyA/myqueue1/* But the restoration code assumes myqueue1 is a file, and not a subdir (because no .) It seems to me, that a much easier fix is to not restore the queue on startup, but instead restore in when the DD is deployed. But I suppose there may be a need to restore a queue before it's actually defined? The auto-restored queues doesn't show up in the 8082 UI (BTW what's that called?). So I am not sure why the PM is creating an instance of MessageLog for them at startup. Am I just not getting it? -David On Tue, 27 Nov 2001, David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David On Tue, 27 Nov 2001, Hiram Chirino wrote: From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names Date: Mon, 26 Nov 2001 23:26:02 -0500 On 2001.11.26 22:50:55 -0500 David Budworth wrote: Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. I'm not the most expert... but I think the queue stop method needs to arrange with the JMSService to stop accepting messages and possibly with the persistence manager to make sure everything is stably saved that should be. Make sure all open transactions are ended before shutting down! Sounds about right. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? I feel like I've seen 10 or twenty implementations of this, but its probably just 3 or 4;-) They are often in Deployers. Could we put one version in either DeployerMBeanSupport or ServiceMBeanSupport? The MBean classes don't seem to ME to be the right place for the kind of code. Maybe a new JNDISupport in the org.jboss.util
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
So, why do we pre-restore the message queues? And not just restore them when a queue deploys? It seems to be a waste of memory to load an entire queue 'just in case' it gets deployed. Is there any reason why I couldn't just move the code from restoreTransactions() (which is called only by startService()) to restoreDestination() which currently seems to just take the messages out of the cache created by restoreTransactions(). -david On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 15:55:06 -0500 David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it pre-restores all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles prepared but not committed properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
Nevermind, problem fixed. I just changed how it finds the directories on restoreTransactions(), and made it ignore them in MessageLog.restore() I'll commit after some testing. -David On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 17:21:31 -0500 David Budworth wrote: So, why do we pre-restore the message queues? And not just restore them when a queue deploys? It seems to be a waste of memory to load an entire queue 'just in case' it gets deployed. Is there any reason why I couldn't just move the code from restoreTransactions() (which is called only by startService()) to restoreDestination() which currently seems to just take the messages out of the cache created by restoreTransactions(). Maybe you can make it work. I didn't see any way to, and I couldn't figure out any way to test it either. So I tried to change it as little as possible. You will definitely have to keep track of the recovered transaction info until all queues are restored: detecting this may me another trick. I thought it was way simpler to process it all at once when the pm started. Why is this causing you problems? I don't see the connection to the namespace issues. david jencks -david On Tue, 27 Nov 2001, David Jencks wrote: On 2001.11.27 15:55:06 -0500 David Budworth wrote: Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was mycompany/myqueue, which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it pre-restores all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles prepared but not committed properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server QueueManager.java TopicManager.java
User: dbudworth
Date: 01/11/27 16:55:29
Modified:src/main/org/jboss/mq/server QueueManager.java
TopicManager.java
Log:
Added support for deep topic and queue names
Passes run-basic-testsuite, so if something is broken the test needs updating.
TopicManager/QueueManager, uses org.jboss.naming.Util to auto-create subcontexts
PersistenceManager/MessageLog updated to support deep subdirectories in
db/jbossmq/file
Revision ChangesPath
1.6 +4 -2 jbossmq/src/main/org/jboss/mq/server/QueueManager.java
Index: QueueManager.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/QueueManager.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- QueueManager.java 2001/11/10 21:38:05 1.5
+++ QueueManager.java 2001/11/28 00:55:29 1.6
@@ -21,13 +21,15 @@
import org.jboss.mq.*;
import org.jboss.system.ServiceMBeanSupport;
+import org.jboss.naming.Util;
+
/**
* This class is a message queue which is stored (hashed by Destination) on the
* JMS provider
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author a href=[EMAIL PROTECTED]Hiram Chirino/a
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class QueueManager extends ServiceMBeanSupport implements QueueManagerMBean
{
@@ -120,7 +122,7 @@
{
subctx = ctx.createSubcontext(queue);
}
- subctx.rebind(queueName, queue);
+ Util.rebind(subctx,queueName,queue);
}
1.6 +3 -3 jbossmq/src/main/org/jboss/mq/server/TopicManager.java
Index: TopicManager.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/TopicManager.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TopicManager.java 2001/11/10 21:38:05 1.5
+++ TopicManager.java 2001/11/28 00:55:29 1.6
@@ -22,6 +22,7 @@
import org.jboss.mq.*;
import org.jboss.system.ServiceMBeanSupport;
import org.jboss.mq.DurableSubcriptionID;//Typo!!!
+import org.jboss.naming.Util;
/**
* This class is a message queue which is stored (hashed by Destination) on the
@@ -29,7 +30,7 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author a href=[EMAIL PROTECTED]Hiram Chirino/a
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class TopicManager
extends ServiceMBeanSupport
@@ -124,8 +125,7 @@
{
subctx = ctx.createSubcontext(topic);
}
- subctx.rebind(topicName, topic);
-
+ Util.rebind(subctx,topicName,topic);
}
protected void stopService()
___
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 MessageLog.java PersistenceManager.java
User: dbudworth
Date: 01/11/27 16:55:29
Modified:src/main/org/jboss/mq/pm/file MessageLog.java
PersistenceManager.java
Log:
Added support for deep topic and queue names
Passes run-basic-testsuite, so if something is broken the test needs updating.
TopicManager/QueueManager, uses org.jboss.naming.Util to auto-create subcontexts
PersistenceManager/MessageLog updated to support deep subdirectories in
db/jbossmq/file
Revision ChangesPath
1.8 +4 -1 jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java
Index: MessageLog.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- MessageLog.java 2001/11/14 01:53:40 1.7
+++ MessageLog.java 2001/11/28 00:55:29 1.8
@@ -29,7 +29,7 @@
*
* @createdAugust 16, 2001
* @author:Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public class MessageLog {
@@ -83,6 +83,9 @@
try {
File[] files = queueName.listFiles();
for ( int i = 0; i files.length; i++ ) {
+// If it's a subdirectory, it's a different queue, PM will restore that
also, so ignore it here
+if (files[i].isDirectory())
+ continue;
String fileName = files[i].getName();
int extIndex = fileName.indexOf( . );
if ( extIndex 0 ) {
1.11 +37 -4 jbossmq/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.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- PersistenceManager.java 2001/11/14 04:23:27 1.10
+++ PersistenceManager.java 2001/11/28 00:55:29 1.11
@@ -15,12 +15,14 @@
import java.io.File;
+import java.io.FileFilter;
import java.io.IOException;
import java.net.URL;
import java.util.Collection;
import java.util.HashMap;
import java.util.Iterator;
import java.util.LinkedList;
+import java.util.ArrayList;
import java.util.Map;
import java.util.TreeSet;
import javax.jms.JMSException;
@@ -43,7 +45,7 @@
* persistence.
*
* @author Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.10 $
+ * @version$Revision: 1.11 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager
{
@@ -159,6 +161,37 @@
}
/**
+* The codegetDirTreecode function takes a directory and
+* looks for all subdirectories below it (recursively)
+*
+* Note: Recursive function, REALLY deep queues WILL cause stack fault
+* Note: Possible bug if someone implements an unused queue cleanup
+*and it attempts to remove the parent dir of a deep queue
+*without verifying that it's really just a parent dir
+*
+* @param parent The directory to look in
+*
+* @return The deep list of subdirectories
+*/
+ private final File[] getDirTree(File parent)
+ {
+ final ArrayList dirs = new ArrayList(); //must be final
+ parent.listFiles(new FileFilter()
+ {
+ public final boolean accept(File file)
+ {
+if (file.isDirectory())
+{
+ dirs.add(file); //add to list of all dirs
+ file.listFiles(this);
+}
+return false; //avoid File.listFiles doing extra work
+ }
+ });
+ return (File[])dirs.toArray(new File[dirs.size()]);
+ }
+
+ /**
* The coderestoreTransactions/code method is called when the
* PersistenceManager service is started. It reads all transaction log
* files, and pre-restores all messages that are committed and not read.
@@ -170,7 +203,8 @@
private void restoreTransactions() throws javax.jms.JMSException
{
TreeSet txs = new TreeSet();
- File[] transactFiles = dataDirFile.listFiles();
+ File[] transactFiles = getDirTree(dataDirFile);
+ int queueNameOffset = dataDirFile.toString().length()+1;
if(transactFiles != null)
{
for (int i = 0; i transactFiles.length; i++)
@@ -179,8 +213,7 @@
if( transactFiles[i].isDirectory() )
{
String dirName = transactFiles[i].toString();
- int start = transactFiles[i].getParent().length()+1;
- String key = dirName.substring(start);
+ String key =
[JBoss-dev] JMS issues re: stopservice, jndi names
Hi all, There are two things bugging me right now in JMS, and I just wanted to know if anyone is working on them, or if they need to be fixed at all. The first one, is pretty obviously a 'needs-to-be-done'. You can't current undeploy a queue/topic. In my sar, I define the JMS queues that the services use, and when I undeploy the .sar, the log says queue stop not yet implemented. The problem this causes is that once you delete the SAR, the queue name disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, or just create the queue via the 8082 UI, you'll get a an error stating the topic/queue already exists. So it seems that on undeploy, the internal stuctures of JBossMQ gets fux0r3d (in script-kiddie speak). I'd be happy to work on this (since I need it). I just didn't know if anyone else was already doing it. Nor do I really know where to start on it. The second one is just something that bothers me, which is if you specify a queue name like: mycompany/queuea You will get a name not bound exception on mycompany. For EJBs this works correctly, where the subcontexts are created on the fly as need be. But for JMS it doesn't. I'd also like to add this, since I don't like having the JMS topics/queues in a flat namespace. I'm not sure if this is by spec though. Are you not allowed to create a heirarchy for the queue/topic names? If I create transient topics, I can do it if I pre-create the subcontexts. So I know it 'works', I'm just not sure it's legal. Also, is there some helper code somewhere in jboss to create a JNDI tree already? Or does everyone just roll there own with tokenizers or something? -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug #482875: Out of Memory
Yep, you fixed it. Thank you. -David On Sunday 18 November 2001 11:14pm, David Jencks wrote: OK, I think I fixed the can't undeploy broken mbean problem, with a testcase too. (in jmx/test/DeployServiceUnitTestCase). Could you check and make sure I fixed the problem you were seeing? Thanks david jencks On 2001.11.17 23:32:09 -0500 David Budworth wrote: Well, while someone is looking at the hot deploy code, please fix the MBean problem. When you deploy a SAR that has a bad mbean, ie: jboss-service.xml specifies an attribute for a MBean that doesn't really exist, you have to restart jboss to get the mbean to go away. Removing the SAR only removes MBeans that successfully deployed, and not anything that threw deployment exceptions when being deployed. I'm gonna try to fix this myself before I file it as a bug. But if someone is looking at the deploy code, and happens to fix it, please say so. -David On Saturday 17 November 2001 03:57pm, Jason Dillon wrote: jboss.org is afflicted with this bug (i think). in an ideal world a jboss server should not need to be restarted expect to update core componets or the vm in which it runs. I would say that it is a bug. Does the same thing happen when large deployables are used on 3.0? --jason On Sat, 17 Nov 2001, Andreas Schaefer wrote: Hi Geeks Recently this bug was reported on JBoss 2.4 stating that JBoss server runs out of memory when to many hot- deployment with big archives. IMO this is not a bug because when people start to deploy big archives then they have to deal with it. - In Production this should not become a problem and when then a restart of JBoss is necessary - In Development this should not be a big problem to bounce the server. What do you think ? Bugs item #482875, was opened at 2001-11-17 12:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=482875gr oup_ id= 22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Joel Boehland (jolby) Assigned to: Nobody/Anonymous (nobody) Summary: OutOfMemory after many Deploy cycles Initial Comment: I have been seeing OutOfMemoryErrors in my server after doing several deploy/redeploy cycles of my application .ear file (which is around 3 megs in size) Basic info: *Hardware: AMD-K2-400MHz, 196MB RAM *OS: linux 2.2.14 *jdk: Blackdown-1.3.0-FCS, mixed mode *Server: JBoss-2.4.3_Jetty-3.1.3-1 *ServerTrace: I don't have one now, but I can provide one later if needed. *Steps to reproduce: Deploy/Redeploy .ear file many times. My .ear is around 3 megs, so it may be necessary to use a large one to trigger this effect. Other info *I have had this happen using native threads mode, and green threads mode. *Jozsa Kristof [EMAIL PROTECTED] has also reported this error on the jboss-user list. He was using IBM jdk 1.3.0 on linux, so this doesn't appear to be tied to any particular version of the jdk. --Joel --- x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug #482875: Out of Memory
Well, while someone is looking at the hot deploy code, please fix the MBean problem. When you deploy a SAR that has a bad mbean, ie: jboss-service.xml specifies an attribute for a MBean that doesn't really exist, you have to restart jboss to get the mbean to go away. Removing the SAR only removes MBeans that successfully deployed, and not anything that threw deployment exceptions when being deployed. I'm gonna try to fix this myself before I file it as a bug. But if someone is looking at the deploy code, and happens to fix it, please say so. -David On Saturday 17 November 2001 03:57pm, Jason Dillon wrote: jboss.org is afflicted with this bug (i think). in an ideal world a jboss server should not need to be restarted expect to update core componets or the vm in which it runs. I would say that it is a bug. Does the same thing happen when large deployables are used on 3.0? --jason On Sat, 17 Nov 2001, Andreas Schaefer wrote: Hi Geeks Recently this bug was reported on JBoss 2.4 stating that JBoss server runs out of memory when to many hot- deployment with big archives. IMO this is not a bug because when people start to deploy big archives then they have to deal with it. - In Production this should not become a problem and when then a restart of JBoss is necessary - In Development this should not be a big problem to bounce the server. What do you think ? Bugs item #482875, was opened at 2001-11-17 12:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=482875group_ id= 22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Joel Boehland (jolby) Assigned to: Nobody/Anonymous (nobody) Summary: OutOfMemory after many Deploy cycles Initial Comment: I have been seeing OutOfMemoryErrors in my server after doing several deploy/redeploy cycles of my application .ear file (which is around 3 megs in size) Basic info: *Hardware: AMD-K2-400MHz, 196MB RAM *OS: linux 2.2.14 *jdk: Blackdown-1.3.0-FCS, mixed mode *Server: JBoss-2.4.3_Jetty-3.1.3-1 *ServerTrace: I don't have one now, but I can provide one later if needed. *Steps to reproduce: Deploy/Redeploy .ear file many times. My .ear is around 3 megs, so it may be necessary to use a large one to trigger this effect. Other info *I have had this happen using native threads mode, and green threads mode. *Jozsa Kristof [EMAIL PROTECTED] has also reported this error on the jboss-user list. He was using IBM jdk 1.3.0 on linux, so this doesn't appear to be tied to any particular version of the jdk. --Joel --- x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] can't build jboss from cvs
Can you put a package in debian main that depends on a non-free software? Remember, JBoss 3.0 DEPENDS on jdk 1.3.x, and there is no free version of that. Nor is there a .deb for it at all in non-free/contrib. I don't believe IBM has a 1.3x .deb, and kaffe definately doesn't support it. As much as I'd like to see JBoss in debian, I can't see how you can put a dependancy on a JDK that doesn't exist as far as debian is concerned. Or are you somehow putting sun/blackdown in the contrib/non-free tree? On Wednesday 14 November 2001 03:43pm, Adam Heath wrote: On Wed, 14 Nov 2001, Jason Dillon wrote: Why do you need a planet57 .deb ? A package in debian needs to be able to build with software in debian. Since planet57 does not exist in debian, I'm making a deb of it. This way, debian/control can contain a Build-Depends on planet57-buildmagic.deb. This is the automated building I told about. Additionally, having it all available as a deb, and only using free software, allows it to go into debian main, which allows for more wide distribution, then if it were to go into contrib or non-free. ___ 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/main/org/jboss/ejb/plugins/cmp/jdbc JDBCStartCommand.java
User: dbudworth
Date: 01/11/13 19:52:15
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCStartCommand.java
Log:
Added check for relatedCMRField existance in execute.
Was assuming there was one and crashing with NPE when attempting to deploy
1:1 cmr beans
Revision ChangesPath
1.7 +5 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStartCommand.java
Index: JDBCStartCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStartCommand.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JDBCStartCommand.java 2001/09/11 18:35:00 1.6
+++ JDBCStartCommand.java 2001/11/14 03:52:15 1.7
@@ -23,7 +23,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public class JDBCStartCommand extends JDBCUpdateCommand implements StartCommand {
// Constructors --
@@ -43,7 +43,10 @@
// create relation tables
JDBCCMRFieldBridge[] cmrFields = entity.getJDBCCMRFields();
for(int i=0; icmrFields.length; i++) {
-if(!cmrFields[i].hasForeignKey()
!cmrFields[i].getRelatedCMRField().hasForeignKey()) {
+//Verify that there is a related CMR field (to avoid NPE)
+if(!cmrFields[i].hasForeignKey()
+ cmrFields[i].getRelatedCMRField() != null
+ !cmrFields[i].getRelatedCMRField().hasForeignKey()) {
createTable(cmrFields[i].getRelationTableName(),
getRelationCreateTableSQL(cmrFields[i]));
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ANN: Clustering support for Stateful Session Beans
Is it a requirement that EJB 2.0 CMP be complete? 1:1 CMR relations are broken right now (SQL executes out of order cause JDBC exceptions), so you can't remove the master in a relation without first removing the dependant. It appears to me, that this is a bitch to fix, but I'll save that for a new post. Just need to know what my coffee grounds/water ratio should be for the rest of the day. -David On Saturday 10 November 2001 07:25am, marc fleury wrote: OK it seems you guys finished your code in time for the alpha version. We will put an alpha as soon as possible, possibly this weekend, Scott is the man. It will include EJB 2.0 CMP, Clustering, microkernel SAR distribution, and various improvements over the 2.4 basis, the super-server, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha |Labourey |Sent: Saturday, November 10, 2001 5:52 AM |To: Tomas Lapienis; Jboss-Dev |Subject: RE: [JBoss-dev] ANN: Clustering support for Stateful Session |Beans | | |Hello Tomas, | | - Cluster is automagically subdivided in sub-clusters (i.e. | sub-partitions), |which optimal size is user-definable. | | Great! Just a question: | Will Entity Beans be clustered? | |They already are. Search the recent post on the ML for the clustering |keyword, posted by Bill Burke. | |In short, just put clusteredTrue/clustered in the EB definition in |jboss.xml (and launch the clustering services by dragging its xml file in |the deploy directory) | | It might be clustered/failoverreclustered | based on pk hash value (maybe)... | When load balancing is done on SB then | EB clustering for cache speed up would | also be great... | |There is no distributed cache (yet?). Consequently, cache is |useless in this |case (which is the case with many (all?) app servers). | |We use pessimistic locking at the database level. Home invocations are |load-balanced whereas remote invocations for a bean are directed |to the same |node (until it fails). Consequently, load-balancing for entity beans is |performed at creation time (and, sure, at failover time). | | P.S. Basically, it would be nice to have | Entity Bean living in cluster somewhere... | |Then, it *is* nice. ;) | |Cheers, | | | Sacha | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-478783 ] CMR records are deleted out of order
Dain,
Are you actively working on this?
I'd be happy to fix it (in the manner you suggest, not my crack-induced
version of it) if you don't have the time.
All I need is a pointer as to where the execution sequence comes from. (I
suppose I could figure it out, but if you know where it is, it'll save time)
Not trying to push or anything, I just need to know if your working on it so
I can get rid of my cascade-delete tags until the fix gets comitted, or if I
should take a shot at fixing it since I have a re-producable test case for it.
Thanks,
-David
On Tuesday 06 November 2001 01:54pm, you wrote:
Bugs item #478783, was opened at 2001-11-06 09:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=478783group_id
=22866
Category: JBossCMP
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: David Budworth (dbudworth)
Assigned to: Dain Sundstrom (dsundstrom)
Summary: CMR records are deleted out of order
Initial Comment:
In a 1:1 CMR, the master bean is deleted before the
child bean.
If you have:
Order - ShippingAddress
With cascade delete turned on
And you perform Order.remove()
SQL Executed is:
DELETE FROM order WHERE id = ?
UPDATE order SET shippingaddress_id = ? WHERE id = ?
Which is really hard to do in a database
I believe that it should be:
DELETE FROM shippingaddress WHERE id = ?
UPDATE order SET shippingaddress = ? WHERE id = ?
DELETE FROM order WHERE id = ?
(Yes, I know it doesn't make sense to update order
right before you delete it, but it seems to be a
byproduct of the interceptor stack system)
Note: The above is a simplified version of my
relations. My actual relation (in case it matters)
is:
Customer --1:n-- Order --1:1-- ShippingAddress
And this happens when I call Customer.remove()
--
Comment By: Dain Sundstrom (dsundstrom)
Date: 2001-11-06 13:54
Message:
Logged In: YES
user_id=251431
You are on crack. :)
The spec says After the bean provider#8217;s ejbRemove()
method returns (and prior to returning to the client), the
Container must remove the entity object from all
relationships in which it participates, and then remove its
persistent representation... After removing the entity
object from all relationships and removing its persistent
representation, the Container must then cascade the
removal to all entity beans with which the entity had been
previously been in container-managed relationships
for which the cascade-delete option was specified. So this
is what happens when you run order.remove():
1. the bean provider#8217;s ejbRemove()method returns
2. remove the entity object from all relationships in
which it participates
UPDATE order SET shippingaddress_id = ? WHERE id = ?
3. then remove its persistent representation
DELETE from order where id = ?
4. cascade the removal to all entity beans with which the
entity had been previously been in container-managed
relationships for which the cascade-delete option was
specified
DELETE FROM shippingaddress where ID = ?
Follow?
This means that not null foreign keys do not currently
work. The spec did give us a way out of this in footnote
11 (At this point it must appear to the application that
the entity has been removed from the persistent store. If
the container employs an optimistic caching strategy and
defers the removal of the entity from the database (e.g.,
to the end of transaction), this must be invisible to the
application.), but this feature has not been implemented
yet.
-dain
--
Comment By: David Budworth (dbudworth)
Date: 2001-11-06 13:01
Message:
Logged In: YES
user_id=343354
Which spec version are you reading?
ejb-2_0-fr-spec.pdf says:
As with the remove operation. the removal triggered by
the cascade-delete option causes the container to invoke
the ejbRemove() method on the entity bean instance that is
to be removed before the persistent representation of that
entity object is removed
That to me sounds like :
shippingaddress.remove(){
DELETE FROM shippingaddress where ID = ?
}
order.store(){
UPDATE order SET shippingaddress_id = ? WHERE id = ?
}
order.remove(){
DELETE from order where id = ?
}
Maybe I have the wrong spec? Or am I just on crack and
not reading it correctly (entirely possible)
--
Comment By: Dain Sundstrom (dsundstrom)
Date: 2001-11-06 10:12
Message:
Logged In: YES
user_id=251431
The ejb 2.0 final draft spec requires that the persistence
representation is removed then the related entieites are
cascad-deleted (section 10.3.4.2). This means that the
following sql should be executed:
UPDATE order SET shippingaddress_id = ? WHERE id = ?
DELETE FROM order WHERE id = ?
DELETE FROM
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
User: dbudworth
Date: 01/11/02 18:07:41
Modified:src/main/org/jboss/ejb/plugins CMPPersistenceManager.java
Log:
added more descriptive NoSuchMethodException throw. Default version didn't
specify what class or what method, requiring users to look in the jboss source
to find out what method was missing. The method name createMethodCache()
sounds more like create a method cache, and not create a create method cache
So the stack trace was pretty much useless.
Revision ChangesPath
1.33 +8 -3 jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
Index: CMPPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- CMPPersistenceManager.java2001/10/09 00:59:39 1.32
+++ CMPPersistenceManager.java2001/11/03 02:07:41 1.33
@@ -53,7 +53,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Dan Christopherson/a
* @author a href=mailto:[EMAIL PROTECTED];Bill Burke/a
* @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a
-* @version $Revision: 1.32 $
+* @version $Revision: 1.33 $
*
* Revisions:
* 20010621 Bill Burke: removed loadEntities call because CMP read-ahead is now
@@ -156,8 +156,13 @@
{
if (methods[i].getName().equals(create))
{
-createMethods.put(methods[i], con.getBeanClass().getMethod(ejbCreate,
methods[i].getParameterTypes()));
-postCreateMethods.put(methods[i],
con.getBeanClass().getMethod(ejbPostCreate, methods[i].getParameterTypes()));
+ try{
+ createMethods.put(methods[i],
con.getBeanClass().getMethod(ejbCreate, methods[i].getParameterTypes()));
+ postCreateMethods.put(methods[i],
con.getBeanClass().getMethod(ejbPostCreate, methods[i].getParameterTypes()));
+ }
+ catch (NoSuchMethodException nsme){
+ throw new NoSuchMethodException(Can't find
ejb[Post]Create in +con.getBeanClass().getName());
+ }
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Templating services
That wouldn't really work, because some of the objects may have a late loading semantic. A CMP2 bean with CMR fields for example. If I toString()ed it, I'd 1) lose all the unique fields 2) never get CMR data Plus, the data map is sent from the client, so it's too late once the MBean gets it. Anyone know if calling an MBean in VM with the client passes pointers? Or does it serialize? I would expect, that this kind of service would really need to be on every app server instance anyway. -David Budworth -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ken Jenks Sent: Monday, October 29, 2001 4:36 AM To: Jboss-Development Subject: Re: [JBoss-dev] Templating services You could try using each object's toString() method and merging that with a Velocity template at run-time. Use the MBean to associate each object with a template. Every object already has a toString() method and a String is already guaranteed to be serializable, so you're most of the way there. That could be the default behavior. You could allow the programmer to specify the name of the String method in the MBean, so you could use MyObject.toWebMacroString() for one and MyObject.toVelocityString() for the other, or add support for different template engines in the future. For example, I usually have a toXML() method in my objects and I could use that to send the object straight through a template to a Web or WAP user without having to go through a servlet or JSP front end. And auto-determin the template engine to use (WebMacro prefers .wm, and Velocity has some other extensions (I don't remember exactly which right now)) That would be .vm. -- Ken Jenks, http://abiblion.com/ Tools for reading. ___ 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] Templating services
It has been brought to my attention that the term Web-Monkey might be offensive to some. Being new to the list, and trying not to piss everyone off, let me clarify. I meant no offense by the term. In my previous company, the HTML coders called themselves Web-Monkies (in fact, that was their group email name). And the java programmers were called Code-Monkies. I never thought anything of it. We called ourselves that mainly because with the wonders of marketing, we didn't have a whole lot of say in how things were done, especially the HTML people. So we all felt like monkies banging out code that benefited nothing but marketing's attempt to justify their income. So, I figured I should apologize before I got lynched. Now, assuming I didn't just piss of marketing people who may/may not be watching this list, I'm done. Thank you, -David Budworth -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Budworth Sent: Sunday, October 28, 2001 11:01 PM To: Jboss-Development Subject: [JBoss-dev] Templating services Hi all, I am in the process of adding templating services to JBoss for my own project, and figured it might be usefull to others. Anyone have any desires for having WebMacro and/or Velocity templating services in JBoss? I personally don't like JSP pages, and find them evil when put to real production use (where you have Web-Monkies doing the HTML, and programmers doing the Java. Web-Monkies don't do well if the template logic needs to be coded in Java) The other issue is, I don't know what the policies are for using third party Open Source software in JBoss. Assuming this is a desirable feature, and a viable one in regards to using other projects software, here's my idea. You start off by registering a key with a template path, ie: admin = /var/templates/admin:/var/templates/shared user = /var/templates/user:/var/templates/shared The path's are just search paths for finding templates (similar to class paths) Then you'd have either: WM WebMacroService.getEngine(admin) That would return a WM object (A webmacro template engine) Or VelocityEngine VelocityService.getEngine(admin) to get the velocity version using the same path. I Don't really like that approach, since it allows people to much with the engine directly, thereby messing up other consumers of the engine (the engines are thread safe, so you'd return the same instance to everyone). Also, I'm pretty sure that it would be legal to return a non-serializable object. So, the way I'd do it would be: TemplateEngine.mergeWebMacro(String pathKey, String templateName, Map dataToMerge) TemplateEngine.mergeVelocity(String pathKey, String templateName, Map dataToMerge) Or better yet: TemplateEngine.merge(String pathKey, String templateName, Map data) And auto-determin the template engine to use (WebMacro prefers .wm, and Velocity has some other extensions (I don't remember exactly which right now)) A cooler way I suppose would be that when someone registers a key with a path, we bind each engine to the JNDI tree as template/webmacro/KEY template/velocity/KEY template/KEY So the use can just get the correct node from the tree and merge(templateName, data) But, I'm not sure an MBean can tell how someone acquired a handle to it (so it woudn't know which key to use). So, if this seems like a reasonable thing to add, lemme know. If you think I'm on crack, shut the hell up, I have to do it anyway for my project, I just won't force y'all to use it. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] is there (911)
Adding one would be trivial (in fact, it's as easy as adding a single string
to the log4j properties)
The problem, is the log would never be a valid XML doc untill the app server
is shut down.
ie:
Using: %d{dd-MMM-}%p%c{1}%m/%c{1}/%p/%d{dd-MMM-}\n
As the pattern string produces:
28-Oct-2001INFOcat1This is a cat1/cat1/INFO/28-Oct-2001
28-Oct-2001INFOcat2This is a cat2/cat2/INFO/28-Oct-2001
28-Oct-2001INFOcat3This is a cat3/cat3/INFO/28-Oct-2001
28-Oct-2001INFOcat1This is a cat1/cat1/INFO/28-Oct-2001
28-Oct-2001INFOcat2This is a cat2/cat2/INFO/28-Oct-2001
28-Oct-2001INFOcat3This is a cat3/cat3/INFO/28-Oct-2001
There would be no document tag for the xml. But I guess you wouldn't want
one anyway, since you couldn't have it at the end.
Meaning, if the log started with log, you couldn't write the /log
until JBoss shut down.
If you want REAL xml (as in with the doc tags), I would suggest a mbean that
will read the logfile in and dump XML.
If you like, I can add that (now that I have my shiny new RW access). It'd
be a 10 minute job (plus 5 hours to figure out where it should be put).
But I'd suggest against that, since composing the string in ram (MBeans
can't return streams can they?) would be hella expensive (a 1GB log file
xmlized would suck)
-David Budworth
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Sunday, October 28, 2001 9:47 PM
To: Jboss-Development@Lists. Sourceforge. Net
Subject: [JBoss-dev] is there (911)
an xml generator to log4j? instead of the flat readable file I mean? this
way you can almost navigate with the data XML. The dates should almost be
at the top of the tree so that you can read by date. In fact reading by
date is one and then you can ask for a tree on topic and see like that.
Creating trees dynamically is a powerful feature.
We would prove how quickly in administration, on the fire, on the job!
With sets instead of trees.
marcf
Marc Fleury
President
JBoss Group, LLC
___
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] Templating services
Hi all, I am in the process of adding templating services to JBoss for my own project, and figured it might be usefull to others. Anyone have any desires for having WebMacro and/or Velocity templating services in JBoss? I personally don't like JSP pages, and find them evil when put to real production use (where you have Web-Monkies doing the HTML, and programmers doing the Java. Web-Monkies don't do well if the template logic needs to be coded in Java) The other issue is, I don't know what the policies are for using third party Open Source software in JBoss. Assuming this is a desirable feature, and a viable one in regards to using other projects software, here's my idea. You start off by registering a key with a template path, ie: admin = /var/templates/admin:/var/templates/shared user = /var/templates/user:/var/templates/shared The path's are just search paths for finding templates (similar to class paths) Then you'd have either: WM WebMacroService.getEngine(admin) That would return a WM object (A webmacro template engine) Or VelocityEngine VelocityService.getEngine(admin) to get the velocity version using the same path. I Don't really like that approach, since it allows people to much with the engine directly, thereby messing up other consumers of the engine (the engines are thread safe, so you'd return the same instance to everyone). Also, I'm pretty sure that it would be legal to return a non-serializable object. So, the way I'd do it would be: TemplateEngine.mergeWebMacro(String pathKey, String templateName, Map dataToMerge) TemplateEngine.mergeVelocity(String pathKey, String templateName, Map dataToMerge) Or better yet: TemplateEngine.merge(String pathKey, String templateName, Map data) And auto-determin the template engine to use (WebMacro prefers .wm, and Velocity has some other extensions (I don't remember exactly which right now)) A cooler way I suppose would be that when someone registers a key with a path, we bind each engine to the JNDI tree as template/webmacro/KEY template/velocity/KEY template/KEY So the use can just get the correct node from the tree and merge(templateName, data) But, I'm not sure an MBean can tell how someone acquired a handle to it (so it woudn't know which key to use). So, if this seems like a reasonable thing to add, lemme know. If you think I'm on crack, shut the hell up, I have to do it anyway for my project, I just won't force y'all to use it. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Templating services
Sorry to reply to my own message, but I meant to say it would be illegal to return non-serializable data from a mbean. and I also forgot to mention that engine.merge(tname, data) would return a string which is the result of merging the template. -David /me promises to almost think about proof-reading his posts before sending them -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Budworth Sent: Sunday, October 28, 2001 11:01 PM To: Jboss-Development Subject: [JBoss-dev] Templating services Hi all, I am in the process of adding templating services to JBoss for my own project, and figured it might be usefull to others. Anyone have any desires for having WebMacro and/or Velocity templating services in JBoss? I personally don't like JSP pages, and find them evil when put to real production use (where you have Web-Monkies doing the HTML, and programmers doing the Java. Web-Monkies don't do well if the template logic needs to be coded in Java) The other issue is, I don't know what the policies are for using third party Open Source software in JBoss. Assuming this is a desirable feature, and a viable one in regards to using other projects software, here's my idea. You start off by registering a key with a template path, ie: admin = /var/templates/admin:/var/templates/shared user = /var/templates/user:/var/templates/shared The path's are just search paths for finding templates (similar to class paths) Then you'd have either: WM WebMacroService.getEngine(admin) That would return a WM object (A webmacro template engine) Or VelocityEngine VelocityService.getEngine(admin) to get the velocity version using the same path. I Don't really like that approach, since it allows people to much with the engine directly, thereby messing up other consumers of the engine (the engines are thread safe, so you'd return the same instance to everyone). Also, I'm pretty sure that it would be legal to return a non-serializable object. So, the way I'd do it would be: TemplateEngine.mergeWebMacro(String pathKey, String templateName, Map dataToMerge) TemplateEngine.mergeVelocity(String pathKey, String templateName, Map dataToMerge) Or better yet: TemplateEngine.merge(String pathKey, String templateName, Map data) And auto-determin the template engine to use (WebMacro prefers .wm, and Velocity has some other extensions (I don't remember exactly which right now)) A cooler way I suppose would be that when someone registers a key with a path, we bind each engine to the JNDI tree as template/webmacro/KEY template/velocity/KEY template/KEY So the use can just get the correct node from the tree and merge(templateName, data) But, I'm not sure an MBean can tell how someone acquired a handle to it (so it woudn't know which key to use). So, if this seems like a reasonable thing to add, lemme know. If you think I'm on crack, shut the hell up, I have to do it anyway for my project, I just won't force y'all to use it. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
