Nabble - Apache XML - Commons - Dev

Fw: CFP open for ApacheCon Europe 2009

2008-10-02T06:31:55Z

FYI.

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Noirin Shirley <noirin@...> wrote on 10/02/2008 04:22:06 AM: > PMCs: Please send this on to your users@ lists! > > If you only have thirty seconds: > > The Call for Papers for ApacheCon Europe 2009, to be held in > Amsterdam, from 23rd to 27th March, is now open! Submit your proposals at > http://eu.apachecon.com/c/aceu2009/cfp/ before 24th October. > > Remember that early bird prices for ApacheCon US 2008, to be held in > New Orleans, from 3rd to 7th November, will go up this Friday, at > midnight Eastern time! > > Sponsorship opportunities for ApacheCon US 2008 and ApacheCon EU > 2009 are still available. If you or your company are interested in > becoming a sponsor, please contact Delia Frees at delia@apachecon. > com for details. > > ******* > > If you want all the details: > > ApacheCon Europe 2009 - Leading the Wave of Open Source > Amsterdam, The Netherlands > 23rd to 27th March, 2009 > > Call for Papers Opens for ApacheCon Europe 2009 > > The Apache Software Foundation (ASF) invites submissions to its > official conference, ApacheCon Europe 2009. To be held 23rd to 27th > March, 2009 at the Mövenpick Hotel Amsterdam City Centre, ApacheCon > serves as a forum for showcasing the ASF's latest developments, > including its projects, membership, and community. ApacheCon offers > unparalleled educational opportunities, with dedicated > presentations, hands-on trainings, and sessions that address core > technology, development, business/marketing, and licensing issues in > Open Source. > > ApacheCon's wide range of activities are designed to promote the > exchange of ideas amongst ASF Members, innovators, developers, > vendors, and users interested in the future of Open Source > technology. The conference program includes competitively selected > presentations, trainings/workshops, and a small number of invited > speakers. All sessions undergo a peer review process by the > ApacheCon Conference Planning team. The following information > provides presentation category descriptions, and information about > how to submit your > proposal. > > Conference Themes and Topics > > APACHECON 2009 - LEADING THE WAVE OF OPEN SOURCE > > Building on the success of the last two years, we are excited to > return to Amsterdam in 2009. We'll be continuing to offer our very > popular two-day trainings, including certifications of completion > for those who fulfill all the requirements of these trainings. > > The ASF comprises some of the most active and recognized developers > in the Open Source community. By bringing together the pioneers, > developers, and users of flagship Open Source technologies, > ApacheCon provides an influential platform for dialogue, between the > speaker and the audience, between project contributors and the > community at large, traversing a wide range of ideas, expertise, and > personalities. > > ApacheCon welcomes submissions from like-minded delegates across > many fields, geographic locations, and areas of development. The > breadth and loosely-structured nature of the Apache community lends > itself to conference content that is also somewhat loosely- > structured. Common themes of interest address groundbreaking > technologies and emerging trends, successful practices (from > development to deployment), and lessons learned (tips, tools, and > tricks). In addition to technical content, ApacheCon invites > Business Track submissions that address Open Source business, > marketing, and legal/licensing issues. > > Topics appropriate for submission to this conference are manifold, > and may include but are not restricted to: > > - Apache HTTP server topics such as installation, configuration, andmigration > - ASF-wide projects such as Lucene, SpamAssassin, Jackrabbit, and Maven > - Scripting languages and dynamic content such as Java, Perl, > Python, Ruby, XSL, and PHP > - Security and e-commerce > - Performance tuning, load balancing and high availability > - New technologies and broader initiatives such as Web Services and Web 2.0 > - ASF-Incubated projects such as Sling, UIMA, and Shindig > > > Submission Guidelines > Submissions must include > - Title > - Speaker name, with affiliation and email address > - Speaker bio (100 words or less) > - Short description (50 words or less) > - Full description including abstract and objectives (200 words or > less) > - Expertise level (beginner to advanced) > - Format and duration (trainings vs. general presentation; half-, > full- or two-day workshop, etc.) > - Intended audience and maximum number of participants (trainings only) > - Background knowledge expected of the participants (trainings only) > > > Types of Presentations > > - Trainings/Workshops > - General Sessions > - Case Studies/Industry Profiles > - Invited Keynotes/Panels/Speakers > - Corporate Showcases & Demonstrations > > BoF sessions and Fast Feather Track talks will be selected separately > > Pre Conference Trainings/Workshops > Held on the first and second day of the conference – 2008-03-23 and > 2008-03-24, Trainings require a registration fee beyond the regular > conference fee. Proposals may be submitted for half-day (3 hours), > full-day (6 hours), or two-day (12 hours) training sessions, aimed > at providing in-depth, hands-on development experience or related > continuing education. Training submissions are welcome at beginner, > intermediate, and expert levels. > > General Sessions > General Sessions include presentations on practical development > applications, insight into high-interest projects, best practices > and key advances, overcoming implementation challenges, and industry > innovations. Especially welcome are submissions that extend > participants' understanding the role of ASF projects and their > influence on the Open Source community at large. General Sessions > are scheduled for 50 minutes and are accessible to all conference delegates. > > Case Study/Industry Profile > Practitioners are invited to submit presentations that focus on how > implementing particular ASF technologies led to improved > products/solutions, service offerings, changes in work practices, > among other successes. Proposals that highlight overcoming > interesting challenges in application design and developing > innovative frameworks using multiple ASF projects are particularly > encouraged. NOTE: Marketing-oriented submissions aimed at promoting > specific organizations or products will not be accepted. > > Invited Keynotes/Panels/Speakers > Each conference the ApacheCon Planning team invites select > presenters dealing with engaging, dialectical, and challenging > subjects to present in keynote and/or panel formats. Topics include > cutting-edge technology development, industry leadership, hot or > emerging trends, opinions on controversial issues, insight on > technology paradigms, and contrasting viewpoints in complementary > professional areas. Those interested in suggesting a candidate for > an invited speaker opportunity should submit a brief proposal with > the speaker's name, affiliation, background/bio, overview of topics > of interest, and contact information. > > Important Dates > Please submit your completed proposal, at http://eu.apachecon. > com/c/aceu2009/cfp/ before Friday, 24th October, 2008 Midnight GMT. > > About ApacheCon 2009 > ApacheCon is co-produced by the Apache Software Foundation and Stone > Circle Productions. The ApacheCon Planning team comprises ASF > Members from all over the world working on a wholly-volunteer basis. > For more information, visit > http://eu.apachecon.com/c/aceu2009/

