Looks like in Ant 1.5 Project.getProperties() returns a copy of the
properties map. The ExecuteModules task was dependent on removing the
value of 'module' and 'target' properties after a module had been
executing... bah!
--jason
---
This
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
Can someone with a win32 workspace, which they build out of regularly
using build.bat, please try to execute the build.sh script using
tools/bin/sh.exe:
..\tools\bin\sh.exe build.sh
I am hoping this will work well... if it does I would like to change the
build.bat files to simple invoke the
I just finished some cleansing of the buildsystem. The build.xml files
are much smaller now... as some of the complexity has moved to include
files. I will be working on simplification of those include files a
little later, as well as trying to increase the performance of the
build.
In case
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
I will get to fixing these projects shortly... chances are that none of
them will be functional.
Sorry for the inconvenience. I will try to have this fixed by tomorrow
evening.
FYI, I do not plan on back-porting any of the build system changes to
pre-HEAD jboss-all flavors.
--jason
I believe this might be resolved by forcing a full checkout... but I
can't get to lubega.com at the moment...
--jason
-Original Message-
From: [EMAIL PROTECTED] [mailto:jboss-
[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, October 03, 2002 4:48 AM
To: [EMAIL
If you have any questions or comments, please let me know.
(NO FLAMES PLEASE... my fragile psyche can't handle it... =P)
Thank you for these changes Jason. We all love you.
Cheers,
Sacha
---
This sf.net email
A side note about this...
If you want to keep working with you project before I can updated your
build files, I recommend that you do not update your workspace and that
you do not make any build.xml changes.
--jason
---
This sf.net email is
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
On 2002.10.03 02:00:12 -0400 Scott M Stark wrote:
Really? You want 2 complete sets of interceptor definititions with
exactly
the same functionality?
I don't. The whole ejb interceptor layer should be deprecated if not
replaced
in 4.0.
1. change all the ejb interceptors so they
Bugs item #614116, was opened at 2002-09-24 17:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=614116group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to:
Juha,
what you need to persist from the registry is the information to
recreate the mbeans
OK. Great. Sorry for the confusion. I think this information is
essentially the MBeanInfo, the object name, and possibly, a dependency
indicator (MB foo must be loaded after MB foobar).
here.
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
On Thu, 3 Oct 2002, Matt Munz wrote:
Juha,
what you need to persist from the registry is the information to
recreate the mbeans
OK. Great. Sorry for the confusion. I think this information is
essentially the MBeanInfo, the object name, and possibly, a dependency
indicator (MB foo
Well, I'm very interested. The work I do is spec-friendly.
An important selling point for us with JBoss is flexibility
via spec compliance. Since I see persistence as an
invaluable feature for JMX, having it be a full fledged
aspect of the spec is important for me. Perhaps if JBoss
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
Hi,
I've been working on this and have run into a problem that
I hope someone can clear up real quick. I'm trying to get
a list of the EJB's deployed within an EAR. I go through
DeploymentInfo.subDeployments, and it looks like what I
need to do is for each of these sub-deployments, get the
all that is needed is init, start, stop, destroy
On Thu, 3 Oct 2002, David Jencks wrote:
proposed mbean interceptor:
create
start
stop
destroy
setMBeanInvoker //not sure of name, this is like setContainer.
getNext
insert or setNext
invoke
Now, this is an mbean stack, so there needs
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
Bugs item #606704, was opened at 2002-09-09 15:05
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=606704group_id=22866
Category: JBossSX
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mathias Bogaert (pathoss)
Assigned to:
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
In principle I think this is a good idea. I'm not 100% sure the possible
implementation complexity will be worth the gains...
1. You can already redeploy a subpackage of even a packed .ear by using the
jmx console and MainDeployer.redeploy. You can do the same thing with the
ant jmx task.
Ok, but should the lifecycle of the interceptors be the same as the
lifecycle of the bean? Right now a service is an mbean that is
available through the jmx-console indepedenent of its JBoss service
lifecycle notion. How is that going to change if the dependency is
embedded into the interceptors?
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
On 2002.09.27 16:21:33 -0400 Igor Fedorenko wrote:
David Jencks wrote:
Hi Igor,
I'd like to stick with the jboss tm and add the needed functionality.
Can you outline what you have been thinking of?
I want to allow resource manager specific variation of XAResource state
change
The code you are looking for may be changed extensively by me in the near
future, I'm slowly migrating it to use the mbean framework rather than
duplicate functionality.
In HEAD find the DeploymentInfo for the EJB module and get its list of
mbeans. This list contains the EjbModule mbean and all
Tapestry doesn't care about file extensions.
By convention, page-specifications are .page and
component-specifications are .jwc.
Earlier versions of tapestry didn't differentiate
between page-specification and component-specification,
pages and components alike used .jwc.
--
[EMAIL
Hello marc,
That's not enough to simply add this: as the JVM will automatically create
one instance of this class (no arg constructor), we would end up with a UCL
that don't have an associated Repository. We will need to implement a new
classloader that delegates loading correctly. Do you think
Hi Jason,
even with a completely new checkout the build of jboss-all fails for me
with Java 1.4.1-b21on Linux.
Using java 1.3.1 on ReliantUnix works fine.
Tagets build and clobber fail with the same Exception immediatly.
Executing: /home/jboss/java/JBoss-cvs/jboss-all/tools/bin/ant -find
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
**
¯Â°Ó·~¿ì¤½«Ç¥X¯²
**
±MªùªA°È°Ó¥Î¿ì¤½«Ç¤§©Ó¯²¤H¡C
¥x¥_¦Uµ¥¯Å°Ó¥Î¿ì¤½«Ç®×¥ó¡A¾A¦X¦UºØ°Ó·~»Ý¨D¡I¡I
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
Juha,
sometimes design-by-email is not a fast route :) ...
all of mbeaninfo should not be always stored. for instance, if I
instantiate my MMB by using a definition from an URL or db then the
mbeaninfo is already persisted there and should not be duplicated (only
the ref to where to
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
Bugs item #617574, was opened at 2002-10-02 07:20
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866
Category: JBossMX
Group: v3.2
Status: Pending
Resolution: Fixed
Priority: 7
Submitted By: Michael Bartmann (bartmann)
Assigned to: Scott
This problem is not related to the thread context class loader. The
heiarichical repositories were incorrectly synchronized and naked
calls to the delegate class loaders generated by the VM were not
synchronized with the repository. Both issues have been fixed.
Scott
Bugs item #613809, was opened at 2002-09-24 06:01
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=613809group_id=22866
Category: CatalinaBundle
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Alexander Opitz (opi)
Assigned to: Scott
On 2002.10.03 16:06:36 -0400 Matt Munz wrote:
Juha,
sometimes design-by-email is not a fast route :) ...
all of mbeaninfo should not be always stored. for instance, if I
instantiate my MMB by using a definition from an URL or db then the
mbeaninfo is already persisted there and
Bugs item #612087, was opened at 2002-09-20 05:03
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=612087group_id=22866
Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned
On Thu, 3 Oct 2002, Matt Munz wrote:
all of mbeaninfo should not be always stored. for instance, if I
instantiate my MMB by using a definition from an URL or db then the
mbeaninfo is already persisted there and should not be duplicated (only
the ref to where to locate it is needed). This
Bugs item #598809, was opened at 2002-08-22 07:49
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=598809group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Joseph Barillari (jdbarillari)
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
Bugs item #582195, was opened at 2002-07-16 05:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=582195group_id=22866
Category: JBossDoc
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Thomas Gran (thomasgran)
Assigned
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
On 2002.10.03 17:19:27 -0400 Juha-P Lindfors wrote:
On Thu, 3 Oct 2002, Matt Munz wrote:
all of mbeaninfo should not be always stored. for instance, if I
instantiate my MMB by using a definition from an URL or db then the
mbeaninfo is already persisted there and should not be duplicated
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.4.0_01
Java(TM) 2 Runtime Environment, Standard
I think this is not happy because the last line is SHUTDOWN... I will remove
that println.
--jason
On Thu, 3 Oct 2002 [EMAIL PROTECTED] wrote:
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
On Thu, 3 Oct 2002, David Jencks wrote:
The location does not have to be accessible after deployment, so the mbean
persistence mechanism has to store it itself.
why wouldn't it be accessible? and if my persistence mechanism is
something like Dain's CMP engine, I don't expect it to store the
Okay, I will look into... must be an Ant CL issue.
--jason
On Thu, 3 Oct 2002, Langelage, Frank wrote:
Hi Jason,
even with a completely new checkout the build of jboss-all fails for me
with Java 1.4.1-b21on Linux.
Using java 1.3.1 on ReliantUnix works fine.
Tagets build and clobber
Bugs item #614116, was opened at 2002-09-24 19:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=614116group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to:
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
JAVA VERSION DETAILS
java version 1.3.1_03
Java(TM) 2 Runtime Environment, Standard
The problem with writing build components in Java is that the maintenece
process is slow and difficult, and only a select few can currently perform
this.
Perhaps if the build components were made into a included module this would
different... I am undescided as of yet to which is
As I was struggling today with the classpath for tapestry compilation
and messing around with ant files and (gasp!) build magic files, I found
myself thinking that Build on JBoss could possibly be a project. JUST
THE CLASSLOADERS with the complete visibility thingy would be pretty
interesting.
FWIW I think ant could be better replaced by a bunch of mbeans running in
an mbean server. Basically task == mbean and target also == mbean. This
would solve about 90% of their problems (especially their incompetent
classloaders) with no work. However none of the ant committers seem
David Jencks wrote:
On 2002.09.27 16:21:33 -0400 Igor Fedorenko wrote:
David Jencks wrote:
Hi Igor,
I'd like to stick with the jboss tm and add the needed functionality.
Can you outline what you have been thinking of?
I want to allow resource manager specific variation of XAResource state
This is done, though only Ant 1.5 aware tools will function at the moment.
If there are other version that need to be compatible (if they can be) let
me know.
--jason
On Thu, 19 Sep 2002, Scott M Stark wrote:
Anymove that restores that ability to run our build in Ant aware tools is a good
I can not find the include task in the 1.5 branch of Ant. I see some
proposal/embed stuff in HEAD... but I can not get it to compile.
--jason
On Thu, 19 Sep 2002, David Jencks wrote:
On 2002.09.19 19:32:25 -0400 Scott M Stark wrote:
I still don't buy it. Many of the existing tests
I would really like the build.xml files to be consistently indented. It
is also really annoying for them to have 2 spaces instead of 3 like the
rest of jboss (I have to tab by hand now or reset my vim environment).
Feel free... tis a pain to keep these consistent. Perhaps you can write a
I have some ideas on using xslt, but I am not sure what the performance
impact would be.
I would need your help to write the stylesheets though...
--jason
On Thu, 19 Sep 2002, David Jencks wrote:
There seems to be an import and an include and I'm not completely sure
what the difference is
Right, we can publish all of the build documentation.
--jason
On Fri, 20 Sep 2002, David Jencks wrote:
I agree. Having them posted might encourage people to make them more
accurate and comprehensive.
The xdoclet-generated todo list would be good also. This is now generated
by the all
Sounds like a good idea. I will set this up when I get to fixing the
snapshots.
--jason
On Fri, 20 Sep 2002, Dain Sundstrom wrote:
I think it would be cool (which means it is not a formal request) to be
able to have some tasks that can build the javadocs and push them to our
webserver
This is done. Look in tools/etc/buildfragments for all of the included
bits.
--jason
On Fri, 20 Sep 2002, Scott M Stark wrote:
The one item I have run into now and then are not being able to see the
default property settings that drive the build because they are stuck in
a buildmagic jar
I agree... but the trick is to accomplish this and still keep the build
files simple, small.
I am thinking about how to do this.
--jason
On Fri, 20 Sep 2002, Scott M Stark wrote:
Less mysteriousness, as in:
!--
| Initialize the build system. Must depend on '_buildmagic:init'.
If I send you an example .xml file can you send me a basic skeleton
stylesheet with examples on how to replave tags and access emements?
--jason
On Fri, 20 Sep 2002, David Jencks wrote:
I've seen similar explanations on the ant list sometimes, but they all go
way over my head. Is there
Number of tests run: 934
Successful tests: 930
Errors:4
Failures: 0
[time of test: 3 October 2002 12:59 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
Sorry for the delay...
Probably the biggest annoyance I have with using a sub-module is that
the ${project.root} property within the sub-module ends up including the
module above it instead of being the actual project root, so I have to
define my own local ${project.root.local} property in
The ant committers are all insane.
--jason
On Thu, 3 Oct 2002, David Jencks wrote:
FWIW I think ant could be better replaced by a bunch of mbeans running in
an mbean server. Basically task == mbean and target also == mbean. This
would solve about 90% of their problems (especially their
On 2002.10.03 22:12:42 -0400 Igor Fedorenko wrote:
David Jencks wrote:
On 2002.09.27 16:21:33 -0400 Igor Fedorenko wrote:
David Jencks wrote:
Hi Igor,
I'd like to stick with the jboss tm and add the needed functionality.
Can you outline what you have been thinking of?
I want to
Jason,
I had submitted an example directly to David sometime last week, but
I'll share with the world now so that the entire Jboss team can benefit.
Its not a Java project per se, as it really only uses a sitemap.xml and
an XSL to produce another ant script for running XSL transformations on
a
82 matches
Mail list logo
