Re: [JBoss-dev] build system change
'testsuite' does not build anything, it simply runs the jboss/testsuite 'tests' target. Too build everything, then run the testsuite, use most, main or all as the target to execute before testsuite. ./build.sh most testsuite 'all' will simply make docs too, which aren't very useful for testing. The 'run-nightly' target should update, clean, build, start jboss, run the tests, stop jboss then generate reports. If you are trying to setup a recurring testsuite run then it should be used. It might need to be update for these latest changes though. Invoking all child modules, even if they don't build anything, isn't a fast process. I think there are still some problems past that though. I had to create a new jndi.properties in src/resources because I couldn't really figure out where the jndi.properties came from before. Could be that there were some other files included in this mysterious way which I have missed. --jason the most On Tue, 4 Sep 2001, Scott M Stark wrote: > The testsuite is expecting that a number of packages have been built but it > is not validating that they have. This is the source of the numerous errors. > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: "Scott M Stark" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Monday, September 03, 2001 11:35 PM > Subject: Re: [JBoss-dev] build system change > > > > Yup, it does work... mostly. Did you get any of the email that I sent to > > you about the security tests? > > > > I think there might be some config or file placement issues. I had to > > change the way several jar files were being created to avoid having one > jar > > build be dependent on the jar build before it (ie. movies files around to > > get a jboss.xml and ejb-jar.xml file). I would really like to change all > of > > these to use the and tasks, but that will required > more > > time than I have at the moment (my guess is that it could be done in 2 > > days). > > > > We should really replace assert() usage. It is on my list of things to > look > > into further, along with a common JBossTestsuite class, and other > testsuite > > improvements. > > > > I would rather not turn of deprecation warnings if it can be avoided. > > > > --jason > > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] build system change
The testsuite is expecting that a number of packages have been built but it is not validating that they have. This is the source of the numerous errors. - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, September 03, 2001 11:35 PM Subject: Re: [JBoss-dev] build system change > Yup, it does work... mostly. Did you get any of the email that I sent to > you about the security tests? > > I think there might be some config or file placement issues. I had to > change the way several jar files were being created to avoid having one jar > build be dependent on the jar build before it (ie. movies files around to > get a jboss.xml and ejb-jar.xml file). I would really like to change all of > these to use the and tasks, but that will required more > time than I have at the moment (my guess is that it could be done in 2 > days). > > We should really replace assert() usage. It is on my list of things to look > into further, along with a common JBossTestsuite class, and other testsuite > improvements. > > I would rather not turn of deprecation warnings if it can be avoided. > > --jason > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] build system change
Yup, it does work... mostly. Did you get any of the email that I sent to
you about the security tests?
I think there might be some config or file placement issues. I had to
change the way several jar files were being created to avoid having one jar
build be dependent on the jar build before it (ie. movies files around to
get a jboss.xml and ejb-jar.xml file). I would really like to change all of
these to use the and tasks, but that will required more
time than I have at the moment (my guess is that it could be done in 2
days).
We should really replace assert() usage. It is on my list of things to look
into further, along with a common JBossTestsuite class, and other testsuite
improvements.
I would rather not turn of deprecation warnings if it can be avoided.
--jason
On Mon, 3 Sep 2001, Scott M Stark wrote:
> Is the testsuite supposed to be building yet? I see numerous errors and
> warnings. The warnings are due to the junit3.7 deprecation of the assert()
> method in favor of assertTrue()
>
> testsuite 1064>./build.sh
> Searching for build.xml ...
> Buildfile: /home/starksm/cvsroot/Main/jboss-all/testsuite/build.xml
>
> init-buildlog:
>
> init:
> [moduleinfo] Project root: /home/starksm/cvsroot/Main/jboss-all
> [moduleinfo] Module root: /home/starksm/cvsroot/Main/jboss-all/testsuite
>
> compile-classes:
> [mkdir] Created dir:
> /home/starksm/cvsroot/Main/jboss-all/testsuite/output/classes
> [javac] Compiling 274 source files to
> /home/starksm/cvsroot/Main/jboss-all/testsuite/output/classes
> [javac]
> /home/starksm/cvsroot/Main/jboss-all/testsuite/src/main/org/jboss/test/bank/
> ejb/AccountBean.java:8: cannot resolve symbol
> [javac] symbol : class CreateException
> [javac] location: package ejb
> [javac] import javax.ejb.CreateException;
> [javac] ^
> [javac]
> /home/starksm/cvsroot/Main/jboss-all/testsuite/src/main/org/jboss/test/util/
> ejb/EntitySupport.java:8: package javax.ejb does not exist
> [javac] import javax.ejb.*;
> [javac] ^
> [javac]
> /home/starksm/cvsroot/Main/jboss-all/testsuite/src/main/org/jboss/test/util/
> ejb/EntitySupport.java:18: cannot resolve symbol
> [javac] symbol : class EntityBean
> [javac] location: class org.jboss.test.util.ejb.EntitySupport
> [javac]implements EntityBean
> [javac] ^
> ...
> [javac]
> /home/starksm/cvsroot/Main/jboss-all/testsuite/src/main/org/jboss/test/testb
> ean/test/Main.java:632: warning: assert(java.lang.String,boolean) in
> junit.framework.Assert has been deprecated
> [javac] assert("pkBean != null", pkBean != null);
> [javac] ^
> [javac] 100 errors
> [javac] 125 warnings
>
> - Original Message -
> From: "Jason Dillon" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Monday, September 03, 2001 10:21 PM
> Subject: [JBoss-dev] build system change
>
>
> > I finished the first round of modifications to the jboss-* modules, to
> make
> > it easier to share modules between projects. The release mechanism has
> been
> > moved to the control module, which will pull the generated files from the
> > source module after that module has been executed.
> >
> > I did away with the 'min' targets. They were mostly useless. I am
> keeping
> > the most targets though, and using them as the default in most cases.
> >
> > I have not had time to update jboss-docs, jboss-website or jboss-mq with
> the
> > new release semantics, but I should get to that soon.
> >
> > I left the release-* targets in each source module, but all that is really
> > used for now is creating an archive of the files under output/*.
> Eventually
> > this mechanism could be used for plugins to generate a .sar (.jsr, .ear,
> > whatever), so some docs them make a nice archive of it.
> >
> > The release-dependencies have all moved to the control module, which means
> > that I had to move over the thirdparty properties too. I don't really
> like
> > that too much, but in the short term there is no way to get around it.
> >
> > I also tried to remember to give each build.xml a valid name, for those
> who
> > have ide's which use that value. I also tried to change the
> > junit.jvm.options to -Ddummy from -client.
> >
> > It looks like Ant 1.4 will allow elements to be created from inside
> > of a , so once I have finished updating the projects, I might look
> > to moving everything that is currently outside of a into one.
> This
> > will make it easier to group properties and patsh with helper tasks
> > together. Like for the path convertion task, which might be required for
> > the manual module under win32.
> >
> > Let me know if there are any problems.
> >
> > --jason
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> ___
> Jbos
Re: [JBoss-dev] build system change
Is the testsuite supposed to be building yet? I see numerous errors and
warnings. The warnings are due to the junit3.7 deprecation of the assert()
method in favor of assertTrue()
testsuite 1064>./build.sh
Searching for build.xml ...
Buildfile: /home/starksm/cvsroot/Main/jboss-all/testsuite/build.xml
init-buildlog:
init:
[moduleinfo] Project root: /home/starksm/cvsroot/Main/jboss-all
[moduleinfo] Module root: /home/starksm/cvsroot/Main/jboss-all/testsuite
compile-classes:
[mkdir] Created dir:
/home/starksm/cvsroot/Main/jboss-all/testsuite/output/classes
[javac] Compiling 274 source files to
/home/starksm/cvsroot/Main/jboss-all/testsuite/output/classes
[javac]
/home/starksm/cvsroot/Main/jboss-all/testsuite/src/main/org/jboss/test/bank/
ejb/AccountBean.java:8: cannot resolve symbol
[javac] symbol : class CreateException
[javac] location: package ejb
[javac] import javax.ejb.CreateException;
[javac] ^
[javac]
/home/starksm/cvsroot/Main/jboss-all/testsuite/src/main/org/jboss/test/util/
ejb/EntitySupport.java:8: package javax.ejb does not exist
[javac] import javax.ejb.*;
[javac] ^
[javac]
/home/starksm/cvsroot/Main/jboss-all/testsuite/src/main/org/jboss/test/util/
ejb/EntitySupport.java:18: cannot resolve symbol
[javac] symbol : class EntityBean
[javac] location: class org.jboss.test.util.ejb.EntitySupport
[javac]implements EntityBean
[javac] ^
...
[javac]
/home/starksm/cvsroot/Main/jboss-all/testsuite/src/main/org/jboss/test/testb
ean/test/Main.java:632: warning: assert(java.lang.String,boolean) in
junit.framework.Assert has been deprecated
[javac] assert("pkBean != null", pkBean != null);
[javac] ^
[javac] 100 errors
[javac] 125 warnings
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2001 10:21 PM
Subject: [JBoss-dev] build system change
> I finished the first round of modifications to the jboss-* modules, to
make
> it easier to share modules between projects. The release mechanism has
been
> moved to the control module, which will pull the generated files from the
> source module after that module has been executed.
>
> I did away with the 'min' targets. They were mostly useless. I am
keeping
> the most targets though, and using them as the default in most cases.
>
> I have not had time to update jboss-docs, jboss-website or jboss-mq with
the
> new release semantics, but I should get to that soon.
>
> I left the release-* targets in each source module, but all that is really
> used for now is creating an archive of the files under output/*.
Eventually
> this mechanism could be used for plugins to generate a .sar (.jsr, .ear,
> whatever), so some docs them make a nice archive of it.
>
> The release-dependencies have all moved to the control module, which means
> that I had to move over the thirdparty properties too. I don't really
like
> that too much, but in the short term there is no way to get around it.
>
> I also tried to remember to give each build.xml a valid name, for those
who
> have ide's which use that value. I also tried to change the
> junit.jvm.options to -Ddummy from -client.
>
> It looks like Ant 1.4 will allow elements to be created from inside
> of a , so once I have finished updating the projects, I might look
> to moving everything that is currently outside of a into one.
This
> will make it easier to group properties and patsh with helper tasks
> together. Like for the path convertion task, which might be required for
> the manual module under win32.
>
> Let me know if there are any problems.
>
> --jason
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH startup and JBossMQ
You start with a security manager using: bin 564> export JAVA_OPTS="-Djava.security.manager -Djava.security.policy=../conf/default/se rver.policy" bin 564> ./run.sh The SecurityPolicySerivce only augments the standard policy info with Subject based permissions. It does not provide an implementation of the standard Java2 security Policy. - Original Message - From: "David Maplesden" <[EMAIL PROTECTED]> To: "JBossDev (E-mail)" <[EMAIL PROTECTED]> Sent: Monday, September 03, 2001 9:09 PM Subject: [JBoss-dev] RH startup and JBossMQ > PS: I have also had issues with the security mechanisms in RH. The problem > is that currently it ignores the server.policy file, which usually is fine > since no SecurityManager is installed. However we have a custom service we > are writing that uses RMI and hence requires a SecurityManager. > Unfortunately as soon as we install one because the server.policy file has > not been loaded there are all sorts of access restrictions that come into > play that effectively stuff the whole server. > > I tried to fix this by using the SecurityPolicyService mbean to implement a > security policy but it uses an xml policy file and I can't seem to get the > right syntax for it. I took an educated guess (based on one in the test > directory of the security module) but it doesn't seem to work. If anyone > has any ideas (Scott this is your area, right?) then I would appreciate a > helping hand. What I am basically asking for is a pointer to the correct > syntax for the xml file or how to run jboss using a convential policy file > (like server.policy). > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-458277 ] EJBException not being propogated
Bugs item #458277, was opened at 2001-09-03 22:23
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=458277&group_id=22866
Category: None
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: EJBException not being propogated
Initial Comment:
In some instances an EJBException that is thrown from within a business method on a
session bean is not being displayed at the JBoss console. Furthermore the error that
the client calling the business method receives does not contain any reference to the
EJB Exception text as follows:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception
is:
java.rmi.ServerException: Transaction rolled back
java.rmi.ServerException: Transaction rolled back
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:245)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.invoke(Unknown
Source)
at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericProxy.java:357)
at
org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.invoke(StatelessSessionProxy.java:123)
at $Proxy1.queryNewFeeCode(Unknown Source)
at FeeManagerUnitTest.testGenerateFeeCode(FeeManagerUnitTest.java:128)
at FeeManagerUnitTest.main(FeeManagerUnitTest.java:144)
The EJBException was thrown from the following code:
// Run this sequence to obtain a fresh fee code.
try {
connection = EjbToolkit.getConnection();
statement = connection.createStatement();
resultSet = statement.executeQuery(FEE_CODE_QUERY);
if (!resultSet.next())
newFeeCode = resultSet.getString(1);
else {
System.out.println("No result!");
<- HERE ->
throw new EJBException("Failed to generate Fee Code from fee_code_seq
sequence.");
}
}
catch(SQLException se) {
throw new EJBException("Failed to query Fee data: ", se);
}
finally {
try {
if (resultSet != null) resultSet.close();
if (statement != null) statement.close();
if (connection != null) connection.close();
}
catch(Exception e) {}
}
The code executes through '<- HERE ->' then throws the EJBException. The
console output is
[Defaullt] No result!
With no mention of the EJBException...
Dave Elliot
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=458277&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] build system change
I finished the first round of modifications to the jboss-* modules, to make it easier to share modules between projects. The release mechanism has been moved to the control module, which will pull the generated files from the source module after that module has been executed. I did away with the 'min' targets. They were mostly useless. I am keeping the most targets though, and using them as the default in most cases. I have not had time to update jboss-docs, jboss-website or jboss-mq with the new release semantics, but I should get to that soon. I left the release-* targets in each source module, but all that is really used for now is creating an archive of the files under output/*. Eventually this mechanism could be used for plugins to generate a .sar (.jsr, .ear, whatever), so some docs them make a nice archive of it. The release-dependencies have all moved to the control module, which means that I had to move over the thirdparty properties too. I don't really like that too much, but in the short term there is no way to get around it. I also tried to remember to give each build.xml a valid name, for those who have ide's which use that value. I also tried to change the junit.jvm.options to -Ddummy from -client. It looks like Ant 1.4 will allow elements to be created from inside of a , so once I have finished updating the projects, I might look to moving everything that is currently outside of a into one. This will make it easier to group properties and patsh with helper tasks together. Like for the path convertion task, which might be required for the manual module under win32. Let me know if there are any problems. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite build.sh
User: user57 Date: 01/09/03 22:10:15 Modified:.build.sh Log: o ignore user's ANT_HOME Revision ChangesPath 1.2 +4 -1 newsite/build.sh Index: build.sh === RCS file: /cvsroot/jboss/newsite/build.sh,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.sh 2001/08/30 22:34:32 1.1 +++ build.sh 2001/09/04 05:10:15 1.2 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.1 2001/08/30 22:34:32 user57 Exp $ +# $Id: build.sh,v 1.2 2001/09/04 05:10:15 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/website build.sh
User: user57 Date: 01/09/03 22:10:15 Modified:website build.sh Log: o ignore user's ANT_HOME Revision ChangesPath 1.2 +3 -0 build/website/build.sh Index: build.sh === RCS file: /cvsroot/jboss/build/website/build.sh,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.sh 2001/08/30 22:01:56 1.1 +++ build.sh 2001/09/04 05:10:15 1.2 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.1 2001/08/30 22:01:56 user57 Exp $ +# $Id: build.sh,v 1.2 2001/09/04 05:10:15 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.sh build.xml
User: user57 Date: 01/09/03 22:08:06 Modified:jbossbuild.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.6 +4 -1 build/jboss/build.sh Index: build.sh === RCS file: /cvsroot/jboss/build/jboss/build.sh,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.sh 2001/08/28 04:53:07 1.5 +++ build.sh 2001/09/04 05:08:06 1.6 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.5 2001/08/28 04:53:07 user57 Exp $ +# $Id: build.sh,v 1.6 2001/09/04 05:08:06 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.16 +840 -133 build/jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/build/jboss/build.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- build.xml 2001/09/03 09:10:12 1.15 +++ build.xml 2001/09/04 05:08:06 1.16 @@ -10,9 +10,9 @@ - + - + @@ -42,21 +42,6 @@ - - - - - - - - - - - - - - - @@ -73,6 +58,8 @@ + + @@ -80,6 +67,21 @@ + + + + + + + + + + + + + + + @@ -99,6 +101,99 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -171,13 +266,6 @@ - - - - - - - @@ -199,6 +287,7 @@ + @@ -215,9 +304,8 @@ + - - @@ -226,74 +314,18 @@ + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Preparing for server release - - - -Releasing server module output - - - + @@ -304,9 +336,9 @@ - - - + + @@ -316,9 +348,9 @@ - - - + + @@ -329,7 +361,7 @@ - + @@ -364,9 +396,9 @@ - - - + + @@ -376,9 +408,9 @@ - - - + + @@ -388,9 +420,9 @@ - - - + + @@ -400,37 +432,720 @@ - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
[JBoss-dev] CVS update: jnp build.sh build.xml
User: user57 Date: 01/09/03 22:08:08 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 jnp/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jnp/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:11 1.6 +++ build.sh 2001/09/04 05:08:08 1.7 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.6 2001/08/28 04:53:11 user57 Exp $ +# $Id: build.sh,v 1.7 2001/09/04 05:08:08 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.6 +9 -44 jnp/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jnp/build.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.xml 2001/08/27 09:01:36 1.5 +++ build.xml 2001/09/04 05:08:08 1.6 @@ -10,9 +10,9 @@ - + - + @@ -163,7 +163,7 @@ - + @@ -182,27 +182,9 @@ + - - - - - - - - - - - - - - - - - - - @@ -374,35 +356,18 @@ - - - - - - - - - - - - - - - - - - - - + + + + + - https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx build.sh build.xml
User: user57 Date: 01/09/03 22:08:07 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 jbosscx/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jbosscx/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:08 1.6 +++ build.sh 2001/09/04 05:08:07 1.7 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.6 2001/08/28 04:53:08 user57 Exp $ +# $Id: build.sh,v 1.7 2001/09/04 05:08:07 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.8 +8 -38 jbosscx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosscx/build.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- build.xml 2001/09/03 02:14:45 1.7 +++ build.xml 2001/09/04 05:08:07 1.8 @@ -10,9 +10,9 @@ - + - + @@ -212,27 +212,9 @@ + - - - - - - - - - - - - - - - - - - - @@ -373,27 +355,18 @@ - - - - - - - - - - - - + + + + + - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual build.sh build.xml
User: user57 Date: 01/09/03 22:08:07 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.8 +4 -1 manual/build.sh Index: build.sh === RCS file: /cvsroot/jboss/manual/build.sh,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- build.sh 2001/08/28 04:53:08 1.7 +++ build.sh 2001/09/04 05:08:07 1.8 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.7 2001/08/28 04:53:08 user57 Exp $ +# $Id: build.sh,v 1.8 2001/09/04 05:08:07 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.19 +9 -30 manual/build.xml Index: build.xml === RCS file: /cvsroot/jboss/manual/build.xml,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- build.xml 2001/09/03 00:04:40 1.18 +++ build.xml 2001/09/04 05:08:07 1.19 @@ -10,9 +10,9 @@ - + - + @@ -79,7 +79,7 @@ - +< @@ -170,26 +170,7 @@ - - - - - - - - - - - - - - - - - - - - + @@ -408,20 +389,18 @@ - - - + + + - - + + - https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss/etc local.properties-example
User: user57 Date: 01/09/03 22:08:07 Modified:jboss/etc local.properties-example Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.3 +4 -0 build/jboss/etc/local.properties-example Index: local.properties-example === RCS file: /cvsroot/jboss/build/jboss/etc/local.properties-example,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- local.properties-example 2001/08/26 07:00:29 1.2 +++ local.properties-example 2001/09/04 05:08:06 1.3 @@ -24,3 +24,7 @@ ### Disable generation of Javadocs ### javadoc-generated-already=true + +### Enable verbose build output ### + +# build.verbose=true ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: admin build.sh build.xml
User: user57 Date: 01/09/03 22:08:06 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 admin/build.sh Index: build.sh === RCS file: /cvsroot/jboss/admin/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:07 1.6 +++ build.sh 2001/09/04 05:08:06 1.7 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.6 2001/08/28 04:53:07 user57 Exp $ +# $Id: build.sh,v 1.7 2001/09/04 05:08:06 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.6 +34 -83admin/build.xml Index: build.xml === RCS file: /cvsroot/jboss/admin/build.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.xml 2001/08/27 09:01:35 1.5 +++ build.xml 2001/09/04 05:08:06 1.6 @@ -10,9 +10,9 @@ - + - + @@ -195,7 +195,7 @@ - + @@ -225,33 +225,9 @@ + - - - - - - - - - - - - - - - - - - - - - - - - - @@ -477,68 +453,46 @@ - - - - - - - - - - - - - - - - - - - - - - + + + + + + - - - - - - - - - - + + + - - - - - + + + + - + + - - - - - - - - + + + + + + + + @@ -627,8 +581,5 @@ - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx build.sh build.xml
User: user57 Date: 01/09/03 22:08:07 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 jbossmx/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jbossmx/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:07 1.6 +++ build.sh 2001/09/04 05:08:07 1.7 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.6 2001/08/28 04:53:07 user57 Exp $ +# $Id: build.sh,v 1.7 2001/09/04 05:08:07 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.7 +8 -54 jbossmx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbossmx/build.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.xml 2001/08/27 09:01:36 1.6 +++ build.xml 2001/09/04 05:08:07 1.7 @@ -10,9 +10,9 @@ - + - + @@ -228,7 +228,7 @@ - + @@ -249,25 +249,8 @@ + - - - - - - - - - - - - - - - - - - @@ -446,44 +429,18 @@ - - - - - - - - - - - - - - - - - - - - + + + - - - - - - - - + - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/varia build.sh build.xml
User: user57 Date: 01/09/03 22:08:08 Modified:variabuild.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 contrib/varia/build.sh Index: build.sh === RCS file: /cvsroot/jboss/contrib/varia/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:11 1.6 +++ build.sh 2001/09/04 05:08:08 1.7 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.6 2001/08/28 04:53:11 user57 Exp $ +# $Id: build.sh,v 1.7 2001/09/04 05:08:08 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.7 +10 -74contrib/varia/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/varia/build.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.xml 2001/08/27 09:01:37 1.6 +++ build.xml 2001/09/04 05:08:08 1.7 @@ -10,9 +10,9 @@ - + - + @@ -267,7 +267,7 @@ - + @@ -288,27 +288,9 @@ + - - - - - - - - - - - - - - - - - - - @@ -478,63 +460,20 @@ - - - - - - - - - - - - - + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest build.sh build.xml
User: user57 Date: 01/09/03 22:08:09 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.5 +4 -1 jbosstest/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jbosstest/build.sh,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- build.sh 2001/08/28 04:53:12 1.4 +++ build.sh 2001/09/04 05:08:09 1.5 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.4 2001/08/28 04:53:12 user57 Exp $ +# $Id: build.sh,v 1.5 2001/09/04 05:08:09 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.10 +11 -27jbosstest/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/build.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- build.xml 2001/09/03 20:21:34 1.9 +++ build.xml 2001/09/04 05:08:09 1.10 @@ -10,9 +10,9 @@ - + - + @@ -281,27 +281,9 @@ + - - - - - - - - - - - - - - - - - - - @@ -1284,13 +1266,18 @@ - + + + + + + + + - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.sh build.xml
User: user57 Date: 01/09/03 22:08:09 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 jboss/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jboss/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:11 1.6 +++ build.sh 2001/09/04 05:08:08 1.7 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.6 2001/08/28 04:53:11 user57 Exp $ +# $Id: build.sh,v 1.7 2001/09/04 05:08:08 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.23 +9 -210jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/build.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- build.xml 2001/09/02 19:29:38 1.22 +++ build.xml 2001/09/04 05:08:09 1.23 @@ -10,9 +10,9 @@ - + - + @@ -285,27 +285,9 @@ + - - - - - - - - - - - - - - - - - - - @@ -748,200 +730,20 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx build.sh build.xml
User: user57 Date: 01/09/03 22:08:08 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 jbosssx/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jbosssx/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:11 1.6 +++ build.sh 2001/09/04 05:08:08 1.7 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.6 2001/08/28 04:53:11 user57 Exp $ +# $Id: build.sh,v 1.7 2001/09/04 05:08:08 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.7 +12 -75jbosssx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosssx/build.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.xml 2001/08/27 09:01:37 1.6 +++ build.xml 2001/09/04 05:08:08 1.7 @@ -10,9 +10,9 @@ - + - + @@ -239,6 +239,7 @@ + @@ -257,27 +258,9 @@ + - - - - - - - - - - - - - - - - - - - @@ -317,10 +300,6 @@ - - @@ -488,59 +467,20 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + - - - - - - - - - - - - - - - - - - - - + + - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq build.sh build.xml
User: user57 Date: 01/09/03 22:08:08 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 jbossmq/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jbossmq/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:11 1.6 +++ build.sh 2001/09/04 05:08:08 1.7 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.6 2001/08/28 04:53:11 user57 Exp $ +# $Id: build.sh,v 1.7 2001/09/04 05:08:08 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.12 +9 -85 jbossmq/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbossmq/build.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- build.xml 2001/08/27 09:01:36 1.11 +++ build.xml 2001/09/04 05:08:08 1.12 @@ -10,9 +10,9 @@ - + - + @@ -237,7 +237,7 @@ - + @@ -270,27 +270,9 @@ + - - - - - - - - - - - - - - - - - - - @@ -538,75 +520,20 @@ - - - - - - - - - - - - - - - - - - - - - - - + + + - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool build.sh build.xml
User: user57 Date: 01/09/03 22:08:08 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 jbosspool/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jbosspool/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:11 1.6 +++ build.sh 2001/09/04 05:08:08 1.7 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.6 2001/08/28 04:53:11 user57 Exp $ +# $Id: build.sh,v 1.7 2001/09/04 05:08:08 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.9 +9 -47 jbosspool/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosspool/build.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- build.xml 2001/08/27 09:01:37 1.8 +++ build.xml 2001/09/04 05:08:08 1.9 @@ -10,9 +10,9 @@ - + - + @@ -203,7 +203,7 @@ - + @@ -237,27 +237,9 @@ + - - - - - - - - - - - - - - - - - - - @@ -452,35 +434,18 @@ - - - - - - - - - - - - - - - - - - - - + + + + + - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee build.sh build.xml
User: user57 Date: 01/09/03 22:08:07 Modified:.build.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 jboss-j2ee/build.sh Index: build.sh === RCS file: /cvsroot/jboss/jboss-j2ee/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:08 1.6 +++ build.sh 2001/09/04 05:08:07 1.7 @@ -8,12 +8,15 @@ ## ## ### == ### -# $Id: build.sh,v 1.6 2001/08/28 04:53:08 user57 Exp $ +# $Id: build.sh,v 1.7 2001/09/04 05:08:07 user57 Exp $ PROGNAME=`basename $0` DIRNAME=`dirname $0` GREP="grep" ROOT="/" + +# Ignore user's ANT_HOME if it is set +ANT_HOME="" # the default search path for ant ANT_SEARCH_PATH="\ 1.9 +9 -47 jboss-j2ee/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss-j2ee/build.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- build.xml 2001/08/27 09:01:36 1.8 +++ build.xml 2001/09/04 05:08:07 1.9 @@ -10,9 +10,9 @@ - + - + @@ -154,7 +154,7 @@ - + @@ -168,26 +168,8 @@ + - - - - - - - - - - - - - - - - - - - @@ -310,35 +292,18 @@ - - - - - - - - - - - - - - - - - - - - + + + + + - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty build.sh build.xml
User: user57 Date: 01/09/03 22:08:08 Modified:jettybuild.sh build.xml Log: o module release is now a control module pull o removed min targets Revision ChangesPath 1.7 +4 -1 contrib/jetty/build.sh Index: build.sh === RCS file: /cvsroot/jboss/contrib/jetty/build.sh,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- build.sh 2001/08/28 04:53:11 1.6 +++ build.sh 2001/09/04 05:08:08 1.7 @@ -15,6 +15,9 @@ GREP="grep" ROOT="/" +# Ignore user's ANT_HOME if it is set +ANT_HOME="" + # the default search path for ant ANT_SEARCH_PATH="\ tools 1.6 +8 -59 contrib/jetty/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jetty/build.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.xml 2001/08/27 09:01:37 1.5 +++ build.xml 2001/09/04 05:08:08 1.6 @@ -12,7 +12,7 @@ - + @@ -224,27 +224,9 @@ + - - - - - - - - - - - - - - - - - - - @@ -371,50 +353,20 @@ - - - - - - - - - - - - - - - - - - - - - - + + + + + - - - - - - - - - - - - - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RH startup and JBossMQ
Hi all, I think we have a problem with RH and jbossmq. With the advent of Marc's changes the order in which the mbeans are initialised and started seems to have changed. Previously all mbeans listed in the jboss.jcml file where initialised before any where started. This meant that when the Persistence Manager was started the queues had already been initialised and the PM knew which queues it had to try to restore from persistant backup storage. Now it seems that each mbean is initialised and then started before the next is initialised. They are still processed in order (now defined by jboss-services.xml) but each one is started before the next is initialised. If this is the case (and I'm pretty sure it is) then it will break the restoration processes in jbossmq. My question then is could we change the startup process back to how it was before or do we change the jbossmq restoration to work with the new startup process. This change to jbossmq may be quite tricky (its hard to tell until I have a good look at it) and I am not that keen to do it. However if RH startup process is the result of a fundamental change in how mbeans are loaded and managed then jbossmq will just have to be fixed. Cheers David PS: I have also had issues with the security mechanisms in RH. The problem is that currently it ignores the server.policy file, which usually is fine since no SecurityManager is installed. However we have a custom service we are writing that uses RMI and hence requires a SecurityManager. Unfortunately as soon as we install one because the server.policy file has not been loaded there are all sorts of access restrictions that come into play that effectively stuff the whole server. I tried to fix this by using the SecurityPolicyService mbean to implement a security policy but it uses an xml policy file and I can't seem to get the right syntax for it. I took an educated guess (based on one in the test directory of the security module) but it doesn't seem to work. If anyone has any ideas (Scott this is your area, right?) then I would appreciate a helping hand. What I am basically asking for is a pointer to the correct syntax for the xml file or how to run jboss using a convential policy file (like server.policy). (xml file I am using for policy) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty and Rabbit Hole
A JNDI env for each service along with well known entries for resources
like JMS and the local filesystem seems like the best approach. I don't see
locating
the JBoss server filesystem as any different than locating a JMS queue:
File root = (File) new InitialContext().lookup("jboss/filesystem");
with an org.jboss.naming.Namespace interface for defining the well known
resource
paths in JNDI.
public interface Namespace
{
public static final String LOCAL_FILESYTEM = "jboss/filesystem";
public static final String JMS_QUEUE_CONN_FACTORY = "ConnectionFactory";
public static final String JMS_TOPIC_CONN_FACTORY = "ConnectionFactory";
public static final String JMS_QUEUES = "queue";
...
}
- Original Message -
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: "marc fleury" <[EMAIL PROTECTED]>
Cc: "Julian Gosnell" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2001 7:57 PM
Subject: RE: [JBoss-dev] Jetty and Rabbit Hole
> > |If there was some sort of ServiceContext, passed into the service bean,
on
> > |init, then it could hold this information.
> >
> > h we want the party in front to incorporate as little from us as
> > possible. That means "no classes" so the current ContextClassLoader
> > integration is about as much "hoochy" we can take.
>
> Is this really the case? How about using an Adapter to take the
ServiceBean
> (with ServiceContext) and wrap something that does not implement the
correct
> interface.
>
> This allows us to provide a clean way to pass data into the service, and
> still support services which don't know anything about the service
> interface.
>
> In those cases the adapter could read the path name from the
ServiceContext
> and pass it on as a property or a call to the object that cares.
>
> Short of force everyone to use resources I can't think of a better way to
> handle this (at the moment). I think that there will almost always have
to
> be some adapter layer between jboss and thirdparty services, we should
plan
> on that from the start.
>
> > The question is how do they find their files, get with the problem.
>
> I know, that is why I mentioned ServiceContext. It could provide
> getProperty() methods or something similar to expose configuration, as
well
> as future tx attributes and anything else we can think of.
>
> > |remeber long ago when I was talking about using a FileSystem
abstraction...
> > |and remeber the bit about defining local resources required by a
service in
> > |the service deployment descriptor, these go hand in hand. Top it off
with
> > |the ServiceContext, and you have all the means to support this type of
> > |per-service configuration.
> >
> > Who provides the "FileSystem" abstraction class? if it is us there is
> > little chance this will fly. Are we going to ask everyone to not use
> > "java.io.File" but our stuff instead if they want to integrate with us
one
> > day? That is not realistic.
>
> So the goal is to provide an architecture, where company x, who knows zero
> about JBoss and its design, to drop in a service and except it to work?
> That is fine, I was thinking a different route... which could be the same
as
> the above, it just will have to use an adapter to bridge the gap.
>
> I was thinking of the FileSystem stuff from NetBeans, but never really
> looked into it much.
>
> > I think we can package a filesystem in a SAR (I am even willing to
rename it
> > to your original name since it was you who first talked). And expand
that
> > in the host FS but when you want to get a pointer to your file (a
> > programmatic one) all we need is a root.
>
> Right, so were does the service get that from? Properties? Custom bean
> call? Reading a resource, which is a properties file, pulling down from
> jndi?
>
> Hrm... that might work. Give each service its own jndi context (like
ejb's
> do)... but that puts us back into the bag of having that service know
about
> that JBoss'ism.
>
> I don't think there is a better way than to design in adapter usage from
the
> start. They will be simple classes, nothing too hard to code.
>
> I could see that one 3rd party service might want a resource, another a
> file, another some JNDI url. Why not support them add by abstracting the
> parts we care about and let them plug in a class to do the rest?
>
> --jason
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty and Rabbit Hole
OK I'll give a little bit more detail about what I'm talking about. But first I'll describe what I think the JBoss mechanism is (which I have only looked at briefly), so you guys can correct me if I'm wrong. I understand that you have a configuration agent that observes JMX registrations and when it see's an object that it knows about it configures components with XML that really is just a series of JMX set calls. After this, you assume a start() method exists and call that. Jetty exposes the majority of it's configuration API via JMX with the approximate hierarchy of MBeans: HttpServerMBean + 0 or more HttpListenerMBeans + 0 or more HandlerContextMBeans + 0 or 1 LogSinkMBeans Each of these MBeans implements the LifeCycleMBean api (start/stop) The ListenerMBeans can also be ThreadedServer and/or SocketListener MBeans The HandlerContextMBean may be a WebApplicationMBean The LogSinkMBean may be a OutputStreamMBean or something else In a JMX environment - two main approaches can be taken to configure this bunch of MBeans. Consider the LogSink within the HttpServer - which is used for the request log. The first is to do just set's on the HttpServer - ie call the setLogSink method passing it a complex object. We achieve this in XML as follows /_mm_dd.request.log 90 true false So a configured LogSink is passed to the JMX setLogSink on HttpServer The second approach is to arrange for a default LogSink to be added to the HttpServer - whose JMX name will be derived from the JMX name of the HTTP server. The configuration agent will spot the registration of the LogSinkMBean and configure that in the normal way (calling sets etc.) The problem with both of the above appraches - is who calls start? In Jetty - everything implements the lifecycle interface, so it has start and stop methods. If you call start on HttpServer, it calls start on all the components within it. So you don't really want a config agent calling start on every component that it see's registered along the way Another problem is sometimes you may need to be a little more procedural than just a straight set. For example in the Jetty demo config, we call getServletHandler in order to set some specific attribute on it: / /servlets/ /servlet/* FALSE OK - looking at the above, it is all pretty incoherent and I don't expect anybody to understand it.Unless you know Jetty. So I will try from a different angle. I have found it very valuable in another project to have a JMX configuration agent that work very similar to the one I've assumed in JBoss, but slightly more powerful. It supports Set, Get, Call and New tags to be run like a script to configure newly registered JMX objects. The following example configures the JMX config agent to trigger on the registration of the com.mortbay.Jetty:name=Jetty,Server=0 MBean. Once triggered it: + Sets the statsOn attribute of the HttpServer. + does a Call to addListener with a complex object arg to configure the HTTP port. + Does a Set of logsink with a complex object arg. + Calls start The XML for this is: FALSE 5 255 6 6 /_mm_dd.request.log 90 true Note that no webapplication is configured by this (it could be) as I expect the normal EAR deployer will do that. This just configures the things that are not included in an EAR. An alternative way to write this configuration would be to use the listeners and logSinks own MBeans to do the configuration: FALSE 5 255 6 6 /_mm_dd.request.log 90 true But this second style of config assumes that the config agent has triggered and configured the SocketListener and WriterLogSink during the configuration of HttpServer - thus they will be configured before the start call on the HttpServer I guess the point that I am trying to make is that some components such as Listeners and log sinks can very easily be configured with a sequence of sets. But something as complex as a HTTP server and servlet container, needs a little more than a sequence of sets. So either you config agent needs to support Set, Call, New tags!Or something else must coordinate the creation of all the component MBeans that can be configured with just a simple sequence of Sets ~(but who calls start() would still be a problem). MMm I don't think this describes what I'm talking about much better? So if you are confused - it is my fault. I'll try to have more of a look at the JBoss stuff and make my suggestions using your XML as examples rather than mine. marc fleury wrote: > |It should not be too much work to do away with t
RE: [JBoss-dev] Jetty and Rabbit Hole
> |If there was some sort of ServiceContext, passed into the service bean, on > |init, then it could hold this information. > > h we want the party in front to incorporate as little from us as > possible. That means "no classes" so the current ContextClassLoader > integration is about as much "hoochy" we can take. Is this really the case? How about using an Adapter to take the ServiceBean (with ServiceContext) and wrap something that does not implement the correct interface. This allows us to provide a clean way to pass data into the service, and still support services which don't know anything about the service interface. In those cases the adapter could read the path name from the ServiceContext and pass it on as a property or a call to the object that cares. Short of force everyone to use resources I can't think of a better way to handle this (at the moment). I think that there will almost always have to be some adapter layer between jboss and thirdparty services, we should plan on that from the start. > The question is how do they find their files, get with the problem. I know, that is why I mentioned ServiceContext. It could provide getProperty() methods or something similar to expose configuration, as well as future tx attributes and anything else we can think of. > |remeber long ago when I was talking about using a FileSystem abstraction... > |and remeber the bit about defining local resources required by a service in > |the service deployment descriptor, these go hand in hand. Top it off with > |the ServiceContext, and you have all the means to support this type of > |per-service configuration. > > Who provides the "FileSystem" abstraction class? if it is us there is > little chance this will fly. Are we going to ask everyone to not use > "java.io.File" but our stuff instead if they want to integrate with us one > day? That is not realistic. So the goal is to provide an architecture, where company x, who knows zero about JBoss and its design, to drop in a service and except it to work? That is fine, I was thinking a different route... which could be the same as the above, it just will have to use an adapter to bridge the gap. I was thinking of the FileSystem stuff from NetBeans, but never really looked into it much. > I think we can package a filesystem in a SAR (I am even willing to rename it > to your original name since it was you who first talked). And expand that > in the host FS but when you want to get a pointer to your file (a > programmatic one) all we need is a root. Right, so were does the service get that from? Properties? Custom bean call? Reading a resource, which is a properties file, pulling down from jndi? Hrm... that might work. Give each service its own jndi context (like ejb's do)... but that puts us back into the bag of having that service know about that JBoss'ism. I don't think there is a better way than to design in adapter usage from the start. They will be simple classes, nothing too hard to code. I could see that one 3rd party service might want a resource, another a file, another some JNDI url. Why not support them add by abstracting the parts we care about and let them plug in a class to do the rest? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty and Rabbit Hole
|> Then how do you reference these files? You mention referencing |the top of | |If there was some sort of ServiceContext, passed into the service bean, on |init, then it could hold this information. h we want the party in front to incorporate as little from us as possible. That means "no classes" so the current ContextClassLoader integration is about as much "hoochy" we can take. |Some legecy services will want files. Some services will only make sence |when working off of files. I can understand that the boot/loading system |should not be tied to files, but there is no reason why we should force |service writters to stop using files. | |Right? The question is how do they find their files, get with the problem. |> need to introduce a sar.xml that is a collection of the jcml |information and |> some self descripting stuff such as the name of the "sar" (in our case |> "jetty"). h | |remeber long ago when I was talking about using a FileSystem abstraction... |and remeber the bit about defining local resources required by a service in |the service deployment descriptor, these go hand in hand. Top it off with |the ServiceContext, and you have all the means to support this type of |per-service configuration. Who provides the "FileSystem" abstraction class? if it is us there is little chance this will fly. Are we going to ask everyone to not use "java.io.File" but our stuff instead if they want to integrate with us one day? That is not realistic. I think we can package a filesystem in a SAR (I am even willing to rename it to your original name since it was you who first talked). And expand that in the host FS but when you want to get a pointer to your file (a programmatic one) all we need is a root. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/rollinglogged SpyTxLog.java SpyMessageLog.java PersistenceManager.java IntegrityLog.java
User: dmaplesden
Date: 01/09/03 19:22:29
Modified:src/main/org/jboss/mq/pm/rollinglogged SpyTxLog.java
SpyMessageLog.java PersistenceManager.java
IntegrityLog.java
Log:
Changed initialisation to use "jboss.system.home" as file anchor.
Revision ChangesPath
1.3 +5 -5 jbossmq/src/main/org/jboss/mq/pm/rollinglogged/SpyTxLog.java
Index: SpyTxLog.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/rollinglogged/SpyTxLog.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SpyTxLog.java 2001/08/17 03:04:05 1.2
+++ SpyTxLog.java 2001/09/04 02:22:29 1.3
@@ -6,7 +6,7 @@
*/
package org.jboss.mq.pm.rollinglogged;
import java.io.IOException;
-
+import java.io.File;
import java.io.Serializable;
import javax.jms.JMSException;
@@ -18,7 +18,7 @@
*
* @createdAugust 16, 2001
* @author:Hiram Chirino ([EMAIL PROTECTED])
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
public class SpyTxLog {
@@ -32,12 +32,12 @@
/
// Constructors
/
- public SpyTxLog( String fileName )
+ public SpyTxLog( File file )
throws JMSException {
try {
- transactionLog = new IntegrityLog( fileName );
+ transactionLog = new IntegrityLog( file );
} catch ( IOException e ) {
- throwJMSException( "Could not open the queue's tranaction log: " +
fileName, e );
+ throwJMSException( "Could not open the queue's tranaction log: " +
file.getAbsolutePath(), e );
}
}
1.3 +5 -4
jbossmq/src/main/org/jboss/mq/pm/rollinglogged/SpyMessageLog.java
Index: SpyMessageLog.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/rollinglogged/SpyMessageLog.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SpyMessageLog.java2001/08/17 03:04:05 1.2
+++ SpyMessageLog.java2001/09/04 02:22:29 1.3
@@ -8,6 +8,7 @@
import java.io.IOException;
import java.io.Serializable;
+import java.io.File;
import javax.jms.JMSException;
import org.jboss.mq.SpyJMSException;
@@ -20,7 +21,7 @@
*
* @createdAugust 16, 2001
* @author:Hiram Chirino ([EMAIL PROTECTED])
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
public class SpyMessageLog {
@@ -32,12 +33,12 @@
/
// Constructor
/
- public SpyMessageLog( String fileName )
+ public SpyMessageLog( File file )
throws JMSException {
try {
- transactionLog = new IntegrityLog( fileName );
+ transactionLog = new IntegrityLog( file );
} catch ( IOException e ) {
- throwJMSException( "Could not open the queue's tranaction log: " +
fileName, e );
+ throwJMSException( "Could not open the queue's tranaction log: " +
file.getAbsolutePath(), e );
}
}
1.6 +18 -19
jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- PersistenceManager.java 2001/09/01 03:01:00 1.5
+++ PersistenceManager.java 2001/09/04 02:22:29 1.6
@@ -6,6 +6,7 @@
*/
package org.jboss.mq.pm.rollinglogged;
+import java.io.File;
import java.net.URL;
import java.util.HashMap;
import java.util.HashSet;
@@ -13,7 +14,7 @@
import java.util.LinkedList;
import java.util.TreeSet;
import javax.jms.JMSException;
-import javax.management.*;
+import javax.management.ObjectName;
import javax.naming.InitialContext;
import org.jboss.mq.ConnectionToken;
@@ -31,7 +32,7 @@
* This class manages all persistence related services.
*
* @author David Maplesden ([EMAIL PROTECTED])
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
org.jboss.mq.pm.PersistenceManager, PersistenceManagerMBean
{
@@ -57,10 +58,8 @@
// Maps transactionIds to txInfos
HashMap transToTxLogs = new HashMap();
-
-
// The directory where persistence data should be stored
- URL data
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file PersistenceManager.java MessageLog.java
User: dmaplesden
Date: 01/09/03 19:22:42
Modified:src/main/org/jboss/mq/pm/file PersistenceManager.java
MessageLog.java
Log:
Changed initialisation to use "jboss.system.home" as file anchor.
Revision ChangesPath
1.6 +6 -9 jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- PersistenceManager.java 2001/09/02 21:33:21 1.5
+++ PersistenceManager.java 2001/09/04 02:22:42 1.6
@@ -35,7 +35,7 @@
* persistence.
*
* @author Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager
{
@@ -47,7 +47,6 @@
// The directory where persistence data should be stored
String dataDirectory;
- URL dataDirURL;
File dataDirFile;
//tx manager
org.jboss.mq.pm.TxManager txManager;
@@ -114,9 +113,8 @@
*/
public void initService() throws Exception
{
- URL configFile = getClass().getClassLoader().getResource("jboss.jcml");
- dataDirURL = new URL(configFile, dataDirectory);
- dataDirFile = new File(dataDirURL.getFile());
+ File jbossHome = new File(System.getProperty("jboss.system.home"));
+ dataDirFile = new File(jbossHome, dataDirectory);
JMSServer server = (JMSServer)getServer().invoke(new
ObjectName(org.jboss.mq.server.JBossMQServiceMBean.OBJECT_NAME), "getJMSServer", new
Object[]{}, new String[]{});
server.setPersistenceManager(this);
}
@@ -223,8 +221,8 @@
{
try
{
- URL logDir = new URL(dataDirURL, dest.toString());
- MessageLog log = new MessageLog(logDir.getFile());
+ File logDir = new File(dataDirFile, dest.toString());
+ MessageLog log = new MessageLog(logDir);
LogInfo info = new LogInfo(log, dest);
synchronized (messageLogs)
{
@@ -253,8 +251,7 @@
{
try
{
- URL logDir = new URL(dataDirURL, dest.toString());
- java.io.File file = new java.io.File(logDir.getFile());
+ File file = new File(dataDirFile, dest.toString());
LogInfo logInfo;
synchronized (messageLogs)
{
1.3 +4 -4 jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java
Index: MessageLog.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MessageLog.java 2001/08/17 03:04:05 1.2
+++ MessageLog.java 2001/09/04 02:22:42 1.3
@@ -24,7 +24,7 @@
*
* @createdAugust 16, 2001
* @author:Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
public class MessageLog {
@@ -47,10 +47,10 @@
/
// Constructor
/
- public MessageLog( String fileName )
+ public MessageLog( File file )
throws JMSException {
- queueName = new File( fileName );
- queueName.mkdir();
+ queueName = file;
+ queueName.mkdirs();
}
/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty and Rabbit Hole
> it is jason that keeps on calling it SAR... I called it JSR :) and there is > an example running in the standard 3.0 CVS. (do a grep on jsr). I have no > problem recalling it .SAR. JSR is confusing, since it is also used for those jcp papers. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty and Rabbit Hole
|> It looks like you/someone have made Jetty into a 'plugin' - thanks. I |> was expecting this to be the .SAR archive that I keep seeing mentioned |> here and there but I've grepped all over the place and can't find |> any mention of them - what's the score here ? | |Like I said before, I have not really looked at the changes Marc |commited in |much detail yet. I can't really say more than that at the moment. it is called a .JSR right now. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/lock/test Main.java
User: patriot1burke
Date: 01/09/03 18:57:01
Modified:src/main/org/jboss/test/lock/test Tag: Branch_2_4 Main.java
Log:
backmerge
Revision ChangesPath
No revision
No revision
1.3.2.3 +127 -69 jbosstest/src/main/org/jboss/test/lock/test/Main.java
Index: Main.java
===
RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/lock/test/Main.java,v
retrieving revision 1.3.2.2
retrieving revision 1.3.2.3
diff -u -r1.3.2.2 -r1.3.2.3
--- Main.java 2001/07/18 06:15:32 1.3.2.2
+++ Main.java 2001/09/04 01:57:01 1.3.2.3
@@ -1,69 +1,127 @@
-package org.jboss.test.lock.test;
-
-import junit.framework.Test;
-import junit.framework.TestCase;
-import junit.framework.TestSuite;
-
-import org.jboss.test.util.Deploy;
-
-public class Main
- extends TestCase
-{
- public Main(String name) {
- super(name);
- }
-
- /**
-* Setup the test suite.
-*/
- public static Test suite() {
- TestSuite suite = new TestSuite();
-
- // add a test case to deploy our support applications
- String filename = "locktest.jar";
- suite.addTest(new Deploy.Deployer(filename));
-
- suite.addTest(new TestSuite(Entity_Option_A_Test.class));
- suite.addTest(new TestSuite(Entity_Option_B_Test.class));
- suite.addTest(new TestSuite(Entity_Option_C_Test.class));
- suite.addTest(new TestSuite(Entity_Option_D_Test.class));
-
- // add a test case to undeploy our support applications
- suite.addTest(new Deploy.Undeployer(filename));
-
- return suite;
- }
-
- public static class Entity_Option_A_Test
- extends EnterpriseEntityTest
- {
- public Entity_Option_A_Test(String name) {
- super(name, "EnterpriseEntity_A");
- }
- }
-
- public static class Entity_Option_B_Test
- extends EnterpriseEntityTest
- {
- public Entity_Option_B_Test(String name) {
- super(name, "EnterpriseEntity_B");
- }
- }
-
- public static class Entity_Option_C_Test
- extends EnterpriseEntityTest
- {
- public Entity_Option_C_Test(String name) {
- super(name, "EnterpriseEntity_C");
- }
- }
-
- public static class Entity_Option_D_Test
- extends EnterpriseEntityTest
- {
- public Entity_Option_D_Test(String name) {
- super(name, "EnterpriseEntity_D");
- }
- }
-}
-
+package org.jboss.test.lock.test;
+
+import junit.framework.Test;
+import junit.framework.TestCase;
+import junit.framework.TestSuite;
+
+import org.jboss.test.util.Deploy;
+
+public class Main
+ extends TestCase
+{
+ public Main(String name) {
+ super(name);
+ }
+
+ /**
+* Setup the test suite.
+*/
+ public static Test suite() {
+ TestSuite suite = new TestSuite();
+
+ // add a test case to deploy our support applications
+ String filename = "locktest.jar";
+ suite.addTest(new Deploy.Deployer(filename));
+
+ suite.addTest(new TestSuite(Entity_Option_A_Test.class));
+ suite.addTest(new TestSuite(Entity_Option_B_Test.class));
+ suite.addTest(new TestSuite(Entity_Option_C_Test.class));
+ suite.addTest(new TestSuite(Entity_Option_D_Test.class));
+
+ // Test ejb.plugins.lock.QueuedPessimisticEJBLock
+ suite.addTest(new TestSuite(Entity_Option_A_Queued_Test.class));
+ suite.addTest(new TestSuite(Entity_Option_B_Queued_Test.class));
+ suite.addTest(new TestSuite(Entity_Option_C_Queued_Test.class));
+ suite.addTest(new TestSuite(Entity_Option_D_Queued_Test.class));
+
+ // suite.addTest(new TestSuite(Entity_Option_C_Multi_Test.class));
+
+ // add a test case to undeploy our support applications
+ suite.addTest(new Deploy.Undeployer(filename));
+
+ return suite;
+ }
+
+ public static class Entity_Option_A_Test
+ extends EnterpriseEntityTest
+ {
+ public Entity_Option_A_Test(String name) {
+ super(name, "EnterpriseEntity_A");
+ }
+ }
+
+ public static class Entity_Option_B_Test
+ extends EnterpriseEntityTest
+ {
+ public Entity_Option_B_Test(String name) {
+ super(name, "EnterpriseEntity_B");
+ }
+ }
+
+ public static class Entity_Option_C_Test
+ extends EnterpriseEntityTest
+ {
+ public Entity_Option_C_Test(String name) {
+ super(name, "EnterpriseEntity_C");
+ }
+ }
+
+ public static class Entity_Option_D_Test
+ extends EnterpriseEntityTest
+ {
+ public Entity_Option_D_Test(String name) {
+ super(name, "EnterpriseEnt
[JBoss-dev] CVS update: jbosstest/src/resources/lock/META-INF jboss.xml ejb-jar.xml
User: patriot1burke Date: 01/09/03 18:56:34 Modified:src/resources/lock/META-INF Tag: Branch_2_4 jboss.xml ejb-jar.xml Log: backmerge Revision ChangesPath No revision No revision 1.1.4.2 +297 -0jbosstest/src/resources/lock/META-INF/jboss.xml Index: jboss.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/lock/META-INF/jboss.xml,v retrieving revision 1.1.4.1 retrieving revision 1.1.4.2 diff -u -r1.1.4.1 -r1.1.4.2 --- jboss.xml 2001/07/18 06:14:54 1.1.4.1 +++ jboss.xml 2001/09/04 01:56:34 1.1.4.2 @@ -13,6 +13,7 @@ org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor + org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor @@ -20,6 +21,7 @@ org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.jaws.JAWSPersistenceManager org.jboss.tm.TxManager + org.jboss.ejb.plugins.lock.SimplePessimisticEJBLock True @@ -53,6 +55,7 @@ org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor + org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor @@ -60,6 +63,7 @@ org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.jaws.JAWSPersistenceManager org.jboss.tm.TxManager + org.jboss.ejb.plugins.lock.SimplePessimisticEJBLock True @@ -93,6 +97,7 @@ org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor + org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor @@ -100,6 +105,7 @@ org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.jaws.JAWSPersistenceManager org.jboss.tm.TxManager + org.jboss.ejb.plugins.lock.SimplePessimisticEJBLock True @@ -133,6 +139,7 @@ org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor + org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor @@ -140,6 +147,7 @@ org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.jaws.JAWSPersistenceManager org.jboss.tm.TxManager + org.jboss.ejb.plugins.lock.SimplePessimisticEJBLock True @@ -163,6 +171,259 @@ D + + EntityBean_A_Queued + false + org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker + + org.jboss.ejb.plugins.LogInterceptor + org.jboss.ejb.plugins.SecurityInterceptor + org.jboss.ejb.plugins.TxInterceptorCMT + org.jboss.ejb.plugins.MetricsInterceptor + org.jboss.ejb.plugins.EntityLockInterceptor + org.jboss.ejb.plugins.EntityInstanceInterceptor + org.jboss.ejb.plugins.EntitySynchronizationInterceptor + + org.jboss.ejb.plugins.EntityInstancePool + org.jboss.ejb.plugins.EntityInstanceCache + org.jboss.ejb.plugins.jaws.JAWSPersistenceManager + org.jboss.tm.TxManager + org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock + + + True + + + org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy + + 50 + 1000 + 300 + 600 + 400 + 60 + 1 + 0.75 + + + + 100 + 10 + + A + + + + EntityBean_B_Queued + false + org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker + + org.jboss.ejb.plugins.LogInterceptor + org.jboss.ejb.plugins.SecurityInterceptor + org.jboss.ejb.plugins.TxInterceptorCMT + org.jboss.ejb.plugins.MetricsInterceptor + org.jboss.ejb.plugins.EntityLockInterceptor + org.jboss.ejb.plugins.EntityInstanceInterceptor + org.jboss.ejb.plugins.EntitySynchronizationInterceptor + + org.jboss.ejb.plugins.EntityInstancePool + org.jboss.ejb.plugins.EntityInstanceCache + org.jboss.ejb.plugins.ja
RE: [JBoss-dev] Jetty and Rabbit Hole
it is jason that keeps on calling it SAR... I called it JSR :) and there is an example running in the standard 3.0 CVS. (do a grep on jsr). I have no problem recalling it .SAR. |I can't find a mention of any sars being deployed when I run up my copy of |JBoss-3.0 or find any in my output tree - should I just stick to the plugin |stuff for now ? under deploy/lib there should be a JSR file. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/bmp/META-INF jboss.xml
User: patriot1burke Date: 01/09/03 18:56:44 Modified:src/resources/bmp/META-INF Tag: Branch_2_4 jboss.xml Log: backmerge Revision ChangesPath No revision No revision 1.3.2.1 +2 -0 jbosstest/src/resources/bmp/META-INF/jboss.xml Index: jboss.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/bmp/META-INF/jboss.xml,v retrieving revision 1.3 retrieving revision 1.3.2.1 diff -u -r1.3 -r1.3.2.1 --- jboss.xml 2001/01/31 19:24:25 1.3 +++ jboss.xml 2001/09/04 01:56:44 1.3.2.1 @@ -11,6 +11,7 @@ org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor +org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor @@ -18,6 +19,7 @@ org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.BMPPersistenceManager org.jboss.tm.TxManager + org.jboss.ejb.plugins.lock.SimplePessimisticEJBLock True ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty and Rabbit Hole
|It should not be too much work to do away with the Jetty config files |all together and configure Jetty entirely via JMX. remember that what we are aiming for is filesystem independence. The fact that the configuration is in a file with XML is not the problem it is the fact that it is expected from a filesystem file that is problematic. JBoss loads its own configuration with jboss-services.xml (ex.jboss.jcml) and then bit by bit through XML snippets but the vehicle that delivers them to the main system is not important. Right now we use URL to create Element to pass to the core. The core is fed "Elements" where those elements come from today are URLs (file or http). JMX is the core that applies the changes how these changes get there is through URLClassLoaders. |For the cisco deployment, this is exactly what they do and they have |a JMX configuration architecture not unlike JBosses. The main difference |is that: | | + The lifecycle methods are not expected. (ie don't have to have a | start(); That's bad :( | + Arbitrary methods can be called as well as attributes set. Ok that I am interested in seeing, is that your scripting language? the XML semantic that recreates invocation? |So I think the aim of the integration, should be to remove all trace of |the jetty configuration mechanism from a standard jboss/jetty installation. The best would be to deliver that configuration either as part of sar that julian was talking about and we provide a way for you to find a fileSystem file (simplest is a file at teh top of the hierarchy that you look for) or even better URL based. |This may be simple? As jetty configuration for most purposes can be |reduced to a series of JMX sets followed by a call to start(). My That would nicely map to the ELement parser that is in there. |However they may be more complex configurations that require arbitrary |methods to be called on the jetty mbeans. These will have to be "arbitrary methods called" sounds strange. Give me an example of that. Do you mean something like the dynamic MBeans? |addressed either by changing the jetty mbeans so everything can be |done as sets, then start() - or improving the jboss mechanism so that |more arbitrary jmx calls can be made. be more precise, this doesn't tell me much, there are predefined MBeans (standard) and dynamic MBeans. We support standard MBeans right now, we could proxy the calls to "invoke" as well. |Again for the cisco deployment, I used a config file format very similar |to that of Jetty's XML - but which was able to call arbitrary JMX methods. If you are talking about your scripting language, I think it might be very interesting as we build more evolved frameworks for management. But I am curious to see what kind of scenarios you are talking about that require these files. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default standardjboss.xml
User: patriot1burke Date: 01/09/03 18:53:40 Modified:src/etc/conf/default Tag: Branch_2_4 standardjboss.xml Log: backmerge Revision ChangesPath No revision No revision 1.8.4.2 +8 -0 jboss/src/etc/conf/default/standardjboss.xml Index: standardjboss.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/standardjboss.xml,v retrieving revision 1.8.4.1 retrieving revision 1.8.4.2 diff -u -r1.8.4.1 -r1.8.4.2 --- standardjboss.xml 2001/06/22 22:52:30 1.8.4.1 +++ standardjboss.xml 2001/09/04 01:53:40 1.8.4.2 @@ -13,6 +13,7 @@ org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor + org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor @@ -20,6 +21,7 @@ org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.jaws.JAWSPersistenceManager org.jboss.tm.TxManager + org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock True @@ -53,12 +55,14 @@ org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor + org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor org.jboss.ejb.plugins.EntityInstancePool org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.jaws.JAWSPersistenceManager + org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock org.jboss.tm.TxManager @@ -233,6 +237,7 @@ org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor + org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor @@ -240,6 +245,7 @@ org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.BMPPersistenceManager org.jboss.tm.TxManager + org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock True @@ -273,6 +279,7 @@ org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor + org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor @@ -280,6 +287,7 @@ org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.BMPPersistenceManager org.jboss.tm.TxManager + org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock True ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ConfigurationMetaData.java BeanMetaData.java
User: patriot1burke
Date: 01/09/03 18:52:06
Modified:src/main/org/jboss/metadata Tag: Branch_2_4
ConfigurationMetaData.java BeanMetaData.java
Log:
backmerge
Revision ChangesPath
No revision
No revision
1.14.2.1 +7 -1 jboss/src/main/org/jboss/metadata/ConfigurationMetaData.java
Index: ConfigurationMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/metadata/ConfigurationMetaData.java,v
retrieving revision 1.14
retrieving revision 1.14.2.1
diff -u -r1.14 -r1.14.2.1
--- ConfigurationMetaData.java2001/06/13 04:52:33 1.14
+++ ConfigurationMetaData.java2001/09/04 01:52:06 1.14.2.1
@@ -13,7 +13,7 @@
/** The configuration information for an EJB container.
* @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.14.2.1 $
*/
public class ConfigurationMetaData extends MetaData {
@@ -37,6 +37,7 @@
public static final String[] commitOptionStrings = { "A", "B", "C", "D"};
// Attributes
+ private String lockClass = "org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock";
private String name;
private String containerInvoker;
private String instancePool;
@@ -83,6 +84,8 @@
public String getTransactionManager() { return transactionManager; }
+ public String getLockClass() {return lockClass;}
+
public Element getContainerInvokerConf() { return containerInvokerConf; }
public Element getContainerPoolConf() { return containerPoolConf; }
public Element getContainerCacheConf() { return containerCacheConf; }
@@ -121,6 +124,9 @@
// set the transaction manager
transactionManager = getElementContent(getOptionalChild(element,
"transaction-manager"), transactionManager);
+
+// set the lock class
+lockClass = getElementContent(getOptionalChild(element, "locking-policy"),
lockClass);
// set the security domain
securityDomain = getElementContent(getOptionalChild(element,
"security-domain"), securityDomain);
1.23.2.1 +397 -370 jboss/src/main/org/jboss/metadata/BeanMetaData.java
Index: BeanMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/BeanMetaData.java,v
retrieving revision 1.23
retrieving revision 1.23.2.1
diff -u -r1.23 -r1.23.2.1
--- BeanMetaData.java 2001/06/15 14:19:06 1.23
+++ BeanMetaData.java 2001/09/04 01:52:06 1.23.2.1
@@ -1,5 +1,5 @@
/*
- * JBoss, the OpenSource EJB server
+ * JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
@@ -13,7 +13,6 @@
import java.util.Set;
import java.util.Collection;
-
import org.w3c.dom.Element;
import org.w3c.dom.NodeList;
@@ -22,423 +21,451 @@
import org.jboss.security.NobodyPrincipal;
import org.jboss.security.SimplePrincipal;
-/** A common meta data class for the entity, message-driven and session beans.
- *
- * @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
- * @author Peter Antman ([EMAIL PROTECTED])
- * @author Daniel OConnor ([EMAIL PROTECTED])
- * @author [EMAIL PROTECTED]
- * @version $Revision: 1.23 $
+/**
+ * A common meta data class for the entity, message-driven and session beans.
+ *
+ * @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
+ * @author mailto:[EMAIL PROTECTED]";>Peter Antman.
+ * @author mailto:[EMAIL PROTECTED]";>Daniel OConnor
+ * @author mailto:[EMAIL PROTECTED]";>Scott Stark.
+ * @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
+ * @version $Revision: 1.23.2.1 $
*/
-public abstract class BeanMetaData extends MetaData {
-// Constants -
- public static final char SESSION_TYPE = 'S';
- public static final char ENTITY_TYPE = 'E';
- public static final char MDB_TYPE = 'M';
+public abstract class BeanMetaData
+ extends MetaData
+{
+ // Constants -
+
+ public static final char SESSION_TYPE = 'S';
+ public static final char ENTITY_TYPE = 'E';
+ public static final char MDB_TYPE = 'M';
- // Attributes
- private ApplicationMetaData application;
+ // Attributes
+ private ApplicationMetaData application;
- // from ejb-jar.xml
-/** The ejb-name element specifies an enterprise beans name. This name is
-
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/lock SimplePessimisticEJBLock.java QueuedPessimisticEJBLock.java package.html MethodOnlyEJBLock.java BeanLockSupport.java
User: patriot1burke Date: 01/09/03 18:50:26 Added: src/main/org/jboss/ejb/plugins/lock Tag: Branch_2_4 SimplePessimisticEJBLock.java QueuedPessimisticEJBLock.java package.html MethodOnlyEJBLock.java BeanLockSupport.java Log: backmerge Revision ChangesPath No revision No revision 1.5.4.1 +1 -1 jboss/src/main/org/jboss/ejb/plugins/lock/SimplePessimisticEJBLock.java Index: SimplePessimisticEJBLock.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/SimplePessimisticEJBLock.java,v retrieving revision 1.5 retrieving revision 1.5.4.1 diff -u -r1.5 -r1.5.4.1 --- SimplePessimisticEJBLock.java 2001/08/08 22:01:31 1.5 +++ SimplePessimisticEJBLock.java 2001/09/04 01:50:26 1.5.4.1 @@ -31,7 +31,7 @@ * * @author Bill Burke * @author Marc Fleury - * @version $Revision: 1.5 $ + * @version $Revision: 1.5.4.1 $ * * Revisions: * 2001/07/29: billb 1.3.4.1 +1 -1 jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java Index: QueuedPessimisticEJBLock.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java,v retrieving revision 1.3 retrieving revision 1.3.4.1 diff -u -r1.3 -r1.3.4.1 --- QueuedPessimisticEJBLock.java 2001/08/21 18:35:51 1.3 +++ QueuedPessimisticEJBLock.java 2001/09/04 01:50:26 1.3.4.1 @@ -42,7 +42,7 @@ * @author Marc Fleury * @author Bill Burke * - * @version $Revision: 1.3 $ + * @version $Revision: 1.3.4.1 $ * * Revisions: * 2001/08/03: billb 1.1.4.1 +1 -1 jboss/src/main/org/jboss/ejb/plugins/lock/package.html Index: package.html === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/package.html,v retrieving revision 1.1 retrieving revision 1.1.4.1 diff -u -r1.1 -r1.1.4.1 --- package.html 2001/08/11 03:44:41 1.1 +++ package.html 2001/09/04 01:50:26 1.1.4.1 @@ -16,7 +16,7 @@ Lesser General Public License for more details. --> - + 1.1.4.1 +1 -1 jboss/src/main/org/jboss/ejb/plugins/lock/MethodOnlyEJBLock.java Index: MethodOnlyEJBLock.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/MethodOnlyEJBLock.java,v retrieving revision 1.1 retrieving revision 1.1.4.1 diff -u -r1.1 -r1.1.4.1 --- MethodOnlyEJBLock.java2001/08/09 20:29:39 1.1 +++ MethodOnlyEJBLock.java2001/09/04 01:50:26 1.1.4.1 @@ -37,7 +37,7 @@ * * @author Bill Burke * - * @version $Revision: 1.1 $ + * @version $Revision: 1.1.4.1 $ * * Revisions: * 2001/08/08: billb 1.4.4.1 +1 -1 jboss/src/main/org/jboss/ejb/plugins/lock/BeanLockSupport.java Index: BeanLockSupport.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/BeanLockSupport.java,v retrieving revision 1.4 retrieving revision 1.4.4.1 diff -u -r1.4 -r1.4.4.1 --- BeanLockSupport.java 2001/08/08 22:01:31 1.4 +++ BeanLockSupport.java 2001/09/04 01:50:26 1.4.4.1 @@ -29,7 +29,7 @@ * * @author Bill Burke * @author Marc Fleury - * @version $Revision: 1.4 $ + * @version $Revision: 1.4.4.1 $ * * Revisions: * 2001/07/29: marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty and Rabbit Hole
> Then how do you reference these files? You mention referencing the top of If there was some sort of ServiceContext, passed into the service bean, on init, then it could hold this information. > the file hierarchy but how do you know where to find it? The only simple > solution that I can think of is you doing a getResource() on your > classloader that would point to the top of the hierarchy and you can work Some legecy services will want files. Some services will only make sence when working off of files. I can understand that the boot/loading system should not be tied to files, but there is no reason why we should force service writters to stop using files. Right? > from there. I would strongly recommend not making that "anchor" file a > configuration file (something widespread in jboss) since the configurations Widespread through more than JBoss. Plugin vendors will probably want access to the filesystem for whatever. > The last point is where to get the name for the sar directory (I don't know > that you are going to deploy "jetty"). This probably means that we will Why wouldn't you deploy jetty? Do you mean that it could be in the main jboss-service.xml, lets just make it a deployable. Lets make everything deployable except for the core system services. > need to introduce a sar.xml that is a collection of the jcml information and > some self descripting stuff such as the name of the "sar" (in our case > "jetty"). h remeber long ago when I was talking about using a FileSystem abstraction... and remeber the bit about defining local resources required by a service in the service deployment descriptor, these go hand in hand. Top it off with the ServiceContext, and you have all the means to support this type of per-service configuration. > Maybe I should read that service proposal thing. Can anyone provide a > pointer. Which service proposal thingy do you mean? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty and Rabbit Hole
> So although whoever did the integration has managed to move over the > webdefault.xml file, we really need to consider what of the rest of Jetty's > config to throw away, and what to keep. I think Hiram did some work to make the plugins/jetty module work out of the default build. > However, initially, Jetty still expects files, which are best arranged in a > hierarchy and assosciated with Jetty. What does it need to run? Just configuration or does it want more? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty and Rabbit Hole
> I'm getting a number of non-Jetty exceptions and ignoring them. What exceptions are you getting? > It looks like you/someone have made Jetty into a 'plugin' - thanks. I > was expecting this to be the .SAR archive that I keep seeing mentioned > here and there but I've grepped all over the place and can't find > any mention of them - what's the score here ? Like I said before, I have not really looked at the changes Marc commited in much detail yet. I can't really say more than that at the moment. > The Jetty plugin deliverable does not appear to own a runtime > distribution tree, as such. This is the cause of all the Exceptions > generated by the default jetty.xml config file, and the reason that you > had to empty it. Assuming that the Jetty plugin needs some sort of tree > of resources available to it at runtime, has any thought been given to > how this might be distributed, since it is not simply a matter of > shipping jars about, but whole directory hierarchies.. I was hoping that > I could put this hierarchy into a .SAR, which would be distributed, > unpacked and then run. Jetty would be able to locate all the files it > needed within a tree relative to the top of the unpacked .SAR. I did not spend much time integrating the plugins/jetty module. All I did was get it to compile under the new system, and package up the jetty-plugin.jar. I think that if we could turn that into a jetty-plugin.sar, which had had all of the support files (static config and whatever) that would be the way to go. That said, I don't really know (at the moment) what needs to be done to make that happen. =| --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] testsuite build system changes
Thanks! --jason On Mon, 3 Sep 2001, Chris Kimpton wrote: > Hi, > > > > > I was planning on pulling the stylesheets out of the optional.jar, > > and > > adding them to src/testsuite. I would like to keep the > > javadoc-like style, > > but I want to make the errors stand out more (bold isn't really > > that > > obvious... I was going to go for white on red). > > Done. > > Tomorrows reports on http://lubega.com will use the new style. > > Let me know if there any other changes people would like... > > I don't suppose yesterdays Automated Test summary report reached > anyone - I havn't got it back in my mailbox, but the log says it sent > it...:-( > > > Regards, > Chris > > = > Need somewhere to Live in London - http://freeflats.com > > __ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger > http://im.yahoo.com > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty and Rabbit Hole
Can you point me to any doc on sars ? This is how Jetty should deliver for 3.0 is it not ? Do I just drop a sar into jboss/deploy ? Is the SARDeployer working yet ? I can't find a mention of any sars being deployed when I run up my copy of JBoss-3.0 or find any in my output tree - should I just stick to the plugin stuff for now ? Jules marc fleury wrote: > |However, initially, Jetty still expects files, which are best arranged in a > |hierarchy and assosciated with Jetty. > > Ok so let's imagine that we pack a jar hierarchy of files and pack that in > sar. > > Then how do you reference these files? You mention referencing the top of > the file hierarchy but how do you know where to find it? The only simple > solution that I can think of is you doing a getResource() on your > classloader that would point to the top of the hierarchy and you can work > from there. I would strongly recommend not making that "anchor" file a > configuration file (something widespread in jboss) since the configurations > can be located to URL. > > So the first part is mine, if you ship a filesystem.jar under META-INF I > will know to unpack it from the $jboss-home/SAR/files directory your > classloader will point to there and if you do a "getResource" it will > correctly find it under that directory. > > The last point is where to get the name for the sar directory (I don't know > that you are going to deploy "jetty"). This probably means that we will > need to introduce a sar.xml that is a collection of the jcml information and > some self descripting stuff such as the name of the "sar" (in our case > "jetty"). h > > Maybe I should read that service proposal thing. Can anyone provide a > pointer. > > marcf > > ___ > 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] Jetty and Rabbit Hole
Julian Gosnell wrote: > > However, initially, Jetty still expects files, which are best arranged in a > hierarchy and assosciated with Jetty. > > > Any thoughts > It should not be too much work to do away with the Jetty config files all together and configure Jetty entirely via JMX. For the cisco deployment, this is exactly what they do and they have a JMX configuration architecture not unlike JBosses. The main difference is that: + The lifecycle methods are not expected. (ie don't have to have a start(); + Arbitrary methods can be called as well as attributes set. So I think the aim of the integration, should be to remove all trace of the jetty configuration mechanism from a standard jboss/jetty installation. This may be simple? As jetty configuration for most purposes can be reduced to a series of JMX sets followed by a call to start(). My vague understanding of the jboss config architecture is that this should be supported. However they may be more complex configurations that require arbitrary methods to be called on the jetty mbeans. These will have to be addressed either by changing the jetty mbeans so everything can be done as sets, then start() - or improving the jboss mechanism so that more arbitrary jmx calls can be made. Again for the cisco deployment, I used a config file format very similar to that of Jetty's XML - but which was able to call arbitrary JMX methods. cheers -- Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty and Rabbit Hole
|It looks like webapps are no longer finding classes contained by jars from |WEB-INF/lib. does the integration code pick up those web-inf/lib jars, if so to what classloader does it add them to? the mlet? If that is the case, in that code try adding the jars to a new URLClassLoader (JBoss' kind). What you want to find out is how the visibility on those classes was dependent on the integration code. |Since the Jetty installation is identical, and the integration code reports |the webapp as successfully deployed, I guess there is something going on in |the ClassLoader passed by JBoss to Jetty on the webapp's deployment thread. | |Is anyone aware of changes to this that may be causing this symptom ? The only difference from your point of view is that the one big MLet stuff is no longer in use. again please find where JBoss loads these web-inf/lib classes on your behalf. ( i find this strange btw, why we we load these classes for you??) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jetty and Rabbit Hole
|However, initially, Jetty still expects files, which are best arranged in a |hierarchy and assosciated with Jetty. Ok so let's imagine that we pack a jar hierarchy of files and pack that in sar. Then how do you reference these files? You mention referencing the top of the file hierarchy but how do you know where to find it? The only simple solution that I can think of is you doing a getResource() on your classloader that would point to the top of the hierarchy and you can work from there. I would strongly recommend not making that "anchor" file a configuration file (something widespread in jboss) since the configurations can be located to URL. So the first part is mine, if you ship a filesystem.jar under META-INF I will know to unpack it from the $jboss-home/SAR/files directory your classloader will point to there and if you do a "getResource" it will correctly find it under that directory. The last point is where to get the name for the sar directory (I don't know that you are going to deploy "jetty"). This probably means that we will need to introduce a sar.xml that is a collection of the jcml information and some self descripting stuff such as the name of the "sar" (in our case "jetty"). h Maybe I should read that service proposal thing. Can anyone provide a pointer. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] What happened to build.bat that was in CVS?
FWIW? --jason On Mon, 3 Sep 2001, Chris Kimpton wrote: > Hi, > > --- Jason Dillon <[EMAIL PROTECTED]> wrote: > > > Is someone having trouble with that? > > I don't think so - there was an old (15 Aug) message under this > subject which was querying what PWD was for in the old .bat scripts > and hence the FWIW answer... > > Chris > > = > Need somewhere to Live in London - http://freeflats.com > > __ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger > http://im.yahoo.com > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib tomcat-service.jar
User: starksm Date: 01/09/03 16:01:09 Modified:src/lib Tag: Branch_2_4 tomcat-service.jar Log: Integrate the Rel_2_4_1_6 from contrib/tomcat Revision ChangesPath No revision No revision 1.9.6.6 +74 -47jboss/src/lib/Attic/tomcat-service.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/naming ENCFactory.java
User: starksm
Date: 01/09/03 16:00:22
Modified:src/main/org/jboss/naming Tag: Branch_2_4 ENCFactory.java
Log:
Look for an existing ENC associated with a parent class loader before
creating a ctxClassLoader ENC
Revision ChangesPath
No revision
No revision
1.3.6.1 +22 -7 jboss/src/main/org/jboss/naming/ENCFactory.java
Index: ENCFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/naming/ENCFactory.java,v
retrieving revision 1.3
retrieving revision 1.3.6.1
diff -u -r1.3 -r1.3.6.1
--- ENCFactory.java 2000/12/07 15:45:09 1.3
+++ ENCFactory.java 2001/09/03 23:00:22 1.3.6.1
@@ -22,7 +22,8 @@
*
* @see
* @author Rickard Oberg ([EMAIL PROTECTED])
- * @version $Revision: 1.3 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.3.6.1 $
*/
public class ENCFactory
implements ObjectFactory
@@ -48,18 +49,32 @@
synchronized (encs)
{
// Get naming for this component
- NamingServer srv =
(NamingServer)encs.get(Thread.currentThread().getContextClassLoader());
-
- // If this is the first time we see this name
+ ClassLoader ctxClassLoader =
Thread.currentThread().getContextClassLoader();
+ NamingServer srv = (NamingServer) encs.get(ctxClassLoader);
+
+ /* If this is the first time we see ctxClassLoader first check to see
+ if a parent ClassLoader has created an ENC namespace.
+ */
if (srv == null)
{
-srv = new NamingServer();
-encs.put(Thread.currentThread().getContextClassLoader(), srv);
+ClassLoader parent = ctxClassLoader.getParent();
+while( parent != null && srv == null )
+{
+ parent = parent.getParent();
+ if( parent != null )
+ srv = (NamingServer) encs.get(parent);
+}
+// If we did not find an ENC create it
+if( srv == null )
+{
+ srv = new NamingServer();
+ encs.put(ctxClassLoader, srv);
+}
}
return new NamingContext(environment, null, srv);
}
}
-
+
// Y overrides ---
// Package protected -
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty and Rabbit Hole
I've just tried deploying some apps to my new JBoss-3.0/Jetty-3.1.RC8 build. It looks like webapps are no longer finding classes contained by jars from WEB-INF/lib. I can deploy exactly the same jar on JBoss-2.4.0_Jetty-3.1.RC8-1 and it works fine. Since the Jetty installation is identical, and the integration code reports the webapp as successfully deployed, I guess there is something going on in the ClassLoader passed by JBoss to Jetty on the webapp's deployment thread. Is anyone aware of changes to this that may be causing this symptom ? Is it work under way, that I would be wasting my time investigating, or is it assumed to all be working ? Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/web/test TestWebIntegration.java
User: starksm
Date: 01/09/03 15:57:14
Modified:src/main/org/jboss/test/web/test Tag: Branch_2_4
TestWebIntegration.java
Log:
Additional tests for accessing secure content
Revision ChangesPath
No revision
No revision
1.7.2.3 +231 -199
jbosstest/src/main/org/jboss/test/web/test/TestWebIntegration.java
Index: TestWebIntegration.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/web/test/TestWebIntegration.java,v
retrieving revision 1.7.2.2
retrieving revision 1.7.2.3
diff -u -r1.7.2.2 -r1.7.2.3
--- TestWebIntegration.java 2001/07/29 16:32:43 1.7.2.2
+++ TestWebIntegration.java 2001/09/03 22:57:14 1.7.2.3
@@ -16,210 +16,242 @@
import org.jboss.test.util.Deploy;
/** Tests of servlet container integration into the JBoss server. This test
-requires than a web container be integrated into the JBoss server. The tests
-currently use the java.net.HttpURLConnection and associated http client and
-these do not return very good information on errors so if a failure occurs it
-is best to connect the webserver using a browser to look for additional error
-info.
-
-The secure access tests require a user named 'jduke' with a password of 'theduke'
-with a role of 'AuthorizedUser' in the servlet container.
-
-@author [EMAIL PROTECTED]
-@version $Revision: 1.7.2.2 $
-*/
+ requires than a web container be integrated into the JBoss server. The tests
+ currently use the java.net.HttpURLConnection and associated http client and
+ these do not return very good information on errors so if a failure occurs it
+ is best to connect the webserver using a browser to look for additional error
+ info.
+
+ The secure access tests require a user named 'jduke' with a password of 'theduke'
+ with a role of 'AuthorizedUser' in the servlet container.
+
+ @author [EMAIL PROTECTED]
+ @version $Revision: 1.7.2.3 $
+ */
public class TestWebIntegration extends TestCase
{
-private static boolean setUp;
-private static boolean webServerAvailable;
-private static String baseURL;
-
-public TestWebIntegration(String name)
-{
-super(name);
-}
-
-/** Test for the availability of a local webserver and deploy the
-jbosstest-web.ear one time if a webserver is found.
- */
-protected void setUp() throws Exception
-{
-if( setUp == true )
-return;
-setUp = true;
-
-Integer port = Integer.getInteger("web.port", 8080);
-baseURL = "http://jduke:theduke@localhost:"; + port + '/';
-try
-{
-String serverName = InetAddress.getLocalHost().getHostName();
-String connectorName = "jmx:" +serverName+ ":rmi";
-RMIConnector server = (RMIConnector) new
InitialContext().lookup(connectorName);
-ObjectName deployerName = new ObjectName("J2EE:service=J2eeDeployer");
-// Ask the deployer for the getWarDeployerName
-Object[] params = {};
-String[] signature = {};
-String warDeployerName = (String) server.invoke(deployerName,
-"getWarDeployerName", params, signature);
-// See if the warDeployerName exists
-deployerName = new ObjectName(warDeployerName);
-webServerAvailable = server.isRegistered(deployerName);
-if( webServerAvailable == true )
-{
-System.out.println("Found warDeployer named: "+warDeployerName);
-try
-{
-Deploy.deploy("jbosstest-web.ear");
-}
-catch(Exception e)
-{
-e.printStackTrace();
-fail("Failed to deploy jbosstest-web.ear");
-}
-// Flush the security domain cache to avoid conflicts with other
testcases
-ObjectName jaasMgr = new
ObjectName("Security:name=JaasSecurityManager");
-params = new Object[]{"other"};
-signature = new String[]{"java.lang.String"};
-server.invoke(jaasMgr, "flushAuthenticationCache", params,
signature);
-}
-else
+ private static boolean setUp;
+ private static boolean webServerAvailable;
+ private static String baseURL;
+
+ public TestWebIntegration(String name)
+ {
+ super(name);
+ }
+
+ /** Test for the availability of a local webserver and deploy the
+jbosstest-web.ear one time if a webserver is found.
+*/
+ protected void setUp() throws Exception
+ {
+ if( setUp == true )
+ return;
+ setUp = true;
+
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/web/servlets IncludeServlet.java UnsecureEJBServlet.java SecureEJBServlet.java SecureServlet.java
User: starksm
Date: 01/09/03 15:57:14
Modified:src/main/org/jboss/test/web/servlets Tag: Branch_2_4
SecureEJBServlet.java SecureServlet.java
Added: src/main/org/jboss/test/web/servlets Tag: Branch_2_4
IncludeServlet.java UnsecureEJBServlet.java
Log:
Additional tests for accessing secure content
Revision ChangesPath
No revision
No revision
1.3.2.1 +17 -8
jbosstest/src/main/org/jboss/test/web/servlets/SecureEJBServlet.java
Index: SecureEJBServlet.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/web/servlets/SecureEJBServlet.java,v
retrieving revision 1.3
retrieving revision 1.3.2.1
diff -u -r1.3 -r1.3.2.1
--- SecureEJBServlet.java 2001/05/22 04:03:27 1.3
+++ SecureEJBServlet.java 2001/09/03 22:57:14 1.3.2.1
@@ -17,8 +17,8 @@
/**
*
- * @author [EMAIL PROTECTED]
- * @version $Revision: 1.3 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.3.2.1 $
*/
public class SecureEJBServlet extends HttpServlet
{
@@ -26,10 +26,14 @@
throws ServletException, IOException
{
String echoMsg = null;
-String param = request.getParameter("testPropagation");
boolean testPropagation = false;
+boolean includeHead = true;
+String param = request.getParameter("testPropagation");
if( param != null )
testPropagation = Boolean.valueOf(param).booleanValue();
+param = request.getParameter("includeHead");
+if( param != null )
+includeHead = Boolean.valueOf(param).booleanValue();
try
{
@@ -53,14 +57,19 @@
throw new ServletException("Failed to call SecuredEJB.echo", e);
}
Principal user = request.getUserPrincipal();
-response.setContentType("text/html");
PrintWriter out = response.getWriter();
-out.println("");
-out.println("ENCServlet");
+if( includeHead == true )
+{
+ response.setContentType("text/html");
+ out.println("");
+ out.println("ENCServlet");
+}
out.println("SecureServlet Accessed");
-out.println("You have accessed this servlet as user: "+user);
+out.println("You have accessed this servlet as user: "+user);
out.println("You have accessed SecuredEJB as user: "+echoMsg);
-out.println("");
+out.println("");
+if( includeHead == true )
+ out.println("");
out.close();
}
1.1.2.1 +2 -2
jbosstest/src/main/org/jboss/test/web/servlets/SecureServlet.java
Index: SecureServlet.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/web/servlets/SecureServlet.java,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- SecureServlet.java2001/05/05 20:59:35 1.1
+++ SecureServlet.java2001/09/03 22:57:14 1.1.2.1
@@ -12,7 +12,7 @@
/**
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.1.2.1 $
*/
public class SecureServlet extends HttpServlet
{
@@ -23,7 +23,7 @@
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("");
-out.println("ENCServlet");
+out.println("SecureServlet");
out.println("SecureServlet Accessed");
out.println("You have accessed this servlet as user:"+user+"");
out.println("");
No revision
No revision
1.1.2.1 +64 -0
jbosstest/src/main/org/jboss/test/web/servlets/Attic/IncludeServlet.java
1.1.2.1 +79 -0
jbosstest/src/main/org/jboss/test/web/servlets/Attic/UnsecureEJBServlet.java
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/web/WEB-INF web.xml
User: starksm Date: 01/09/03 15:56:11 Modified:src/resources/web/WEB-INF Tag: Branch_2_4 web.xml Log: Add jsp include tests Revision ChangesPath No revision No revision 1.8.2.3 +33 -1 jbosstest/src/resources/web/WEB-INF/web.xml Index: web.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/web/WEB-INF/web.xml,v retrieving revision 1.8.2.2 retrieving revision 1.8.2.3 diff -u -r1.8.2.2 -r1.8.2.3 --- web.xml 2001/07/09 08:54:13 1.8.2.2 +++ web.xml 2001/09/03 22:56:11 1.8.2.3 @@ -31,6 +31,14 @@ org.jboss.test.web.servlets.DebugServlet +IncludeServlet +org.jboss.test.web.servlets.IncludeServlet + + +SecureIncludeServlet +org.jboss.test.web.servlets.IncludeServlet + + SecureServlet org.jboss.test.web.servlets.SecureServlet @@ -39,6 +47,10 @@ org.jboss.test.web.servlets.SecureEJBServlet +UnsecureEJBServlet + org.jboss.test.web.servlets.UnsecureEJBServlet + + SecureEJBServletMT org.jboss.test.web.servlets.SecureEJBServletMT @@ -50,6 +62,14 @@ classpath /classpath.jsp + +restricted/include_ejb.jsp +/restricted/include_ejb.jsp + + +restricted/ejb.jsp +/restricted/ejb.jsp + rpcrouter @@ -102,6 +122,14 @@ /ClientLoginServlet +IncludeServlet +IncludeServlet + + +SecureIncludeServlet +/restricted/IncludeServlet + + SecureServlet /restricted/SecureServlet @@ -110,6 +138,10 @@ /restricted/SecureEJBAccess +UnsecureEJBServlet +UnsecureEJBAccess + + SecureEJBServletMT /restricted/SecureEJBAccessMT @@ -173,7 +205,7 @@ DELETE -Only +Only authenticated users can access secure content AuthorizedUser ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/web/restricted ejb.jsp include_ejb.jsp
User: starksm Date: 01/09/03 15:56:11 Added: src/resources/web/restricted Tag: Branch_2_4 ejb.jsp include_ejb.jsp Log: Add jsp include tests Revision ChangesPath No revision No revision 1.1.2.1 +39 -0 jbosstest/src/resources/web/restricted/Attic/ejb.jsp 1.1.2.1 +21 -0 jbosstest/src/resources/web/restricted/Attic/include_ejb.jsp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/web index.html
User: starksm Date: 01/09/03 15:56:11 Modified:src/resources/web Tag: Branch_2_4 index.html Log: Add jsp include tests Revision ChangesPath No revision No revision 1.5.2.2 +14 -0 jbosstest/src/resources/web/index.html Index: index.html === RCS file: /cvsroot/jboss/jbosstest/src/resources/web/index.html,v retrieving revision 1.5.2.1 retrieving revision 1.5.2.2 diff -u -r1.5.2.1 -r1.5.2.2 --- index.html2001/07/09 01:06:08 1.5.2.1 +++ index.html2001/09/03 22:56:11 1.5.2.2 @@ -31,6 +31,9 @@ A JSP page that access the org.jboss.test.web.util.Util class from the WEB-INF/lib/util.jar to dump its class loaders and display the JNDI ENC. + Try include_ejb.jsp + A secured JSP page that includes the ejb.jsp multiple times + Security Tests @@ -59,6 +62,17 @@ Try ClientLoginServlet An unsecure servlet that performs a JAAS login as jduke to access a secured EJB. + + Try UnsecureEJBServlet + An unsecure servlet that tries to access a secured EJB. + + Try IncludeServlet + An unsecure servlet that tries to include both secured and unsecured servlets + which access a secured EJB. + + Try IncludeServlet + An secure servlet that tries to include both secured and unsecured servlets + which access a secured EJB. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/etc/conf/tomcat jboss.jcml.patch
User: starksm Date: 01/09/03 15:55:02 Modified:tomcat/src/etc/conf/tomcat Tag: Branch_2_4 jboss.jcml.patch Log: Update for changes in jboss.jcml Revision ChangesPath No revision No revision 1.2.2.3 +19 -19contrib/tomcat/src/etc/conf/tomcat/jboss.jcml.patch Index: jboss.jcml.patch === RCS file: /cvsroot/jboss/contrib/tomcat/src/etc/conf/tomcat/jboss.jcml.patch,v retrieving revision 1.2.2.2 retrieving revision 1.2.2.3 diff -u -r1.2.2.2 -r1.2.2.3 --- jboss.jcml.patch 2001/07/28 18:21:04 1.2.2.2 +++ jboss.jcml.patch 2001/09/03 22:55:01 1.2.2.3 @@ -1,22 +1,22 @@ -*** jboss.jcml Fri Jul 27 17:22:55 2001 jboss.jcml.tomcatFri Jul 27 18:09:04 2001 +*** jboss.jcml Mon Sep 3 15:57:08 2001 +--- jboss.jcml.tomcatMon Sep 3 15:57:35 2001 *** *** 154,162 - false - - -! - - + + - - - + + +
[JBoss-dev] CVS update: jbosstest/src/resources/web/restricted - New directory
User: starksm Date: 01/09/03 15:55:40 jbosstest/src/resources/web/restricted - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] security exception in 2.4 final
I have verified the issue using the indicated type of jsp page. A fix has been committed to the 2.4 branch and will be in the next 2.4.x release. - Original Message - From: "Schouten, Andreas" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 28, 2001 2:57 AM Subject: RE: [JBoss-dev] security exception in 2.4 final > Hi Scott, > > the error is not in the DatabaseServerLoginModul. The username being passed > to it is null (or "null"). > The error only occurs if the container creates a new instance of the called > stateless session bean. I stored a timestamp as menber variable in the SB > and print it on every call. As long this instance is used no security > exception occurs. > > You should be able to reproduce the problem if You include a sequence of jsp > includes in a jsp. > > > > > > > > > > > > > > > where test.jsp looks up a stateless session bean which respond data fromn an > entity bean. > > The data is displayed correct once but the next includes cause the security > exception. With jBoss rel 23 the includes are processed correct each with an > own instance of the SB. > > Andreas > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/main/org/jboss/tomcat/security JBossSecurityMgrRealm.java
User: starksm
Date: 01/09/03 15:46:09
Modified:tomcat/src/main/org/jboss/tomcat/security Tag: Branch_2_4
JBossSecurityMgrRealm.java
Log:
Update cleanup of SecurityAssociation to work with included content
Revision ChangesPath
No revision
No revision
1.4.2.7 +229 -201
contrib/tomcat/src/main/org/jboss/tomcat/security/JBossSecurityMgrRealm.java
Index: JBossSecurityMgrRealm.java
===
RCS file:
/cvsroot/jboss/contrib/tomcat/src/main/org/jboss/tomcat/security/JBossSecurityMgrRealm.java,v
retrieving revision 1.4.2.6
retrieving revision 1.4.2.7
diff -u -r1.4.2.6 -r1.4.2.7
--- JBossSecurityMgrRealm.java2001/07/29 15:26:04 1.4.2.6
+++ JBossSecurityMgrRealm.java2001/09/03 22:46:09 1.4.2.7
@@ -24,222 +24,250 @@
import org.jboss.security.SubjectSecurityManager;
/** This is a request interceptor for authentication/authorization of users
-that uses the JBossSX security framework. It relieas on the JNDI ENC
-namespace setup by the AbstractWebContainer. In particular, it uses the
-java:comp/env/security subcontext to access the security manager interfaces
-for authorization and authenticaton.
-
-@see org.jboss.web.AbstractWebContainer
-@see org.jboss.security.EJBSecurityManager
-@see org.jboss.security.RealmMapping
-@see org.jboss.security.SimplePrincipal
-@see org.jboss.security.SecurityAssociation
-@see org.jboss.security.SubjectSecurityManager
-
-@author [EMAIL PROTECTED]
-@version $Revision: 1.4.2.6 $
-*/
+ that uses the JBossSX security framework. It relieas on the JNDI ENC
+ namespace setup by the AbstractWebContainer. In particular, it uses the
+ java:comp/env/security subcontext to access the security manager interfaces
+ for authorization and authenticaton.
+
+ @see org.jboss.web.AbstractWebContainer
+ @see org.jboss.security.EJBSecurityManager
+ @see org.jboss.security.RealmMapping
+ @see org.jboss.security.SimplePrincipal
+ @see org.jboss.security.SecurityAssociation
+ @see org.jboss.security.SubjectSecurityManager
+
+ @author [EMAIL PROTECTED]
+ @version $Revision: 1.4.2.7 $
+ */
public class JBossSecurityMgrRealm extends BaseInterceptor
{
-static Category category =
Category.getInstance(JBossSecurityMgrRealm.class.getName());
-private String subjectAttributeName = "j_subject";
-private boolean useJAAS = false;
-
-/** A flag to indicate if the security manager implements the
SubjectSecurityManager
- rather than EJBSecurityManager. When true, the authenticated Subject is
obtained
- from the SubjectSecurityManager and placed into the request under the
- subjectAttributeName attribute.
- */
-public void setUseJAAS(boolean useJAAS)
-{
-this.useJAAS = useJAAS;
-}
-/** The name of the request attribute under with the authenticated JAAS
- Subject is stored on successful authentication.
- */
-public void setSubjectAttributeName(String subjectAttributeName)
-{
-this.subjectAttributeName = subjectAttributeName;
-}
-
-private Context getSecurityContext()
-{
-Context securityCtx = null;
-// Get the JBoss security manager from the ENC context
-try
-{
-InitialContext iniCtx = new InitialContext();
-securityCtx = (Context) iniCtx.lookup("java:comp/env/security");
-}
-catch(NamingException e)
-{
-// Apparently there is no security context?
-}
-return securityCtx;
-}
-
-public int authenticate(Request request, Response response)
-{
+ private static Category category =
Category.getInstance(JBossSecurityMgrRealm.class);
+ private static ThreadLocal authInfo = new ThreadLocal();
+ private String subjectAttributeName = "j_subject";
+ private boolean useJAAS = false;
+
+ /** A flag to indicate if the security manager implements the
SubjectSecurityManager
+rather than EJBSecurityManager. When true, the authenticated Subject is obtained
+from the SubjectSecurityManager and placed into the request under the
+subjectAttributeName attribute.
+*/
+ public void setUseJAAS(boolean useJAAS)
+ {
+ this.useJAAS = useJAAS;
+ }
+ /** The name of the request attribute under with the authenticated JAAS
+Subject is stored on successful authentication.
+*/
+ public void setSubjectAttributeName(String subjectAttributeName)
+ {
+ this.subjectAttributeName = subjectAttributeName;
+ }
+
+ private Context getSecurityContext()
+ {
+ Context securityCtx = null;
+ // Get the JBoss security manager from the ENC context
+ try
+ {
+
[JBoss-dev] CVS update: contrib/tomcat/src/main/org/jboss/tomcat EmbeddedTomcatServiceSX.java EmbeddedTomcatServiceSXMBean.java
User: starksm
Date: 01/09/03 15:46:08
Modified:tomcat/src/main/org/jboss/tomcat Tag: Branch_2_4
EmbeddedTomcatServiceSX.java
EmbeddedTomcatServiceSXMBean.java
Log:
Update cleanup of SecurityAssociation to work with included content
Revision ChangesPath
No revision
No revision
1.2.2.2 +2 -2
contrib/tomcat/src/main/org/jboss/tomcat/EmbeddedTomcatServiceSX.java
Index: EmbeddedTomcatServiceSX.java
===
RCS file:
/cvsroot/jboss/contrib/tomcat/src/main/org/jboss/tomcat/EmbeddedTomcatServiceSX.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- EmbeddedTomcatServiceSX.java 2001/06/23 01:10:58 1.2.2.1
+++ EmbeddedTomcatServiceSX.java 2001/09/03 22:46:08 1.2.2.2
@@ -43,8 +43,8 @@
@see org.jboss.web.AbstractWebContainer
-@author [EMAIL PROTECTED]
-@version $Revision: 1.2.2.1 $
+@author [EMAIL PROTECTED]
+@version $Revision: 1.2.2.2 $
*/
public class EmbeddedTomcatServiceSX extends AbstractWebContainer
implements EmbeddedTomcatServiceSXMBean
1.1.4.1 +2 -2
contrib/tomcat/src/main/org/jboss/tomcat/EmbeddedTomcatServiceSXMBean.java
Index: EmbeddedTomcatServiceSXMBean.java
===
RCS file:
/cvsroot/jboss/contrib/tomcat/src/main/org/jboss/tomcat/EmbeddedTomcatServiceSXMBean.java,v
retrieving revision 1.1
retrieving revision 1.1.4.1
diff -u -r1.1 -r1.1.4.1
--- EmbeddedTomcatServiceSXMBean.java 2001/05/23 18:26:33 1.1
+++ EmbeddedTomcatServiceSXMBean.java 2001/09/03 22:46:08 1.1.4.1
@@ -14,8 +14,8 @@
* Management interface for the Embedded Tomcat service
*
* @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
- * @author [EMAIL PROTECTED]
- * @version $Revision: 1.1 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.1.4.1 $
*/
public interface EmbeddedTomcatServiceSXMBean extends AbstractWebContainerMBean
{
___
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/naming JbossWebXmlReader.java
User: starksm
Date: 01/09/03 15:46:09
Modified:tomcat/src/main/org/jboss/tomcat/naming Tag: Branch_2_4
JbossWebXmlReader.java
Log:
Update cleanup of SecurityAssociation to work with included content
Revision ChangesPath
No revision
No revision
1.6.2.1 +2 -2
contrib/tomcat/src/main/org/jboss/tomcat/naming/JbossWebXmlReader.java
Index: JbossWebXmlReader.java
===
RCS file:
/cvsroot/jboss/contrib/tomcat/src/main/org/jboss/tomcat/naming/JbossWebXmlReader.java,v
retrieving revision 1.6
retrieving revision 1.6.2.1
diff -u -r1.6 -r1.6.2.1
--- JbossWebXmlReader.java2001/06/22 05:37:52 1.6
+++ JbossWebXmlReader.java2001/09/03 22:46:08 1.6.2.1
@@ -30,8 +30,8 @@
the servlet class loader has been set on the Context.
@author mailto:[EMAIL PROTECTED]";>Kevin Lewis
-@author [EMAIL PROTECTED]
-@version $Revision: 1.6 $
+@author [EMAIL PROTECTED]
+@version $Revision: 1.6.2.1 $
*/
public class JbossWebXmlReader extends BaseInterceptor
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty and Rabbit Hole
Julian Gosnell wrote: > Jason, > > I have checked out a fresh jboss-all tree, built it successfully and > tried running it. > > I'm getting a number of non-Jetty exceptions and ignoring them. > > On the Jetty side - a couple of questions. > > 1. > It looks like you/someone have made Jetty into a 'plugin' - thanks. I > was expecting this to be the .SAR archive that I keep seeing mentioned > here and there but I've grepped all over the place and can't find > any mention of them - what's the score here ? > > 2. > The Jetty plugin deliverable does not appear to own a runtime > distribution tree, as such. This is the cause of all the Exceptions > generated by the default jetty.xml config file, and the reason that you > had to empty it. Assuming that the Jetty plugin needs some sort of tree > of resources available to it at runtime, has any thought been given to > how this might be distributed, since it is not simply a matter of > shipping jars about, but whole directory hierarchies.. I was hoping that > I could put this hierarchy into a .SAR, which would be distributed, > unpacked and then run. Jetty would be able to locate all the files it > needed within a tree relative to the top of the unpacked .SAR. setting JettyHome to a valid Jetty installation in jboss-service.xml solves all Jetty related problems... e.g. : /home/jules/java/Jetty-3.1.RC8 ../conf/default/jetty.xml ../conf/default/webdefault.xml true true So although whoever did the integration has managed to move over the webdefault.xml file, we really need to consider what of the rest of Jetty's config to throw away, and what to keep. We could just strip everything out of the config file and check it in - but I think we are going to find that there are many places where Jetty expects configuration in the form of a filename., which we may like to continue to use for the moment. Ultimately these should be replaceable with a URL. Then we can either distribute the necessary files in a .SAR and they will be found even if it is run packed, because we can reference into the archive with a url, or these files can be left on a single machine, and referenced by each node as and when necessary. However, initially, Jetty still expects files, which are best arranged in a hierarchy and assosciated with Jetty. Any thoughts Jules > > > Thanks for the help, > > Jules > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _ 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] Jetty and Rabbit Hole
Jason, I have checked out a fresh jboss-all tree, built it successfully and tried running it. I'm getting a number of non-Jetty exceptions and ignoring them. On the Jetty side - a couple of questions. 1. It looks like you/someone have made Jetty into a 'plugin' - thanks. I was expecting this to be the .SAR archive that I keep seeing mentioned here and there but I've grepped all over the place and can't find any mention of them - what's the score here ? 2. The Jetty plugin deliverable does not appear to own a runtime distribution tree, as such. This is the cause of all the Exceptions generated by the default jetty.xml config file, and the reason that you had to empty it. Assuming that the Jetty plugin needs some sort of tree of resources available to it at runtime, has any thought been given to how this might be distributed, since it is not simply a matter of shipping jars about, but whole directory hierarchies.. I was hoping that I could put this hierarchy into a .SAR, which would be distributed, unpacked and then run. Jetty would be able to locate all the files it needed within a tree relative to the top of the unpacked .SAR. Thanks for the help, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/stylesheets junit-frames.xsl
User: kimptoc Date: 01/09/03 14:32:12 Modified:src/stylesheets junit-frames.xsl Log: added some more details to the junitreport Revision ChangesPath 1.2 +45 -1 jbosstest/src/stylesheets/junit-frames.xsl Index: junit-frames.xsl === RCS file: /cvsroot/jboss/jbosstest/src/stylesheets/junit-frames.xsl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- junit-frames.xsl 2001/09/03 20:21:34 1.1 +++ junit-frames.xsl 2001/09/03 21:32:12 1.2 @@ -3,7 +3,17 @@ xmlns:redirect="org.apache.xalan.xslt.extensions.Redirect" extension-element-prefixes="redirect"> + + + + + + + + + + + + + + + + + Java Version + + Java Vendor + + Java VM Name + + Java VM Version + + Java VM Info + + OS Name + + OS Version + + OS Arch + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] What happened to build.bat that was in CVS?
Hi, --- Jason Dillon <[EMAIL PROTECTED]> wrote: > Is someone having trouble with that? I don't think so - there was an old (15 Aug) message under this subject which was querying what PWD was for in the old .bat scripts and hence the FWIW answer... Chris = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-458168 ] PropVals for PrincipalMappingProperties
Bugs item #458168, was opened at 2001-09-03 14:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=458168&group_id=22866 Category: JBossServer Group: v2.5 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Frank Langelage (lafr) Assigned to: Nobody/Anonymous (nobody) Summary: PropVals for PrincipalMappingProperties Initial Comment: see also Bug #457772 ! In mbean "ConnectionFactoryLoader" the section for "PrincipalMappingProperties" has the same problem as in #457772. If only the attribute "userName" is set, it is evaluated correct. But Connection to Database fails (wrong/empty password). If I write userName=me password=mypw in jboss-service.xml, then the server tries to use "mepassword=mypw" as the username for DB-Connection -> user not known. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=458168&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] What happened to build.bat that was in CVS?
Hrm... I guess I should have read the subject. The path search is only to find tools/bin/ant., which will then take care of setting up the class path as needed. Because of the plugins/* stuff we may need to use ../tools or ../../tools. build.sh can do a full path search back to /, but build.bat, just does a search back 4 levels, which should work. Is someone having trouble with that? Perhaps we should move plugins/* to .. and just hardcode ../tools everywhere. --jason On Mon, 3 Sep 2001, Chris Kimpton wrote: > Hi, > > > > > OK, but for what is the PWD search for? do you have more infor on > > it? it > > does not seem to search for ANT_HOME at least. > > > > FWIW - it was finding the current working directory, so that it could > put the classes directory on the classpath as an absolute path. > > There were problems before where a relative path was failing in some > environments not sure which... > > HTH, > Chris > > = > Need somewhere to Live in London - http://freeflats.com > > __ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger > http://im.yahoo.com > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] What happened to build.bat that was in CVS?
Which PWD search are you talking about? --jason On Mon, 3 Sep 2001, Chris Kimpton wrote: > Hi, > > > > > OK, but for what is the PWD search for? do you have more infor on > > it? it > > does not seem to search for ANT_HOME at least. > > > > FWIW - it was finding the current working directory, so that it could > put the classes directory on the classpath as an absolute path. > > There were problems before where a relative path was failing in some > environments not sure which... > > HTH, > Chris > > = > Need somewhere to Live in London - http://freeflats.com > > __ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger > http://im.yahoo.com > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] What happened to build.bat that was in CVS?
Hi, > > OK, but for what is the PWD search for? do you have more infor on > it? it > does not seem to search for ANT_HOME at least. > FWIW - it was finding the current working directory, so that it could put the classes directory on the classpath as an absolute path. There were problems before where a relative path was failing in some environments not sure which... HTH, Chris = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] testsuite build system changes
Hi, > > I was planning on pulling the stylesheets out of the optional.jar, > and > adding them to src/testsuite. I would like to keep the > javadoc-like style, > but I want to make the errors stand out more (bold isn't really > that > obvious... I was going to go for white on red). Done. Tomorrows reports on http://lubega.com will use the new style. Let me know if there any other changes people would like... I don't suppose yesterdays Automated Test summary report reached anyone - I havn't got it back in my mailbox, but the log says it sent it... :-( Regards, Chris = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/stylesheets junit-frames.xsl
User: kimptoc
Date: 01/09/03 13:21:34
Added: src/stylesheets junit-frames.xsl
Log:
added first cut of a custom jboss junitreport
Revision ChangesPath
1.1 jbosstest/src/stylesheets/junit-frames.xsl
Index: junit-frames.xsl
===
http://www.w3.org/1999/XSL/Transform"; version="1.0"
xmlns:lxslt="http://xml.apache.org/xslt";
xmlns:redirect="org.apache.xalan.xslt.extensions.Redirect"
extension-element-prefixes="redirect">
.
JBoss Test Suite Results.
Frame Alert
This document is designed to be viewed using the frames feature. If
you see this message, you are using a non-frame-capable web client.
body {
font:normal 68% verdana,arial,helvetica;
color:#00;
}
td {
font-size: 68%
}
p {
line-height:1.5em;
margin-top:0.5em; margin-bottom:1.0em;
}
h1 {
margin: 0px 0px 5px;
font: 165% verdana,arial,helvetica
}
h2 {
margin-top: 1em;
margin-bottom: 0.5em;
font: bold 125% verdana,arial,helvetica
}
h3 {
margin-bottom: 0.5em;
font: bold 115% verdana,arial,helvetica
}
h4 {
margin-bottom: 0.5em;
font: bold 100% verdana,arial,helvetica
}
h5 {
margin-bottom: 0.5em;
font: bold 100% verdana,arial,helvetica
}
h6 {
margin-bottom: 0.5em;
font: bold 100% verdana,arial,helvetica
}
.Error {
font-weight:bold;
color:white;
}
.Failure {
font-weight:bold;
color:white;
}
.ErrorDetail {
font-weight:bold;
color:red;
}
.FailureDetail {
font-weight:bold;
color:purple;
}
Class .
Tests
Classes
Classes
/
.html
[JBoss-dev] CVS update: jbosstest build.xml
User: kimptoc Date: 01/09/03 13:21:34 Modified:.build.xml Log: added first cut of a custom jboss junitreport Revision ChangesPath 1.9 +5 -2 jbosstest/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/build.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- build.xml 2001/09/02 20:57:23 1.8 +++ build.xml 2001/09/03 20:21:34 1.9 @@ -10,7 +10,7 @@ - + @@ -1529,7 +1529,10 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss Version.java
User: user57
Date: 01/09/03 13:02:03
Modified:src/main/org/jboss Version.java
Log:
o getIntProperty will return -1 instead of throwing an exception
Revision ChangesPath
1.3 +10 -7 jboss/src/main/org/jboss/Version.java
Index: Version.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/Version.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Version.java 2001/09/01 04:11:59 1.2
+++ Version.java 2001/09/03 20:02:03 1.3
@@ -17,7 +17,7 @@
* Provides access to JBoss version (and build) properties.
*
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
public final class Version
{
@@ -170,20 +170,23 @@
}
/**
-* Returns a property value as an int.
+* Returns a property value as an int.
*
-* @param name Description of Parameter
-* @return The IntProperty value
+* @return The property value, or -1 if there was a problem converting
+* it to an int.
*/
private int getIntProperty(final String name)
{
- return Integer.valueOf(props.getProperty(name)).intValue();
+ try {
+ return Integer.valueOf(props.getProperty(name)).intValue();
+ }
+ catch (Exception e) {
+ return -1;
+ }
}
/**
* Load the version properties from a resource.
-*
-* @returnDescription of the Returned Value
*/
private Properties loadProperties()
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/stylesheets fancy.xsl
User: user57 Date: 01/09/03 13:02:38 Modified:src/stylesheets fancy.xsl Log: o added file:// to import of chunk.xsl, may fix win32 bug, may not... still it should be there. Revision ChangesPath 1.3 +2 -2 manual/src/stylesheets/fancy.xsl Index: fancy.xsl === RCS file: /cvsroot/jboss/manual/src/stylesheets/fancy.xsl,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- fancy.xsl 2001/08/30 19:41:10 1.2 +++ fancy.xsl 2001/09/03 20:02:38 1.3 @@ -1,6 +1,6 @@ - + http://www.w3.org/1999/XSL/Transform"; xmlns:saxon="http://icl.com/saxon"; @@ -11,7 +11,7 @@ exclude-result-prefixes="doc" extension-element-prefixes="saxon xalanredirect lxslt"> - + styles.css 1 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: build/jboss build.xml
> Laziness ;-) > > ant complained that it did not recognise the mimemail task - and I > could not see it - until I upgraded my docs to be ant1.4beta2 - and > then I saw it was an optional task - I was too lazy to amend the > build.xml to recognise the task - especially when mail worked without > any extra config at least so I thought - but where are the daily > testing results this morning - according to the log files they were > sent... You were not use the ant from tools then? I was thinking mimemail, so that we could eventually attach different versions of the report, like a summary, a detail and perhaps an html detail too. Please make sure you are building off of the version of ant from tools (ala the build. scripts. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Forums: ability to search ALL forums & feedback
I have two suggestions for the forums system. First, there should be a function on the top-level forums page to submit feedback or report problems on the forums (which is why I'm writing this here). Second, it would be useful to have the ability to search ALL of the forums, not just one at a time. -- === David M. Karr ; Best Consulting [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJB 2.0 CMP
Got it now ... but it is still not seeing eye to eye ... comments below .. Dain Sundstrom wrote: > Dave, > > We still don't see eye-to-eye, and I think I made the problem worse with my > example. > > I think the most common type of relationship will be something like 'a cd > has an artist' or 'a cd has a publisher.' In this cases, the foreign key > for the artist or publisher would be just another column in the cd table. > So we would have something like: > > String idbn pk > String title > ... > Oid cd_artist fk > Oid cd_publisher fk > > The oid is a place holder for what ever the pk for cd and artist (don't let > it confuse you). I will argue that this is the most common relationship > type and is auto created by the system. > Sure, Oid could be artist number, name > Now your mapping is very different from what we have above. Your mapping > mapps a foreign key to one of the pk columns (multi-key). This is a very > difficult mapping because of the way the cmp engine is architected. The CMP > engine is field oriented as apposed to column oriented. A field can map to > multiple columns (a feature that existed in jaws). > > Follow so far? Not a good database practice to have one field name map to multiple database columns, but you have to support it. I would suggest though most IDE's would map 1 column in the database to 1 field in the entity and that case should be the rule, not the exception. > > Now each entity is composed of a collection of cmp field field objects and a > collection of foreign key fields (or relation table key fields). I'm only > going to address foreign key fields here. When the system starts it > initializes the cmp fields for every entity. After that is complete it > initializes the relationships. For each cmr field in an entity, it locates > the related entity and creates a set of foreign-keys that are a copy of the > related entitie's pk field(s). > > Still with me? > I'm with you but I think this is the rub. Why are we creating a copy of the related keys? Since you alredy have to create the actual implementation of the data for the entity bean, you must have code to map set and get calls into a set/retrive data out of the entity. Why not map the reference in the foreign key object to the entiy field and then just get it when you need it? Do they both not have to be in sync at all times anyway? > The problem you mapping presents is you want to use a field for both an > entity cmp and a relation foreign key field. In the current code these > fields are different object. The caching code is also field oriented, so > you would end up with two distinct caches of the code. Which could be a big > problem. > See above. > Ok let's take a step back and examine the mapping from the spec perspecitve. > Using a pk field as a relationship foreign key presents a problem because > the spec requres that a pk never change after ejbCreate but also requires > that a relationship can not be set until ejbPostCreate. This leads to the > question, how exactly are you going to set the relationship? > > Any way, I don't think any of the above text is that important. Although I > think what you ask will make your code not spec compliant, I also think this > type of mapping is important. I will look into adding support for this type > of mapping, but it won't happen soon. I am focusing on the features > required for spec compliance. Then I am going to add performance > enhancements. And finally additional features. > Yup, thats a problem. Looks like we would have to use 10.8.3 to get around it. I would not have a problem sticking in an primary key oid to get around it but it is just extra table space. I would agree though that unless it is easy to implement this would be a low priority. > Ok that was a lot of babble. I need to stop writting emails before I get my > first cup of coffee. > Oh, you just must be so excited when you get my e-mails you just have to type! Not bad babbling without caffeine ! > -dain dave ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-458075 ] HttpgetRemoteUser() NullPointerException
Bugs item #458075, was opened at 2001-09-03 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=458075&group_id=22866 Category: JBossServer Group: v2.2.2 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: HttpgetRemoteUser() NullPointerException Initial Comment: - j2sdk1.3 on Debian-testing and NT-4.0, both on x86 - JBoss-2.2.2_Tomcat-3.2.2 - apache-1.3.19 HttpServletRequest.getRemoteUser() throws a NullPointerException in both of the following situations: - Access via Tomcat's HTTP port 8080, with no access control information in the web.xml (i.e. an un-authenticated user) - Access via Apache and ajp12, the user authenticated via BASIC_AUTH >From the API docs: > getRemoteUser() > Returns the login of the > user making this request, if the > user has been authenticated, or null > if the user has not been authenticated. A NullPointerException is clearly a bug. In the first situation, it should return null. In the second, I'd expect it to return the correct user name, but I can see the possibility that there might be more configuration required. I'm certainly interested in pointers to information about how to make this work, if indeed it does. In my deployment environment, the existing Apache server and its authentication framework, SSL certificate, etc., are givens that I can't eliminate (although limited reconfiguration is possible). - Raz -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=458075&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EJB playing with finders
No cigar ... [CMP,DEBUG] EQL-QL: select object(t) from transferhead t where t.status=' ' [CMP,DEBUG] java.lang.IndexOutOfBoundsException: Index: -1, Size: 0 [CMP,DEBUG] at java.util.ArrayList.RangeCheck(ArrayList.java:491) [CMP,DEBUG] at java.util.ArrayList.remove(ArrayList.java:375) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.ejbql.Assembly.pop(Assembly.java:55) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.jdbc.ejbql.EJBQLParser$5.workOn(EJBQLParser.java:250) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.ejbql.Parser.matchAndAssemble(Parser.java:22) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.ejbql.Optional.match(Optional.java:14) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.ejbql.Parser.matchAndAssemble(Parser.java:14) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.ejbql.Sequence.match(Sequence.java:25) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.ejbql.Parser.matchAndAssemble(Parser.java:14) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.ejbql.Parser.soleMatch(Parser.java:48) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLFinderCommand.(JDBCEJBQLFinderCommand.java:54) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.jdbc.JDBCCommandFactory.createEJBQLFinderCommand(JDBCCommandFactory.java:100) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.start(JDBCFindEntitiesCommand.java:89) [CMP,DEBUG] at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java:94) [CMP,DEBUG] at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:169) [CMP,DEBUG] at org.jboss.ejb.EntityContainer.start(EntityContainer.java:355) [CMP,DEBUG] at org.jboss.ejb.Application.start(Application.java:213) [CMP,DEBUG] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:384) [CMP,DEBUG] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:308) [CMP,DEBUG] at java.lang.reflect.Method.invoke(Native Method) [CMP,DEBUG] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [CMP,DEBUG] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [CMP,DEBUG] at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:492) [CMP,DEBUG] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:470) [CMP,DEBUG] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) [CMP,DEBUG] at java.lang.reflect.Method.invoke(Native Method) [CMP,DEBUG] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [CMP,DEBUG] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [CMP,DEBUG] at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:437) [CMP,DEBUG] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:221) [CMP,DEBUG] at org.jboss.ejb.AutoDeployer.startService(AutoDeployer.java:362) [CMP,DEBUG] at org.jboss.util.ServiceMBeanSupport.start(ServiceMBeanSupport.java:109) [CMP,DEBUG] at java.lang.reflect.Method.invoke(Native Method) [CMP,DEBUG] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [CMP,DEBUG] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [CMP,DEBUG] at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:506) [CMP,DEBUG] at $Proxy0.start(Unknown Source) [CMP,DEBUG] at org.jboss.system.ServiceController.deploy(ServiceController.java:138) [CMP,DEBUG] at java.lang.reflect.Method.invoke(Native Method) [CMP,DEBUG] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) [CMP,DEBUG] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) [CMP,DEBUG] at org.jboss.deployment.ServiceDeployer.postRegister(ServiceDeployer.java:405) [CMP,DEBUG] at com.sun.management.jmx.MBeanServerImpl.postRegisterInvoker(MBeanServerImpl.java:2274) [CMP,DEBUG] at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:532) [CMP,DEBUG] at org.jboss.Main.(Main.java:231) [CMP,DEBUG] at org.jboss.Main$1.run(Main.java:134) [CMP,DEBUG] at java.security.AccessController.doPrivileged(Native Method) [CMP,DEBUG] at org.jboss.Main.main(Main.java:130) Dain Sundstrom wrote: > Right now there is no error handling in the ejb-ql parser. The problem with > your ejb-ql is you have status when you should have t.status. > > It should work then, > > -dain > > >>-Original Message- >>From: Dave Smith [mailto:[EMAIL PROTECTED]] >>Sent: Friday, August 31, 2001 8:12 AM >>To: [EMAIL PROTECTED] >>Subject: [JBoss-dev] EJB playing with finders >> >> >>I am trying a simple home method with a query >> >>Home method >> >>public java.util.Collection findByInQueue() >> throws java.rmi.RemoteException,javax.ejb.FinderException; >> >> >>ejb-jar.xml snippit >> >> >>select object(t) from transferhead t where status=' ' >> >>findByInQueue >> >> >> >>Remote >> >> >>Now there are two proble
[JBoss-dev] NOWAIT Option
Hello Guys, Sometime back I'd posted a query about being able to specify a NOWAIT / WAIT option for the 'select-for-update' bean level option. The change I'd suggested was simply to 1. Add a wait-option field in the jaws.xml file that held the exact string that was used to specify the wait option and gets appended to the select for update sql 2. Load this in the JawsEntityMetaData 3. Check for it and add it in the JDBCLoadEntityCommand. Does this sound sensible or completely off? Regards Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] TEST - please ignore
can I send emails from an unregistered email address? This electronic message (email) and any attachments to it are subject to copyright and are sent for the personal attention of the addressee. Although you may be the named recipient, it may become apparent that this email and its contents are not intended for you and an addressing error has been made. This email may include information that is legally privileged and exempt from disclosure. If you have received this email in error, please advise us immediately and delete this email and any attachments from your computer system.Rabobank International is the trading name of Coöperatieve Centrale Raiffeisen-Boerenleenbank B.A. which is incorporated in the Netherlands. Registered with the Registrar of Companies for England & Wales No. BR002630 and regulated by the SFA for the conduct of investment business in the UK. The presence of this footnote also confirms that this email has been automatically checked by Rabobank International for the presence of computer viruses prior to it being sent, however, no guarantee is given or implied that this email is virus free upon delivery. == ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.xml
User: kimptoc Date: 01/09/03 02:10:12 Modified:jbossbuild.xml Log: added some debug info on email sender Revision ChangesPath 1.15 +6 -1 build/jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/build/jboss/build.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- build.xml 2001/09/02 19:29:38 1.14 +++ build.xml 2001/09/03 09:10:12 1.15 @@ -10,7 +10,7 @@ - + @@ -596,7 +596,12 @@ + Sending Reports + + + + https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: build/jboss build.xml
Hi,
--- Jason Dillon <[EMAIL PROTECTED]> wrote:
> why mail over mimemail?
>
> --jason
>
>
> On Sun, 2 Sep 2001, Chris Kimpton wrote:
>
> > User: kimptoc
> > Date: 01/09/02 12:29:38
> >
> > - > - subject="Automated JBoss Testsuite"
> > - message="Automated JBoss Testsuite"
> > - from="[EMAIL PROTECTED]">
> > -
> > -
> > -
> > -
> > + > + subject="Automated JBoss Testsuite Results"
> > + message="Automated JBoss Testsuite Results"
> > + from="${run.nightly.email.from}"
> > + mailhost="${run.nightly.email.mailhost}"
> > +
>
files="${project.root}/testsuite/output/reports/text/TESTS-TestSuites.txt"
> > +/>
> > +
> > +
> > +
Laziness ;-)
ant complained that it did not recognise the mimemail task - and I
could not see it - until I upgraded my docs to be ant1.4beta2 - and
then I saw it was an optional task - I was too lazy to amend the
build.xml to recognise the task - especially when mail worked without
any extra config at least so I thought - but where are the daily
testing results this morning - according to the log files they were
sent...
Chris
=
Need somewhere to Live in London - http://freeflats.com
__
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] security exception in 2.4 final
Could anybody reproduce this error? I would very appreciate any help because I need to update my application to 2.4 final! With rel 23 I run sometimes (can't reproduce it after restart of jBoss) in this error: [Default] java.lang.IllegalStateException: No transaction. [Default] at org.jboss.tm.TransactionImpl.registerSynchronization(TransactionImpl.java:13 5) I got the hint, that this may be an error fixed in the final release. Andreas > -Original Message- > From: Schouten, Andreas [SMTP:[EMAIL PROTECTED]] > Sent: 28 August 2001 11:58 > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] security exception in 2.4 final > > Hi Scott, > > the error is not in the DatabaseServerLoginModul. The username being > passed > to it is null (or "null"). > The error only occurs if the container creates a new instance of the > called > stateless session bean. I stored a timestamp as menber variable in the SB > and print it on every call. As long this instance is used no security > exception occurs. > > You should be able to reproduce the problem if You include a sequence of > jsp > includes in a jsp. > > > > > > > > > > > > > > > where test.jsp looks up a stateless session bean which respond data fromn > an > entity bean. > > The data is displayed correct once but the next includes cause the > security > exception. With jBoss rel 23 the includes are processed correct each with > an > own instance of the SB. > > Andreas > > > -Original Message- > > From: Scott M Stark [SMTP:[EMAIL PROTECTED]] > > Sent: 24 August 2001 17:15 > > To: [EMAIL PROTECTED] > > Subject:Re: [JBoss-dev] security exception in 2.4 final > > > > That doesn't narrow the issue down as I can perform this type of access > > pattern without > > seeing a problem. What is the username/principal being passed to the > > DatabaseServerLoginModule > > for authentication when you see the failure? > > > > If you have a test ear that reproduces the problem I can look into the > > issue > > myself. > > > > - Original Message - > > From: "Schouten, Andreas" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Friday, August 24, 2001 1:35 AM > > Subject: RE: [JBoss-dev] security exception in 2.4 final > > > > > > > I reproduced the error today. > > > back to 2.4.0.23 o.k > > > -> 2.4.0.26 faild > > > -> 2.4.0.23 o.k > > > -> 2.4.0 faild > > > > > > fist I copied my jboss.jcml from the 23 release but in the last test I > > > merged my configuration into the jBoss.jcml from final release. > > > > > > I will descripe the steps leading to the error more, perhaps You can > > give > > my > > > a hint how I can locate the problem. > > > > > > 1. Login with a customised login page. -> succsessful > > > 2. The fist page contains only data from tomcat (no remote calls) > > > 3. The second page is genarated with several remote calls. Several > > stateles > > > SB's and EB's are created. > > > 4. The generation of the third (this is the second thread which calls > > beans) > > > fails with the security exception. > > > > > > > > > > > > > > > > -Original Message- > > > > From: Scott M Stark [SMTP:[EMAIL PROTECTED]] > > > > Sent: 23 August 2001 21:04 > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-dev] security exception in 2.4 final > > > > > > > > This is the binary I am using for the JBossStore site and I don't > see > > this > > > > problem for restricted content. The example2 in the JAAS tutorial > also > > > > uses the DatabaseServerLoginModule and creates a stateless session > > bean > > > > on each access and this does not show this problem. > > > > > > > > Is the username in the database when this starts to fail? > > > > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