Fw: Application Period Opens for Travel Assistance to ApacheCon US 2008

2008-09-26T08:55:03Z

FYI.

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

"Gavin" <gavin@...> wrote on 09/25/2008 09:36:44 AM: > Dear PMCs, > > Please could you forward the below message to your user@ and dev@ mailing > lists, thanks in advance. > > ------------- > > The Travel Assistance Committee is taking in applications for those wanting > to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New > Orleans. > > The Travel Assistance Committee is looking for people who would like to be > able to attend ApacheCon US 2008 who need some financial support in order to > get there. There are VERY few places available and the criteria is high, > that aside applications are open to all open source developers who feel that > their attendance would benefit themselves, their project(s), the ASF and > open source in general. > > Financial assistance is available for flights, accomodation and entrance > fees either in full or in part, depending on circumstances. It is intended > that all our ApacheCon events are covered, so it may be prudent for those in > Europe and or Asia to wait until an event closer to them comes up - you are > all welcome to apply for ApacheCon US of course, but there must be > compelling reasons for you to attend an event further away that your home > location for your application to be considered above those closer to the > event location. > > More information can be found on the main Apache website at > http://www.apache.org/travel/index.html - where you will also find a link to > the application form and details for submitting. > > Time is very tight for this event, so applications are open now and will end > on the 2nd October 2008 - to give enough time for travel arrangements to be > made. > > Good luck to all those that will apply. > > Regards, > > The Travel Assistance Committee

Re: [VOTE] Add Boris to PMC

2008-08-29T13:33:39Z

