The existing development mailing lists for Jakarta subprojects (BCEL, BSF, Cactus, ECS, JCS, JMeter, ORO, Regexp and retired subproject Slide) are merging. Two new lists will be soon be created, one for development discussions and another for notifications (such as SVN, Bugzilla, JIRA, Gump). Subscribers to any of the existing development lists mentioned above (also see CC header of this message) will be subscribed to the two new lists automatically. The existing lists that appear in the CC header of this message will subsequently be closed, with appropriate forwards in place to point to the merged list. The shared development discussions mailing list will use the convention of identifying the subproject associated with the posting in the email subject using square brackets. For example, a recent email sent to the jmeter-dev list had the subject: Exposing run info with JMX Once the shared mailing list is set up, the convention would be to use the following email subject instead: [JMeter] Exposing run info with JMX As a reminder, unsubscribing from a mailing list called list@jakarta.apache.org can be done by sending an email to list-unsubscribe@jakarta.apache.org (replace "list" with actual name of the mailing list to unsubscribe from). -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
[Relaying result to all lists] The vote to merge dev lists at Jakarta has passed with the following binding votes cast: 5 +1s: Felipe Leme Daniel Savarese Vadim Gritsenko Rahul Akolkar Stephen Colebourne 2 +0s: Sebastian Bazley Rony Flatscher 2 -1s: Thomas Vandahl Torsten Curdt I also count 4 non-binding +1s (Mark Murphy, Venkat Krishnamurthy, Henri Yandell, Jörg Schaible) and 3 non-binding -1s (Hanson Char, Giuseppe, Tim Cronin). Two non-binding +1s were cast by folks who until recently were on the PMC (bayard, joehni) so perhaps not giving their votes enough credit is getting too technical here. We'll encourage simple conventions (as Commons was mentioned, for example) to make filtering email, searching archives etc. as convenient as we can on a shared list. Hope is that will alleviate to some extent the primary concern of those who've voted against. I will open an INFRA ticket for this merge in a week or so (after I post another heads up note with more details, dev mailing list conventions etc. to the lists). Thanks to everyone who voted. -Rahul On Mon, Oct 19, 2009 at 4:02 PM, Rahul Akolkar <rahul.akolkar@gmail.com> wrote: > [Suggestion is to please reply to the general@jakarta list only] > > This is a vote to consolidate the development lists at Jakarta into > one development and one notifications list. For background including > timing, anticipated benefits and some discussion, see proposal [1] > thread. > > [ ] +1 > [ ] -1 > > While not required, it'd be nice if anyone voting against could > briefly state the reason(s). And you're ofcourse welcome to vote +/-0 > if you really want. > > Vote will run atleast 72 hours and will close no sooner than Thursday 5 pm EST. > > TIA. > -Rahul > > [1] (long, possibly fragmented URL below) > http://mail-archives.apache.org/mod_mbox/jakarta-general/200910.mbox/%3cce1f2ea80910091443t5cad1db0na0663c416cb83a72@mail.gmail.com%3e > --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
[Suggestion is to please reply to the general@jakarta list only] This is a vote to consolidate the development lists at Jakarta into one development and one notifications list. For background including timing, anticipated benefits and some discussion, see proposal [1] thread. [ ] +1 [ ] -1 While not required, it'd be nice if anyone voting against could briefly state the reason(s). And you're ofcourse welcome to vote +/-0 if you really want. Vote will run atleast 72 hours and will close no sooner than Thursday 5 pm EST. TIA. -Rahul [1] (long, possibly fragmented URL below) http://mail-archives.apache.org/mod_mbox/jakarta-general/200910.mbox/%3cce1f2ea80910091443t5cad1db0na0663c416cb83a72@mail.gmail.com%3e --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
[Out of necessity, this is heavily cross-posted. Suggestion is to send any replies to the general@jakarta list only to keep any discussion in one place.] We currently have 8 active development lists at Jakarta, each devoted to a subproject. I've been subscribed to all for a while and based on my observations and the overall benefits of doing so, I think its time to consolidate them into a single development list at Jakarta. Motivations (not in any order): * Flattens and simplifies oversight - Not much else to be said on that. * Communication - Subprojects can often have various touch points. So, Rony's surprise today at the BSF taglib being retired is one example. Lets have all dev discussions on one list. * Cross-pollination - Most subprojects are at the point where it certainly wouldn't hurt to have the active folks from all of Jakarta around for dev discussions, votes etc. * Manageable overhead - More on this later, but we have a number of usual suspects showing up on many of the dev lists, they'd barely notice a difference. Others can manage, IMO/hopefully. Operationally: * The combined list traffic will obviously be more than any one of the separate lists. However, development tends to be in spurts on these lists and the probabilistic chances of more than a couple of subproject spurts happening at the same time seems quite low. Overall, combined traffic is not at all overpowering IMO. * The proposal will include closing current dev lists and adding all subscribers to the one new dev list. We'll post a heads up on these lists before that. Throw in site-cvs@ as well for good measure. * We could repurpose general@ as the one dev list, but OTOH, seems worthwhile to maintain the dev / general separation. * No changes proposed to the user lists. Thoughts? Lets say a little over a week (10 days, which should give us two weekends) for initial feedback and opinions please. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
https://issues.apache.org/bugzilla/show_bug.cgi?id=35842
Daniel F. Savarese <dfs@apache.org> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
https://issues.apache.org/bugzilla/show_bug.cgi?id=37909
Daniel F. Savarese <dfs@apache.org> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
https://issues.apache.org/bugzilla/show_bug.cgi?id=45461
Daniel F. Savarese <dfs@apache.org> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
https://issues.apache.org/bugzilla/show_bug.cgi?id=47876
Daniel F. Savarese <dfs@apache.org> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
https://issues.apache.org/bugzilla/show_bug.cgi?id=47876
Daniel F. Savarese <dfs@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Daniel F. Savarese <dfs@apache.org> 2009-09-19 17:36:20 PDT ---
To obtain the behavior you desire call Perl5Matcher.setMultiline with an
argument of true prior to performing your matches. If you don't know how to
use the software, please post a question to the oro-user mailing list first
before opening a bug report.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
https://issues.apache.org/bugzilla/show_bug.cgi?id=47876
Summary: Glob Expression
Product: ORO
Version: Unknown
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Main
AssignedTo: oro-dev@jakarta.apache.org
ReportedBy: amar.hussain@mail.com
Using the Demonstration Applet http://jakarta.apache.org/oro/demo.html
If you:
1: choose Glob Expression
2: Then in the first text area exter text "input*"
3: choose contains()
4: Then in the Search Input text area exter text:
someAAAinput
someBBBinput
The search results is:
Compiling regular expression.
Searching
Match 1: input
Match 2: input
The input contained 2 matches.
This seems like a bug to me.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
In message <OFF80590E8.E7B74BCC-ON42257599.003E8C97-42257599.00517BB1@rmb.co.za >, Neil Crow writes: >I would like to be able to locate the jakarta-oro in the central maven2 >repository location categorized alongside the many other Apache artifacts. >http://repo1.maven.org/maven2/org/apache/ > >If the oro team agree to this, then I can assist with porting to a maven-2 >project structure. I have not kept current with maven, so if you're already an Apache committer the easiest thing to do is for me to ask the PMC to vote to grant you commit access to oro to make the necessary changes. If you're not already an Apache committer, then if you submit a patch (probably should open a bugzilla issue for this and attach the patch to the issue; unfortunately, oro never migrated to JIRA) I can apply it. The only problem is that there are changes on the trunk that should probably have been made in a separate 2.1 branch. If you want to move forward with this, I can move the trunk to a 2.1 branch and rebase the trunk against oro-2.0.8 plus the non-experimental 2.1 changes (i.e., addition of Apache License 2.0 headers and Perl5Util returning thread-local results) and you can make the maven-2 changes against the new trunk. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
Hi, I have a project that is built using maven, and I have been struggling to find the jakarta-oro artifacts on a public maven repository. The best hit that I get is a once-off for version 2.0.8 hosted on a jboss repository. [http://repository.jboss.com/maven2/apache-oro/jakarta-oro/] I found this link in the archives [http://mail-archives.apache.org/mod_mbox/jakarta-oro-dev/200304.mbox/<1051063328.7959.81.camel@appserv>] where Bert, had made a maven project, however I never found any follow-up to that posting. This may have been done using maven-1, which for all intensive purposes is now deprecated. I would like to be able to locate the jakarta-oro in the central maven2 repository location categorized alongside the many other Apache artifacts. http://repo1.maven.org/maven2/org/apache/ If the oro team agree to this, then I can assist with porting to a maven-2 project structure. Regards, Neil Crow. This e-mail is subject to a disclaimer, available at http://www.rmb.co.za/web/elements.nsf/online/disclaimer-communications.html --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
https://issues.apache.org/bugzilla/show_bug.cgi?id=45461
Daniel F. Savarese <dfs@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Daniel F. Savarese <dfs@apache.org> 2008-07-22 12:39:48 PST ---
This is not a bug and is the intended behavior. GlobCompiler is not meant to
be an implementation of glob(3). The API docs explain the intended behavior
(http://jakarta.apache.org/oro/api/org/apache/oro/text/GlobCompiler.html):
* - Matches zero or more instances of any character. If the
STAR_CANNOT_MATCH_NULL_MASK option is used, * matches one or more
instances of any character.
glob(3) concerns itself with matching file system path names within the context
of shell filename expansion. Many applications use glob-style expressions
outside of the file system path name context and expect * to match any
character. Even a file system-oriented program such as find (at least the GNU
implementation) does not conform to glob(3)/glob(7). For example, find -path
"*" will match all intervening slashes.
If you intend to use GlobCompiler and require the ability to not match slashes,
we can add a STAR_CANNOT_MATCH_SLASH_MASK option. However, it would be more
efficient to discuss this on the mailing list. In general, it is more
effective to raise and discuss questions on the mailing list first and open
issues only after it's been confirmed that there is indeed an issue that
requires opening. If it is agreed that STAR_CANNOT_MATCH_SLASH_MASK is the way
to go, then an improvement/new feature issue can be opened.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
https://issues.apache.org/bugzilla/show_bug.cgi?id=45461
Summary: GlobCompiler: * should not match the path separator '/'
Product: ORO
Version: 2.0.8
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Main
AssignedTo: oro-dev@jakarta.apache.org
ReportedBy: eric.sirianni@gmail.com
import org.apache.oro.text.GlobCompiler;
import org.apache.oro.text.regex.MalformedPatternException;
import org.apache.oro.text.regex.Pattern;
import org.apache.oro.text.regex.Perl5Matcher;
public class Main {
public static void main(String[] args) throws MalformedPatternException {
GlobCompiler globCompiler = new GlobCompiler();
Pattern pattern = globCompiler.compile("*.c");
Perl5Matcher perl5Matcher = new Perl5Matcher();
System.out.println(perl5Matcher.matches("foo.c", pattern));
System.out.println(perl5Matcher.matches("subdir/bar.c", pattern));
}
}
$ java -cp ... Main
true
true
Expected behavior is:
true
false
The glob man page states:
Pathnames
Globbing is applied on each of the components of a pathname separately. A '/'
in a pathname cannot be matched by a '?' or '*' wildcard, or by a range like
'[.-0]'. A range cannot contain an explicit '/' character; this would lead to a
syntax error.
If a filename starts with a '.', this character must be matched explicitly.
(Thus, 'rm *' will not remove .profile, and 'tar c *' will not archive all your
files; 'tar c .' is better.)
Writing a simple C program that uses glob confirms this:
$ cat testglob.c
#include <glob.h>
main(int argc, char *argv[]) {
glob_t globbuf;
globbuf.gl_offs = 2;
glob("*.c", GLOB_DOOFFS, 0, &globbuf);
globbuf.gl_pathv[0] = "ls";
globbuf.gl_pathv[1] = "-l";
execvp("ls", &globbuf.gl_pathv[0]);
}
$ find
.
./subdir
./subdir/bar.c
./testglob.c
./a.out
$ ./a.out
-rw-rw-r-- 1 sirianni engr 236 2008-07-22 13:36 testglob.c
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at general@gump.apache.org.
Project jakarta-oro has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Configuration Failed'.
For reference only, the following projects are affected by this:
- jakarta-oro : Java Regular Expression package
Full details are available at:
http://vmgump.apache.org/gump/public/jakarta-oro/jakarta-oro/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were provided:
-INFO- Failed with reason configuration failed
-ERROR- Bad Dependency. Project: xml-apis : unknown to *this* workspace
-DEBUG- Extracted fallback artifacts from Gump Repository
To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/jakarta-oro/jakarta-oro/rss.xml
- Atom: http://vmgump.apache.org/gump/public/jakarta-oro/jakarta-oro/atom.xml
============================== Gump Tracking Only ===
Produced by Gump version 2.3.
Gump Run 21001618062008, vmgump:vmgump-public:21001618062008
Gump E-mail Identifier (unique within run) #15.
--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at general@gump.apache.org.
Project jakarta-oro has an issue affecting its community integration.
This issue affects 3 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-net : Commons Net
- jakarta-oro : Java Regular Expression package
- xstream : simple library to serialize object to XML and back
again
Full details are available at:
http://vmgump.apache.org/gump/public/jakarta-oro/jakarta-oro/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were provided:
-INFO- Failed with reason build failed
-DEBUG- Extracted fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-oro/jakarta-oro/gump_work/build_jakarta-oro_jakarta-oro.html
Work Name: build_jakarta-oro_jakarta-oro (Type: Build)
Work ended in a state of : Failed
Elapsed:
Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only
-Dversion=05022008 -f build.xml jar
[Working Directory: /srv/gump/public/workspace/jakarta-oro]
CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:ant-jmf-gump-05022008.jar:ant-swing-gump-05022008.jar:ant-apache-resolver-gump-05022008.jar:ant-trax-gump-05022008.jar:ant-junit-gump-05022008.jar:ant-launcher-gump-05022008.jar:ant-nodeps-gump-05022008.jar:ant-gump-05022008.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar
---------------------------------------------
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/Main
---------------------------------------------
To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/jakarta-oro/jakarta-oro/rss.xml
- Atom: http://vmgump.apache.org/gump/public/jakarta-oro/jakarta-oro/atom.xml
============================== Gump Tracking Only ===
Produced by Gump version 2.3.
Gump Run 40001605022008, vmgump:vmgump-public:40001605022008
Gump E-mail Identifier (unique within run) #10.
--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
In message <FCD1D758047E304782306A6CF0D3D80508C98997@BLR-EC-MBX05.wipro.com>, v ijendra.bhagwath@wipro.com writes: >Is jakarta-oro-2.0.8.jar compatible with WebSphere 6.0? You need to provide more information than that. What do you mean by "compatible"? What problem are you experiencing? More than likely, any problems you are having are because WebSphere already includes another version of oro that it uses internally and your application is loading that version. Most Java application servers shipped some version of oro in the past and occasionally, people have run into conflicts. For example, see the following URL: http://jamonapi.sourceforge.net/WebSphereOro.html Search the mail archives, do a Web search on WebSphere+oro, contact IBM support for more information. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
Is jakarta-oro-2.0.8.jar compatible with WebSphere 6.0? The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
Hmm better send this to poi-user@jakarta.apache.org, don't think you will get a valuable response
on
the oro list..
Mvgr,
Martin
Mingfan.Lu wrote:
> When I use the POI-HLSF to extract the text from the slides.
> My code is very easy:
> PowerPointExtractor ppe = new PowerPointExtractor("c:\\4.ppt");
> String s = ppe.getText(true,true);
> System.out.println(s);
> ppe.close();
>
> But there is a error:
> java.lang.ClassCastException: org.apache.poi.hslf.record.Slide cannot be
> cast to org.apache.poi.hslf.record.MainMaster
> I trace the bug, I find that:
> For the ppt which has more than 2(include 2) MainMasters, the SlideShow
> Constructor could not correctly to get MasterRecords:
>
>
> SlideListWithText masterSLWT =
> _documentRecord.getMasterSlideListWithText();
> SlideListWithText slidesSLWT = _documentRecord.getSlideSlideListWithText();
> SlideListWithText notesSLWT = _documentRecord.getNotesSlideListWithText();
>
> //find master slides
> SlideAtomsSet[] masterSets = new SlideAtomsSet[0];
> org.apache.poi.hslf.record.MainMaster[] masterRecords = null;
> if (masterSLWT != null){
>
> masterSets = masterSLWT.getSlideAtomsSets();
> masterRecords = new org.apache.poi.hslf.record.MainMaster[
> masterSets.length];
> for(int i=0; i<masterRecords.length; i++) {
> masterRecords[i] = (org.apache.poi.hslf.record.MainMaster
> )getCoreRecordForSAS(masterSets[i]);
> }
> }
>
> Eg. The masterSets.length =2, but there is only 1 master records in the
> MostRecentCoreRecords, so the there will be a casting error.
>
> And I also find that the test data given in the Src dir, all ppt file are
> simple, all of them have only 1 master slide,
>
> Did anyone test the ones which have more than 2 master slides?
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
When I use the POI-HLSF to extract the text from the slides.
My code is very easy:
PowerPointExtractor ppe = new PowerPointExtractor("c:\\4.ppt");
String s = ppe.getText(true,true);
System.out.println(s);
ppe.close();
But there is a error:
java.lang.ClassCastException: org.apache.poi.hslf.record.Slide cannot be
cast to org.apache.poi.hslf.record.MainMaster
I trace the bug, I find that:
For the ppt which has more than 2(include 2) MainMasters, the SlideShow
Constructor could not correctly to get MasterRecords:
SlideListWithText masterSLWT =
_documentRecord.getMasterSlideListWithText();
SlideListWithText slidesSLWT = _documentRecord.getSlideSlideListWithText();
SlideListWithText notesSLWT = _documentRecord.getNotesSlideListWithText();
//find master slides
SlideAtomsSet[] masterSets = new SlideAtomsSet[0];
org.apache.poi.hslf.record.MainMaster[] masterRecords = null;
if (masterSLWT != null){
masterSets = masterSLWT.getSlideAtomsSets();
masterRecords = new org.apache.poi.hslf.record.MainMaster[
masterSets.length];
for(int i=0; i<masterRecords.length; i++) {
masterRecords[i] = (org.apache.poi.hslf.record.MainMaster
)getCoreRecordForSAS(masterSets[i]);
}
}
Eg. The masterSets.length =2, but there is only 1 master records in the
MostRecentCoreRecords, so the there will be a casting error.
And I also find that the test data given in the Src dir, all ppt file are
simple, all of them have only 1 master slide,
Did anyone test the ones which have more than 2 master slides?
--
With respects,
Mingfan.Lu
In message <BA256842F04A9348A1D46EDDCC55BBA605773C0D@exch1-srv.cajval.sba.com.a >Why MalformedPatternException doesn't extend from RuntimeException? So that malformed dynamically generated regular expressions--such as those entered by an application user or read from a file--that are passed along to a pattern compiler--don't crash your application. In such an instance, a malformed expression is a non-fatal recoverable error. If you're using only hard-coded statically defined patterns, then this won't be apparent immediately. There is great disagreement about the utility of checked exceptions, likely fueled by their profligate presence in the Java core APIs. I do not wish to rekindle that debate. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
Hello, Why MalformedPatternException doesn't extend from RuntimeException? Rodrigo. *** ADVERTENCIA *** - El contenido del presente mensaje y los archivos adjuntos que pudiera contener son privados, estrictamente confidenciales y exclusivos para su destinatario, pudiendo contener informacion protegida por normas legales y de secreto profesional. Bajo ninguna circunstancia su contenido puede ser transmitido o revelado a terceros ni divulgado en forma alguna. En consecuencia de haberlo recibido por error, rogamos contactar al remitente y eliminarlo de su sistema. No nos responsabilizamos por la integridad y la seguridad de este mensaje, ya que el mismo podría estar sujeto a manipulaciones ilegales de informacion. *** WARNING *** - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed and it may be subject to unauthorized amendment, for which we accept no liability.
At 2:58 PM -0400 4/11/06, Daniel F. Savarese wrote: >In message <p0623093cc05974e4a6fb@[10.0.1.2]>, "Mark F. Murphy" writes: >>However, for some difficult regex's, there might need to be some >>support methods in order to make them readily usable. > >Well, I suggest that if you have the motivation, cook something up and >submit it. Adding a collection of useful regular expressions/parsing >functions with support classes for common tasks may breathe some new >life into the project. I don't think it would conflict with anything >already going on in Commons. Also, it's been suggested to move >Commons Lang out of Commons and to move ORO into Commons Lang. The >addition you've suggested seems like a good fit either way. OK. I have a CSVIterator class I just wrote which used the my csv regex. It basically takes a single line string in the constructor and allows one to get the next field as needed. There's also a helper method to simply convert the iterator into a List: List csvList = new CSVIterator(line).toList(); All we need to do is figure out how we'd like to package this stuff. Should we have a different package name for the bundle? What should it be called? Should we do a peer review process first? Etc. Also, I've got my RFC822 matcher which I could dust off and make useful. I'd have to figure out the best way to utilize it in a helper class. Lastly, it might be nice to put out a call for any additional regex helpers. I'm we've all written a few in the past. I think I've got a US Address regex I wrote long time ago. Though it might be a bit too specific... but I think the US Post Office publishes valid address formats. mark -- --------------------------------------------------------------------------- Mark F. Murphy, Director Software Development <mailto:markm@tyrell.com> Tyrell Software Corp <http://www.tyrell.com> --------------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
In message <p0623093cc05974e4a6fb@[10.0.1.2]>, "Mark F. Murphy" writes: >However, for some difficult regex's, there might need to be some >support methods in order to make them readily usable. Well, I suggest that if you have the motivation, cook something up and submit it. Adding a collection of useful regular expressions/parsing functions with support classes for common tasks may breathe some new life into the project. I don't think it would conflict with anything already going on in Commons. Also, it's been suggested to move Commons Lang out of Commons and to move ORO into Commons Lang. The addition you've suggested seems like a good fit either way. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
At 10:57 PM -0400 4/4/06, Daniel F. Savarese wrote: >In message <p06230906c055a3265f18@[10.0.1.2]>, "Mark F. Murphy" writes: >>It also came to mind that it might be kind of nice to bundle some >>very common expressions which would be useful for others. > >Sounds good to me. They'd also make a good basis for unit tests. >What's a good way to include them? String constants in a singleton? That would be one way. However, for some difficult regex's, there might need to be some support methods in order to make them readily usable. For example, the CSV regex I did requires a 5 group match because of the various conditions which might exist: 1) quoted field 2) quoted field had sep term 3) non-quoted field 4) non-quoted field had sep term 5) empty field The "had sep term" is only needed to check the last field for being empty. So while the regex is a big part of the CSV parser, without a little support code using it, someone might have a difficult time getting out of it what they ultimately want... an array of fields from a parsed CSV line. Of course, the raw regex is certainly good for people who need something just to look at in order to handle their own custom needs and get them going. mark -- --------------------------------------------------------------------------- Mark F. Murphy, Director Software Development <mailto:markm@tyrell.com> Tyrell Software Corp <http://www.tyrell.com> --------------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
In message <p06230906c055a3265f18@[10.0.1.2]>, "Mark F. Murphy" writes: >It also came to mind that it might be kind of nice to bundle some >very common expressions which would be useful for others. Sounds good to me. They'd also make a good basis for unit tests. What's a good way to include them? String constants in a singleton? daniel --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
At 8:47 PM -0800 1/4/06, Mark F. Murphy wrote: >With so many packages using ORO, you'd think it would be more >valuable if it had more Perl enhancements. On that note... It also came to mind that it might be kind of nice to bundle some very common expressions which would be useful for others. I just finished up a CSV regex. I looked around the net and found a few, but each was weak in one area or the other. So I ended up enhancing whatever I found. I also developed a RFC822 (email address) matcher some years back which I use in my projects. mark -- --------------------------------------------------------------------------- Mark F. Murphy, Director Software Development <mailto:markm@tyrell.com> Tyrell Software Corp <http://www.tyrell.com> --------------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
Author: dfs
Date: Sat Apr 1 09:46:38 2006
New Revision: 390706
URL: http://svn.apache.org/viewcvs?rev=390706&view=rev
Log:
Elaborated on Perl5Util thread-local change.
Modified:
jakarta/oro/trunk/CHANGES
Modified: jakarta/oro/trunk/CHANGES
URL: http://svn.apache.org/viewcvs/jakarta/oro/trunk/CHANGES?rev=390706&r1=390705&r2=390706&view=diff
==============================================================================
--- jakarta/oro/trunk/CHANGES (original)
+++ jakarta/oro/trunk/CHANGES Sat Apr 1 09:46:38 2006
@@ -1,7 +1,8 @@
$Id$
Version 2.1-dev-1
- o Perl5Util.getMatch() now returns a thread-local result.
+ o Perl5Util.getMatch() now returns a thread-local result as do the
+ MatchResult interface methods implemented by Perl5Util.
o broke up the master jar files into separate components:
jakarta-oro : all classes
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
Author: dfs
Date: Sat Apr 1 09:31:03 2006
New Revision: 390702
URL: http://svn.apache.org/viewcvs?rev=390702&view=rev
Log:
Made more match-associated stated thread-local.
Modified:
jakarta/oro/trunk/src/java/org/apache/oro/text/perl/Perl5Util.java
Modified: jakarta/oro/trunk/src/java/org/apache/oro/text/perl/Perl5Util.java
URL: http://svn.apache.org/viewcvs/jakarta/oro/trunk/src/java/org/apache/oro/text/perl/Perl5Util.java?rev=390702&r1=390701&r2=390702&view=diff
==============================================================================
--- jakarta/oro/trunk/src/java/org/apache/oro/text/perl/Perl5Util.java (original)
+++ jakarta/oro/trunk/src/java/org/apache/oro/text/perl/Perl5Util.java Sat Apr 1 09:31:03
2006
@@ -135,8 +135,26 @@
private Perl5Matcher __matcher;
/** The compiled match expression parsing regular expression. */
private Pattern __matchPattern;
- /** The last match from a successful call to a matching method. */
- private ThreadLocal __lastMatch;
+
+ class ThreadState {
+ /** The last match from a successful call to a matching method. */
+ MatchResult lastMatch = null;
+
+ /**
+ * Keeps track of the original input (for postMatch() and preMatch())
+ * methods. This will be discarded if the preMatch() and postMatch()
+ * methods are moved into the MatchResult interface.
+ */
+ Object originalInput = null;
+
+ /**
+ * Keeps track of the begin and end offsets of the original input for
+ * the postMatch() and preMatch() methods.
+ */
+ private int inputBeginOffset = 0, inputEndOffset = 0;
+ }
+
+ private ThreadLocal __threadState;
/**
* A container for temporarily holding the results of a split before
@@ -144,19 +162,6 @@
*/
private ArrayList __splitList;
- /**
- * Keeps track of the original input (for postMatch() and preMatch())
- * methods. This will be discarded if the preMatch() and postMatch()
- * methods are moved into the MatchResult interface.
- */
- private Object __originalInput;
-
- /**
- * Keeps track of the begin and end offsets of the original input for
- * the postMatch() and preMatch() methods.
- */
- private int __inputBeginOffset, __inputEndOffset;
-
/** Used for default return value of post and pre Match() */
private static final String __nullString = "";
@@ -188,7 +193,11 @@
public Perl5Util(PatternCache cache) {
__splitList = new ArrayList();
__matcher = new Perl5Matcher();
- __lastMatch = new ThreadLocal();
+ __threadState = new ThreadLocal() {
+ protected synchronized Object initialValue() {
+ return new ThreadState();
+ }
+ };
__patternCache = cache;
__expressionCache = new CacheLRU(cache.capacity());
__compilePatterns();
@@ -205,6 +214,15 @@
this(new PatternCacheLRU());
}
+
+ /**
+ * A convenience method to take care of typecasting. Wouldn't be
+ * necessary if we we could use Java Generics.
+ **/
+ private ThreadState __getState() {
+ return (ThreadState)__threadState.get();
+ }
+
/**
* Compiles the patterns (currently only the match expression) used to
* parse Perl5 expressions. Right now it initializes __matchPattern.
@@ -330,10 +348,11 @@
result = __matcher.contains(input, __parseMatchExpression(pattern));
if(result) {
- __lastMatch.set(__matcher.getMatch());
- __originalInput = input;
- __inputBeginOffset = 0;
- __inputEndOffset = input.length;
+ ThreadState state = __getState();
+ state.lastMatch = __matcher.getMatch();
+ state.originalInput = input;
+ state.inputBeginOffset = 0;
+ state.inputEndOffset = input.length;
}
return result;
@@ -425,10 +444,11 @@
result = __matcher.contains(input, __parseMatchExpression(pattern));
if(result) {
- __lastMatch.set(__matcher.getMatch());
- __originalInput = input.getInput();
- __inputBeginOffset = input.getBeginOffset();
- __inputEndOffset = input.getEndOffset();
+ ThreadState state = __getState();
+ state.lastMatch = __matcher.getMatch();
+ state.originalInput = input.getInput();
+ state.inputBeginOffset = input.getBeginOffset();
+ state.inputEndOffset = input.getEndOffset();
}
return result;
@@ -447,7 +467,7 @@
* last match found.
*/
public synchronized MatchResult getMatch() {
- return (MatchResult)__lastMatch.get();
+ return __getState().lastMatch;
}
@@ -561,7 +581,7 @@
Util.substitute(result, __matcher, entry._pattern, entry._substitution,
input, entry._numSubstitutions);
- __lastMatch.set(__matcher.getMatch());
+ __getState().lastMatch = __matcher.getMatch();
return subCount;
}
@@ -667,7 +687,7 @@
Util.substitute(result, __matcher, compiledPattern, substitution,
input, numSubstitutions);
- __lastMatch.set(__matcher.getMatch());
+ __getState().lastMatch = __matcher.getMatch();
return subCount;
}
@@ -818,7 +838,7 @@
__splitList.clear();
// Just for the sake of completeness
- __lastMatch.set(currentResult);
+ __getState().lastMatch = currentResult;
}
/**
@@ -955,8 +975,7 @@
* @return The length of the last match found.
*/
public synchronized int length() {
- MatchResult match = (MatchResult)__lastMatch.get();
- return match.length();
+ return getMatch().length();
}
/**
@@ -966,8 +985,7 @@
* the entire match itself.
*/
public synchronized int groups() {
- MatchResult match = (MatchResult)__lastMatch.get();
- return match.groups();
+ return getMatch().groups();
}
@@ -983,8 +1001,7 @@
* of length 0.
*/
public synchronized String group(int group) {
- MatchResult match = (MatchResult)__lastMatch.get();
- return match.group(group);
+ return getMatch().group(group);
}
/**
@@ -1000,8 +1017,7 @@
* use the offset to index an array or String.
*/
public synchronized int begin(int group) {
- MatchResult match = (MatchResult)__lastMatch.get();
- return match.begin(group);
+ return getMatch().begin(group);
}
@@ -1016,8 +1032,7 @@
* string will return its start offset.
*/
public synchronized int end(int group) {
- MatchResult match = (MatchResult)__lastMatch.get();
- return match.end(group);
+ return getMatch().end(group);
}
@@ -1032,8 +1047,7 @@
* not exist, returns -1.
*/
public synchronized int beginOffset(int group) {
- MatchResult match = (MatchResult)__lastMatch.get();
- return match.beginOffset(group);
+ return getMatch().beginOffset(group);
}
/**
@@ -1048,8 +1062,7 @@
* string will return its start offset.
*/
public synchronized int endOffset(int group) {
- MatchResult match = (MatchResult)__lastMatch.get();
- return match.endOffset(group);
+ return getMatch().endOffset(group);
}
/**
@@ -1058,7 +1071,7 @@
* @return A string containing the entire match.
*/
public synchronized String toString() {
- MatchResult match = (MatchResult)__lastMatch.get();
+ MatchResult match = getMatch();
if(match == null)
return null;
return match.toString();
@@ -1071,38 +1084,38 @@
* @return The part of the input following the last match found.
*/
public synchronized String preMatch() {
- int begin;
+ ThreadState state = __getState();
- if(__originalInput == null)
+ if(state.originalInput == null)
return __nullString;
- begin = beginOffset(0);
+ int begin = beginOffset(0);
if(begin <= 0)
return __nullString;
- if(__originalInput instanceof char[]) {
+ if(state.originalInput instanceof char[]) {
char[] input;
- input = (char[])__originalInput;
+ input = (char[])state.originalInput;
// Just in case we make sure begin offset is in bounds. It should
// be but we're paranoid.
if(begin > input.length)
begin = input.length;
- return new String(input, __inputBeginOffset, begin);
- } else if(__originalInput instanceof String) {
+ return new String(input, state.inputBeginOffset, begin);
+ } else if(state.originalInput instanceof String) {
String input;
- input = (String)__originalInput;
+ input = (String)state.originalInput;
// Just in case we make sure begin offset is in bounds. It should
// be but we're paranoid.
if(begin > input.length())
begin = input.length();
- return input.substring(__inputBeginOffset, begin);
+ return input.substring(state.inputBeginOffset, begin);
}
return __nullString;
@@ -1115,37 +1128,37 @@
* @return The part of the input following the last match found.
*/
public synchronized String postMatch() {
- int end;
+ ThreadState state = __getState();
- if(__originalInput == null)
+ if(state.originalInput == null)
return __nullString;
- end = endOffset(0);
+ int end = endOffset(0);
if(end < 0)
return __nullString;
- if(__originalInput instanceof char[]) {
+ if(state.originalInput instanceof char[]) {
char[] input;
- input = (char[])__originalInput;
+ input = (char[])state.originalInput;
// Just in case we make sure begin offset is in bounds. It should
// be but we're paranoid.
if(end >= input.length)
return __nullString;
- return new String(input, end, __inputEndOffset - end);
- } else if(__originalInput instanceof String) {
+ return new String(input, end, state.inputEndOffset - end);
+ } else if(state.originalInput instanceof String) {
String input;
- input = (String)__originalInput;
+ input = (String)state.originalInput;
// Just in case we make sure begin offset is in bounds. It should
// be but we're paranoid.
if(end >= input.length())
return __nullString;
- return input.substring(end, __inputEndOffset);
+ return input.substring(end, state.inputEndOffset);
}
return __nullString;
@@ -1162,10 +1175,11 @@
* length array.
*/
public synchronized char[] preMatchCharArray() {
+ ThreadState state = __getState();
int begin;
char[] result = null;
- if(__originalInput == null)
+ if(state.originalInput == null)
return null;
begin = beginOffset(0);
@@ -1173,30 +1187,31 @@
if(begin <= 0)
return null;
- if(__originalInput instanceof char[]) {
+ if(state.originalInput instanceof char[]) {
char[] input;
- input = (char[])__originalInput;
+ input = (char[])state.originalInput;
// Just in case we make sure begin offset is in bounds. It should
// be but we're paranoid.
if(begin >= input.length)
begin = input.length;
- result = new char[begin - __inputBeginOffset];
- System.arraycopy(input, __inputBeginOffset, result, 0, result.length);
- } else if(__originalInput instanceof String) {
+ result = new char[begin - state.inputBeginOffset];
+ System.arraycopy(input, state.inputBeginOffset, result, 0,
+ result.length);
+ } else if(state.originalInput instanceof String) {
String input;
- input = (String)__originalInput;
+ input = (String)state.originalInput;
// Just in case we make sure begin offset is in bounds. It should
// be but we're paranoid.
if(begin >= input.length())
begin = input.length();
- result = new char[begin - __inputBeginOffset];
- input.getChars(__inputBeginOffset, begin, result, 0);
+ result = new char[begin - state.inputBeginOffset];
+ input.getChars(state.inputBeginOffset, begin, result, 0);
}
return result;
@@ -1213,10 +1228,11 @@
* length array.
*/
public synchronized char[] postMatchCharArray() {
+ ThreadState state = __getState();
int end;
char[] result = null;
- if(__originalInput == null)
+ if(state.originalInput == null)
return null;
end = endOffset(0);
@@ -1224,31 +1240,31 @@
if(end < 0)
return null;
- if(__originalInput instanceof char[]) {
+ if(state.originalInput instanceof char[]) {
int length;
char[] input;
- input = (char[])__originalInput;
+ input = (char[])state.originalInput;
// Just in case we make sure begin offset is in bounds. It should
// be but we're paranoid.
if(end >= input.length)
return null;
- length = __inputEndOffset - end;
+ length = state.inputEndOffset - end;
result = new char[length];
System.arraycopy(input, end, result, 0, length);
- } else if(__originalInput instanceof String) {
+ } else if(state.originalInput instanceof String) {
String input;
- input = (String)__originalInput;
+ input = (String)state.originalInput;
// Just in case we make sure begin offset is in bounds. It should
// be but we're paranoid.
- if(end >= __inputEndOffset)
+ if(end >= state.inputEndOffset)
return null;
- result = new char[__inputEndOffset - end];
- input.getChars(end, __inputEndOffset, result, 0);
+ result = new char[state.inputEndOffset - end];
+ input.getChars(end, state.inputEndOffset, result, 0);
}
return result;
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
Author: dfs
Date: Sat Apr 1 08:53:45 2006
New Revision: 390695
URL: http://svn.apache.org/viewcvs?rev=390695&view=rev
Log:
Changed Perl5Util MatchResult instances produced by getMatch() to be thread-local.
Modified:
jakarta/oro/trunk/CHANGES
jakarta/oro/trunk/src/java/org/apache/oro/text/perl/Perl5Util.java
Modified: jakarta/oro/trunk/CHANGES
URL: http://svn.apache.org/viewcvs/jakarta/oro/trunk/CHANGES?rev=390695&r1=390694&r2=390695&view=diff
==============================================================================
--- jakarta/oro/trunk/CHANGES (original)
+++ jakarta/oro/trunk/CHANGES Sat Apr 1 08:53:45 2006
@@ -1,6 +1,8 @@
$Id$
Version 2.1-dev-1
+ o Perl5Util.getMatch() now returns a thread-local result.
+
o broke up the master jar files into separate components:
jakarta-oro : all classes
jakarta-oro-core : required interfaces
Modified: jakarta/oro/trunk/src/java/org/apache/oro/text/perl/Perl5Util.java
URL: http://svn.apache.org/viewcvs/jakarta/oro/trunk/src/java/org/apache/oro/text/perl/Perl5Util.java?rev=390695&r1=390694&r2=390695&view=diff
==============================================================================
--- jakarta/oro/trunk/src/java/org/apache/oro/text/perl/Perl5Util.java (original)
+++ jakarta/oro/trunk/src/java/org/apache/oro/text/perl/Perl5Util.java Sat Apr 1 08:53:45
2006
@@ -110,16 +110,11 @@
* the last {@link org.apache.oro.text.regex.MatchResult MatchResult}
* found (which can be accessed with {@link #getMatch()}) by a match or
* substitution (or even a split, but this isn't particularly useful).
- * At the moment, the
+ * The
* {@link org.apache.oro.text.regex.MatchResult MatchResult} returned
- * by {@link #getMatch()} is not stored in a thread-local variable. Therefore
- * concurrent calls to {@link #getMatch()} will produce unpredictable
- * results. So if your concurrent program requires the match results,
- * you must protect the matching and the result retrieval in a critical
- * section. If you do not need match results, you don't need to do anything
- * special. If you feel the J2SE implementation of {@link #getMatch()}
- * should use a thread-local variable and obviate the need for a critical
- * section, please express your views on the oro-dev mailing list.
+ * by {@link #getMatch()} is stored in a thread-local variable. Therefore
+ * concurrent calls to {@link #getMatch()} will produce the last match
+ * found by the calling thread.
*
* @version @version@
* @since 1.0
@@ -141,7 +136,8 @@
/** The compiled match expression parsing regular expression. */
private Pattern __matchPattern;
/** The last match from a successful call to a matching method. */
- private MatchResult __lastMatch;
+ private ThreadLocal __lastMatch;
+
/**
* A container for temporarily holding the results of a split before
* deleting trailing empty fields.
@@ -192,6 +188,7 @@
public Perl5Util(PatternCache cache) {
__splitList = new ArrayList();
__matcher = new Perl5Matcher();
+ __lastMatch = new ThreadLocal();
__patternCache = cache;
__expressionCache = new CacheLRU(cache.capacity());
__compilePatterns();
@@ -333,7 +330,7 @@
result = __matcher.contains(input, __parseMatchExpression(pattern));
if(result) {
- __lastMatch = __matcher.getMatch();
+ __lastMatch.set(__matcher.getMatch());
__originalInput = input;
__inputBeginOffset = 0;
__inputEndOffset = input.length;
@@ -428,7 +425,7 @@
result = __matcher.contains(input, __parseMatchExpression(pattern));
if(result) {
- __lastMatch = __matcher.getMatch();
+ __lastMatch.set(__matcher.getMatch());
__originalInput = input.getInput();
__inputBeginOffset = input.getBeginOffset();
__inputEndOffset = input.getEndOffset();
@@ -450,7 +447,7 @@
* last match found.
*/
public synchronized MatchResult getMatch() {
- return __lastMatch;
+ return (MatchResult)__lastMatch.get();
}
@@ -564,7 +561,7 @@
Util.substitute(result, __matcher, entry._pattern, entry._substitution,
input, entry._numSubstitutions);
- __lastMatch = __matcher.getMatch();
+ __lastMatch.set(__matcher.getMatch());
return subCount;
}
@@ -670,7 +667,7 @@
Util.substitute(result, __matcher, compiledPattern, substitution,
input, numSubstitutions);
- __lastMatch = __matcher.getMatch();
+ __lastMatch.set(__matcher.getMatch());
return subCount;
}
@@ -821,7 +818,7 @@
__splitList.clear();
// Just for the sake of completeness
- __lastMatch = currentResult;
+ __lastMatch.set(currentResult);
}
/**
@@ -958,7 +955,8 @@
* @return The length of the last match found.
*/
public synchronized int length() {
- return __lastMatch.length();
+ MatchResult match = (MatchResult)__lastMatch.get();
+ return match.length();
}
/**
@@ -968,7 +966,8 @@
* the entire match itself.
*/
public synchronized int groups() {
- return __lastMatch.groups();
+ MatchResult match = (MatchResult)__lastMatch.get();
+ return match.groups();
}
@@ -984,7 +983,8 @@
* of length 0.
*/
public synchronized String group(int group) {
- return __lastMatch.group(group);
+ MatchResult match = (MatchResult)__lastMatch.get();
+ return match.group(group);
}
/**
@@ -1000,7 +1000,8 @@
* use the offset to index an array or String.
*/
public synchronized int begin(int group) {
- return __lastMatch.begin(group);
+ MatchResult match = (MatchResult)__lastMatch.get();
+ return match.begin(group);
}
@@ -1015,7 +1016,8 @@
* string will return its start offset.
*/
public synchronized int end(int group) {
- return __lastMatch.end(group);
+ MatchResult match = (MatchResult)__lastMatch.get();
+ return match.end(group);
}
@@ -1030,7 +1032,8 @@
* not exist, returns -1.
*/
public synchronized int beginOffset(int group) {
- return __lastMatch.beginOffset(group);
+ MatchResult match = (MatchResult)__lastMatch.get();
+ return match.beginOffset(group);
}
/**
@@ -1045,7 +1048,8 @@
* string will return its start offset.
*/
public synchronized int endOffset(int group) {
- return __lastMatch.endOffset(group);
+ MatchResult match = (MatchResult)__lastMatch.get();
+ return match.endOffset(group);
}
/**
@@ -1054,9 +1058,10 @@
* @return A string containing the entire match.
*/
public synchronized String toString() {
- if(__lastMatch == null)
+ MatchResult match = (MatchResult)__lastMatch.get();
+ if(match == null)
return null;
- return __lastMatch.toString();
+ return match.toString();
}
@@ -1071,7 +1076,7 @@
if(__originalInput == null)
return __nullString;
- begin = __lastMatch.beginOffset(0);
+ begin = beginOffset(0);
if(begin <= 0)
return __nullString;
@@ -1115,7 +1120,7 @@
if(__originalInput == null)
return __nullString;
- end = __lastMatch.endOffset(0);
+ end = endOffset(0);
if(end < 0)
return __nullString;
@@ -1163,7 +1168,7 @@
if(__originalInput == null)
return null;
- begin = __lastMatch.beginOffset(0);
+ begin = beginOffset(0);
if(begin <= 0)
return null;
@@ -1214,7 +1219,7 @@
if(__originalInput == null)
return null;
- end = __lastMatch.endOffset(0);
+ end = endOffset(0);
if(end < 0)
return null;
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
We're discussing various ideas and thoughts on restructuring Jakarta on the general@jakarta mailing list. On the off chance that someone isn't subscribed to the general@jakarta.apache.org mailing list, I thought I'd drop an email to each of the -dev mailing lists so they have a chance to be involved. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
Author: dfs
Date: Fri Jan 27 12:33:20 2006
New Revision: 372972
URL: http://svn.apache.org/viewcvs?rev=372972&view=rev
Log:
Fixed a spelling error in build.propertes comment.
Modified:
jakarta/oro/trunk/build.properties
Modified: jakarta/oro/trunk/build.properties
URL: http://svn.apache.org/viewcvs/jakarta/oro/trunk/build.properties?rev=372972&r1=372971&r2=372972&view=diff
==============================================================================
--- jakarta/oro/trunk/build.properties (original)
+++ jakarta/oro/trunk/build.properties Fri Jan 27 12:33:20 2006
@@ -17,7 +17,7 @@
#
# This file controls various properties which may be set during a build.
#
-# This file is intended to be modified by users to accomadate their own
+# This file is intended to be modified by users to accommodate their own
# working practices, or overridden by one of the property files specified
# in build.xml.
#
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
In message <p06230925bfe25404b981@[10.0.1.2]>, "Mark F. Murphy" writes:
>Well, I started the thread because I was thinking about adding some
>of the functionality we've been talking about.
That would put you in the driver's seat :) I agree with you that
updating Perl5Matcher/Perl5Compiler to the latest Perl syntax (5.8?)
(excluding any features from the perlre man page labeled as
"highly experimental") is probably the most desired enhancement.
Personally, look-behind assertions would be nice and reducing the
amount of recursion in the processing of inefficiently formulated
regular expressions (to reduce the likelihood of blowing the stack).
daniel
-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#-
s a v a r e s e # In distant lands, I hear the call of my home.
software research # Yet my work is not done. My journey's just begun.
http://www.savarese.com/ # -- http://www.sleepandthetraveller.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
At 11:02 PM -0500 1/4/06, Daniel F. Savarese wrote: >There's a lot of development >we could do to improve ORO--from feature enhancements, such as supporting >the latest Perl regex syntax, to design and performance improvements--but >there's got to be reason to make the time investment. I keep on finding >jakarta-oro jars being used in unexpected places, but I haven't seen any >of the developers for those projects show up here despite its apparently >very widespread use :( Well, I started the thread because I was thinking about adding some of the functionality we've been talking about. With so many packages using ORO, you'd think it would be more valuable if it had more Perl enhancements. mark -- --------------------------------------------------------------------------- Mark F. Murphy, Director Software Development <mailto:markm@tyrell.com> Tyrell Software Corp <http://www.tyrell.com> --------------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
In message <p06230920bfe22c838928@[10.0.1.2]>, "Mark F. Murphy" writes:
>Seriously though, do we expect the projects that depend on ORO
>currently to be switching to java.util.regex?
I think they will switch, but I wouldn't say we should expect them to in
the sense of recommending they switch. By and large, most Java developers
prefer to use the core APIs and eliminate dependencies on non-standard
libraries. The latest case of this I've seen has been various comments
in public forums criticizing programmers using my RockSaw raw socket
library because it's non-standard and there's a possibility raw sockets
may be added to java.net in a future JDK.
I think it's a safe bet that most new Java development that requires
regular expressions is being done with java.util.regex. The interest
in alternative regular expression libraries appears to have dropped
precipitously since the release of JDK 1.4. There's a lot of development
we could do to improve ORO--from feature enhancements, such as supporting
the latest Perl regex syntax, to design and performance improvements--but
there's got to be reason to make the time investment. I keep on finding
jakarta-oro jars being used in unexpected places, but I haven't seen any
of the developers for those projects show up here despite its apparently
very widespread use :(
daniel
-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-| Sleep and The Traveller |-#-#-#-#-#-#-#-
s a v a r e s e # In distant lands, I hear the call of my home.
software research # Yet my work is not done. My journey's just begun.
http://www.savarese.com/ # -- http://www.sleepandthetraveller.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: oro-dev-help@jakarta.apache.org
At 4:06 PM -0500 1/4/06, Daniel F. Savarese wrote: >In message <p06230952bfdf91794dcd@[10.0.1.2]>, "Mark F. Murphy" writes: >>Is there still a goal of adding Perl 5.6 regex? Is work being done on it? >> >>With so many projects using ORO, is there a need to move forward on this? > >I think the situation we're in is one of insufficient demand for >enhancements. When demand evidences itself, I think we'll see >work on enhancements (provided those with the demand are willing to >do some of the work). But I don't expect that demand to materialize, >especially after java.util.regex has reinvented or borrowed jakarta-oro >concepts to fix API shortcomings in its original incarnation (e.g., the >addition in 1.5 of MatchResult, quote(), the usePattern() kluge, >region(), etc.). Except not many are on 1.5 yet. :) Seriously though, do we expect the projects that depend on ORO currently to be switching to java.util.regex? mark -- --------------------------------------------------------------------------- Mark F. Murphy, Director Software Development <mailto:markm@tyrell.com> Tyrell Software Corp <http://www.tyrell.com> --------------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
In message <p06230952bfdf91794dcd@[10.0.1.2]>, "Mark F. Murphy" writes: >Is there still a goal of adding Perl 5.6 regex? Is work being done on it? > >With so many projects using ORO, is there a need to move forward on this? I think the situation we're in is one of insufficient demand for enhancements. When demand evidences itself, I think we'll see work on enhancements (provided those with the demand are willing to do some of the work). But I don't expect that demand to materialize, especially after java.util.regex has reinvented or borrowed jakarta-oro concepts to fix API shortcomings in its original incarnation (e.g., the addition in 1.5 of MatchResult, quote(), the usePattern() kluge, region(), etc.). daniel --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
So, I was looking at the Development Plan and didn't see any kind of schedule. http://jakarta.apache.org/oro/devplan-2.0.html Is there still a goal of adding Perl 5.6 regex? Is work being done on it? With so many projects using ORO, is there a need to move forward on this? mark -- --------------------------------------------------------------------------- Mark F. Murphy, Director Software Development <mailto:markm@tyrell.com> Tyrell Software Corp <http://www.tyrell.com> --------------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37909>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37909 ------- Additional Comments From dfs@apache.org 2005-12-15 20:52 ------- (In reply to comment #2) > actually, we need this (in my company) to specify dependencies in to oro in our > apps with the Extension-List mechanism. For instance Tomcat does not consider > that a dependency is resolved if the "extension" we depend on does not specify > this entry. Thanks. I don't think most of us at Jakarta were aware that this was becoming an issue. We've updated the packaging instructions at http://jakarta.apache.org/site/packageversioning.html to include Implementaton-Vendor-Id. It would seem we should have been doing this since J2SE 1.3. The change I made to oro is in the main trunk. If you haven't already manually fixed the manifest for your purposes, you can either build the latest version of the source from: http://svn.apache.org/repos/asf/jakarta/oro/trunk/ or rebuild the 2.0.8 source using the current: http://svn.apache.org/repos/asf/jakarta/oro/trunk/build.properties http://svn.apache.org/repos/asf/jakarta/oro/trunk/build.xml I don't think the change is significant enough to merit a 2.0.9 release (it would be 2.0.8 with just build.properties and build.xml changed). But if there is some reason why it's necessary, I can call for a release vote. Further discussion should happen on the oro-dev mailing list (no use cluttering this issue report). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37909>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37909 ------- Additional Comments From pgrange@cvf.fr 2005-12-15 09:31 ------- (In reply to comment #1) > Added Implementation-Vendor-Id to manifest. It would be nice if an > explanation could be provided as to why it was needed. Sorry. I could say that it is just to have a better manifest... ;) but actually, we need this (in my company) to specify dependencies in to oro in our apps with the Extension-List mechanism. For instance Tomcat does not consider that a dependency is resolved if the "extension" we depend on does not specify this entry. Thank you for your help. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: oro-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: oro-dev-help@jakarta.apache.org