Greg Wilkins wrote:
...
But, hopefully most of it can be solved with some renaming and/or
a minor restructure.
...
Actually reading Giany's issues (14 73), I think we need a
bit more of a rename/restructure.
It does appear that our current AbstractComponent and AbstractContainer
really
AbstractComponent
and AbstractContainer in my renamed tree).
cheers
Dain Sundstrom wrote:
On Sunday, September 14, 2003, at 11:25 PM, Greg Wilkins wrote:
It does appear that our current AbstractComponent and AbstractContainer
really should be ManagedObjects and it is simple to make them
implement
for the delay!
Nah - I think we should restrict the vote to sad gits that work on
open source all weekend :-)
I'll probably put a new patch up tonight with a few more minor
cleanups - but no changes of substance.
cheers
Aaron
On Sat, 13 Sep 2003, Greg Wilkins wrote:
We have 2 concrete patches and 1
This is just a repeat of the vote email I sent earlier, but with
the same markers in the subject.
Aaron has asked for a bit of time to review the latest patches, so
we wont bring this to a close until late tuesday.
We have 2 concrete patches and 1 abstract proposal to vote on:
[ ] Greg's patch: A
Jeremy Boynes wrote:
For those who missed the Jira mail, I have uploaded a derivative of
Aaron's patch that allows the geronimo EJB POJO's (like Session) to
subclass the spec ones and still implement JNDIEnvironmentRefs
For me this patch is a little bit better - it is starting down the
path of my
We have 2 concrete patches and 1 abstract proposal to vote on:
[ ] Greg's patch: A single tree of standard geronimo elements
[ ] Aaron's/Jeremy's patch: Dual concrete trees
[ ] Proposal of a concrete geronimo tree with abstract standard tree.
My own vote is
[+1] Greg's patch: A single tree of
been offline for 36hrs with ISP failure...
Jeremy Boynes wrote:
Greg's is much larger, but I have reservations about the actual data model.
For example, EJB extends JNDINameable but MDB's do not have a JNDI binding.
I am also confused about the meaning of JNDINameable as both EJB and EJBRef
are
+1
Jeremy Boynes wrote:
Aaron has been involved in Geronimo since its launch and has submitted
numerous patches. He has shown initiative in taking on areas that were not
being developed and that were likely to be needed imminently; for example,
implementation of JSR88 functionality, a command line
The name changes that I have been putting into my patch have all been
Ejb -- EJB
Cmr -- CMR
I'll try extra a list shortly.
cheers
Aaron Mulder wrote:
On Mon, 8 Sep 2003, Jeremy Boynes wrote:
Please make sure you use all-caps as per the coding convention e.g. EJBRef.
This was something I start to
, but RPCBean now does. I'll look at
Aarons patch shortly to add support for jndi-name into the schema, as it
is missing.
JNDIEnvironmentRefs has been put back - and as part of that, lots more
naming convention stuff has been fixed.
cheers
Greg Wilkins wrote:
Jeremy Boynes wrote:
Greg's is much
Aaron Mulder wrote:
Stepping back a little, the truth is, any of the options on the
table at this point will likely meet the requirements, and I suspect we're
unlikely to reach 100% consensus on the design, so why don't you either
call a vote on which alternative with a time limit, or
Jeremy Boynes wrote:
No-one objected and no-one new voted overnight so I'm going to declare we
decided on Option #2.
I've been offline for 24hrs for an ISP reasons - so it would be good to keep
votes like this open for at least a few days.
Not that it matters for me on this one:
+1 for Option #2
In the interest of progress and explaination, I have
started making the changes for both the geronimo only
model and the standard as interfaces model.
I'll make the code available later today, but wont commit
unless we get a rough concensus.
So don't let the writing of code stop anybody putting
I've had a look at Aarons patch posted to
http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-76
While better - it still suffers from trying to provide two inheritance
trees and only fully implementing one of them. This works for now because
we have so few geronimo specific elements in
Mulder wrote:
On Tue, 9 Sep 2003, Greg Wilkins wrote:
...Displayable-ejb.Ejb-ejb.RpcBean-ejb.Session-geronimo.ejb.Session
But geronimo.ejb.Session should extend geronimo.ejb.EJB
Or are you saying that we just just don't have a geronimo.ejb.EJB class
and multiple implement it's methods
to reach consensus on the above or I have to stop worrying about it :-)
cheers
-Original Message-
From: Gmane Remailer [mailto:public=SUao4/[EMAIL PROTECTED] On Behalf
Of Greg Wilkins
Sent: Monday, September 08, 2003 8:11 PM
To:
[EMAIL PROTECTED]
Subject: Re: [XML][Deployment]POJO design
Dain Sundstrom wrote:
On Tuesday, September 9, 2003, at 02:02 AM, Greg Wilkins wrote:
Jeremy Boynes wrote:
I think a concrete class hierarchy is easiest here, with the Geronimo
POJOs extending the Standard ones. That way tools can work with
standard
objects or geronimo objects as they like
Aaron Mulder wrote:
On Tue, 9 Sep 2003, Alex Blewitt wrote:
The rationale for not having geronimo.ejb.EJB (the abstract
supertype for Session/Entity/Message beans) is that geronimo.ejb.Session
can't extend it!
That's why Greg is proposing that everything in J2EE land should
turn into
Greg Stein wrote:
There are few true barriers to adding committers. The notion of current
committers are not used to working together is a red herring. You're
already working with the community at large. It has nothing to do with the
current set of committers.
I would recommend coming up with,
Jeremy Boynes wrote:
I am reluctant to back out the current code as we don't have an
alternative at this time and so other stuff that depends on being able
to load DDs will break. I suggest we stay with what we have until an
alternative is available and then restart this discussion then.
Using
Jeremy Boynes wrote:
Why not try it out?
Because I have a fundamental disagreement with the approach.
Duplication and ignoring the standard descriptors is bad.
This is a strong felt concern, and I would need to see a lot more
support for your approach before I put this concern aside.
I'm also
Jeremy Boynes wrote:
Using the code is checked in resolution to discussions is
not a good precident to set.
The I don't like what you did but don't have a working alternative one
isn't either :-)
I think the proceedural point is that you should have flagged your
intent to try a single file
Jeremy,
a good summary of a very long conversation. Just a few small differences
I'd put at the end
Jeremy Boynes wrote:
Greg and I ended up having a very long IM discussion on the subject. We
did not reach agreement on a solution, but we did come up with a plan to
proceed.
Firstly, a couple
I'm looking at the POJOs for the deployment descriptors and I'm a
little confused by their design and what conventions they are meant
to follow.
The source of my confusion is that there are two inheritance
hierarchies that are partially implemented in the POJOs
One hierarchy is the standard typing
-1
I understand that the single file nature of this approach is considered
attractive. JSR154 was considering supporting such descriptor extensions
as part of the spec. However, this was removed from the spec and the
feeling is that the J2EE jsrs will no longer favour such descriptor extensions
does, except
instead of having a weird 2 file thing we put everything in a single
consistent descriptor.
-dain
On Saturday, September 6, 2003, at 08:26 PM, Greg Wilkins wrote:
-1
I understand that the single file nature of this approach is considered
attractive. JSR154 was considering supporting
I've always included the servlet classes source in Jetty - but mostly just
to get the javadoc generated. I guess the same logic applies here.
But can we not do this just yet as I'd like to get a basic web container
going this week and don't want to have to deal with this at the moment.
James -
+1 for james amendment (ie use a naming convention that gives us mashalling
for
free - but no opinion on betwixt vs digester etc.)
+1 for pojos (well for doing something).
I'm happy to write/generate the classes for the webapp deployment
descriptor - but there is now a twisty little maze of
Note that my votes are not strongly cast... so if we do end up
debating XMLBeans vs betwixt vs digester then I'm going to
retract my vote and push for just dom.
Note I still have not heard any real reason not to use dom - so
it is the obvious choice if we can't agree on anything else.
Greg
Dain Sundstrom wrote:
I applied this patch.
What exactly is conflicting between the two?
I have already done a commit to remove the conflict.
It was between getDeploymentDescriptor returning a String or
a Document.
cheers
-dain
On Thursday, August 21, 2003, at 04:33 AM, gianny DAMOUR wrote:
For the web container, it is pretty simple to setup a threadlocal
on the way into a web application context. However it is more tricky
if a servlet from one context dispatches to another context - as there
may not be suitable cut points to put in geronimo specific handling.
We can either
, but the spec does not say if they inherit any
of the context. But if inheritable can be done at little cost, then that
would be good.
cheers
Jeremy Boynes wrote:
From: Gmane Remailer [mailto:public=SUao4/[EMAIL PROTECTED] On Behalf
Of Greg Wilkins
For the web container, it is pretty simple
Bodo Wippermann wrote:
does not need to define its own identity, its already inherited.
Not applied.
We are currently talking about this in the thread
[deployment][jsr77] Dependency code in AbstractStateManageable.
I don't believe that AbstractStateManageable should have a name
and that this is
Done
sorry for the oops
Siva wrote:
Raphel is right.Can some one pls run the included patch
and delete the StateTest.java in the folder
specs\j2ee-management\src\test\org\apache\management\j2ee
Regards
Siva
- Original Message -
From: Ralph Apel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent:
Bodo Wippermann wrote:
to compile the unit tests the StateTest should also be moved.
and the package name should be corrected.
DOH! How did that pass the test harnesses!
fixing now.
.
cheers
Dain Sundstrom wrote:
On Wednesday, August 20, 2003, at 02:25 AM, Greg Wilkins wrote:
Can somebody explain what's the story with the dependency
code that has been checked in? Dain - is that you???
Yes that was me.
A lot of the deployment dependancy code appears to have been
added
Bodo Wippermann wrote:
tests the notification names and the Filter
patched thanks
Dain Sundstrom wrote:
[ lots of stuff ]
I still don't agree with lots of what you said - but your concrete
proposals below I can mostly agree with - and we can debate the
details later.
Here is what I plan on doing:
Add a ManagedObject interface
+1
Create an AbstractManagedObject which
I think it would be good if this information about Geronimo could be put
on the wiki FAQ.
Given that our meta name space uses the name of an entire native
american nation, I don't think it is inappropriate to call our project
after a prominant native american.
Surely if apache and it's feather
implementations.
Regards,
Vikram Goyal
--
/**
* Greg Wilkins
* Partner
* Core Developers Network
**/
Greg Wilkins wrote:
So I'm giving notice that I'm going to move
State
StateManageable
NotificationType
from specs/j2ee-management/src/java/org/apache/management/j2ee
to modules/core/src/java/org/apache/geronimo/management
OK, I'm going ahead with this. Commit in the next hour
Just to follow up on my own email I'd like to explain how
I see the deployment, container and component stuff working for
the web stuff (this is in the wiki, but I'll say it here).
I see the following web components:
WebContainer
WebConnector
WebApplication
WebAccessLog
We have been discussing this for a bit in the JSR77 threads.
While these classes are not part of the spec API, they are definitely
part of the spec. They are implementations of the object models
defined in the spec.
They have been put into the spec module so that we realize that they
cannot be
Dain Sundstrom wrote:
I just had a fairly bad CVS experience, and I know some others also
have. The problem is moving code. This causes big problems for people
with uncommitted changes, and makes for some very unhappy programmers.
I suggest that as a community that we agree to give at least
The JSR Object model classes have not part of the spec *API* - hence
they are not in the javax.management.j2ee package.
But they are defined by the spec. They are our java implementations
of Object models that are clearly defined in the spec. Thus I think
that putting them under the spec module
Dain Sundstrom wrote:
Before I sent the email, I rescanned the entire 77 thread and did not
find a single message mentioning that the entire 77 and 88 packages were
going to be moved.
We are talking about different things then. I think it was Jason who moved
the 77 and 88 trees - which he
Dain Sundstrom wrote:
I suggested org.apache.geronimo.management
OK - so we wont move them back to org.apache.geronimo.core package,
just the core module.
Having them 77 models in their own package is all that is really needed.
So I'm giving notice that I'm going to move
State
Paul Hammant wrote:
Daniel,
Jira is alleged to be the best.
http://jira.attlassian.com for those that want to play with it.
The correct url is: http://jira.atlassian.com
Indeed. I'm also guilty of not ready Greg's posting too well, which was
councelling to not use an issue tracker.
Jason Dillon wrote:
Per my previous emails I think we should vote to allow Alex Blewitt
commit rights.
I'm abstaining from this vote for now not because of anything
against Alex - but because I'd like to see the apache old hands run
the process for a bit (and because I have not yet had time
Jason Dillon wrote:
JSR77 is a bit strange.
Heh, to say the least.
It specifies object models, but without saying that they are actual
classes and definitely not saying what package they are in.
But these are part of the impl right and not the spec?
Yes and no :-)
I guess they are part of the
Berin Loritsch wrote:
Dain Sundstrom wrote:
BTW, they really aren't Java interfaces, but rather exposed management
interfaces, which are just naming conventions.
grumble, grumble, snarl, spit...
rant type=stupid specs
Why have a language feature like interfaces if you speicify in all your
I actually think that a tracking system at this stage would not help
much. Too many things don't work and many patches will be outdated
before they ever get applied.
I think we actually need a few more committers on the project. This
would both reduce the number of PATCHes generated and
JSR77 is a bit strange.
It specifies object models, but without saying that they are actual
classes and definitely not saying what package they are in.
So org.apache.geronimo.common.StateManageable is an implementation
of one of the JSR77 state models - but we can't put it in javax.management
as
I've been doing the JSR77 committing, but I'm not sure if I'm
going to take the responsibility of managing the jsr77 implementation.
I have only really been doing it so I can get it to the stage that
I can work on the AbstractWebContainer components.
Gianny and Maas have been making some good
I'll let jasons work on the spec module settle a bit and then
look at committing these.
cheers
gianny DAMOUR wrote:
Hello,
These should be interface definitions rather than concrete classes -
there
could be a variety of classes implementing them.
I diagree with this one. It is nice to provide
about JSPs!-)
So thanks again for jasper! Good work guys!
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
-
To unsubscribe, e-mail: [EMAIL
new DeploymentException(e);
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
Alex Blewitt wrote:
You just need to be able to read through the configuration using an
Iterator, surely?
Not if you want automatic persistence. Making it a Bean is good.
but whatever I agree it is a bad idea for this Container.
So how about the following
void addComponent(Component)
James Strachan wrote:
On Thursday, August 14, 2003, at 11:56 am, Alex Blewitt wrote:
Though as soon as I did this something hit me - if you add a
component by itself - and a component doesn't have an ObjectName (at
least on the Component interface today) then how does the Container
know the
James Strachan wrote:
How's this?
public interface Container extends Component {
public ListIterator getComponents();
public ListIterator getComponentNames();
public void addComponent(Component component);
public void removeComponent(Component component);
}
But then Adrian Jackson wrote:
Jason Dillon wrote:
I am going to be moving this.
Should the model classes also live under the spec module?
Gianny has proposed org.apache.geronimo.j2eemanagement
as the package. But would prefer org.apache.management.j2ee
or org.apache.geronimo.management.j2ee to match better
with
Jason Dillon wrote:
[Exception] IllegalArgumentException: address must not be null
+1
org.apache.geronimo.common.NullArgumentException extends IAE and handles
the formatting of the message too, so you can:
throw new NullArgumentException(address);
I will only +1 the NullArgumentException if it
You can access the jasper configuration in Jetty via
the webdefault.xml in the jbossweb-jetty.sar
regards
JD Brennan wrote:
Do you have an example of what the web.xml mappings
would look like? I've checked the Tomcat docs, searched
the JBoss 3.2.1 source tree and even read the web.xml
DTD, but I
Scott M Stark wrote:
... especially given the fact that there was no discussion on any
public or private JBoss channel...
We have been told many times in public and private not to post dissenting
views to the jboss lists - so we could hardly discuss our reasons for
a fork there. Plus many of
is due. Specifically that my listing
be returned to the JBoss developers page - at leasted listed in the
forced to retire section. Due credit is the least that one can expected
for their contributions.
regards
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting
Firstly a note to the list moderator: This is a request for CVS access, so
I believe that it is on topic and should not be censored.
Bill Burke wrote:
JBoss Group, as caretaker of the JBoss project, has recently decided to
remove CVS access committers for a few of our committers. We do not remove
community for geronimo to be a success.
So given that this is happening - constructive criticism is welcome.
But complaints about why it was started in the first place are just
a waste of bandwidth.
cheers
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting
Jochen Wiedmann wrote:
Quoting Greg Wilkins [EMAIL PROTECTED]:
However, open process is at least as important as open software.
Agreed. But the ASF has just given a bad example on this (IMO).
Following the discussions on Geronimo in the last days, my
impression is that a lot of decisions
see
how pride, ego, control etc. can be motives for joining a democratic
meritocracy?
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
.
I'll give this a few hours for DON'T DO IT reponses and if I don't
get them I'll do the commit and we can work on the remaining issues.
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
Index: modules/core/src
August 2003 09:00 pm, Greg Wilkins wrote:
OK, I have an initial patch for this ready. I can commit it myself,
but I wanted to post it as a warning as it has a few unresolved issues.
I have implemented the JSR77 state model in Component and AbstractComponent
For start and stop this was simple. But I
) has at least got
our vocab and states into the same ball park as JSR77. Hopefully
we can move the structure closer soon as well.
cheers
Sean Hamblett wrote:
On Tuesday 12 August 2003 11:30 pm, Greg Wilkins wrote:
Greg,
Thanks! I appreciate the details on the component/container relationship
forward). But if you want to do this yourself... feel free to
take this over for now.
cheers
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
undocumented MBeans without real meta data. We can also expose
more of an object simply by changing the MBean descriptor file.
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
but in the tomcat 5 releases.
thanks
PS. can I be cc'd on any replies as I don't read this mailing list.
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
project
pomVersion3/pomVersion
idjetty/id
nameJetty
infrastructure, but that's a different thread. :)
Aaron
On Sat, 9 Aug 2003, Greg Wilkins wrote:
Here is what I'm thinking about the geronimo web container.
I would like to see the container, the connectors and webapplications
as all top level geronimo components (aka services).
They would all have
Jules Gosnell wrote:
Greg Wilkins wrote:
I don't expect the webconnector service to actually implement the
connector - as JMX is not really the right sort of bus to push HTTP
requests/responses over. Instead I see the webconnectors pushing
their
configuration at the webcontainer
I don't know if this falls into the too much choice is a bad thing
arena, but would it not be good if we could have both a dynamic jboss
inspired EJB container and a compiled EJB container (perhaps from
or inspired by the JOnAS folks??).
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44
differing behavior when running in
development from when running in production.
Enjoy,
Craig
- Original Message -
From: Greg Wilkins [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, August 10, 2003 1:07 AM
Subject: Re: Reflection Bad, OO and direct Method invocation Good...
I don't know
Barlow, Dustin wrote:
Maybe its time for the CDN folks to be a little more forthcoming about their
real intentions and explain why they felt they needed to plan and implement
their flight/fork from the JBoss Group in secret.
Most new companies are conceived and put together in private.
There is
in implementation, configuration and behaviour.
I hope the get a skeleton of all this going in the next week or two.
cheers
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
You can simply set your own handler in the root context and
if it handles all requests, then a not found handler will never
be created or used.
You can also do this without jetty too much specific code simply by
creating a root webapp as part of the jetty configuratoin (call
addWebAppliction).
an option not to auto start?
cheers
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
an option not to auto start?
cheers
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
for them in $(java.lib.home) and allow that
to be set to /usr/share/java (but default to $(jetty.home)/ext)
That's enough for 1 email I'll try to work out what the
classpath issue is on my system.
Thanks for this package!
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort
that file to be edited to turn these demos off. Probably
OK if we describe how to do that on a jetty-debian home page.
Finally- if you have an ant target that builds the deb packages,
please send it to me and I'll put it in the standard Jetty package
under jetty/extra/debian.
thanks again.
--
Greg
Scott M Stark wrote:
You have a cron job removing these files. Override the location jetty
uses for its temp storage by setting the java.io.tmpdir property to
point to the jboss
server/x/tmp directory for example.
Jason was going to change the JBoss startup so that it set java.io.tmpdir
to the
several related open source technologies.
While this is not an internals course, details of the container
implementation are presented where important or interesting.
10% discount still available for bookings before July 25.
I hope to see you there.
--
/**
* Greg Wilkins
and
hopefully it will continue to live in the JBoss project (although we may
want to review the duplicate source tree issue).
The intent will be to keep the web container services totally pluggable
so that you can simple drop in the web sar of *your* choice.
regards
--
/**
* Greg
Sacha Labourey wrote:
Consequently, in any case, what is the process to get RW access to Jetty?
Ask - and almost always you shall receive.
If you want I'll give you access and you can check these
changes in, but if they are just stats changes then I'm happy to do it
my self as it will probably
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet
use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
---
This SF.net email
of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
---
This SF.NET email is sponsored
with some intelligence should...
I just verified that both Tomcat and ServletExec correctly interpret the
specification and map stuff as the exception on page 76 mentions...
I'm CCing Greg Wilkins on that as he might be aware of a trick to make it
work, or maybe he can help us fix the engine, and get
that should be OK, seeing that I probably borrowed those 45 lines from
apache. It is their log format after all :-)
cheers
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
---
This SF.net email is sponsored
jboss normally. I can see the logic of this (simplicity) but
in reality it really should use the jars from /usr/share/java
is that your eventual intent?
cheers
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http
Joe Phillips wrote: On Mon, 2003-01-20 at 05:00, Greg Wilkins wrote:
Your jboss debs for 3.0.2-2 deployed without problems on my
debian sid system. Good work!
+ Does it really need to depend on your jdk1.4 package?
Jboss can run on 1.3 and most debian users will have already
web
container).
2.4 could handle multiple web container instances ( of the same or different
types). 3.0 does not cope so well with that.
cheers
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http://www.mortbay.com
jboss normally. I can see the logic of this (simplicity) but
in reality it really should use the jars from /usr/share/java
is that your eventual intent?
cheers
--
Greg Wilkins[EMAIL PROTECTED] Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK. http
701 - 800 of 943 matches
Mail list logo
