Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
On Saturday 01 December 2001 04:20, Scott M Stark wrote: No, I don't see the java:comp context for this standalone war. The AbstractWebContainer.parseWebAppDescriptors is not being called as part of the deploy so the ENC is not getting created. There is some integration problem between Jetty and the AbstractWebContainer for a single war I'll look into. I also have the same problem with my bigger app that is a complete ear with ejb-jar war. I'm only using standard J2EE deployment descriptors + jbosscmp-jdbc.xml (no jboss-web.xml or jboss.xml). This was working some couple of days ago, but stopped recently. Peter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NPE in JDBCCustomFinderQuery
Hello! I get a: java.lang.NullPointerException org.jboss.ejb.plugins.cmp.jdbc.JDBCCustomFinderQuery.execute(JDBCCustomFinderQuery.java:68) There's a bug in the constructor: Index: JDBCCustomFinderQuery.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCustomFinderQuery.java,v retrieving revision 1.1 diff -r1.1 JDBCCustomFinderQuery.java 50c50 finderMethod = finderMethod; --- this.finderMethod = finderMethod; Peter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
On Saturday 01 December 2001 04:20, Scott M Stark wrote: No, I don't see the java:comp context for this standalone war. The AbstractWebContainer.parseWebAppDescriptors is not being called as part of the deploy so the ENC is not getting created. There is some integration problem between Jetty and the AbstractWebContainer for a single war I'll look into. I dit some traceback and it appears that AbstractWebContainer subclass (org.jboss.jetty.JettyService) is not calling WebDescriptorParser.parseWebAppDescriptors(). The call to parseWebAppDescriptors() is being made from within org.jboss.jetty.JBossWebApplicationContext.JBossSXSecurityHandler.start() method, which is not called since no JBossSXSecurityHandler instance is ever created. The JBossWebApplicationContext.getSecurityHandler() is never called. It's true. I have not yet configured the security in my app. But it should work nevertheless. Why is parsing done in JBossSXSecurityHandler's start() method? Because the start() method is called with the correct thread's contextClassLoader? If it is different than thread's contextClassLoader when performDeploy is called then it should be the child of it as it is asserted in the sanity check being made in JBossSXSecurityHandler.start() method. So I made a test and moved the parseWebAppDescriptors() call from the JBossSXSecurityHandler.start() method to the org.jboss.jetty.Jetty.deploy() method, just before JBossWebApplicationContext.start() method is called. It works. Peter Here are the diffs: Index: JBossWebApplicationContext.java === RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java,v retrieving revision 1.4 diff -c -r1.4 JBossWebApplicationContext.java *** JBossWebApplicationContext.java 2001/11/28 01:22:25 1.4 --- JBossWebApplicationContext.java 2001/12/01 15:46:02 *** *** 117,125 } // Parse descriptors and set up the JNDI environment ! Element webAppDD = _webApp.getWebApp(); ! Element jbossDD = _webApp.getJbossWeb(); ! _descriptorParser.parseWebAppDescriptors(loader, webAppDD, jbossDD); // Add the JBoss security realm String realmName = getRealm(); --- 117,125 } // Parse descriptors and set up the JNDI environment ! // Element webAppDD = _webApp.getWebApp(); ! // Element jbossDD = _webApp.getJbossWeb(); ! // _descriptorParser.parseWebAppDescriptors(loader, webAppDD, jbossDD); // Add the JBoss security realm String realmName = getRealm(); *** *** 246,248 --- 246,249 return path.substring(jar:file:.length(),path.length()-(resource.length()+2)); } } + Index: Jetty.java === RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Jetty.java,v retrieving revision 1.24 diff -c -r1.24 Jetty.java *** Jetty.java 2001/11/29 01:21:29 1.24 --- Jetty.java 2001/12/01 15:46:02 *** *** 204,209 --- 204,213 _log.info(no jboss-web.xml found); } + // + // delegate parsing of some elements to descriptorParser + descriptorParser.parseWebAppDescriptors(cl, wa.getWebApp(), wa.getJbossWeb()); + // finally start the app app.start(); *** *** 287,289 --- 291,294 url.substring(index, url.length()); } } + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/event VerificationEventGeneratorSupport.java
User: juhalindfors
Date: 01/12/01 09:29:31
Modified:src/main/org/jboss/verifier/event
VerificationEventGeneratorSupport.java
Log:
adding wasn't the optimal way of removing a listener
Revision ChangesPath
1.4 +3 -3
jboss/src/main/org/jboss/verifier/event/VerificationEventGeneratorSupport.java
Index: VerificationEventGeneratorSupport.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/event/VerificationEventGeneratorSupport.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- VerificationEventGeneratorSupport.java2001/01/03 08:28:43 1.3
+++ VerificationEventGeneratorSupport.java2001/12/01 17:29:30 1.4
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: VerificationEventGeneratorSupport.java,v 1.3 2001/01/03 08:28:43 tobias Exp
$
+ * $Id: VerificationEventGeneratorSupport.java,v 1.4 2001/12/01 17:29:30
juhalindfors Exp $
*
* You can reach the author by sending email to [EMAIL PROTECTED]
*/
@@ -43,7 +43,7 @@
* @see OTHER RELATED CLASSES
*
* @author Juha Lindfors
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
* @sinceJDK 1.3
*/
public class VerificationEventGeneratorSupport extends EventGeneratorSupport {
@@ -65,7 +65,7 @@
public void removeVerificationListener(VerificationListener listener) {
-super.addListener(listener);
+super.removeListener(listener);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/adapter/jdbc/xa XAManagedConnection.java
User: d_jencks
Date: 01/12/01 10:08:19
Modified:src/main/org/jboss/resource/adapter/jdbc/xa
XAManagedConnection.java
Log:
probably workaround for code that compiles but does not run... protected superclass
method cannot be called from inner class in subclass.
Revision ChangesPath
1.2 +8 -1
jbosscx/src/main/org/jboss/resource/adapter/jdbc/xa/XAManagedConnection.java
Index: XAManagedConnection.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/adapter/jdbc/xa/XAManagedConnection.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- XAManagedConnection.java 2001/09/08 19:32:21 1.1
+++ XAManagedConnection.java 2001/12/01 18:08:18 1.2
@@ -24,7 +24,7 @@
*
* @authorAaron Mulder [EMAIL PROTECTED]
* @authora href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class XAManagedConnection extends BaseManagedConnection
{
@@ -194,6 +194,13 @@
public void cleanup()
throws ResourceException
{
+ }
+
+ //To work around apparent jvm or compiler bug where inner class cannot call
protected
+ //method on superclass of containing class.
+ protected void fireConnectionEvent(javax.resource.spi.ConnectionEvent ce)
+ {
+ super.fireConnectionEvent(ce);
}
XADataSource getDataSource()
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/adapter/jdbc/xa XAManagedConnection.java
| probably workaround for code that compiles but does not run...
|protected superclass method cannot be called from inner class in subclass.
on the uselesness of package protection make the super class call public
and be done with the OO wanking
marcf
|
| Revision ChangesPath
| 1.2 +8 -1
|jbosscx/src/main/org/jboss/resource/adapter/jdbc/xa/XAManagedConnec
|tion.java
|
| Index: XAManagedConnection.java
| ===
| RCS file:
|/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/adapter/jdbc/xa/
|XAManagedConnection.java,v
| retrieving revision 1.1
| retrieving revision 1.2
| diff -u -r1.1 -r1.2
| --- XAManagedConnection.java 2001/09/08 19:32:21 1.1
| +++ XAManagedConnection.java 2001/12/01 18:08:18 1.2
| @@ -24,7 +24,7 @@
|*
|* @authorAaron Mulder [EMAIL PROTECTED]
|* @authora
|href=mailto:[EMAIL PROTECTED];David Jencks/a
| - * @version $Revision: 1.1 $
| + * @version $Revision: 1.2 $
|*/
| public class XAManagedConnection extends BaseManagedConnection
| {
| @@ -194,6 +194,13 @@
| public void cleanup()
| throws ResourceException
| {
| + }
| +
| + //To work around apparent jvm or compiler bug where inner
|class cannot call protected
| + //method on superclass of containing class.
| + protected void
|fireConnectionEvent(javax.resource.spi.ConnectionEvent ce)
| + {
| + super.fireConnectionEvent(ce);
| }
|
| XADataSource getDataSource()
|
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-487846 ] org.jboss.proxy.Proxies.Impl.sameTypes()
Bugs item #487846, was opened at 2001-12-01 08:17
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=487846group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Levart (plevart)
Assigned to: Nobody/Anonymous (nobody)
Summary: org.jboss.proxy.Proxies.Impl.sameTypes()
Initial Comment:
The org.jboss.proxy.Proxies.Impl.sameTypes() has two
bugs. The first is harmless as it will never be
executed but the second causes the method to return
the oposite boolean value as it should. The
consequence is that proxy generation producess new
instancess of Class anc ClassLoader objects for every
instance of the proxy that implements the same
interfaces. More dangerous is the fact that some day
the proxy generator could return a proxy instance
that actualy didn't implement the requested
interfaces.
I reported this on the jboss-developement but heard
no answers yet. I'm submiting this as a bug so that
it won't be forgotten.
Peter
Here is the diff:
Index: Proxies.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/proxy/Proxies.java,v
retrieving revision 1.7
diff -c -r1.7 Proxies.java
*** Proxies.java2001/11/26 03:19:46 1.7
--- Proxies.java2001/12/01 16:05:13
***
*** 300,306
// (duplication and reordering are ignored)
static boolean sameTypes(Class tt1[], Class
tt2[])
{
! if (tt1.length == 1 tt2.length == 0)
{
return tt1[0] == tt2[0];
}
--- 300,306
// (duplication and reordering are ignored)
static boolean sameTypes(Class tt1[], Class
tt2[])
{
! if (tt1.length == 1 tt2.length == 1)
{
return tt1[0] == tt2[0];
}
***
*** 335,341
totalSeen2 += seen2;
}
// now, each element of tt2 must have
been visited
! return totalSeen2 != tt2.length;
}
static Class[] copyAndUniquify(Class
targetTypes[])
--- 335,341
totalSeen2 += seen2;
}
// now, each element of tt2 must have
been visited
! return totalSeen2 == tt2.length;
}
static Class[] copyAndUniquify(Class
targetTypes[])
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=487846group_id=22866
___
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 JDBCCustomFinderQuery.java
User: plevart
Date: 01/12/01 12:32:03
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCCustomFinderQuery.java
Log:
Fix a typo in constructor that causes NPE in execute()
Revision ChangesPath
1.2 +2 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCustomFinderQuery.java
Index: JDBCCustomFinderQuery.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCustomFinderQuery.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JDBCCustomFinderQuery.java2001/11/28 11:32:54 1.1
+++ JDBCCustomFinderQuery.java2001/12/01 20:32:03 1.2
@@ -31,7 +31,7 @@
*
* @see org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class JDBCCustomFinderQuery implements JDBCQueryCommand {
private Logger log;
@@ -47,7 +47,7 @@
* @param finderMethod the EJB finder method implementation
*/
public JDBCCustomFinderQuery(JDBCStoreManager manager, Method finderMethod) {
- finderMethod = finderMethod;
+ this.finderMethod = finderMethod;
this.log = Logger.getLogger(
this.getClass().getName() +
. +
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy Proxies.java
User: plevart
Date: 01/12/01 12:49:27
Modified:src/main/org/jboss/proxy Proxies.java
Log:
Fix for bug #487846
Revision ChangesPath
1.8 +2 -2 jboss/src/main/org/jboss/proxy/Proxies.java
Index: Proxies.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/Proxies.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Proxies.java 2001/11/26 03:19:46 1.7
+++ Proxies.java 2001/12/01 20:49:26 1.8
@@ -300,7 +300,7 @@
// (duplication and reordering are ignored)
static boolean sameTypes(Class tt1[], Class tt2[])
{
- if (tt1.length == 1 tt2.length == 0)
+ if (tt1.length == 1 tt2.length == 1)
{
return tt1[0] == tt2[0];
}
@@ -335,7 +335,7 @@
totalSeen2 += seen2;
}
// now, each element of tt2 must have been visited
-return totalSeen2 != tt2.length;
+return totalSeen2 == tt2.length;
}
static Class[] copyAndUniquify(Class targetTypes[])
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty Jetty.java
User: schaefera
Date: 01/12/01 13:29:45
Modified:jetty/src/main/org/jboss/jetty Jetty.java
Log:
Fixed the problem with Jetty on Windows as well as remove the obsolete
DataCollector from the J2eeDeployers.
Revision ChangesPath
1.25 +37 -8 contrib/jetty/src/main/org/jboss/jetty/Jetty.java
Index: Jetty.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Jetty.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- Jetty.java2001/11/29 01:21:29 1.24
+++ Jetty.java2001/12/01 21:29:44 1.25
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: Jetty.java,v 1.24 2001/11/29 01:21:29 jules_gosnell Exp $
+// $Id: Jetty.java,v 1.25 2001/12/01 21:29:44 schaefera Exp $
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -26,6 +26,24 @@
import org.mortbay.jetty.servlet.WebApplicationContext;
import org.mortbay.util.Resource;
+/**
+ * description
+ *
+ * @author a href=mailto:[EMAIL PROTECTED];Julian Gosnell/a
+ * @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a.
+ * @version $Revision: 1.25 $
+ *
+ * pbRevisions:/b
+ *
+ * pb20011201 andreas:/b
+ * ul
+ * liFixed fixURL() because it is to Unix centric. Right now the
+ * method looks for the last part of the JAR URL (file:/...) which
+ * should be the JAR file name and add a /. before them. Now this
+ * should work for Windows as well (the problem with windows was that
+ * after file: came the DRIVE LETTER which created a wrong URL).
+ * /ul
+ **/
public class Jetty
extends org.mortbay.jetty.Server
{
@@ -278,12 +296,23 @@
static String
fixURL(String url)
{
-String protocol=file:;
-int index=url.indexOf(protocol)+protocol.length();
-return
- url.substring(0,index)+
- File.separator +
- .+
- url.substring(index, url.length());
+// Get the separator of the JAR URL and the file reference
+int index = url.indexOf( '!' );
+if( index = 0 ) {
+ index = url.lastIndexOf( '/', index );
+} else {
+ index = url.lastIndexOf( '/' );
+}
+// Now add a ./ before the JAR file to add a different path
+if( index = 0 ) {
+ return
+url.substring( 0, index ) +
+/. +
+url.substring( index );
+} else {
+ // Now forward slash found then there is severe problem with
+ // the URL but here we just ignore it
+ return url;
+}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment J2eeDeployer.java
User: schaefera
Date: 01/12/01 13:29:45
Modified:src/main/org/jboss/deployment J2eeDeployer.java
Log:
Fixed the problem with Jetty on Windows as well as remove the obsolete
DataCollector from the J2eeDeployers.
Revision ChangesPath
1.49 +1 -44 jboss/src/main/org/jboss/deployment/J2eeDeployer.java
Index: J2eeDeployer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/deployment/J2eeDeployer.java,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- J2eeDeployer.java 2001/11/26 21:46:50 1.48
+++ J2eeDeployer.java 2001/12/01 21:29:45 1.49
@@ -60,7 +60,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Toby Allsopp/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
* @author a href=mailto:[EMAIL PROTECTED];Christoph G. Jung/a.
- * @version $Revision: 1.48 $
+ * @version $Revision: 1.49 $
*/
public class J2eeDeployer
@@ -196,16 +196,10 @@
{
URL url = new URL(_url);
- // comment author=cgjungfactored out for subclass access /comment
- ObjectName lCollector = createCollectorName();
-
// undeploy first if it is a redeploy
try
{
undeploy(_url);
- // Remove application data by its id
- // comment author=cgjung factored out for subclass access /comment
- removeFromCollector(_url,lCollector);
}
catch (Exception _e)
{
@@ -253,43 +247,6 @@
log.error(fatal error:, _e);
throw new J2eeDeploymentException(fatal error: +_e);
}
- }
- }
-
- /** creation of collector name factored out.
-* @author schaefera
-* @author cgjung
-*/
- protected ObjectName createCollectorName()
- {
- try
- {
- return new ObjectName( Management, service, Collector );
- }
- catch( Exception e )
- {
- return null;
- }
- }
-
- /** report of removal to data collector factored out for subclass access
-* a try/catch for dealing with an uninstalled collector has been added.
-* @author schaefera
-* @author cgjung
-*/
- protected void removeFromCollector(String _url, ObjectName lCollector)
- {
- try
- {
- server.invoke(lCollector,
-removeApplication,
-new Object[] { _url },
-new String[]{ java.lang.String }
- );
- }
- catch(Exception e)
- {
- log.info(Report of undeployment of J2EE application: + _url + could
not be reported.);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc class.java interface.java
User: schaefera
Date: 01/12/01 13:29:45
Modified:src/etc class.java interface.java
Log:
Fixed the problem with Jetty on Windows as well as remove the obsolete
DataCollector from the J2eeDeployers.
Revision ChangesPath
1.9 +32 -40jboss/src/etc/class.java
Index: class.java
===
RCS file: /cvsroot/jboss/jboss/src/etc/class.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- class.java2001/08/03 17:15:42 1.8
+++ class.java2001/12/01 21:29:45 1.9
@@ -1,12 +1,13 @@
/*
-* JBoss, the OpenSource J2EE webOS
-*
-* Distributable under LGPL license.
-* See terms of license at gnu.org.
-*/
+ * JBoss, the OpenSource J2EE webOS
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
+ */
+
package x;
-//EXPLICIT IMPORTS
+// EXPLICIT IMPORTS
import a.b.C1; // GOOD
import a.b.C2;
import a.b.C3;
@@ -14,38 +15,33 @@
// DO NOT WRITE
import a.b.*; // BAD
-/**
-* description
-*
-* @see related
-* @author a href=mailto:{email};{full name}/a.
-* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
-* @version $Revision: 1.8 $
-*
-* pbRevisions:/b
-*
-* pbmmdd author:/b
-* ul
-* li explicit fix description (no line numbers but methods) go beyond the cvs
commit message
-* /ul
-*eg:
-* pb20010516 marc fleury:/b
-* ul
-* li Ask all developers to clearly document the Revision, changed the header.
-* /ul
-* pb20010719 andreas schaefer:/b
-* ul
-* li Changed indentation to 3 spaces to go along with the guidelines and
removed second comment
-*about this to avoid confusion.
-* /ul
-*/
-
-
// DO NOT USE TAB TO INDENT CODE USE *3* SPACES FOR PORTABILITY AMONG EDITORS
+/**
+ * description
+ *
+ * @see related
+ * @author a href=mailto:{email};{full name}/a.
+ * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
+ * @version $Revision: 1.9 $
+ *
+ * pbRevisions:/b
+ *
+ * pbmmdd author:/b
+ * ul
+ * li explicit fix description (no line numbers but methods) go
+ *beyond the cvs commit message
+ * /ul
+ * eg:
+ * pb20010516 marc fleury:/b
+ * ul
+ * li Ask all developers to clearly document the Revision,
+ *changed the header.
+ * /ul
+ */
public class X
-extends Y
-implements Z
+ extends Y
+ implements Z
{
// Constants -
@@ -98,7 +94,6 @@
}
}
-
// Test database
vendorSource.getXAConnection().close();
@@ -106,10 +101,8 @@
bind(new InitialContext(), java:/+getPoolName(),
new Reference(vendorSource.getClass().getName(),
getClass().getName(), null));
-
- // We are done
- log.log(XA Data source +getPoolName()+ bound to java:/+getPoolName());
}
+
// Z implementation --
// Y overrides ---
@@ -122,4 +115,3 @@
// Inner classes -
}
-
1.7 +34 -43jboss/src/etc/interface.java
Index: interface.java
===
RCS file: /cvsroot/jboss/jboss/src/etc/interface.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- interface.java2001/08/03 17:15:42 1.6
+++ interface.java2001/12/01 21:29:45 1.7
@@ -1,12 +1,13 @@
/*
-* JBoss, the OpenSource J2EE webOS
-*
-* Distributable under LGPL license.
-* See terms of license at gnu.org.
-*/
+ * JBoss, the OpenSource J2EE webOS
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
+ */
+
package x;
-//EXPLICIT IMPORTS
+// EXPLICIT IMPORTS
import a.b.C1; // GOOD
import a.b.C2;
import a.b.C3;
@@ -14,46 +15,36 @@
// DO NOT WRITE
import a.b.*; // BAD
-
-/**
-* description
-*
-* @see related
-* @author a href=mailto:{email};{full name}/a.
-* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
-* @version $Revision: 1.6 $
-* Revisions:
-*
-* pbRevisions:/b
-*
-* pbmmdd author:/b
-* ul
-* li explicit fix description (no line numbers but methods) go beyond the cvs
commit message
-* /ul
-*eg:
-* pb20010516 marc fleury:/b
-* ul
-* li Ask all developers to clearly document the Revision, changed the header.
-* /ul
-* pb20010719 andreas schaefer:/b
-* ul
-* li Changed indentation to 3 spaces to go along with the guidelines and
removed second comment
-*about
[JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment/scope J2eeGlobalScopeDeployer.java
User: schaefera
Date: 01/12/01 13:29:45
Modified:src/main/org/jboss/deployment/scope
J2eeGlobalScopeDeployer.java
Log:
Fixed the problem with Jetty on Windows as well as remove the obsolete
DataCollector from the J2eeDeployers.
Revision ChangesPath
1.16 +14 -19
jboss/src/main/org/jboss/deployment/scope/J2eeGlobalScopeDeployer.java
Index: J2eeGlobalScopeDeployer.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/deployment/scope/J2eeGlobalScopeDeployer.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- J2eeGlobalScopeDeployer.java 2001/11/24 19:46:42 1.15
+++ J2eeGlobalScopeDeployer.java 2001/12/01 21:29:45 1.16
@@ -253,9 +253,6 @@
// build url from string spec
URL url = new URL(_url);
-// find the collector to report to
-ObjectName lCollector = createCollectorName();
-
// initialise teared down deployments just in case that nothing
// is teared down
List allTearedDown=new java.util.ArrayList();
@@ -265,7 +262,7 @@
// use modified undeploy in order to tear down
// dependent apps as well, reporting will be
// done here!
-undeployWithDependencies(_url,allTearedDown,url,lCollector);
+undeployWithDependencies(_url,allTearedDown,url);
} catch (Exception _e) {
// not a real exception; fresh deployment case
allTearedDown.add(url);
@@ -288,7 +285,7 @@
d=installApplication(nextUrl);
// and start it (and the depending stuff, before)
// reporting is done here
-startApplication(d, scope, lCollector);
+startApplication(d, scope);
} catch(Exception e) {
uninstallApplication(nextUrl.toString());
throw new J2eeDeploymentException(could not start application
+nextUrl,e);
@@ -306,13 +303,13 @@
* @throws J2eeDeploymentException if an error occures for one of these
* modules
*/
-protected void startApplication(Deployment dep, Scope scope, ObjectName
lCollector) throws J2eeDeploymentException {
+protected void startApplication(Deployment dep, Scope scope) throws
J2eeDeploymentException {
// here we collect all the started deployments (not only dep)
// in the order they should be deployed
List deployments=new java.util.ArrayList();
// recursively start all sub-deployments
-startApplication(dep, deployments,scope,lCollector);
+startApplication(dep, deployments,scope);
Iterator allDeployments=deployments.iterator();
@@ -341,7 +338,7 @@
// have been setup
source.afterStartup();
} catch(Exception e) {
-stopApplication(_d,new java.util.ArrayList(),null,scope,lCollector);
+stopApplication(_d,new java.util.ArrayList(),null,scope);
throw new J2eeDeploymentException(could not deploy +_d.getName());
}
@@ -358,7 +355,7 @@
* @throws J2eeDeploymentException if an error occures for one of these
* modules
*/
-protected void startApplication(Deployment _d, List alreadyMarked, Scope scope,
ObjectName lCollector) throws J2eeDeploymentException {
+protected void startApplication(Deployment _d, List alreadyMarked, Scope scope)
throws J2eeDeploymentException {
ClassLoader parent=Thread.currentThread().getContextClassLoader();
@@ -388,7 +385,7 @@
log.info(Deploying dependent application +absoluteUrl);
try{
newD = installApplication(absoluteUrl);
-startApplication(newD,alreadyMarked,scope,lCollector);
+startApplication(newD,alreadyMarked,scope);
} catch(Exception e) {
try{
uninstallApplication(absoluteUrl.toString());
@@ -422,7 +419,7 @@
* @throws J2eeDeploymentException to
* indicate problems in undeployment.
*/
-protected void stopApplication(Deployment _d, List redeployUrls, URL newUrl,
Scope scope, ObjectName lCollector) throws J2eeDeploymentException {
+protected void stopApplication(Deployment _d, List redeployUrls, URL newUrl,
Scope scope) throws J2eeDeploymentException {
// synchronize on the scope
synchronized(scope.classLoaders) {
@@ -453,13 +450,11 @@
allDependencies.next();
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge JDBCEntityBridge.java
User: dsundstrom
Date: 01/12/01 13:55:05
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge
JDBCEntityBridge.java
Log:
Added support for autogenerated foriegn key constraints on relationships.
Just add fk-constrainttrue/fk-constraint to defaults or relationship
role.
Changed relation tables to synchronize data after jdbc store executes.
Revision ChangesPath
1.15 +44 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java
Index: JDBCEntityBridge.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCEntityBridge.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- JDBCEntityBridge.java 2001/11/28 11:32:55 1.14
+++ JDBCEntityBridge.java 2001/12/01 21:55:05 1.15
@@ -16,6 +16,9 @@
import java.util.Map;
import javax.ejb.EJBException;
+import javax.sql.DataSource;
+import javax.naming.InitialContext;
+import javax.naming.NamingException;
import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.EntityEnterpriseContext;
@@ -49,11 +52,16 @@
* One per cmp entity bean type.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*/
public class JDBCEntityBridge implements EntityBridge {
protected JDBCEntityMetaData metadata;
protected JDBCStoreManager manager;
+
+ private DataSource dataSource;
+
+ /** is the table assumed to exist */
+ protected boolean tableExists;
protected JDBCCMPFieldBridge[] cmpFields;
protected Map cmpFieldsByName;
@@ -75,6 +83,15 @@
this.metadata = metadata;
this.manager = manager;
+ // find the datasource
+ try {
+ dataSource = (DataSource)new InitialContext().lookup(
+ metadata.getDataSourceName());
+ } catch(NamingException e) {
+ throw new DeploymentException(Error: can't find data source: +
+ metadata.getDataSourceName());
+ }
+
// CMP fields
loadCMPFields(metadata);
@@ -227,7 +244,32 @@
public JDBCEntityMetaData getMetaData() {
return metadata;
}
-
+
+ /**
+* Returns the datasource for this entity.
+*/
+ public DataSource getDataSource() {
+ return dataSource;
+ }
+
+ /**
+* Does the table exists yet? This does not mean that table has been created
+* by the appilcation, or the the database metadata has been checked for the
+* existance of the table, but that at this point the table is assumed to
+* exist.
+* @return true if the table exists
+*/
+ public boolean getTableExists() {
+ return tableExists;
+ }
+
+ /**
+* Sets table exists flag.
+*/
+ public void setTableExists(boolean tableExists) {
+ this.tableExists = tableExists;
+ }
+
public String getTableName() {
return metadata.getTableName();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jbosscmp-jdbc_3_0.dtd
User: dsundstrom Date: 01/12/01 13:56:24 Modified:src/resources/org/jboss/metadata jbosscmp-jdbc_3_0.dtd Log: Added fk-constraint element to dtd. Revision ChangesPath 1.2 +12 -2 jboss/src/resources/org/jboss/metadata/jbosscmp-jdbc_3_0.dtd Index: jbosscmp-jdbc_3_0.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jbosscmp-jdbc_3_0.dtd,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jbosscmp-jdbc_3_0.dtd 2001/11/25 04:06:27 1.1 +++ jbosscmp-jdbc_3_0.dtd 2001/12/01 21:56:24 1.2 @@ -19,7 +19,7 @@ -- !ELEMENT defaults (datasource?, type-mapping?, create-table?, remove-table?, read-only?, time-out?, select-for-update?, pk-constraint?, - preferred-relation-mapping?, read-ahead?) + fk-constraint?, preferred-relation-mapping?, read-ahead?) !-- @@ -79,6 +79,16 @@ !-- +Should a foreign key constraint be added for this relationship role? + +The fk-constraint element must be one of the two following: + fk-constrainttrue/fk-constraint + fk-constraintfalse/fk-constraint +-- +!ELEMENT fk-constraint (#PCDATA) + + +!-- Should a primary key constraint be added when creating tables? The pk-constraint element must be one of the two following: @@ -368,7 +378,7 @@ ejb-relationship-role. -- !ELEMENT ejb-relationship-role (ejb-relationship-role-name, - (foreign-key-fields | table-key-fields)) + fk-constraint, (foreign-key-fields | table-key-fields)) !-- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default standardjbosscmp-jdbc.xml
User: dsundstrom Date: 01/12/01 13:57:41 Modified:src/etc/conf/default standardjbosscmp-jdbc.xml Log: Added default value for fk-constraint. Default is false because hypersonic db does not support the ALTER TABLE statement. Revision ChangesPath 1.10 +3 -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.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- standardjbosscmp-jdbc.xml 2001/11/27 00:15:30 1.9 +++ standardjbosscmp-jdbc.xml 2001/12/01 21:57:41 1.10 @@ -7,7 +7,7 @@ !-- -- !-- = -- -!-- $Id: standardjbosscmp-jdbc.xml,v 1.9 2001/11/27 00:15:30 peter_f Exp $ -- +!-- $Id: standardjbosscmp-jdbc.xml,v 1.10 2001/12/01 21:57:41 dsundstrom Exp $ -- jbosscmp-jdbc @@ -19,6 +19,8 @@ remove-tablefalse/remove-table read-onlyfalse/read-only time-out300/time-out + pk-constrainttrue/pk-constraint + fk-constraintfalse/fk-constraint select-for-updatefalse/select-for-update preferred-relation-mappingforeign-key/preferred-relation-mapping /defaults ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata JDBCRelationMetaData.java JDBCRelationshipRoleMetaData.java
User: dsundstrom
Date: 01/12/01 13:55:06
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCRelationMetaData.java
JDBCRelationshipRoleMetaData.java
Log:
Added support for autogenerated foriegn key constraints on relationships.
Just add fk-constrainttrue/fk-constraint to defaults or relationship
role.
Changed relation tables to synchronize data after jdbc store executes.
Revision ChangesPath
1.8 +6 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCRelationMetaData.java
Index: JDBCRelationMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCRelationMetaData.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- JDBCRelationMetaData.java 2001/11/28 11:32:55 1.7
+++ JDBCRelationMetaData.java 2001/12/01 21:55:05 1.8
@@ -25,7 +25,7 @@
* have set methods.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.7 $
+ * @version $Revision: 1.8 $
*/
public final class JDBCRelationMetaData {
private final static int TABLE = 1;
@@ -214,11 +214,13 @@
left = new JDBCRelationshipRoleMetaData(
this,
jdbcApplication,
+ element,
defaultValues.getLeftRelationshipRole());
right = new JDBCRelationshipRoleMetaData(
this,
jdbcApplication,
+ element,
defaultValues.getRightRelationshipRole());
return;
@@ -299,7 +301,7 @@
} else {
primaryKeyConstraint = defaultValues.hasPrimaryKeyConstraint();
}
-
+
// read-only
String readOnlyString = MetaData.getOptionalChildContent(
mappingElement, read-only);
@@ -365,6 +367,7 @@
leftRole = new JDBCRelationshipRoleMetaData(
this,
jdbcApplication,
+ element,
defaultValues.getLeftRelationshipRole());
}
@@ -374,6 +377,7 @@
rightRole = new JDBCRelationshipRoleMetaData(
this,
jdbcApplication,
+ element,
defaultValues.getRightRelationshipRole());
}
1.10 +132 -116
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.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JDBCRelationshipRoleMetaData.java 2001/11/26 03:12:27 1.9
+++ JDBCRelationshipRoleMetaData.java 2001/12/01 21:55:05 1.10
@@ -18,11 +18,11 @@
import org.w3c.dom.Element;
/**
- * Imutable class which represents one ejb-relationship-role element found in the
- * ejb-jar.xml file's ejb-relation elements.
+ * Imutable class which represents one ejb-relationship-role element found in
+ * the ejb-jar.xml file's ejb-relation elements.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public final class JDBCRelationshipRoleMetaData {
/**
@@ -41,6 +41,11 @@
private final boolean multiplicityOne;
/**
+* Should this role have a foreign key constraint?
+*/
+ private final boolean foreignKeyConstraint;
+
+ /**
* Should this entity be deleted when related entity is deleted.
*/
private final boolean cascadeDelete;
@@ -66,7 +71,7 @@
public JDBCRelationshipRoleMetaData(
JDBCRelationMetaData relationMetaData,
JDBCApplicationMetaData application,
- RelationshipRoleMetaData relationshipRole) throws DeploymentException {
+ RelationshipRoleMetaData relationshipRole) throws DeploymentException {
this.relationMetaData = relationMetaData;
RelationshipRoleMetaData relatedRole =
@@ -75,6 +80,7 @@
relationshipRoleName = relationshipRole.getRelationshipRoleName();
multiplicityOne = relationshipRole.isMultiplicityOne();
cascadeDelete = relationshipRole.isCascadeDelete();
+ foreignKeyConstraint = false;
String tempCmrFieldName = relationshipRole.getCMRFieldName();
if(tempCmrFieldName == null) {
@@ -83,7 +89,6 @@
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCAbstractQueryCommand.java JDBCCreateEntityCommand.java JDBCDeleteRelationsCommand.java JDBCFindByForeignKeyCommand.java JDBCInsertRelationsCommand.java JDBCLoadEntityCommand.java JDBCLoadFieldCommand.java JDBCLoadRelationCommand.java JDBCReadAheadCommand.java JDBCRelationInterceptor.java JDBCRemoveEntityCommand.java JDBCStartCommand.java JDBCStopCommand.java JDBCStoreEntityCommand.java JDBCStoreManager.java
User: dsundstrom
Date: 01/12/01 13:55:05
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCAbstractQueryCommand.java
JDBCCreateEntityCommand.java
JDBCDeleteRelationsCommand.java
JDBCFindByForeignKeyCommand.java
JDBCInsertRelationsCommand.java
JDBCLoadEntityCommand.java
JDBCLoadFieldCommand.java
JDBCLoadRelationCommand.java
JDBCReadAheadCommand.java
JDBCRelationInterceptor.java
JDBCRemoveEntityCommand.java JDBCStartCommand.java
JDBCStopCommand.java JDBCStoreEntityCommand.java
JDBCStoreManager.java
Log:
Added support for autogenerated foriegn key constraints on relationships.
Just add fk-constrainttrue/fk-constraint to defaults or relationship
role.
Changed relation tables to synchronize data after jdbc store executes.
Revision ChangesPath
1.2 +3 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCAbstractQueryCommand.java
Index: JDBCAbstractQueryCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCAbstractQueryCommand.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JDBCAbstractQueryCommand.java 2001/11/28 11:32:54 1.1
+++ JDBCAbstractQueryCommand.java 2001/12/01 21:55:04 1.2
@@ -42,7 +42,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public abstract class JDBCAbstractQueryCommand implements JDBCQueryCommand {
private JDBCStoreManager manager;
@@ -80,9 +80,10 @@
PreparedStatement ps = null;
try {
// get the connection
- con = manager.getDataSource().getConnection();
+ con = manager.getEntityBridge().getDataSource().getConnection();
// create the statement
+ log.debug(Executing SQL: + sql);
ps = con.prepareStatement(sql);
// set the parameters
1.9 +5 -3
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCreateEntityCommand.java
Index: JDBCCreateEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCreateEntityCommand.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JDBCCreateEntityCommand.java 2001/11/29 20:40:05 1.8
+++ JDBCCreateEntityCommand.java 2001/12/01 21:55:04 1.9
@@ -32,7 +32,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
public class JDBCCreateEntityCommand implements CreateEntityCommand {
private JDBCStoreManager manager;
@@ -151,10 +151,11 @@
PreparedStatement ps = null;
try {
// get the connection
- DataSource dataSource = manager.getDataSource();
+ DataSource dataSource = entity.getDataSource();
con = dataSource.getConnection();
// create the statement
+ log.debug(Executing SQL: + entityExistsSQL);
ps = con.prepareStatement(entityExistsSQL);
// set the parameters
@@ -188,10 +189,11 @@
int rowsAffected = 0;
try {
// get the connection
- DataSource dataSource = manager.getDataSource();
+ DataSource dataSource = entity.getDataSource();
con = dataSource.getConnection();
// create the statement
+ log.debug(Executing SQL: + insertEntitySQL);
ps = con.prepareStatement(insertEntitySQL);
// set the parameters
1.6 +3 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDeleteRelationsCommand.java
Index: JDBCDeleteRelationsCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDeleteRelationsCommand.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JDBCDeleteRelationsCommand.java 2001/11/28 11:32:54 1.5
+++ JDBCDeleteRelationsCommand.java 2001/12/01 21:55:04 1.6
@@ -21,7 +21,7 @@
* Deletes relations from a relation table.
*
* @author a href=mailto:[EMAIL
[JBoss-dev] error starting jetty on W2k from cvs
Hi Jules, I just did a fresh checkout ( today ~2pm est) from cvs and tried to get jboss/jetty running but ran into the following problem during startup. JettyService can't find the jetty.properites file and I think it has something to do with an incompaitbility with the syntax you are using in Jetty.fixURL( ) and the windows filesystem. I tried to fix it myself, but since I am not too familar with the classloading in jboss I didn't get very far so I wanted to give you a heads up. Here is the url that it is using: jar:file:\./E:/projects/jboss-all/build/output/jboss-3.0.0alpha/tmp/deploy/ServiceDeployer/deploy.26/jetty-plugin.sar!/jetty.properties and the exception: java.util.zip.ZipException: The filename, directory name, or volume label syntax is incorrect at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(Unknown Source) at java.util.jar.JarFile.init(Unknown Source) at java.util.jar.JarFile.init(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.init(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(Unknown Source) at java.net.URL.openStream(Unknown Source) at org.jboss.jetty.JettyService.ensureProperties(JettyService.java:114) -Rick
[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
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins CMPFilePersistenceManager.java CMPPersistenceManager.java
(EntityEnterpriseContext ctx)
- throws RemoteException
{
-// Logger.debug(Store entity);
-
storeEntity(ctx.getId(), ctx.getInstance());
}
public void passivateEntity(EntityEnterpriseContext ctx)
- throws RemoteException
{
// This plugin doesn't do anything specific
}
public void removeEntity(EntityEnterpriseContext ctx)
- throws RemoteException, RemoveException
+ throws RemoveException
{
// Remove file
if (!getFile(ctx.getId()).delete())
- throw new RemoveException(Could not remove file:+getFile(ctx.getId()));
-// Logger.debug(Removed file for+ctx.getId());
+ throw new RemoveException(Could not remove file: +
+ getFile(ctx.getId()));
}
// Z implementation --
1.36 +20 -115 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.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- CMPPersistenceManager.java2001/11/24 20:43:22 1.35
+++ CMPPersistenceManager.java2001/12/02 00:05:44 1.36
@@ -26,7 +26,6 @@
import org.jboss.ejb.EntityEnterpriseContext;
import org.jboss.ejb.EntityCache;
import org.jboss.ejb.EntityPersistenceStore;
-import org.jboss.ejb.EntityPersistenceStore2;
import org.jboss.metadata.EntityMetaData;
import org.jboss.util.Sync;
@@ -35,24 +34,24 @@
import org.jboss.management.j2ee.TimeStatistic;
/**
- * The CMP Persistence Manager implements the semantics of the CMP
- * EJB 1.1 call back specification.
+ * The CMP Persistence Manager implements the semantics of the CMP
+ * EJB 1.1 call back specification.
*
- * This Manager works with a EntityPersistenceStore that takes care of the
- * physical storing of instances (JAWS, JDBC O/R, FILE, Object).
+ * This Manager works with a EntityPersistenceStore that takes care of the
+ * physical storing of instances (JAWS, JDBC O/R, FILE, Object).
*
- * @see related
- * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @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.35 $
+ * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
+ * @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.36 $
*
- * Revisions:
- * 20010621 Bill Burke: removed loadEntities call because CMP read-ahead is now
- * done directly by the finder.
- * 20010709 Andreas Schaefer: added statistics gathering
- *
+ * Revisions:
+ * 20010621 Bill Burke: removed loadEntities call because CMP read-ahead is now
+ * done directly by the finder.
+ * 20010709 Andreas Schaefer: added statistics gathering
+ * 20011201 Dain Sundstrom: moved createBeanInstance and initEntity back into
+ * the persistence store.
*/
public class CMPPersistenceManager
implements EntityPersistenceManager
@@ -141,11 +140,7 @@
*/
public Object createBeanClassInstance() throws Exception
{
- if(store instanceof EntityPersistenceStore2)
- {
- return ((EntityPersistenceStore2)store).createBeanClassInstance();
- }
- return con.getBeanClass().newInstance();
+ return store.createBeanClassInstance();
}
private void createMethodCache( Method[] methods )
@@ -197,16 +192,7 @@
Method postCreateMethod = (Method)postCreateMethods.get(m);
// Deligate initialization of bean to persistence store
- // if the store can handle initialization.
- if(store instanceof EntityPersistenceStore2)
- {
- ((EntityPersistenceStore2)store).initEntity(ctx);
- }
- else
- {
- // for backwards compatibility
- initEntity(ctx);
- }
+ store.initEntity(ctx);
// Call ejbCreate on the target bean
try
@@ -377,8 +363,9 @@
}
long lStart = System.currentTimeMillis();
- // The implementation of the call can be left absolutely empty, the
propagation of the call
- // is just a notification for stores that would need to know that an instance
is being activated
+ // The implementation of the call can be left absolutely empty, the
+ // propagation of the call is just a notification for stores that would
+ // need to know
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EntityPersistenceStore.java EntityPersistenceStore2.java
User: dsundstrom
Date: 01/12/01 16:05:44
Modified:src/main/org/jboss/ejb EntityPersistenceStore.java
Removed: src/main/org/jboss/ejb EntityPersistenceStore2.java
Log:
Moved createBeanInstance and initEntity back into the PersistenceStore.
Revision ChangesPath
1.10 +22 -1 jboss/src/main/org/jboss/ejb/EntityPersistenceStore.java
Index: EntityPersistenceStore.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EntityPersistenceStore.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- EntityPersistenceStore.java 2001/11/28 11:35:19 1.9
+++ EntityPersistenceStore.java 2001/12/02 00:05:44 1.10
@@ -26,11 +26,32 @@
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Simone Bordet/a
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public interface EntityPersistenceStore
extends ContainerPlugin
{
+ /**
+* Returns a new instance of the bean class or a subclass of the bean class.
+*
+* @return the new instance
+*
+* @throws Exception
+*/
+ Object createBeanClassInstance() throws Exception;
+
+ /**
+* Initializes the instance context.
+*
+* pThis method is called before createEntity, and should
+*reset the value of all cmpFields to 0 or null.
+*
+* @param ctx
+*
+* @throws RemoteException
+*/
+ void initEntity(EntityEnterpriseContext ctx);
+
/**
* This method is called whenever an entity is to be created.
* The persistence manager is responsible for handling the results properly
___
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/jaws JAWSPersistenceManager.java
User: dsundstrom
Date: 01/12/01 16:05:45
Modified:src/main/org/jboss/ejb/plugins/jaws
JAWSPersistenceManager.java
Log:
Moved createBeanInstance and initEntity back into the PersistenceStore.
Revision ChangesPath
1.34 +96 -1
jboss/src/main/org/jboss/ejb/plugins/jaws/JAWSPersistenceManager.java
Index: JAWSPersistenceManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/JAWSPersistenceManager.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- JAWSPersistenceManager.java 2001/11/24 20:43:24 1.33
+++ JAWSPersistenceManager.java 2001/12/02 00:05:45 1.34
@@ -6,12 +6,15 @@
*/
package org.jboss.ejb.plugins.jaws;
+import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.rmi.RemoteException;
+import java.util.Iterator;
import javax.ejb.CreateException;
+import javax.ejb.EJBException;
import javax.ejb.RemoveException;
import org.apache.log4j.Category;
@@ -23,6 +26,8 @@
import org.jboss.ejb.plugins.jaws.jdbc.JDBCCommandFactory;
+import org.jboss.metadata.EntityMetaData;
+
import org.jboss.util.FinderResults;
/**
@@ -34,7 +39,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.33 $
+ * @version $Revision: 1.34 $
*
* pbRevisions:/b
*
@@ -42,6 +47,10 @@
* ul
* li Get Rid of debug flag, use log4j instead
* /ul
+ * pb20011201 Dain Sundstrom:/b
+ * ul
+ * li Added createBeanInstance and initEntity methods
+ * /ul
*
*/
public class JAWSPersistenceManager
@@ -122,6 +131,92 @@
{
if(destroyCommand != null) // On deploy errors, sometimes JAWS was never
initialized!
destroyCommand.execute();
+ }
+
+ public Object createBeanClassInstance() throws Exception {
+ return container.getBeanClass().newInstance();
+ }
+
+ /**
+* Reset all attributes to default value
+*
+* The EJB 1.1 specification is not entirely clear about this,
+* the EJB 2.0 spec is, see page 169.
+* Robustness is more important than raw speed for most server
+* applications, and not resetting atrribute values result in
+* *very* weird errors (old states re-appear in different instances and the
+* developer thinks he's on drugs).
+*/
+ public void initEntity(EntityEnterpriseContext ctx)
+ {
+ // first get cmp metadata of this entity
+ Object instance = ctx.getInstance();
+ Class ejbClass = instance.getClass();
+ Field cmpField;
+ Class cmpFieldType;
+
+ EntityMetaData metaData = (EntityMetaData)container.getBeanMetaData();
+ Iterator i= metaData.getCMPFields();
+
+ while(i.hasNext())
+ {
+ try
+ {
+// get the field declaration
+try
+{
+ cmpField = ejbClass.getField((String)i.next());
+ cmpFieldType = cmpField.getType();
+ // find the type of the field and reset it
+ // to the default value
+ if (cmpFieldType.equals(boolean.class))
+ {
+ cmpField.setBoolean(instance,false);
+ }
+ else if (cmpFieldType.equals(byte.class))
+ {
+ cmpField.setByte(instance,(byte)0);
+ }
+ else if (cmpFieldType.equals(int.class))
+ {
+ cmpField.setInt(instance,0);
+ }
+ else if (cmpFieldType.equals(long.class))
+ {
+ cmpField.setLong(instance,0L);
+ }
+ else if (cmpFieldType.equals(short.class))
+ {
+ cmpField.setShort(instance,(short)0);
+ }
+ else if (cmpFieldType.equals(char.class))
+ {
+ cmpField.setChar(instance,'\u');
+ }
+ else if (cmpFieldType.equals(double.class))
+ {
+ cmpField.setDouble(instance,0d);
+ }
+ else if (cmpFieldType.equals(float.class))
+ {
+ cmpField.setFloat(instance,0f);
+ }
+ else
+ {
+ cmpField.set(instance,null);
+ }
+}
+catch (NoSuchFieldException e)
+{
+ // will be here with dependant value object's private attributes
+ // should not be a
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCStoreManager.java
User: dsundstrom
Date: 01/12/01 16:05:45
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCStoreManager.java
Log:
Moved createBeanInstance and initEntity back into the PersistenceStore.
Revision ChangesPath
1.17 +3 -3
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStoreManager.java
Index: JDBCStoreManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStoreManager.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- JDBCStoreManager.java 2001/12/01 21:55:05 1.16
+++ JDBCStoreManager.java 2001/12/02 00:05:45 1.17
@@ -27,7 +27,7 @@
import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.Container;
import org.jboss.ejb.EntityContainer;
-import org.jboss.ejb.EntityPersistenceStore2;
+import org.jboss.ejb.EntityPersistenceStore;
import org.jboss.ejb.EntityEnterpriseContext;
import org.jboss.ejb.ListCacheKey;
import org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler;
@@ -61,9 +61,9 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @see org.jboss.ejb.EntityPersistenceStore
- * @version $Revision: 1.16 $
+ * @version $Revision: 1.17 $
*/
-public class JDBCStoreManager implements EntityPersistenceStore2 {
+public class JDBCStoreManager implements EntityPersistenceStore {
/**
* To simplify null values handling in the preloaded data pool we use
___
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 ActivateEntityCommand.java CMPStoreManager.java CreateEntityCommand.java InitEntityCommand.java LoadEntitiesCommand.java LoadEntityCommand.java PassivateEntityCommand.java RemoveEntityCommand.java StoreEntityCommand.java
User: dsundstrom
Date: 01/12/01 16:05:45
Modified:src/main/org/jboss/ejb/plugins/cmp
ActivateEntityCommand.java CMPStoreManager.java
CreateEntityCommand.java InitEntityCommand.java
LoadEntitiesCommand.java LoadEntityCommand.java
PassivateEntityCommand.java
RemoveEntityCommand.java StoreEntityCommand.java
Log:
Moved createBeanInstance and initEntity back into the PersistenceStore.
Revision ChangesPath
1.4 +2 -4
jboss/src/main/org/jboss/ejb/plugins/cmp/ActivateEntityCommand.java
Index: ActivateEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/ActivateEntityCommand.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ActivateEntityCommand.java2001/09/01 22:03:14 1.3
+++ ActivateEntityCommand.java2001/12/02 00:05:45 1.4
@@ -8,7 +8,6 @@
package org.jboss.ejb.plugins.cmp;
import org.jboss.ejb.EntityEnterpriseContext;
-import java.rmi.RemoteException;
/**
* ActivateEntityCommand handles the EntityBean activate message.
@@ -25,12 +24,11 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public interface ActivateEntityCommand
{
// Public
- public void execute(EntityEnterpriseContext ctx)
- throws RemoteException;
+ public void execute(EntityEnterpriseContext ctx);
}
1.9 +6 -13 jboss/src/main/org/jboss/ejb/plugins/cmp/CMPStoreManager.java
Index: CMPStoreManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/CMPStoreManager.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- CMPStoreManager.java 2001/11/24 22:31:09 1.8
+++ CMPStoreManager.java 2001/12/02 00:05:45 1.9
@@ -8,8 +8,6 @@
import java.lang.reflect.Method;
-import java.rmi.RemoteException;
-
import java.util.HashMap;
import java.util.Map;
@@ -18,7 +16,7 @@
import org.jboss.ejb.Container;
import org.jboss.ejb.EntityContainer;
-import org.jboss.ejb.EntityPersistenceStore2;
+import org.jboss.ejb.EntityPersistenceStore;
import org.jboss.ejb.EntityEnterpriseContext;
@@ -58,10 +56,10 @@
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @see org.jboss.ejb.EntityPersistenceStore
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
public abstract class CMPStoreManager
- implements EntityPersistenceStore2
+ implements EntityPersistenceStore
{
// Attributes
@@ -157,7 +155,7 @@
// EJB Commands -
- public void initEntity(EntityEnterpriseContext ctx) throws RemoteException
+ public void initEntity(EntityEnterpriseContext ctx)
{
initEntityCommand.execute(ctx);
}
@@ -165,7 +163,7 @@
public Object createEntity(Method m,
Object[] args,
EntityEnterpriseContext ctx)
- throws RemoteException, CreateException
+ throws CreateException
{
return createEntityCommand.execute(m, args, ctx);
}
@@ -187,37 +185,32 @@
}
public void activateEntity(EntityEnterpriseContext ctx)
- throws RemoteException
{
activateEntityCommand.execute(ctx);
}
public void loadEntity(EntityEnterpriseContext ctx)
- throws RemoteException
{
loadEntityCommand.execute(ctx);
}
public void loadEntities(FinderResults keys)
- throws RemoteException
{
loadEntitiesCommand.execute(keys);
}
public void storeEntity(EntityEnterpriseContext ctx)
- throws RemoteException
{
storeEntityCommand.execute(ctx);
}
public void passivateEntity(EntityEnterpriseContext ctx)
- throws RemoteException
{
passivateEntityCommand.execute(ctx);
}
public void removeEntity(EntityEnterpriseContext ctx)
- throws RemoteException, RemoveException
+ throws RemoveException
{
removeEntityCommand.execute(ctx);
}
1.4 +2 -3
jboss/src/main/org/jboss/ejb/plugins/cmp/CreateEntityCommand.java
Index: CreateEntityCommand.java
===
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
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 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
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
h running JBoss with the EJB available, in this case a special EJB for clustering of configuration can be, will be a requirement. It is not the whooping 50k footprint that it takes that are going to make a difference. on 2 you are right about the db, but my first idea (well with juha really) was to have the ejb with a custom persistence engine, namely the one that reads and stores the xml files for configuration. This way you still have your familiar XML based configuration but the front end ejb enables you to lookup, read, load/store all that in a secure and transactional way. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Saturday, December 01, 2001 7:24 PM |To: 'David Budworth'; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |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
Re: [JBoss-dev] error starting jetty on W2k from cvs
Hi Rick Try again. I uploaded a fix for that this afternoon (west). Andy - Original Message - From: Rick Gibbs To: [EMAIL PROTECTED] Sent: Saturday, December 01, 2001 3:06 PM Subject: [JBoss-dev] error starting jetty on W2k from cvs Hi Jules, I just did a fresh checkout ( today ~2pm est) from cvs and tried to get jboss/jetty running but ran into the following problem during startup. JettyService can't find the jetty.properites file and I think it has something to do with an incompaitbility with the syntax you are using in Jetty.fixURL( ) and the windows filesystem. I tried to fix it myself, but since I am not too familar with the classloading in jboss I didn't get very far so I wanted to give you a heads up. Here is the url that it is using: jar:file:\./E:/projects/jboss-all/build/output/jboss-3.0.0alpha/tmp/deploy/ServiceDeployer/deploy.26/jetty-plugin.sar!/jetty.properties and the exception: java.util.zip.ZipException: The filename, directory name, or volume label syntax is incorrect at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(Unknown Source) at java.util.jar.JarFile.init(Unknown Source) at java.util.jar.JarFile.init(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.init(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(Unknown Source) at java.net.URL.openStream(Unknown Source) at org.jboss.jetty.JettyService.ensureProperties(JettyService.java:114) -Rick
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/bmp CustomFindByEntitiesCommand.java package.html
User: dsundstrom Date: 01/12/01 17:41:46 Removed: src/main/org/jboss/ejb/plugins/cmp/bmp CustomFindByEntitiesCommand.java package.html Log: Finished removal of lame factorization. Moved CMPStoreManager.PersistenceContext to JDBCContext. ___ 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 JDBCContext.java JDBCActivateEntityCommand.java JDBCCreateEntityCommand.java JDBCCustomFinderQuery.java JDBCDestroyCommand.java JDBCFindEntitiesCommand.java JDBCFindEntityCommand.java JDBCInitCommand.java JDBCInitEntityCommand.java JDBCLoadEntityCommand.java JDBCPassivateEntityCommand.java JDBCRemoveEntityCommand.java JDBCStartCommand.java JDBCStopCommand.java JDBCStoreEntityCommand.java
User: dsundstrom
Date: 01/12/01 17:41:46
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCActivateEntityCommand.java
JDBCCreateEntityCommand.java
JDBCCustomFinderQuery.java JDBCDestroyCommand.java
JDBCFindEntitiesCommand.java
JDBCFindEntityCommand.java JDBCInitCommand.java
JDBCInitEntityCommand.java
JDBCLoadEntityCommand.java
JDBCPassivateEntityCommand.java
JDBCRemoveEntityCommand.java JDBCStartCommand.java
JDBCStopCommand.java JDBCStoreEntityCommand.java
Added: src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCContext.java
Log:
Finished removal of lame factorization.
Moved CMPStoreManager.PersistenceContext to JDBCContext.
Revision ChangesPath
1.6 +2 -3
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCActivateEntityCommand.java
Index: JDBCActivateEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCActivateEntityCommand.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JDBCActivateEntityCommand.java2001/11/28 11:32:54 1.5
+++ JDBCActivateEntityCommand.java2001/12/02 01:41:46 1.6
@@ -8,7 +8,6 @@
package org.jboss.ejb.plugins.cmp.jdbc;
import org.jboss.ejb.EntityEnterpriseContext;
-import org.jboss.ejb.plugins.cmp.ActivateEntityCommand;
import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge;
/**
@@ -20,10 +19,10 @@
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*/
-public class JDBCActivateEntityCommand implements ActivateEntityCommand {
+public class JDBCActivateEntityCommand {
private JDBCEntityBridge entity;
public JDBCActivateEntityCommand(JDBCStoreManager manager) {
1.10 +2 -3
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCreateEntityCommand.java
Index: JDBCCreateEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCreateEntityCommand.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JDBCCreateEntityCommand.java 2001/12/01 21:55:04 1.9
+++ JDBCCreateEntityCommand.java 2001/12/02 01:41:46 1.10
@@ -17,7 +17,6 @@
import javax.sql.DataSource;
import org.jboss.ejb.EntityEnterpriseContext;
-import org.jboss.ejb.plugins.cmp.CreateEntityCommand;
import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge;
import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge;
import org.jboss.logging.Logger;
@@ -32,9 +31,9 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
-public class JDBCCreateEntityCommand implements CreateEntityCommand {
+public class JDBCCreateEntityCommand {
private JDBCStoreManager manager;
private JDBCEntityBridge entity;
private Logger log;
1.3 +2 -3
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCustomFinderQuery.java
Index: JDBCCustomFinderQuery.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCustomFinderQuery.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JDBCCustomFinderQuery.java2001/12/01 20:32:03 1.2
+++ JDBCCustomFinderQuery.java2001/12/02 01:41:46 1.3
@@ -18,7 +18,6 @@
import javax.ejb.FinderException;
import org.jboss.ejb.EntityEnterpriseContext;
-import org.jboss.ejb.plugins.cmp.FindEntitiesCommand;
import org.jboss.logging.Logger;
import org.jboss.util.FinderResults;
@@ -31,9 +30,9 @@
*
* @see org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
-public class JDBCCustomFinderQuery implements JDBCQueryCommand {
+public class JDBCCustomFinderQuery {
private Logger log;
/**
1.8 +2 -4
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDestroyCommand.java
Index: JDBCDestroyCommand.java
===
RCS file:
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp ActivateEntityCommand.java CMPStoreManager.java CommandFactory.java CreateEntityCommand.java DestroyCommand.java FindEntitiesCommand.java FindEntityCommand.java InitCommand.java InitEntityCommand.java LoadEntitiesCommand.java LoadEntityCommand.java PassivateEntityCommand.java RemoveEntityCommand.java StartCommand.java StopCommand.java StoreEntityCommand.java
User: dsundstrom Date: 01/12/01 17:41:46 Removed: src/main/org/jboss/ejb/plugins/cmp ActivateEntityCommand.java CMPStoreManager.java CommandFactory.java CreateEntityCommand.java DestroyCommand.java FindEntitiesCommand.java FindEntityCommand.java InitCommand.java InitEntityCommand.java LoadEntitiesCommand.java LoadEntityCommand.java PassivateEntityCommand.java RemoveEntityCommand.java StartCommand.java StopCommand.java StoreEntityCommand.java Log: Finished removal of lame factorization. Moved CMPStoreManager.PersistenceContext to JDBCContext. ___ 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/bridge JDBCCMP1xFieldBridge.java JDBCCMP2xFieldBridge.java JDBCCMRFieldBridge.java JDBCEntityBridge.java
User: dsundstrom
Date: 01/12/01 17:41:46
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge
JDBCCMP1xFieldBridge.java JDBCCMP2xFieldBridge.java
JDBCCMRFieldBridge.java JDBCEntityBridge.java
Log:
Finished removal of lame factorization.
Moved CMPStoreManager.PersistenceContext to JDBCContext.
Revision ChangesPath
1.9 +24 -15
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCCMP1xFieldBridge.java
Index: JDBCCMP1xFieldBridge.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCCMP1xFieldBridge.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JDBCCMP1xFieldBridge.java 2001/11/26 03:12:26 1.8
+++ JDBCCMP1xFieldBridge.java 2001/12/02 01:41:46 1.9
@@ -16,7 +16,7 @@
import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.EntityEnterpriseContext;
-import org.jboss.ejb.plugins.cmp.CMPStoreManager;
+import org.jboss.ejb.plugins.cmp.jdbc.JDBCContext;
import org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCCMPFieldMetaData;
@@ -35,19 +35,24 @@
* One for each entity bean cmp field.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
public class JDBCCMP1xFieldBridge extends JDBCAbstractCMPFieldBridge {
- protected Field field;
+ private Field field;
- public JDBCCMP1xFieldBridge(JDBCStoreManager manager, JDBCCMPFieldMetaData
metadata) throws DeploymentException {
+ public JDBCCMP1xFieldBridge(
+ JDBCStoreManager manager,
+ JDBCCMPFieldMetaData metadata) throws DeploymentException {
+
super(manager, metadata);
try {
- field = manager.getMetaData().getEntityClass().getField(getFieldName());
+ field = manager.getMetaData().getEntityClass().getField(
+ getFieldName());
} catch(NoSuchFieldException e) {
// Non recoverable internal exception
- throw new DeploymentException(No field named ' + getFieldName() + '
found in entity class.);
+ throw new DeploymentException(No field named ' + getFieldName() +
+ ' found in entity class.);
}
}
@@ -56,7 +61,8 @@
return field.get(ctx.getInstance());
} catch(Exception e) {
// Non recoverable internal exception
- throw new EJBException(Internal error getting instance field +
getFieldName() + : + e);
+ throw new EJBException(Internal error getting instance field +
+ getFieldName() + : + e);
}
}
@@ -65,7 +71,8 @@
field.set(ctx.getInstance(), value);
} catch(Exception e) {
// Non recoverable internal exception
- throw new EJBException(Internal error setting instance field +
getFieldName() + : + e);
+ throw new EJBException(Internal error setting instance field +
+ getFieldName() + : + e);
}
}
@@ -84,7 +91,8 @@
/**
* Mark this field as clean.
- * Saves the current state in context, so it can be compared when isDirty is
called.
+ * Saves the current state in context, so it can be compared when
+ * isDirty is called.
*/
public void setClean(EntityEnterpriseContext ctx) {
FieldState fieldState = getFieldState(ctx);
@@ -98,7 +106,8 @@
public boolean isReadTimedOut(EntityEnterpriseContext ctx) {
if(isReadOnly()) {
- long readInterval = System.currentTimeMillis() -
getFieldState(ctx).lastRead;
+ long readInterval = System.currentTimeMillis() -
+ getFieldState(ctx).lastRead;
return readInterval metadata.getReadTimeOut();
}
@@ -108,17 +117,17 @@
public void resetPersistenceContext(EntityEnterpriseContext ctx) {
if(isReadTimedOut(ctx)) {
- Map fieldStates =
((CMPStoreManager.PersistenceContext)ctx.getPersistenceContext()).fieldState;
- fieldStates.put(this, new FieldState());
+ JDBCContext jdbcCtx = (JDBCContext)ctx.getPersistenceContext();
+ jdbcCtx.put(this, new FieldState());
}
}
private FieldState getFieldState(EntityEnterpriseContext ctx) {
- Map fieldStates =
((CMPStoreManager.PersistenceContext)ctx.getPersistenceContext()).fieldState;
- FieldState fieldState = (FieldState)fieldStates.get(this);
+ JDBCContext jdbcCtx = (JDBCContext)ctx.getPersistenceContext();
+ FieldState fieldState = (FieldState)jdbcCtx.get(this);
if(fieldState == null) {
fieldState = new
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JBossUserRealm.java Jetty.java JettyService.java JettyServiceMBean.java
User: starksm
Date: 01/12/01 18:08:53
Modified:jetty/src/main/org/jboss/jetty Tag: Branch_2_4
JBossUserRealm.java Jetty.java JettyService.java
JettyServiceMBean.java
Log:
Synch up with changes for 2.4.4 and fix incorrect role type
passed to RealmMapping.doesUserHaveRole
Revision ChangesPath
No revision
No revision
1.2.2.4 +190 -189 contrib/jetty/src/main/org/jboss/jetty/JBossUserRealm.java
Index: JBossUserRealm.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossUserRealm.java,v
retrieving revision 1.2.2.3
retrieving revision 1.2.2.4
diff -u -r1.2.2.3 -r1.2.2.4
--- JBossUserRealm.java 2001/10/30 22:45:12 1.2.2.3
+++ JBossUserRealm.java 2001/12/02 02:08:53 1.2.2.4
@@ -1,189 +1,190 @@
-/*
- * jBoss, the OpenSource EJB server
- *
- * Distributable under GPL license.
- * See terms of license at gnu.org.
- */
-
-// $Id: JBossUserRealm.java,v 1.2.2.3 2001/10/30 22:45:12 jules_gosnell Exp $
-
-package org.jboss.jetty;
-
-import java.util.Collections;
-import java.util.HashMap;
-import java.util.Set;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-import org.apache.log4j.Category;
-import org.jboss.security.EJBSecurityManager;
-import org.jboss.security.RealmMapping;
-import org.jboss.security.SecurityAssociation;
-import org.jboss.security.SimplePrincipal;
-import org.mortbay.http.HttpRequest;
-import org.mortbay.http.UserPrincipal;
-import org.mortbay.http.UserRealm;
-
-/** An implementation of UserRealm that integrates with the JBossSX
- * security manager associted with the web application.
- * @author [EMAIL PROTECTED]
- * @version $Revision: 1.2.2.3 $
- */
-
-public class JBossUserRealm
- implements UserRealm
-{
- private Category _log;
- private String _realmName;
- private EJBSecurityManager _securityMgr;
- private RealmMapping _realmMapping;
- private HashMap_users = new HashMap();
-
- class User
-extends SimplePrincipal
-implements UserPrincipal
- {
-User(String name)
-{
- super(name);
- _log.info(Security- created JBossUserRealm::User: +name);
-}
-
-public boolean
- equals(Object o)
-{
- if (o==this)
- return true;
-
- if (o==null)
- return false;
-
- if (getClass()!=o.getClass())
- return false;
-
- String myName =this.getName();
- String yourName=((User)o).getName();
-
- if (myName==null yourName==null)
- return true;
-
- if (myName!=null myName.equals(yourName))
- return true;
-
- return false;
-}
-
-public boolean
- authenticate(String password, HttpRequest request)
-{
- boolean authenticated = false;
- String userName = this.getName(); // needs disambiguation
-
- // Get the JBoss security manager from the ENC context
- if(_securityMgr!=null _securityMgr.isValid(this, password))
- {
- authenticated = true;
- _log.info(Security- User: +userName+ is authenticated);
- SecurityAssociation.setPrincipal(this);
- SecurityAssociation.setCredential(password.toCharArray());
- }
- else
- {
- _log.warn(Security- User: +userName+ is NOT authenticated);
- }
-
- return authenticated;
-}
-
-public boolean
- isUserInRole(String role)
-{
- boolean isUserInRole = false;
- String userName = this.getName();
-
- // Get the JBoss security manager from the ENC context
- Set requiredRoles = Collections.singleton(role);
- if(_realmMapping.doesUserHaveRole(this, requiredRoles))
- {
- isUserInRole = true;
- _log.info(Security- User: +userName+ is in Role: +role);
- }
- else
- {
- _log.warn(Security- User: +userName+ is NOT in Role: +role);
- }
-
- return isUserInRole;
-}
-
-public UserRealm
- getUserRealm()
-{
- return JBossUserRealm.this;
-}
- }
-
- public
-JBossUserRealm(Category log, String realmName)
- {
-_log = log;
-_realmName = realmName;
-_log.info(Security- created JBossUserRealm: +_realmName);
- }
-
- public String
-getName()
- {
-return _realmName;
- }
-
- /**
- * @deprecated
- */
- public UserPrincipal
-getUser(String userName, HttpRequest request)
- {
-return getUser(userName);
- }
-
- //
-
- private synchronized User
-ensureUser(String userName)
- {
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty SetupHandler.java
User: starksm Date: 01/12/01 18:09:58 Modified:jetty/src/main/org/jboss/jetty Tag: Branch_2_4 SetupHandler.java Log: Update email address Revision ChangesPath No revision No revision 1.4.2.5 +3 -3 contrib/jetty/src/main/org/jboss/jetty/Attic/SetupHandler.java Index: SetupHandler.java === RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Attic/SetupHandler.java,v retrieving revision 1.4.2.4 retrieving revision 1.4.2.5 diff -u -r1.4.2.4 -r1.4.2.5 --- SetupHandler.java 2001/10/30 22:45:12 1.4.2.4 +++ SetupHandler.java 2001/12/02 02:09:58 1.4.2.5 @@ -5,7 +5,7 @@ * See terms of license at gnu.org. */ -// $Id: SetupHandler.java,v 1.4.2.4 2001/10/30 22:45:12 jules_gosnell Exp $ +// $Id: SetupHandler.java,v 1.4.2.5 2001/12/02 02:09:58 starksm Exp $ package org.jboss.jetty; @@ -25,8 +25,8 @@ * An HttpHandler that simply hooks into the web application startup * so that is sees the correct class loader and security realm name. * - * @author [EMAIL PROTECTED] - * @version $Revision: 1.4.2.4 $ + * @author [EMAIL PROTECTED] + * @version $Revision: 1.4.2.5 $ */ public class SetupHandler extends NullHandler ___ 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 to
Re: [JBoss-dev] error starting jetty on W2k from cvs
much better, thanks! - Original Message - From: Andreas Schaefer To: Rick Gibbs ; [EMAIL PROTECTED] Sent: Saturday, December 01, 2001 7:55 PM Subject: Re: [JBoss-dev] error starting jetty on W2k from cvs Hi Rick Try again. I uploaded a fix for that this afternoon (west). Andy - Original Message - From: Rick Gibbs To: [EMAIL PROTECTED] Sent: Saturday, December 01, 2001 3:06 PM Subject: [JBoss-dev] error starting jetty on W2k from cvs Hi Jules, I just did a fresh checkout ( today ~2pm est) from cvs and tried to get jboss/jetty running but ran into the following problem during startup. JettyService can't find the jetty.properites file and I think it has something to do with an incompaitbility with the syntax you are using in Jetty.fixURL( ) and the windows filesystem. I tried to fix it myself, but since I am not too familar with the classloading in jboss I didn't get very far so I wanted to give you a heads up. Here is the url that it is using: jar:file:\./E:/projects/jboss-all/build/output/jboss-3.0.0alpha/tmp/deploy/ServiceDeployer/deploy.26/jetty-plugin.sar!/jetty.properties and the exception: java.util.zip.ZipException: The filename, directory name, or volume label syntax is incorrect at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(Unknown Source) at java.util.jar.JarFile.init(Unknown Source) at java.util.jar.JarFile.init(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.init(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(Unknown Source) at java.net.URL.openStream(Unknown Source) at org.jboss.jetty.JettyService.ensureProperties(JettyService.java:114) -Rick
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 183 Successful tests: 178 Errors:2 Failures: 3 [time of test: 2 December 2001 3:5 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 183 Successful tests: 180 Errors:1 Failures: 2 [time of test: 2 December 2001 3:45 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
it isn't if we can have an admin that makes complete sense using our own infrastructure then so much the better, I really see no problem with that. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Budworth |Sent: Saturday, December 01, 2001 9:18 PM |To: Dain Sundstrom |Cc: 'David Budworth'; [EMAIL PROTECTED] |Subject: 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
[JBoss-dev] [ jboss-Bugs-487375 ] Typo in VerificationEventGeneratorSuppor
Bugs item #487375, was opened at 2001-11-29 20:45
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=487375group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Bob Spence (bgspence)
Assigned to: Juha Lindfors (juhalindfors)
Summary: Typo in VerificationEventGeneratorSuppor
Initial Comment:
I'm new to open source, but was reading the slashdot
article on JBoss and decided to take a look.
I downloaded the snapshot at:
jboss-all.zip 17708979 bytes Nov 29, 2001 2:09:42 AM
and took a first look in the sources at:
package org.jboss.verifier.event
The file VerificationEventGeneratorSupport.java has
the following snippit of code:
public void removeVerificationListener
(VerificationListener listener) {
super.addListener(listener);
}
Should the remove listener be adding one?
Enquiring minds want to know,
Bob Spence
(it's really my first peek into all this SourceForge
stuff)
--
Comment By: Juha Lindfors (juhalindfors)
Date: 2001-12-01 09:32
Message:
Logged In: YES
user_id=175239
Thanks for the report. This has been fixed in the 3.0 branch.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=487375group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 173 Successful tests: 170 Errors:1 Failures: 2 [time of test: 2 December 2001 4:45 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 183 Successful tests: 180 Errors:1 Failures: 2 [time of test: 2 December 2001 5:40 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-487994 ] JNDI context problem.
Bugs item #487994, was opened at 2001-12-01 21:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=487994group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Alex Pavlov (apavlov) Assigned to: Nobody/Anonymous (nobody) Summary: JNDI context problem. Initial Comment: I use SUN JDK 1.3.1_01 Server HotSpot VM, Win2K Proff. Problem exist on next bundles: JBoss 2.4.3+Tomcat 3.2 JBoss 2.4.3+Tomcat 4.01 JBoss 3.0alpaha+Jetty Problem: I put some object into HttpSession. Object implements HttpSession listener, and should perform some operation on JNDI context. Everything work fine for method 'valueBound(HttpSessionBindingEvent event)', but if I try to work with with JNDI from method 'valueUnbound(HttpSessionBindingEvent event)', I've got NameNotFoundException: conext 'env' not bound. Here is server log: [Default] Unbound from session: 0hkf2a5ei1 [Default] Event name: TestSessionScopeJNDI [Default] javax.naming.NameNotFoundException: env not bound [Default] at org.jnp.server.NamingServer.getBinding (NamingServer.java:495) [Default] [Default] at org.jnp.server.NamingServer.getBinding (NamingServer.java:503) [Default] [Default] at org.jnp.server.NamingServer.getObject (NamingServer.java:509) [Default] [Default] at org.jnp.server.NamingServer.lookup (NamingServer.java:282) [Default] [Default] at org.jnp.interfaces.NamingContext.lookup (NamingContext.java:349) [Default] [Default] at org.jnp.interfaces.NamingContext.lookup (NamingContext.java:457) [Default] [Default] at org.jnp.interfaces.NamingContext.lookup (NamingContext.java:333) [Default] [Default] at javax.naming.InitialContext.lookup (Unknown Source) [Default] [Default] at JndiPrintBean.valueUnbound(Unknown Source) [Default] [Default] at org.apache.tomcat.session.StandardSession.removeAttribu te(StandardSession.java:670) [Default] [Default] at org.apache.tomcat.session.StandardSession.expire (StandardSession.java:383) [Default] [Default] at org.apache.tomcat.session.StandardManager.processExpire s(StandardManager.java:483) [Default] [Default] at org.apache.tomcat.session.StandardManager.run (StandardManager.java:553) [Default] [Default] at java.lang.Thread.run(Unknown Source) [Default] -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=487994group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build Broken?
Ok, what on earth is paying attention to this value? Are you building or running? --jason On Tue, 27 Nov 2001, Julian Gosnell wrote: I should have been more specific. I only get the error when I set it ! Jules --- Hunter Hillegas [EMAIL PROTECTED] wrote: Yup, JBOSS_HOME was set properly. I'll do a refresh and test it again this afternoon to see if it persists... From: Julian Gosnell [EMAIL PROTECTED] Date: Tue, 27 Nov 2001 11:56:22 + (GMT) To: Hunter Hillegas [EMAIL PROTECTED], JBoss Dev [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build Broken? Have you got JBOSS_HOME set ? This one has bittent me before Jules --- Hunter Hillegas [EMAIL PROTECTED] wrote: Just grabbed the latest CVS and I get this on startup: 20:09:54,995 WARN [ServiceDeployer] SaxException getting document: java.io.FileNotFoundException: /usr/java/jboss/co6/jboss-all/server/src/resources/org/jboss/metadata/jboss- service.dtd (No such file or directory) at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) At this point the server shuts down... ___ 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 __ 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
Re: [JBoss-dev] Build Broken?
What needs JBOSS_HOME set to function? --jason On Tue, 27 Nov 2001, Hunter Hillegas wrote: Yup, JBOSS_HOME was set properly. I'll do a refresh and test it again this afternoon to see if it persists... From: Julian Gosnell [EMAIL PROTECTED] Date: Tue, 27 Nov 2001 11:56:22 + (GMT) To: Hunter Hillegas [EMAIL PROTECTED], JBoss Dev [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build Broken? Have you got JBOSS_HOME set ? This one has bittent me before Jules --- Hunter Hillegas [EMAIL PROTECTED] wrote: Just grabbed the latest CVS and I get this on startup: 20:09:54,995 WARN [ServiceDeployer] SaxException getting document: java.io.FileNotFoundException: /usr/java/jboss/co6/jboss-all/server/src/resources/org/jboss/metadata/jboss- service.dtd (No such file or directory) at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) At this point the server shuts down... ___ 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
RE: [JBoss-dev] Build Broken?
Looks like run.sh needs this (jboss_init_redhat.sh too, though I don't know anything about that script). run.sh will set this if it is not set to ../ from where the run.jar is, so that you don't have to be in the bin/ directory to execute the script and have it work correctly. Could possibly remove the check for its existance and always use ../ for JBOSS_HOME. Or could bitch that JBOSS_HOME is set and continue using that value. Looks like there are some references to JBOSS_HOME in the docs too. --jason On Tue, 27 Nov 2001, marc fleury wrote: what IS this JBOSS_HOME thing? it keeps pooping up and we keep banging it on the head, SETTING VARIABLES IS DUMB... who needs jboss-home set? marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Julian Gosnell |Sent: Tuesday, November 27, 2001 6:56 AM |To: Hunter Hillegas; JBoss Dev |Subject: Re: [JBoss-dev] Build Broken? | | |Have you got JBOSS_HOME set ? | |This one has bittent me before | | |Jules | | --- Hunter Hillegas [EMAIL PROTECTED] wrote: | Just grabbed the latest CVS and I get this on | startup: | | 20:09:54,995 WARN [ServiceDeployer] SaxException | getting document: | java.io.FileNotFoundException: | |/usr/java/jboss/co6/jboss-all/server/src/resources/org/jboss/metada |ta/jboss- | service.dtd (No such file or directory) | at | |org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) | | | At this point the server shuts down... | | | ___ | 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
