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. jsp:include page=test.jsp flush=true jsp:param name=name value=d1/ /jsp:include jsp:include page=test.jsp flush=true jsp:param name=name value=d2/ /jsp:include jsp:include page=test.jsp flush=true jsp:param name=name value=d3/ /jsp:include jsp:include page=test.jsp flush=true jsp:param name=name value=d4/ /jsp:include 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
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
!-- email output to list --
-mimemail tolist=[EMAIL PROTECTED]
- subject=Automated JBoss Testsuite
- message=Automated JBoss Testsuite
- from=[EMAIL PROTECTED]
- fileset dir=${project.root}/testsuite/output/reports
-include name=text/**/
- /fileset
-/mimemail
+mail tolist=${run.nightly.email.tolist}
+ 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
[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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.14 2001/09/02 19:29:38 kimptoc Exp $ --
+!-- $Id: build.xml,v 1.15 2001/09/03 09:10:12 kimptoc Exp $ --
project default=main
@@ -596,7 +596,12 @@
/target
target name=run-nightly-email depends=init
+
echoSending Reports/echo
+echo message=to: ${run.nightly.email.tolist}/
+echo message=from: ${run.nightly.email.from}/
+echo message=via: ${run.nightly.email.mailhost}/
+
!-- email output to list --
mail tolist=${run.nightly.email.tolist}
subject=Automated JBoss Testsuite Results
___
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
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.init(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.init(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 query ejb-qlselect object(t) from transferhead t where status=' '/ejb-ql query-method method-namefindByInQueue/method-name method-params /method-params
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 setfield and getfield 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] 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] 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.sh|bat scripts. --jason ___ 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 @@ ?xml version=1.0 encoding=UTF-8? -!-- $Id: fancy.xsl,v 1.2 2001/08/30 19:41:10 tmcsys Exp $ -- +!-- $Id: fancy.xsl,v 1.3 2001/09/03 20:02:38 user57 Exp $ -- xsl:stylesheet xmlns:xsl=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 - xsl:import href=@oasis.docbook.xsl.root@/html/chunk.xsl/ + xsl:import href=file:[EMAIL PROTECTED]@/html/chunk.xsl/ xsl:param name=html.stylesheetstyles.css/xsl:param xsl:param name=toc.section.depth1/xsl:param ___ 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 a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
- * @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: 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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.8 2001/09/02 20:57:23 kimptoc Exp $ --
+!-- $Id: build.xml,v 1.9 2001/09/03 20:21:34 kimptoc Exp $ --
project default=main
@@ -1529,7 +1529,10 @@
fileset dir=${build.reports}
include name=TEST-*.xml/
/fileset
- report format=frames todir=${build.reports}/html/
+ report format=frames
+ todir=${build.reports}/html
+ styledir=${build.stylesheets}
+ /
/junitreport
/target
___
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
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] 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.bin|sh, 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] 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. : mbean code=org.jboss.jetty.JettyService name=:service=Jetty attribute name=JettyHome/home/jules/java/Jetty-3.1.RC8/attribute attribute name=Configuration../conf/default/jetty.xml/attribute attribute name=WebDefault../conf/default/webdefault.xml/attribute attribute name=UnpackWarstrue/attribute attribute name=PublishMBeanstrue/attribute /mbean 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] 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 a href=mailto:[EMAIL PROTECTED];Kevin Lewis/a
-@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] 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. jsp:include page=test.jsp flush=true jsp:param name=name value=d1/ /jsp:include jsp:include page=test.jsp flush=true jsp:param name=name value=d2/ /jsp:include jsp:include page=test.jsp flush=true jsp:param name=name value=d3/ /jsp:include jsp:include page=test.jsp flush=true jsp:param name=name value=d4/ /jsp:include 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: 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
[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 - attribute name=BeanCacheJMSMonitoringEnabledfalse/attribute -/mbean - -! !-- Uncomment to add embedded tomcat service -mbean code=org.jboss.tomcat.EmbeddedTomcatServiceSX name=DefaultDomain:service=EmbeddedTomcat / ---- - -!-- Uncomment and set file URL to add Jetty service (you can set config more than once) -mbean code=org.jboss.jetty.JettyService name=DefaultDomain:service=Jetty + attribute name=BeanCacheJMSMonitoringEnabledfalse/attribute +/mbean + +! !-- Uncomment to add embedded tomcat service +mbean code=org.jboss.tomcat.EmbeddedTomcatServiceSX name=DefaultDomain:service=EmbeddedTomcat / +--- + +!-- Uncomment and set file URL to add Jetty service (you can set config more than once) +mbean code=org.jboss.jetty.JettyService name=DefaultDomain:service=Jetty --- 154,161 - attribute name=BeanCacheJMSMonitoringEnabledfalse/attribute -/mbean - -! !-- Uncomment to add embedded tomcat service -- -mbean code=org.jboss.tomcat.EmbeddedTomcatServiceSX name=DefaultDomain:service=EmbeddedTomcat / - -!-- Uncomment and set file URL to add Jetty service (you can set config more than once) -mbean code=org.jboss.jetty.JettyService name=DefaultDomain:service=Jetty + attribute name=BeanCacheJMSMonitoringEnabledfalse/attribute +/mbean + +! !-- Uncomment to add embedded tomcat service -- +mbean code=org.jboss.tomcat.EmbeddedTomcatServiceSX name=DefaultDomain:service=EmbeddedTomcat / + +!-- Uncomment and set file URL to add Jetty service (you can set config more than once) +mbean code=org.jboss.jetty.JettyService name=DefaultDomain:service=Jetty ___ 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 @@ servlet-classorg.jboss.test.web.servlets.DebugServlet/servlet-class /servlet servlet +servlet-nameIncludeServlet/servlet-name +servlet-classorg.jboss.test.web.servlets.IncludeServlet/servlet-class +/servlet +servlet +servlet-nameSecureIncludeServlet/servlet-name +servlet-classorg.jboss.test.web.servlets.IncludeServlet/servlet-class +/servlet +servlet servlet-nameSecureServlet/servlet-name servlet-classorg.jboss.test.web.servlets.SecureServlet/servlet-class /servlet @@ -39,6 +47,10 @@ servlet-classorg.jboss.test.web.servlets.SecureEJBServlet/servlet-class /servlet servlet +servlet-nameUnsecureEJBServlet/servlet-name + servlet-classorg.jboss.test.web.servlets.UnsecureEJBServlet/servlet-class +/servlet +servlet servlet-nameSecureEJBServletMT/servlet-name servlet-classorg.jboss.test.web.servlets.SecureEJBServletMT/servlet-class /servlet @@ -50,6 +62,14 @@ servlet-nameclasspath/servlet-name jsp-file/classpath.jsp/jsp-file /servlet +servlet +servlet-namerestricted/include_ejb.jsp/servlet-name +jsp-file/restricted/include_ejb.jsp/jsp-file +/servlet +servlet +servlet-namerestricted/ejb.jsp/servlet-name +jsp-file/restricted/ejb.jsp/jsp-file +/servlet !-- Default Apache SOAP 2.2 Servlets -- servlet servlet-namerpcrouter/servlet-name @@ -102,6 +122,14 @@ url-pattern/ClientLoginServlet/url-pattern /servlet-mapping servlet-mapping +servlet-nameIncludeServlet/servlet-name +url-patternIncludeServlet/url-pattern +/servlet-mapping +servlet-mapping +servlet-nameSecureIncludeServlet/servlet-name +url-pattern/restricted/IncludeServlet/url-pattern +/servlet-mapping +servlet-mapping servlet-nameSecureServlet/servlet-name url-pattern/restricted/SecureServlet/url-pattern /servlet-mapping @@ -110,6 +138,10 @@ url-pattern/restricted/SecureEJBAccess/url-pattern /servlet-mapping servlet-mapping +servlet-nameUnsecureEJBServlet/servlet-name +url-patternUnsecureEJBAccess/url-pattern +/servlet-mapping +servlet-mapping servlet-nameSecureEJBServletMT/servlet-name url-pattern/restricted/SecureEJBAccessMT/url-pattern /servlet-mapping @@ -173,7 +205,7 @@ http-methodDELETE/http-method /web-resource-collection auth-constraint -descriptionOnly /description +descriptionOnly authenticated users can access secure content/description role-nameAuthorizedUser/role-name /auth-constraint user-data-constraint ___ 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/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(html);
-out.println(headtitleENCServlet/title/head);
+if( includeHead == true )
+{
+ response.setContentType(text/html);
+ out.println(html);
+ out.println(headtitleENCServlet/title/headbody);
+}
out.println(h1SecureServlet Accessed/h1);
-out.println(bodypreYou have accessed this servlet as user: +user);
+out.println(preYou have accessed this servlet as user: +user);
out.println(You have accessed SecuredEJB as user: +echoMsg);
-out.println(/pre/body/html);
+out.println(/pre);
+if( includeHead == true )
+ out.println(/pre/body/html);
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(html);
-out.println(headtitleENCServlet/title/head);
+out.println(headtitleSecureServlet/title/head);
out.println(h1SecureServlet Accessed/h1);
out.println(bodyYou have accessed this servlet as user:+user+/body);
out.println(/html);
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/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;
+
+ Integer port =
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: 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 related
* @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
[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 Binary file ___ 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
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
[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=detailatid=376685aid=458168group_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 attribute name=PrincipalMappingProperties userName=me password=mypw /attribute 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=detailatid=376685aid=458168group_id=22866 ___ 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
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] 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
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
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
[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 a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
* @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 a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
- * @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 a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
+ * @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a.
+ * @author a href=mailto:[EMAIL PROTECTED];Daniel OConnor/a
+ * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
+ * @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
+ * @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
[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 @@ interceptororg.jboss.ejb.plugins.SecurityInterceptor/interceptor interceptororg.jboss.ejb.plugins.TxInterceptorCMT/interceptor interceptor metricsEnabled=trueorg.jboss.ejb.plugins.MetricsInterceptor/interceptor + interceptororg.jboss.ejb.plugins.EntityLockInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityInstanceInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntitySynchronizationInterceptor/interceptor /container-interceptors @@ -20,6 +21,7 @@ instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache persistence-managerorg.jboss.ejb.plugins.jaws.JAWSPersistenceManager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager + locking-policyorg.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock/locking-policy container-invoker-conf RMIObjectPort/RMIObjectPort OptimizedTrue/Optimized @@ -53,12 +55,14 @@ interceptororg.jboss.ejb.plugins.SecurityInterceptor/interceptor interceptororg.jboss.ejb.plugins.TxInterceptorCMT/interceptor interceptor metricsEnabled=trueorg.jboss.ejb.plugins.MetricsInterceptor/interceptor + interceptororg.jboss.ejb.plugins.EntityLockInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityInstanceInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntitySynchronizationInterceptor/interceptor /container-interceptors instance-poolorg.jboss.ejb.plugins.EntityInstancePool/instance-pool instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache persistence-managerorg.jboss.ejb.plugins.jaws.JAWSPersistenceManager/persistence-manager + locking-policyorg.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock/locking-policy transaction-managerorg.jboss.tm.TxManager/transaction-manager container-invoker-conf RMIObjectPort/RMIObjectPort @@ -233,6 +237,7 @@ interceptororg.jboss.ejb.plugins.SecurityInterceptor/interceptor interceptororg.jboss.ejb.plugins.TxInterceptorCMT/interceptor interceptor metricsEnabled=trueorg.jboss.ejb.plugins.MetricsInterceptor/interceptor + interceptororg.jboss.ejb.plugins.EntityLockInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityInstanceInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntitySynchronizationInterceptor/interceptor /container-interceptors @@ -240,6 +245,7 @@ instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache persistence-managerorg.jboss.ejb.plugins.BMPPersistenceManager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager + locking-policyorg.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock/locking-policy container-invoker-conf RMIObjectPort/RMIObjectPort OptimizedTrue/Optimized @@ -273,6 +279,7 @@ interceptororg.jboss.ejb.plugins.SecurityInterceptor/interceptor interceptororg.jboss.ejb.plugins.TxInterceptorCMT/interceptor interceptor metricsEnabled=trueorg.jboss.ejb.plugins.MetricsInterceptor/interceptor + interceptororg.jboss.ejb.plugins.EntityLockInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityInstanceInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntitySynchronizationInterceptor/interceptor /container-interceptors @@ -280,6 +287,7 @@ instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache
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: 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 @@ interceptororg.jboss.ejb.plugins.SecurityInterceptor/interceptor interceptororg.jboss.ejb.plugins.TxInterceptorCMT/interceptor interceptor metricsEnabled=trueorg.jboss.ejb.plugins.MetricsInterceptor/interceptor +interceptororg.jboss.ejb.plugins.EntityLockInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityInstanceInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntitySynchronizationInterceptor/interceptor /container-interceptors @@ -18,6 +19,7 @@ instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache persistence-managerorg.jboss.ejb.plugins.BMPPersistenceManager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager + locking-policyorg.jboss.ejb.plugins.lock.SimplePessimisticEJBLock/locking-policy container-invoker-conf RMIObjectPort/RMIObjectPort OptimizedTrue/Optimized ___ 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. |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/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 @@ interceptororg.jboss.ejb.plugins.SecurityInterceptor/interceptor interceptororg.jboss.ejb.plugins.TxInterceptorCMT/interceptor interceptor metricsEnabled=trueorg.jboss.ejb.plugins.MetricsInterceptor/interceptor + interceptororg.jboss.ejb.plugins.EntityLockInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityInstanceInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntitySynchronizationInterceptor/interceptor /container-interceptors @@ -20,6 +21,7 @@ instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache persistence-managerorg.jboss.ejb.plugins.jaws.JAWSPersistenceManager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager + locking-policyorg.jboss.ejb.plugins.lock.SimplePessimisticEJBLock/locking-policy container-invoker-conf !-- RMIObjectPort/RMIObjectPort -- OptimizedTrue/Optimized @@ -53,6 +55,7 @@ interceptororg.jboss.ejb.plugins.SecurityInterceptor/interceptor interceptororg.jboss.ejb.plugins.TxInterceptorCMT/interceptor interceptor metricsEnabled=trueorg.jboss.ejb.plugins.MetricsInterceptor/interceptor + interceptororg.jboss.ejb.plugins.EntityLockInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityInstanceInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntitySynchronizationInterceptor/interceptor /container-interceptors @@ -60,6 +63,7 @@ instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache persistence-managerorg.jboss.ejb.plugins.jaws.JAWSPersistenceManager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager + locking-policyorg.jboss.ejb.plugins.lock.SimplePessimisticEJBLock/locking-policy container-invoker-conf !-- RMIObjectPort/RMIObjectPort -- OptimizedTrue/Optimized @@ -93,6 +97,7 @@ interceptororg.jboss.ejb.plugins.SecurityInterceptor/interceptor interceptororg.jboss.ejb.plugins.TxInterceptorCMT/interceptor interceptor metricsEnabled=trueorg.jboss.ejb.plugins.MetricsInterceptor/interceptor + interceptororg.jboss.ejb.plugins.EntityLockInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityInstanceInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntitySynchronizationInterceptor/interceptor /container-interceptors @@ -100,6 +105,7 @@ instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache persistence-managerorg.jboss.ejb.plugins.jaws.JAWSPersistenceManager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager + locking-policyorg.jboss.ejb.plugins.lock.SimplePessimisticEJBLock/locking-policy container-invoker-conf !-- RMIObjectPort/RMIObjectPort -- OptimizedTrue/Optimized @@ -133,6 +139,7 @@ interceptororg.jboss.ejb.plugins.SecurityInterceptor/interceptor interceptororg.jboss.ejb.plugins.TxInterceptorCMT/interceptor interceptor metricsEnabled=trueorg.jboss.ejb.plugins.MetricsInterceptor/interceptor + interceptororg.jboss.ejb.plugins.EntityLockInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntityInstanceInterceptor/interceptor interceptororg.jboss.ejb.plugins.EntitySynchronizationInterceptor/interceptor /container-interceptors @@ -140,6 +147,7 @@ instance-cacheorg.jboss.ejb.plugins.EntityInstanceCache/instance-cache persistence-managerorg.jboss.ejb.plugins.jaws.JAWSPersistenceManager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager + locking-policyorg.jboss.ejb.plugins.lock.SimplePessimisticEJBLock/locking-policy container-invoker-conf !-- RMIObjectPort/RMIObjectPort -- OptimizedTrue/Optimized @@ -163,6 +171,259 @@ /container-pool-conf commit-optionD/commit-option /container-configuration + container-configuration + container-nameEntityBean_A_Queued/container-name +
[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, EnterpriseEntity_D);
+ }
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
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
[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 dataDirURL;
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
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
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 Set name=LogSink New class=org.mortbay.util.OutputStreamLogSink ArgSystemProperty name=jetty.log default=./logs//_mm_dd.request.log/Arg Set name=RetainDays90/Set Set name=Appendtrue/Set Set name=flushOnfalse/Set /New /Set 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: Call name=addContext Arg//Arg Set name=ClassPathSystemProperty name=jetty.home default=.//servlets//Set Set name=DynamicServletPathSpec/servlet/*/Set Get name=ServletHandler Set name=ServeDynamicSystemServlets type=booleanFALSE/Set /Get 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: Configure jmxname=org.mortbay.jetty:name=Jetty,Server=0 Set name=statsOn type=booleanFALSE/Set Call name=addListener Arg New class=org.mortbay.http.SocketListener Set name=portSystemProperty name=application.portno default=8080//Set Set name=minThreads5/Set Set name=maxThreads255/Set Set name=maxIdleTimeMs6/Set Set name=maxReadTimeMs6/Set /New /Arg /Call Set name=logSink New class=org.mortbay.util.WriterLogSink ArgSystemProperty name=application.log default=./logs//_mm_dd.request.log/Arg Set name=retainDays90/Set Set name=appendtrue/Set /New /Set Call name=start/ /Configure 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: Configure jmxname=org.mortbay.jetty:name=Jetty,Server=0 Set name=statsOn type=booleanFALSE/Set Call name=addListenerArgNew class=com.mortbay.HTTP.SocketListener//Arg/Call Set name=logSinkNew class=com.mortbay.Util.WriterLogSink//Set Call name=start/ /Configure Configure
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
[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) ?xml version = 1.0 encoding = UTF-8? policy application-policy name = other authorization grant permission code = java.security.AllPermission/ /grant /authorization /application-policy /policy ___ 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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.8 2001/08/27 09:01:36 user57 Exp $ --
+!-- $Id: build.xml,v 1.9 2001/09/04 05:08:07 user57 Exp $ --
-project default=main
+project default=main name=JBoss/J2EE
!-- == --
!-- Initialization --
@@ -154,7 +154,7 @@
!-- Override JUnit defaults --
property name=junit.timeout value=24/ !-- 4 minutes --
property name=junit.batchtest.todir value=${build.reports}/
- property name=junit.jvm.options value=-client/
+ property name=junit.jvm.options value=-Ddummy/
!-- Where source files live --
property name=source.java value=${module.source}/main/
@@ -168,26 +168,8 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
-
!-- == --
!-- Compile--
@@ -310,35 +292,18 @@
target name=release depends=all
description=Builds a release distribution.
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${release.lib.ext}/
-copy todir=${release.lib.ext} filtering=no
- fileset dir=${build.jars}
- include name=jboss-j2ee.jar/
- /fileset
-/copy
-
-!-- Copy the generated libraries (client) --
-mkdir dir=${release.client}/
-copy todir=${release.client} filtering=no
- fileset dir=${build.jars}
- include name=jboss-j2ee.jar/
- /fileset
-/copy
-
-!-- Copy the generated javadocs --
-mkdir dir=${release.module.api}/
-copy todir=${release.module.api} filtering=no
- fileset dir=${build.api}
+!-- Copy the output directory to the release directory --
+mkdir dir=${release.root}/
+copy todir=${release.root} filtering=no
+ fileset dir=${module.build}
include name=**/*/
+ exclude name=${release.id}/**/
/fileset
/copy
/target
target
[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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.11 2001/08/27 09:01:36 user57 Exp $ --
+!-- $Id: build.xml,v 1.12 2001/09/04 05:08:08 user57 Exp $ --
-project default=main
+project default=main name=JBoss/Messaging
!-- == --
!-- Initialization --
@@ -237,7 +237,7 @@
!-- Override JUnit defaults --
property name=junit.timeout value=24/ !-- 4 minutes --
property name=junit.batchtest.todir value=${build.reports}/
- property name=junit.jvm.options value=-client/
+ property name=junit.jvm.options value=-Ddummy/
!-- RMIC should generate stubs compatible with Java 1.2+ --
property name=rmic.stubVersion value=1.2/
@@ -270,27 +270,9 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
-
!-- == --
!-- Pretty --
!-- == --
@@ -538,75 +520,20 @@
!-- Builds a release distribution. --
!-- == --
- target name=release depends=all, release-dependencies
+ target name=release depends=all
description=Builds a release distribution.
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${release.lib.ext}/
-copy todir=${release.lib.ext} filtering=no
- fileset dir=${build.jars}
- include name=jbossmq.jar/
- /fileset
-/copy
-
-!-- Copy the generated libraries (client) --
-mkdir dir=${release.client}/
-copy todir=${release.client} filtering=no
- fileset dir=${build.jars}
- include name=*-client.jar/
- /fileset
-/copy
-
-!-- Copy the static documents (docs) --
-mkdir dir=${release.module.docs}/
-copy todir=${release.module.docs} filtering=no
- fileset dir=${build.docs}
- include
[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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.6 2001/08/27 09:01:37 user57 Exp $ --
+!-- $Id: build.xml,v 1.7 2001/09/04 05:08:08 user57 Exp $ --
-project default=main
+project default=main name=JBoss/Security
!-- == --
!-- Initialization --
@@ -239,6 +239,7 @@
!-- Override JUnit defaults --
property name=junit.timeout value=24/ !-- 4 minutes --
property name=junit.batchtest.todir value=${build.reports}/
+ property name=junit.jvm.options value=-Ddummy/
!-- RMIC should generate stubs compatible with Java 1.2+ --
property name=rmic.stubVersion value=1.2/
@@ -257,27 +258,9 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
-
!-- == --
!-- Compile--
!-- == --
@@ -317,10 +300,6 @@
classpath refid=javac.classpath/
include name=${javac.includes}/
exclude name=${javac.excludes}/
-
- !-- Currently needs HSQL
- exclude name=org/jboss/test/**/
- --
/javac
/target
@@ -488,59 +467,20 @@
!-- Builds a release distribution. --
!-- == --
- target name=release depends=all, release-dependencies
+ target name=release depends=all
description=Builds a release distribution.
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${release.lib.ext}/
-copy todir=${release.lib.ext} filtering=no
- fileset dir=${build.jars}
- include name=jbosssx.jar/
- include name=jaas.jar/
- /fileset
-/copy
-
-!-- Copy the generated libraries (client) --
-mkdir dir=${release.client}/
-copy todir=${release.client} filtering=no
- fileset dir=${build.jars}
- include
[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 @@
!-- $Id$ --
-project default=main
+project default=main name=JBoss Plugins/Jetty
!-- == --
!-- Initialization --
@@ -224,27 +224,9 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
-
!-- == --
!-- Compile--
!-- == --
@@ -371,50 +353,20 @@
!-- Builds a release distribution. --
!-- == --
- target name=release depends=all, release-dependencies
+ target name=release depends=all
description=Builds a release distribution.
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${release.lib.ext}/
-copy todir=${release.lib.ext} filtering=no
- fileset dir=${build.jars}
- include name=**/*/
- /fileset
-/copy
-
-!-- Copy the default configuration files (conf/default) --
-mkdir dir=${release.conf.default}/
-copy todir=${release.conf.default} filtering=no
- fileset dir=${build.etc}
- include name=jetty.xml/
- include name=jetty.properties/
- /fileset
-/copy
-
-!-- Copy the generated javadocs (docs/api/module) --
-mkdir dir=${release.module.api}/
-copy todir=${release.module.api} filtering=no
- fileset dir=${build.api}
+!-- Copy the output directory to the release directory --
+mkdir dir=${release.root}/
+copy todir=${release.root} filtering=no
+ fileset dir=${module.build}
include name=**/*/
+ exclude name=${release.id}/**/
/fileset
/copy
/target
- target name=release-dependencies depends=init
-mkdir dir=${release.lib.ext}/
-copy todir=${release.lib.ext} filtering=no
- fileset dir=${mortbay.jetty.lib}
-include name=**/*.jar/
- /fileset
- fileset dir=${mortbay.jetty3extra.jmx.lib}
-include name=**/*.jar/
- /fileset
-/copy
- /target
-
target name=release-archive-prepare depends=release
mkdir dir=${module.release}/
-property name=release.archive.basename
- value=${module.release}/${release.id}/
/target
target name=release-zip depends=release-archive-prepare
[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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.9 2001/09/03 20:21:34 kimptoc Exp $ --
+!-- $Id: build.xml,v 1.10 2001/09/04 05:08:09 user57 Exp $ --
-project default=main
+project default=main name=JBoss/Testsuite
!-- == --
!-- Initialization --
@@ -281,27 +281,9 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
-
!-- == --
!-- Pretty --
!-- == --
@@ -1284,13 +1266,18 @@
target name=release depends=all
description=Builds a release distribution.
-!-- currently there is no release for this module --
+!-- Copy the output directory to the release directory --
+mkdir dir=${release.root}/
+copy todir=${release.root} filtering=no
+ fileset dir=${module.build}
+ include name=**/*/
+ exclude name=${release.id}/**/
+ /fileset
+/copy
/target
target name=release-archive-prepare depends=release
mkdir dir=${module.release}/
-property name=release.archive.basename
- value=${module.release}/${release.id}/
/target
target name=release-zip depends=release-archive-prepare
@@ -1618,8 +1605,5 @@
target name=most depends=jars
description=Builds almost everything./
-
- target name=min depends=compile
- description=Builds a minimal subset./
/project
___
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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.8 2001/08/27 09:01:37 user57 Exp $ --
+!-- $Id: build.xml,v 1.9 2001/09/04 05:08:08 user57 Exp $ --
-project default=main
+project default=main name=JBoss/Pool
!-- == --
!-- Initialization --
@@ -203,7 +203,7 @@
!-- Override JUnit defaults --
property name=junit.timeout value=24/ !-- 4 minutes --
property name=junit.batchtest.todir value=${build.reports}/
- property name=junit.jvm.options value=-client/
+ property name=junit.jvm.options value=-Ddummy/
!-- Where source files live --
property name=source.java value=${module.source}/main/
@@ -237,27 +237,9 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
-
!-- == --
!-- Pretty --
!-- == --
@@ -452,35 +434,18 @@
target name=release depends=all
description=Builds a release distribution.
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${release.lib.ext}/
-copy todir=${release.lib.ext} filtering=no
- fileset dir=${build.jars}
- include name=jbosspool.jar/
- /fileset
-/copy
-
-!-- Copy the generated deployment libraries (deploy/lib) --
-mkdir dir=${release.deploy.lib}/
-copy todir=${release.deploy.lib} filtering=no
- fileset dir=${build.jars}
- include name=*.rar/
- /fileset
-/copy
-
-!-- Copy the generated javadocs (docs/api/module) --
-mkdir dir=${release.module.api}/
-copy todir=${release.module.api} filtering=no
- fileset dir=${build.api}
+!-- Copy the output directory to the release directory --
+mkdir dir=${release.root}/
+copy todir=${release.root} filtering=no
+ fileset dir=${module.build}
include name=**/*/
+
[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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.6 2001/08/27 09:01:37 user57 Exp $ --
+!-- $Id: build.xml,v 1.7 2001/09/04 05:08:08 user57 Exp $ --
-project default=main
+project default=main name=JBoss Plugins/Varia
!-- == --
!-- Initialization --
@@ -267,7 +267,7 @@
!-- Override JUnit defaults --
property name=junit.timeout value=24/ !-- 4 minutes --
property name=junit.batchtest.todir value=${build.reports}/
- property name=junit.jvm.options value=-client/
+ property name=junit.jvm.options value=-Ddummy/
!-- RMIC should generate stubs compatible with Java 1.2+ --
property name=rmic.stubVersion value=1.2/
@@ -288,27 +288,9 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
-
!-- == --
!-- Compile--
!-- == --
@@ -478,63 +460,20 @@
!-- Builds a release distribution. --
!-- == --
- target name=release depends=all, release-dependencies
+ target name=release depends=all
description=Builds a release distribution.
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${release.lib.ext}/
-copy todir=${release.lib.ext} filtering=no
- fileset dir=${build.jars}
- include name=**/
- /fileset
-/copy
-
-!-- Copy the generated javadocs (docs/api/module) --
-mkdir dir=${release.module.api}/
-copy todir=${release.module.api} filtering=no
- fileset dir=${build.api}
+!-- Copy the output directory to the release directory --
+mkdir dir=${release.root}/
+copy todir=${release.root} filtering=no
+ fileset dir=${module.build}
include name=**/*/
+ exclude
[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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.6 2001/08/27 09:01:36 user57 Exp $ --
+!-- $Id: build.xml,v 1.7 2001/09/04 05:08:07 user57 Exp $ --
-project default=main
+project default=main name=JBoss/Cluster
!-- == --
!-- Initialization --
@@ -228,7 +228,7 @@
!-- Override JUnit defaults --
property name=junit.timeout value=24/ !-- 4 minutes --
property name=junit.batchtest.todir value=${build.reports}/
- property name=junit.jvm.options value=-client/
+ property name=junit.jvm.options value=-Ddummy/
!-- RMIC should generate stubs compatible with Java 1.2+ --
property name=rmic.stubVersion value=1.2/
@@ -249,25 +249,8 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
!-- == --
!-- Compile--
@@ -446,44 +429,18 @@
target name=release depends=all
description=Builds a release distribution.
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${release.lib.ext}/
-copy todir=${release.lib.ext} filtering=no
- fileset dir=${build.jars}
- include name=jbossmx.jar/
- include name=jbossha.jar/
- /fileset
-/copy
-
-!-- Copy the generated libraries (client) --
-mkdir dir=${release.client}/
-copy todir=${release.client} filtering=no
- fileset dir=${build.jars}
- include name=jbossha-client.jar/
- /fileset
-/copy
-
-!-- Copy the static documents (docs) --
-mkdir dir=${release.module.docs}/
-copy todir=${release.module.docs} filtering=no
+!-- Copy the output directory to the release directory --
+mkdir dir=${release.root}/
+copy todir=${release.root} filtering=no
fileset dir=${module.build}
- include name=examples/*/
- /fileset
-/copy
-
-!-- Copy the generated javadocs (docs/api/module) --
-
[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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.5 2001/08/27 09:01:35 user57 Exp $ --
+!-- $Id: build.xml,v 1.6 2001/09/04 05:08:06 user57 Exp $ --
-project default=main
+project default=main name=JBoss/Admin
!-- == --
!-- Initialization --
@@ -195,7 +195,7 @@
!-- Override JUnit defaults --
property name=junit.timeout value=24/ !-- 4 minutes --
property name=junit.batchtest.todir value=${build.reports}/
- property name=junit.jvm.options value=-client/
+ property name=junit.jvm.options value=-Ddummy/
!-- ejbdoclet bits --
path id=dreambean.ejbdoclet.task.classpath
@@ -225,33 +225,9 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
-
- !-- Not really sure why these are here --
- property name=release.admin value=${release.root}/admin/
- property name=release.admin.client value=${release.admin}/client/
- property name=release.admin.client.lib value=${release.admin.client}/lib/
- property name=release.admin.components value=${release.admin}/components/
-
!-- == --
!-- Compile--
!-- == --
@@ -477,68 +453,46 @@
target name=release depends=all
description=Builds a release distribution.
-!-- Copy the generated scripts runnable jars (bin) --
-mkdir dir=${release.bin}/
-copy todir=${release.bin} filtering=no
- fileset dir=${build.bin}
- include name=**/*/
- /fileset
-/copy
-!-- since copy does not preserve permissions, do this here (again) --
-!-- need to create unix scripts !!!
-chmod perm=+x
- fileset dir=${build.bin}
- include name=**/*.sh/
- /fileset
-/chmod
---
-
-!-- Copy the generated javadocs (docs/api/module) --
-mkdir dir=${release.module.api}/
-copy
[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: 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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.7 2001/09/03 02:14:45 d_jencks Exp $ --
+!-- $Id: build.xml,v 1.8 2001/09/04 05:08:07 user57 Exp $ --
-project default=main
+project default=main name=JBoss/Connector
!-- == --
!-- Initialization --
@@ -212,27 +212,9 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
-
!-- == --
!-- Pretty --
!-- == --
@@ -373,27 +355,18 @@
target name=release depends=all
description=Builds a release distribution.
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${release.lib.ext}/
-copy todir=${release.lib.ext} filtering=no
- fileset dir=${build.jars}
- include name=jbosscx.jar/
- /fileset
-/copy
-
-!-- Copy the generated javadocs (docs/api/module) --
-mkdir dir=${release.module.api}/
-copy todir=${release.module.api} filtering=no
- fileset dir=${build.api}
+!-- Copy the output directory to the release directory --
+mkdir dir=${release.root}/
+copy todir=${release.root} filtering=no
+ fileset dir=${module.build}
include name=**/*/
+ exclude name=${release.id}/**/
/fileset
/copy
/target
target name=release-archive-prepare depends=release
mkdir dir=${module.release}/
-property name=release.archive.basename
- value=${module.release}/${release.id}/
/target
target name=release-zip depends=release-archive-prepare
@@ -510,8 +483,5 @@
target name=most depends=jars
description=Builds almost everything./
-
- target name=min depends=compile
- description=Builds a minimal subset./
/project
___
Jboss-development mailing list
[EMAIL
[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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.15 2001/09/03 09:10:12 kimptoc Exp $ --
+!-- $Id: build.xml,v 1.16 2001/09/04 05:08:06 user57 Exp $ --
-project default=main
+project default=main name=JBoss/Build
!-- == --
!-- Initialization --
@@ -42,21 +42,6 @@
!-- Initialize the build system. --
target name=init unless=project-initialized-already
depends=init-buildlog
-
-echo message=user.home = ${user.home}/
-echo message=build.compiler = ${build.compiler}/
-echo message=java.home = ${java.home}/
-echo message=java.class.path = ${java.class.path}/
-echo message=java.version = ${java.version}/
-echo message=java.vendor = ${java.vendor}/
-echo message=java.vm.version = ${java.vm.version}/
-echo message=java.vm.name = ${java.vm.name}/
-echo message=java.vm.info = ${java.vm.info}/
-echo message=os.name = ${os.name}/
-echo message=os.arch = ${os.name}/
-echo message=os.version = ${os.name}/
-echo message=/
-
tstamp
format property=build.number pattern=MMddHHmm/
/tstamp
@@ -73,6 +58,8 @@
resolver force=${buildmagic.resolveproperties.force}/
propertyfilter all=${buildmagic.propertyfilter.all}/
property name=project-initialized-already value=true/
+
+call target=show-environment/
/target
target name=init-buildlog unless=buildlog-disabled
@@ -80,6 +67,21 @@
property name=buildlog-disabled value=true/
/target
+ target name=show-environment if=build.verbose
+echo message=user.home = ${user.home}/
+echo message=build.compiler = ${build.compiler}/
+echo message=java.home = ${java.home}/
+echo message=java.class.path = ${java.class.path}/
+echo message=java.version = ${java.version}/
+echo message=java.vendor = ${java.vendor}/
+echo message=java.vm.version = ${java.vm.version}/
+echo message=java.vm.name = ${java.vm.name}/
+echo message=java.vm.info = ${java.vm.info}/
+echo message=os.name = ${os.name}/
+echo message=os.arch = ${os.name}/
+echo message=os.version = ${os.name}/
+ /target
+
!-- == --
!-- Project Configuration --
@@ -99,6 +101,99 @@
!-- == --
+ !-- Tool Configuration --
+ !-- == --
+
+ !-- No non-standard tools are required for this module. --
+
+
+ !-- == --
+ !-- Library Configuration --
+ !-- == --
+
+ !-- Java Naming and Directory Interface (JNDI) --
+ property name=sun.jndi.root value=${thirdparty.root}/sun/jndi/
+ property name=sun.jndi.lib value=${sun.jndi.root}/lib/
+
+ !-- Java Management Extensions (JMX) --
+ property name=sun.jmx.root value=${thirdparty.root}/sun/jmx/
+ property name=sun.jmx.lib
[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 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.5 2001/08/27 09:01:36 user57 Exp $ --
+!-- $Id: build.xml,v 1.6 2001/09/04 05:08:08 user57 Exp $ --
-project default=main
+project default=main name=JBoss/Naming
!-- == --
!-- Initialization --
@@ -163,7 +163,7 @@
!-- Override JUnit defaults --
property name=junit.timeout value=24/ !-- 4 minutes --
property name=junit.batchtest.todir value=${build.reports}/
- property name=junit.jvm.options value=-client/
+ property name=junit.jvm.options value=-Ddummy/
!-- RMIC should generate stubs compatible with Java 1.2+ --
property name=rmic.stubVersion value=1.2/
@@ -182,27 +182,9 @@
!-- Where release generated files will go --
property name=release.id value=${module.name}-${module.version}-${build.id}/
property name=release.root value=${module.release}/${release.id}/
+ property name=release.archive.basename
value=${module.release}/${release.id}/
- property name=release.bin value=${release.root}/bin/
- property name=release.client value=${release.root}/client/
- property name=release.conf value=${release.root}/conf/
- property name=release.conf.default value=${release.conf}/default/
- property name=release.db value=${release.root}/db/
- property name=release.deploy value=${release.root}/deploy/
- property name=release.deploy.lib value=${release.deploy}/lib/
- property name=release.lib value=${release.root}/lib/
- property name=release.lib.ext value=${release.lib}/ext/
- property name=release.log value=${release.root}/log/
- property name=release.tmp value=${release.root}/tmp/
-
- !-- Documentation and examples --
- property name=release.docs value=${release.root}/docs/
- property name=release.examples value=${release.docs}/examples/
- property name=release.api value=${release.docs}/api/
- property name=release.module.docs value=${release.docs}/${module.name}/
- property name=release.module.api value=${release.api}/${module.name}/
-
!-- == --
!-- Compile--
!-- == --
@@ -374,35 +356,18 @@
target name=release depends=all
description=Builds a release distribution.
-!-- Copy the generated libraries (lib/ext) --
-mkdir dir=${release.lib.ext}/
-copy todir=${release.lib.ext} filtering=no
- fileset dir=${build.jars}
- include name=jnpserver.jar/
- /fileset
-/copy
-
-!-- Copy the generated libraries (client) --
-mkdir dir=${release.client}/
-copy todir=${release.client} filtering=no
- fileset dir=${build.jars}
- include name=jnp-client.jar/
- /fileset
-/copy
-
-!-- Copy the generated javadocs --
-mkdir dir=${release.module.api}/
-copy todir=${release.module.api} filtering=no
- fileset dir=${build.api}
+!-- Copy the output directory to the release directory --
+mkdir dir=${release.root}/
+copy todir=${release.root} filtering=no
+ fileset dir=${module.build}
include name=**/*/
+ exclude name=${release.id}/**/
[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] 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 path elements to be created from inside of a target, so once I have finished updating the projects, I might look to moving everything that is currently outside of a target 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
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=detailatid=376685aid=458277group_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=detailatid=376685aid=458277group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
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 path elements to be created from inside of a target, so once I have finished updating the projects, I might look to moving everything that is currently outside of a target 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