Just got back from vacation. A belated +1 from me.

I've heard that in some communities the PMC = all (most?) committers. I was actually thinking of nominating Boris along with several other active committers and suggesting that we do a bit of PMC clean-up. We have a couple members that were added to the initial PMC when Xerces became a top-level project who seem to have never participated in the PMC (and are possibly not even subscribed to the project mailing lists anymore; if they are they no longer post). They've effectively never been on the PMC and I think they should be removed to reflect that unless they speak up.

Thanks.

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Gareth Reakes <gareth@...> wrote on 08/12/2008 03:17:36 AM: > Hey guys, > > Boris has been doing a lot of good work first as a contributor and, for > some time now, as a committer. I would like to propose that we ask Boris > to join the PMC to recognise this work. > > +1 > > > Gareth > > -- > Gareth Reakes, CTO WE7 > +44-20-7117-0809 http://www.we7.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: c-dev-unsubscribe@... > For additional commands, e-mail: c-dev-help@...

Re: Future of xml-commons-resolver development and maintenance

2008-08-18T11:12:42Z

/ Michael Glavassevich <mrglavas@...> was heard to say:
| I think since Norm is the author of xmlresolver.dev.java.net he could
| relicense it under the Apache license and donate it to xml-commons if he
| chooses. Would probably be a good idea to follow-up on the
| legal-discuss@... list if folks are interested in pursuing this.

I'd be happy to change the license. I'll see if I can repost the code in
the next day or two.

Be seeing you,
norm

--
Norman Walsh <ndw@...> | Time wounds all heels.
http://nwalsh.com/ |

attachment0 (191 bytes) Download Attachment

Re: Future of xml-commons-resolver development and maintenance

2008-08-15T20:45:02Z

Hi Earl,

GPL is a non-starter here. You cannot include code under this license in any Apache project. Be very careful if you're taking a look at GPL code and contributing to similar Apache projects (so as not to indavertently contaminate the codebase). I personally avoid looking at it altogether.

I think since Norm is the author of xmlresolver.dev.java.net he could relicense it under the Apache license and donate it to xml-commons if he chooses. Would probably be a good idea to follow-up on the legal-discuss@apache.org list if folks are interested in pursuing this.

Thanks.

Earl Hood wrote:

On August 14, 2008 at 13:40, Norman Walsh wrote:

> I'm unlikely to have a lot of time to work on it, so I think it's
> reasonable to transition the maintenance over to others.

Thanks for responding.

It does seem that some action on commons-resolver is occuring,
with those having commit access starting to incorporate patches
that have been submitted. I've submiited a signed license
document so ASF can include the patches I have posted.

> In the meantime, I did rewrite it a while back, see
> xmlresolver.dev.java.net.

I'll try to take a look at it when I get time.

> My motivations for the rewrite were at least three-fold:
>
> 1. The design of the current code base really isn't all that good. I
> didn't know all that much Java when I started and I think some of
> my choices were poor ones. (Some of my new choices may be poor too,
> of course :-).

I think we all can look at code we have written in the past and
realized things could have been done better :)

It seems the features you have added into your newer project could
be added into commons-resolver if there is enough demand for such
features.

One thing that may be a problem with your rewrite is the license you
have for it: GPL. I personally have no problems with the GPL, but the
license may be prohibitive for some. This could prevent any potential
transition to a newer resolver implementation for some projects.

Good luck with your new job,

--ewh
--
Earl Hood, <earl@earlhood.com>
Web: <http://www.earlhood.com/>
PGP Public Key: <http://www.earlhood.com/gpgpubkey.txt>

Re: Future of xml-commons-resolver development and maintenance

2008-08-14T13:02:21Z

On August 14, 2008 at 13:40, Norman Walsh wrote:

> I'm unlikely to have a lot of time to work on it, so I think it's
> reasonable to transition the maintenance over to others.

Thanks for responding.

It does seem that some action on commons-resolver is occuring,
with those having commit access starting to incorporate patches
that have been submitted. I've submiited a signed license
document so ASF can include the patches I have posted.

