Re: [Informal Vote] please express your opinion on using Nexus and Hudson: see https://issues.apache.org/jira/browse/UIMA-1717
Marshall Schor wrote: Here's my vision of automation (achieved over time :-) ), and why CI could be important - it is building the potential releases from source checkout. We have CI going on Hudson; we decide at some point that things merit a release; so we push some button on the CI or Nexus interface and get a particular snapshot release tagged, checked out and built as a candidate. We do some additional integration testing, and then vote on the thing in the nexus repo, where it look like a release but is in some held state. After the vote succeeds, we log onto the Nexus web interface and push another button, and the release happens. +1 sounds nice Jörn
Re: [Informal Vote] please express your opinion on using Nexus and Hudson: see https://issues.apache.org/jira/browse/UIMA-1717
Marshall Schor wrote: I'm +1 for doing this, and offer to do some/most of the legwork to get this to happen. Other opinions? From a development point of view Hudson can help us to make sure that our build is never broken, and if so notice us, but usually our build always works. Not sure if it is worth the effort to get one build broken notification per year. The only other advantage I see is that it can automatically publish snapshot builds, but when this is the motivation to get CI on Hudson we maybe should start to release more frequently. Jörn
Re: Sandbox OSGi runtime
Tommaso Teofili wrote: Hi all, what do you think of a uimaj module similar to uimaj-ep-runtime just for sandbox components (something like sanxbox-osgi-runtime)? This is useful when you want to use Sandbox components in an OSGi environment. Not sure how this can be done, since UIMA must be able to load the AEs from an OSGi bundle, but then we have all the issues we discussed a while back. http://mail-archives.apache.org/mod_mbox/incubator-uima-dev/201001.mbox/b917db631001280112v1a9b2d27if068b0c1ba5f7...@mail.gmail.com Jörn
Re: rename uimaj-ep-runtime ?
Marshall Schor wrote: Tommaso Teofili wrote: Hi all, following the UIMA and OSGI thread, do you think we can rename uimaj-ep-runtime as uimaj-osgi-untime ? Any issues with backwards compatibility? (I think we should try to minimize renames that would require actions by our users.) This change would break the builds of users who use maven to build their eclipse plugins depending on the runtime plugin. Jörn
Re: [Discuss] graduation
Marshall Schor wrote: After reading the parts of the ASF website related to graduation from the incubator to a top-level project (for instance I think this is the main link: http://incubator.apache.org/guides/graduation.htm), do you think we're ready for graduation? Is there more we need to do first? +1 Jörn
Re: [PROPOSAL] AlchemyAPI Annotator
Tommaso Teofili wrote: Thanks a lot, Marshall! We'll fill the grant and let you know once it's been sent. Maybe you want to open a jira issue, then we can track the import of the project there. Jörn
Re: OSGIing UIMA
Tommaso Teofili wrote: Hi all, my initial need was to simply use UIMA as OSGI bundle so I looked at the uimaj-as-osgi-runtime and uimaj-eclipse-runtime that seem to me very near to what I deserve, they were fine except that (at the moment) I don't need the UIMA-AS packages and the 'eclipse' label puzzled me a bit and actually, as far as I can understand, the Eclipe plugin configurations in the uimaj-eclipse-plugins POM are not needed for an OSGI environment. So my first idea was only to do some crafting on uimaj-eclipse-runtime. When I created uimaj-as-osgi-runtime we named it osgi and not eclipse, because we noticed that it will now be used also outside of eclipse. We should rename uimaj-ep-runtime to uimaj-osgi-runtime. uimaj-ep-runtime does not depend on any eclipse plugins and can be used with an OSGi server. Actually I did that already together with Eclipse-RegisterBuddy to be able to load annotators from a bundle. What I realized after Thilo's reply was that instead of having a unique UIMA OSGI runtime artifact (bundle) with all the stuff inside we could make each UIMA module (uimaj-core, uimaj-tools, uimaj-cpe, etc) a single bundle with all its fine grain packages and resources. Taking this approach does not has a real advantage over the approach we have right now, in my opinion. Maybe you save a few KB storage on the server, if you do not deploy all the classes. But what else do you think we get ? If this should be the case we should provide alternative packagings (jar/pear/bundle) to maintain compatibility with non-OSGI systems. More over (for annotators) if we enable the bundle packaging then we need to modify the tools that use pears i.e. the CVD to be able to load AEs also from a bundle So annotator bundles are already supported. To make uima OSGi compliant we should do the annotator loading a bit different. Can we not use the OSGi's FrameworkUtil to load annotator class ? If so we can have a bundle activator for uima-ep-runtime which modifies the way annotators are loaded. Jörn
Re: OSGIing UIMA
Thilo Goetz wrote: On 1/28/2010 17:15, Jörn Kottmann wrote: Marshall Schor wrote: I'm probably showing my ignorance here :-) but, leaving aside the question of making core uima support annotators as osgi bundles, can you say what the differences are between the uimaj-ep-runtime bundle we build for eclipse, having all the core UIMA capability, and your goal below of making uimaj available as an OSGI bundle? My understanding is that Eclipse plugins are osgi bundles, and we build these using the Felix maven plugin, which wraps the standard OSGI bundle making code. Thanks for the clarifications... Isn't the only thing we are missing the support for annotators in OSGi bundles ? Right now that can be hacked by using the Eclipse-RegisterBuddy header, which works for example with the spring OSGi server. Thilo, why do you think we cannot add OSGi annotator bundles without breaking backward compatibility ? Good question. I should have written it down, I can't quite recall now what I was thinking of. One thing that might get interesting is JCas, and basically everything that does manual class loading. Maybe this can all be done in a backward compatible manner, though. What do you think about OSGi's FrameworkUtil, can we use that to do our class loading ? Jörn
Re: [PROPOSAL] AlchemyAPI Annotator
Tommaso Teofili wrote: Hi Thilo, I wrote all the code by myself except for some help from Simone Tripodi (Cocoon committer and PMC, Commons Digester Sandbox and Labs Amber committer) with the JsonDigester to parse Json files (made with javacc). In total it's 18.705 lines of code (you can see some metrics by Ohloh on http://code.google.com/p/alchemy-annotator/ ), many classes are JCASGen generated TypeSystem classes but the relevant part is more or less 50 classes. Do you think we need a software grant? How many of these 19K lines are generated ? Jörn
Re: OSGIing UIMA
Marshall Schor wrote: I'm probably showing my ignorance here :-) but, leaving aside the question of making core uima support annotators as osgi bundles, can you say what the differences are between the uimaj-ep-runtime bundle we build for eclipse, having all the core UIMA capability, and your goal below of making uimaj available as an OSGI bundle? My understanding is that Eclipse plugins are osgi bundles, and we build these using the Felix maven plugin, which wraps the standard OSGI bundle making code. Thanks for the clarifications... Isn't the only thing we are missing the support for annotators in OSGi bundles ? Right now that can be hacked by using the Eclipse-RegisterBuddy header, which works for example with the spring OSGi server. Thilo, why do you think we cannot add OSGi annotator bundles without breaking backward compatibility ? Beside that, it might be a bit more tricky for uima as because it relies on ActiveMQ which did not work well with OSGi in my tests with the uima as client and the spring OSGi server. Jörn
Re: [PROPOSAL] AlchemyAPI Annotator
Tommaso Teofili wrote: Hi all, I've developed a set of UIMA components (analysis engines) wrapping AlchemyAPI [1] webservices provided by Orchestr8 [2] I'd like to donate and include in the Sandbox. +1 sounds interesting, Jörn
Why isn't UIMA AS using the JMS message expiration feature ?
Hello, I noticed that messages sent from the client to the service can pill up in the queue in the case the service is not available e.g. down for an update. In the case the client uses a timeout it should also set the JMS message expiration to the timeout, then the broker can remove old messages Should I open a jira for this ? Jörn
Re: [VOTE] Release UIMA 2.3.0 RC9 as UIMA 2.3.0 incubating
+1 Jörn Marshall Schor wrote: This build keeps the uimacpp and sandbox components from the previous release candidate (the download site on people.apache.org/~schor has hard links to the previous artifacts - so they are guaranteed to be identical). We've had a few sanity checks for the RC9 build, including installing the Eclipse plugins via the RC9 update site on both linux and windows, and running downloading installing the base uima and uima-as binary components and running the installation verification tests - and everything looks good. This build consists of 4 major components: the core UIMA framework (uimaj), the C++ enablement (uimacpp), the Asynchronous Scaleout component (uima-as) and a set of annotators and other add-ons (sandbox). These have been through more than 3 months of validation and testing (counting the previous release candidates). The build process was strengthened to include running RAT (the Release Audit tool) automatically and verifying no RAT issues are found (except for the uimacpp part, where it is still run and verified manually). The release artifacts are available on http://people.apache.org/~schor/uima-release-candidates/2.3.0-RC9/ These artifacts include a partial version of the Eclipse Update Site for the Eclipse plugins, but is complete for the 2.3.0 release. The release is digitally signed by Marshall Schor for all the components except for the C++ component, which is signed by Edward Epstein. No new export control issues are needed for the components; only the uima-as component continues to be classified as 5D002 because it includes Apache ActiveMQ which is so classified (see http://www.apache.org/licenses/exports/ ) Please vote on approving this release. This vote is for all 4 components, together. After the UIMA committers vote, we will ask the IPMC to vote. [ ] +1 Release RC9, it's ready [ ] -1 Don't release yet because of these issues which need to be addressed first: ... --Marshall
Re: with luck, will try to build RC9 tomorrow
Marshall Schor wrote: There are no changes to sandbox, so that won't be rebuilt (and it will have 2009 copyright date, reflecting the time it was built). I'll wait for Jörn to close or otherwise conclude UIMA-1674 per note from Jerry today. Thanks, I tested both fixes Jerry did UIMA-1674 and UIMA-1718. Jörn
Re: UIMA AS client connection to broker lost issue
Jaroslaw Cwiklik wrote: That is right. jerry On Mon, Dec 14, 2009 at 9:53 AM, Jörn Kottmann kottm...@gmail.com wrote: Jaroslaw Cwiklik wrote: Yes, this exception comes from UIMA AS client and it is thrown if the connection to the broker is lost. If the connection to a broker is lost the current code doesnt use onBeforeMessageSend() callback. This method is only called if the connection is ok, right before the send(). The code that detects connection failure is before this. When you get BrokerConnectionException you know that what you've sent previously will not come back. The reply queue has already been deleted. You may assume this and awake all waiting threads and invalidate their states and retry if that is what you want to do. If the broker finally comes online, eventually UIMA AS client will call onBeforeMessageSend() and that will be a clue that things are back to normal. Sorry, have been through a few very busy weeks, since the release is now delayed I would like to fix this problem. To make sure I understand you correctly, a CAS is send via sendCas(...), but it cannot be send because of a broker connection exception, the error is then reported to the status call back listeners entityProcessComplete method. When the status call back listener receives the BrokerConnectionException it should consider all outstanding CASes as failed and retry them. Is that correct ? Must the same action be taken if a timed out CAS comes back ? Jörn
Re: 2.3.0 release candidate 08 now on people.apache.org for review
Marshall Schor wrote: This candidate is located at http://people.apache.org/~schor/uima-release-candidates/2.3.0-RC8/ and includes uimaj uima-as sandbox (this is identical to RC7, it wasn't rebuilt) uimacpp (this is a rebuild by Eddie, hard-linked from p.a.o/~eae, rel 03) eclipse-update-site I'll start the vote in 2-3 days, after some sanity tests are done (to insure I didn't mess up the build process). I will install the new uima-as on our test servers tomorrow. Jörn
Re: UIMA AS client connection to broker lost issue
Jaroslaw Cwiklik wrote: Yes, this exception comes from UIMA AS client and it is thrown if the connection to the broker is lost. If the connection to a broker is lost the current code doesnt use onBeforeMessageSend() callback. This method is only called if the connection is ok, right before the send(). The code that detects connection failure is before this. When you get BrokerConnectionException you know that what you've sent previously will not come back. The reply queue has already been deleted. You may assume this and awake all waiting threads and invalidate their states and retry if that is what you want to do. If the broker finally comes online, eventually UIMA AS client will call onBeforeMessageSend() and that will be a clue that things are back to normal. Sorry, have been through a few very busy weeks, since the release is now delayed I would like to fix this problem. To make sure I understand you correctly, a CAS is send via sendCas(...), but it cannot be send because of a broker connection exception, the error is then reported to the status call back listeners entityProcessComplete method. When the status call back listener receives the BrokerConnectionException it should consider all outstanding CASes as failed and retry them. Is that correct ? Jörn
Re: [VOTE] Release UIMA 2.3.0 release candidate 7 as UIMA 2.3.0 incubating
Marshall Schor wrote: This build consists of 4 major components: the core UIMA framework (uimaj), the C++ enablement (uimacpp), the Asynchronous Scaleout component (uima-as) and a set of annotators and other add-ons (sandbox). These have been through more than 3 months of validation and testing. The build process was strengthened to include running RAT (the Release Audit tool) automatically and verifying no RAT issues are found (except for the uimacpp part, where it is still run and verified manually). The release artifacts are available on http://people.apache.org/~schor/uima-release-candidates/2.3.0-RC7/ These artifacts include a partial version of the Eclipse Update Site for the Eclipse plugins - the site is missing the older versions, but this will be of course corrected when we merge this (after release approval) with the previous information in the Apache dist/incubator/uima directory. The release is digitally signed by Marshall Schor for all the components except for the C++ component, which is signed by Edward Epstein. Please vote on approving this release. This vote is for all 4 components, together. After the UIMA committers vote, we will ask the IPMC to vote. [ ] +1 Release RC7, it's ready [ ] -1 Don't release yet because of these issues which need to be addressed first: ... +1 Jörn
Re: Release candidate 3 of 2.3.0 is now available
Marshall Schor wrote: Jukka Zitting wrote: Hi, On Mon, Nov 30, 2009 at 11:10 PM, Marshall Schor m...@schor.com wrote: Jukka Zitting wrote: It should always be possible to recreate all the binaries from the source package. See the last paragraph of http://www.apache.org/dev/release.html#what. We were aware of this, and do a build from the source distribution test - and the builds work but it is possible that we've missed something here. OK, cool. I digged a bit deeper into uimaj-distr and I think I now better understand how the release package gets built. Everything seems OK there, but I wonder if it wasn't easier to simply package an export of the svn tag. Maintaining different svn and release layouts is quite prone to errors. I agree, it would be easier. I don't recall at the moment why we had a different approach at first, but it's probably worth revisiting that decision. When do you plan to make the next RC ? Thanks, Jörn
UIMA AS extended tests just hang
Hi, I tried to add a test to the extended tests, but when I execute them they just hang. Jörn Console output: ... UIMA AS Client - Shared JMS Connection Not Closed. Current Client Instance Count1 UIMA AS Client Undeployed All Containers Nov 20, 2009 4:29:42 PM org.apache.uima.adapter.jms.activemq.JmsOutputChannel stop INFO: Controller: NoOpAnnotatorQueue Output Channel Shutdown Completed Nov 20, 2009 4:29:42 PM org.apache.uima.aae.controller.AnalysisEngineInstancePoolWithThreadAffinity abort INFO: NoOpAnnotator Calling Destroy On AE instance # 0 Nov 20, 2009 4:29:42 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineCommon_impl$SharedConnection destroy INFO: UIMA AS Client Terminated. Shared Connection Still Open. Current Client Count:1 getMeta Timeout on delegate:NoOpAnnotatorQueue runTest: Initialization Received Reply Containing Exception: Stopping Uima AS Client API. Service Not Responding To a Ping. Nov 20, 2009 4:29:57 PM org.apache.uima.aae.delegate.Delegate$1 Delegate.TimerTask.run INFO: Timeout While Waiting For Reply From Delegate:NoOpAnnotatorQueue GetMeta Request Timed Out. Configured Reply Window Of 60,000. Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineCommon_impl notifyOnTimout INFO: Request For Metadata Has Timed-out. Service Queue:NoOpAnnotatorQueue org.apache.uima.aae.error.UimaASMetaRequestTimeout at org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineCommon_impl.notifyOnTimout(BaseUIMAAsynchronousEngineCommon_impl.java:1872) at org.apache.uima.adapter.jms.client.ClientServiceDelegate.handleError(ClientServiceDelegate.java:152) at org.apache.uima.aae.delegate.Delegate$1.run(Delegate.java:624) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.client.ClientServiceDelegate handleError INFO: Request For Metadata Has Timed-out. Service Queue:NoOpAnnotatorQueue Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineCommon_impl stop INFO: Stopping Asynchronous Client. Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineCommon_impl stop INFO: Asynchronous Client Has Stopped. Nov 20, 2009 4:29:57 PM org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl terminate INFO: Controller: NoOpAnnotator Received Terminate Event Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.activemq.JmsInputChannel stop INFO: Stopping Service JMS Transport. Service: NoOpAnnotatorQueue Service:NoOpAnnotator Message Channel:queue://NoOpAnnotatorQueue Selector:Command=2000 OR Command=2002 Stopped Service:NoOpAnnotator Message Channel:queue://NoOpAnnotatorQueue Selector:Command=2001 Stopped Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.activemq.JmsInputChannel stop INFO: Stopping Service JMS Transport. Service: NoOpAnnotatorQueue Nov 20, 2009 4:29:57 PM org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl stop INFO: Stopping Controller: NoOpAnnotator Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.activemq.JmsOutputChannel stop INFO: Controller: NoOpAnnotatorQueue Aborted Connection To Endpoint: ID:karkand-54505-1258730845595-3:3664:4 and Broker Uri: tcp://localhost:8200 Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.activemq.JmsOutputChannel stop INFO: Controller: NoOpAnnotatorQueue Aborted Connection To Endpoint: ID:karkand-54505-1258730845595-3:3664:1 and Broker Uri: tcp://localhost:8200 Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.activemq.JmsOutputChannel stop INFO: Controller: NoOpAnnotatorQueue Aborted Connection To Endpoint: ID:karkand-54505-1258730845595-3:3664:2 and Broker Uri: tcp://localhost:8200 Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl initialize WARNING: Aborting Asynchronous Client Due to: Metadata Timeout Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl notifyOnInitializationFailure WARNING: Top Level Controller Initialization Exception. Cause: org.apache.uima.resource.ResourceInitializationException org.apache.uima.resource.ResourceInitializationException at org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl.initialize(BaseUIMAAsynchronousEngine_impl.java:668) at org.apache.uima.ee.test.utils.BaseTestSupport.initialize(BaseTestSupport.java:169) at org.apache.uima.ee.test.TestUimaASExtended.access$3(TestUimaASExtended.java:1) at org.apache.uima.ee.test.TestUimaASExtended$1.run(TestUimaASExtended.java:438) Caused by: org.apache.uima.aae.error.UimaASMetaRequestTimeout ... 4 more JMS Connection to Broker: tcp://localhost:8200 Closed Service:NoOpAnnotator Stopped UIMA AS Client - Shared JMS Connection Closed UIMA AS Client Undeployed All Containers Nov 20, 2009 4:29:57 PM org.apache.uima.adapter.jms.activemq.JmsOutputChannel stop INFO:
UIMA AS console input
Press 'q'+'Enter' to quiesce and stop the service or 's'+'Enter' to stop it now. Note: selected option is not echoed on the console. On Ubuntu Linux it is echoed to the console (connected via ssh to the machine). Jörn
UIMA AS client connection to broker lost issue
Hi, right now I am testing the camel uima driver for error handling, for this I have an AE which just throws an exception when it get a CAS. The error handling is just the default, which means that the worker node just reports the error back to the uima as client. Thats fine, the camel route is configured to retry for every in this scenario, thats also fine. But after a while the system just hangs and stops retrying it took me a while to figure out why. The uima driver assumes that every CAS it sends causes a result to be returned, but once in a while it gets back a CAS with a different/new reference id than the one which was sent. This causes the allocated control thread to wait, when this happens to all control threads it just hangs. First of all can it be assumed that for every sent CAS a status comes back with the same reference id (when using timeouts) ? Here is the error I get back in case the reference id does not match the one of the send CAS: org.apache.uima.jms.error.handler.BrokerConnectionException: Unable To Deliver CAS:-7fbfaf13:1250d5b260d:-7ffa To Destination. Connection To Broker failover:(tcp://XXX1:61616,tcp://XXX2:61616)?randomize=false Has Been Lost Jörn
Re: How to avoid message localization failed ?
Marshall Schor wrote: Jörn Kottmann wrote: Hello, on our sever message localization always fails with this error message: MESSAGE LOCALIZATION FAILED: Can't find bundle for base name jms_adapter_messages, locale en_DK This is a little annoying because even in case it fails it should just use english error messages, and if that fails the key of the error message is better than nothing. Should I open a jira ? The localization code already is trying various variations, down to the base name by itself. It's the Java standard getBundle in the standard Java class ResourceBundle. The base name here is jms_adapter_messages, and there is supposed to be a jms_adapter_messages.properties file on the classpath (it's in uimaj-as-jms project, in src/main/resources). Can you find out why this is not on the classpath? The exception was thrown in the our UIMA AS client which is running in an OSGI server using the uima as osgi bundle. Who exactly is trying to load the message file from the classpath ? I guess thats done in the uima core and uima core cannot see the classpath of the uima as bundle. This would explain why it fails in an osgi environment. Jörn
Re: How to avoid message localization failed ?
Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Hello, on our sever message localization always fails with this error message: MESSAGE LOCALIZATION FAILED: Can't find bundle for base name jms_adapter_messages, locale en_DK This is a little annoying because even in case it fails it should just use english error messages, and if that fails the key of the error message is better than nothing. Should I open a jira ? The localization code already is trying various variations, down to the base name by itself. It's the Java standard getBundle in the standard Java class ResourceBundle. The base name here is jms_adapter_messages, and there is supposed to be a jms_adapter_messages.properties file on the classpath (it's in uimaj-as-jms project, in src/main/resources). Can you find out why this is not on the classpath? The exception was thrown in the our UIMA AS client which is running in an OSGI server using the uima as osgi bundle. Who exactly is trying to load the message file from the classpath ? I guess thats done in the uima core and uima core cannot see the classpath of the uima as bundle. This would explain why it fails in an osgi environment. Ok, I added Eclipse-RegisterBuddy to the uima as bundle and then it is possible to locate the exception message file, but I guess that is not part of the OSGI standard. Anyway with Spring DM Server it works. I suggest to add it to the manifest, what do others think ? Jörn
UIMA AS client cannot deserialize exception when running in an OSGI server
Hi, I am doing some error testing and noticed that in case the client gets an exception from a worker node it may fail to deserialize the exception when running in an OSGI server, here is the error: [2009-11-18 14:57:00.689] ActiveMQ Session Task System.err E WARNING: javax.jms.JMSException: Failed to build body from content. Serializable class not available to broker. Reason: com.springsource.server.osgi.framework.ServerClassNotFoundException: org.apache.uima.aae.error.UimaEEServiceException in ServerBundleClassLoader: [bundle=org.apache.activemq.activemq-core_5.3.0] It seems that activemq tries to load uima classes, which it cannot see because they are not on the activemq bundle classpath. Jörn
Re: UIMA AS client cannot deserialize exception when running in an OSGI server
Marshall Schor wrote: Jörn Kottmann wrote: Hi, I am doing some error testing and noticed that in case the client gets an exception from a worker node it may fail to deserialize the exception when running in an OSGI server, here is the error: [2009-11-18 14:57:00.689] ActiveMQ Session Task System.err E WARNING: javax.jms.JMSException: Failed to build body from content. Serializable class not available to broker. Reason: com.springsource.server.osgi.framework.ServerClassNotFoundException: org.apache.uima.aae.error.UimaEEServiceException in ServerBundleClassLoader: [bundle=org.apache.activemq.activemq-core_5.3.0] It seems that activemq tries to load uima classes, which it cannot see because they are not on the activemq bundle classpath. Can you make an OSGi bundle which has both uima-as and its dependencies? That should be possible we did something like that in an internal project where an osgi bundle contains hadoop/hbase classes and dependencies. Jörn
UIMA AS error handling of exception thrown from CasMultiplier.process
Hi, the first Analysis Engine in our uima-as setup is a CasMultiplier, we implement the process method and from this method our implementation throws a RuntimeException, not nice but it can happen. In the client interface we get the CAS back, but EntityProcessStatus.isException returns false, how can it be detected that the CAS was not processed successfully ? Thanks, Jörn
How to avoid message localization failed ?
Hello, on our sever message localization always fails with this error message: MESSAGE LOCALIZATION FAILED: Can't find bundle for base name jms_adapter_messages, locale en_DK This is a little annoying because even in case it fails it should just use english error messages, and if that fails the key of the error message is better than nothing. Should I open a jira ? Jörn
Re: Apache Uima 2.3.0-incubating release candidate 01
Marshall Schor wrote: The release candidate 01 for 2.3.0-incubating is on http://people.apache.org/~schor/uima-release-candidates/2.3.0-RC1/ It has 4 parts: uimaj - the main uima release uima-as - the uima-as add on uima-sandbox - the sandbox components being released uima-cpp - the C++ release, including several binary builds. The Release Audit Reports (RAT) are included. I'll work on posting a test plan to our wiki, probably tomorrow; meanwhile, please try it out. Everyone should recompile existing code which depends on UIMA against this RC to test if there are any problems with the generification. Jörn
Re: doing 2.3.0 RC1 - tomorrow morning?
Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Unless I hear some objections, I would like to tag the first (and hopefully only :-) ) release candidate for 2.3.0 tomorrow morning. Please get any fixes finished up that you would like to get into the release before then, or ask for a short delay if needed... -Marshall Would be nice to get some feedback on UIMA-1658 and UIMA-1659 before we do the rc. These are the last to issue I have with our UIMA AS installation which are important to get fixed. 1657 is fixed, 1658 will need perhaps extensive investigation involving uima-as, spring, and activemq - any of which could be the underlying cause. Because this may be quite open-ended, I will go ahead with doing release candidates now, and we can work for as long as we need to on hardening the fail-over. Let's tentatively plan on a uima-as point release in a couple of months to pick up these changes (assuming the fail-over capability has stablized by then). +1, through UIMA-1657 the failover now works after the worker nodes and the clients are restarted. I agree with Marshall that it could take some time to find out whats wrong. Jörn
Re: doing 2.3.0 RC1 - tomorrow morning?
Marshall Schor wrote: Unless I hear some objections, I would like to tag the first (and hopefully only :-) ) release candidate for 2.3.0 tomorrow morning. Please get any fixes finished up that you would like to get into the release before then, or ask for a short delay if needed... -Marshall Would be nice to get some feedback on UIMA-1658 and UIMA-1659 before we do the rc. These are the last to issue I have with our UIMA AS installation which are important to get fixed. Jörn
Re: doing 2.3.0 RC1 - tomorrow morning?
Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Unless I hear some objections, I would like to tag the first (and hopefully only :-) ) release candidate for 2.3.0 tomorrow morning. Please get any fixes finished up that you would like to get into the release before then, or ask for a short delay if needed... -Marshall Would be nice to get some feedback on UIMA-1658 and UIMA-1659 before we do the rc. These are the last to issue I have with our UIMA AS installation which are important to get fixed. OK - I think Jerry was looking at 1657 (which I think you meant instead of 1659?). Yes I wonder, though, if getting fail-over to work (or work better) will be a bit of a long journey, and whether we should do that in the next release? Maybe Jerry can give me a few hints where I have to look for the code which is reading from the input queue. Then I maybe find out whats going wrong in the failover case on the worker node. I have time for that tomorrow. On the other side I guess we are doing multiple release candidates anyway right ? Jörn
Re: doing 2.3.0 RC1 - tomorrow morning?
Jaroslaw Cwiklik wrote: *UIMA-1657 http://issues.apache.org/jira/browse/UIMA-1657 is finished*. I've added two new testcases to test failover URI with tcp and http Both seem to work. For some reason I can't submit changes to the svn from home. I will check this in tomorrow first thing in the morning. The changes I've put in only address support for URI's that contain failover string. I have not tested, nor I claim support for, the actual failover from one broker to the next if the connection fails Thanks :-) I will test it as soon as it is checked in. I hope there is only a small problem why the actual failover does not work. I will try to find the cause tomorrow. Jörn
Using failover in broker URL causes XML exception
Hi, in the deployment descriptor the broker URL is specified as failover:(tcp://10.45.2.100:61616,tcp://10.45.2.101:61616)?randomize=false and that causes on startup of the worker node the attached exception. Jörn org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 14 in XML document from URL [file:/tmp/UIMAdd2springOutput63279.xml] is invalid; nested exception is org.xml.sax.SAXParseException: Attribute value qBroker_failover_c_(tcp_c__ss_10.45.2.100_c_61616,tcp_c__ss_10.45.2.101_c_61616) of type ID must be a name. Caused by: org.xml.sax.SAXParseException: Attribute value qBroker_failover_c_(tcp_c__ss_10.45.2.100_c_61616,tcp_c__ss_10.45.2.101_c_61616) of type ID must be a name. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.validateDTDattribute(XMLDTDValidator.java:1427) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.addDTDDefaultAttrsAndValidate(XMLDTDValidator.java:1333) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleStartElement(XMLDTDValidator.java:1940) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:764) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1359) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2747) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:225) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283) at org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:76) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:351) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:303) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:280) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:131) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:147) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:173) at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:112) at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:79) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:101) at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:389) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:324) at org.springframework.context.support.FileSystemXmlApplicationContext.init(FileSystemXmlApplicationContext.java:93) at org.springframework.context.support.FileSystemXmlApplicationContext.init(FileSystemXmlApplicationContext.java:77) at org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.deploy(SpringContainerDeployer.java:434) at org.apache.uima.adapter.jms.service.UIMA_Service.deploy(UIMA_Service.java:165) at org.apache.uima.adapter.jms.service.UIMA_Service.main(UIMA_Service.java:387) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
Using failover in broker URL causes XML exception
Hi, in the deployment descriptor the broker URL is specified as failover:(tcp://10.45.2.100:61616,tcp://10.45.2.101:61616)?randomize=false and that causes on startup of the worker node the attached exception. Jörn org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 14 in XML document from URL [file:/tmp/UIMAdd2springOutput63279.xml] is invalid; nested exception is org.xml.sax.SAXParseException: Attribute value qBroker_failover_c_(tcp_c__ss_10.45.2.100_c_61616,tcp_c__ss_10.45.2.101_c_61616) of type ID must be a name. Caused by: org.xml.sax.SAXParseException: Attribute value qBroker_failover_c_(tcp_c__ss_10.45.2.100_c_61616,tcp_c__ss_10.45.2.101_c_61616) of type ID must be a name. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.validateDTDattribute(XMLDTDValidator.java:1427) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.addDTDDefaultAttrsAndValidate(XMLDTDValidator.java:1333) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.handleStartElement(XMLDTDValidator.java:1940) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java:764) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1359) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2747) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107) at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:225) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283) at org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:76) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:351) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:303) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:280) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:131) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:147) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:173) at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:112) at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:79) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:101) at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:389) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:324) at org.springframework.context.support.FileSystemXmlApplicationContext.init(FileSystemXmlApplicationContext.java:93) at org.springframework.context.support.FileSystemXmlApplicationContext.init(FileSystemXmlApplicationContext.java:77) at org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.deploy(SpringContainerDeployer.java:434) at org.apache.uima.adapter.jms.service.UIMA_Service.deploy(UIMA_Service.java:165) at org.apache.uima.adapter.jms.service.UIMA_Service.main(UIMA_Service.java:387) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at
Re: [jira] Commented: (UIMA-1643) UIMA AS client does not recover correctly when the connection to a broker fails
Jaroslaw Cwiklik wrote: Initially this is exactly what I thought of doing. But we need finer level of control. Dont want to be stuck in the AMQ send method until the broker becomes available. Instead the code will silently retry connection indefinitely similar to Spring Listener's waitUntilSuccessfull() In our system we plan to use a Pure Master Slave ActiveMQ Broker. In the case the Master fails the clients just reconnect to the Slave. More information can be found here: http://activemq.apache.org/pure-master-slave.html The broker URL for this configuration looks like this: failover://(tcp://masterhost:61616,tcp://slavehost:61616)?randomize=false If the code retires to connect it must be able to detect that the broker is not available, maybe the send method just throws an exception, which is then handled. Does non-blocking sending in case of an error also work if failover is used ? Jörn
Re: [jira] Commented: (UIMA-1643) UIMA AS client does not recover correctly when the connection to a broker fails
Jaroslaw Cwiklik wrote: As I understand it, when you use failover around the AMQ URL and the named broker(s) is/are not available, the send blocks. The latest AMQ release 5.3 has support for timeouts using this notation: failover:(tcp://primary:61616)?timeout=3000 This is a new release that I have not tried yet. Besides, we are releasing UIMA AS with AMQ 4.1.1 support and our code should be backwards compatible. Having said that, I had problems with correct failover behaviour with 4.1.1 while 5.2 worked fine. Ok, we use 5.3, so I will just add the timeout to the client (when this issue is closed) and deployment descriptor. Thanks, Jörn
Re: time for the frist release candidate
Marshall Schor wrote: I'm aware of one more change coming in tomorrow to the regEx annotator, and then, after that, I think we're ready to build uima, uima-as, and uima sandbox releases. I plan to do the final update to the release notes and tag the release, sometime tomorrow. Please let me know of any issues with this. Thanks! -Marshall +1 Jörn
Re: is there a release of the UIMA support for open-nlp that we can link to?
Marshall Schor wrote: I went to the opennlp home page and looked around for mentions of UIMA - didn't see any - but may have missed something. Is there documentation / downloads etc. that can be linked to at this point, or not yet? No there is no mention about the UIMA OpenNLP integration on the web site, but you could link to cvs. Jörn
Re: Cas Editor POM questions
Marshall Schor wrote: Marshall Schor wrote: While reviewing the Eclipse tooling, I noticed that the POM for the Cas Editor has a dependency on groupIdorg.eclipse.swt/groupId artifactIdorg.eclipse.swt.win32.win32.x86/artifactId If this dependency is removed, there are a lot of compile errors. But because this dependency is on something with win32 and x86 in the name, does it imply that the Cas Editor tool only runs on x86 / windows platforms? I found some stuff on the internet that uses the maven profile mechanism to switch the jar depending on the platform/os. I think that this setup, as it is now, probably works, without any of that, though. If you try and build this on other platforms, it should still build (because the x86/win/swt jar is only used for proper compiling, but isn't used in running (the scope is provided). And when you run, the right version of the jar is provided by the Eclipse environment the plugin is installed into, I think (not tested yet). Yes, exactly, it only needs it to compile, the correct version is then provided by eclipse. I think there is no need that change it. The Cas Editor should run on every platform for which an eclipse runtime exists. I usually test it on Ubuntu, OS X and once in a while on Windows. Jörn
Re: Cas Editor POM questions
Another question: I think the dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.5/version /dependency should have scopetest/scope - is this OK if I change this? I cannot recall the exact reason its done like this, I will find out if the scope can be changed to test. It has to do with the unit tests, they are a bit different. The Cas Editor has two kind of tests: a) Normal unit tests which are executed when its build (like the other unit tests in uima) b) Unit tests which must be run inside an eclipse instance. The latter once can right now only be manually started from eclipse. I do that once in a while, and it should be done for the release on all supported platforms (Linux, OS X, Windows). To make these tests work the manifest must at least contain junit as an optional dependency (but that should be configured correctly). The execution of these tests is always a bit tricky, maybe I just changed the scope to compile and forgot to switch it back to test. And then there is maven problem, I do not know how to configure two different test source folders, maybe you know. I googled a bit around bit for me it looks like its only possible to have one test source folder. Jörn
UIMA-AS error handling in case an exception is thrown from CM.next method
Hi everyone, I might found a problem in the error handling when an exception is thrown from the CasMultiplier.next method before getEmptyCas was called. UIMA-AS prints out the stack trace of the exception from the next method and afterwards it prints out the following exception stack trace, is that expected behavior ? Jörn Here is the exception stack trace: CASAdminException: Can't flush CAS, flushing is disabled. at org.apache.uima.cas.impl.CASImpl.reset(CASImpl.java:869) at org.apache.uima.util.CasPool.releaseCas(CasPool.java:224) at org.apache.uima.resource.impl.CasManager_impl.releaseCas(CasManager_impl.java:141) at org.apache.uima.cas.AbstractCas_ImplBase.release(AbstractCas_ImplBase.java:35) at org.apache.uima.cas.impl.CASImpl.release(CASImpl.java:3591) at org.apache.uima.cas.impl.CASImpl.release(CASImpl.java:3589) at org.apache.uima.aae.controller.BaseAnalysisEngineController.dropCAS(BaseAnalysisEngineController.java:1040) at org.apache.uima.aae.controller.BaseAnalysisEngineController.dropCAS(BaseAnalysisEngineController.java:1273) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.dropCAS(AggregateAnalysisEngineController_impl.java:302) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.sendReplyToRemoteClient(AggregateAnalysisEngineController_impl.java:1832) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.replyToClient(AggregateAnalysisEngineController_impl.java:1943) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.finalStep(AggregateAnalysisEngineController_impl.java:1567) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.abortProcessingCas(AggregateAnalysisEngineController_impl.java:971) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.process(AggregateAnalysisEngineController_impl.java:1010) at org.apache.uima.aae.error.handler.ProcessCasErrorHandler.handleError(ProcessCasErrorHandler.java:521) at org.apache.uima.aae.error.ErrorHandlerChain.handle(ErrorHandlerChain.java:57) at org.apache.uima.aae.handler.input.ProcessResponseHandler.handleProcessResponseWithException(ProcessResponseHandler.java:535) at org.apache.uima.aae.handler.input.ProcessResponseHandler.handle(ProcessResponseHandler.java:642) at org.apache.uima.aae.handler.HandlerBase.delegate(HandlerBase.java:149) at org.apache.uima.aae.handler.input.ProcessRequestHandler_impl.handle(ProcessRequestHandler_impl.java:951) at org.apache.uima.aae.spi.transport.vm.UimaVmMessageListener.onMessage(UimaVmMessageListener.java:107) at org.apache.uima.aae.spi.transport.vm.UimaVmMessageDispatcher$1.run(UimaVmMessageDispatcher.java:70) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) CASAdminException: Can't flush CAS, flushing is disabled. at org.apache.uima.cas.impl.CASImpl.reset(CASImpl.java:869) at org.apache.uima.util.CasPool.releaseCas(CasPool.java:224) at org.apache.uima.resource.impl.CasManager_impl.releaseCas(CasManager_impl.java:141) at org.apache.uima.cas.AbstractCas_ImplBase.release(AbstractCas_ImplBase.java:35) at org.apache.uima.cas.impl.CASImpl.release(CASImpl.java:3591) at org.apache.uima.cas.impl.CASImpl.release(CASImpl.java:3589) at org.apache.uima.aae.controller.BaseAnalysisEngineController.dropCAS(BaseAnalysisEngineController.java:1040) at org.apache.uima.aae.controller.BaseAnalysisEngineController.dropCAS(BaseAnalysisEngineController.java:1273) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.dropCAS(AggregateAnalysisEngineController_impl.java:302) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.sendReplyToRemoteClient(AggregateAnalysisEngineController_impl.java:1832) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.replyToClient(AggregateAnalysisEngineController_impl.java:1943) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.finalStep(AggregateAnalysisEngineController_impl.java:1567) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.abortProcessingCas(AggregateAnalysisEngineController_impl.java:971) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.process(AggregateAnalysisEngineController_impl.java:1010) at org.apache.uima.aae.error.handler.ProcessCasErrorHandler.handleError(ProcessCasErrorHandler.java:521) at org.apache.uima.aae.error.ErrorHandlerChain.handle(ErrorHandlerChain.java:57) at org.apache.uima.aae.handler.input.ProcessResponseHandler.handleProcessResponseWithException(ProcessResponseHandler.java:535) at org.apache.uima.aae.handler.input.ProcessResponseHandler.handle(ProcessResponseHandler.java:642) at
BaseAnalysisEngineController line 1742 IndexOutOfBoundsException
Hi, I got an IndexOutOfBoundsException, I think there is a concurrency problem at the mentioned place. Jörn Here is the stack trace: Caused by: java.lang.IndexOutOfBoundsException: Index: 2, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at org.apache.uima.aae.controller.BaseAnalysisEngineController.stop(BaseAnalysisEngineController.java:1741) at org.apache.uima.aae.controller.BaseAnalysisEngineController.stop(BaseAnalysisEngineController.java:1707) at org.apache.uima.aae.controller.AggregateAnalysisEngineController_impl.stop(AggregateAnalysisEngineController_impl.java:2753) at org.apache.uima.aae.controller.BaseAnalysisEngineController.terminate(BaseAnalysisEngineController.java:1967) at org.apache.uima.aae.controller.BaseAnalysisEngineController.terminate(BaseAnalysisEngineController.java:1940) at org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.initializeContainer(SpringContainerDeployer.java:313) at org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.deploy(SpringContainerDeployer.java:390) ... 7 more
Re: Issues not closed for 2.3.0 release
Marshall Schor wrote: Jörn Kottmann wrote: On Oct 18, 2009, at 10:22 PM, Marshall Schor wrote: (Joern) UIMA-1619 https://issues.apache.org/jira/browse/UIMA-1619 Clarify that a Cas Editor Project is required to use the Cas Editor in the documentation https://issues.apache.org/jira/browse/UIMA-1619 I will close this issue next week, Jörn Danke! I can also do the first pass at this, and then you could just check it - if it's ok with you? Yes that would be nice, thanks. Otherwise if you don't want to do it, I think I will have it done until Wednesday. Jörn
Re: UIMA-AS client dependencies
Marshall Schor wrote: I took a look at the dependencies for the uimaj-as-activemq project, using the tools: mvn dependency:analyze and mvn dependency:tree and here's what I found. 1) uimaj-examples is a testing dependency - I'll change the scope. 2) There are some dependencies coded in what appears to be a strange way. Here's an example: dependency groupIdorg.apache.activemq/groupId artifactIdactivemq-optional/artifactId version4.1.1/version exclusions exclusion groupIdorg.apache.activemq/groupId artifactIdactivemq-optional/artifactId /exclusion /exclusions /dependency This says include org.apache.activemq:activemq-optional:jar:4.1.1:compile, but exclude org.apache.activemq:activemq-optional I think what this was attempting to do was to exclude activemq-optional, which was being brought in as a transitive dependency. This doesn't work, as evidenced by using mvn dependency:tree, so I'm removing it. The xstream dependency turns out to be just a testcase dependency, so I'm changing that scope to test. I ran mvn dependency:tree -Dverbose and got a complete listing of the dependencies, and after review the only one I think I can safely exclude is the activemq-web-demo. I'll make a jira for this. -Marshall Thanks Marshall good job. The ActiveMQ guys say that in a minimal configuration you only need these jars: * activemq-core.jar * commons-logging.jar * geronimo-spec-jms.jar * geronimo-spec-jta.jar * geronimo-spec-j2ee-management.jar Optional the spring.jar is needed for xml based configuration and the persistence jar for persistence. The required jars are combined in an activemq.jar file. Do you think we can just take this activemq.jar file and combine it with the uima jars for a client ? If so we might want to say that in our documentation, because it makes it easier to get started with UIMA-AS. Jörn http://activemq.apache.org/version-5-initial-configuration.html
UIMA-AS uses printStackTrace()
Hi, the UIMA-AS code uses printStackTrace() here and there once in a while. The problem with printStackTrace() is that it does not print the date and it is also difficult to find in which line the exception was actually handled because it only prints out the exception itself. I suggest that we just do a search for printStackTrace() and replace all occurrences with a log statement. Jörn
UIMA-AS client dependencies
Hi everyone, I have a small UIMA AS clients which is build with maven, it depends on uimaj-core, uimaj-as-core and uimj-as-activemq. The list of dependencies is very long and I wonder it that is really necessary, since I have to run this little tool on a server the classpath in my start script gets a mile long. Would it be possible to reduce the amount of dependencies ? e.g. uimaj-examples could be a good candidate to remove Jörn
Re: UIMA-AS client dependencies
Marshall Schor wrote:
Jörn Kottmann wrote:
Hi everyone,
I have a small UIMA AS clients which is build with maven,
it depends on uimaj-core, uimaj-as-core and uimj-as-activemq.
The list of dependencies is very long and I wonder it
that is really necessary, since I have to run
this little tool on a server the classpath
in my start script gets a mile long.
You might be able to use the new bootstrap loader (see the
uimaj-bootstrap project) to reduce the class path.
Would it be possible to reduce the amount
of dependencies ?
Probably. We've tried, but have gotten into trouble, for instance, when
we launched a uima-as client with only some of the active-mq jars, only
to find that under some error conditions (e.g., the broker failing), the
behavior became unstable. So it would have to be carefully investigated.
e.g. uimaj-examples could be a good candidate to remove
I tried removing it (in Eclipse, from the build path) and that seemed to
not cause any problems, so it's probably a good candidate to remove.
There are optional dependencies which are made non-optional
through maven, because they are just normal dependencies.
Here is a list taken from uimaj-as-activemq, maybe we can handle
that a bit different, and I really doubt that we need them all.
dependency
groupIdcommons-beanutils/groupId
artifactIdcommons-beanutils/artifactId
version1.6.1/version
/dependency
dependency
groupIdcommons-collections/groupId
artifactIdcommons-collections/artifactId
version2.1/version
/dependency
dependency
groupIdcommons-dbcp/groupId
artifactIdcommons-dbcp/artifactId
version1.2/version
/dependency
dependency
groupIdcommons-pool/groupId
artifactIdcommons-pool/artifactId
version1.2/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId
version1.0/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-j2ee-jacc_1.0_spec/artifactId
version1.0/version
/dependency
dependency
groupIdactivemq/groupId
artifactIdjmdns/artifactId
version1.0-RC2/version
/dependency
dependency
groupIdlog4j/groupId
artifactIdlog4j/artifactId
version1.2.12/version
/dependency
dependency
groupIdmx4j/groupId
artifactIdmx4j-remote/artifactId
version2.1.1/version
/dependency
dependency
groupIdmx4j/groupId
artifactIdmx4j-tools/artifactId
version2.1.1/version
/dependency
dependency
groupIdorg.apache.uima/groupId
artifactIduimaj-as-core/artifactId
version${uimaj-as-release-version}/version
scopecompile/scope
/dependency
dependency
groupIdorg.apache.uima/groupId
artifactIduimaj-as-jms/artifactId
version${uimaj-as-release-version}/version
scopecompile/scope
/dependency
dependency
groupIdcommons-httpclient/groupId
artifactIdcommons-httpclient/artifactId
version2.0.1/version
/dependency
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdjetty/artifactId
version6.0.1/version
/dependency
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdjetty-util/artifactId
version6.0.1/version
/dependency
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdservlet-api-2.5/artifactId
version6.0.1/version
/dependency
dependency
groupIdxmlpull/groupId
artifactIdxmlpull/artifactId
version1.1.3.4d_b4_min/version
/dependency
dependency
groupIdcom.thoughtworks.xstream/groupId
artifactIdxstream/artifactId
version1.2.2/version
/dependency
dependency
groupIdorg.apache.derby/groupId
artifactIdderby/artifactId
version10.1.1.0/version
/dependency
dependency
groupIdorg.apache.xbean/groupId
artifactIdxbean-spring/artifactId
version2.8/version
/dependency
Jörn
Re: Change to build process for assemblies
Marshall Schor wrote: RAT will fail the build with a strange error message ( Too many unapproved licenses: nnn) if it finds a file with missing license headers. The nnn represents the number of problem files that need fixing or excluding. The RAT report lists all these in target/rat.txt of the distr project. Updated my workspace to get your changes and now mvn install in the uimaj-distr project fails with this error message, in my case nnn is 19. How can I see which files are causing the problem ? Jörn
Re: Change to build process for assemblies
When building (mvn install in uimaj-distr) on Unix I get lots of
warnings towards the
end maybe, there is something incorrect:
[INFO] [assembly:single {execution: default}]
[INFO] Reading assembly descriptor: src/main/assembly/bin.xml
[INFO] Reading assembly descriptor: src/main/assembly/src.xml
[INFO] Building tar :
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-bin.tar.gz
[WARNING] Assembly file:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-bin.tar.gz
is not a regular file (it may be a directory). It cannot be attached to
the project build for installation or deployment.
[INFO] Building zip:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-bin.zip
[WARNING] Assembly file:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-bin.zip
is not a regular file (it may be a directory). It cannot be attached to
the project build for installation or deployment.
[INFO] uima-as-2.3.0-incubating-SNAPSHOT/ already added, skipping
[INFO] Building tar :
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-src.tar.gz
[INFO] uima-as-2.3.0-incubating-SNAPSHOT/ already added, skipping
[WARNING] Assembly file:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-src.tar.gz
is not a regular file (it may be a directory). It cannot be attached to
the project build for installation or deployment.
[INFO] uima-as-2.3.0-incubating-SNAPSHOT/ already added, skipping
[INFO] Building zip:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-src.zip
[INFO] uima-as-2.3.0-incubating-SNAPSHOT/ already added, skipping
[WARNING] Assembly file:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-src.zip
is not a regular file (it may be a directory). It cannot be attached to
the project build for installation or deployment.
Jörn
Re: Change to build process for assemblies
Despite these warnings the distribution gets created, but it has the wrong
name uima-as-2.3.0-incubating-SNAPSHOT-xxx but should be
uima-2.3.0-incubating-SNAPSHOT-xxx.
Jörn
Jörn Kottmann wrote:
When building (mvn install in uimaj-distr) on Unix I get lots of
warnings towards the
end maybe, there is something incorrect:
[INFO] [assembly:single {execution: default}]
[INFO] Reading assembly descriptor: src/main/assembly/bin.xml
[INFO] Reading assembly descriptor: src/main/assembly/src.xml
[INFO] Building tar :
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-bin.tar.gz
[WARNING] Assembly file:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-bin.tar.gz
is not a regular file (it may be a directory). It cannot be attached
to the project build for installation or deployment.
[INFO] Building zip:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-bin.zip
[WARNING] Assembly file:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-bin.zip
is not a regular file (it may be a directory). It cannot be attached
to the project build for installation or deployment.
[INFO] uima-as-2.3.0-incubating-SNAPSHOT/ already added, skipping
[INFO] Building tar :
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-src.tar.gz
[INFO] uima-as-2.3.0-incubating-SNAPSHOT/ already added, skipping
[WARNING] Assembly file:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-src.tar.gz
is not a regular file (it may be a directory). It cannot be attached
to the project build for installation or deployment.
[INFO] uima-as-2.3.0-incubating-SNAPSHOT/ already added, skipping
[INFO] Building zip:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-src.zip
[INFO] uima-as-2.3.0-incubating-SNAPSHOT/ already added, skipping
[WARNING] Assembly file:
/home/joern/uima-dev3/uimaj-distr/target/uima-as-2.3.0-incubating-SNAPSHOT-src.zip
is not a regular file (it may be a directory). It cannot be attached
to the project build for installation or deployment.
Jörn
Re: UIMA report is due
Tommaso Teofili wrote: I've added also Tika to the projects UIMA is now integrated with. Tommaso New integration with other Apache projects (such as Lucas and Tika Annotator - integrations with Apache Lucene search and Tika). And also Apache Camel to drive UIMA AS processing. Jörn
Re: UIMA report is due
Tommaso Teofili wrote: I've just updated the wiki. Let me know if there is something else to mention that comes in your mind. The Configurable Feature Editor, including documentation, was refreshed, and will be included in the next release. Isn't it called Configurable Feature Extractor ? Jörn
Re: [jira] Closed: (UIMA-1604) Add ShutdownHook to Uima As Service Wrapper
Jerry Cwiklik (JIRA) wrote: [ https://issues.apache.org/jira/browse/UIMA-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1604. --- Resolution: Fixed Instrumented UIMA_Service with ShutdownHook to run quiesce and stop on kill signal Thanks Jerry, that makes things easier for me. Jörn
Re: Cas Editor Eclipse naming
Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: I was testing the Cas Editor plugin, as a new naive user. There is nothing in the documentation that says to create one or more new projects, of a special type, for use by the Cas Editor - so I was trying to use a plain Java project, and of course, nothing was working. Part of the problem is that the label for the Cas Editor things in Eclipse is NLP. I did not recognize or associate that with either UIMA or the Cas Editor. (So, for instance, if you say in Eclipse, menu - file - new - other you get a pick list with lots of things, including one labeled NLP. Same with menu - window - show view - other same NLP entry.) I think we should rename this categorization tag to something that uses the words Uima, and CasEditor - maybe it should be a 2 level categorization, the top one being UIMA (which already exists, and is used by the Component Descriptor Editor), and a then CasEditor. WDYT? (What do you think)? You are right Marshall, they should be renamed to something which is appropriate now, the naming is a left over from the first days of the Cas Editor. The reason they were not renamed yet for the 2.3.0 release is that we should start a bigger refactoring effort to remove the project model from the Cas Editor plugin and create a new plugin based on it which helps users developing UIMA applications. A while back we decided to do this after the 2.3.0 release. Changing the names is not a big deal, but we should take into account that they might be changed again for the release after 2.3.0. +1 for the naming you suggested. If it's quick to do, maybe we should rename this for the 2.3.0 release. In any case, I think we need a paragraph in the documentation at the beginning to tell the user he needs to create a Cas Editor project using the wizard, before he can use the Cas Editor - that it only works in that context. The names are defined in the plugin.xml file, renaming is quick, but I am not sure if it is possible to define a UIMA category twice. The UIMA category is defined in the uimaj-ep-configurator plugin: category name=UIMA id=org.apache.uima.cpe.UIMA /category and in the Cas Editor it is defined like this: category name=NLP id=org.apache.uima.caseditor.ui.wizards / and for the views category id=org.apache.uima.caseditor.ui.views name=NLP / we could simply rename NLP - to UIMA, but then we might have two categories with UIMA. To reuse the org.apache.uima.cpe.UIMA category I think the Cas Editor must depend on uimaj-ep-configurator project. What do you think about renaming NLP to Cas Editor and the Cas Editor project from Project to Cas Editor Project ? Another option in my opinion is to move the UIMA category to the runtime project, maybe thats the right thing to do. Jörn
Re: Clarifying when the Cas Editor needs the special nature, and when it needs the Corpus Explorer
Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: The Cas Editor seems to be enabled by two different things in Eclipse. One is the Corpus Explorer view, which among other things, enables certain right-click menu items. The other is the natureorg.apache.uima.caseditor.NLPProject/nature, although I'm not sure what it enables. Actually the Corpus Explorer only works together with projects which have the NLPProject nature. Non NLPProject nature projects are only displayed like they would be in the eclipse navigator view. The special right-click menu items and project structure is only available in NLPProject nature projects. Hmmm, I tried the following: In a new workspace, I created 2 projects - a java project and an NLP project. The java project did not have the NLPProject nature. Then I switched to the Corpus Explorer, and found when I right-clicked the two projects and picked properties, I saw the panel with Processor Folders, Corpus Folders, etc. (Even for the project that didn't have the NLP Project nature) So I guess that the NLP Nature isn't required to show this. But it may be required for something else For the project without the NLP nature you should not have seen the panels in the properties menu, I also could not reproduce the behavior you observed. Are you sure that your java project has not the nlp nature ? (You can check that manually in the .project file) Jörn
Re: Cas Editor Eclipse naming
Marshall Schor wrote: I was testing the Cas Editor plugin, as a new naive user. There is nothing in the documentation that says to create one or more new projects, of a special type, for use by the Cas Editor - so I was trying to use a plain Java project, and of course, nothing was working. Part of the problem is that the label for the Cas Editor things in Eclipse is NLP. I did not recognize or associate that with either UIMA or the Cas Editor. (So, for instance, if you say in Eclipse, menu - file - new - other you get a pick list with lots of things, including one labeled NLP. Same with menu - window - show view - other same NLP entry.) I think we should rename this categorization tag to something that uses the words Uima, and CasEditor - maybe it should be a 2 level categorization, the top one being UIMA (which already exists, and is used by the Component Descriptor Editor), and a then CasEditor. WDYT? (What do you think)? You are right Marshall, they should be renamed to something which is appropriate now, the naming is a left over from the first days of the Cas Editor. The reason they were not renamed yet for the 2.3.0 release is that we should start a bigger refactoring effort to remove the project model from the Cas Editor plugin and create a new plugin based on it which helps users developing UIMA applications. A while back we decided to do this after the 2.3.0 release. Changing the names is not a big deal, but we should take into account that they might be changed again for the release after 2.3.0. +1 for the naming you suggested. Jörn
Re: Aligning the Cas Editor nature name
Marshall Schor wrote: Should the nature for enabling the Cas Editor, natureorg.apache.uima.caseditor.NLPProject/nature be better specified as org.apache.uima.CasEditor? That would break backward compatibility and since I planned to completely refactor/rewrite the project model code I would prefer to rename it then after the 2.3.0 release. Here's my thinking: UIMA in general is used for unstructured information - which may be text / language related, or may be other kinds of things, such as image data, audio recordings, etc., not related to NLP - Natural Language Processing. The Cas Editor (I think) is able to look at and edit CASes that may have nothing to do with Natural Language Processing (is this right?). Yes, I planned to add support for other SOFA types than plain/text e.g. for images. Image support together with multi SOFA support could be used to inspect/display a CAS which contains a scanned page as image and the OCRed text. Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency Can you please commit the updated versions ? Done. Thanks for the reminder :-). The main uimaj pom is updated to no longer include the alternative Eclipse repo - now only maven central repo and the incubator repositories are included. Just tried to build UIMA on a fresh machine over at a friends place, but it could not find various eclipse plugins. Does that has to do with that change ? I would guess so - I ran mvn dependency:tree on many of the ones I changed to insure it could still find things, but maybe I missed one or 2 - could you post details? No, I think uimaj-ep-debug failed, but I do not have more details, the cas editor also could not be build. If that does not help, I can try to reproduce the error on my machine and post detailed information. Jörn Well, now that I try again, everything is broken... It fails for me, too. I tried various things to fix this, and could get the basic uimaj-ep-debug plugin to find the one Eclipse component in the maven central repo that it depends on, but that plugin has lots of dependencies, and they cannot be found in the maven central repo. So I don't think we've gotten to the bottom of this issue. I'm going to revert back to using the alternate eclipse repo, and at least get things working again (I hope). Sorry for breaking the build - but something was hiding this breakage from me before. What do you think about explicitly excluding org.eclipse.equinox.app from the org.eclipse.core.runtime dependency ? It would then be declared like this: dependency groupIdorg.eclipse.core/groupId artifactIdruntime/artifactId version[3.3.0.0,4.0.0)/version scopeprovided/scope exclusions exclusion groupIdorg.eclipse.equinox/groupId artifactIdapp/artifactId /exclusion /exclusions /dependency Not that I would prefer this way, but maybe it is better than having a build which fails under certain circumstances. Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Marshall Schor wrote: Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency Can you please commit the updated versions ? As said before the eclipse runtime provides all dependencies, so it does not matter against which we compile as long as it is the minimal supported version (3.3.0), otherwise APIs could be used which are not available in 3.3.0. Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency Can you please commit the updated versions ? Done. Thanks for the reminder :-). The main uimaj pom is updated to no longer include the alternative Eclipse repo - now only maven central repo and the incubator repositories are included. Just tried to build UIMA on a fresh machine over at a friends place, but it could not find various eclipse plugins. Does that has to do with that change ? Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Maybe we can use another version of eclipse as dependency. I think this is definitely worth investigating. It's quite possible that later version of Eclipse jar uploading to the central maven repo have found a way around this. We could update to eclipse 3.4. I also noticed that our eclipse plugins depend on different eclipse version, would it be an advantage to only depend on one ? I don't think there's any advantage. What happens I think, is that these jars are used to make the compile step work, but at runtime, these jars are all provided by the particular Eclipse environment. Yes, but maven downloads both versions of eclipse, using only one version makes the initial build faster. Jörn
Re: Lucas packaging of dependencies
Rico Landefeld wrote: I don't know how this is supposed to work. I removed the Ant task which creates the lib directory because I've thought that this is handled in the parent POM like the rest of the PEAR packaging, but this is not the case. Should I provide a patch which re includes the lib directory creation and the missing google-collection entry in the notice file? Beside that, are there good default values for Lucas ? I think it should be possible to define a mapping file which indexes the Document Annotation and uses a standard tokenizer. Is there a good default location where the index could be written to ? Jörn
Re: Lucas packaging of dependencies
Marshall Schor wrote: Rico Landefeld wrote: I think its difficult to define a default index directory, because this strongly depends on the usage scenario. Maybe we could try to write the index into the current directory.Any better ideas? How about a temp directory (just as an initial default) ? Do you know a good candidate ? Would be nice if we can find one which works for unix and windows. Jörn
FsVariables docbook build problem on Unix
When building the FsVariables on Unix I get the following error message: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An Ant BuildException has occured: The following error occurred while executing this line: /home/joern/uima-dev3/uima-docbook-tool/build/build-docbook.xml:29: The following error occurred while executing this line: /home/joern/uima-dev3/uima-docbook-tool/build/common-properties-per-book.xml:80: /home/joern/uima-dev3/FsVariables/docbook/fsVariablesUserGuide/images not found. The build_documentation.xml contains the following line: property name=book_name value=fsVariablesUserGuide/ If value is changed to FsVariablesUserGuide the image folder can be found. Can I check-in the correction ? Jörn
Lucas artifactId does not match folder name in svn
The maven eclipse plugin expects that the folder name of the project matches the artifactId, but that is not the case for Lucas. The artifactId is lucas and the folder name is Lucas. On Unix eclipse cannot find the lucas project, because its named Lucas. I suggest that we either change the folder name or the artifactId to be identical. Jörn
Re: [jira] Created: (UIMA-1567) Maven build: add prerequisites to uimaj to specify minimum Maven release level
Good idea, now I hope our build fails with a proper error message when its build with an old maven version. Jörn On Sep 12, 2009, at 11:06 AM, Marshall Schor (JIRA) wrote: Maven build: add prerequisites to uimaj to specify minimum Maven release level Key: UIMA-1567 URL: https://issues.apache.org/jira/browse/UIMA-1567 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3S, 2.3, 2.3AS -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r807253 - in /incubator/uima/sandbox/trunk/Lucas: DISCLAIMER doc/ doc/pdf/ doc/pdf/LuceneCASConsumerUserGuide.pdf pom.xml
Why did you check in the user guide as PDF ? Jörn sc...@apache.org wrote: Author: schor Date: Mon Aug 24 14:53:26 2009 New Revision: 807253 URL: http://svn.apache.org/viewvc?rev=807253view=rev Log: [UIMA-1501] Added: incubator/uima/sandbox/trunk/Lucas/DISCLAIMER incubator/uima/sandbox/trunk/Lucas/doc/ incubator/uima/sandbox/trunk/Lucas/doc/pdf/ incubator/uima/sandbox/trunk/Lucas/doc/pdf/LuceneCASConsumerUserGuide.pdf (with props) Modified: incubator/uima/sandbox/trunk/Lucas/pom.xml Added: incubator/uima/sandbox/trunk/Lucas/DISCLAIMER URL: http://svn.apache.org/viewvc/incubator/uima/sandbox/trunk/Lucas/DISCLAIMER?rev=807253view=auto == --- incubator/uima/sandbox/trunk/Lucas/DISCLAIMER (added) +++ incubator/uima/sandbox/trunk/Lucas/DISCLAIMER Mon Aug 24 14:53:26 2009 @@ -0,0 +1,7 @@ +Apache UIMA is an effort undergoing incubation at The Apache Software +Foundation (ASF). Incubation is required of all newly accepted projects +until a further review indicates that the infrastructure, communications, +and decision making process have stabilized in a manner consistent with +other successful ASF projects. While incubation status is not necessarily +a reflection of the completeness or stability of the code, it does +indicate that the project has yet to be fully endorsed by the ASF. Added: incubator/uima/sandbox/trunk/Lucas/doc/pdf/LuceneCASConsumerUserGuide.pdf URL: http://svn.apache.org/viewvc/incubator/uima/sandbox/trunk/Lucas/doc/pdf/LuceneCASConsumerUserGuide.pdf?rev=807253view=auto == Binary file - no diff available. Propchange: incubator/uima/sandbox/trunk/Lucas/doc/pdf/LuceneCASConsumerUserGuide.pdf -- svn:mime-type = application/octet-stream Modified: incubator/uima/sandbox/trunk/Lucas/pom.xml URL: http://svn.apache.org/viewvc/incubator/uima/sandbox/trunk/Lucas/pom.xml?rev=807253r1=807252r2=807253view=diff == --- incubator/uima/sandbox/trunk/Lucas/pom.xml (original) +++ incubator/uima/sandbox/trunk/Lucas/pom.xml Mon Aug 24 14:53:26 2009 @@ -28,29 +28,20 @@ nameApache UIMA - Lucene CAS Indexer/name version2.3.0-incubating-SNAPSHOT/version descriptionWrites information contained in CAS objects to fields of a Lucene search index; mapping is done in a mapping file./description - urlhttp://incubator.apache.org/uima/url - licenses - license - nameThe Apache Software License, Version 2.0/name - urlhttp://www.apache.org/licenses/LICENSE-2.0.txt/url - distributionrepo/distribution - /license - /licenses - scm - urlhttp://svn.apache.org/viewvc/incubator/uima/url - /scm + + parent +groupIdorg.apache.uima/groupId +artifactIduimaj/artifactId +version2.3.0-incubating-SNAPSHOT/version !-- this comment is a flag for changeVersion -- +relativePath../uimaj/relativePath + /parent + properties componentIdLuceneCASIndexer/componentId - /properties + /properties + build plugins - plugin - artifactIdmaven-compiler-plugin/artifactId - configuration - source1.5/source - target1.5/target - /configuration - /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId @@ -189,7 +180,6 @@ plugin groupIdorg.apache.uima/groupId artifactIdPearPackagingMavenPlugin/artifactId - version2.3.0-incubating-SNAPSHOT/version extensionstrue/extensions executions execution @@ -216,18 +206,9 @@ /execution /executions /plugin - plugin - groupIdorg.apache.maven.plugins/groupId - artifactIdmaven-compiler-plugin/artifactId - - configuration - source1.5/source - target1.5/target - /configuration - - /plugin /plugins /build + dependencies dependency
Re: [jira] Created: (UIMA-1551) Lucas PearPackagingMavenPlugin PEAR classpath is incorrect
Jörn Kottmann (JIRA) wrote: Lucas PearPackagingMavenPlugin PEAR classpath is incorrect -- Key: UIMA-1551 URL: https://issues.apache.org/jira/browse/UIMA-1551 Project: UIMA Issue Type: Bug Components: Sandbox-Lucas Reporter: Jörn Kottmann Assignee: Rico Landefeld Fix For: 2.3S The classpath entry says currently: classpath !-- PEAR file component classpath settings -- $main_root/lib/cglib-nodep-2.1_3.jar;$main_root/lib/google-collect-snapshot-20080530.jar;$main_root/lib/log4j-1.2.14.jar;$main_root/lib/lucene-core-2.4.0.jar;$main_root/lib/lucene-snowball-2.4.0.jar /classpath Which is incorrect because, Lucas does not depend anymore on the google-collections snapshot and lucene 2.4.0. Maybe we should consider opening a jira issue to improve the PearPackagingMavenPlugin to automatically create the classpath. Jörn
Re: Build error after updating to latest uimaj/pom.xml (rev. 807808)
Tommaso Teofili wrote: no particular difficulty in my opinion: you only have to download the archive from maven.apache.org and, eventually, change your system path to new Maven location. However, as Jason Van Zyl stated in the last JUG meeting here in Rome, Maven is on its way towards 3.0 release and newer Maven versions begin to get some features of the upcoming release (but personally I don't know which ones). Tommaso Yes, but it is still annoying since 2.0.9 is the default on many installed systems. Jörn
Re: Build error after updating to latest uimaj/pom.xml (rev. 807808)
Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Tommaso Teofili wrote: yes, there are many changes from 2.0.9, you could try with newest 2.2.1. I have no problem with both 2.1.0 and 2.2.1 on MacOS X 10.5, but get the same error Jorn gets with maven 2.0.9. Tommaso Thanks Tommaso, for the investigation ! I'm on 2.2, and saw a bunch of messages that 2.1 is not a good level (unless I'm confusing this with something else) - so I encourage everyone to migrate to 2.2.x. Sure I can update to 2.2.x, but I do not appreciate the change because OS X 10.5 and Ubuntu 9.10 both are shipped with maven 2.0.9. For me that sounds like many users will run into this issue. What do we get anything that is worth depending on 2.2.x ? Good question. I think some dependencies have been creeping in... Before going down the path of trying to find all of these, how hard is it to get/use the 2.2.x maven on these systems? For Ubuntu I downloaded maven 2.2.1 and placed it in the home folder, then I updated the .profile to place it on the path before the already installed maven. The .profile now has this additional entry: PATH=$HOME/maven/bin:$PATH Jörn
Re: Build error after updating to latest uimaj/pom.xml (rev. 807808)
Marshall Schor wrote: Tommaso Teofili wrote: yes, there are many changes from 2.0.9, you could try with newest 2.2.1. I have no problem with both 2.1.0 and 2.2.1 on MacOS X 10.5, but get the same error Jorn gets with maven 2.0.9. Tommaso Thanks Tommaso, for the investigation ! I'm on 2.2, and saw a bunch of messages that 2.1 is not a good level (unless I'm confusing this with something else) - so I encourage everyone to migrate to 2.2.x. Sure I can update to 2.2.x, but I do not appreciate the change because OS X 10.5 and Ubuntu 9.10 both are shipped with maven 2.0.9. For me that sounds like many users will run into this issue. What do we get anything that is worth depending on 2.2.x ? Jörn
Re: Lucas NOTICE file
Thilo Goetz wrote: The NOTICE file for Lucas currently does not list any external dependencies. However, looking at Lucas after it's been built, it seems to me we'll be shipping the google-collections.jar. The google collections jars is in most places just use to get an empty iterator, and in two places to build a map. I would be +1 not using it. Jörn
Projects are not synchronized after building
Hi, after building uima there are lots of empty src/main/resource/META-INF folders created in different projects. Can these be added to svn:ignore ? After building the docbook there are .db files created, why these are checked in ? Must they be checked in again when they change during the build ? Could we ignore these files, since they are generated ? Jörn
Build error after updating to latest uimaj/pom.xml (rev. 807808)
After updating to the newest uimaj/pom.xml file the build fails, with the following error message: jo...@karkand:~/uima-dev3/uimaj$ mvn -e install + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Apache UIMA Java SDK [INFO] Apache UIMA Utility Classes For JUnit Tests [INFO] Apache UIMA Java Framework Core [INFO] Apache UIMA - Java Vinci Transport Library [INFO] Apache UIMA Java Vinci Adapter [INFO] Apache UIMA Java Collection Processing Engine [INFO] Apache UIMA Java Framework - Document Annotation [INFO] Apache UIMA Java SDK Tools [INFO] Apache UIMA Java SDK Examples [INFO] Apache UIMA Java SOAP Adapter [INFO] Apache UIMA Utility Classes For Component JUnit Tests [INFO] Apache UIMA Java SDK common Eclipse plugin settings [INFO] Apache UIMA Debug Eclipse Plugin [INFO] Apache UIMA JCasGen Eclipse Plugin [INFO] Apache UIMA Configurator Eclipse Plugin [INFO] Apache UIMA PEAR Packager Eclipse Plugin [INFO] Apache UIMA Cas Editor Eclipse Plugin [INFO] Apache UIMA Runtime Plugin [INFO] Apache UIMA - PearPackagingMavenPlugin [INFO] Apache UIMA internal Tools [INFO] [INFO] Building Apache UIMA Java SDK [INFO]task-segment: [install] [INFO] [FATAL ERROR] org.codehaus.plexus.component.configurator.BasicComponentConfigurator#configureComponent(...) caused a linkage error (java.lang.NoSuchMethodError) and may be out-of-date. Check the realms: [FATAL ERROR] Plugin realm = app0.child-container[org.apache.maven.plugins:maven-antrun-plugin] urls[0] = file:/home/joern/.m2/repository/org/apache/maven/plugins/maven-antrun-plugin/1.3/maven-antrun-plugin-1.3.jar urls[1] = file:/home/joern/.m2/repository/ant-contrib/ant-contrib/1.0b3/ant-contrib-1.0b3.jar urls[2] = file:/home/joern/.m2/repository/ant/ant/1.5/ant-1.5.jar urls[3] = file:/home/joern/.m2/repository/org/apache/ant/ant/1.7.1/ant-1.7.1.jar urls[4] = file:/home/joern/.m2/repository/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar urls[5] = file:/home/joern/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar [FATAL ERROR] Container realm = plexus.core urls[0] = file:/usr/share/maven2/lib/wagon-ssh-common.jar urls[1] = file:/usr/share/maven2/lib/jsch.jar urls[2] = file:/usr/share/maven2/lib/wagon-http-shared.jar urls[3] = file:/usr/share/maven2/lib/wagon-ssh.jar urls[4] = file:/usr/share/maven2/lib/wagon-ssh-external.jar urls[5] = file:/usr/share/maven2/lib/xml-apis.jar urls[6] = file:/usr/share/maven2/lib/plexus-utils.jar urls[7] = file:/usr/share/maven2/lib/plexus-container-default.jar urls[8] = file:/usr/share/maven2/lib/wagon-provider-api.jar urls[9] = file:/usr/share/maven2/lib/wagon-http-lightweight.jar urls[10] = file:/usr/share/maven2/lib/jtidy.jar urls[11] = file:/usr/share/maven2/lib/doxia-sink-api.jar urls[12] = file:/usr/share/maven2/lib/wagon-file.jar urls[13] = file:/usr/share/maven2/lib/plexus-interactivity-api.jar urls[14] = file:/usr/share/maven2/lib/maven2.jar urls[15] = file:/usr/share/maven2/lib/commons-cli.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error configuring: org.apache.maven.plugins:maven-antrun-plugin. Reason: java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.close(Ljava/io/InputStream;)V [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring: org.apache.maven.plugins:maven-antrun-plugin. Reason: java.lang.NoSuchMethodError: org.apache.tools.ant.util.FileUtils.close(Ljava/io/InputStream;)V at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:587) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at
Re: Build error after updating to latest uimaj/pom.xml (rev. 807808)
Thilo Goetz wrote: Have you tried deleting m2 repository? I did an svn up and build yesterday, and it worked for me. Yes that I tried on the day the apache servers where down, and then it took a while until i could build my projects again, but it did not help. Does anyone now more about this issue ? Jörn
Re: Build error after updating to latest uimaj/pom.xml (rev. 807808)
Tommaso Teofili wrote: Hi Jorn, which Maven version are you using? 2.0.9 on Ubuntu linux Jörn
Re: source files packaging
On Sep 1, 2009, at 4:42 AM, Adam Lally wrote: On Sat, Aug 29, 2009 at 1:00 PM, Jörn Kottmannkottm...@gmail.com wrote: On Aug 28, 2009, at 3:14 PM, Marshall Schor wrote: We could do this for all of our Jars, and I'm thinking this would be a good idea. One reason would be it would align us slightly better with the maven way of doing things. When users download jars from maven they would find the sources rather than get maven warning messages that no sources were found, and the m2eclipse plugin would easily be able to get the sources. +1 Yes I would really appreciate having the source code in eclipse linked to the uiima jars automatically with mvn eclipse:eclipse. I'm not sure I completely understand - does this mean our binary distributions contain source, or not? If so, I am uneasy about that. We had this discussion prior to the last release without a real consensus being reached: http://markmail.org/thread/oqredcsn3camvyy7. To have source code linked in eclipse a binary (the one we have now) and separate source jars must be published via maven. Jörn
Re: UIMA AS client CPU load
Posted it a few days ago, would be nice if someone
could have a look. I assume there is a wait missing, right ?
If so the fix is simple and we can include it in 2.3.0.
Jörn
Jörn Kottmann wrote:
Hi everyone,
to put some load on one of our UIMA AS system I wrote
a small tool which uses the client API to send CASes to
a processing pipeline.
This tool has an endless loop which waits for work
to arrive and then sends it to the processing pipeline.
It basically looks like this:
text = getNextDocument() // returns plain text which should be analyzed
CAS cas = uimASEngine.getCAS();
cas.setDocumentText(text)
uimaAsEngine.sendCAS(cas)
When the tool is started there is usually lots of work waiting
and all available CASes are sent out to the service. It takes a while
until the first CAS is completly processed. Now the
tool gets a new text and waits for a new CAS inside getCAS().
Now I wonder why waiting for a CAS inside getCAS() puts 95 to 100 %
CPU load
on one core on my client machine.
I looked at the place where it waits in
BaseUIMAAsynchronousEngineCommon_impl
around line 536 in getCAS().
Here is the wait loop:
while (running) {
try {
// Wait until the CAS producer adds the CAS to the
CasQueueEntry and
// signals CAS availability.
entry.getSemaphore().acquire();
if (entry.getCas() == null) {
continue;
} else {
return entry.getCas();
}
} finally {
entry.getSemaphore().release();
} } // while
For me it looks like that if entry.getCAS() returns null it immediately
tries again and polls entry.getCAS() as often as possible.
Jörn
Re: Still a uima-as directory in the sandbox
I also think we should delete the directory, because its moved (with history) to a new location, which can be easily found. The tagged versions remains in the sandbox, in case someone is looking for the old release version. Jörn
Re: UIMA AS client CPU load
Jaroslaw Cwiklik wrote: Jorn, I've fixed this under UIMA-1540. Let me know if this fixes the problem. Yeah, tried to build it, but it the tests hang here: +-- Sep 1, 2009 5:54:13 PM org.apache.uima.aae.controller.BaseAnalysisEngineController logPlatformInfo INFO: +-- Starting UIMA AS Service - PID:20891 +-- + Service Name:Person Title Annotator + Service Queue Name:PersonTitleAnnotatorQueue + Service Start Time:01 Sep 2009 17:54:05 + UIMA AS Version:2.3.0 + UIMA Core Version:2.3.0 + OS Name:Linux + OS Version:2.6.28-15-generic + OS Architecture:i386 + OS CPU Count:2 + JVM Vendor:Sun Microsystems Inc. + JVM Name:Java HotSpot(TM) Server VM + JVM Version:14.0-b16 + JVM Input Args:[-Xmx300M] + JVM Classpath:/usr/share/maven2/boot/classworlds.jar + JVM LIB_PATH:/usr/lib/jvm/java-6-sun-1.6.0.14/jre/lib/i386/server:/usr/lib/jvm/java-6-sun-1.6.0.14/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.14/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib +-- Sep 1, 2009 5:54:13 PM org.apache.uima.adapter.jms.activemq.JmsInputChannel setEndpointName INFO: top_level_input_queue_service_1 Service Starting - Listening for Messages Sep 1, 2009 5:54:13 PM org.apache.uima.adapter.jms.activemq.SpringContainerDeployer waitForServiceNotification INFO: Uima EE Client Blocking - Awaiting Top Level Controller Initialization Notification Service:Person Title Annotator Listener Ready. Broker:tcp://localhost:8118 Queue:queue://PersonTitleAnnotatorQueue Selector:Command=2000 OR Command=2002 Service:Person Title Annotator Listener Ready. Broker:tcp://localhost:8118 Queue:queue://PersonTitleAnnotatorQueue Selector:Command=2001 CasManager Initialized Cas Pool:PrimitiveAEService. Cas Pool Size:5 Initial Cas Heap Size:50 cells Service:Person Title Annotator Initialized. Ready To Process Messages From Queue:PersonTitleAnnotatorQueue Sep 1, 2009 5:54:14 PM org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl initialize INFO: * Initialized the Controller. Person Title Annotator Ready To Process. Sep 1, 2009 5:54:14 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl setupConnection INFO: UIMA AS Client Created Shared Connection To Broker: tcp://karkand:8118 UIMA AS Client Created Shared Connection To Broker:tcp://karkand:8118 Sep 1, 2009 5:54:14 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl initializeProducer INFO: Initializing JMS Message Producer. Broker: tcp://karkand:8118 Queue Name: PersonTitleAnnotatorQueue Sep 1, 2009 5:54:14 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl initializeConsumer INFO: Initializing JMS Message Consumer. Broker: tcp://karkand:8118 Queue Name: ID:karkand-56803-1251820447466-3:2:1 Client Activated Temp Reply Queue:ID:karkand-56803-1251820447466-3:2:1 Sep 1, 2009 5:54:15 PM org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl initialize INFO: Asynchronous Client Has Been Initialized. Serialization Strategy: [xmi] Ready To Process. First Initialize Call Completed Received Expected Exception:class org.apache.uima.UIMA_IllegalStateException
Re: source files packaging
On Aug 28, 2009, at 3:14 PM, Marshall Schor wrote: We could do this for all of our Jars, and I'm thinking this would be a good idea. One reason would be it would align us slightly better with the maven way of doing things. When users download jars from maven they would find the sources rather than get maven warning messages that no sources were found, and the m2eclipse plugin would easily be able to get the sources. +1 Yes I would really appreciate having the source code in eclipse linked to the uiima jars automatically with mvn eclipse:eclipse. Jörn
Re: Generification of FSIndex
Marshall Schor wrote: OK - sounds like this won't be on the fix list for 2.3.0 ;-) And, given the value of being able to do this in selected cases, it doesn't sound right, either, to change the arguments to find, moveTo, etc from FeatureStructure. So let's leave this as is. I created a jira issue to change moveTo back to FeatureStructure argument, it was not changed yet because I misunderstood you. Which other methods are you referring to ? Jörn
UIMA AS client CPU load
Hi everyone,
to put some load on one of our UIMA AS system I wrote
a small tool which uses the client API to send CASes to
a processing pipeline.
This tool has an endless loop which waits for work
to arrive and then sends it to the processing pipeline.
It basically looks like this:
text = getNextDocument() // returns plain text which should be analyzed
CAS cas = uimASEngine.getCAS();
cas.setDocumentText(text)
uimaAsEngine.sendCAS(cas)
When the tool is started there is usually lots of work waiting
and all available CASes are sent out to the service. It takes a while
until the first CAS is completly processed. Now the
tool gets a new text and waits for a new CAS inside getCAS().
Now I wonder why waiting for a CAS inside getCAS() puts 95 to 100 % CPU
load
on one core on my client machine.
I looked at the place where it waits in
BaseUIMAAsynchronousEngineCommon_impl
around line 536 in getCAS().
Here is the wait loop:
while (running) {
try {
// Wait until the CAS producer adds the CAS to the
CasQueueEntry and
// signals CAS availability.
entry.getSemaphore().acquire();
if (entry.getCas() == null) {
continue;
} else {
return entry.getCas();
}
} finally {
entry.getSemaphore().release();
}
} // while
For me it looks like that if entry.getCAS() returns null it immediately
tries again and polls entry.getCAS() as often as possible.
Jörn
generics: AnnotationIndex.subiterator
FSIteratorT subiterator(AnnotationFS annot); Is that correct ? It leads to a problem in the Subiterator class, because it calls moveTo(annot) on an FSIterator, but annot must not have type T. Jörn
Re: generics: AnnotationIndex.subiterator
Jörn Kottmann wrote:
FSIteratorT subiterator(AnnotationFS annot);
Is that correct ?
It leads to a problem in the Subiterator class, because it calls
moveTo(annot) on an FSIterator, but annot must not have type
T.
The AnnotationIndexImpl has this method
public FSIteratorAnnotationFS subiterator(AnnotationFS annot,
boolean ambiguous, boolean strict) {
return new SubiteratorAnnotationFS(this.index.iterator(), annot,
ambiguous, strict);
}
if now the AnnotationFS is replaced by a T which is defined as T extends
AnnotationFS then,
the method is changed to
public FSIteratorT subiterator(AnnotationFS annot, boolean
ambiguous, boolean strict) {
return new SubiteratorT(this.index.iterator(), annot, ambiguous,
strict);
}
which leads to a compile error because Subiterator expects annot to be
of type T and not of
type AnnotationFS. Subitertor calls on the passed iterator moveTo(annot)
which creates a
conflict here.
Jörn
Re: generics issue with iterators
Marshall Schor wrote: After generification of iterators, this line in Lucas doesn't compile: In src/main/java, org.apache.uima.lucas.indexer.analysis, the class: AnnotationTokenStream line 340: annotationIterator = Iterators.filter(jCas.getAnnotationIndex(annotationType).iterator(), new NotNullPredicateAnnotation()); gives message: The method filter(IteratorT, Predicate? super T) in the type Iterators is not applicable for the arguments (FSIteratorAnnotationFS, AnnotationTokenStream.NotNullPredicateAnnotation) I observe that if I change new NotNullPredicateAnnotation()); // to new NotNullPredicateAnnotationFS()); that the error goes away, but is replaced with another error: Type mismatch: cannot convert from IteratorAnnotationFS to IteratorAnnotation I think the original form assigns to T the value AnnotationFS. This makes the assignment of the predicate NotNullPredicateX have the type X be a super type of AnnotationFS. But Annotation is a subtype, not a supertype. So it fails. I think the JCas version of getAnnotationIndex(annotationType).iterator() should end up returning an iterator over Annotation, not AnnotationFS. This would fix this, I think. But that would mean that we return an AnnotationIndexAnnotation and not AnnotationIndexAnnotationFS, right ? Jörn
generics: JFSIndexRepository
public interface JFSIndexRepository {
FSIndexTOP getIndex(String label);
FSIndexTOP getIndex(String label, int type);
AnnotationIndexAnnotation getAnnotationIndex();
AnnotationIndexAnnotation getAnnotationIndex(int type);
IteratorFSIndexTop getIndexes();
FSIteratorTOP getAllIndexedFS(Type aType);
FSIteratorTOP getAllIndexedFS(int aType);
}
Is the above generification correct ?
We could use FeatureStructure instead of TOP, I am not sure
whats better.
Jörn
UIMA .html files in doc folder have executable bit set
Hi, after building a distribution of the current head and unpacking the .tar.gz file, the .html files in the doc folder have the executable bit set. In Ubuntu 9.04 the .html files cannot be opened in a browser by double clicking them, because Ubuntu shows a Do you want to run xxx.html, or display its contents? dialog. Jörn
generics: CasManager.getCasInterface
Right now its declared as AbstractCas getCasInterface(CAS cas, Class? extends AbstractCas requiredInterface); but I think it should be T extends AbstractCas T getCasInterface(CAS cas, Class? extends AbstractCas requiredInterface); I will change it if there are no objections. Jörn
Re: generics: CasManager.getCasInterface
Jörn Kottmann wrote: Right now its declared as AbstractCas getCasInterface(CAS cas, Class? extends AbstractCas requiredInterface); but I think it should be T extends AbstractCas T getCasInterface(CAS cas, Class? extends AbstractCas requiredInterface); ups, it must be: T extends AbstractCas T getCasInterface(CAS cas, ClassT requiredInterface);
Re: generics: ResourceFactory.produceResource
Adam Lally wrote: On Wed, Aug 19, 2009 at 1:54 PM, Jörn Kottmannkottm...@gmail.com wrote: The current declaration with out generics: public Resource produceResource(Class aResourceClass, ResourceSpecifier aSpecifier, MapString, Object aAdditionalParams) throws ResourceInitializationException; Can it be assumed that aResourceClass is always a class which extends Resource, if so it could be declared as Class? extends Resource. Yes, I think that is right. In CPEFactory a org.apache.uima.collection.base_cpm.BaseCollectionReader is used as a resource class at line 345 to call UIMAFramework.produceResource. BaseCollectionReader does not extends the Resource interface. I wonder if that is correct usage of the produceResource method. Jörn
Re: generics: additionalParams
Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, Object which will cause compile errors in user code when they use a Properties object to pass in the additional params. I don't think its common practice to use Properties for additional params. If we fix the one found use cited above, are there any other cases where instances of Properties are passed as additionalParams in our own code? What do we think is the likelyhood that users will use Properties as instances of additional params? Our documentation says See the Javadocs for info on the additional parameters. The Javadocs say this is a Map ... Valid parameter names are defined as constants on the XYZ Interface ... and in that interface, these constants are Strings. But users might decide to represent these parameters in a properties file. Here are some considerations (apologies if I get this wrong - please correct): - If we declare as Object, Object, then you cannot assign a MapString, Object to the parameter. - Having the key of the map be an Object is more general, and would accommodate Properties. - declaring as String, Object - cannot assign new Properties() to it any more, unless you do the double-fisted cast (MapString,Object)(Object) If that is the trade off, I think I would rather have it be String, Object. +1 from me for MapString, Object If there are no objections I would like to start with the change to get it done before our 28th deadline. Jörn
Re: release 2.3.0 plan
One way we have to ensure that the uima core generification is correct is to use our API with generics, thats why I would like to suggest to move our release a few days and use the time to convert existing code outside of the core. That could be done after the code freeze. Jörn Marshall Schor wrote: I'd like to freeze in 3 weeks, if that is reasonable. For all of you with code that you want to have in the release, is 3 weeks (Aug 28 - a Friday) too soon to freeze (stop developing, and see if we can cut a release candidate)? This means: coding of any new things is done, tests written, and everything runs/builds documentation is done As part of the release process, after we do a release candidate, we'll ask everyone to help in testing it. During that time, no new feature work please, just work on getting the candidate into shape to release (fixing bugs). Things that are not ready will be postponed to the next release. Please respond with a +1 if you think you can wrap up any work needed in 3 weeks, and a -1 if you think the release point should be delayed because of something you believe strongly should make this release. See this wiki page for info on the release plan: http://cwiki.apache.org/confluence/display/UIMA/ReleasePlan2.3.0 Thanks to everyone for help in getting this out! -Marshall (volunteering as the release manager this time around)
Re: release 2.3.0 plan
Marshall Schor wrote: +1 I'm for doing testing of the new generification because of the difficulty of doing this correctly... -Marshall What kind of testing do think of ? Jörn
generics: AnalysisComponent.getRequiredCasInterface();
Is that the correct generification? Class? extends AbstractCas getRequiredCasInterface(); Implementing classes can then specify the concrete return type. For example: ClassJCas JCasAnnotator_ImplBase.getRequiredCasInterface() ClassCAS CasAnnotator_ImplBase.getRequiredCasInterface() Jörn
generics: ResourceFactory.produceResource
The current declaration with out generics: public Resource produceResource(Class aResourceClass, ResourceSpecifier aSpecifier, MapString, Object aAdditionalParams) throws ResourceInitializationException; Can it be assumed that aResourceClass is always a class which extends Resource, if so it could be declared as Class? extends Resource. There are many places where aResourceClass occurs, we should handle them all identical. Jörn
Re: generics: CasPool
Adam Lally wrote: On Mon, Aug 17, 2009 at 10:39 AM, Jörn Kottmannkottm...@gmail.com wrote: The CasPool has a constructor CasPool(int aNumInstances, Collection aComponentDescriptionsOrMetaData, Properties aPerformanceTuningSettings, ResourceManager aResourceManager) where aComponentDescriptionsOrMetaData is a collection which can contain according to javadoc AnalysisEngineDescription, CollectionReaderDescription, CasConsumerDescription or ProcessingResourceMetaData objects A reference of the Collection is passed to fillPool which passes the Collection to a CasDefinition constructor which then casts everything to ProcessingResourceMetaData, which will result in a ClassCastException in the case of AnalysisEngineDescription, CollectionReaderDescription and CasConsumerDescription objects. Well, when we use generics we get an error. Good catch, that javadoc does seem to be wrong. I wonder if it was correct at some point in the past and the code has changed? Maybe, at least it was not changed through the generics. Jörn
Re: generics: additionalParams
Jörn Kottmann wrote: The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapString, Object. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a MapObject, Object which will cause compile errors in user code when they use a Properties object to pass in the additional params. I don't think its common practice to use Properties for additional params. Any opinions on this ? Jörn
Re: Ontology Annotator to the sandbox
Ahmed Abdeen Hamed wrote: Attached is the documentation to the old version and I will point you a PEAR file once I finish refactoring. You cannot send attachments to this list. http://obo-annotator.svn.sourceforge.net/viewvc/obo-annotator/obo-annotator/OBO-Annotator.pdf?view=log Is this the link to the documentation you attached ? Jörn
