[jira] Assigned: (UIMA-1501) more refactoring and updating - parent POMs
[ https://issues.apache.org/jira/browse/UIMA-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1501: Assignee: Marshall Schor > more refactoring and updating - parent POMs > --- > > Key: UIMA-1501 > URL: https://issues.apache.org/jira/browse/UIMA-1501 > Project: UIMA > Issue Type: Improvement > Components: Build, Packaging and Test >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Minor > > use pluginManagement and dependencyManagement to refactor additional items. > Update to javadoc plugin 2.5 (the current level - what the superPom > specifies). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-319) Annotator and Analysis Engine Guide "Other Examples" section may be misplaced
[ https://issues.apache.org/jira/browse/UIMA-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-319: Affects Version/s: (was: 2.2) (was: 2.1) 2.3 > Annotator and Analysis Engine Guide "Other Examples" section may be misplaced > - > > Key: UIMA-319 > URL: https://issues.apache.org/jira/browse/UIMA-319 > Project: UIMA > Issue Type: Improvement > Components: Documentation >Affects Versions: 2.3 >Reporter: Adam Lally >Priority: Trivial > > Annotator and Analysis Engine Guide has "Other Examples" section that > mentions a CAS Consumer, but the concept of CAS Consumers hasn't been > introduced yet. Perhaps this section belongs in the CPE Developer's Guide > instead? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1510) improve uimaj-distr assembly
[ https://issues.apache.org/jira/browse/UIMA-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1510. Resolution: Fixed > improve uimaj-distr assembly > > > Key: UIMA-1510 > URL: https://issues.apache.org/jira/browse/UIMA-1510 > Project: UIMA > Issue Type: Improvement >Reporter: Marshall Schor >Assignee: Marshall Schor > Fix For: 2.3 > > > change POM to POM style (from Jar style) - previous problem seems to have > gone away which required Jar style. This way, no extraneous "jar" file is > generated. > update dependency sets with useProjectArtifact = false to avoid 18 warning > messages. > factor out version/scope from dependency sets > use current level of JavaDoc generation tool (works much faster, is preset to > Java 5 in parent poms, etc.) > use current level of assembly plugin 2.2-beta-4, up from 2.2-beta-2 > drop bz2 formats -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1510) improve uimaj-distr assembly
improve uimaj-distr assembly Key: UIMA-1510 URL: https://issues.apache.org/jira/browse/UIMA-1510 Project: UIMA Issue Type: Improvement Reporter: Marshall Schor Assignee: Marshall Schor Fix For: 2.3 change POM to POM style (from Jar style) - previous problem seems to have gone away which required Jar style. This way, no extraneous "jar" file is generated. update dependency sets with useProjectArtifact = false to avoid 18 warning messages. factor out version/scope from dependency sets use current level of JavaDoc generation tool (works much faster, is preset to Java 5 in parent poms, etc.) use current level of assembly plugin 2.2-beta-4, up from 2.2-beta-2 drop bz2 formats -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1358) Exceptions on generated CASes are returned to client without parentage information
[ https://issues.apache.org/jira/browse/UIMA-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1358. --- Resolution: Fixed Applied Burn's patch > Exceptions on generated CASes are returned to client without parentage > information > -- > > Key: UIMA-1358 > URL: https://issues.apache.org/jira/browse/UIMA-1358 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.2.2 >Reporter: Burn Lewis >Assignee: Jerry Cwiklik > Fix For: 2.3S > > Attachments: uimaj-as-activemq_1358.patch > > > The client should be told which of its input CASes might have (indirectly) > generated this failing CAS. Also is there any value in sending more than one > exception if many children fail? If the aggregate is not a CM then the > client should just be told that the input CAS failed. > Here is part of a recent email discussion on this problem: > I think I have a somewhat clearer picture of how we might handle errors on > child CASes. > First consider Primitive & Aggregate CMs, and then a non-CM aggregate that > contains a CM. > I can see 3 different ways an application may wish to handle errors on child > CASes: > Primitive CM > Stop generating children/descendants of the input CAS and return an exception > on the input CAS > Generate an "incomplete" CAS -- perhaps marked as "damaged" > (useful when the total count must be preserved and a place-holder provided) > Ignore the error, generate no CAS and carry on to generate the next CAS (if > any) > Aggregate CM > Stop generating any more children/descendants from the input CAS and return > the exception on the input CAS > Allow the CAS to continue in the flow > Quietly drop the CAS, do not return it and do not generate an exception > Simple Aggregate with internal CM > Stop generating any more children/descendants from the input CAS and return > the exception on the input CAS > Allow the CAS to continue in the flow (it will be dropped at the end of the > flow) > Quietly drop the CAS as if it reached the end of the flow, and do not > generate an exception > Currently our aggregate error-handling supports #2, while #3 doesn't depend > on the framework. I have added aggregate support for #3 to the > AdvancedFixedFlowController in the UIMA-AS test suite (as part of Jira 1353) > in the form of a new AllowDropOnFailure option which specifies the delegates > for which a failing CAS can be dropped, i.e. skip to the end of the flow with > the forceCasToBeDropped flag set. (I used it to test the thresholdWindow > error handling to verify that an intermittently failing delegate is disabled > when N of the last M CASes fail.) > But I don't think our docs indicate what should happen in #1 and the current > implementation handles it differently ... the exception is associated with > the child CAS without any reference to the input CAS, and the CM continues to > generate children, so the client can get many exceptions that refer to > unknown CASes. The getParentCasReferenceId() method in the > UimaASProcessStatus (which I could not find in the JavaDocs) can be used to > associate a child CAS with the input CAS that generated it, but it is always > null when an exception is returned. > Consider the information available to the entityProcessComplete callback when > an input CAS successfully generates 2 children: > returnedCAS getCasReferenceId() getParentCasReferenceId() > isException() > > Child1 ID-of-Child1ID-of-Parent > false > Child2 ID-of-Child2ID-of-Parent > false > Parent ID-of-Parentnull > false > If the 2nd child causes an exception then the client might see (Option > A) > returnedCAS getCasReferenceId() getParentCasReferenceId() > isException() > > Child1 ID-of-Child1ID-of-Parent > false > nullID-of-Parentnull > true > Or we could put the failing child's ID in the status (Option B) > returnedCAS getCasReferenceId() getParentCasReferenceId() > isException() > > Child1 ID-of-Child1ID-of-Parent > false > nullID-of-Child2ID-of-Parent > true > Note that in an Aggregate CM the failing CAS may not have been generated > directly by the parent, but by any one of its descendants. > I think option A is cleaner and easier to document ... "exception always on > input CAS". If the ID of the failing child is useful we could
[jira] Commented: (UIMA-1298) A shared remote CM hangs when one of its clients runs out of memory
[ https://issues.apache.org/jira/browse/UIMA-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745597#action_12745597 ] Jerry Cwiklik commented on UIMA-1298: - Consider spinning a thread in the CM service that periodically checks outgoing connections to detect failed clients. Perhaps sending a Ping message to a client can be used to detect stale connections and dead clients. > A shared remote CM hangs when one of its clients runs out of memory > > > Key: UIMA-1298 > URL: https://issues.apache.org/jira/browse/UIMA-1298 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.3AS >Reporter: Burn Lewis >Priority: Minor > Fix For: 2.3S > > > Twice I observed that when one client aggregate of a shared remote CM crashed > with an out-of-memory exception the service stopped responding to the other > client's requests. No errors found in the service log. The client was not > using the service at the time of the crash. Requests stacked up on the input > queue ... almost as if the service was blocked on an empty pool, or ...? > Killing a client (cntl-C) did not cause the hang. Weird! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1487) Add support for collectionProcessComplete timeout setting in JMS service adapter
[ https://issues.apache.org/jira/browse/UIMA-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1487. --- Resolution: Fixed Fixed by Eddie > Add support for collectionProcessComplete timeout setting in JMS service > adapter > > > Key: UIMA-1487 > URL: https://issues.apache.org/jira/browse/UIMA-1487 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Eddie Epstein >Assignee: Eddie Epstein > > The JMS service adapter is used to allow UIMA aggregates to call UIMA AS > services, similar to Vinci and SOAP services. The JMS adapter supports > process and getmeta timeouts, but not CPC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1298) A shared remote CM hangs when one of its clients runs out of memory
[ https://issues.apache.org/jira/browse/UIMA-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1298: - Affects Version/s: 2.3AS defer beyond 2.3.0 release > A shared remote CM hangs when one of its clients runs out of memory > > > Key: UIMA-1298 > URL: https://issues.apache.org/jira/browse/UIMA-1298 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.3AS >Reporter: Burn Lewis >Priority: Minor > Fix For: 2.3S > > > Twice I observed that when one client aggregate of a shared remote CM crashed > with an out-of-memory exception the service stopped responding to the other > client's requests. No errors found in the service log. The client was not > using the service at the time of the crash. Requests stacked up on the input > queue ... almost as if the service was blocked on an empty pool, or ...? > Killing a client (cntl-C) did not cause the hang. Weird! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1278) Add ability to report JMS reconnection status
[ https://issues.apache.org/jira/browse/UIMA-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1278: - Affects Version/s: 2.3AS defer beyond 2.3.0 release > Add ability to report JMS reconnection status > - > > Key: UIMA-1278 > URL: https://issues.apache.org/jira/browse/UIMA-1278 > Project: UIMA > Issue Type: Improvement > Components: Async Scaleout >Affects Versions: 2.3AS >Reporter: Bhavani Iyer >Assignee: Bhavani Iyer > > The ControllerCallbackListener needs to be extended to provide APIs to report > JMS reconnection status. > At present this status is reported by C++ services via the > UimacppServiceController bean, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1288) Need a Better Approach For Specifying UIMA AS Broker URL in Deployment Descriptor
[
https://issues.apache.org/jira/browse/UIMA-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor reassigned UIMA-1288:
Assignee: Tong Fin (was: Eddie Epstein)
> Need a Better Approach For Specifying UIMA AS Broker URL in Deployment
> Descriptor
> -
>
> Key: UIMA-1288
> URL: https://issues.apache.org/jira/browse/UIMA-1288
> Project: UIMA
> Issue Type: Improvement
> Components: Async Scaleout
>Reporter: Jerry Cwiklik
>Assignee: Tong Fin
>
> Each UIMA AS deployment descriptor requires at least one Broker URL for the
> connection factory. Instead of hard coding the URL, perhaps a placeholder for
> it should be used. At runtime, the placeholder could be resolved to the
> actual URL by Spring resolver component. The value could come from either an
> external file or from an environment. The new approach should accommodate
> specifying more than one placeholder, since an aggregate may have delegates
> whose queues are managed by a different broker. The new approach would
> simplify deployment of UIMA AS services, especially during testing.
> A placeholder syntax could be inherited from Spring, where it looks like
> ${placeholder-name}.
> dd2spring would need to change to handle a placeholder notation in addition
> to supporting hard coded broker URL that we use now. A new bean must be added
> to the generated xml. It will be :
> class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
> value="SYSTEM_PROPERTIES_MODE_OVERRIDE"/>
>
>
> This bean is setup to resolve placeholders using system variables, like
> -Dplaceholder-name=placeholder-value
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1297) Uima AS Service Not Handling Send Failures Correctly
[ https://issues.apache.org/jira/browse/UIMA-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1297: Assignee: Burn Lewis (was: Jerry Cwiklik) > Uima AS Service Not Handling Send Failures Correctly > > > Key: UIMA-1297 > URL: https://issues.apache.org/jira/browse/UIMA-1297 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Jerry Cwiklik >Assignee: Burn Lewis > Attachments: uimaj-as-activemq_1297.patch > > > When a send requst fails due to a lost broker connection, the uima AS > aggregate removes the CAS from the outstanding list. Subsequently, when a > timer pops the Timeout Exception is reported against the wrong CAS. > Fix the code so that the CAS remains in the outstanding list until the timer > pops. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1358) Exceptions on generated CASes are returned to client without parentage information
[ https://issues.apache.org/jira/browse/UIMA-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1358: Assignee: Jerry Cwiklik (was: Burn Lewis) > Exceptions on generated CASes are returned to client without parentage > information > -- > > Key: UIMA-1358 > URL: https://issues.apache.org/jira/browse/UIMA-1358 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.2.2 >Reporter: Burn Lewis >Assignee: Jerry Cwiklik > Fix For: 2.3S > > Attachments: uimaj-as-activemq_1358.patch > > > The client should be told which of its input CASes might have (indirectly) > generated this failing CAS. Also is there any value in sending more than one > exception if many children fail? If the aggregate is not a CM then the > client should just be told that the input CAS failed. > Here is part of a recent email discussion on this problem: > I think I have a somewhat clearer picture of how we might handle errors on > child CASes. > First consider Primitive & Aggregate CMs, and then a non-CM aggregate that > contains a CM. > I can see 3 different ways an application may wish to handle errors on child > CASes: > Primitive CM > Stop generating children/descendants of the input CAS and return an exception > on the input CAS > Generate an "incomplete" CAS -- perhaps marked as "damaged" > (useful when the total count must be preserved and a place-holder provided) > Ignore the error, generate no CAS and carry on to generate the next CAS (if > any) > Aggregate CM > Stop generating any more children/descendants from the input CAS and return > the exception on the input CAS > Allow the CAS to continue in the flow > Quietly drop the CAS, do not return it and do not generate an exception > Simple Aggregate with internal CM > Stop generating any more children/descendants from the input CAS and return > the exception on the input CAS > Allow the CAS to continue in the flow (it will be dropped at the end of the > flow) > Quietly drop the CAS as if it reached the end of the flow, and do not > generate an exception > Currently our aggregate error-handling supports #2, while #3 doesn't depend > on the framework. I have added aggregate support for #3 to the > AdvancedFixedFlowController in the UIMA-AS test suite (as part of Jira 1353) > in the form of a new AllowDropOnFailure option which specifies the delegates > for which a failing CAS can be dropped, i.e. skip to the end of the flow with > the forceCasToBeDropped flag set. (I used it to test the thresholdWindow > error handling to verify that an intermittently failing delegate is disabled > when N of the last M CASes fail.) > But I don't think our docs indicate what should happen in #1 and the current > implementation handles it differently ... the exception is associated with > the child CAS without any reference to the input CAS, and the CM continues to > generate children, so the client can get many exceptions that refer to > unknown CASes. The getParentCasReferenceId() method in the > UimaASProcessStatus (which I could not find in the JavaDocs) can be used to > associate a child CAS with the input CAS that generated it, but it is always > null when an exception is returned. > Consider the information available to the entityProcessComplete callback when > an input CAS successfully generates 2 children: > returnedCAS getCasReferenceId() getParentCasReferenceId() > isException() > > Child1 ID-of-Child1ID-of-Parent > false > Child2 ID-of-Child2ID-of-Parent > false > Parent ID-of-Parentnull > false > If the 2nd child causes an exception then the client might see (Option > A) > returnedCAS getCasReferenceId() getParentCasReferenceId() > isException() > > Child1 ID-of-Child1ID-of-Parent > false > nullID-of-Parentnull > true > Or we could put the failing child's ID in the status (Option B) > returnedCAS getCasReferenceId() getParentCasReferenceId() > isException() > > Child1 ID-of-Child1ID-of-Parent > false > nullID-of-Child2ID-of-Parent > true > Note that in an Aggregate CM the failing CAS may not have been generated > directly by the parent, but by any one of its descendants. > I think option A is cleaner and easier to document ... "exception always on > input CAS". If the ID of the failing child is use
[jira] Assigned: (UIMA-1393) UimaSerializer should make use of ThreadLocal
[ https://issues.apache.org/jira/browse/UIMA-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1393: Assignee: Jerry Cwiklik > UimaSerializer should make use of ThreadLocal > - > > Key: UIMA-1393 > URL: https://issues.apache.org/jira/browse/UIMA-1393 > Project: UIMA > Issue Type: Improvement > Components: Async Scaleout >Reporter: Jörn Kottmann >Assignee: Jerry Cwiklik >Priority: Trivial > Fix For: 2.3AS > > Attachments: UIMA-1393.patch > > > The current implementation tries to emulate ThreadLocal with a Map and a > lock. Using ThreadLocal directly has the advantage of making > the code simpler and enabling garbage collection for cached instances when > the belonging thread ends. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1405) Uima AS not allowing deployment of more than one deployment descriptor in the same jvm
[ https://issues.apache.org/jira/browse/UIMA-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1405: - Affects Version/s: 2.3AS deferred beyond 2.3.0 release > Uima AS not allowing deployment of more than one deployment descriptor in the > same jvm > -- > > Key: UIMA-1405 > URL: https://issues.apache.org/jira/browse/UIMA-1405 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.3AS >Reporter: Jerry Cwiklik >Assignee: Jerry Cwiklik >Priority: Minor > > Uima AS fails with ResourceInitializationException when one tries to deploy > more than one deployment descriptor using deployAsyncService script. The > problem is that components in generated spring context files are deployed > into a single Spring container. But each spring context files defines > singleton objects that are not meant to be used externally. An example of > such non-shared singleton would the InProcessCache. It is meant to be shared > by components defined in a single context file. There are few possibly > solutions here: > 1) modify dd2spring to assign unique names to spring beans to prevent sharing > across context files. > 2) modify uima-as deployer to deploy each context file in a separate spring > container > 3) find a way to prevent spring from sharing singleton objects across context > files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1227) Help users debug binary CAS serialization problems
[ https://issues.apache.org/jira/browse/UIMA-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1227: - Affects Version/s: 2.3AS deferred beyond 2.3.0 release - requires changes to core to support comparing type systems > Help users debug binary CAS serialization problems > -- > > Key: UIMA-1227 > URL: https://issues.apache.org/jira/browse/UIMA-1227 > Project: UIMA > Issue Type: Improvement > Components: Async Scaleout >Affects Versions: 2.3AS >Reporter: Eddie Epstein > > In order to use binary CAS serialization for remote services, both client and > service must have identical type systems. If not the same, binary > deserialization is likely to throw exceptions. The service request handler > should catch these exceptions when using binary deserialization and add > message suggesting a likely cause of the problem: unequal type systems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1295) Add "continue" as an error handling option for getMeta at initialization
[ https://issues.apache.org/jira/browse/UIMA-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1295: - Affects Version/s: 2.3AS deferred beyond 2.3.0 release > Add "continue" as an error handling option for getMeta at initialization > > > Key: UIMA-1295 > URL: https://issues.apache.org/jira/browse/UIMA-1295 > Project: UIMA > Issue Type: New Feature > Components: Async Scaleout >Affects Versions: 2.3AS >Reporter: Eddie Epstein > > In http://markmail.org/message/ceb2npk5qsmuftn4 Yosi Mass requested that UIMA > support a peer-to-peer capability where services are discovered dynamically > to improve load balancing, and presumably, to enhance processing by using > analytics which only become available after a client has started. > UIMA AS already supports dynamically expanding processing capability for a > particular service, by simply starting additional service instances pointed > at the service's existing request queue. Using appropriate error handling > and/or custom flow controller options, a UIMA AS aggregate also has the > capability to ignore a missing delegate service, as long as the delegate > service was available during aggregate initialization. The enhancement > suggested here is to allow an aggregate service to later use a delegate > service that was unavailable during initialization. > UIMA changes would be: > 1. add a new error handling option for getMeta failures at initialization. > Currently the options at init are to disable any use of the delegate, or fail > initialization and terminate the aggregate. The new option, "continue", would > be ignore this failure and complete initialization of the aggregate, but mark > the delegate as being in a special state, very similar to the "questionable" > state described in UIMA-1127. > 2. The difference from UIMA-1127 is that when getMeta succeeds for this > delegate, the service's type system would be checked to see that it is > compatible with that of the aggregate. See UIMA-1290 for details on what > validation means. If valid, the delegate is marked fully operational. If the > type system fails validation, and process error handling is set to continue, > a new exception type would be given to the flow controller to decide how to > handle the situation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1328) deployAsyncService.sh causes Log4j FileNotFoundException
[ https://issues.apache.org/jira/browse/UIMA-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1328: Assignee: Jerry Cwiklik > deployAsyncService.sh causes Log4j FileNotFoundException > > > Key: UIMA-1328 > URL: https://issues.apache.org/jira/browse/UIMA-1328 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.3AS > Environment: Ubuntu 8.10 >Reporter: Jörn Kottmann >Assignee: Jerry Cwiklik > > The following exception is printed to the console during startup: > bin/deployAsyncService.sh tagger/desc/Deploy_TextAnalysis.xml > >>> Setting defaultBrokerURL to: > log4j:ERROR setFile(null,true) call failed. > java.io.FileNotFoundException: /activemq-data/activemq.log (No such file or > directory) > at java.io.FileOutputStream.openAppend(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:177) > at java.io.FileOutputStream.(FileOutputStream.java:102) > at org.apache.log4j.FileAppender.setFile(FileAppender.java:272) > at > org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java:156) > at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:151) > at > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:247) > at > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:123) > at > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:87) > at > org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:645) > at > org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:603) > at > org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:500) > at > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:406) > at > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:432) > at > org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:460) > at org.apache.log4j.LogManager.(LogManager.java:113) > at org.apache.log4j.Category.getInstance(Category.java:514) > at > org.apache.commons.logging.impl.Log4JCategoryLog.(Log4JCategoryLog.java:100) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:502) > at > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:285) > at > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:255) > at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:381) > at org.springframework.util.ClassUtils.(ClassUtils.java:67) > at > org.springframework.core.io.DefaultResourceLoader.(DefaultResourceLoader.java:52) > at > org.springframework.context.support.AbstractApplicationContext.(AbstractApplicationContext.java:184) > at > org.springframework.context.support.AbstractRefreshableApplicationContext.(AbstractRefreshableApplicationContext.java:80) > at > org.springframework.context.support.AbstractXmlApplicationContext.(AbstractXmlApplicationContext.java:58) > at > org.springframework.context.support.FileSystemXmlApplicationContext.(FileSystemXmlApplicationContext.java:91) > at > org.springframework.context.support.FileSystemXmlApplicationContext.(FileSystemXmlApplicationContext.java:77) > at > org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.deploy(SpringContainerDeployer.java:370) > at > org.apache.uima.adapter.jms.service.UIMA_Service.deploy(UIMA_Service.java:170) > at > org.apache.uima.adapter.jms.service.UIMA_Service.main(UIMA_Service.java:406) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-1269) NPE when using a C++ service deployed via JNI
[ https://issues.apache.org/jira/browse/UIMA-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1269: Assignee: Bhavani Iyer > NPE when using a C++ service deployed via JNI > - > > Key: UIMA-1269 > URL: https://issues.apache.org/jira/browse/UIMA-1269 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.2.2 >Reporter: Burn Lewis >Assignee: Bhavani Iyer > > C++ services don't support delta CAS so the JNI wrapper clears the Marker > before uploading the C++ CAS but then the service crashes when trying to > return a delta CAS to its caller. May also have a problem in an aggregate if > one of its services does not support delta CAS ... need to invalidate the > input Marker and make the aggregate return a full CAS. Should also create a > fresh Marker for following delegates so they can return delta CASes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1480) Add version compatibility verification to UIMA-AS for base UIMA level
[ https://issues.apache.org/jira/browse/UIMA-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1480. --- Resolution: Fixed Modified UIMA-AS client and UIMA AS Service Controller's base class to check for version compatibility between UIMA-AS and UIMA Core. The code checks for exact match. > Add version compatibility verification to UIMA-AS for base UIMA level > - > > Key: UIMA-1480 > URL: https://issues.apache.org/jira/browse/UIMA-1480 > Project: UIMA > Issue Type: Improvement > Components: Async Scaleout >Reporter: Marshall Schor >Assignee: Jerry Cwiklik > Fix For: 2.3AS > > > As part of the repackaging of UIMA-AS, it won't necessarily be packaged with > a version of base UIMA - so it should verify that the version of base UIMA it > is running with is OK. For now, require that it be at the corresponding > level that is released - e.g., 2.3.0 for the Base and 2.3.0 for UIMA-AS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1509) Generify the aResourceClass Class through the uimaj-core codebase
Generify the aResourceClass Class through the uimaj-core codebase - Key: UIMA-1509 URL: https://issues.apache.org/jira/browse/UIMA-1509 Project: UIMA Issue Type: Improvement Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 It should be declared as Class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1434) UIMA AS logs an exception when handling stale messages
[ https://issues.apache.org/jira/browse/UIMA-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1434. --- Resolution: Fixed > UIMA AS logs an exception when handling stale messages > -- > > Key: UIMA-1434 > URL: https://issues.apache.org/jira/browse/UIMA-1434 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Jerry Cwiklik >Assignee: Jerry Cwiklik >Priority: Minor > > Stale messages should not be logged with an exception. Messages can become > stale for a number of reasons and should not be logged as a warning. Instead > of an exception, a message should be logged to indicate that the stale > message was processed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1439) Fix interemittent hangs in UIMA AS when stopping the JMS listener
[ https://issues.apache.org/jira/browse/UIMA-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1439. --- Resolution: Fixed Fixed under JIRA UIMA-1433. Bug in caching JMS connections prevented cleanup code from stopping AMQ threads. > Fix interemittent hangs in UIMA AS when stopping the JMS listener > - > > Key: UIMA-1439 > URL: https://issues.apache.org/jira/browse/UIMA-1439 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Jerry Cwiklik >Assignee: Jerry Cwiklik > > When stopping UIMA AS listener, the ThreadPoolTaskExecutor shutdown method is > called and the code than waits for all threads managed by the executor to > stop. The problem is that listener's stop method may be called from one of > the threads that are being managed by the executor. The executor tries to > stop the thread and the thread tries to stop the executor. This leads to a > hang. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1292) Uima AS Jms Listener Should Support Retry When Establishing Connection To a Broker
[ https://issues.apache.org/jira/browse/UIMA-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik closed UIMA-1292. --- Resolution: Fixed The listener failed to recover from a lost broker because of the maxInactivityDuration=0 parameter in the broker URL. This effectively turns off ability to detect socket closure and causing a service to sit on a stale connection. No messages flow into the service even if a new broker becomes available. Modified the listener to accept broker URL as provided by a user. Removed check for existence of maxInactivityDuration=0. If there are problems with socket closing due to inactivity use keepAlive=true parameter in the broker URL instead of maxInactivityDuration=0. Example: tcp://host:61616?keepAlive=true. This turns on low level socket keep alive protocol which sends small packets and awaits ACKs. The frequency of these packets can be changed on linux by editing this file: /proc/sys/net/ipv4/tcp_keepalive_intvl. The default frequency on linux is 75 seconds > Uima AS Jms Listener Should Support Retry When Establishing Connection To a > Broker > -- > > Key: UIMA-1292 > URL: https://issues.apache.org/jira/browse/UIMA-1292 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Jerry Cwiklik >Assignee: Jerry Cwiklik > > UIMA AS service should support retry when a listener on the service input > queue fails due to a broker not being available. The listener should log a > message stating the fact that the broker is not available and it should enter > a loop attempting to reconnect. When a broker becomes available the listener > should reconnect, log a message that the connection was made, and proceed to > complete initialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: possibly including the BSFAnnotator in the sandbox release 2.3.0
OK I have a look Cheers Olivier > -Message d'origine- > De : Marshall Schor [mailto:m...@schor.com] > Envoyé : jeudi 20 août 2009 16:52 > À : uima-dev@incubator.apache.org > Objet : Re: possibly including the BSFAnnotator in the sandbox release > 2.3.0 > > Hi Olivier - > > I updated the project: > removed the bsf-bsh.jar > updated the bsh.jar to bsh-1.3.0.jar > > I changed the POM so it didn't depend on the bsf-bsh.jar and changed > the > dependency of the bsh.jar to bsh-1.3.0.jar. > > When I tried to build it, it failed when running the > testAnnotatorAggregated. (The tests ran before I did these updates) > > The error was: caused by org.apache.bsf.BSFException: the application > script threw an exception: > java.lang.NullPointerException: Null Pointer in Method Invocation > > at bsh.util.BeanShellBSFEngine.call(Unknown Source) > at > org.apache.uima.annotator.bsf.BSFAnnotator.initialize(BSFAnnotator.java > :161) > > Can you take a look? > > I've check in the updated project - you should be able to just check it > out. > > Thanks. -Marshall > > Olivier Terrier wrote: > > Hi Marshall > > > > When I donated the BSFAnnotator about two years ago I was not very > > familiar with the maven-based Apache UIMA build process... And I'm > > afraid I'm still not be. > > > > > >> While working on including the BSFAnnotator in the sandbox release, > I > >> noticed it has 6 jar files in its "lib" directory. The NOTICE file > >> says > >> that the project includes some components under MPL and SPL; > however, > >> the information needed to associate each of this included 3rd-party > >> > > jar > > > >> files with the proper license is missing. > >> > >> Can someone who knows identify the source of the following jars: > >> > >> bsf.jar > >> > > Apache 2 license > > Comes from > > http://apache.crihan.fr/dist/jakarta/bsf/binaries/bsf-bin-2.4.0.zip > > > > > >> bsh-bsf.jar > >> > > No longer needed: can be removed > > > > > >> bsh.jar > >> > > Dual licensed under both the SPL and LGPL => SPL is in the list of > > acceptable licenses available here: > > http://www.apache.org/legal/3party.html > > Can be replaced by http://www.beanshell.org/bsh-1.3.0.jar (which now > > contains the bsh-bsf.jar classes) > > > > > > > >> commons-logging-api-1.1.jar > >> > > Apache 2 license > > Comes from > > http://archive.apache.org/dist/commons/logging/binaries/commons- > logging- > > 1.1.zip > > > > > >> js.jar > >> > > Dual licensed under both the MPL 1.1 and GPL => MPL is in the list of > > acceptable licenses available here: > > http://www.apache.org/legal/3party.html > > Comes from ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R7.zip > > > > > >> log4j-1.2.15.jar > >> > > Apache 2 license > > Comes from > > http://www.apache.org/dyn/closer.cgi/logging/log4j/1.2.15/apache- > log4j-1 > > .2.15.zip > > > > > >> Is there a better way to package / distribute this in binary form? > >> > > Probably using maven dependencies but I don't have enough maven- > skills > > to do it myself > > > > > >> Also, I noticed that the POM section for building the documentation > is > >> commented out - because there is no docbook style documentation. > The > >> documentation seems limited to a README and some examples. Is there > >> additional documentation available for this? > >> > > No: just the README sorry > > > > I guess that a real revamping should use the JSR-223 (javax.script) > > which is included in Java 1.6 and add support to new popular > scripting > > languages like groovy, beanshell 2.0 etc... > > > > > > > >> -Marshall > >> > > > > > >
[jira] Created: (UIMA-1508) Generify uimaj-core
Generify uimaj-core --- Key: UIMA-1508 URL: https://issues.apache.org/jira/browse/UIMA-1508 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Jörn Kottmann Fix For: 2.3 Parent issue for all generification issues for uimaj-core to keep track of all changes and the overall progress. All generification issues should specify this issue as parent issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1507) BaseCollectionReader should extend Resource
BaseCollectionReader should extend Resource --- Key: UIMA-1507 URL: https://issues.apache.org/jira/browse/UIMA-1507 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 To allow a call to produceResource to create a BaseCollectionReader, it must extend the Resource interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: possibly including the BSFAnnotator in the sandbox release 2.3.0
Hi Olivier - I updated the project: removed the bsf-bsh.jar updated the bsh.jar to bsh-1.3.0.jar I changed the POM so it didn't depend on the bsf-bsh.jar and changed the dependency of the bsh.jar to bsh-1.3.0.jar. When I tried to build it, it failed when running the testAnnotatorAggregated. (The tests ran before I did these updates) The error was: caused by org.apache.bsf.BSFException: the application script threw an exception: java.lang.NullPointerException: Null Pointer in Method Invocation at bsh.util.BeanShellBSFEngine.call(Unknown Source) at org.apache.uima.annotator.bsf.BSFAnnotator.initialize(BSFAnnotator.java:161) Can you take a look? I've check in the updated project - you should be able to just check it out. Thanks. -Marshall Olivier Terrier wrote: > Hi Marshall > > When I donated the BSFAnnotator about two years ago I was not very > familiar with the maven-based Apache UIMA build process... And I'm > afraid I'm still not be. > > >> While working on including the BSFAnnotator in the sandbox release, I >> noticed it has 6 jar files in its "lib" directory. The NOTICE file >> says >> that the project includes some components under MPL and SPL; however, >> the information needed to associate each of this included 3rd-party >> > jar > >> files with the proper license is missing. >> >> Can someone who knows identify the source of the following jars: >> >> bsf.jar >> > Apache 2 license > Comes from > http://apache.crihan.fr/dist/jakarta/bsf/binaries/bsf-bin-2.4.0.zip > > >> bsh-bsf.jar >> > No longer needed: can be removed > > >> bsh.jar >> > Dual licensed under both the SPL and LGPL => SPL is in the list of > acceptable licenses available here: > http://www.apache.org/legal/3party.html > Can be replaced by http://www.beanshell.org/bsh-1.3.0.jar (which now > contains the bsh-bsf.jar classes) > > > >> commons-logging-api-1.1.jar >> > Apache 2 license > Comes from > http://archive.apache.org/dist/commons/logging/binaries/commons-logging- > 1.1.zip > > >> js.jar >> > Dual licensed under both the MPL 1.1 and GPL => MPL is in the list of > acceptable licenses available here: > http://www.apache.org/legal/3party.html > Comes from ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R7.zip > > >> log4j-1.2.15.jar >> > Apache 2 license > Comes from > http://www.apache.org/dyn/closer.cgi/logging/log4j/1.2.15/apache-log4j-1 > .2.15.zip > > >> Is there a better way to package / distribute this in binary form? >> > Probably using maven dependencies but I don't have enough maven-skills > to do it myself > > >> Also, I noticed that the POM section for building the documentation is >> commented out - because there is no docbook style documentation. The >> documentation seems limited to a README and some examples. Is there >> additional documentation available for this? >> > No: just the README sorry > > I guess that a real revamping should use the JSR-223 (javax.script) > which is included in Java 1.6 and add support to new popular scripting > languages like groovy, beanshell 2.0 etc... > > > >> -Marshall >> > > >
[jira] Created: (UIMA-1506) update Bean Scripting Framework Annotator with info about licenses and documentation
update Bean Scripting Framework Annotator with info about licenses and documentation Key: UIMA-1506 URL: https://issues.apache.org/jira/browse/UIMA-1506 Project: UIMA Issue Type: Improvement Components: Sandbox-BSFAnnotator Reporter: Marshall Schor Assignee: Marshall Schor Priority: Minor Fix For: 2.3AS update with info received in email: http://markmail.org/thread/e3q5gk6h42jggg5c -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: possibly including the BSFAnnotator in the sandbox release 2.3.0
Olivier Terrier wrote: > Hi Marshall > > When I donated the BSFAnnotator about two years ago I was not very > familiar with the maven-based Apache UIMA build process... And I'm > afraid I'm still not be. > > >> While working on including the BSFAnnotator in the sandbox release, I >> noticed it has 6 jar files in its "lib" directory. The NOTICE file >> says >> that the project includes some components under MPL and SPL; however, >> the information needed to associate each of this included 3rd-party >> > jar > >> files with the proper license is missing. >> >> Can someone who knows identify the source of the following jars: >> >> bsf.jar >> > Apache 2 license > Comes from > http://apache.crihan.fr/dist/jakarta/bsf/binaries/bsf-bin-2.4.0.zip > > >> bsh-bsf.jar >> > No longer needed: can be removed > > >> bsh.jar >> > Dual licensed under both the SPL and LGPL => SPL is in the list of > acceptable licenses available here: > http://www.apache.org/legal/3party.html > Can be replaced by http://www.beanshell.org/bsh-1.3.0.jar (which now > contains the bsh-bsf.jar classes) > > > >> commons-logging-api-1.1.jar >> > Apache 2 license > Comes from > http://archive.apache.org/dist/commons/logging/binaries/commons-logging- > 1.1.zip > > >> js.jar >> > Dual licensed under both the MPL 1.1 and GPL => MPL is in the list of > acceptable licenses available here: > http://www.apache.org/legal/3party.html > Comes from ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R7.zip > > >> log4j-1.2.15.jar >> > Apache 2 license > Comes from > http://www.apache.org/dyn/closer.cgi/logging/log4j/1.2.15/apache-log4j-1 > .2.15.zip > > >> Is there a better way to package / distribute this in binary form? >> > Probably using maven dependencies but I don't have enough maven-skills > to do it myself > > >> Also, I noticed that the POM section for building the documentation is >> commented out - because there is no docbook style documentation. The >> documentation seems limited to a README and some examples. Is there >> additional documentation available for this? >> > No: just the README sorry > > I guess that a real revamping should use the JSR-223 (javax.script) > which is included in Java 1.6 and add support to new popular scripting > languages like groovy, beanshell 2.0 etc... > > > Thanks for responding! I'll update the project with this information. -Marshall >> -Marshall >> > > >
Re: generics: ResourceFactory.produceResource
On Thu, Aug 20, 2009 at 8:11 AM, Jörn Kottmann wrote: > Adam Lally wrote: >> >> On Wed, Aug 19, 2009 at 1:54 PM, Jörn Kottmann wrote: >> >>> >>> The current declaration with out generics: >>> >>> public Resource produceResource(Class aResourceClass, ResourceSpecifier >>> aSpecifier, >>> Map aAdditionalParams) throws >>> ResourceInitializationException; >>> >>> Can it be assumed that aResourceClass is always a class which extends >>> Resource, >>> if so it could be declared as Class. >>> >>> >> >> 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. > That usage doesn't seem quite right. It will only work if the implementation of BaseCollectionReader happens to also implement Resource, otherwise I think it would throw a ClassCastException in produceResource(). I'm in favor of making BaseCollectionReader extend Resource. -Adam
Re: generics: ResourceFactory.produceResource
Adam Lally wrote: On Wed, Aug 19, 2009 at 1:54 PM, Jörn Kottmann wrote: The current declaration with out generics: public Resource produceResource(Class aResourceClass, ResourceSpecifier aSpecifier, Map aAdditionalParams) throws ResourceInitializationException; Can it be assumed that aResourceClass is always a class which extends Resource, if so it could be declared as Class. 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
[jira] Created: (UIMA-1505) Generics for org.apache.uima.analysis_engine classes
Generics for org.apache.uima.analysis_engine classes Key: UIMA-1505 URL: https://issues.apache.org/jira/browse/UIMA-1505 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: possibly including the BSFAnnotator in the sandbox release 2.3.0
Hi Marshall When I donated the BSFAnnotator about two years ago I was not very familiar with the maven-based Apache UIMA build process... And I'm afraid I'm still not be. > While working on including the BSFAnnotator in the sandbox release, I > noticed it has 6 jar files in its "lib" directory. The NOTICE file > says > that the project includes some components under MPL and SPL; however, > the information needed to associate each of this included 3rd-party jar > files with the proper license is missing. > > Can someone who knows identify the source of the following jars: > > bsf.jar Apache 2 license Comes from http://apache.crihan.fr/dist/jakarta/bsf/binaries/bsf-bin-2.4.0.zip > bsh-bsf.jar No longer needed: can be removed > bsh.jar Dual licensed under both the SPL and LGPL => SPL is in the list of acceptable licenses available here: http://www.apache.org/legal/3party.html Can be replaced by http://www.beanshell.org/bsh-1.3.0.jar (which now contains the bsh-bsf.jar classes) > commons-logging-api-1.1.jar Apache 2 license Comes from http://archive.apache.org/dist/commons/logging/binaries/commons-logging- 1.1.zip > js.jar Dual licensed under both the MPL 1.1 and GPL => MPL is in the list of acceptable licenses available here: http://www.apache.org/legal/3party.html Comes from ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R7.zip > log4j-1.2.15.jar Apache 2 license Comes from http://www.apache.org/dyn/closer.cgi/logging/log4j/1.2.15/apache-log4j-1 .2.15.zip > Is there a better way to package / distribute this in binary form? Probably using maven dependencies but I don't have enough maven-skills to do it myself > > Also, I noticed that the POM section for building the documentation is > commented out - because there is no docbook style documentation. The > documentation seems limited to a README and some examples. Is there > additional documentation available for this? No: just the README sorry I guess that a real revamping should use the JSR-223 (javax.script) which is included in Java 1.6 and add support to new popular scripting languages like groovy, beanshell 2.0 etc... > > -Marshall