> In the meantime, I did rewrite it a while back, see
> xmlresolver.dev.java.net.

I'll try to take a look at it when I get time.

> My motivations for the rewrite were at least three-fold:
>
> 1. The design of the current code base really isn't all that good. I
> didn't know all that much Java when I started and I think some of
> my choices were poor ones. (Some of my new choices may be poor too,
> of course :-).

I think we all can look at code we have written in the past and
realized things could have been done better :)

It seems the features you have added into your newer project could
be added into commons-resolver if there is enough demand for such
features.

One thing that may be a problem with your rewrite is the license you
have for it: GPL. I personally have no problems with the GPL, but the
license may be prohibitive for some. This could prevent any potential
transition to a newer resolver implementation for some projects.

Good luck with your new job,

--ewh
--
Earl Hood, <earl@...>
Web: <http://www.earlhood.com/>
PGP Public Key: <http://www.earlhood.com/gpgpubkey.txt>

Re: Future of xml-commons-resolver development and maintenance

2008-08-14T10:40:59Z

/ "Earl Hood" <earl@...> was heard to say:
| If you no longer have the time and resources to work on the
| resolver, are you open to transitioning maintenance to others
| whom have cycles to spare?

Sorry, I didn't mean to leave this unanswered for so long. Getting
ramped up in my new job has consumed most of my bandwidth for a couple
of months.

I'm unlikely to have a lot of time to work on it, so I think it's
reasonable to transition the maintenance over to others.

In the meantime, I did rewrite it a while back, see xmlresolver.dev.java.net.

I've been running the new code for months without issues, but it's
probably still not as well tested as the code in the Apache Commons
project.

My motivations for the rewrite were at least three-fold:

1. The design of the current code base really isn't all that good. I
didn't know all that much Java when I started and I think some of
my choices were poor ones. (Some of my new choices may be poor too,
of course :-).

2. I wanted to support the idea of an automatic local cache, so that
users don't have to manually build catalog files.

3. I wanted to try to support RDDL.

I'm not sure how (or if) that rewrite should be factored into a transition
plan, but I thought I should mention it.

Be seeing you,
norm

--
Norman Walsh <ndw@...> | DNA neither cares nor knows. DNA just
http://nwalsh.com/ | is. And we dance to its music.--Richard
| Dawkins

attachment0 (191 bytes) Download Attachment

August Board Report

2008-08-06T20:11:59Z

Hey all,

It's board report time again. Not sure when we need this in by but I'm going to be away for two weeks so will post the updates for Xerces-J and XML Commons on the Wiki here (http://wiki.apache.org/xerces/August2008) before I go.

Could other committers please fill in the status for Xerces-C and Xerces-P.

Thanks.

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

DO NOT REPLY [Bug 45569] New: Eliminate need for user.dir grant when not using relative-catalogs

2008-08-05T15:02:55Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45569

Summary: Eliminate need for user.dir grant when not using
relative-catalogs
Product: XmlCommons
Version: 1.x
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: Resolver
AssignedTo: commons-dev@...
ReportedBy: ecapachedev@...

When the CatalogManager configuration of relative-catalogs is false, the
catalog paths will be absolute. When parsing the catalogs in
Catalog.parseCatalogFile, the first thing that occurs is creating a URL of the
current working directory, which requires a grant to the "user.dir"
PropertyPermission. Creating this URL is unnecessary when an absolute path to
the catalog is passed in and the grant would also be unnecessary.

To alleviate this condition, a URL can be attempted to be made from the
fileName first and if a MalformedURLException occurs, treat it as a relative
path. In essence:

try {
base = new URL(fixSlashes(fileName));
} catch (MalformedURLException mue) {
...
}

Alternatively, there can be a mode set or passed in to treat the fileName
appropriately.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 37998] org.apache.xerces.validators.common.Grammar. buildSyntaxTree

2008-07-28T05:56:06Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=37998

Mark Thomas <markt@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|DUPLICATE |INVALID

