Re: [JBoss-dev] Will grand unification of CL solve this?
Anatoly Akkerman wrote: > I've been seeing the following problem and have been wondering how to > solve it or whether the grand unification will solve it. > > I am writing an EJB application that processes XML descriptors using > Castor. Now, Castor is loaded by the SL and is available to the > application but when an EJB invokes Castor, it has to be able to > instantiate certain classes from the application. It seems in 3.0alpha > this is not possible. The only way I can get rid of this problem is by > removing castor from lib/ext and deploying it as an application > library. This is, obviously not a good solution. > > In general, is there a way to deal with such issues? This is really a known bug of Castor. It, like a ton of other flawed libraries, does not use Thread.currentThread().getContextClassLoader().loadClass() to get classes. Instead it uses Class.forName(), which doesn't work properly. If this is changed in Castor, your code will work just fine. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs binary.jsp
User: starksm Date: 01/12/02 22:49:36 Modified:src/docs binary.jsp Log: Add the 2.4.4 beta links Revision ChangesPath 1.17 +31 -1 newsite/src/docs/binary.jsp Index: binary.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/binary.jsp,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- binary.jsp2001/11/28 16:34:28 1.16 +++ binary.jsp2001/12/03 06:49:36 1.17 @@ -27,8 +27,10 @@ DOWNLOAD THE JBOSS SERVER PRODUCTS TODAY! + JBoss 2.4.4 is our current beta version. It will run on 1.3+ JVMs. + JBoss 2.4.3 is our current stable version. It will run on 1.3+ JVMs. - + This is our full suite of products and it is likely to be all you will need to try out our technology. If you need a servlet container, we @@ -64,6 +66,34 @@ Size Date + +http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4-beta.zip";>JBoss-2.4.4-beta.zip +6,414,665 +November 28, 2001 + + +http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4-src.tgz";>JBoss-2.4.4-src.tgz Src Archive +23,601,950 +November 28, 2001 + + +http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4_Tomcat-4.0.1-beta.zip";>JBoss-2.4.4_Tomcat-4.0.1-beta.zip +11,712,873 +November 28, 2001 + + +http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4_Tomcat-3.2.4-beta.zip";>JBoss-2.4.4_Tomcat-3.2.4-beta.zip +9,764,030 +November 28, 2001 + + +http://prdownloads.sourceforge.net/jboss/JBoss-2.4.4-beta_Jetty-3.1.3-1.zip";>JBoss-2.4.4-beta_Jetty-3.1.3-1.zip +10659593 +December 2, 2001 + + + + http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3.zip";>JBoss-2.4.3.zip 6.1M ___ 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
I just took a look at this and it has been fixed by Jules. - Original Message - From: "Peter Levart" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Jules Gosnell" <[EMAIL PROTECTED]> Sent: Saturday, December 01, 2001 7:47 AM Subject: 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 > ___ 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: 3 December 2001 5:41 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-Patches-488277 ] Make JBoss compile with JDK 1.4 (#3)
Patches item #488277, was opened at 2001-12-02 21:31
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=488277&group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Guillaume Boissiere (boissier)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make JBoss compile with JDK 1.4 (#3)
Initial Comment:
- patch #3: Same thing as previous patch but for the
testsuite TestConnection.java file.
Please apply. Thanks!
-- Guillaume
--- jboss-
all/testsuite/src/main/org/jboss/test/util/TestConnecti
on.java Sun Oct 21 19:03:48 2001
+++ jboss-all-
new/testsuite/src/main/org/jboss/test/util/TestConnecti
on.java Sun Dec 2 21:49:50 2001
@@ -118,4 +118,49 @@
public void setTypeMap(Map parm1) throws
java.sql.SQLException {
throw new SQLException(TEST_DB);
}
+
+
+ // Note: The following methods have been added to
make the testsuite compile
+ // with JDK 1.4.
+ // These methods will need to be implemented
later on.
+ // Uncomment those 12 methods to compile JBoss
with JDK 1.4.
+ /*
+ public Statement createStatement(int
resultSetType, int resultSetConcurrency, int
resultSetHoldability) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public int getHoldability() throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public CallableStatement prepareCall(String sql,
int resultSetType, int resultSetConcurrency, int
resultSetHoldability) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String
sql, int autoGeneratedKeys) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String
sql, int resultSetType, int resultSetConcurrency, int
resultSetHoldability) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String
sql, int[] columnIndexes) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public PreparedStatement prepareStatement(String
sql, String[] columnNames) throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public void releaseSavepoint(Savepoint savepoint)
throws SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public void rollback(Savepoint savepoint) throws
SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public void setHoldability(int holdability) throws
SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public Savepoint setSavepoint() throws
SQLException {
+throw new SQLException(TEST_DB);
+ }
+ public Savepoint setSavepoint(String name) throws
SQLException {
+throw new SQLException(TEST_DB);
+ }
+ */
+
}
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=488277&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-488276 ] Make JBoss compile with JDK 1.4 (#2)
Patches item #488276, was opened at 2001-12-02 21:25
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=488276&group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Guillaume Boissiere (boissier)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make JBoss compile with JDK 1.4 (#2)
Initial Comment:
- patch #2: In JDK 1.4, the interfaces
java.sql.Statement, java.sql.PreparedStatement,
java.sql.Connection and java.sql.ResultSet have new
methods.
The patch below adds code that adds those interfaces
to make the project compile. The code is commented so
that:
1. it works with JDK 1.3
2. users using JDK 1.4 can easily figure out what to
uncomment to make it work without having to go through
the whole debugging process
Please apply:
diff -urN jboss-
all/connector/src/main/org/jboss/resource/adapter/jdbc/
local/ConnectionInPool.java jboss-all-
new/connector/src/main/org/jboss/resource/adapter/jdbc/
local/ConnectionInPool.java
--- jboss-
all/connector/src/main/org/jboss/resource/adapter/jdbc/
local/ConnectionInPool.java Fri Nov 23 00:54:55
2001
+++ jboss-all-
new/connector/src/main/org/jboss/resource/adapter/jdbc/
local/ConnectionInPool.java Sun Dec 2 21:47:39
2001
@@ -3,11 +3,16 @@
*/
package org.jboss.resource.adapter.jdbc.local;
+// Uncomment this one line to compile JBoss with JDK
1.4
+//import java.lang.UnsupportedOperationException;
+
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
+
+// Uncomment this one line to compile JBoss with JDK
1.4
+//import java.sql.Savepoint;
+
import java.sql.SQLException;
import java.sql.SQLWarning;
import java.sql.Statement;
@@ -898,4 +903,48 @@
}
}
}
+
+
+ // Note: The following methods have been added to
make JBoss compile with JDK 1.4.
+ // These methods will need to be implemented
later on.
+ // Uncomment those 12 methods to compile JBoss
with JDK 1.4.
+ /*
+ public Statement createStatement(int
resultSetType, int resultSetConcurrency, int
resultSetHoldability) throws SQLException {
+ throw new UnsupportedOperationException("Method
createStatement() not yet implemented.");
+ }
+ public int getHoldability() throws SQLException {
+ throw new UnsupportedOperationException("Method
getHoldability() not yet implemented.");
+ }
+ public CallableStatement prepareCall(String sql,
int resultSetType, int resultSetConcurrency, int
resultSetHoldability) throws SQLException {
+ throw new UnsupportedOperationException("Method
prepareCall() not yet implemented.");
+ }
+ public PreparedStatement prepareStatement(String
sql, int autoGeneratedKeys) throws SQLException {
+ throw new UnsupportedOperationException("Method
prepareStatement() not yet implemented.");
+ }
+ public PreparedStatement prepareStatement(String
sql, int resultSetType, int resultSetConcurrency, int
resultSetHoldability) throws SQLException {
+ throw new UnsupportedOperationException("Method
prepareStatement() not yet implemented.");
+ }
+ public PreparedStatement prepareStatement(String
sql, int[] columnIndexes) throws SQLException {
+ throw new UnsupportedOperationException("Method
prepareStatement() not yet implemented.");
+ }
+ public PreparedStatement prepareStatement(String
sql, String[] columnNames) throws SQLException {
+ throw new UnsupportedOperationException("Method
prepareStatement() not yet implemented.");
+ }
+ public void releaseSavepoint(Savepoint savepoint)
throws SQLException {
+ throw new UnsupportedOperationException("Method
releaseSavepoint() not yet implemented.");
+ }
+ public void rollback(Savepoint savepoint) throws
SQLException {
+ throw new UnsupportedOperationException("Method
rollback() not yet implemented.");
+ }
+ public void setHoldability(int holdability) throws
SQLException {
+ throw new UnsupportedOperationException("Method
setHoldability() not yet implemented.");
+ }
+ public Savepoint setSavepoint() throws
SQLException {
+ throw new UnsupportedOperationException("Method
setSavepoint() not yet implemented.");
+ }
+ public Savepoint setSavepoint(String name) throws
SQLException {
+ throw new UnsupportedOperationException("Method
setSavepoint() not yet implemented.");
+ }
+ */
+
}
diff -urN jboss-
all/connector/src/main/org/jboss/resource/adapter/jdbc/
local/PreparedStatementInPool.java jboss-all-
new/connector/src/main/org/jboss/resource/adapter/jdbc/
local/PreparedStatementInPool.java
--- jboss-
all/connector/src/main/org/jboss/resource/adapter/jdbc/
local/PreparedStatementInPool.java Sat Sep 8
16:32:20 2001
+++ jboss-all-
new/connector/src/main/org/jboss/resource/adapter/jdbc/
local/PreparedStatementInPool.java Sun
[JBoss-dev] [ jboss-Patches-488274 ] Make JBoss compile with JDK 1.4 (#1)
Patches item #488274, was opened at 2001-12-02 21:11
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=488274&group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Guillaume Boissiere (boissier)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make JBoss compile with JDK 1.4 (#1)
Initial Comment:
The following 3 patches are needed to make JBoss
compile with JDK 1.4beta3. All specific 1.4 stuff is
commented by default so that it does not break
anything.
- patch #1: In JDK 1.4, the Throwable interface has a
new method: public Throwable getCause()
This causes a conflict with the file
BankException.java. Obvious patch attached.
--- jboss-
all/testsuite/src/main/org/jboss/test/bank/interfaces/B
ankException.java Sun Jan 7 18:14:35 2001
+++ jboss-all-
new/testsuite/src/main/org/jboss/test/bank/interfaces/B
ankException.java Sun Dec 2 10:24:39 2001
@@ -37,7 +37,7 @@
}
// Public -
---
- public Exception getCause() { return cause; }
+ public Throwable getCause() { return cause; }
public String toString() { return super.toString()
+", Cause:"+cause; }
}
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=488274&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: website-snapshots build.xml
Hey, I don't really have time at the moment to look this over. I am not
ignoring you, just don't have time to give this the attention that it
deserves.
--jason
On Sun, 25 Nov 2001 [EMAIL PROTECTED] wrote:
> Why set permissions to 655? (rw owner, rx for group and world) --- the
> owner of the files can't execute these---755 is probably the right choice
> here. Really, build.sh is the only one to worry about --- I don't see why
> you can't execute the 'ant' program or 'antRun' with calls to sh like 'sh
> ../tools/bin/ant' (pretty much has to be configured correctly on any UNIX
> system for it to function). Even if we are still having trouble getting
> build.sh executable properly, it's easy enough to drop in a README or
> INSTALL doc to tell the user to execute 'sh build.sh' which should work
> regardless.
>
> Why does build.sh need the search() function anyway? Don't we pretty much
> know where our version of ant is going to be located? You can just export
> ANT_HOME to be whatever you
> want
>
> I know that this stuff is probably not JBoss' biggest priority right now,
> but I'd like to make this as easy as possible for anybody to build! (Tell
> me to shut up about this and I will -- I can make it work for myself
> regardless :)
>
> -jason
>
>
>
>
>
> Jason Dillon <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 11/21/2001 05:42 PM
>
>
> To: [EMAIL PROTECTED]
> cc:
> Subject:[JBoss-dev] CVS update: website-snapshots build.xml
>
>
>
> User: user57
> Date: 01/11/21 14:42:36
>
> Modified:.build.xml
> Log:
>o HACKED the build file to make all 'build.sh' and
> 'tools/bin/ant[Run]' files executable.
>! I don't really like it, but don't have much choice. Thanks SUN!
>
> Revision ChangesPath
> 1.2 +41 -17website-snapshots/build.xml
>
> Index: build.xml
> ===
> RCS file: /cvsroot/jboss/website-snapshots/build.xml,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -r1.1 -r1.2
> --- build.xml 2001/11/20 00:42:20 1.1
> +++ build.xml 2001/11/21 22:42:35 1.2
> @@ -10,7 +10,7 @@
>
>
>
> -
> +
>
>
>
> @@ -264,9 +264,9 @@
>Exporting CVS modules for snaphots...
>
>
> -
> +
>
> -
> +
> command="-Q -r -f -z3 export"
> date="TODAY"
> @@ -291,10 +291,18 @@
>
>
>
> - - longfile="gnu"
> - basedir="${build.snapshots.tmp}"
> - includes="jboss-all/**">
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
>zipfile="${build.snapshots}/jboss-all.tgz"/>
> @@ -309,27 +317,43 @@
>
>
>
> - - longfile="gnu"
> - basedir="${build.snapshots.tmp}"
> - includes="jboss-mq/**">
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
>zipfile="${build.snapshots}/jboss-mq.tgz"/>
>
>
> -
> -
> +
> +
>
>
>
>
>
>
> - - longfile="gnu"
> - basedir="${build.snapshots.tmp}"
> - includes="jboss-plugins/**">
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>
>zipfile="${build.snapshots}/jboss-plugins.tgz"/>
>
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 173 Successful tests: 170 Errors:1 Failures: 2 [time of test: 3 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] CVS update: jboss build.xml
User: starksm Date: 01/12/02 20:44:19 Modified:.build.xml Log: Need all jsse jars Revision ChangesPath 1.40 +4 -3 jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/build.xml,v retrieving revision 1.39 retrieving revision 1.40 diff -u -r1.39 -r1.40 --- build.xml 2001/12/03 04:33:06 1.39 +++ build.xml 2001/12/03 04:44:19 1.40 @@ -10,7 +10,7 @@ - + @@ -192,8 +192,9 @@ - - + + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS Head fails to build due to no com.sun.net.ssl.* package
The changes are still being merged, wait. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Budworth" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, December 02, 2001 8:07 PM Subject: [JBoss-dev] CVS Head fails to build due to no com.sun.net.ssl.* package > I just updated my tree after a few days, and SecurityDomain fails to > build now. It seems as though it can't find com.sun.net.ssl.* classes. > > And when looking in every jar file in the jdk, I can't find any package > containing "ssl" in it. > > Is there some other sun library we must install now? > > -David > > > Below is one of the errors I get. > > /home/david/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java :12: > cannot resolve symbol > symbol : class KeyManagerFactory > location: package ssl > import com.sun.net.ssl.KeyManagerFactory; > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.xml
User: starksm Date: 01/12/02 20:33:06 Modified:.build.xml Log: Add JSSE jars to build path Revision ChangesPath 1.39 +10 -1 jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/build.xml,v retrieving revision 1.38 retrieving revision 1.39 diff -u -r1.38 -r1.39 --- build.xml 2001/11/12 04:24:18 1.38 +++ build.xml 2001/12/03 04:33:06 1.39 @@ -10,7 +10,7 @@ - + @@ -188,6 +188,14 @@ + + + + + + + + @@ -268,6 +276,7 @@ + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata WebMetaData.java
User: starksm
Date: 01/12/02 20:28:14
Modified:src/main/org/jboss/metadata WebMetaData.java
Log:
Add ejb-local-ref support
Revision ChangesPath
1.6 +180 -126 jboss/src/main/org/jboss/metadata/WebMetaData.java
Index: WebMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/WebMetaData.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- WebMetaData.java 2001/11/26 03:17:48 1.5
+++ WebMetaData.java 2001/12/03 04:28:13 1.6
@@ -14,144 +14,198 @@
import org.jboss.deployment.DeploymentException;
-/** A representation of the web-app.xml and jboss-web.xml deployment
+/** A representation of the web.xml and jboss-web.xml deployment
* descriptors as used by the AbstractWebContainer web container integration
* support class.
- *
+ *
* @see XmlLoadable
* @see org.jboss.web.AbstractWebContainer
-
- * @author mailto:[EMAIL PROTECTED]";>Scott Stark.
- * @version $Revision: 1.5 $
+
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.6 $
*/
public class WebMetaData implements XmlLoadable
{
-private HashMap resourceReferences = new HashMap();
-private ArrayList environmentEntries = new ArrayList();
-private HashMap ejbReferences = new HashMap();
-private ArrayList securityRoleReferences = new ArrayList();
-private String securityDomain;
-
-public WebMetaData()
-{
-}
-
-/** Return an iterator of the env-entry mappings.
+ private HashMap resourceReferences = new HashMap();
+ private HashMap resourceEnvReferences = new HashMap();
+ private ArrayList environmentEntries = new ArrayList();
+ private HashMap ejbReferences = new HashMap();
+ private HashMap ejbLocalReferences = new HashMap();
+ private ArrayList securityRoleReferences = new ArrayList();
+ private String securityDomain;
+
+ public WebMetaData()
+ {
+ }
+
+ /** Return an iterator of the env-entry mappings.
@return Iterator of EnvEntryMetaData objects.
*/
-public Iterator getEnvironmentEntries()
-{
-return environmentEntries.iterator();
-}
-/** Return an iterator of the ejb-ref mappings.
+ public Iterator getEnvironmentEntries()
+ {
+ return environmentEntries.iterator();
+ }
+ /** Return an iterator of the ejb-ref mappings.
@return Iterator of EjbRefMetaData objects.
+*/
+ public Iterator getEjbReferences()
+ {
+ return ejbReferences.values().iterator();
+ }
+ /** Return an iterator of the ejb-local-ref mappings.
+@return Iterator of EjbLocalRefMetaData objects.
*/
-public Iterator getEjbReferences()
-{
-return ejbReferences.values().iterator();
-}
-/** Return an iterator of the resource-ref mappings.
+ public Iterator getEjbLocalReferences()
+ {
+ return ejbLocalReferences.values().iterator();
+ }
+
+ /** Return an iterator of the resource-ref mappings.
@return Iterator of ResourceRefMetaData objects.
+*/
+ public Iterator getResourceReferences()
+ {
+ return resourceReferences.values().iterator();
+ }
+ /** Return an iterator of the resource-ref mappings.
+@return Iterator of ResourceEnvRefMetaData objects.
*/
-public Iterator getResourceReferences()
-{
-return resourceReferences.values().iterator();
-}
-/** Return the optional security-domain jboss-web.xml element.
+ public Iterator getResourceEnvReferences()
+ {
+ return resourceEnvReferences.values().iterator();
+ }
+
+ /** Return the optional security-domain jboss-web.xml element.
@return The jndiName of the security manager implementation that is
-responsible for security of the web application. May be null if
-there was no security-domain specified in the jboss-web.xml
-descriptor.
-*/
-public String getSecurityDomain()
-{
-return securityDomain;
-}
-
-public void importXml(Element element) throws Exception
-{
-String rootTag =
element.getOwnerDocument().getDocumentElement().getTagName();
-if( rootTag.equals("web-app") )
-{
-importWebXml(element);
-}
-else if( rootTag.equals("jboss-web") )
-{
-importJBossWebXml(element);
-}
-}
-
-/** Parse the elements of the web-app element used by the integration layer.
-*/
-protected void importWebXml(Element webApp) throws Exception
-{
-// Parse the web-app/resource-ref elements
-Iterator iterator = MetaData.getChildrenByTagName(webApp, "resource-ref");
-while( iterator.hasNext() )
-
[JBoss-dev] CVS update: jboss/src/main/org/jboss/web AbstractWebContainer.java AbstractWebContainerMBean.java
User: starksm
Date: 01/12/02 20:21:42
Modified:src/main/org/jboss/web AbstractWebContainer.java
AbstractWebContainerMBean.java
Log:
Merge 2.4 branch updated to main
Revision ChangesPath
1.9 +102 -48 jboss/src/main/org/jboss/web/AbstractWebContainer.java
Index: AbstractWebContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/web/AbstractWebContainer.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- AbstractWebContainer.java 2001/11/26 03:19:46 1.8
+++ AbstractWebContainer.java 2001/12/03 04:21:42 1.9
@@ -2,6 +2,7 @@
import java.net.MalformedURLException;
import java.net.URL;
+import java.net.URLClassLoader;
import java.util.HashMap;
import java.util.Iterator;
import javax.naming.Context;
@@ -14,9 +15,9 @@
import org.w3c.dom.Element;
import org.jboss.deployment.DeploymentException;
-import org.jboss.logging.Logger;
import org.jboss.metadata.EjbRefMetaData;
import org.jboss.metadata.EnvEntryMetaData;
+import org.jboss.metadata.ResourceEnvRefMetaData;
import org.jboss.metadata.ResourceRefMetaData;
import org.jboss.metadata.WebMetaData;
import org.jboss.naming.Util;
@@ -51,7 +52,7 @@
String password = f(request);
// Get the JBoss security manager from the ENC context
InitialContext iniCtx = new InitialContext();
-EJBSecurityManager securityMgr = (EJBSecurityManager)
iniCtx.lookup("java:comp/env/security/securityMgr");
+SecurityManager securityMgr = (SecurityManager)
iniCtx.lookup("java:comp/env/security/securityMgr");
SimplePrincipal principal = new SimplePrincipal(username);
if( securityMgr.isValid(principal, password) )
{
@@ -69,22 +70,22 @@
An outline of the steps for authorizing the user is:
-// Get the username & required roles from the request context...
-String username = f(request);
-String[] roles = f(request);
-// Get the JBoss security manager from the ENC context
-InitialContext iniCtx = new InitialContext();
-RealmMapping securityMgr = (RealmMapping)
iniCtx.lookup("java:comp/env/security/realmMapping");
-SimplePrincipal principal = new SimplePrincipal(username);
-Set requiredRoles = new HashSet(Arrays.asList(roles));
-if( securityMgr.doesUserHaveRole(principal, requiredRoles) )
-{
-// Indicate the user has the required roles for the web content...
-}
-else
-{
-// Deny access...
-}
+ // Get the username & required roles from the request context...
+ String username = f(request);
+ String[] roles = f(request);
+ // Get the JBoss security manager from the ENC context
+ InitialContext iniCtx = new InitialContext();
+ RealmMapping securityMgr = (RealmMapping)
iniCtx.lookup("java:comp/env/security/realmMapping");
+ SimplePrincipal principal = new SimplePrincipal(username);
+ Set requiredRoles = new HashSet(Arrays.asList(roles));
+ if( securityMgr.doesUserHaveRole(principal, requiredRoles) )
+ {
+ // Indicate the user has the required roles for the web content...
+ }
+ else
+ {
+ // Deny access...
+ }
The one thing to be aware of is the relationship between the thread context
@@ -106,13 +107,13 @@
@see #performUndeploy(String)
@see #parseWebAppDescriptors(ClassLoader, Element, Element)
@see #linkSecurityDomain(String, Context)
-@see org.jboss.security.EJBSecurityManager;
+@see org.jboss.security.SecurityManager;
@see org.jboss.security.RealmMapping;
@see org.jboss.security.SimplePrincipal;
@see org.jboss.security.SecurityAssociation;
-@author mailto:[EMAIL PROTECTED]";>Scott Stark.
-@version $Revision: 1.8 $
+@author [EMAIL PROTECTED]
+@version $Revision: 1.9 $
*/
public abstract class AbstractWebContainer extends ServiceMBeanSupport implements
AbstractWebContainerMBean
{
@@ -142,10 +143,6 @@
public void parseWebAppDescriptors(ClassLoader loader, Element webApp,
Element jbossWeb) throws Exception;
}
-/** The "WebContainer" log4j category instance available for logging related
-to WebContainer events.
- */
-protected Logger category = Logger.getLogger(this.getClass());
/** A mapping of deployed warUrl strings to the WebApplication object */
protected HashMap deploymentMap = new HashMap();
@@ -159,12 +156,16 @@
perform the container specific deployment steps and registers the
returned WebApplication in the deployment map. The steps performed are:
+ClassLoader appClassLoader = thread.getContextClassLoader();
+URLClassLoader warLoader = URLClassLoader.newInstance(empty,
appClassLoader);
+thread.setContextClassLoader(warLoader);
WebDe
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JBossUserRealm.java JBossWebApplicationContext.java
User: starksm
Date: 01/12/02 20:15:51
Modified:jetty/src/main/org/jboss/jetty JBossUserRealm.java
JBossWebApplicationContext.java
Log:
Change EJBSecurityMgr to AuthenticationManager
Revision ChangesPath
1.9 +5 -5 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.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JBossUserRealm.java 2001/11/21 23:13:01 1.8
+++ JBossUserRealm.java 2001/12/03 04:15:51 1.9
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossUserRealm.java,v 1.8 2001/11/21 23:13:01 jules_gosnell Exp $
+// $Id: JBossUserRealm.java,v 1.9 2001/12/03 04:15:51 starksm Exp $
package org.jboss.jetty;
@@ -17,7 +17,7 @@
import javax.naming.NamingException;
import javax.security.auth.Subject;
import org.apache.log4j.Category;
-import org.jboss.security.EJBSecurityManager;
+import org.jboss.security.AuthenticationManager;
import org.jboss.security.RealmMapping;
import org.jboss.security.SecurityAssociation;
import org.jboss.security.SimplePrincipal;
@@ -29,7 +29,7 @@
/** An implementation of UserRealm that integrates with the JBossSX
* security manager associted with the web application.
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.8 $
+ * @version $Revision: 1.9 $
*/
// TODO
@@ -135,7 +135,7 @@
private Category _log=Category.getInstance("Jetty");
private String _realmName;
- private EJBSecurityManager _securityMgr;
+ private AuthenticationManager _securityMgr;
private RealmMapping _realmMapping;
private HashMap_users = new HashMap();
private String _subjectAttributeName = "j_subject"; // needs
accessors - TODO
@@ -153,7 +153,7 @@
InitialContext iniCtx = new InitialContext();
// do we need the 'java:comp/env' prefix ? TODO
Context securityCtx =(Context) iniCtx.lookup("java:comp/env/security");
- _securityMgr =(EJBSecurityManager) securityCtx.lookup("securityMgr");
+ _securityMgr =(AuthenticationManager) securityCtx.lookup("securityMgr");
_realmMapping =(RealmMapping) securityCtx.lookup("realmMapping");
iniCtx=null;
1.6 +1 -2
contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java
Index: JBossWebApplicationContext.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JBossWebApplicationContext.java 2001/12/03 00:28:45 1.5
+++ JBossWebApplicationContext.java 2001/12/03 04:15:51 1.6
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossWebApplicationContext.java,v 1.5 2001/12/03 00:28:45 jules_gosnell Exp
$
+// $Id: JBossWebApplicationContext.java,v 1.6 2001/12/03 04:15:51 starksm Exp $
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -24,7 +24,6 @@
import javax.naming.Context;
import javax.naming.InitialContext;
-import org.jboss.security.EJBSecurityManager;
import org.jboss.security.RealmMapping;
import org.jboss.security.SimplePrincipal;
import org.jboss.security.SecurityAssociation;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS Head fails to build due to no com.sun.net.ssl.* package
I just updated my tree after a few days, and SecurityDomain fails to build now. It seems as though it can't find com.sun.net.ssl.* classes. And when looking in every jar file in the jdk, I can't find any package containing "ssl" in it. Is there some other sun library we must install now? -David Below is one of the errors I get. /home/david/jboss-all/server/src/main/org/jboss/security/SecurityDomain.java:12: cannot resolve symbol symbol : class KeyManagerFactory location: package ssl import com.sun.net.ssl.KeyManagerFactory; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 183 Successful tests: 180 Errors:1 Failures: 2 [time of test: 3 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
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Container.java ContainerFactory.java
User: starksm
Date: 01/12/02 19:43:42
Modified:src/main/org/jboss/ejb Container.java ContainerFactory.java
Log:
Rename EJBSecurityManager to AuthenticationManager
Revision ChangesPath
1.63 +5 -5 jboss/src/main/org/jboss/ejb/Container.java
Index: Container.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- Container.java2001/11/27 06:15:26 1.62
+++ Container.java2001/12/03 03:43:41 1.63
@@ -50,7 +50,7 @@
import org.jboss.metadata.ResourceRefMetaData;
import org.jboss.metadata.ResourceEnvRefMetaData;
import org.jboss.metadata.ApplicationMetaData;
-import org.jboss.security.EJBSecurityManager;
+import org.jboss.security.AuthenticationManager;
import org.jboss.security.RealmMapping;
import org.jboss.ejb.plugins.local.BaseLocalContainerInvoker;
@@ -73,7 +73,7 @@
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Scott Stark.
* @author Bill Burke
- * @version $Revision: 1.62 $
+ * @version $Revision: 1.63 $
*
* Revisions:
*
@@ -126,7 +126,7 @@
protected TransactionManager tm;
/** This is the SecurityManager */
- protected EJBSecurityManager sm;
+ protected AuthenticationManager sm;
/** This is the realm mapping */
protected RealmMapping rm;
@@ -192,12 +192,12 @@
return tm;
}
- public void setSecurityManager(EJBSecurityManager sm)
+ public void setSecurityManager(AuthenticationManager sm)
{
this.sm = sm;
}
- public EJBSecurityManager getSecurityManager()
+ public AuthenticationManager getSecurityManager()
{
return sm;
}
1.103 +3 -3 jboss/src/main/org/jboss/ejb/ContainerFactory.java
Index: ContainerFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/ContainerFactory.java,v
retrieving revision 1.102
retrieving revision 1.103
diff -u -r1.102 -r1.103
--- ContainerFactory.java 2001/11/28 01:15:08 1.102
+++ ContainerFactory.java 2001/12/03 03:43:42 1.103
@@ -41,7 +41,7 @@
import org.jboss.metadata.SessionMetaData;
import org.jboss.metadata.XmlFileLoader;
import org.jboss.metadata.XmlLoadable;
-import org.jboss.security.EJBSecurityManager;
+import org.jboss.security.AuthenticationManager;
import org.jboss.security.RealmMapping;
import org.jboss.system.ServiceMBeanSupport;
import org.jboss.util.MBeanProxy;
@@ -70,7 +70,7 @@
* @author mailto:[EMAIL PROTECTED]";>Peter Antman.
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
-* @version $Revision: 1.102 $
+* @version $Revision: 1.103 $
*/
public class ContainerFactory
extends ServiceMBeanSupport
@@ -714,7 +714,7 @@
confSecurityDomain = securityDomain;
//System.out.println("lookup securityDomain manager name:
"+confSecurityDomain);
Object securityMgr = iniCtx.lookup(confSecurityDomain);
-EJBSecurityManager ejbS = (EJBSecurityManager) securityMgr;
+AuthenticationManager ejbS = (AuthenticationManager) securityMgr;
RealmMapping rM = (RealmMapping) securityMgr;
container.setSecurityManager( ejbS );
container.setRealmMapping( rM );
___
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 SecurityInterceptor.java SecurityProxyInterceptor.java
User: starksm
Date: 01/12/02 19:43:42
Modified:src/main/org/jboss/ejb/plugins SecurityInterceptor.java
SecurityProxyInterceptor.java
Log:
Rename EJBSecurityManager to AuthenticationManager
Revision ChangesPath
1.27 +3 -3 jboss/src/main/org/jboss/ejb/plugins/SecurityInterceptor.java
Index: SecurityInterceptor.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/SecurityInterceptor.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- SecurityInterceptor.java 2001/11/26 03:12:25 1.26
+++ SecurityInterceptor.java 2001/12/03 03:43:42 1.27
@@ -17,7 +17,7 @@
import org.jboss.metadata.BeanMetaData;
import org.jboss.metadata.SecurityIdentityMetaData;
import org.jboss.security.AnybodyPrincipal;
-import org.jboss.security.EJBSecurityManager;
+import org.jboss.security.AuthenticationManager;
import org.jboss.security.RealmMapping;
import org.jboss.security.SecurityAssociation;
import org.jboss.security.SimplePrincipal;
@@ -27,7 +27,7 @@
@author Oleg Nitz
@author mailto:[EMAIL PROTECTED]";>Scott Stark.
-@version $Revision: 1.26 $
+@version $Revision: 1.27 $
*/
public class SecurityInterceptor extends AbstractInterceptor
{
@@ -42,7 +42,7 @@
* @supplierQualifier authentication
* @clientCardinality 1..*
*/
-protected EJBSecurityManager securityManager;
+protected AuthenticationManager securityManager;
/**
* @supplierCardinality 0..1
1.8 +3 -3
jboss/src/main/org/jboss/ejb/plugins/SecurityProxyInterceptor.java
Index: SecurityProxyInterceptor.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/SecurityProxyInterceptor.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- SecurityProxyInterceptor.java 2001/11/24 20:43:23 1.7
+++ SecurityProxyInterceptor.java 2001/12/03 03:43:42 1.8
@@ -18,7 +18,7 @@
import org.jboss.ejb.EnterpriseContext;
import org.jboss.ejb.MethodInvocation;
-import org.jboss.security.EJBSecurityManager;
+import org.jboss.security.AuthenticationManager;
import org.jboss.security.SecurityProxy;
import org.jboss.security.SecurityProxyFactory;
@@ -30,7 +30,7 @@
* interceptor has access to the EJB instance and context.
*
* @author mailto:[EMAIL PROTECTED]";>Scott Stark.
- * @version $Revision: 1.7 $
+ * @version $Revision: 1.8 $
*/
public class SecurityProxyInterceptor
extends AbstractInterceptor
@@ -51,7 +51,7 @@
*/
protected Container container;
- protected EJBSecurityManager securityManager;
+ protected AuthenticationManager securityManager;
/**
* @supplierCardinality 0..1
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/security AuthenticationManager.java SecurityDomain.java AnybodyPrincipal.java NobodyPrincipal.java RealmMapping.java SecurityAssociation.java SecurityProxy.java SecurityProxyFactory.java SimplePrincipal.java SubjectSecurityManager.java EJBSecurityManager.java
User: starksm
Date: 01/12/02 19:43:05
Modified:src/main/org/jboss/security AnybodyPrincipal.java
NobodyPrincipal.java RealmMapping.java
SecurityAssociation.java SecurityProxy.java
SecurityProxyFactory.java SimplePrincipal.java
SubjectSecurityManager.java
Added: src/main/org/jboss/security AuthenticationManager.java
SecurityDomain.java
Removed: src/main/org/jboss/security EJBSecurityManager.java
Log:
Rename EJBSecurityManager to AuthenticationManager and update author email
Revision ChangesPath
1.5 +2 -2 jboss/src/main/org/jboss/security/AnybodyPrincipal.java
Index: AnybodyPrincipal.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/security/AnybodyPrincipal.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- AnybodyPrincipal.java 2001/08/03 17:15:56 1.4
+++ AnybodyPrincipal.java 2001/12/03 03:43:05 1.5
@@ -16,8 +16,8 @@
Note that this class is not likely to operate correctly in a collection
since the hashCode() and equals() methods are not correlated.
-@author mailto:[EMAIL PROTECTED]";>Scott Stark.
-@version $Revision: 1.4 $
+@author [EMAIL PROTECTED]
+@version $Revision: 1.5 $
*/
public class AnybodyPrincipal implements Comparable, Principal
{
1.5 +2 -2 jboss/src/main/org/jboss/security/NobodyPrincipal.java
Index: NobodyPrincipal.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/security/NobodyPrincipal.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- NobodyPrincipal.java 2001/08/03 17:15:56 1.4
+++ NobodyPrincipal.java 2001/12/03 03:43:05 1.5
@@ -16,8 +16,8 @@
Note that this class is not likely to operate correctly in a collection
since the hashCode() and equals() methods are not correlated.
-@author mailto:[EMAIL PROTECTED]";>Scott Stark.
-@version $Revision: 1.4 $
+@author [EMAIL PROTECTED]
+@version $Revision: 1.5 $
*/
public class NobodyPrincipal implements Comparable, Principal
{
1.7 +2 -2 jboss/src/main/org/jboss/security/RealmMapping.java
Index: RealmMapping.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/security/RealmMapping.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- RealmMapping.java 2001/09/26 05:59:50 1.6
+++ RealmMapping.java 2001/12/03 03:43:05 1.7
@@ -17,8 +17,8 @@
environment Principal belongs via the {@link #getPrincipal(Principal) getPrincipal}
method.
-@author mailto:[EMAIL PROTECTED]";>Scott Stark.
-@version $Revision: 1.6 $
+@author [EMAIL PROTECTED]
+@version $Revision: 1.7 $
*/
public interface RealmMapping
{
1.8 +4 -4 jboss/src/main/org/jboss/security/SecurityAssociation.java
Index: SecurityAssociation.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/security/SecurityAssociation.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- SecurityAssociation.java 2001/08/10 17:51:32 1.7
+++ SecurityAssociation.java 2001/12/03 03:43:05 1.8
@@ -31,8 +31,8 @@
the current VM.
@author Daniel O'Connor ([EMAIL PROTECTED])
-@author mailto:[EMAIL PROTECTED]";>Scott Stark.
-@version $Revision: 1.7 $
+@author [EMAIL PROTECTED]
+@version $Revision: 1.8 $
*/
public final class SecurityAssociation
{
@@ -48,11 +48,11 @@
boolean useThreadLocal = false;
try
{
- useThreadLocal =
Boolean.getBoolean("org.jboss.security.SecurityAssociation.ThreadLocal");
+useThreadLocal =
Boolean.getBoolean("org.jboss.security.SecurityAssociation.ThreadLocal");
}
catch(SecurityException e)
{
- // Just use the default
+// Ignore and use the default
}
if( useThreadLocal )
1.4 +2 -2 jboss/src/main/org/jboss/security/SecurityProxy.java
Index: SecurityProxy.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/security/SecurityProxy.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SecurityProxy.java2001/08/03 17:15:56 1.3
+++ SecurityProxy.java2001/12/03 03:43:05 1.4
@@ -15,8 +15,8 @@
Custom security checks are those that cannot be described using the
standard EJB deployment time declarative role based security.
-@author mailto:[E
[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: 3 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] Changes to State-Management in ServiceMBeanSupport
Hi Geeks In JSR-77 I need to know when a component failed to be started. Right now ServiceMBeanSupport only goes back to STOPPED when starting of the component failed. Now I would like to add a new start called FAILED. Whenever a component failed to start OR stop in will go into this state. I would implement it this way that the state FAILED works like STOPPED. Any objections ? x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jdk bug 4388666 resolved
http://developer.java.sun.com/developer/bugParade/bugs/4388666.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JSR-77 Update
Hi Geeks Today I started to implement the StateManagement to the first JSR-77 component (JNDI). Now a user can use JSR-77 to start and stop the components implementing State Management. To test it: - get latest JBoss from CVS - create it - start it - open HTML-Adaptor - go to domain: SingleJBoss - select the component with attribute "name=LocalJNDI" - click on it - go to the stop-button, click on it and see in the JBoss console output that JNDI is stopped. Have fun x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/naming NamingService.java
User: schaefera
Date: 01/12/02 18:26:01
Modified:src/main/org/jboss/naming NamingService.java
Log:
Added the State-Management to the JSR-77 JNDI component as well as
adding the proper creation in the NamingService of this component.
Now postRegister() and postDeregister() create/destroy the JSR-77
representant because then start() and stop() works as expected.
I also added a ServiceName which is the actual name of the MBean
to the ServiceMBeanSupport therefore the MBean itself can hand its
name over to another MBean (necessary for JSR-77).
Revision ChangesPath
1.22 +41 -17jboss/src/main/org/jboss/naming/NamingService.java
Index: NamingService.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/naming/NamingService.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- NamingService.java2001/11/28 06:33:38 1.21
+++ NamingService.java2001/12/03 02:26:01 1.22
@@ -25,15 +25,26 @@
import org.jboss.management.j2ee.JNDI;
import org.jboss.system.ServiceMBeanSupport;
-/** A JBoss service that starts the jnp JNDI server.
- *
- * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
- * @author mailto:[EMAIL PROTECTED]";>Scott Stark.
- * @version $Revision: 1.21 $
+/**
+ * A JBoss service that starts the jnp JNDI server.
*
- * Revisions:
- * 20010622 scott.stark: Report IntialContext env for problem tracing
- */
+ * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
+ * @author mailto:[EMAIL PROTECTED]";>Scott Stark.
+ * @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
+ * @version $Revision: 1.22 $
+ *
+ * Revisions:
+ *
+ * 20010622 scott.stark:
+ *
+ * Report IntialContext env for problem tracing
+ *
+ * 20011202 Andreas Schaefer:
+ *
+ * Added JSR-77 representation, see {@liink #postRegister postRegister()}
+ * and {@link #postDeregister postDeregister()}.
+ *
+ **/
public class NamingService
extends ServiceMBeanSupport
implements NamingServiceMBean
@@ -43,6 +54,9 @@
// Attributes
Main naming;
+ /** Object Name of the JSR-77 representant of this servie **/
+ ObjectName mJNDI;
+
// Static
// Constructors --
@@ -173,21 +187,31 @@
Context ctx = (Context)iniCtx.lookup("java:");
ctx.rebind("comp", envRef);
log.info("Naming started on port "+naming.getPort());
-
- // Finally create the JSR-77 management representation
- JNDI.create( getServer(), "LocalJNDI" );
}
public void stopService()
{
- // First destroy the JSR-77 management representation
- JNDI.destroy( getServer(), "LocalJNDI" );
-
naming.stop();
log.info("JNP server stopped");
}
-
+
+ public void postRegister( Boolean pRegistrationDone )
+ {
+ super.postRegister( pRegistrationDone );
+ if( pRegistrationDone.booleanValue() ) {
+ // Create the JSR-77 management representation
+ mJNDI = JNDI.create( getServer(), "LocalJNDI", getServiceName() );
+ }
+ }
+
+ public void postDeregister()
+ {
+ super.postDeregister();
+ if( mJNDI != null ) {
+ // Destroy the JSR-77 management representation
+ JNDI.destroy( getServer(), "LocalJNDI" );
+ }
+ }
+
// Protected -
}
-
-
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/management/j2ee JNDI.java
User: schaefera
Date: 01/12/02 18:26:01
Modified:src/main/org/jboss/management/j2ee JNDI.java
Log:
Added the State-Management to the JSR-77 JNDI component as well as
adding the proper creation in the NamingService of this component.
Now postRegister() and postDeregister() create/destroy the JSR-77
representant because then start() and stop() works as expected.
I also added a ServiceName which is the actual name of the MBean
to the ServiceMBeanSupport therefore the MBean itself can hand its
name over to another MBean (necessary for JSR-77).
Revision ChangesPath
1.5 +88 -7 jboss/src/main/org/jboss/management/j2ee/JNDI.java
Index: JNDI.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/JNDI.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JNDI.java 2001/11/28 06:33:37 1.4
+++ JNDI.java 2001/12/03 02:26:01 1.5
@@ -6,18 +6,23 @@
*/
package org.jboss.management.j2ee;
+import javax.management.AttributeChangeNotification;
+import javax.management.JMException;
import javax.management.MalformedObjectNameException;
import javax.management.MBeanServer;
+import javax.management.Notification;
+import javax.management.NotificationListener;
import javax.management.ObjectName;
import org.jboss.logging.Logger;
+import org.jboss.system.ServiceMBean;
/**
* Root class of the JBoss JSR-77 implementation of
* {@link javax.management.j2ee.JNDI JNDI}.
*
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*
* Revisions:
*
@@ -25,6 +30,10 @@
*
* Adjustments to the JBoss Guidelines
*
+ * 20011202 Andreas Schaefer:
+ *
+ * Added state handling (except event notification)
+ *
**/
public class JNDI
extends J2EEResource
@@ -34,6 +43,10 @@
// Attributes
+ private long mStartTime = -1;
+ private int mState = ServiceMBean.STOPPED;
+ private ObjectName mService;
+
// Static
private static final String[] sTypes = new String[] {
@@ -46,7 +59,7 @@
"state.failed"
};
- public static ObjectName create( MBeanServer pServer, String pName ) {
+ public static ObjectName create( MBeanServer pServer, String pName, ObjectName
pService ) {
Logger lLog = Logger.getLogger( JNDI.class );
ObjectName lServer = null;
try {
@@ -60,16 +73,18 @@
return null;
}
try {
- // Now create the J2EEApplication
+ // Now create the JNDI Representant
return pServer.createMBean(
"org.jboss.management.j2ee.JNDI",
null,
new Object[] {
pName,
- lServer
+ lServer,
+ pService
},
new String[] {
String.class.getName(),
+ ObjectName.class.getName(),
ObjectName.class.getName()
}
).getObjectName();
@@ -106,12 +121,14 @@
*
* @throws InvalidParameterException If list of nodes or ports was null or empty
**/
- public JNDI( String pName, ObjectName pServer )
+ public JNDI( String pName, ObjectName pServer, ObjectName pService )
throws
MalformedObjectNameException,
InvalidParentException
{
super( "JNDI", pName, pServer );
+ getLog().info( "Service name: " + pService );
+ mService = pService;
}
// javax.managment.j2ee.EventProvider implementation -
@@ -131,22 +148,63 @@
// javax.management.j2ee.StateManageable implementation --
public long getStartTime() {
- return 0;
+ return mStartTime;
}
public int getState() {
- return 0;
+ return mState;
}
public void start() {
+ try {
+ getServer().invoke(
+mService,
+"start",
+new Object[] {},
+new String[] {}
+ );
+ }
+ catch( JMException jme ) {
+ //AS ToDo: later on we have to define what happens when service could not
be started
+ jme.printStackTrace();
+ }
}
public void startRecursive() {
+ // No recursive start here
+ start();
}
public void stop() {
+ try {
+ getServer().invoke(
+mService,
+"s
[JBoss-dev] CVS update: jboss/src/main/org/jboss/system ServiceMBeanSupport.java
User: schaefera
Date: 01/12/02 18:26:02
Modified:src/main/org/jboss/system ServiceMBeanSupport.java
Log:
Added the State-Management to the JSR-77 JNDI component as well as
adding the proper creation in the NamingService of this component.
Now postRegister() and postDeregister() create/destroy the JSR-77
representant because then start() and stop() works as expected.
I also added a ServiceName which is the actual name of the MBean
to the ServiceMBeanSupport therefore the MBean itself can hand its
name over to another MBean (necessary for JSR-77).
Revision ChangesPath
1.7 +40 -10jboss/src/main/org/jboss/system/ServiceMBeanSupport.java
Index: ServiceMBeanSupport.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/ServiceMBeanSupport.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ServiceMBeanSupport.java 2001/11/26 03:19:46 1.6
+++ ServiceMBeanSupport.java 2001/12/03 02:26:01 1.7
@@ -23,17 +23,24 @@
* service that conforms to the ServiceMBean interface. Subclasses must
* override {@link #getName} method and should override
* {@link #startService}, and {@link #stopService} as approriate.
- *
- *
+ *
* @see ServiceMBean
*
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
- * @version $Revision: 1.6 $
- *
- * Revisions:
- * 20010619 scott.stark: use the full service class name as the log4j
- * log name
+ * @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer
+ * @version $Revision: 1.7 $
+ *
+ * Revisions:
+ *
+ * 20010619 scott.stark:
+ *
+ * use the full service class name as the log4j log name
+ *
+ * 20011202 Andreas Schaefer:
+ *
+ * Add the own MBean Service Name to be remembered in an attribute
+ *
*/
public abstract class ServiceMBeanSupport
extends NotificationBroadcasterSupport
@@ -43,6 +50,8 @@
private int state;
private MBeanServer server;
+ /** Own Object Name this MBean is registered with, see {@link #preRegister
preRegister()}. **/
+ private ObjectName mServiceName;
private int id = 0;
protected Logger log;
@@ -60,6 +69,10 @@
public abstract String getName();
+ public ObjectName getServiceName() {
+ return mServiceName;
+ }
+
public MBeanServer getServer()
{
return server;
@@ -187,12 +200,30 @@
NDC.pop();
}
*/
+
+ /**
+ * Callback method of {@link javax.management.MBeanRegistration MBeanRegistration}
+ * before the MBean is registered at the JMX Agent.
+ *
+ * Attention: Always call this method when you overwrite it in a subclass
+ * because it saves the Object Name of the MBean.
+ *
+ * @param server Reference to the JMX Agent this MBean is registered on
+ * @param name Name specified by the creator of the MBean. Note that you can
+ * overwrite it when the given ObjectName is null otherwise the
+ * change is discarded (maybe a bug in JMX-RI).
+ **/
public ObjectName preRegister(MBeanServer server, ObjectName name)
throws Exception
{
- name = getObjectName(server, name);
+ ObjectName lName = getObjectName(server, name);
+ if( name == null ) {
+ mServiceName = lName;
+ } else {
+ mServiceName = name;
+ }
this.server = server;
- return name;
+ return lName;
}
public void postRegister(Boolean registrationDone)
@@ -223,7 +254,6 @@
return name;
}
-
protected void startService()
throws Exception
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/server MBeanServerImpl.java
User: juhalindfors
Date: 01/12/02 18:20:55
Added: src/main/org/jboss/mx/server MBeanServerImpl.java
Log:
Revision ChangesPath
1.1 jmx/src/main/org/jboss/mx/server/MBeanServerImpl.java
Index: MBeanServerImpl.java
===
/*
* LGPL
*/
package org.jboss.mx.server;
import javax.management.InstanceNotFoundException;
import javax.management.ReflectionException;
import javax.management.MBeanException;
import javax.management.ObjectName;
import javax.management.ObjectInstance;
import javax.management.Attribute;
import javax.management.AttributeList;
import javax.management.MBeanServer;
import javax.management.NotificationListener;
import javax.management.NotificationFilter;
import javax.management.InstanceAlreadyExistsException;
import javax.management.NotCompliantMBeanException;
import javax.management.MBeanRegistrationException;
import javax.management.OperationsException;
import javax.management.IntrospectionException;
import javax.management.AttributeNotFoundException;
import javax.management.InvalidAttributeValueException;
import javax.management.ListenerNotFoundException;
import javax.management.RuntimeErrorException;
import javax.management.QueryExp;
import javax.management.MBeanInfo;
import javax.management.DynamicMBean;
import javax.management.loading.DefaultLoaderRepository;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import java.io.ObjectInputStream;
import org.jboss.mx.server.registry.BasicMBeanRegistry;
import org.jboss.mx.server.registry.MBeanRegistry;
import org.jboss.mx.server.registry.MBeanEntry;
public class MBeanServerImpl implements MBeanServer {
protected String defaultDomain = "DefaultDomain";
protected MBeanRegistry registry= null;
public MBeanServerImpl(String defaultDomain) {
this.defaultDomain = defaultDomain;
this.registry = new BasicMBeanRegistry();
}
public Object instantiate(String className) throws ReflectionException,
MBeanException {
try {
Class clazz = DefaultLoaderRepository.loadClass(className);
return clazz.newInstance();
}
catch (ClassNotFoundException e) {
throw new ReflectionException(e, "Class not found: " + className);
}
catch (InstantiationException e) {
throw new ReflectionException(e, "Cannot instantiate with no-args
constructor: " + className);
}
catch (IllegalAccessException e) {
throw new ReflectionException(e, "Illegal access to default constructor: "
+ className);
}
}
public Object instantiate(String className, ObjectName loaderName)
throws ReflectionException, MBeanException, InstanceNotFoundException {
return null;
}
public Object instantiate(String className, Object[] params, String[] signature)
throws ReflectionException, MBeanException {
try {
Class clazz = DefaultLoaderRepository.loadClass(className);
Class[] sign = new Class[signature.length];
for (int i = 0; i < signature.length; ++i) {
try {
sign[i] = DefaultLoaderRepository.loadClass(signature[i]);
}
catch (ClassNotFoundException e) {
throw new ReflectionException(e, "Constructor parameter class not
found: " + signature[i]);
}
}
Constructor constructor = clazz.getConstructor(sign);
return constructor.newInstance(params);
}
catch (ClassNotFoundException e) {
throw new ReflectionException(e, "Class not found: " + className);
}
catch (InstantiationException e) {
throw new ReflectionException(e, "Cannot instantiate with specified
constructor: " + className);
}
catch (IllegalAccessException e) {
throw new ReflectionException(e, "Illegal access to specified constructor:
" + className);
}
catch (NoSuchMethodException e) {
throw new ReflectionException(e, "Specified constructor not found for class
" + className);
}
catch (InvocationTargetException e) {
Throwable t = e.getTargetException();
if (t instanceof Exception)
throw new MBeanException((Exception)t, "Constructor has thrown an
exception: " + t.getMessage());
else
throw new RuntimeErrorException((Error)t, "Error thrown from the
specified constructor: " + t.getMessage());
}
}
public java.lang.Object instantiate(String className, ObjectName loaderName,
Object[] params, String[] signature)
throws ReflectionException, MBeanException, InstanceNotFoundException {
return null;
}
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/server/registry - New directory
User: juhalindfors Date: 01/12/02 18:17:26 jmx/src/main/org/jboss/mx/server/registry - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/server/registry BasicMBeanRegistry.java MBeanEntry.java MBeanRegistry.java
User: juhalindfors
Date: 01/12/02 18:18:43
Added: src/main/org/jboss/mx/server/registry
BasicMBeanRegistry.java MBeanEntry.java
MBeanRegistry.java
Log:
you want them fast
Revision ChangesPath
1.1
jmx/src/main/org/jboss/mx/server/registry/BasicMBeanRegistry.java
Index: BasicMBeanRegistry.java
===
/*
* LGPL
*/
package org.jboss.mx.server.registry;
import java.util.Map;
import java.util.HashMap;
import javax.management.InstanceNotFoundException;
import javax.management.ObjectName;
public class BasicMBeanRegistry implements MBeanRegistry {
private HashMap mbeanMap = new HashMap();
public void add(MBeanEntry e) {
mbeanMap.put(e.getObjectName(), e);
}
public void remove(ObjectName name) throws InstanceNotFoundException {
Object o = mbeanMap.remove(name);
if (o == null)
throw new InstanceNotFoundException(name + " not registered.");
}
public MBeanEntry get(ObjectName name) throws InstanceNotFoundException {
MBeanEntry entry = (MBeanEntry)mbeanMap.get(name);
if (entry == null)
throw new InstanceNotFoundException(name + " not registered.");
return entry;
}
public boolean contains(ObjectName name) {
return mbeanMap.containsKey(name);
}
public int getSize() {
return mbeanMap.size();
}
}
1.1 jmx/src/main/org/jboss/mx/server/registry/MBeanEntry.java
Index: MBeanEntry.java
===
/*
* LGPL
*/
package org.jboss.mx.server.registry;
import javax.management.DynamicMBean;
import javax.management.ObjectName;
public class MBeanEntry {
private ObjectName objectName = null;
private Object objectReference = null;
private DynamicMBean invocationInterface = null;
private String className = null;
public MBeanEntry(ObjectName objectName, Object objectReference) {
this.objectName = objectName;
this.objectReference = objectReference;
this.invocationInterface = (DynamicMBean)objectReference;
this.className = objectName.getClass().getName();
}
public ObjectName getObjectName() {
return objectName;
}
public DynamicMBean getInvocationInterface() {
return invocationInterface;
}
public String getClassName() {
return className;
}
public Object getInstance() {
return objectReference;
}
}
1.1 jmx/src/main/org/jboss/mx/server/registry/MBeanRegistry.java
Index: MBeanRegistry.java
===
/*
* LGPL
*/
package org.jboss.mx.server.registry;
import javax.management.ObjectName;
import javax.management.InstanceNotFoundException;
public interface MBeanRegistry {
void add(MBeanEntry e);
void remove(ObjectName name) throws InstanceNotFoundException;
MBeanEntry get(ObjectName name) throws InstanceNotFoundException;
boolean contains(ObjectName name);
int getSize();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/server - New directory
User: juhalindfors Date: 01/12/02 18:14:04 jmx/src/main/org/jboss/mx/server - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Support for mbean arbitrary config info
In 2.4.4 I added support for a mbean/config child element that allowed one to pass arbitrary heiarchical configuration information to the mbean after its attributes had been set if the mbean implemented an importXml(Element) operation. This is used in the catalina mbean to support arbitrary connector configuration fragments from the no longer used catalina server.xml file, and an example is below. Is add the same capability to the org.jboss.system.ServiceConfigurator inconsistent with the persistent mbean discussions? Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/loading BasicLoaderRepository.java LoaderRepository.java
User: juhalindfors
Date: 01/12/02 18:13:31
Added: src/main/org/jboss/mx/loading BasicLoaderRepository.java
LoaderRepository.java
Log:
build fancy loaders here
Revision ChangesPath
1.1 jmx/src/main/org/jboss/mx/loading/BasicLoaderRepository.java
Index: BasicLoaderRepository.java
===
/*
* LGPL
*/
package org.jboss.mx.loading;
import java.util.Set;
import java.util.Iterator;
import java.util.HashSet;
public class BasicLoaderRepository implements LoaderRepository {
private static LoaderRepository instance = null;
public synchronized static LoaderRepository getInstance() {
if (instance != null)
return instance;
else {
instance = new BasicLoaderRepository();
return instance;
}
}
protected Set loaders = new HashSet();
private BasicLoaderRepository() {
}
public Class loadClass(String className) throws ClassNotFoundException {
return loadClassWithout(null, className);
}
public Class loadClassWithout(ClassLoader skipLoader, String className) throws
ClassNotFoundException {
Class clazz = null;
// try ctx cl first
ClassLoader ctxLoader = Thread.currentThread().getContextClassLoader();
if (ctxLoader != skipLoader) {
try {
clazz = ctxLoader.loadClass(className);
}
catch (ClassNotFoundException e) {
// ignore and move on to the loader list
}
}
if (clazz != null)
return clazz;
Iterator it = loaders.iterator();
while (it.hasNext()) {
ClassLoader cl = (ClassLoader)it.next();
if (cl != skipLoader) {
try {
clazz = cl.loadClass(className);
}
catch (ClassNotFoundException ignored) {
// go on and try the next loader
}
}
}
if (clazz == null)
throw new ClassNotFoundException(className);
return clazz;
}
public void addClassLoader(ClassLoader cl) {
loaders.add(cl);
}
public void removeClassLoader(ClassLoader cl) {
loaders.remove(cl);
}
}
1.1 jmx/src/main/org/jboss/mx/loading/LoaderRepository.java
Index: LoaderRepository.java
===
/*
* LGPL
*/
package org.jboss.mx.loading;
public interface LoaderRepository {
public Class loadClass(String className) throws ClassNotFoundException;
public Class loadClassWithout(ClassLoader loader, String className) throws
ClassNotFoundException;
public void addClassLoader(ClassLoader cl);
public void removeClassLoader(ClassLoader cl);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/loading - New directory
User: juhalindfors Date: 01/12/02 18:11:52 jmx/src/main/org/jboss/mx/loading - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss - New directory
User: juhalindfors Date: 01/12/02 18:10:13 jmx/src/main/org/jboss - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx - New directory
User: juhalindfors Date: 01/12/02 18:10:29 jmx/src/main/org/jboss/mx - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org - New directory
User: juhalindfors Date: 01/12/02 18:09:49 jmx/src/main/org - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/javax/management MBeanServerFactory.java Notification.java ObjectInstance.java
User: juhalindfors
Date: 01/12/02 18:08:47
Added: src/main/javax/management MBeanServerFactory.java
Notification.java ObjectInstance.java
Log:
leftovers
Revision ChangesPath
1.1 jmx/src/main/javax/management/MBeanServerFactory.java
Index: MBeanServerFactory.java
===
/*
* LGPL
*/
package javax.management;
import java.util.Map;
import java.util.List;
import java.util.HashMap;
import java.util.ArrayList;
public class MBeanServerFactory extends java.lang.Object {
private static Map serverMap = new HashMap();
public static void releaseMBeanServer(MBeanServer mbeanServer) {
throw new Error("NYI");
}
public static MBeanServer createMBeanServer() {
return createMBeanServer("DefaultDomain");
}
public static MBeanServer createMBeanServer(String domain) {
MBeanServer server = new org.jboss.mx.server.MBeanServerImpl(domain);
serverMap.put(createAgentID(), server);
return server;
}
public static MBeanServer newMBeanServer() {
return new org.jboss.mx.server.MBeanServerImpl("DefaultDomain");
}
public static MBeanServer newMBeanServer(String domain) {
return new org.jboss.mx.server.MBeanServerImpl(domain);
}
public static java.util.ArrayList findMBeanServer(String AgentId) {
if (AgentId != null) {
ArrayList list = new ArrayList(1);
list.add(serverMap.get(AgentId));
return list;
}
return new ArrayList(serverMap.values());
}
private static String createAgentID() { return "BOOM!"; }
}
1.1 jmx/src/main/javax/management/Notification.java
Index: Notification.java
===
/*
* LGPL
*/
package javax.management;
public class Notification extends java.util.EventObject {
private String type = null;
private long sequenceNumber = 0;
private String message = null;
private long timeStamp = System.currentTimeMillis();
private Object userData = null;
public Notification(java.lang.String type,
java.lang.Object source,
long sequenceNumber) {
super(source);
this.type = type;
this.sequenceNumber = sequenceNumber;
this.timeStamp = System.currentTimeMillis();
}
public Notification(java.lang.String type,
java.lang.Object source,
long sequenceNumber,
java.lang.String message) {
this(type, source, sequenceNumber);
this.message = message;
this.timeStamp = System.currentTimeMillis();
}
public Notification(java.lang.String type,
java.lang.Object source,
long sequenceNumber,
long timeStamp) {
this(type, source, sequenceNumber);
this.timeStamp = timeStamp;
}
public Notification(java.lang.String type,
java.lang.Object source,
long sequenceNumber,
long timeStamp,
java.lang.String message)
{
this(type, source, sequenceNumber, timeStamp);
this.message = message;
}
public java.lang.Object getSource() {
return super.source;
}
public void setSource(Object source) throws IllegalArgumentException {
if (source instanceof String) {
try {
super.source = new ObjectName((String)source);
}
catch (MalformedObjectNameException e) {
throw new IllegalArgumentException("malformed object name: " + source);
}
}
else if (source instanceof ObjectName) {
super.source = source;
}
else throw new IllegalArgumentException("Notification source must be an object
name");
}
public long getSequenceNumber() {
return sequenceNumber;
}
public void setSequenceNumber(long sequenceNumber) {
this.sequenceNumber = sequenceNumber;
}
public java.lang.String getType() {
return type;
}
public long getTimeStamp() {
return timeStamp;
}
public void setTimeStamp(long timeStamp) {
this.timeStamp = timeStamp;
}
public java.lang.String getMessage() {
return message;
}
public java.lang.Object getUserData() {
return userData;
}
public void setUserData(java.lang.Object userData) {
this.userData = userData;
}
}
1.1 jmx/src/main/javax/management/ObjectInstance.
[JBoss-dev] CVS update: jmx/src/main/javax/management/loading DefaultLoaderRepository.java MLet.java MLetMBean.java
User: juhalindfors
Date: 01/12/02 18:08:48
Added: src/main/javax/management/loading
DefaultLoaderRepository.java MLet.java
MLetMBean.java
Log:
leftovers
Revision ChangesPath
1.1
jmx/src/main/javax/management/loading/DefaultLoaderRepository.java
Index: DefaultLoaderRepository.java
===
/*
* LGPL
*/
package javax.management.loading;
import java.util.Vector;
import org.jboss.mx.loading.LoaderRepository;
import org.jboss.mx.loading.BasicLoaderRepository;
public class DefaultLoaderRepository extends java.lang.Object implements
java.io.Serializable {
protected static java.util.Vector loaders = new Vector();
private static LoaderRepository repository = BasicLoaderRepository.getInstance();
public DefaultLoaderRepository() {
}
public static Class loadClass(String className) throws ClassNotFoundException {
return repository.loadClass(className);
}
public static Class loadClassWithout(ClassLoader loader, String className) throws
ClassNotFoundException {
return repository.loadClassWithout(loader, className);
}
}
1.1 jmx/src/main/javax/management/loading/MLet.java
Index: MLet.java
===
/*
* LGPL
*/
package javax.management.loading;
import javax.management.ObjectName;
import javax.management.MBeanServer;
import javax.management.MBeanRegistration;
import javax.management.ServiceNotFoundException;
import java.net.URL;
import java.net.URLStreamHandlerFactory;
import java.net.URLClassLoader;
import java.net.MalformedURLException;
import java.io.InputStream;
public class MLet extends URLClassLoader implements MLetMBean, MBeanRegistration {
public MLet() {
super(null);
}
public MLet(URL[] urls) {
super(urls);
}
public MLet(URL[] urls, ClassLoader parent) {
super(urls, parent);
}
public MLet(URL[] urls, ClassLoader parent, URLStreamHandlerFactory factory) {
super(urls, parent, factory);
}
public ObjectName preRegister(MBeanServer server, ObjectName name) throws
Exception {
if (name == null)
return new ObjectName(":type=MLet");
return name;
}
public void postRegister(java.lang.Boolean registrationDone) {}
public void preDeregister() throws java.lang.Exception {}
public void postDeregister() {}
public java.util.Set getMBeansFromURL(String url) throws ServiceNotFoundException
{
return null;
}
public java.util.Set getMBeansFromURL(URL url) throws ServiceNotFoundException {
return null;
}
public void addURL(URL url) {
super.addURL(url);
}
public void addURL(String url) throws ServiceNotFoundException {
try {
super.addURL(new URL(url));
} catch (MalformedURLException e) {
throw new ServiceNotFoundException("Malformed URL: " + url);
}
}
public URL[] getURLs() {
return super.getURLs();
}
public URL getResource(String name) {
return super.getResource(name);
}
public InputStream getResourceAsStream(String name) {
return super.getResourceAsStream(name);
}
public String getLibraryDirectory() {
throw new Error("NYI");
}
public void setLibraryDirectory(String libdir) {
throw new Error("NYI");
}
}
1.1 jmx/src/main/javax/management/loading/MLetMBean.java
Index: MLetMBean.java
===
/*
* LGPL
*/
package javax.management.loading;
import javax.management.ServiceNotFoundException;
public interface MLetMBean {
public java.util.Set getMBeansFromURL(java.lang.String url) throws
ServiceNotFoundException;
public java.util.Set getMBeansFromURL(java.net.URL url) throws
ServiceNotFoundException;
public void addURL(java.net.URL url);
public void addURL(java.lang.String url) throws ServiceNotFoundException;
public java.net.URL[] getURLs();
public java.net.URL getResource(java.lang.String name);
public java.io.InputStream getResourceAsStream(java.lang.String name);
public java.util.Enumeration getResources(java.lang.String name) throws
java.io.IOException;
public java.lang.String getLibraryDirectory();
public void setLibraryDirectory(java.lang.String libdir);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/lis
[JBoss-dev] CVS update: jmx/src/main/javax/management/loading - New directory
User: juhalindfors Date: 01/12/02 18:02:11 jmx/src/main/javax/management/loading - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/javax/management Attribute.java AttributeList.java DescriptorAccess.java MBeanAttributeInfo.java MBeanConstructorInfo.java MBeanFeatureInfo.java MBeanInfo.java MBeanNotificationInfo.java MBeanOperationInfo.java MBeanParameterInfo.java ObjectName.java
User: juhalindfors
Date: 01/12/02 18:01:30
Added: src/main/javax/management Attribute.java AttributeList.java
DescriptorAccess.java MBeanAttributeInfo.java
MBeanConstructorInfo.java MBeanFeatureInfo.java
MBeanInfo.java MBeanNotificationInfo.java
MBeanOperationInfo.java MBeanParameterInfo.java
ObjectName.java
Log:
metadata classes
Revision ChangesPath
1.1 jmx/src/main/javax/management/Attribute.java
Index: Attribute.java
===
/*
* LGPL
*/
package javax.management;
public class Attribute extends Object implements java.io.Serializable {
private String name = null;
private Object value = null;
public Attribute(String name, Object value) {
this.name = name;
this.value = value;
}
public java.lang.String getName() {
return name;
}
public java.lang.Object getValue() {
return value;
}
public boolean equals(java.lang.Object object) {
if (!(object instanceof Attribute))
return false;
Attribute attr = (Attribute)object;
return (name.equals(attr.getName()) && value.equals(attr.getValue()));
}
}
1.1 jmx/src/main/javax/management/AttributeList.java
Index: AttributeList.java
===
/*
* LGPL
*/
package javax.management;
public class AttributeList
extends java.util.ArrayList {
public AttributeList() {
super();
}
public AttributeList(int initialCapacity) {
super(initialCapacity);
}
public AttributeList(AttributeList list) {
super(list);
}
public void add(Attribute object) {
super.add(object);
}
public void add(int index, Attribute object) {
super.add(index, object);
}
public void set(int index, Attribute object) {
super.set(index, object);
}
public boolean addAll(AttributeList list) {
return super.addAll(list);
}
public boolean addAll(int index, AttributeList list) {
return super.addAll(index, list);
}
}
1.1 jmx/src/main/javax/management/DescriptorAccess.java
Index: DescriptorAccess.java
===
/*
* LGPL
*/
package javax.management;
public interface DescriptorAccess {
public Descriptor getDescriptor();
public void setDescriptor(Descriptor inDescriptor);
}
1.1 jmx/src/main/javax/management/MBeanAttributeInfo.java
Index: MBeanAttributeInfo.java
===
/*
* LGPL
*/
package javax.management;
public class MBeanAttributeInfo
extends MBeanFeatureInfo
implements java.io.Serializable, java.lang.Cloneable {
protected String type = null;
protected boolean isReadable = false;
protected boolean isWritable = false;
protected boolean isIs = false;
public MBeanAttributeInfo(java.lang.String name,
java.lang.String type,
java.lang.String description,
boolean isReadable,
boolean isWritable,
boolean isIs) {
super(name, description);
this.type = type;
this.isReadable = isReadable;
this.isWritable = isWritable;
this.isIs = isIs;
}
public MBeanAttributeInfo(java.lang.String name,
java.lang.String description,
java.lang.reflect.Method getter,
java.lang.reflect.Method setter)
throws IntrospectionException {
super(name, description);
throw new Error("NYI");
}
public java.lang.Object clone() throws CloneNotSupportedException {
MBeanAttributeInfo clone = (MBeanAttributeInfo)super.clone();
clone.type = getType();
clone.isReadable = isReadable();
clone.isWritable = isWritable();
clone.isIs = isIs();
return clone;
}
public java.lang.String getType() {
return type;
}
public boolean isReadable() {
return isReadable;
}
public boolean isWritable() {
return isWritable;
}
public boolean isIs() {
return isIs;
}
}
1.1 jmx/src/main/javax/management/MBeanConstructorInfo.java
Index: MBeanConstructorInfo.java
==
[JBoss-dev] CVS update: jboss build.xml
User: starksm Date: 01/12/02 17:43:40 Modified:.Tag: Branch_2_4 build.xml Log: Clean up the build further Revision ChangesPath No revision No revision 1.33.2.4 +65 -16jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/build.xml,v retrieving revision 1.33.2.3 retrieving revision 1.33.2.4 diff -u -r1.33.2.3 -r1.33.2.4 --- build.xml 2001/11/28 21:14:01 1.33.2.3 +++ build.xml 2001/12/03 01:43:39 1.33.2.4 @@ -11,8 +11,8 @@ your system/environment. This can be done by editing this file, or creating an .ant.properties file in the directory from step 1. a. version-tag: set this to the cvs tag you want to build. For example, -to build the JBoss_2_4_2 version use: - version-tag="JBoss_2_4_2" +to build the JBoss_2_4_4 version use: + version-tag="JBoss_2_4_4" To build the latest 2.4 branch chode use: version-tag="Branch_2_4" b. tomcat3x: set to the absolute path of the jakarta-tomcat-3.2.3 distribution @@ -20,7 +20,7 @@ c. tomcat4x: set to the absolute path of the jakarta-tomcat-4.0 distribution This is required to build the contrib/catalina bundle -3. Execute the dist target by running Ant1.3 in the directory created +3. Execute the dist target by running Ant1.4.1 in the directory created in step 1. This will create a jboss/dist directory with the JBoss server version and contrib/tomcat/bundle/JBoss_x_Tomcat-3.x directory with the JBoss/Tomcat bundle, and a contrib/catalina/bundle/JBoss_x_Tomcat-4.x @@ -36,9 +36,9 @@ - + - + @@ -137,21 +137,70 @@ - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - + + + + + + + + + + + + - + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] setEntityContext called at pool push time (because of reclaim usage in EntityInstancePool)
My last post is wrong, it is in fact a lot more simple: JBOSS 2.4.4 almost latest CVS Entity instances are created by the pool on the get() method The creation is followed by setEntityContext The problem is that the free() method is never called on EntityInstancePool (except by the passivation method). So an entity bean is never push to the pool. So the pool is always empty for entity beans. So on my next call, the instanciation/setEntityContext happens again. That's why I see a lot of setEntityContext() happening and this why I see this this as a performance killer because I do a lot of jndi lookup there. Is this a normal behaviour or does it hide something ? Regards. Vincent. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/main/org/jboss/tomcat/security HypothermicRealm.java
User: starksm Date: 01/12/02 17:45:39 Removed: tomcat/src/main/org/jboss/tomcat/security Tag: Branch_2_4 HypothermicRealm.java Log: Remove obsolete HypothermicRealm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/javax/management Descriptor.java DynamicMBean.java MBeanException.java MBeanRegistration.java MBeanServer.java MBeanServerDelegateMBean.java NotificationBroadcaster.java NotificationFilter.java NotificationListener.java PersistentMBean.java QueryExp.java ValueExp.java
User: juhalindfors
Date: 01/12/02 17:42:59
Added: src/main/javax/management Descriptor.java DynamicMBean.java
MBeanException.java MBeanRegistration.java
MBeanServer.java MBeanServerDelegateMBean.java
NotificationBroadcaster.java
NotificationFilter.java NotificationListener.java
PersistentMBean.java QueryExp.java ValueExp.java
Log:
javax.management interfaces
Revision ChangesPath
1.1 jmx/src/main/javax/management/Descriptor.java
Index: Descriptor.java
===
/*
* LGPL
*/
package javax.management;
public interface Descriptor extends java.io.Serializable {
public java.lang.Object getFieldValue(java.lang.String fieldName)
throws RuntimeOperationsException;
public void setField(java.lang.String fieldName,
java.lang.Object fieldValue)
throws RuntimeOperationsException;
public java.lang.String[] getFields();
public java.lang.String[] getFieldNames();
public java.lang.Object[] getFieldValues(java.lang.String[] fieldNames);
public void removeField(java.lang.String fieldName);
public void setFields(java.lang.String[] fieldNames,
java.lang.Object[] fieldValues)
throws RuntimeOperationsException;
public java.lang.Object clone()
throws RuntimeOperationsException;
}
1.1 jmx/src/main/javax/management/DynamicMBean.java
Index: DynamicMBean.java
===
/*
* LGPL
*/
package javax.management;
public interface DynamicMBean {
public java.lang.Object getAttribute(java.lang.String attribute)
throws AttributeNotFoundException,
MBeanException,
ReflectionException;
public void setAttribute(Attribute attribute)
throws AttributeNotFoundException,
InvalidAttributeValueException,
MBeanException,
ReflectionException;
public AttributeList getAttributes(java.lang.String[] attributes);
public AttributeList setAttributes(AttributeList attributes);
public java.lang.Object invoke(java.lang.String actionName,
java.lang.Object[] params,
java.lang.String[] signature)
throws MBeanException,
ReflectionException;
public MBeanInfo getMBeanInfo();
}
1.1 jmx/src/main/javax/management/MBeanException.java
Index: MBeanException.java
===
/*
* LGPL
*/
package javax.management;
public class MBeanException
extends JMException {
private Exception e = null;
public MBeanException(java.lang.Exception e) {
super();
this.e = e;
}
public MBeanException(java.lang.Exception e,
java.lang.String message) {
super(message);
this.e = e;
}
public java.lang.Exception getTargetException() {
return e;
}
}
1.1 jmx/src/main/javax/management/MBeanRegistration.java
Index: MBeanRegistration.java
===
/*
* LGPL
*/
package javax.management;
public interface MBeanRegistration {
public ObjectName preRegister(MBeanServer server,
ObjectName name)
throws java.lang.Exception;
public void postRegister(java.lang.Boolean registrationDone);
public void preDeregister()
throws java.lang.Exception;
public void postDeregister();
}
1.1 jmx/src/main/javax/management/MBeanServer.java
Index: MBeanServer.java
===
/*
* LGPL
*/
package javax.management;
public interface MBeanServer {
public java.lang.Object instantiate(java.lang.String className)
throws ReflectionException,
MBeanException;
public java.lang.Object instantiate(java.lang.String className,
ObjectName loaderName)
throws ReflectionException,
MBeanException,
InstanceNotFoundException;
public java.lang.Object instantiate(java.lang.String className,
java.lang.Object[] params,
java.lang.String[] signature)
throws ReflectionException,
MBeanException;
public java.lang.Object instantiate(String className,
ObjectName lo
[JBoss-dev] CVS update: contrib/tomcat/src/build build.xml
User: starksm Date: 01/12/02 17:39:21 Modified:tomcat/src/build Tag: Branch_2_4 build.xml Log: Change release to version Revision ChangesPath No revision No revision 1.15.2.10 +4 -4 contrib/tomcat/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/tomcat/src/build/build.xml,v retrieving revision 1.15.2.9 retrieving revision 1.15.2.10 diff -u -r1.15.2.9 -r1.15.2.10 --- build.xml 2001/11/28 06:30:02 1.15.2.9 +++ build.xml 2001/12/03 01:39:21 1.15.2.10 @@ -1,5 +1,5 @@ - +
[JBoss-dev] CVS update: jmx/src/main/javax/management AttributeNotFoundException.java BadAttributeValueExpException.java BadBinaryOpValueExpException.java BadStringOperationException.java InstanceAlreadyExistsException.java InstanceNotFoundException.java IntrospectionException.java InvalidApplicationException.java InvalidAttributeValueException.java JMException.java JMRuntimeException.java ListenerNotFoundException.java MBeanRegistrationException.java MalformedObjectNameException.java NotCompliantMBeanException.java OperationsException.java ReflectionException.java RuntimeErrorException.java RuntimeMBeanException.java RuntimeOperationsException.java ServiceNotFoundException.java
User: juhalindfors
Date: 01/12/02 17:39:08
Added: src/main/javax/management AttributeNotFoundException.java
BadAttributeValueExpException.java
BadBinaryOpValueExpException.java
BadStringOperationException.java
InstanceAlreadyExistsException.java
InstanceNotFoundException.java
IntrospectionException.java
InvalidApplicationException.java
InvalidAttributeValueException.java
JMException.java JMRuntimeException.java
ListenerNotFoundException.java
MBeanRegistrationException.java
MalformedObjectNameException.java
NotCompliantMBeanException.java
OperationsException.java ReflectionException.java
RuntimeErrorException.java
RuntimeMBeanException.java
RuntimeOperationsException.java
ServiceNotFoundException.java
Log:
javax.management exceptions
Revision ChangesPath
1.1 jmx/src/main/javax/management/AttributeNotFoundException.java
Index: AttributeNotFoundException.java
===
/*
* LGPL
*/
package javax.management;
public class AttributeNotFoundException extends OperationsException {
public AttributeNotFoundException() {
super();
}
public AttributeNotFoundException(java.lang.String message) {
super(message);
}
}
1.1 jmx/src/main/javax/management/BadAttributeValueExpException.java
Index: BadAttributeValueExpException.java
===
/*
* LGPL
*/
package javax.management;
public class BadAttributeValueExpException extends Exception {
private Object val = null;
public BadAttributeValueExpException(java.lang.Object val) {
super();
this.val = val;
}
public java.lang.String toString() {
return super.toString();
}
}
1.1 jmx/src/main/javax/management/BadBinaryOpValueExpException.java
Index: BadBinaryOpValueExpException.java
===
/*
* LGPL
*/
package javax.management;
public class BadBinaryOpValueExpException extends Exception {
private ValueExp exp = null;
public BadBinaryOpValueExpException(ValueExp exp) {
super();
this.exp = exp;
}
public ValueExp getExp() {
return exp;
}
public java.lang.String toString() {
return super.toString();
}
}
1.1 jmx/src/main/javax/management/BadStringOperationException.java
Index: BadStringOperationException.java
===
/*
* LGPL
*/
package javax.management;
public class BadStringOperationException extends Exception {
public BadStringOperationException(java.lang.String op) {
super(op);
}
public java.lang.String toString() {
return super.toString();
}
}
1.1
jmx/src/main/javax/management/InstanceAlreadyExistsException.java
Index: InstanceAlreadyExistsException.java
===
/*
* LGPL
*/
package javax.management;
public class InstanceAlreadyExistsException
extends OperationsException {
public InstanceAlreadyExistsException() {
super();
}
public InstanceAlreadyExistsException(java.lang.String message) {
super(message);
}
}
1.1 jmx/src/main/javax/management/InstanceNotFoundException.java
Index: InstanceNotFoundException.java
===
/*
* LGPL
*/
package javax.management;
public class InstanceNotFoundException
extends OperationsException {
public InstanceNotFoundException() {
super();
}
public InstanceNotFoundException(java.lang.String message) {
super(message);
}
}
1.1 jmx/src/main/javax/management/IntrospectionException.java
Index: IntrospectionException.java
===
/*
* LGPL
*/
package javax.management;
public class IntrospectionException
extends OperationsException
{
public IntrospectionException() {
super();
}
public IntrospectionException(java.lang.String message) {
supe
[JBoss-dev] CVS update: jmx/src/main/javax - New directory
User: juhalindfors Date: 01/12/02 17:37:20 jmx/src/main/javax - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/javax/management - New directory
User: juhalindfors Date: 01/12/02 17:37:45 jmx/src/main/javax/management - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src - New directory
User: juhalindfors Date: 01/12/02 17:36:31 jmx/src - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main - New directory
User: juhalindfors Date: 01/12/02 17:36:54 jmx/src/main - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Will grand unification of CL solve this?
yes marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Anatoly Akkerman |Sent: Sunday, December 02, 2001 6:10 PM |To: JBoss-Dev |Subject: [JBoss-dev] Will grand unification of CL solve this? | | |Hi, | |I've been seeing the following problem and have been wondering how to |solve it or whether the grand unification will solve it. | |I am writing an EJB application that processes XML descriptors using |Castor. Now, Castor is loaded by the SL and is available to the |application but when an EJB invokes Castor, it has to be able to |instantiate certain classes from the application. It seems in 3.0alpha |this is not possible. The only way I can get rid of this problem is by |removing castor from lib/ext and deploying it as an application |library. This is, obviously not a good solution. | |In general, is there a way to deal with such issues? | |- |Anatoly Akkerman |Computer Science Dept. |Courant Institute of Mathematical Sciences, NYU |715 Broadway, #719 Tel: 212 998-3493 |New York, NY 10003 Fax: 212 995-4123 |- | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
I'm still not happy about this - there is still something broken in my build. If you guys can survive another 24 hours, i shall try to sort it out tomorrow. Apologies to anyone I am holding up - I know how frustrating it can be. Jules Julian Gosnell wrote: > Sorry guys, > > Somehow the code that sets up the ENC stuff move places during a reshuffle. > > I've put it back now. Please let me know if you still have problems. > > Apologies for taking so long to sort this out - i haven't been at my machine > for a couple of days. > > Jules > > P.S. > > Thanks also to those concerned for the fixURL() 'fix' - I should have called > mine ' breakURL' ! > > 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. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > - Original Message - > > From: "Peter Levart" <[EMAIL PROTECTED]> > > To: "Scott M Stark" <[EMAIL PROTECTED]>; "Scott M Stark" > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Friday, November 30, 2001 8:42 AM > > Subject: Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken > > > > > On Friday 30 November 2001 12:38, Scott M Stark wrote: > > > > I just looked at the latest build with the jbosstest.ear from the > > testsuite > > > > module > > > > and the DebugServlet http://localhost:8080/jbosstest/DebugServlet > > > > is displaying the full java:comp context correctly: > > > > > > > > > > I tried that too and it is displaying it correctly for me too. I don't > > know > > > why it is working for that particular test app and why not for my app. So > > I > > > did a fresh checkout of jboss-all and I created a minimal jbosstest.war > > > composed of only the: > > > > > > DebugServlet.java, Util.java & web.xml. > > > > > > Attached to the message you will find it. Not displaying java:comp. > > > > > > Please, can you try it? Am I missing something? Can you make it display > > the > > > java:comp/env/Strings/s1 ? > > > > > > > > > Peter > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken
Sorry guys, Somehow the code that sets up the ENC stuff move places during a reshuffle. I've put it back now. Please let me know if you still have problems. Apologies for taking so long to sort this out - i haven't been at my machine for a couple of days. Jules P.S. Thanks also to those concerned for the fixURL() 'fix' - I should have called mine ' breakURL' ! 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. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Peter Levart" <[EMAIL PROTECTED]> > To: "Scott M Stark" <[EMAIL PROTECTED]>; "Scott M Stark" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Friday, November 30, 2001 8:42 AM > Subject: Re: [JBoss-dev] JNDI view of java:comp context from Jetty broken > > > On Friday 30 November 2001 12:38, Scott M Stark wrote: > > > I just looked at the latest build with the jbosstest.ear from the > testsuite > > > module > > > and the DebugServlet http://localhost:8080/jbosstest/DebugServlet > > > is displaying the full java:comp context correctly: > > > > > > > I tried that too and it is displaying it correctly for me too. I don't > know > > why it is working for that particular test app and why not for my app. So > I > > did a fresh checkout of jboss-all and I created a minimal jbosstest.war > > composed of only the: > > > > DebugServlet.java, Util.java & web.xml. > > > > Attached to the message you will find it. Not displaying java:comp. > > > > Please, can you try it? Am I missing something? Can you make it display > the > > java:comp/env/Strings/s1 ? > > > > > > Peter > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JBossWebApplicationContext.java Jetty.java
User: jules_gosnell
Date: 01/12/02 16:28:45
Modified:jetty/src/main/org/jboss/jetty
JBossWebApplicationContext.java Jetty.java
Log:
ensure ENC is built properly...
Revision ChangesPath
1.5 +4 -4
contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java
Index: JBossWebApplicationContext.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JBossWebApplicationContext.java 2001/11/28 01:22:25 1.4
+++ JBossWebApplicationContext.java 2001/12/03 00:28:45 1.5
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossWebApplicationContext.java,v 1.4 2001/11/28 01:22:25 jules_gosnell Exp
$
+// $Id: JBossWebApplicationContext.java,v 1.5 2001/12/03 00:28:45 jules_gosnell Exp
$
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -117,9 +117,9 @@
}
// Parse descriptors and set up the JNDI environment
- Element webAppDD = _webApp.getWebApp();
- Element jbossDD = _webApp.getJbossWeb();
- _descriptorParser.parseWebAppDescriptors(loader, webAppDD, jbossDD);
+ // Element webAppDD = _webApp.getWebApp();
+ // Element jbossDD = _webApp.getJbossWeb();
+ // _descriptorParser.parseWebAppDescriptors(loader, webAppDD, jbossDD);
// Add the JBoss security realm
String realmName = getRealm();
1.26 +6 -4 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.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- Jetty.java2001/12/01 21:29:44 1.25
+++ Jetty.java2001/12/03 00:28:45 1.26
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: Jetty.java,v 1.25 2001/12/01 21:29:44 schaefera Exp $
+// $Id: Jetty.java,v 1.26 2001/12/03 00:28:45 jules_gosnell Exp $
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -27,12 +27,12 @@
import org.mortbay.util.Resource;
/**
- *
+ *
*
* @author mailto:[EMAIL PROTECTED]";>Julian Gosnell
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
- * @version $Revision: 1.25 $
- *
+ * @version $Revision: 1.26 $
+ *
* Revisions:
*
* 20011201 andreas:
@@ -223,6 +223,8 @@
}
// finally start the app
+ _log.info("setting up ENC");
+ descriptorParser.parseWebAppDescriptors(wa.getClassLoader(), wa.getWebApp(),
wa.getJbossWeb());
app.start();
// keep track of deployed contexts for undeployment
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Will grand unification of CL solve this?
On 2001.12.02 18:10:08 -0500 Anatoly Akkerman wrote: > Hi, > > I've been seeing the following problem and have been wondering how to > solve it or whether the grand unification will solve it. > > I am writing an EJB application that processes XML descriptors using > Castor. Now, Castor is loaded by the SL and is available to the > application but when an EJB invokes Castor, it has to be able to > instantiate certain classes from the application. It seems in 3.0alpha > this is not possible. The only way I can get rid of this problem is by > removing castor from lib/ext and deploying it as an application > library. This is, obviously not a good solution. Why is this a bad solution? > > In general, is there a way to deal with such issues? Not that I know of, although there may well be. I was actually wondering if some of the "always there" parts of jboss should be put into a scope/classloader that is inaccessible from any application. I don't know of any such pieces, but I wondered... david jencks > > - > Anatoly Akkerman > Computer Science Dept. > Courant Institute of Mathematical Sciences, NYU > 715 Broadway, #719 Tel: 212 998-3493 > New York, NY 10003 Fax: 212 995-4123 > - > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx - Imported sources
User: juhalindfors Date: 01/12/02 15:57:04 Log: will this create a new module? (try #2) Status: Vendor Tag: JBG Release Tags: initial-import No conflicts created by this import ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NPE in $Proxy ???
I am having a very strange error. Perhaps, I have no clue of what I am doing but here it goes. Server: 3.0alpha I have a SFSB (appManager) that talks to SLSB (Registry) that updates CMP Entity (DescriptorCMP). in ejbRemove() of SFSB I call SLSB to update a particular Entity before this appManager is gone. The call to SLSB succeeds, entity is updated but on the return path of the invocation, the SLSB proxy throws a NPE. Here is the trace: 18:15:09,426 DEBUG [org.jboss.tm.TxCapsule] Committed OK, tx=XidImpl [FormatId=257, GlobalId=lib03//8, BranchQual=] 18:15:09,436 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//8, BranchQual=] 18:15:09,436 DEBUG [org.jboss.tm.TxCapsule] Reused instance for tx=XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,436 DEBUG [org.jboss.tm.TxManager] began tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,436 DEBUG [org.jboss.tm.TxCapsule] registerSynchronization(): Entered, tx=XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] status=STATUS_ACTIVE 18:15:09,436 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,436 DEBUG [org.jboss.tm.TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,586 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,586 DEBUG [org.jboss.tm.TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,586 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,586 DEBUG [org.jboss.tm.TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,586 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,586 DEBUG [org.jboss.tm.TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,586 DEBUG [org.jboss.tm.TxCapsule] registerSynchronization(): Entered, tx=XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] status=STATUS_ACTIVE 18:15:09,586 DEBUG [org.jboss.tm.TxCapsule] registerSynchronization(): Entered, tx=XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] status=STATUS_ACTIVE 18:15:09,586 DEBUG [org.jboss.tm.TxCapsule] registerSynchronization(): Entered, tx=XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] status=STATUS_ACTIVE 18:15:09,586 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,586 DEBUG [org.jboss.tm.TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,586 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,586 DEBUG [org.jboss.tm.TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,596 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,596 DEBUG [org.jboss.tm.TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,596 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,596 DEBUG [org.jboss.tm.TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,596 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,596 DEBUG [org.jboss.tm.TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,596 INFO [Default] Released lock for petstore, 18:15:09,596 INFO [Default] Released lock for application: petstore 18:15:09,596 DEBUG [org.jboss.tm.TxManager] suspended tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,596 DEBUG [org.jboss.tm.TxManager] resumed tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=lib03//9, BranchQual=] 18:15:09,596 ERROR [Default] java.lang.NullPointerException 18:15:09,596 ERROR [Default]at $Proxy8.releaseAppLock(Unknown Source) 18:15:09,596 ERROR [Default]at test.deployment.config.ejb.AppManagerBean.ejbRemove(Unknown Source) 18:15:09,596 ERROR [Default]at java.lang.reflect.Method.invoke(Native Method) 18:15:09,596 ERROR [Default]at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.removeSession(StatefulSessionFilePersistenceManager.java:309) 18:15:09,596 ERROR [Default]at org.jboss.ejb.StatefulSessionContainer.remove(StatefulSessionContainer.java:359) 18:15:09,596 ERROR [Default]at java.lang.reflect.Method.invoke(Native Method) 18:15:09,596 ERROR [Default]at org.jboss.ejb.StatefulSess
[JBoss-dev] Will grand unification of CL solve this?
Hi, I've been seeing the following problem and have been wondering how to solve it or whether the grand unification will solve it. I am writing an EJB application that processes XML descriptors using Castor. Now, Castor is loaded by the SL and is available to the application but when an EJB invokes Castor, it has to be able to instantiate certain classes from the application. It seems in 3.0alpha this is not possible. The only way I can get rid of this problem is by removing castor from lib/ext and deploying it as an application library. This is, obviously not a good solution. In general, is there a way to deal with such issues? - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-487071 ] Problem with JAAS authentication modules
Bugs item #487071, was opened at 2001-11-29 05:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=487071&group_id=22866 Category: JBossSX Group: v2.4 (stable) Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason Vasquez (jpvasquez) Assigned to: Scott M Stark (starksm) Summary: Problem with JAAS authentication modules Initial Comment: Environment: * Solaris 7 * Sun JDK 1.3.1 * JBoss 2.4.3/Jetty Bundle I have a custom JAAS authentication module, which is almost an exact duplicate of the LdapLoginModule that is delivered with JBoss 2.4.3. It has some changes to make it work with our environment here. The module works fine (binds to the directory with the user's credentials, and searches the roles to add to the JBoss environment. It adds these roles with an exact copy of the original, delivered module code: //roleName is a String containing the role name userRoles.addMember(new SimplePrincipal(roleName)); I know that the roles are getting added with some additional logging I've added around this code. When I log into the site via a browser (through Jetty), I am prompted for my username/password, but I receive an error about a ClassCastException. The JBoss console has much better details as to what has happened. I will paste that below. Any ideas as to what might be going on here? Thanks, Jason Console Output: [JaasSecurityManagerService] Created securityMgr=org.jboss.security.plugins.JaasSecurityMana ger@3b625b [JaasSecurityManagerService] setCachePolicy, c=null [JaasSecurityManagerService] Added MyLDAP, org.jboss.security.plugins.JaasSecurityManager@3b625b to map [Jetty] Security- User: rz95127 [Jetty] Security- created JBossUserRealm::User: rz95127 [Default] Logged into LDAP server, javax.naming.ldap.InitialLdapContext@2d26d2 [Default] - got a result - [Default] lis_admin [Default] User 'rz95127' authenticated. [Jetty] Security- User: rz95127 is authenticated [Jetty] WARNING: GET /cams/admin/ HTTP/1.1 java.lang.ClassCastException: java.lang.String at org.jboss.security.plugins.JaasSecurityManager.doesUser HaveRole(JaasSecurityManager.java:278) at org.jboss.jetty.JBossUserRealm$User.isUserInRole (JBossUserRealm.java:105) at org.mortbay.http.handler.SecurityHandler.authenticatedI nRole(SecurityHandler.java:360) at org.mortbay.http.handler.SecurityHandler.handle (SecurityHandler.java:286) at org.mortbay.http.HandlerContext.handle (HandlerContext.java:1037) at org.mortbay.http.HandlerContext.handle (HandlerContext.java:992) at org.mortbay.http.HttpServer.service (HttpServer.java:699) at org.mortbay.http.HttpConnection.service (HttpConnection.java:745) at org.mortbay.http.HttpConnection.handleNext (HttpConnection.java:918) at org.mortbay.http.HttpConnection.handle (HttpConnection.java:760) at org.mortbay.http.SocketListener.handleConnection (SocketListener.java:148) at org.mortbay.util.ThreadedServer.handle (ThreadedServer.java:287) at org.mortbay.util.ThreadPool$JobRunner.run (ThreadPool.java:716) at java.lang.Thread.run(Thread.java:484) -- >Comment By: Scott M Stark (starksm) Date: 2001-12-02 14:30 Message: Logged In: YES user_id=175228 A new JBoss-2.4.4/Jetty-3.1.3-1 bundle has been released with a fix for the security problem. -- Comment By: Scott M Stark (starksm) Date: 2001-11-29 14:38 Message: Logged In: YES user_id=175228 The security integration tests fail for this release bundle, so its not a valid distribution. I'll look at updating the release to run with the 2.4.4 beta this weekend. [starksm@banshee build]$ ant -buildfile run_tests.xml - Dtestcase=web run-testcase Buildfile: run_tests.xml run-testcase: [junit] Running org.jboss.test.web.test.TestWebIntegration [junit] Found warDeployer named: :service=Jetty [junit] Deploying: jbosstest-web.ear...Done [junit] Invokded flushAuthenticationCache(other) [junit] Try #1 [junit] Connecting to: http://jduke:theduke@localhost:8080/jbosstest/restricted/Sec ureServlet [junit] HttpClient.reponse = HTTP/1.1 500 Internal Server Error [junit] responseCode=500, response=Internal Server Error [junit] [junit] [junit] Error 500 Internal Server Error [junit] [junit] HTTP ERROR: 500 Internal Server Error [junit] java.lang.ClassCastException: java.lang.StringRequestURI=/jbosstest/restricted/SecureSe rvlet [junit] [junit] [junit] [junit] [junit] [junit]
[JBoss-dev] CVS update: contrib/jetty/src/build build.xml
User: starksm
Date: 01/12/02 14:07:27
Modified:jetty/src/build Tag: Branch_2_4 build.xml
Log:
Synch up with the tomcat bundle build proceedure
Revision ChangesPath
No revision
No revision
1.6.2.2 +157 -113 contrib/jetty/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/jetty/src/build/Attic/build.xml,v
retrieving revision 1.6.2.1
retrieving revision 1.6.2.2
diff -u -r1.6.2.1 -r1.6.2.2
--- build.xml 2001/09/15 13:14:59 1.6.2.1
+++ build.xml 2001/12/02 22:07:27 1.6.2.2
@@ -1,47 +1,71 @@
-
-
+
+
+
-
+
+
+
+
-
+
-
+
-
-
-
-
-
-
+
+
+
+
+
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
+
+
+
-
+
+
+
+
@@ -60,106 +84,61 @@
/>
+
+Specification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${version} CVSTag=${version-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
-
-
-
+
+
+
+
+
-
-
+
+
-
-
-
@@ -177,9 +156,9 @@
-
+
-
+
Adding Jetty MLET to jboss.conf
@@ -228,17 +207,82 @@
-
-
-
-
+#!/bin/sh
+JBOSS_CLASSPATH=$$JBOSS_CLASSPATH:$$JAVA_HOME/lib/tools.jar
+export JBOSS_CLASSPATH
+/bin/sh ./run.sh jetty
+
+@echo off
+set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;%JAVA_HOME%/lib/tools.jar
+.\run.bat jetty
+
+
+
+
+
+
-
-Adding run script
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] setEntityContext called at pool push time (because of reclaim usage in EntityInstancePool)
Hi, JBOSS 2.4.4 almost latest CVS If I have some finders method called, new Entity are created by the pool, then push (free) in the pool at the end. The push is done by remove/create because reclaim is false, so setEntityContext is run here. So I don't have real pool usage because the overhead of setEntityContext is always there. I am doing jndi lookups in setEntityContext which is quite "heavy". If I use EntityMultiInstanceSynchronizationInterceptor, the free method of AbstractInstanceCache in not called and so the pool is not used at all (see EnityInstancePool.free()) I am not confident enough to find the solution. Regards. Vincent. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] StdServerSession and TX
[The background to this mail, may be found in the message forum:
http://www.jboss.org/forums/thread.jsp?forum=48&thread=4209]
Hi, Hiram and you other JBossMQ hackers. I have made a try to
reimplement the ServerSession(Pool) stuff so that it should potentially
become really (;-)) spec comliant and be able to handle the case where
more than one message is stuffed into the session (the chance are great
that it will ease integration with SonicMQ and SwiftMQ).
To do this I tested to make the StdServerSession a MessageListener and
make the session actually call StdServerSession and have the transaction
stuff in the onMessage. The TX stuff was therefore moved from
StdServerSession.run() (which calles the session.run()) to a new
onMessage method in StdServerSession (which then calles the container
invoker).
It does not, however, work as expected. What I can see I get this
behaviour:
1. If a rollback occures the message is not acknowledged and stays in
PM.
2. But no more attempts are made at delivering it.
As far as I can see all things are equals, except that the normal
restore is not run.
I.e a rollback in this code will roll the ack back, but no redelivery
will be tried, which I guess is not correct behaviour.
I poked a round in the code, and I wonder if it is these lines of codes
that make it:
After the message has been delivered to the listener this is done:
if ( session.transacted ) {
session.connection.spyXAResourceManager.ackMessage(
session.currentTransactionId, message );
} else if ( session.acknowledgeMode == session.AUTO_ACKNOWLEDGE ||
session.acknowledgeMode == session.DUPS_OK_ACKNOWLEDGE ) {
message.doAcknowledge();
}
Could it be, that when the TX stuff is in run() (i.e the commit/rollback
stuff will be run after this method has returned, this works because it
overrides the ack, but when the TX code is in the listener, the ack will
be run even if the receipt was acually a rollback.
I am not shure in what regards we should consider this a bug or not, but
I do know that it will not work to load a session with several messages
for the ASF part, since this will lead to the fact that several messages
will be run under a single transaction, which is not allowed according
to the EJB 2.0 spec. Therefore we must either forbid more than one
message a time, move the TX code into the onMessage part, or create some
cind of non spec compliant callback interface (as weblogic and the ri
has done).
Or is it something else playing tricks here?
//Peter
--
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems ArchitectWWW: http://www.tim.se
Email: [EMAIL PROTECTED]WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RequiredModelMBean.java? / general rantings
You are correct sir! (doing my best Ed McMahon impression) JBoss is providing most of the infrustructure (we use JMX/JMS/EJB). And, we are planning on selling by January. So it may even be the first JBoss 3.0 based thing in commercial use. This is why I go on these little mini-rants about administration. At my previous job (eloan.com), the biggest cause for downtime was from administration mistakes. And that was in no way the fault of the actual admins. The admins were the best I've seen. It really came from having too many different non-connected pieces to manage. Every developer rolled their own for config data, file location, a thousand little cron jobs, etc.. Which is why I fully believe that central and *easy* administration is going to be the winner in this space. And JBoss has all the parts required to make this happen. No other app server can touch us here. But, I think I'm preaching to the choir here, as far as JBoss being the "Kwisatz Haderach" of app servers. (Dune reference, but I don't know a geek who hasn't seen Dune, so you probably already knew that) -David On Sun, 02 Dec 2001, marc fleury wrote: > So much the better, you get to work on stuff that Juha wrote for the book > and will save you some time. You even get to use it in your application if > you want, seems like JBoss3.0 is providing a lot of infrastructure for you. > > Your help will be much appreciated on that base, > > marcf > > |-Original Message- > |From: David Budworth [mailto:[EMAIL PROTECTED]] > |Sent: Sunday, December 02, 2001 4:50 AM > |To: Juha-P Lindfors > |Cc: David Budworth; [EMAIL PROTECTED]; > |[EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings > | > | > |Ahh. ok. > | > |Well, it's obvious to me (as well as everyone else I assume). That you > |know a lot more about this stuff than I do. > | > |So, I'll leave it to the experts. > | > |Thanks for replying. > | > |-David > | > | > |On Sun, 02 Dec 2001, Juha-P Lindfors wrote: > | > |> > |> > |> Hi, > |> > |> > Marc / everyone, > |> > > |> > When you asked about this Dynamic mbean thing I'm working on, were you > |> > thinking of me applying it to RequiredModelMBean? > |> > |> I wrote a ModelMBean implementation for the book and will commit an > |> implementation based on it (with some other stuff) in the next couple of > |> days. > |> > |> > |> > If I read correctly, we are required to supply an > |implementation of that > |> > class, no? > |> > |> Just implementing the ModelMBean interface will be enough. > |> > |> > |> > 1) What are the expectations for determining the MBeanInfo? Should we > |> > expect a XYZMBean interface to match the XYZ implementation the user > |> > provides? (similar to regular MBeans) > |> > > |> > This would be easy to add. Since I already have the code that > |walks the > |> > methods of any specified interface to compose the operation/attribute > |> > info structures. > |> > |> The metadata can be built using introspection on the resource class, read > |> from a database, read from a file, looked up from the JNDI. The > |> rules for introspection can follow the standard MBean rules, or you can > |> create your own naming rules for a specific resource type. > |> > |> > |> > 2) What should be the rules for determining the operations/attributes? > |> > I have written and re-written this logic in my own code about 15 times, > |> > never really happy with it. Example, how to handle: > |> > > |> > int getXYZ(); > |> > void setXYZ(float); > |> > > |> > Do you consider the get to be a RO attribute and one to be an > |operation? Or > |> > throw an exception for non-compliant naming? I see nothing in the spec > |> > regarding naming standards on dynamic mbean oper/attr > |> > > |> > or > |> > > |> > int getXYZ(); > |> > void setXYZ(int); > |> > void setXYZ(float); > |> > > |> > Do we consider get/set(int) to be a RW attr, and set(float) to be an > |> > operation? Or throw again? > |> > |> If you are talking about the Standard MBean behaviour, that would cause a > |> NotCompliantMBeanException to be thrown. However, for ModelMBeans you > |> could build your own resource types that allow this kind of interface to > |> be handled differently. > |> > |> > As for persistence, have you finished rolling on the floor laughing at > |> > my idea of using EJBs to store? I have noticed that no other > |components > |> > use EJBs for their JDBC based persistence. Is there a reason for this? > |> > |> The MMBean persistence can be abstracted behind a > |> simple PersistenceManager interface with load and store operations. The > |> persistence implementation may then be file based, direct JDBC, JDO or > |> EJB. > |> > |> > |> -- Juha > |> > |> > |> ___ > |> Jboss-development mailing list > |> [EMAIL PROTECTED] > |> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-develop
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
In other words JBossMX is going to be a full JMX implementation from mr lindfors, in the meantime I don't want you diverting resources by using our lists :) you fight your own war kid, You know we have a history of squashing open* projects :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Sunday, December 02, 2001 1:06 PM |To: Bordet, Simone; David Budworth; Juha-P Lindfors |Cc: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |Simone, | |unless OpenJMX becomes a project of JBoss I don't really want you plugin |your stuff on our lists :) | |thanks | |marcf | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED]]On Behalf Of ||Bordet, Simone ||Sent: Sunday, December 02, 2001 12:48 PM ||To: marc fleury; David Budworth; Juha-P Lindfors ||Cc: [EMAIL PROTECTED] ||Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings || || ||Hi, || ||jumping in late... ||OpenJMX will soon release an implementation of RMMB with pluggable ||logging redirection and pluggable persistence mechanism. See ||http://sourceforge.net/projects/openjmx for details. || ||Cheers || ||Simon || ||> -Original Message- ||> From: marc fleury [mailto:[EMAIL PROTECTED]] ||> Sent: domenica 2 dicembre 2001 16:33 ||> To: David Budworth; Juha-P Lindfors ||> Cc: [EMAIL PROTECTED] ||> Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings ||> ||> ||> So much the better, you get to work on stuff that Juha wrote ||> for the book ||> and will save you some time. You even get to use it in your ||> application if ||> you want, seems like JBoss3.0 is providing a lot of ||> infrastructure for you. ||> ||> Your help will be much appreciated on that base, ||> ||> marcf ||> ||> |-Original Message- ||> |From: David Budworth [mailto:[EMAIL PROTECTED]] ||> |Sent: Sunday, December 02, 2001 4:50 AM ||> |To: Juha-P Lindfors ||> |Cc: David Budworth; [EMAIL PROTECTED]; ||> |[EMAIL PROTECTED] ||> |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings ||> | ||> | ||> |Ahh. ok. ||> | ||> |Well, it's obvious to me (as well as everyone else I ||> assume). That you ||> |know a lot more about this stuff than I do. ||> | ||> |So, I'll leave it to the experts. ||> | ||> |Thanks for replying. ||> | ||> |-David ||> | ||> | ||> |On Sun, 02 Dec 2001, Juha-P Lindfors wrote: ||> | ||> |> ||> |> ||> |> Hi, ||> |> ||> |> > Marc / everyone, ||> |> > ||> |> > When you asked about this Dynamic mbean thing I'm ||> working on, were you ||> |> > thinking of me applying it to RequiredModelMBean? ||> |> ||> |> I wrote a ModelMBean implementation for the book and will commit an ||> |> implementation based on it (with some other stuff) in the ||> next couple of ||> |> days. ||> |> ||> |> ||> |> > If I read correctly, we are required to supply an ||> |implementation of that ||> |> > class, no? ||> |> ||> |> Just implementing the ModelMBean interface will be enough. ||> |> ||> |> ||> |> > 1) What are the expectations for determining the ||> MBeanInfo? Should we ||> |> > expect a XYZMBean interface to match the XYZ ||> implementation the user ||> |> > provides? (similar to regular MBeans) ||> |> > ||> |> > This would be easy to add. Since I already have the code that ||> |walks the ||> |> > methods of any specified interface to compose the ||> operation/attribute ||> |> > info structures. ||> |> ||> |> The metadata can be built using introspection on the ||> resource class, read ||> |> from a database, read from a file, looked up from the JNDI. The ||> |> rules for introspection can follow the standard MBean ||> rules, or you can ||> |> create your own naming rules for a specific resource type. ||> |> ||> |> ||> |> > 2) What should be the rules for determining the ||> operations/attributes? ||> |> > I have written and re-written this logic in my own code ||> about 15 times, ||> |> > never really happy with it. Example, how to handle: ||> |> > ||> |> > int getXYZ(); ||> |> > void setXYZ(float); ||> |> > ||> |> > Do you consider the get to be a RO attribute and one to be an ||> |operation? Or ||> |> > throw an exception for non-compliant naming? I see ||> nothing in the spec ||> |> > regarding naming standards on dynamic mbean oper/attr ||> |> > ||> |> > or ||> |> > ||> |> > int getXYZ(); ||> |> > void setXYZ(int); ||> |> > void setXYZ(float); ||> |> > ||> |> > Do we consider get/set(int) to be a RW attr, and ||> set(float) to be an ||> |> > operation? Or throw again? ||> |> ||> |> If you are talking about the Standard MBean behaviour, ||> that would cause a ||> |> NotCompliantMBeanException to be thrown. However, for ||> ModelMBeans you ||> |> could build your own resource types that allow this kind ||> of interface to ||> |> be handled differently. ||> |> ||> |> > As for persistence, have you finished rolling on the ||> floor laughing at ||> |> > my idea of using EJBs to store? I have notic
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
Simone, unless OpenJMX becomes a project of JBoss I don't really want you plugin your stuff on our lists :) thanks marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Bordet, Simone |Sent: Sunday, December 02, 2001 12:48 PM |To: marc fleury; David Budworth; Juha-P Lindfors |Cc: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |Hi, | |jumping in late... |OpenJMX will soon release an implementation of RMMB with pluggable |logging redirection and pluggable persistence mechanism. See |http://sourceforge.net/projects/openjmx for details. | |Cheers | |Simon | |> -Original Message- |> From: marc fleury [mailto:[EMAIL PROTECTED]] |> Sent: domenica 2 dicembre 2001 16:33 |> To: David Budworth; Juha-P Lindfors |> Cc: [EMAIL PROTECTED] |> Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings |> |> |> So much the better, you get to work on stuff that Juha wrote |> for the book |> and will save you some time. You even get to use it in your |> application if |> you want, seems like JBoss3.0 is providing a lot of |> infrastructure for you. |> |> Your help will be much appreciated on that base, |> |> marcf |> |> |-Original Message- |> |From: David Budworth [mailto:[EMAIL PROTECTED]] |> |Sent: Sunday, December 02, 2001 4:50 AM |> |To: Juha-P Lindfors |> |Cc: David Budworth; [EMAIL PROTECTED]; |> |[EMAIL PROTECTED] |> |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings |> | |> | |> |Ahh. ok. |> | |> |Well, it's obvious to me (as well as everyone else I |> assume). That you |> |know a lot more about this stuff than I do. |> | |> |So, I'll leave it to the experts. |> | |> |Thanks for replying. |> | |> |-David |> | |> | |> |On Sun, 02 Dec 2001, Juha-P Lindfors wrote: |> | |> |> |> |> |> |> Hi, |> |> |> |> > Marc / everyone, |> |> > |> |> > When you asked about this Dynamic mbean thing I'm |> working on, were you |> |> > thinking of me applying it to RequiredModelMBean? |> |> |> |> I wrote a ModelMBean implementation for the book and will commit an |> |> implementation based on it (with some other stuff) in the |> next couple of |> |> days. |> |> |> |> |> |> > If I read correctly, we are required to supply an |> |implementation of that |> |> > class, no? |> |> |> |> Just implementing the ModelMBean interface will be enough. |> |> |> |> |> |> > 1) What are the expectations for determining the |> MBeanInfo? Should we |> |> > expect a XYZMBean interface to match the XYZ |> implementation the user |> |> > provides? (similar to regular MBeans) |> |> > |> |> > This would be easy to add. Since I already have the code that |> |walks the |> |> > methods of any specified interface to compose the |> operation/attribute |> |> > info structures. |> |> |> |> The metadata can be built using introspection on the |> resource class, read |> |> from a database, read from a file, looked up from the JNDI. The |> |> rules for introspection can follow the standard MBean |> rules, or you can |> |> create your own naming rules for a specific resource type. |> |> |> |> |> |> > 2) What should be the rules for determining the |> operations/attributes? |> |> > I have written and re-written this logic in my own code |> about 15 times, |> |> > never really happy with it. Example, how to handle: |> |> > |> |> > int getXYZ(); |> |> > void setXYZ(float); |> |> > |> |> > Do you consider the get to be a RO attribute and one to be an |> |operation? Or |> |> > throw an exception for non-compliant naming? I see |> nothing in the spec |> |> > regarding naming standards on dynamic mbean oper/attr |> |> > |> |> > or |> |> > |> |> > int getXYZ(); |> |> > void setXYZ(int); |> |> > void setXYZ(float); |> |> > |> |> > Do we consider get/set(int) to be a RW attr, and |> set(float) to be an |> |> > operation? Or throw again? |> |> |> |> If you are talking about the Standard MBean behaviour, |> that would cause a |> |> NotCompliantMBeanException to be thrown. However, for |> ModelMBeans you |> |> could build your own resource types that allow this kind |> of interface to |> |> be handled differently. |> |> |> |> > As for persistence, have you finished rolling on the |> floor laughing at |> |> > my idea of using EJBs to store? I have noticed that no other |> |components |> |> > use EJBs for their JDBC based persistence. Is there a |> reason for this? |> |> |> |> The MMBean persistence can be abstracted behind a |> |> simple PersistenceManager interface with load and store |> operations. The |> |> persistence implementation may then be file based, direct |> JDBC, JDO or |> |> EJB. |> |> |> |> |> |> -- Juha |> |> |> |> |> |> ___ |> |> Jboss-development mailing list |> |> [EMAIL PROTECTED] |> |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.s
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
Hi, jumping in late... OpenJMX will soon release an implementation of RMMB with pluggable logging redirection and pluggable persistence mechanism. See http://sourceforge.net/projects/openjmx for details. Cheers Simon > -Original Message- > From: marc fleury [mailto:[EMAIL PROTECTED]] > Sent: domenica 2 dicembre 2001 16:33 > To: David Budworth; Juha-P Lindfors > Cc: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings > > > So much the better, you get to work on stuff that Juha wrote > for the book > and will save you some time. You even get to use it in your > application if > you want, seems like JBoss3.0 is providing a lot of > infrastructure for you. > > Your help will be much appreciated on that base, > > marcf > > |-Original Message- > |From: David Budworth [mailto:[EMAIL PROTECTED]] > |Sent: Sunday, December 02, 2001 4:50 AM > |To: Juha-P Lindfors > |Cc: David Budworth; [EMAIL PROTECTED]; > |[EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings > | > | > |Ahh. ok. > | > |Well, it's obvious to me (as well as everyone else I > assume). That you > |know a lot more about this stuff than I do. > | > |So, I'll leave it to the experts. > | > |Thanks for replying. > | > |-David > | > | > |On Sun, 02 Dec 2001, Juha-P Lindfors wrote: > | > |> > |> > |> Hi, > |> > |> > Marc / everyone, > |> > > |> > When you asked about this Dynamic mbean thing I'm > working on, were you > |> > thinking of me applying it to RequiredModelMBean? > |> > |> I wrote a ModelMBean implementation for the book and will commit an > |> implementation based on it (with some other stuff) in the > next couple of > |> days. > |> > |> > |> > If I read correctly, we are required to supply an > |implementation of that > |> > class, no? > |> > |> Just implementing the ModelMBean interface will be enough. > |> > |> > |> > 1) What are the expectations for determining the > MBeanInfo? Should we > |> > expect a XYZMBean interface to match the XYZ > implementation the user > |> > provides? (similar to regular MBeans) > |> > > |> > This would be easy to add. Since I already have the code that > |walks the > |> > methods of any specified interface to compose the > operation/attribute > |> > info structures. > |> > |> The metadata can be built using introspection on the > resource class, read > |> from a database, read from a file, looked up from the JNDI. The > |> rules for introspection can follow the standard MBean > rules, or you can > |> create your own naming rules for a specific resource type. > |> > |> > |> > 2) What should be the rules for determining the > operations/attributes? > |> > I have written and re-written this logic in my own code > about 15 times, > |> > never really happy with it. Example, how to handle: > |> > > |> > int getXYZ(); > |> > void setXYZ(float); > |> > > |> > Do you consider the get to be a RO attribute and one to be an > |operation? Or > |> > throw an exception for non-compliant naming? I see > nothing in the spec > |> > regarding naming standards on dynamic mbean oper/attr > |> > > |> > or > |> > > |> > int getXYZ(); > |> > void setXYZ(int); > |> > void setXYZ(float); > |> > > |> > Do we consider get/set(int) to be a RW attr, and > set(float) to be an > |> > operation? Or throw again? > |> > |> If you are talking about the Standard MBean behaviour, > that would cause a > |> NotCompliantMBeanException to be thrown. However, for > ModelMBeans you > |> could build your own resource types that allow this kind > of interface to > |> be handled differently. > |> > |> > As for persistence, have you finished rolling on the > floor laughing at > |> > my idea of using EJBs to store? I have noticed that no other > |components > |> > use EJBs for their JDBC based persistence. Is there a > reason for this? > |> > |> The MMBean persistence can be abstracted behind a > |> simple PersistenceManager interface with load and store > operations. The > |> persistence implementation may then be file based, direct > JDBC, JDO or > |> EJB. > |> > |> > |> -- Juha > |> > |> > |> ___ > |> Jboss-development mailing list > |> [EMAIL PROTECTED] > |> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
So much the better, you get to work on stuff that Juha wrote for the book and will save you some time. You even get to use it in your application if you want, seems like JBoss3.0 is providing a lot of infrastructure for you. Your help will be much appreciated on that base, marcf |-Original Message- |From: David Budworth [mailto:[EMAIL PROTECTED]] |Sent: Sunday, December 02, 2001 4:50 AM |To: Juha-P Lindfors |Cc: David Budworth; [EMAIL PROTECTED]; |[EMAIL PROTECTED] |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |Ahh. ok. | |Well, it's obvious to me (as well as everyone else I assume). That you |know a lot more about this stuff than I do. | |So, I'll leave it to the experts. | |Thanks for replying. | |-David | | |On Sun, 02 Dec 2001, Juha-P Lindfors wrote: | |> |> |> Hi, |> |> > Marc / everyone, |> > |> > When you asked about this Dynamic mbean thing I'm working on, were you |> > thinking of me applying it to RequiredModelMBean? |> |> I wrote a ModelMBean implementation for the book and will commit an |> implementation based on it (with some other stuff) in the next couple of |> days. |> |> |> > If I read correctly, we are required to supply an |implementation of that |> > class, no? |> |> Just implementing the ModelMBean interface will be enough. |> |> |> > 1) What are the expectations for determining the MBeanInfo? Should we |> > expect a XYZMBean interface to match the XYZ implementation the user |> > provides? (similar to regular MBeans) |> > |> > This would be easy to add. Since I already have the code that |walks the |> > methods of any specified interface to compose the operation/attribute |> > info structures. |> |> The metadata can be built using introspection on the resource class, read |> from a database, read from a file, looked up from the JNDI. The |> rules for introspection can follow the standard MBean rules, or you can |> create your own naming rules for a specific resource type. |> |> |> > 2) What should be the rules for determining the operations/attributes? |> > I have written and re-written this logic in my own code about 15 times, |> > never really happy with it. Example, how to handle: |> > |> > int getXYZ(); |> > void setXYZ(float); |> > |> > Do you consider the get to be a RO attribute and one to be an |operation? Or |> > throw an exception for non-compliant naming? I see nothing in the spec |> > regarding naming standards on dynamic mbean oper/attr |> > |> > or |> > |> > int getXYZ(); |> > void setXYZ(int); |> > void setXYZ(float); |> > |> > Do we consider get/set(int) to be a RW attr, and set(float) to be an |> > operation? Or throw again? |> |> If you are talking about the Standard MBean behaviour, that would cause a |> NotCompliantMBeanException to be thrown. However, for ModelMBeans you |> could build your own resource types that allow this kind of interface to |> be handled differently. |> |> > As for persistence, have you finished rolling on the floor laughing at |> > my idea of using EJBs to store? I have noticed that no other |components |> > use EJBs for their JDBC based persistence. Is there a reason for this? |> |> The MMBean persistence can be abstracted behind a |> simple PersistenceManager interface with load and store operations. The |> persistence implementation may then be file based, direct JDBC, JDO or |> EJB. |> |> |> -- Juha |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RequiredModelMBean.java? / general rantings
Ahh. ok. Well, it's obvious to me (as well as everyone else I assume). That you know a lot more about this stuff than I do. So, I'll leave it to the experts. Thanks for replying. -David On Sun, 02 Dec 2001, Juha-P Lindfors wrote: > > > Hi, > > > Marc / everyone, > > > > When you asked about this Dynamic mbean thing I'm working on, were you > > thinking of me applying it to RequiredModelMBean? > > I wrote a ModelMBean implementation for the book and will commit an > implementation based on it (with some other stuff) in the next couple of > days. > > > > If I read correctly, we are required to supply an implementation of that > > class, no? > > Just implementing the ModelMBean interface will be enough. > > > > 1) What are the expectations for determining the MBeanInfo? Should we > > expect a XYZMBean interface to match the XYZ implementation the user > > provides? (similar to regular MBeans) > > > > This would be easy to add. Since I already have the code that walks the > > methods of any specified interface to compose the operation/attribute > > info structures. > > The metadata can be built using introspection on the resource class, read > from a database, read from a file, looked up from the JNDI. The > rules for introspection can follow the standard MBean rules, or you can > create your own naming rules for a specific resource type. > > > > 2) What should be the rules for determining the operations/attributes? > > I have written and re-written this logic in my own code about 15 times, > > never really happy with it. Example, how to handle: > > > > int getXYZ(); > > void setXYZ(float); > > > > Do you consider the get to be a RO attribute and one to be an operation? Or > > throw an exception for non-compliant naming? I see nothing in the spec > > regarding naming standards on dynamic mbean oper/attr > > > > or > > > > int getXYZ(); > > void setXYZ(int); > > void setXYZ(float); > > > > Do we consider get/set(int) to be a RW attr, and set(float) to be an > > operation? Or throw again? > > If you are talking about the Standard MBean behaviour, that would cause a > NotCompliantMBeanException to be thrown. However, for ModelMBeans you > could build your own resource types that allow this kind of interface to > be handled differently. > > > As for persistence, have you finished rolling on the floor laughing at > > my idea of using EJBs to store? I have noticed that no other components > > use EJBs for their JDBC based persistence. Is there a reason for this? > > The MMBean persistence can be abstracted behind a > simple PersistenceManager interface with load and store operations. The > persistence implementation may then be file based, direct JDBC, JDO or > EJB. > > > -- Juha > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RequiredModelMBean.java? / general rantings
Hi, > Marc / everyone, > > When you asked about this Dynamic mbean thing I'm working on, were you > thinking of me applying it to RequiredModelMBean? I wrote a ModelMBean implementation for the book and will commit an implementation based on it (with some other stuff) in the next couple of days. > If I read correctly, we are required to supply an implementation of that > class, no? Just implementing the ModelMBean interface will be enough. > 1) What are the expectations for determining the MBeanInfo? Should we > expect a XYZMBean interface to match the XYZ implementation the user > provides? (similar to regular MBeans) > > This would be easy to add. Since I already have the code that walks the > methods of any specified interface to compose the operation/attribute > info structures. The metadata can be built using introspection on the resource class, read from a database, read from a file, looked up from the JNDI. The rules for introspection can follow the standard MBean rules, or you can create your own naming rules for a specific resource type. > 2) What should be the rules for determining the operations/attributes? > I have written and re-written this logic in my own code about 15 times, > never really happy with it. Example, how to handle: > > int getXYZ(); > void setXYZ(float); > > Do you consider the get to be a RO attribute and one to be an operation? Or > throw an exception for non-compliant naming? I see nothing in the spec > regarding naming standards on dynamic mbean oper/attr > > or > > int getXYZ(); > void setXYZ(int); > void setXYZ(float); > > Do we consider get/set(int) to be a RW attr, and set(float) to be an > operation? Or throw again? If you are talking about the Standard MBean behaviour, that would cause a NotCompliantMBeanException to be thrown. However, for ModelMBeans you could build your own resource types that allow this kind of interface to be handled differently. > As for persistence, have you finished rolling on the floor laughing at > my idea of using EJBs to store? I have noticed that no other components > use EJBs for their JDBC based persistence. Is there a reason for this? The MMBean persistence can be abstracted behind a simple PersistenceManager interface with load and store operations. The persistence implementation may then be file based, direct JDBC, JDO or EJB. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
