I agree with David. It's easier to see what is happening when you deploy a
service that needs some jars to know exactly which ones are:
* You can check the versions
* You know which jars are not used anymore
* When the system grows (and it will) dependencies are more easily tracked
I see this
Patches item #489774, was opened at 2001-12-06 01:57
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=489774group_id=22866
Category: JBossCMP
Group: v2.4 BETA (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco Ladermann (mpl)
Assigned
Hi,
right now sars and service.xml files need to be explicitly
undeployed and
redeployed. This will be fixed when the undeploy responsibility
goes to
AutoDeployer where it belongs.
Does this mean that the tests will fail until then - or is there
another problem on my Testsuite run?
I
IT IS AN ADMINISTRATION FUCKING NIGHTMARE!!
I WILL DEAL WITH THIS IMMEDIATELY
View: http://jboss.org/forums/thread.jsp?forum=66thread=4932
___
Jboss-development mailing list
[EMAIL PROTECTED]
Is this the same functionality your MBeanClassLoader
is supposed to
provide? If so, how exactly is this supposed to
work?
No it is not the same, it achieves the same but one is an administration
*un-necessary* nightmare, the other one is implicit, you don't do anything.
The presence of
You are correct I will rectify this.
View: http://jboss.org/forums/thread.jsp?forum=66thread=4933
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
David,
I did a small hack to DeployerMBeanSupport that calls
undeploy instead of sending the message.
My motivation was laziness when redeploying modified
SARs.
This seems to work fine in my tests, including
suspending dependent services, except...
The classloader in the SarDeployerInfo is
On 2001.12.06 07:12:48 -0500 Chris Kimpton wrote:
Hi,
right now sars and service.xml files need to be explicitly
undeployed and
redeployed. This will be fixed when the undeploy responsibility
goes to
AutoDeployer where it belongs.
Does this mean that the tests will fail
on 1-12-06 13.12, Chris Kimpton at [EMAIL PROTECTED] wrote:
Does this mean that the tests will fail until then - or is there
another problem on my Testsuite run?
No i do not think so ... that behaivior has been there some time ... but the
new log4j.RollingFileAppender might need a bigger
When the new ClassLoader code is checked in, I shall
work on a proper JSP solution. Until then, everything
is just a temporary hack.
If you want JSP compilation to work, you have to tell
JBoss where the tools.jar is. We can't ship it with
JBoss because it is part of the JDK.
Jules
--- Peter
David,
I am actually reading your code, I will try to simplify this and make it implicity
when I have a moment (next as we work on the CL integration), It will be pretty I
guarantee it
View: http://jboss.org/forums/thread.jsp?forum=66thread=4932
We could,
but:
1. some architectures (One of my first beta testers is
on MacOS X) do not seem to have the jar at all - it
seems to have been collapsed into the rest of the
runtime.
2. Many people will be running JBoss on a JRE not a
JDK, and precompiling their JSPs during development.
I am
I thought I'd try to investigate all the test failures...
but I can't checkout jboss-all!
cvs hangs while checking out jboss.net/testsuite/src/stylesheets
Anyone else seeing this???
View: http://jboss.org/forums/thread.jsp?forum=66thread=4974
Please move the demo-app discussion on the online forum,
I have created a forum just for it, it is called J2EE design pattern but please move
this over there as it really doesn't belong on this forum
thanks
View: http://jboss.org/forums/thread.jsp?forum=66thread=4941
I am looking at the boot of JBoss and there is a rogue service.xml file which 1- is
confusing considering that there is one in the Default as well, 2- really doesn't
belong there, in fact there should NOT be a boot-service.xml.
I will remove the boot-server directory as it includes only jetty
on 1-12-06 15.44, Julian Gosnell at [EMAIL PROTECTED] wrote:
1. some architectures (One of my first beta testers is
on MacOS X) do not seem to have the jar at all - it
seems to have been collapsed into the rest of the
runtime.
ahhh . a special for OSX ... hmmm .
2. Many people will be
on 1-12-06 16.22, Peter Fagerlund at [EMAIL PROTECTED] wrote:
2. Many people will be running JBoss on a JRE not a
JDK, and precompiling their JSPs during development.
Could We not just say clearly :
SDK required - else If running under JRE please copy tools.jar here ...
/peter_f
Guys,
You all may or may
not agree, but the current structure of mbean xml files is really
confusing. I think the concept of one mbean file containing all
out-of-the-box components that come with JBoss is much easier for a new user to
understand( and for me for that matter :). In the 2.4.x
I sure as hell can't find the reason, please move this either to default either to
it's own sar/service.xml file. :)
View: http://jboss.org/forums/thread.jsp?forum=66thread=4975
___
Jboss-development mailing list
[EMAIL PROTECTED]
on 1-12-06 15.56, marc fleury at [EMAIL PROTECTED] wrote:
Please move the demo-app discussion on the online forum,
Yes very good - We still need to find a structur -here now :
Scenario :
I dload JBoss3.0 binary
- it comes with a demo folder of deployable examples
In dload JBoss3.0 src
Patches item #489797, was opened at 2001-12-06 03:10
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=489797group_id=22866
Category: JBossCMP
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Crowley (crowleym)
Assigned to:
I totally agree ;-)
I am pulling my hairs cause changing a simple parameter with the SAR means unjar,
touch, rejar, this is silly
I REALLY LIKED the one file for the boot
Guys,
You all may or may not agree, but the current
structure of mbean xml files
is really confusing. I think the
Kudos for the copying and resolution logic, it is complex stuff (which is why you are
swimming in it like a fish) and you managed to make it readable and almost
straightforward.I also played with it and it works.
Really kudos, you did implement the relevant logic.
Just don't push it on the
2.4.x series, all you
had to do was look at jboss.jcml to see and
configure
all components in
jboss and what order they were brought up in the
system.
Yes this was critically simple, configuration is very
confusing and putting a comment in the
jboss-service.xml that says don't
It is now coming back to me, someone in the london training (was
it you sacha?) was pushing for unix levels you know rc.0 -
rc.6 as a way to define dependency in a lose fashion, that was
actually pretty good and allows for different files of configuration.
No, I guess it was one of the
Patches item #489841, was opened at 2001-12-06 05:28
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=489841group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Goedhart
User: starksm
Date: 01/12/06 08:37:54
Modified:src/main/org/jboss/ejb/plugins/jrmp/interfaces
BeanProxy.java
Log:
Handle null a argument to isIdentical().
Revision ChangesPath
1.5 +16 -7
User: starksm
Date: 01/12/06 08:38:57
Modified:src/main/org/jboss/ejb/plugins/jrmp/interfaces Tag:
Branch_2_4 BeanProxy.java
Log:
Return false if a is null as it does not make sense to compare a null
a against a null b.
Revision ChangesPath
No
I have been doing some thinking on this freebay idea and came up with
some things. As I said I am not against working on a complete
application, however I think we should focus on an app that has
potential resale value. Why? Simple if it can be sold developers
arent working for free, and
[EMAIL PROTECTED] wrote:
But IMHO, while simple, unix-like levels doesn't seem to be the nicest
feature I've ever seen... a bit tricky... maybe that's just me... In that
case, why not simply creating subdirectories in the deploy folder and start
their content depending on the name of the
My plans are way ahead of my time to implement any of this...
some comments.
1. Don't confuse the utterly messed up and misleading current use of the classpath
element and service.xml packaging with its capabilities and usefulness. There are 2
problems with the current packaging IMHO:
a.the
User: mnf999
Date: 01/12/06 08:59:09
Modified:src/main/org/jboss Main.java
Log:
Just so that Bill Burke stops being confused
Revision ChangesPath
1.57 +2 -2 jboss/src/main/org/jboss/Main.java
Index: Main.java
User: d_jencks
Date: 01/12/06 09:14:43
Modified:src/main/org/jboss/ejb/plugins/jrmp/interfaces
BeanProxy.java
Log:
At least make it compile
Revision ChangesPath
1.6 +2 -2
|a.the base jboss-service.jar includes every jar under the sun that
|I didn't explicitly remove, rather than the ones actually used in
|the base package, and
including jars in classpath as code requirement is the initial problem,
remove that.
|b. No one has actually divided up the functionality
The problems are caused by the build scripts. jboss-xa.rar and jboss-jdbc.rar are
missing from deploy/lib.
View: http://jboss.org/forums/thread.jsp?forum=66thread=4926
___
Jboss-development mailing list
[EMAIL PROTECTED]
After a few minutes of investigation, I found one reason all the tests are
failing, jboss-xa.rar and jboss-jdbc.rar are not copied to deploy/lib, so
no database access for anyone.
Look guys, in the last day we've had a big untested change in the build
system and a file checked in that doesn't
User: starksm
Date: 01/12/06 09:41:33
Modified:src/main/org/jboss/ejb/plugins/jrmp/interfaces Tag:
Branch_2_4 BeanProxy.java
Log:
Forgot what a Boolean was.
Revision ChangesPath
No revision
No revision
Bill Burke wrote:
Guys,
You all may or may not agree, but the current structure of mbean xml
files is really confusing.
Ah. I'm glad someone else has some reservations. I assumed I was just
lagging behind (probably true anyway) and that everyone else knew
exactly what was going on
Hi,
I need a little history lesson. I can't find
org.jboss.security.ssl.DomainServerSocketFactory in the RH JBoss all
checkout. It is used in SSLServerSocketFactory for the Catalina contrib
package. Could someone (Scot?) tell me why this was used instead of the
Catalina SSL support and point
Feature Requests item #489919, was opened at 2001-12-06 09:23
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376688aid=489919group_id=22866
Category: JBossServer
Group: v2.4.x
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to:
On 2001.12.06 12:46:21 -0500 Luke Taylor wrote:
Bill Burke wrote:
Guys,
You all may or may not agree, but the current structure of mbean xml
files is really confusing.
Ah. I'm glad someone else has some reservations. I assumed I was just
lagging behind (probably true anyway)
I AM WORKING ON IT RIGHT NOW
Could somone possibly supply a v. brief summary of
the current situation
and what the final plan is? Some things it would be
useful to know:
The current situation is that simple jboss.jcml like deployment which was in the first
Rabbit-hole release I did was
On the other hand, I think quite a few people have
said it was confusing at
first and useful when they got used to it.
It's **killer** stuff, when you are trying to do advanced dependency deployment, but
we will not force it on un-suspicious newbies and those used to the simple 2.x
MBeans in 2.4.x are really really simple and easy to understand. It's also easy to
understand the flow of initialization. IMHO, anything new in 3.0 should be an
extension of 2.4.x for more advanced configurations. I'm hoping that 3.0 will move
back to 2.4.x's simplicity, but be extendible
I forgot to remind everyone of the point behind these apparently fragmented
service.xml files
They enable easy deployment/undeployment of large chunks of server
functionality (including replacing the classes implementing the
functionality) WHILE THE SERVER IS RUNNING. In 2.4, to add a
Good question that is something I am still thinking about
here is my current understanding (disclaimer: research).
SARs are nice from a packaging standpoint, (i.e. you ship a
SAR to a client he can just drop it in his server at run
time) but a nightmare from a jar creation/xml file
in order of simplicity there is
less simple : all in sars, PACKAGED SARS (with no classes in
there either ! X-()
medium: all in separate mybean-service.xml it can be good to have
the separate files (without the silly packaging) so that the
autodeployer can pick up the fact that you have
David Jencks wrote:
On 2001.12.06 12:46:21 -0500 Luke Taylor wrote:
Ah. I'm glad someone else has some reservations. I assumed I was just
lagging behind (probably true anyway) and that everyone else knew
exactly what was going on from all the discussions on sars and services
so it's good
On 2001.12.06 14:17:46 -0500 Adam Heath wrote:
On Thu, 6 Dec 2001, David Jencks wrote:
b. No one has actually divided up the functionality of jboss into
reasonable
independently deployable packages. (maybe this would be an actually
useful
project for that debian packaging guy...???)
Any idea why they are not copied?
--jason
On Thu, 6 Dec 2001, David Jencks wrote:
After a few minutes of investigation, I found one reason all the tests are
failing, jboss-xa.rar and jboss-jdbc.rar are not copied to deploy/lib, so
no database access for anyone.
Look guys, in the last
marc fleury wrote:
I think this is an obsolete antique.
yes, ok I will remove it
Marc, could you shed some light on what the boot-server config. does
and how it works? Is it all outdated or is that still part of the
web-booting infrastructure? David says he doesn't know what this is
I can check this out just fine.
--jason
On Thu, 6 Dec 2001, David Jencks wrote:
I thought I'd try to investigate all the test failures...
but I can't checkout jboss-all!
cvs hangs while checking out jboss.net/testsuite/src/stylesheets
Anyone else seeing this???
View:
Some food for thought on the mbean system: (Just tell me to shutup and
crawl back into my cubicle if you want!)
While reading the thread current mbean structure confusing I was
thinking about some other issues with mbeans, specifically versioning.
In the special purpose app server we
User: user57
Date: 01/12/06 12:17:30
Modified:.build.xml
Log:
o merged 'rars' target into 'jars'
Revision ChangesPath
1.17 +4 -4 jbosscx/build.xml
Index: build.xml
===
RCS
User: user57
Date: 01/12/06 12:34:05
Modified:src/lib jive.jar
Log:
o jive with debug information
Revision ChangesPath
1.9 +9686 -8612website-forums/src/lib/jive.jar
Binary file
___
User: user57
Date: 01/12/06 12:44:44
Modified:src/web/forums error.jsp
Log:
o hrm...
Revision ChangesPath
1.5 +1 -7 website-forums/src/web/forums/error.jsp
Index: error.jsp
===
RCS
User: user57
Date: 01/12/06 12:40:54
Added: src/web/forums error.jsp
Log:
o adding a better error.jsp page which will log exceptions ala log4j
Revision ChangesPath
1.4 +52 -50website-forums/src/web/forums/error.jsp
User: user57
Date: 01/12/06 12:48:56
Modified:src/lib jive.jar
Log:
o revert
Revision ChangesPath
1.10 +8612 -9686website-forums/src/lib/jive.jar
Binary file
___
Jboss-development mailing list
[EMAIL
Is anyone working on integrating the above 2 systems? If not, I may end up
having to do it myself.
What makes this problematic, is tomcat has rearranged a bunch of their code,
and have given no 'upgrading' doc, describing how to port something from 3.2
to 3.3.
Since tomcat 3.3 is the current
if you want to.. although its not used anywhere yet.. and it's completely
lacking the build infrastructure so you'd have to add that. Of course I
don't mind if you want to work on it :)
-- Juha
At 19:32 5.12.2001 -0800, Jason Dillon wrote:
Should we add the JBossMX stuff to jboss-all? I
I will build'ify it.
What is the deal with the cluster stuff? It is currently in jbossmx module
in cvs. It should be moved, but moving it will break all jboss-all
checkouts, which I am not really into doing too often. I think we should
leave it there until there is time to fix the CVS
User: user57
Date: 01/12/06 13:18:01
Modified:src/web/forums error.jsp
Log:
o re-enable logging
Revision ChangesPath
1.6 +7 -1 website-forums/src/web/forums/error.jsp
Index: error.jsp
That's up to bill and sacha.. but I think you're right, moving might be
more trouble than its worth
-- Juha
On Thu, 6 Dec 2001, Jason Dillon wrote:
What is the deal with the cluster stuff? It is currently in jbossmx module
in cvs. It should be moved, but moving it will break all jboss-all
marc fleury wrote:
2. Is the boot-server configuration only used for booting over the
network
- can we try this out just now, and how do you decide what
configuration
it obtains/supplies??
That I really don't know what it is doing there, see my previous
mail on jetty here
User: juhalindfors
Date: 01/12/06 13:23:41
Modified:src/main/org/jboss/mx/server/registry
BasicMBeanRegistry.java
Log:
synchronize registry access (Trevor Squires)
Revision ChangesPath
1.3 +3 -1
On Thu, 6 Dec 2001, Andrew Scherpbier wrote:
While reading the thread current mbean structure confusing I was
thinking about some other issues with mbeans, specifically versioning.
In the special purpose app server we developed at my previous company we
ran into a problem with upgrades.
Bugs item #489465, was opened at 2001-12-05 10:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=489465group_id=22866
Category: JBossServer
Group: v2.5 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Emmanuel Sciara (sciara)
[EMAIL PROTECTED] wrote:
I forgot to remind everyone of the point behind these apparently fragmented
service.xml files
They enable easy deployment/undeployment of large chunks of server
functionality (including replacing the classes implementing the
functionality) WHILE THE SERVER IS
Marc, don't throw the baby out with the bath water. I agree the current
situation is too confusing.
However, IMHO, one of the main benefits of the multi-sar/service.xml
packaging is exactly the control you get from so many files. It divides
pieces of the server up into chunks you don't need to
Does anyone remember who originally wrote the time-out code or know the
original goal?
I am working on adding read-only to relationships, and have some questions
on how time-out is supposed to work.
Once a read-only field is loaded in a transaction, is it supposed to be
valid for the length of
User: juhalindfors
Date: 01/12/06 13:43:19
Modified:src/main/org/jboss/mx/server/registry
BasicMBeanRegistry.java
Log:
JBoss style: from KR to ANSI C
Revision ChangesPath
1.4 +40 -17
David M and David J
still working with the Spaghetti code in ServiceDeployer, I remember in september we
had a depends discussion in *MBEAN* dependency, and DavidM added that to the
codebase, I also see a entry in the log from DavidM.
now,
I can't find anything about the MBean service
I added it, it lasted a couple of weeks, David J removed it when he
overhauled the entire deployment mechanism. As I didn't have the time to
contribute much myself I just left him to it.
Use the biggest baddest blow torch you can.
Cheers
David
David M and David J
still working with the
On 2001.12.06 14:01:03 -0500 Bill Burke wrote:
MBeans in 2.4.x are really really simple and easy to understand. It's
also easy to understand the flow of initialization. IMHO, anything new
in 3.0 should be an extension of 2.4.x for more advanced configurations.
I'm hoping that 3.0 will move
I seem to be getting out of order message delivery today;-)
I wish I knew what problem you were trying to solve, marc.
Somehow I doubt you'll like it marc... however we could reduce the entire
dependency mechanism to mbean-mbean dependencies by:
Make every package be represented by a
User: starksm
Date: 01/12/06 15:55:55
Modified:src/docs/common doco.jsp
Log:
Move the documentation link to offerings and update the available
for pay docs.
Revision ChangesPath
1.12 +27 -13newsite/src/docs/common/doco.jsp
Index: doco.jsp
I think I am starting to see more clearly,
the mbean-refs in the ServiceController is good, that was added by David J,
the ServiceDeployer class dependency nazi I am not sure I like :)
I think I am there, will fix when I am done cooking/eating putting the
little one to bed.
marcf
come to think of it, users will have to checkout again to get the jboss-all/jmx
directory too.
we really need to reorganize the repository to avoid this in the future.
:(
--jason
View: http://jboss.org/forums/thread.jsp?forum=66thread=4999
___
User: starksm
Date: 01/12/06 15:55:55
Modified:src/docs navigation.jsp
Log:
Move the documentation link to offerings and update the available
for pay docs.
Revision ChangesPath
1.18 +1 -1 newsite/src/docs/navigation.jsp
Index: navigation.jsp
User: starksm
Date: 01/12/06 16:06:28
Modified:src/docs/common doco.jsp
Log:
Change the image alingment to seperate the sections
Revision ChangesPath
1.13 +9 -4 newsite/src/docs/common/doco.jsp
Index: doco.jsp
User: juhalindfors
Date: 01/12/06 16:02:36
Added: src/main/org/jboss/mx/interceptor Invocation.java
Log:
Revision ChangesPath
1.1 jmx/src/main/org/jboss/mx/interceptor/Invocation.java
Index: Invocation.java
he he...
in fact 2 problems one real one fake
the fake: 'depends' removal i have been working on my codebase for the past
3weeks and the code was update by david j last week :) I was missing it but
I did update the server deployer hence panic...my bad
the real: the classpath explicit thingy,
User: juhalindfors
Date: 01/12/06 16:19:49
Modified:src/main/javax/management ObjectName.java
Log:
jboss style + tweaks
Revision ChangesPath
1.2 +83 -51jmx/src/main/javax/management/ObjectName.java
Index: ObjectName.java
hmm? did I drop my module in the wrong place in the CVS?
-- Juha
On Thu, 6 Dec 2001, Jason Dillon wrote:
Date: Thu, 6 Dec 2001 16:45:57 -0700 (MST)
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JBossMX and jboss-all
come to think of it, users will
User: user57
Date: 01/12/06 16:24:18
Modified:.modules
Log:
o something is odd...
Revision ChangesPath
1.74 +0 -2 CVSROOT/modules
Index: modules
===
RCS file:
User: user57
Date: 01/12/06 16:25:05
Modified:.modules
Log:
o revert to 1.72
Revision ChangesPath
1.75 +1 -1 CVSROOT/modules
Index: modules
===
RCS file:
User: user57
Date: 01/12/06 16:27:35
Modified:.modules
Log:
o lets try this again
Revision ChangesPath
1.76 +2 -0 CVSROOT/modules
Index: modules
===
RCS file:
User: user57
Date: 01/12/06 16:33:20
Added: .build.bat build.sh build.xml
Log:
o adding build files
Revision ChangesPath
1.1 jmx/build.bat
Index: build.bat
===
@echo
just added build files. you will need to checkout jboss-all again to get the changes.
--jason
_
View: http://jboss.org/forums/thread.jsp?forum=66thread=4999
___
Jboss-development
For what its worth I think the jar dependency tracking stuff is the only
stuff in need of a rethink, the mbean-ref and classpath syntax I am quite
happy with.
I certainly don't think we need a return to the depends tag.
BTW, I have also noticed a bug in the mbean-ref stuff, it would be nice if
On 2001.12.06 19:03:23 -0500 marc fleury wrote:
he he...
in fact 2 problems one real one fake
the fake: 'depends' removal i have been working on my codebase for the
past
3weeks and the code was update by david j last week :) I was missing it
but
I did update the server deployer hence
No the jmx stuff is in the right place, though if it is called jbossmx it
might have made sence to use that... but since that is currently the cluster
module... ahhh.
It is all messed up.
We really should re-org the entire repository, to reflect the namespace that
we are using on checkout.
oh ya, when it comes time to hook these up, we need to add module defs in
build/build.xml and add it to one of the default groups.
I left it out for the moment, so it won't get built by default.
_
View:
Is there a way to co and build a standalone jbossmx? that should be
possible, can it be done the way MQ uses CVS now?
-- Juha
On Thu, 6 Dec 2001, Jason Dillon wrote:
Date: Thu, 6 Dec 2001 17:25:43 -0700 (MST)
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re:
Thanks for this work, Jason.
-- Juha
On Thu, 6 Dec 2001, Jason Dillon wrote:
Date: Thu, 06 Dec 2001 16:33:20 -0800
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] CVS update: jmx build.bat build.sh build.xml
User: user57
Date: 01/12/06 16:33:20
should this file be part of the 3.0 release? There is an open bug:
[ #486081 ] cluster-service.xml not in 3.0 alpha kit
on this, but I haven't a clue if this should be added or not. Can someone
tell me.
--jason
___
Jboss-development mailing
|For what its worth I think the jar dependency tracking stuff is the only
|stuff in need of a rethink, the mbean-ref and classpath syntax I am quite
|happy with.
same here
that and the standard xml file being a nightmare of bits and pieces that
really should be a standard file.
It's a small
sure, just need to setup a seperate project like jboss-mq, setup build files
and bingo.
unfortunatly the namespace is kinda messed up, so you would probably have to
setup a jboss-mx project.
--jason
On Fri, 7 Dec 2001, Juha-P Lindfors wrote:
Is there a way to co and build a standalone
User: user57
Date: 01/12/06 17:04:36
Modified:jbossbuild.xml
Log:
o changed release to use the modules-most target (which does not generate/
install docs)
o added release-full, which get the previous behavior
Revision ChangesPath
1.55 +8 -2
User: starksm
Date: 01/12/06 17:07:17
Modified:src/resources/web Tag: Branch_2_4 index.html
Log:
Use relative urls on the index.html page.
Include the jbosstest-22-web.war in the ear
Revision ChangesPath
No revision
No
1 - 100 of 143 matches
Mail list logo