--- Comment #2 from Mark Thomas <markt@...> 2008-07-28 05:56:05 PST ---
Changed resolution to INVALID since duplicate bug has been deleted from
Bugzilla and leaving as DUPLICATE creates referential integrity issues for the
underlying database.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45210] Base systemId not set when parsing XML catalogs

2008-07-18T02:44:28Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210

--- Comment #4 from David Crossley <crossley@...> 2008-07-18 02:44:27 PST ---
I have not tried the patch yet, and now away for another week.

When you talked about relative references, i thought that you were referring to
entries within the catalog. See one of our examples at:
[1]
http://svn.apache.org/repos/asf/forrest/trunk/main/webapp/resources/schema/catalog.forrest.xcat
The "uri" attributes of the "public" elements do get resolved relative to the
catalog.forrest.xcat file.

Anyway, now i see that you mean the DTD for the catalog itself.

By the way, i think that i am still a bit confused by that "relative-catalogs"
property and will attempt again to understand the docs.

Note that we use a PublicIdentifier for our catalogs (e.g. [1] above). IIRC the
Resolver handles this internally when we do it that way. We don't need the
catalog.dtd to be present, and it doesn't bang on the net to try to get it from
that SystemIdentifier URL.

I will still investigate your patch and do some testing.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: Support for URL values for property "catalogs" in CatalogManager.properties

2008-06-27T15:32:15Z

Just thought I'd mention that it should already be possible to do this programmatically. The Catalog class has a parseCatalog(URL) method [1].

Thanks.

[1] http://xml.apache.org/commons/components/apidocs/resolver/org/apache/xml/resolver/Catalog.html#parseCatalog(java.net.URL)

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Charles Dylan Shearer <dshearer@...> wrote on 06/21/2008 09:32:43 AM: > Currently, Resolver allows developers to use paths as values for the > property "catalogs" in CatalogManager.properties. I was wondering how > you all felt about adding support for URLs in this property, so that > users could specify exactly how catalogs are to be located: for > example, "classpath:/com/package/catalog.xml" for catalogs on the > classpath or "file:///directory/catalog.xml" for catalogs on the > filesystem. > > I couldn't tell exactly from the documentation, but it seems that > Resolver currently interprets these paths as referring to the > filesystem. > > What does everyone think? > > Dylan

DO NOT REPLY [Bug 45210] Base systemId not set when parsing XML catalogs

2008-06-26T07:51:06Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210

Earl Hood <earl@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |earl@...

--- Comment #3 from Earl Hood <earl@...> 2008-06-26 07:51:05 PST ---
Are you stating the patch breaks some existing behavior?
This fixes a problem with the actual parsing of catalog
files via the SAX parser.

In the project I'm working on, the resolver errors out
on XML catalog files that have doctype declarations. For example:

<!DOCTYPE catalog SYSTEM "../../../dtd/catalog.dtd>
<catalog>...

The problem is the resolver does not set the initial base
URI when calling SAX. Therefore, the *SAX parser* will
resolve all (XML) entities with a base URI of the current working
directory, and NOT the location of the catalog file.

Therefore, in the above, the URI "../../../dtd/catalog.dtd"
will be looked up by the SAX parser based on the current
working directory. But, the URI should be resolved based
on the location of the catalog file.

The patch basically sets the systemId setting when SAX is
invoked when parsing the file so any relative URI *entity*
references in the catalog itself will be resolved against
the correct base.

None of this affects how catalog paths are resolved via
things like <nextCatalog> entries since that is an
application-specific processing task and not something the
SAX parser resolves itself.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 44263] The XML resolver generates invalid file scheme URLs

2008-06-25T01:57:12Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=44263

David Crossley <crossley@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE

--- Comment #1 from David Crossley <crossley@...> 2008-06-25 01:57:12 PST ---
This issue sounds like it might be a duplicate of #28719

*** This bug has been marked as a duplicate of bug 28719 ***

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 28719] Resolver generates an incorrect base URL when user .dir is "/"

2008-06-25T01:57:12Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=28719

David Crossley <crossley@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |kristian.spangsege@...

--- Comment #6 from David Crossley <crossley@...> 2008-06-25 01:57:12 PST ---
*** Bug 44263 has been marked as a duplicate of this bug. ***

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45210] Base systemId not set when parsing XML catalogs

