For what it's worth, I tend to create a project with one gigantic
module containing all the Geronimo source paths. That way it will at
least resolve all the module cross-references, and you only need to come
up with one huge set of libraries across all the Geronimo code.
The do
N!!! Please, no start braces on separate lines. I don't care
for the extra spaces around parentheses much either. Though I'm cool with
all spaces / no tabs.
Aaron
On Thu, 27 May 2004, Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
> +1
>
> We use this
> http://avalon.ap
[X] Yes, switch to SVN.
[ ] No, stick with CVS.
[X] I don't care if the history is imported.
[ ] I want the history imported.
Will there be any particular version of subversion required? I
have "1.0.0-73.3" (the latest from SuSE)
Aaron
I think the most spec-compliant way to do this would be to fire up
a JSR-88 deployment tool, fully configure the module, and then save the
deployment plan to a file. Then we could provide a (fully portable) Ant
task that would deploy a module given the xAR and saved deployment plan.
(Not
; the right order, being sure to put the compiled schemas we want to use
> first before the ones from a parent classloader.
>
> david jencks
>
> On Saturday, February 21, 2004, at 06:25 AM, Aaron Mulder wrote:
>
> > Jeremy,
> > Do you think there's so
Jeremy,
Do you think there's some way to tell XMLBeans to load a document,
and let the only references to that schema type be assigned to the loaded
elements? In other words, the XMLBeans infrastructure should "load and
forget"? If so, you still have to expect, in the general case, that t
I guess my hope would be that in the example below, the n1 prefix
would be inherited by the children, so in essence it was legal to refer to
the first child with either "n1" or "n2" and the second child with either
"n1" or "n3". I wouldn't expect that to be the case if the URIs were
di
So I'm trying to run a JSR-88 tool that uses XMLBeans for the J2EE
DDs against the Geronimo (connector) JSR-88 plugin that also uses XMLBeans
for the J2EE namespace. Problem is, the tool doesn't use the same package
names that the Geronimo plugin does. And apparently there's some static
m
And tools, at least insofar as we have command-line or application
tools (such as a deployer or command-line admin tools) that are running
neither in the server nor on it, but still communicate with it. though
there's no reason these couldn't be bundled with the web apps.
Aaron
On Sat, 1
Another thing I've noticed about XMLBeans is that it doesn't seem
to validate while reading a document -- at least by default. That means
that if someone hand-codes a DD, we'll just silently ignore any errors and
they won't understand why certain DD features "just don't work".
Aaron
On F
On Tue, 10 Feb 2004, Jacek Laskowski wrote:
> This is because clean must not be called until Geronimo has already been
> built. Please follow instructions at
> http://wiki.apache.org/geronimo/BuildingAndRunning.
Of course, the page above doesn't mention that the clean doesn't
work until
Never mind -- it worked after a clean build.
Aaron
On Mon, 9 Feb 2004, Aaron Mulder wrote:
> Now I'm getting the test error Jeremy mentioned.
>
> Aaron
>
>
> test:test:
> [junit] Running
> org.apache.geronimo.connector.deployment.Connector_1_0Te
ruary 8, 2004, at 04:18 PM, Jeremy Boynes wrote:
>
> > Aaron Mulder wrote:
> >
> >>I just checked out a new tree and tried to build. I did a rebuild
> >> in the modules/maven-xmlbeans-plugin directory first as per David's
> >> advice. Now when I
I just checked out a new tree and tried to build. I did a rebuild
in the modules/maven-xmlbeans-plugin directory first as per David's
advice. Now when I build, I get compile errors on the XMLBeans generated
classes. It looks like the classes are there, just with the wrong package
or
On Mon, 26 Jan 2004, Jeremy Boynes wrote:
> Can you put a e.printStackTrace in DistributeCommand at line 127 (call
> to fail()) to see what is happening?
org.apache.geronimo.deployment.DeploymentException: Unable to unpack WAR
content
at
org.apache.geronimo.jetty.deployment.JettyModule.
On Mon, 26 Jan 2004, Jeremy Boynes wrote:
> > I'm seeing the testPacked test in jetty DeploymentTest fail on my Linux
> > machine but pass on os X.
> >
> > Haven't investigated, anyone else see this?
Fails for me too (also on Linux). Could it be a case sensitivity
problem?
Aaron
On Mon, 26 Jan 2004, Dain Sundstrom wrote:
> I would prefer the tool ask the provider for the desired location for
> the streams to be stored, which would also allow the provider to have
> the file name end with .xml, and allow the configurations to be
> seamlessly portable between tools.
On Mon, 26 Jan 2004, Dain Sundstrom wrote:
> > Now you are being dense. You have to be able to transport it over
> > the network in one stream. Is that so onerous?
>
> I disagree. We write the provider layer and we may send the
> information to the server in several disconnected streams. T
On Mon, 26 Jan 2004, Jeremy Boynes wrote:
> So for 88 to be useful, the vendor must support having all their DD
> information in one file? But the RI does not that...
Now you are being dense. You have to be able to transport it over
the network in one stream. Is that so onerous? Whatev
I'm afraid I have to object to the decision to move all the server
deployment information to become the responsibility of individual modules.
I think it will be a bug not a feature if the web deployment information
and format is different depending on whether you're using Tomcat or Jetty,
On Mon, 26 Jan 2004, Jeremy Boynes wrote:
> Sorry if I'm being dense, but how does the tool merge together all the
> server specific information? For example, there could be several files
> generated by different calls to save(OutputStream) and
> save(OutputStream, DConfigBeanRoot) for the diffe
On Sun, 25 Jan 2004, Jeremy Boynes wrote:
> A couple of things in the JSR 88 API don't make sense to me - if anyone
> has definitive answers I would appreciate it.
>
> On distribute(), what exactly is the "deploymentPlan" passed in? I am
> assuming that it is the tool's responsibility to pass in
On Sun, 25 Jan 2004, Jeremy Boynes wrote:
> That just seems so wrong :-(
>
> On the other hand, the DDBeans themselves are immutable so the only
> events DConfigBeans receive would pertain to changes in the tree.
> Provided whatever is mutating the XML notifies all replicas we should be OK.
>
>
Any given DConfigBean should only be asked for child DConfigBeans
corresponding to the XPaths returned by getXPaths(). However, if a
DConfigBean wants to access an arbitrary DDBean (for example, to put a
listener on it), it can use either an absolute or relative XPath to locate
that DDBean
What (if anything) will replace twiddle? Currently the JSR-88
client uses it to start.
Thanks,
Aaron
On Wed, 21 Jan 2004, David Jencks wrote:
> We have been converting much of Geronimo to the new GBean framework,
> which is proving to provide considerable conceptual and code
>
bstantial concurrency level and the iterators will reflect
> > the current state of the collection as much as possible.
> >
> > Ed Letifov.
> >
> > On Monday, Jan 12, 2004, at 19:57 Europe/Amsterdam, Aaron Mulder wrote:
> >
> >>We may also want to
We may also want to consider that instead of copying the
Collection at iteration time, we could copy it only at update time, and
then write the new (changed) version over the old (iterated) version,
leaving the only references to the old collection with the iterators.
I'm assuming that we
On Tue, 6 Jan 2004, Jeremy Boynes wrote:
> Yeah, sorry - it's taking longer than expected but I have to work as
> well :-)
If you think it's going to be a problem, we could always put it in
a branch so more people can work on it before it's "done".
> It is very close to the 88 model.
>
I believe Jeremy is in the midst of some significant changes to
the deployment process. Perhaps he can comment, but I'm guessing this
isn't the best time to work on new deployment features.
The ApplicationDeployer is the JSR-88 server side. All the
unimplemented methods are ba
On Sun, 4 Jan 2004, Jeremy Boynes wrote:
> > Reorganization proposal:
> >
> > 1. move LocalEntityResolver to kernel module. IMO it should be used for
> > validating/loading mbean configurations. This will presumably also
> > require setting up its mbean in the boot.mlet.
> >
>
> -1 as the ke
I think it needs to happen during distribution, before we attempt
to start the module. However, this depends on the ClassSpace being set
up, because the validator will want to load classes to make sure the right
methods are present, etc.
Aaron
On Thu, 1 Jan 2004, Jacek Laskowski wrote
I'm confused; there's code out there, and you added your Wiki
comments to the page that describes the code. What are your questions
about the direction?
I will note that the general movement seems to be to allow
individual services to do their own thing, which if applied in this
[+0.5] Yes, Keep the name Geronimo
[] No, Change the name
I have some concern over the name in the sense that it might be
hard to sell "let's use Geronimo" to a project manager who thinks "jump
off a cliff". Basically, I'd prefer not to have "additional risk"
associated with the pro
While we're on this class, we also need a distributeURL.
I wonder if it wouldn't be better to change this class to have
only distributeURL and undeployURL, and let the MBean created for the
deployment handle the starting and stopping (deploy = distribute + start
MBean). We'd have
This looks like the code was compiled under JDK 1.4 and run under
JDK 1.3, or something like that (thus the class with the unsupported
version, which is the JDK complaining). It shouldn't be related to the
hangs. Those usually mean your network connection is down, or the machine
can't
Apaprently BEA and IBM have pulled together some extensions for
J2EE app servers which they intend to implement and propose as JSRs.
Probably worth keeping in the back of our mind.
http://news.com.com/2100-7345-5111567.html?tag=nl
Particularly:
"The three technical specificati
On Mon, 24 Nov 2003, Noel J. Bergman wrote:
> They don't, as far as I know. Geronimo is hardly the only project to raise
> a concern about "190MB of generated artifacts in CVS?!" There are various
> alternative solutions being looked at, including a build server. So look
> for things to change d
We (by which I think I mean myself, Jeremy, and David J) talked a
bit at ApacheCon about changing our strategy on deplyoment descriptors.
Our conclusion was that we should split the DDs up again, so that Geronimo
DDs *do not* extend J2EE DDs, but we have 2 separate DD structures. As
f
On Mon, 24 Nov 2003, Bordet, Simone wrote:
> It's because JMX allows to register the same listener with different filters.
Okay.
> Not following here.
>
> The listener stays on the client, and in JSR 160 semantic is not a
> remote object: it is burden of the "framework" to handle these de
On Mon, 24 Nov 2003, Hiram Chirino wrote:
> Thanks for updating the test case.. It made it easy to track down the
> problem. It turns out that the reason that the NotificationListener is
> not properly removed is because the filters are being passed by value in
> the addNotificationListener an
On Sun, 23 Nov 2003, Jeremy Boynes wrote:
> This most definitely does *not* support changing the stack on the fly.
> In Geronimo, the stack is built when the container is started and
> remains constant until it stops. This avoids the need to synchronize on
> getNext(), and eliminates the potenti
Okay, with the latest changes, the extraneous connections and OOM
error are gone (thanks Hiram!). It turns out I was mistaken about the
original NotificationFilter issue. I have made my filter serailizable,
and it gets applied on the server side.
However, I've now got a differ
On Sun, 23 Nov 2003, Markus Karg wrote:
> thanks for the answer. I'll do some tests in the next weeks, maybe I'll
> bother
> you with some questions then... ;-)
>
> There is one question which actually is not essential but I just wanted to
> ask. The JSR-88 spec tells that the deployment manage
Markus,
Right now the Geronimo JSR-88 implementation is "partial". There
are DConfigBeans available (mainly for EJB JAR modules, but a couple for
web app modules too), and they should do the right thing, but the other
modules types and the actions (distribute, start, etc.) are by and large
I'm working through the remote JMX notifications now (thanks
Hiram!). The basic operation seems to be fine. There's one strange
issue, though. When I remove the listener, after some time has passed
(60-90 seconds), there's a stack trace on the server side during firing
events. Then ther
On Sat, 22 Nov 2003, Noel J. Bergman wrote:
> By and large, things seem to be going well here. The overall view should be
> positive. There will be more contribution of direction. And we need to
> instill a mindset within the Geronimo Community about working within the
> ASF, rather than looking
I call to terminate the project immediately, on the basis that it
used the Codehaus Wiki instead of the "proper" Apache Wiki before Apache
adopted that Wiki after all, which at least remotely smells like working
around the Apache infrastructure to me.
Does that make sense?
On Thu, 20 Nov 2003, n. alex rupp wrote:
> Great : )
> What's the name of the tool, and how is it licensed?
It's in CVS (core module, o.a.g.console.cli)
Aaron
Alex,
There's a command-line deploy tool you can look at if you want to
see how a generic JSR-88 tool interacts with the DConfigBeans. The
command-line tool doesn't offer standard DD editing, though it should.
Basically, you'll have to write an implementation of the DDBeans for
standard
It looks like the new ClassSpace element is required in
geronimo-ejb-jar.xml -- is that intentional? Is there no way to get a
"default" class space?
Aaron
I've finished some changes to the deployer. Now the JSR-88
application deployer has moved into the kernel, and all deployment
activity goes through it (including service deployment). As for the
DeploymentController, it now has a queue of pending deployment activities,
and it runs them one
Um, I thought he had said he planned to revise his patches again
(after the last round of mailing list discussion) and I was kind of
waiting on that. Maybe I was just confused.
In any case, I'll be able to put in some solid time on this at
ApacheCon, starting tomorrow, so we shou
opefully that helps.
>
> --Keith
>
>
> Aaron Mulder wrote:
> >
> > XMLBeans does not support our schemas. I tried to follow up with
> > them on the XMLBeans mailing list, but it was dropped. There's a similar
> > story with Castor, thoug
XMLBeans does not support our schemas. I tried to follow up with
them on the XMLBeans mailing list, but it was dropped. There's a similar
story with Castor, though at least in that case I was asked to expect a
delay. Haven't tried JAXB, though I haven't heard great things about it
ei
What's even *more* interesting than the new specs is the fact that
the JCP can apparently see into the future! Perhaps this isn't the real
world... Perhaps we're all living inside a machine... Oh, wait.
Aaron
On Wed, 5 Nov 2003, David Blevins wrote:
> I pulled this data from the JCP
On Tue, 4 Nov 2003, Dain Sundstrom wrote:
> That is what I thought. We can easily find all deployments with an
> ObjectName pattern query.
> ...
> That won't work. Dependencies are static and so are notification
> listeners, so when every you changed states you would have to
> reestablish all
I thought we were going to use the JMX ObjectNames to identify
deployments, rather than keeping an actual repository somewhere? I guess
one of the questions to answer on that score is whether we could put the
status as a property in the ObjectName and change it as the module is
started
On Thu, 30 Oct 2003 [EMAIL PROTECTED] wrote:
> The following comment has been added to this issue:
>
> Author: Jan Bartel
> Created: Thu, 30 Oct 2003 2:50 PM
>Body:
> The AbstractStateManageable changes have been checked in.
>
> Aaron, can you please articulate a proposal that ad
On Wed, 29 Oct 2003, Noel J. Bergman wrote:
> You should also think of proposals for Software Summit
> (www.softwaresummit.com), which is a far more technical conference. And, of
> course, ApacheCon.
I think the deadline for submitting proposals for both of those is
past... Or not open y
vaOne (San Francisco, USA, June 28-July 1, 2004).
Aaron
On Wed, 29 Oct 2003, Aaron Mulder wrote:
> Is anyone interested in working on Geronimo-related proposals for
> JavaOne 2004? Of course, it'll be a bit of a shot in the dark as to what
> will be ready by that time, but t
Is anyone interested in working on Geronimo-related proposals for
JavaOne 2004? Of course, it'll be a bit of a shot in the dark as to what
will be ready by that time, but there have certainly been a number of
people asking for a timeline... :)
Aaron
On Sun, 26 Oct 2003, Emerson Cargnin wrote:
> While trying to debug geronimo, when the debugger reachs the following code :
>
> ThreadGroup group = new ThreadGroup("Geronimo");
> Thread mainThread = new Thread(group, main, "Main-Thread");
> mainThread.start();
> mainThread.join(); // stops here
>
If you e-mail me the images, I can check them in to CVS, and then
you can refer to them from the (Codehaus) Wiki. This is what I did for
the images on the Architecture/Deployment and Architecture/JSR-88 pages
(and you can see the source code to include the images on those pages).
.
Aaron
> [EMAIL PROTECTED] wrote:
> > Message:
> >
> >The following issue has been closed.
> >
> >Resolver: Aaron Mulder
> >Date: Tue, 21 Oct 2003 10:16 AM
> >
> > Closed per Gianny's request.
> > -
On Mon, 20 Oct 2003, gianny DAMOUR wrote:
> I though that you intended to implement these JSR-88 commands via
> ApplicationDeployer?
My intention was that the initial call goes to the
ApplicationDeployer, and it assembles a series of goals and hands those
over to the DeploymentManager to
One of the first questions I have for the people working on this
is related to Web Services support for EJBs (required for EJB 2.1). I'm
assuming AXIS will be used for this. I wonder whether all the information
required to do it will be available in the standard J2EE web services
deployme
I'd like to make some improvements to the kernel
DeploymentController. Specifically, I'd like to work on implementing the
JSR-88 command "start", "stop", "undeploy", "distribute", "redeploy", etc.
Several of these take multiple modules to operate on, and all return a
"progress object"
On Sun, 19 Oct 2003, Hiram Chirino wrote:
> Can you point send me a script of the commands you are running that gets
> this to fail? I'm sure it's a problem somewhere in the async remoting
> transport layer. It's quite new and has not received that much testing
> :( Platform info would be good
I've gotten the JSR-88 command-line client a little further, to
the point where I make 6 or 8 JMX calls when I'm working with it. This
often fails with a timeout error, but not always. Lately, when I start
the Geronimo server, the first time I fire up the client it fails, but if
I the
I changed the namespace flag in the properties file. Now I've got
a new and different error. :)
Aaron
[echo] Generating sources for
/home/ammulder/cvs/geronimo/modules/xbeans/src/schema/geronimo-application-client.xsd
[java] -- Disabling generation of Marshalling framework met
stor.properties file.
>
> in the castor.properties file change the following line:
>
> org.exolab.castor.parser.namespaces=false
>
> to:
>
> org.exolab.castor.parser.namespaces=true
>
>
> --Keith
>
>
> Aaron Mulder wrote:
> >
> > I
I tried Castor 0.9.5.2 on my DD Schemas, and I get the stack trace
below. The error is complaining that I've tried to map "xml" as a
namespace, but I'm pretty sure I haven't -- I've looked through the files
and grepped for "xmlns:xml" and "xml=" and so on and found nothing. If
someone fro
I have to agree with David. Part of the "distribute" step will
involve ensuring that the package is runnable (validation, generating any
required code, etc.), and another part is generating a living MBean with
which the archive/application can be started, removed, etc. I don't think
it's
Any design notes I have left are on the (Codehaus) Wiki (and
relate to deployment, management, and JSR-88, IIRC).
Aaron
On Mon, 13 Oct 2003, Cabrera, Alan wrote:
> The documentation that you seek has been partially completed. Some pieces
> are done more thouroughly than others w/ some no
On Mon, 13 Oct 2003, Arnaud Blandin wrote:
> The behavior you are experiencing appeared when we introduced native
> SAX2 support in support. We believed it is a Xerces bug but we checked
> in a workaround in the latest version of Castor (CVS). You can download
> a nightly build that should include
On Sun, 12 Oct 2003, Jacek Laskowski wrote:
> Once Castor's team joined the mailing list and are ready to work out any
> issues we've seen so far, who is in charge of deciding whether Castor is
> the tool of our choice and we cease *immediatelly* writing POJOs and
> handling mapping between XMLs
On Fri, 10 Oct 2003, Bruce Snyder wrote:
> Funny you should mention this. I am considering a map that people
> add themselves to via MapServer, PostGIS and PostgreSQL. We'll see
> if I even have the time to implement it ;-).
As long as you're going that far, you might as well add the optio
Philadelphia, PA USA (or thereabouts)
Aaron
My sense is that none of the tools is a "perfect fit" out of the
box, so it's just a matter of working through the necessary
customizations. I think I'm quite close to being satisfied with XMLBeans
-- I suspect I just need to straighten out our Geronimo namespace and then
wait for the
First of all, I think the ApplicationDeployer needs to be involved
when things are auto-deployed as well as JSR-88 deployed. So it should be
involved in every deployment (at least to the degree that it can track
them if it wants to). I belive the module type and target(s) must be
conveyed
On Wed, 8 Oct 2003, Cabrera, Alan wrote:
> Since we're talking about XML, have we decided on the issue of namespace
> targets? Am I the only one who thinks that modifying Sun's elements and
> putting them back into Sun's namespace is a bad idea? If I am, then why is
> this a non-issue?
I
On Wed, 8 Oct 2003, Jacek Laskowski wrote:
> Does it mean that we're considering it as a tool to handle our XML files
> ? I thought we'd agreed that the files were to be parsed by our own
> code. Would it be changed in the future? When? I doubt if we keep
> writing the code ourselves nobody will ev
XMLBeans is now in Apache, and I've gotten the Apache version to
generate, read, and write POJOs for the DDs. The JAR I built from the
Apache source is about the same size as Castor, which is not great, but
1/2 of the pre-Apache version.
On the down side, it's very slow to read
I agree with the ideas below. One note: I'd like the default, if
no jndi-root is specified, to be that each application goes in its own
JNDI root (rather than defaulting to everything being shared in one).
I'd also like to back this up with ClassLoader separation, so that if two
apps end
Just to kind of recap where we are (I think):
- I favor a central deployer which delegates only where necessary
- Jan favors separate deployers per module, with a common base class
- We seem to be more or less in agreement on the API, whichever way it
ends up being implemented
- Gianny was go
Okay, this is a bunch of inline responses, with a specific code &
procedure proposal at the very end:
On Sat, 4 Oct 2003, Jan Bartel wrote:
> I agree there may be common code that can be extracted for the
> deployment of various j2ee artifacts such as ears and wars. This will
> come out
Okay, had another IM conversation with Jeremy, and some new things
came to light, and I'll present this as an alternative to the previous
option. As before, please feel free to chime in with feedback.
1) There will be some way of saving the current MBean state of the server
and reloading
Alex and I talked a bit more by IM, and this is what we came up
with. Please feel free to send any comments.
1) We will save all distributed files to one directory, and we will set
that to be the same as the "deploy" directory by default (keeping all
deployments in the same location, w
On Fri, 3 Oct 2003, n. alex rupp wrote:
> My point here is that versioning issues should be resolved in the EJB and
> Servlet containers respectively, not by the application loader. I remember
> discussions specifically regarding the above example from several weeks ago
> occurring between dain an
On Fri, 3 Oct 2003, n. alex rupp wrote:
> Q&A from the wiki page asked this question:
>
> "Question: What happens if you place an application module in the
> auto-deploy directory, so it is deployed, and then you go in via JSR-88 and
> undeploy it? Presumably, it must be removed from the auto-depl
On Fri, 3 Oct 2003, Jeremy Boynes wrote:
> ...
> Anything that is explicitly deploying an application should *NOT* do it
> by copying stuff into the deploy directory. Instead it should pass a URL
> to the DeploymentPlanner and let it figure out the details.
> ...
> So basically, distribution is a d
On Fri, 3 Oct 2003, n. alex rupp wrote:
> I'm not certain we're moving in the right direction with this, Aaron.
Well, that's why I asked!
> > Next, if we want to support the best-case deployment behavior,
> > where old requests finish against the old code and new requests go against
> > t
So we've got the one main deploy directory, where you can dump
stuff that you want to deploy (apps, server modules, etc.). The JSR-88
separation of "distribute" and "deploy" raises some problems though. When
"distribute" is called for an application, the application needs to be
sent o
Jan (and Greg),
This looks cool.
That said, I'd like to work on centralizing some of the deployment
logic. All the work of dealing with deployment plans and tasks is going
to be fairly common across application module types, and we'll need to
bring a lot of it together when we dep
I'm currently working on fleshing out the Deployment documentation
page a bit more. I put a diagram up there that touches on the Geronimo
JMX architecture, management, and deployment. I'm going to start working
on the description of the existing deployment features now.
Aaron
http://
Dain,
Can you say how the revised code fixes the issue? Does it do
something similar to what Gianny described, or just default to a different
parent?
Would it make sense to apply Gianny's change for now and then you
can apply your update when you have time?
Thanks,
Aar
I've got most of the wiring in place now (the JSR-88 client can
talk to a remote server and there's plenty of DD plumbing [for EJBs
anyway]), but you still can't actually deploy an application. I'm next
going to work on implementing the server-side JSR-88 features for
deployment. That sti
replace
it with something more like the geronimo-ejb-jar.xsd
Aaron
On Wed, 1 Oct 2003, Aaron Mulder wrote:
> On Wed, 1 Oct 2003, Alan D. Cabrera wrote:
> > The schema target namespace seems to be http://java.sun.com/xml/ns/j2ee.
> > Shouldn't it be http://geronimo.apache.org
On Wed, 1 Oct 2003, Alan D. Cabrera wrote:
> The schema target namespace seems to be http://java.sun.com/xml/ns/j2ee.
> Shouldn't it be http://geronimo.apache.org/xml/schema/j2ee?
I think we need to discuss this. I originally thought to use the
http://geronimo.apache.org/xml/schema/j2ee
On Wed, 1 Oct 2003, Jason Dillon wrote:
> o.a.g.c.Classes.loadClass() already does this, though not sure if it is
> still there with the recent move of stuff...
No it doesn't -- it only tries the TCCL -- it doesn't fall back on
any other CL if the TCCL fails. Of course, you could pass i
1 - 100 of 264 matches
Mail list logo
