Just my 2c.
I think that an XML/HTTP integration of JBossMQ should be done by making
a JAXM personality of JBossMQ. I had a quite lengty mail conversation
with a guy a couple of month ago where we sort of tried to interpret the
spec in a JMS way. He said he was going to implement the stuff, but
On 14 Nov, Till: [EMAIL PROTECTED] wrote:
Just my 2c.
I think that an XML/HTTP integration of JBossMQ should be done by making
a JAXM personality of JBossMQ. I had a quite lengty mail conversation
with a guy a couple of month ago where we sort of tried to interpret the
spec in a JMS way.
Bugs item #481645, was opened at 2001-11-14 03:10
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=481645group_id=22866
Category: JBossTX
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Dieter Bartmann (bartmann_d)
Assigned to:
User: lepe
Date: 01/11/14 03:56:44
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCDefinedFinderCommand.java
Log:
[ #422247 ] CMP finder command case-sensitive
Revision ChangesPath
No revision
User: lepe
Date: 01/11/14 04:18:19
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc
JDBCDefinedFinderCommand.java
Log:
[ #422247 ] CMP finder command case-sensitive
Revision ChangesPath
1.20 +4 -3
Sorry to chime in so lateBut hasn't my CacheKey change been in since
2.4.0?
Also remember why I added the copying to the CacheKey in the first place.
What I was doing in my application code was reusing a fat-primary key so I
didn't have to reallocate one. Thus the entity cache was getting
Bill Burke wrote:
Also remember why I added the copying to the CacheKey in the first place.
What I was doing in my application code was reusing a fat-primary key so I
didn't have to reallocate one. Thus the entity cache was getting corrupted
because I kept on changing the shared primary key
Hey,
So, if you're going to get rid of the MarshalledObject and
all the copying,
why not just get rid of CacheKey all together?
Hehe... if it is removed I have only one thing to say: told
you so... :-)
/Rickard
eee, man this guy seem to *always* be right. Ah well, pure alien
Bordet, Simone wrote:
eee, man this guy seem to *always* be right. Ah well, pure alien
category.
Rickard, ehrm, who will win the football league this year ? :-))
I *could* tell, but that'd spoil the fun ;-)
/Rickard
--
Rickard Öberg
___
On Wed, 14 Nov 2001, Scott M Stark wrote:
Yes, this change has been in since the start of 2.4, and people have
complained about CacheKey showing up as a bottleneck since its
release. It started showing up even more dramtically in the pending
2.4.4 codebase due to some other change that is
Maybe I am missing something, but isn't this whole issue about distributing
a compiler with JBoss so the user doesn't have to download the JDK and edit
a configuration file to point to it?
If that is the case, can't we distribute jikes?
-Phil
User: mnf999
Date: 01/11/14 08:37:04
jboss/src/main/org/jboss/invocation - New directory
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: mnf999
Date: 01/11/14 08:43:19
Added: src/main/org/jboss/invocation Invocation.java
Log:
The new Invocation object, it is just a generalized invocation that carries
Transaction and security with it. Then we keep some variables directly but it should
really work through
Yes, you are missing the fact that tools.jar is plattform/vendor dependant.
Therefore you would have to distribute one for each plattform.
Andy
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 8:14 AM
Subject: Re: [JBoss-dev] RH:
Jikes is not a Java program and you have to use a binary suitable for
the target platform. I'm not interested in getting into supporting mutiple
platform binaries.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
amen
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Wednesday, November 14, 2001 11:51 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
|
|
|Jikes is not a Java program and you have to use a
User: mnf999
Date: 01/11/14 08:43:19
Modified:src/main/org/jboss/ejb MethodInvocation.java
Log:
The new Invocation object, it is just a generalized invocation that carries
Transaction and security with it. Then we keep some variables directly but it should
really work through
Ok,
[FOR RECORD, ARCH CHANGE]
we discussed some time ago the possible extension of the MethodInvocation
to be a more generic and powerful entity.
Basically I have added the invocation directory and the Invocation.java, as
well as changed the MethodInvocation.
The 10,000 ft is that the new RH
kids,
we are hearing a lot of talk about EJB and not EJB and blabla bla. Well I
will say that I am a big fan of the framework, for reasons that even our
favorite aliens are missing ;-) but that is another thread.
The reason I want EJB to take a backseat in the LAYOUT OF THE CODE is that
I
Bugs item #422247, was opened at 2001-05-08 03:06
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=422247group_id=22866
Category: JBossCMP
Group: v2.3 (unstable)
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Lennart Petersson (lepe)
Assigned
Definitely.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: marc fleury [EMAIL PROTECTED]
To: Jboss-Development@Lists. Sourceforge. Net
[EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 9:21 AM
Subject:
wowowo,
I realize I forgot to say what this is good for :)
you can now attach ANY PAYLOAD to an invocation, not just the stuff
generated at the client, so that you can pass information down the chain,
have interceptors talking to each other and pass arbitrary data around the
JMX base, VERY VERY
On Wed, 14 Nov 2001, Scott M Stark wrote:
Jikes is not a Java program and you have to use a binary suitable for
the target platform. I'm not interested in getting into supporting mutiple
platform binaries.
Well, I guess now is as good a time as any to bring up a problem I have with
the
2.4.x is based on the archaic and fragmented build policy from the
early days of JBoss and its not likely to change(at least by me).
The build process has been totally reorganized in the main branch for the
3.0 release so focus on getting a source ball that suits your purpose
using it.
Feature Requests item #481711, was opened at 2001-11-14 07:11
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376688aid=481711group_id=22866
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous
User: tmcsys
Date: 01/11/14 10:24:10
Added: src/docs petstore_frames_user.html
Log:
Match 'user' pages color scheme
Revision ChangesPath
1.1 newsite/src/docs/petstore_frames_user.html
Index: petstore_frames_user.html
Amen.
FWIW, I think the major advantage of the EJB framework over e.g. using JDO
is that, especially in the jboss environment, it is very simple to do
(limited) meta-class programming. The EJB spec uses this for transactions
and security, Scott uses it for Security Proxies, I have used it to
|Although I originally thought including an mbean-iterator in the method
|invocation, as you have done, was the way to go, after discussion with
|Scott and some experiments I changed my mind to think an approach using
|interceptor factories and interceptor chain factories (both mbeans) is a
|Amen.
|
|FWIW, I think the major advantage of the EJB framework over e.g. using JDO
|is that, especially in the jboss environment, it is very simple to do
|(limited) meta-class programming. The EJB spec uses this for transactions
|and security, Scott uses it for Security Proxies, I have used it
I'm preparing a patch (my humble contribution, snif!) for run.bat/run.jar.
It includes:
1.- Support for tools.jar 'a la' Tomcat: you should define a JAVA_HOME
environment variable that points to your java instalation directory. It
checks if tools.jar is where it should. If not, it doesn't let
How about removing the code and leaving a comment in the run.bat file?
It's easy to modify the required of JAVA_HOME to add tools.jar if
JAVA_HOME is available
-Mensaje original-
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]En nombre de David
Maplesden
Enviado el: miércoles, 14
actually scratch all this discussion,
I think I have a better idea for the MI/Invocation
I will keep the payload and just put different readers on it, the basic
one will be the Invocation, the extended one will be the MI but essentially
we can create a MI and set the payload from the incoming
Looks good Hiram,
Can I make one suggestion. When I was profiling and improving JBossMQ's
performance I implemented a couple of static methods
SpyMessage.writeMessage() and SpyMessage.readMessage() to use instead of the
standard writeObject and readObject methods. I think you should use them
yeah sounds good, add it if you can find it, if you can't print a warning
and carry on
-Original Message-
From: Ignacio Coloma [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 15, 2001 8:48 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] RH: tools.jar (javac)...
How about
Patches item #481803, was opened at 2001-11-14 11:10
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=481803group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Ignacio Coloma
This is the purpose of the Logger.isXXXEnabled() call. Any debugging
that is executed on a per message basis should be a trace level message
that is enclosed inside of a test for that priority level being active. This
allows for enabling tracing with very fine control at runtime and one of
the
Thanks, that's good to know. The amount and level of logging in JBossMQ
needs to be looked at, its not completely hopeless, but its far from
consistent (mainly because of my changes I guess).
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November
On Thu, 15 Nov 2001, David Maplesden wrote:
You might be jumping the gun a bit with this one. tools.jar is only needed
afaik for Jasper i.e. when Jetty (or Tomcat) needs to serve jsp pages. Not
everyone will want this, indeed many people will probably run JBoss without
a servlet engine,
On Thu, 15 Nov 2001, David Maplesden wrote:
if(DEBUG) log.debug(a message);
so that we can easily set the flag to false and recompile a higher
performance version of the engine. With the static flag set to false the
compiler removes the line completely, so there is no performance hit at
On Wed, 14 Nov 2001, Scott M Stark wrote:
2.4.x is based on the archaic and fragmented build policy from the
early days of JBoss and its not likely to change(at least by me).
The build process has been totally reorganized in the main branch for the
3.0 release so focus on getting a source
Next week.
- Original Message -
From: Adam Heath [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, November 14, 2001 12:55 PM
Subject: Re: [JBoss-dev] RH: tools.jar (javac)...
On Wed, 14 Nov 2001, Scott M Stark wrote:
2.4.x is based on the
Oh, and if we are talking about performance, I would appreciate everyone
being very careful about placing debug statements inside any code that is
executed for every message through the system. Several of these have been
introduced with the advent of the message caching and David J's new
I couldn't agree more.
When I first started reading the code, It was hard to sperate the EJB
sepecific stuff from the rest. I think this will help up out alot.
-dain
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 14, 2001 11:21 AM
To:
This is great.
This is what I wanted to do when I wrote my message passing hack. I think
one problem is the current interceptors will be expecting a Method object,
so when they are changed to handle an Invocation with out a Method object, I
will definitely switch over.
-dain
-Original
On Wed, 14 Nov 2001, Scott M Stark wrote:
Next week.
Ooh! I can't wait.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
In general the logging in Main is way overboard as not everyone is upto
speed with the trace level logging support. This is the first thing I will
address when I get back to working on Main next week.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
Can we automate .deb building with the new build system?
--jason
On Wed, 14 Nov 2001, Adam Heath wrote:
On Wed, 14 Nov 2001, Scott M Stark wrote:
2.4.x is based on the archaic and fragmented build policy from the
early days of JBoss and its not likely to change(at least by me).
The
Oops, did you remove the excess debug statements I put in or can you point
a bit to where they might be? I'm not at all sure I could recognize such
places..
David Jencks
On 2001.11.14 14:56:29 -0500 David Maplesden wrote:
Looks good Hiram,
Can I make one suggestion. When I was profiling
yOn Wed, 14 Nov 2001, Jason Dillon wrote:
Can we automate .deb building with the new build system?
Possibly. The whole point of debian is automation. We have lots of build
daemons setup(for all the architectures we support), that demand this sort of
feature.
I have just checked out the cvs
|-Original Message-
|From: Dain Sundstrom [mailto:[EMAIL PROTECTED]]
|Sent: Wednesday, November 14, 2001 4:13 PM
|To: 'marc fleury'; Jboss-Development@Lists. Sourceforge. Net
|Subject: RE: [JBoss-dev] Invocation and MethodInvocation
|
|
|This is great.
|
|This is what I wanted to do
I haven't removed any debug statements since I did my initial big
contribution some months ago, I thought people might be using them trying to
track down a particular bug.
Now that we are so close to 3.0 coming out I thought I would mention it in
passing so people where aware of the performance
adam@gradall:~/brainfood/jboss/cvs/jboss$ ant
Buildfile: build.xml
[taskdef] Could not load definitions from resource
planet57/tools/buildmagic/task/autoload.properties. It could not be found.
BUILD FAILED
/home/adam/brainfood/jboss/cvs/jboss/build.xml:23: taskdef class
Hi all,
I think that the merging of init and start has broken the CMR code. The CMR
code depends on having a complete two-phase startup. In the phase 1 (init)
all of the relation ships are connected, and in phase 2 (start) these
relationships are used to create the entity tables with fks,
yOn Wed, 14 Nov 2001, Adam Heath wrote:
adam@gradall:~/brainfood/jboss/cvs/jboss$ ant
Buildfile: build.xml
[taskdef] Could not load definitions from resource
planet57/tools/buildmagic/task/autoload.properties. It could not be found.
BUILD FAILED
Ok look,
the invoker stuff also depends on a init/start, I think that init/start
isn't really an important thing to clean at this point (but I could be
wrong, I have been proven wrong in the past).
I didn't really fully follow the discussion either but can we put it back
for the time being.
We
I read the mail on the problems with clustering, and I didn't see any thing
will help me. Here is what I need for the CMR code:
ejb1.init();
ejb2.init();
ejb3.init();
ejb4.init();
ejb1.start();
ejb2.start();
ejb3.start();
ejb4.start();
but I am getting is:
ejb1.init();
ejb1.start();
I think this makes a case for rolling back to the 2 phase initialization
since clustering has the same problem.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Dain
Sundstrom
Sent: Wednesday, November 14, 2001 5:12 PM
To: [EMAIL PROTECTED]
On 2001.11.14 17:11:52 -0500 Dain Sundstrom wrote:
Hi all,
I think that the merging of init and start has broken the CMR code. The
CMR
code depends on having a complete two-phase startup. In the phase 1
(init)
all of the relation ships are connected, and in phase 2 (start) these
I don't really understand the MBean deployment ref stuff, but I'll comment
on it anyway :)
I think we need some sort of concept of a deployment unit, in my case an
ejb-jar. After reading the discussion on this change, I think I understand
the reason for the change. The problem is that we can't
As I have pointed out repeatedly in the past few days it is not possible to
have non-trivial mbean init-start with mbean-ref style dependencies,
whereas it is pretty easy to fix these problems by explicitly noting the
dependencies.
Note that the stuff I did only applies to mbeans: I did not
Don't worry about it, I am actually looking at the SAR dependency stuff and
that is really cool stuff. I really like it. So we will need to find a way
to solve the problem down the road.
Don't worry about it for now, some other time, leave the init()/start() as
we are building the
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 14, 2001 4:58 PM
To: Dain Sundstrom
Cc: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] MBean init/start change broke CMR
On 2001.11.14 17:11:52 -0500 Dain Sundstrom wrote:
Hi all,
I
Ok, the ejb-jar should still be one deployment unit. The init/start
shouldn't affect anything except mbeans in a *service.xml file. Almost
certainly I broke something like ContainerFactory. Could you send me your
test cases and I will see if I can figure this out?
Thanks
david jencks
On
Use the build.sh script.
--jason
On Wed, 14 Nov 2001, Adam Heath wrote:
adam@gradall:~/brainfood/jboss/cvs/jboss$ ant
Buildfile: build.xml
[taskdef] Could not load definitions from resource
planet57/tools/buildmagic/task/autoload.properties. It could not be found.
BUILD FAILED
On Wed, 14 Nov 2001, Jason Dillon wrote:
Why do you need a planet57 .deb ?
A package in debian needs to be able to build with software in debian. Since
planet57 does not exist in debian, I'm making a deb of it.
This way, debian/control can contain a Build-Depends on
planet57-buildmagic.deb.
On Wed, 14 Nov 2001, Jason Dillon wrote:
Use the build.sh script.
That wouldn't help, since there is no planet57 code at all on my system. In
fact, build.sh makes no attempt at finding planet57 code, and assumes it is
just in the classpath.
It also assumes that ant will use $CLASSPATH.
David,
I've done some reasearch on ContainerFactory, and I think I have a solution.
From the logs I've seen that you removed the app.init() method, which should
be ok. All we need to do is add back an init method to the Container class,
which I think is below the level you care about. Then we
Can you put a package in debian main that depends on a non-free software?
Remember, JBoss 3.0 DEPENDS on jdk 1.3.x, and there is no free version of
that.
Nor is there a .deb for it at all in non-free/contrib.
I don't believe IBM has a 1.3x .deb, and kaffe definately doesn't support it.
As
Yes, thats about it, except I changed quite a few files below that too.
I'm sorting them all out.
Thanks
david jencks
On 2001.11.14 19:32:29 -0500 Dain Sundstrom wrote:
David,
I've done some reasearch on ContainerFactory, and I think I have a
solution.
From the logs I've seen that you
Why do you need to know anything about buildmagic to build JBoss? All you
do is `cvs get jboss-all` and `build/build.sh` that is it. Why would it be
any different to build a debian package (or any package for that matter).
If you are setting up a seprate environment that does not use
What are you talking about? build.sh makes no assumptions about the users
classpath and sets it up correctly to use the jars from tools/lib.
If you are trying to build JBoss from MAIN the onl;y supported method is
using either build.sh or build.bat. Direct usage of ant is NOT supported.
We are not planning on re-adding tools.jar to the package are we?
Perhaps we could setup an InstallAnywhere installer which could have some
custom tasks to install a tools.jar from the target JDK for those users who
might have trouble doing this by hand.
--jason
On Wed, 14 Nov 2001, Adam
Further more, there are a slew of other .jars which a JBoss build depends
on. I don't understand why you need a buildmagic deb, nor am I sure what
that deb would even consist of.
If this is going to be released to the mass of debian users I would like to
know the full details of the package
On Wed, 14 Nov 2001, Jason Dillon wrote:
What are you talking about? build.sh makes no assumptions about the users
classpath and sets it up correctly to use the jars from tools/lib.
There are no jars whatsoever in jboss cvs. Please, don't just assume
something.
If you are trying to build
No were not.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: Adam Heath [EMAIL PROTECTED]
Cc: Scott M Stark [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, November
On Wed, 14 Nov 2001, Jason Dillon wrote:
Why do you need to know anything about buildmagic to build JBoss? All you
do is `cvs get jboss-all` and `build/build.sh` that is it. Why would it be
any different to build a debian package (or any package for that matter).
When making a source
On 2001.11.14 21:02:53 -0500 Adam Heath wrote:
On Wed, 14 Nov 2001, Jason Dillon wrote:
What are you talking about? build.sh makes no assumptions about the
users
classpath and sets it up correctly to use the jars from tools/lib.
There are no jars whatsoever in jboss cvs. Please,
yOn Wed, 14 Nov 2001, Jason Dillon wrote:
On Wed, 14 Nov 2001, Jason Dillon wrote:
What are you talking about? build.sh makes no assumptions about the users
classpath and sets it up correctly to use the jars from tools/lib.
There are no jars whatsoever in jboss cvs. Please, don't
On Thu, 15 Nov 2001, David Maplesden wrote:
Settle down, it was very apparent to anyone following your conversation that
you guys were talking about different cvs modules.
It's not apparent to me(who is new with jboss), and not apparent to Jason(who
is not). So, you can imagine my
This is not an appropriate response my friend... especially from a newcomer.
I certainly am not motivated to help by such comments... though I will
persist anyways.
--jason
On Wed, 14 Nov 2001, Adam Heath wrote:
yOn Wed, 14 Nov 2001, Jason Dillon wrote:
On Wed, 14 Nov 2001, Jason
On 2001.11.14 23:54:00 -0500 Adam Heath wrote:
On Wed, 14 Nov 2001, David Jencks wrote:
On 2001.11.14 21:02:53 -0500 Adam Heath wrote:
On Wed, 14 Nov 2001, Jason Dillon wrote:
What are you talking about? build.sh makes no assumptions about
the
users
classpath and sets it
First off you are using the wrong cvs module to build a functional JBoss 3.0
release. The build system and cvs organization has changed drammatically
from 2.x
I know there are not any docs to point this out directly, which I am going
to fix. http://jboss.org/developers/cvs.jsp has been
JBoss daily test results
SUMMARY
Number of tests run: 172
Successful tests: 135
Errors:23
Failures: 14
[time of test: 15 November 2001 5:26 GMT]
[java.version:
User: d_jencks
Date: 01/11/14 21:30:55
Modified:src/main/org/jboss/ejb/plugins/local
BaseLocalContainerInvoker.java
Log:
Fixed Application and rolled back changes on Container, EntityContainer,
MessageDrivenContainer, StatefulSessionContainer,
User: user57
Date: 01/11/14 21:35:15
Removed: src/docs bm-usersguide.pdf
Log:
removed to avoid confusion
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
User: user57
Date: 01/11/14 21:35:15
Modified:src/docs/developers cvs.jsp
Log:
removed to avoid confusion
Revision ChangesPath
1.6 +0 -17 newsite/src/docs/developers/cvs.jsp
Index: cvs.jsp
Is there any reason why crimson.jar is referenced in server/src/etc/run.mf?
Won't this make it hard to switch jaxp compliant parsers?
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
On Wed, 14 Nov 2001, Jason Dillon wrote:
First off you are using the wrong cvs module to build a functional JBoss 3.0
release. The build system and cvs organization has changed drammatically
from 2.x
I know there are not any docs to point this out directly, which I am going
to fix.
On Wed, 14 Nov 2001, Jason Dillon wrote:
This is not an appropriate response my friend... especially from a newcomer.
I certainly am not motivated to help by such comments... though I will
persist anyways.
Well, I kept repeating the same thing over and over and over, and wasn't
getting
JBoss daily test results
SUMMARY
Number of tests run: 187
Successful tests: 148
Errors:25
Failures: 14
[time of test: 15 November 2001 6:24 GMT]
[java.version:
User: d_jencks
Date: 01/11/14 22:27:28
Modified:src/etc/conf/default hsqldb-default-service.xml
Log:
Modified to be an example and test of anonymous mbean-refs
Revision ChangesPath
1.4 +19 -9 jboss/src/etc/conf/default/hsqldb-default-service.xml
Index:
User: d_jencks
Date: 01/11/14 22:30:22
Modified:src/main/org/jboss/system ServiceConfigurator.java
Log:
Added anonymous mbean-ref and mbean-ref-lists. (i.e, don't supply a name). See
hsqldb-default-service for an example
Revision ChangesPath
1.7 +82 -64
It would only cause a problem if there were inconsistencies between the
common xml classes. If you set the JAXP properties your saying which
parser factory to use so it doesn't matter if fatories for other parsers are
on the classpath. I switch parsers all the time with this entry in the
Out of curiousity, where does connector (jbosscx) fit into your packaging
scheme? For 3.0 you might consider putting the contents of pool and
connector into one package (if they aren't already) as pool is now small
and only used by jbosscx.
david jencks
On 2001.11.15 01:11:20 -0500 Adam Heath
On Wed, 14 Nov 2001, Jason Dillon wrote:
If you are trying to build a 3.0 .deb then please use the 'jboss-all' module
from cvs and use 'build/build.sh release' to create a release suitable for
stuffing into the package. The files will be inder 'build/output/jboss-*/
Ok, I've done this, and
marc fleury wrote:
we agree on the metaprogramming, we are going to make it dynamic too,
some other day I will publish a white paper :) Let Rickard fire first
I intend to write a whitey on it some day too, but basically it goes
something like this:
* Meta-programming is good, but not
96 matches
Mail list logo