2008-06-25T01:23:20Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210

David Crossley <crossley@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |

--- Comment #2 from David Crossley <crossley@...> 2008-06-25 01:23:20 PST ---
(Woops, accidently closed this when Bz skipped to the next issue.)

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45209] xml.catalog. verbosity has not effect when CatalogManager.properties not used

2008-06-25T01:20:37Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45209

David Crossley <crossley@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45209] xml.catalog. verbosity has not effect when CatalogManager.properties not used

2008-06-25T01:19:57Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45209

David Crossley <crossley@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45210] Base systemId not set when parsing XML catalogs

2008-06-25T01:18:46Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210

David Crossley <crossley@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45209] xml.catalog. verbosity has not effect when CatalogManager.properties not used

2008-06-25T01:17:45Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45209

David Crossley <crossley@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|crossley@... |commons-dev@...

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45209] xml.catalog. verbosity has not effect when CatalogManager.properties not used

2008-06-25T00:14:12Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45209

David Crossley <crossley@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|commons-dev@... |crossley@...

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45210] Base systemId not set when parsing XML catalogs

2008-06-24T22:07:23Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45210

--- Comment #1 from David Crossley <crossley@...> 2008-06-24 22:07:23 PST ---
Have you considered the effect of the "relative-catalogs" property?
http://xml.apache.org/commons/components/resolver/tips.html
http://xml.apache.org/commons/components/resolver/resolver-article.html

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: Future of xml-commons-resolver development and maintenance

2008-06-24T17:53:32Z

Michael Glavassevich wrote:

> Earl Hood wrote:
> >
> > The revision number is bogus since it is based on the svn revision
> > of the repo I imported that 1.2 source release.
> >
> > The diffs are against the released 1.2 source. If required,
> > I can see if the diffs need to be redone against the trunk,
> > assuming there are changes in the trunk from 1.2.
>
> No changes have been made to the resolver code since the 1.2 release.

Thanks for clarifying. The diffs that i have tried are okay.
I will comment via BugZilla if needed.

-David

Re: Future of xml-commons-resolver development and maintenance

2008-06-24T17:10:32Z

No changes have been made to the resolver code since the 1.2 release.

Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrglavas@...
E-mail: mrglavas@...

Earl Hood <earl@...> wrote on 06/24/2008 08:00:47 PM: > The revision number is bogus since it is based on the svn revision > of the repo I imported that 1.2 source release. > > The diffs are against the released 1.2 source. If required, > I can see if the diffs need to be redone against the trunk, > assuming there are changes in the trunk from 1.2. > > --ewh

Re: Future of xml-commons-resolver development and maintenance

2008-06-24T17:00:47Z

On June 24, 2008 at 16:24, David Crossley wrote:

> Earl, while reviewing some of your patches, i see that you
> appear to be using an old version of xml-commons. Your diffs
> say "revision 2813", yet the current revision (last change from
> mrglavas) is 669794.

The revision number is bogus since it is based on the svn revision
of the repo I imported that 1.2 source release.

The diffs are against the released 1.2 source. If required,
I can see if the diffs need to be redone against the trunk,
assuming there are changes in the trunk from 1.2.

--ewh

Re: Future of xml-commons-resolver development and maintenance

2008-06-23T23:24:31Z

Earl, while reviewing some of your patches, i see that you
appear to be using an old version of xml-commons. Your diffs
say "revision 2813", yet the current revision (last change from
mrglavas) is 669794.

See the "Where can I get the source code?" section at
http://xml.apache.org/commons/
i.e.
http://svn.apache.org/repos/asf/xml/commons/trunk/

-David

DO NOT REPLY [Bug 45240] Deprecated SAX API Used by SAXCatalogReader and SAXCatalogParser

2008-06-21T06:34:53Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45240

Dylan Shearer <dshearer@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Support for URL values for property "catalogs" in CatalogManager.properties

2008-06-21T06:32:43Z

Currently, Resolver allows developers to use paths as values for the
property "catalogs" in CatalogManager.properties. I was wondering how
you all felt about adding support for URLs in this property, so that
users could specify exactly how catalogs are to be located: for
example, "classpath:/com/package/catalog.xml" for catalogs on the
classpath or "file:///directory/catalog.xml" for catalogs on the
filesystem.

I couldn't tell exactly from the documentation, but it seems that
Resolver currently interprets these paths as referring to the
filesystem.

What does everyone think?

Dylan

DO NOT REPLY [Bug 45240] Deprecated SAX API Used by SAXCatalogReader and SAXCatalogParser

2008-06-19T20:51:08Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45240

--- Comment #6 from Michael Glavassevich <mrglavas@...> 2008-06-19 20:51:08 PST ---
They're a documented part of the API:
http://xml.apache.org/commons/components/apidocs/resolver/index.html. Users of
the resolver might be using these classes. In fact Xerces uses
SAXCatalogReader directly.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45240] Deprecated SAX API Used by SAXCatalogReader and SAXCatalogParser

2008-06-19T20:41:32Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45240

--- Comment #5 from Dylan Shearer <dshearer@...> 2008-06-19 20:41:32 PST ---
(In reply to comment #4)
> Yes SAX1 is deprecated, but the proposed patch makes backwards incompatible
> changes to the API. Deleting methods and interfaces from an API which has
> shipped is generally a bad thing to do. There are lots of methods, classes and
> interfaces in the Java platform that are deprecated and none of them can be
> deleted because it might break some existing application. Not in favour of
> changes which might break the existing user base.
>

Aren't SAXCatalogReader and SAXCatalogParser internal classes?

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45240] Deprecated SAX API Used by SAXCatalogReader and SAXCatalogParser

2008-06-19T20:21:48Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45240

--- Comment #4 from Michael Glavassevich <mrglavas@...> 2008-06-19 20:21:48 PST ---
Yes SAX1 is deprecated, but the proposed patch makes backwards incompatible
changes to the API. Deleting methods and interfaces from an API which has
shipped is generally a bad thing to do. There are lots of methods, classes and
interfaces in the Java platform that are deprecated and none of them can be
deleted because it might break some existing application. Not in favour of
changes which might break the existing user base.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45240] Deprecated SAX API Used by SAXCatalogReader and SAXCatalogParser

2008-06-19T19:57:37Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45240

Dylan Shearer <dshearer@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #22148|0 |1
is obsolete| |

--- Comment #3 from Dylan Shearer <dshearer@...> 2008-06-19 19:57:36 PST ---
Created an attachment (id=22149)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22149)
Patch without formatting changes (fixed).

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45240] Deprecated SAX API Used by SAXCatalogReader and SAXCatalogParser

2008-06-19T19:52:22Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45240

Dylan Shearer <dshearer@...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #22147|0 |1
is obsolete| |

--- Comment #2 from Dylan Shearer <dshearer@...> 2008-06-19 19:52:22 PST ---
Created an attachment (id=22148)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22148)
Patch without formatting changes.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45240] Deprecated SAX API Used by SAXCatalogReader and SAXCatalogParser

2008-06-19T18:58:41Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45240

--- Comment #1 from David Crossley <crossley@...> 2008-06-19 18:58:41 PST ---
Thanks. However could you please provide a new patch. Whatever text editor you
are using has made many text-formatting changes. Please only change the
necessary lines.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 45240] New: Deprecated SAX API Used by SAXCatalogReader and SAXCatalogParser

2008-06-19T17:32:15Z

https://issues.apache.org/bugzilla/show_bug.cgi?id=45240

Summary: Deprecated SAX API Used by SAXCatalogReader and
SAXCatalogParser
Product: XmlCommons
Version: 1.x
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P3
Component: Resolver
AssignedTo: commons-dev@...
ReportedBy: dshearer@...

Created an attachment (id=22147)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22147)
Patches for both SAXCatalogReader and SAXCatalogParser in one file.

SAXCatalogReader and SAXCatalogParser use these deprecated SAX classes:
org.xml.sax.DocumentHandler, org.xml.sax.Parser, and org.xml.sax.AttributeList.

--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.