Re: Issues not closed for 2.3.0 release
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? -Marshall
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: Issues not closed for 2.3.0 release
Also I think we need to fix 1607 - wrong log format - Jerry is working on it. - Burn.
Re: Issues not closed for 2.3.0 release
Marshall, I cant close https://issues.apache.org/jira/browse/UIMA-1531 yet.
Over the weekend I've discovered why the Logger ignores uima
formatter defined in Logger.properties and logs entries using the default
formatter (xml). It turns out that the java LogManager uses system
classloader to load the formatter class. Here is the method where this magic
occurs:
Formatter getFormatterProperty(String name, Formatter defaultValue) {
String val = getProperty(name);
try {
if (val != null) {
Class clz = ClassLoader.getSystemClassLoader().loadClass(val);
return (Formatter) clz.newInstance();
}
} catch (Exception ex) {
// We got one of a variety of exceptions in creating the
// class or creating an instance.
// Drop through.
}
// We got an exception. Return the defaultValue.
return defaultValue;
}
It surprising that that this java component silently ignores errors. Since
the uima formatter class is not loaded into the system classloader by the
UimaBootstrap, the LogManager returns a default formatter from the method
above.
I dont know how to fix this problem yet. One possibility is to change
UimaBootstrap to load jars/classes into the system classloader. Another
possibility is to load this one class into the system classloader although
I've failed trying to do this. I attempted to augment
the system classloader using reflection to inject a new URL like so:
URL url = new
URL(jar:file:/C:/uima/releases/2.3.3-04/apache-uima/lib/uima-core.jar!/java/util/logging/XMLFormatter.class);
Class[] parameters = new Class[]{URL.class};
URLClassLoader sysloader = (URLClassLoader)
ClassLoader.getSystemClassLoader();
Class sysclass = URLClassLoader.class;
try {
Method method = sysclass.getDeclaredMethod(addURL, parameters);
method.setAccessible(true);
method.invoke(sysloader, new Object[]{url});
} catch (Throwable t) {
t.printStackTrace();
throw new IOException(Error, could not add URL to system
classloader);
}//end try catch
Again, for some reason this doesnt work.I can inject jar files into the
system classloader using the above technique but not individual classes from
jars.
Jerry
On Sun, Oct 18, 2009 at 4:22 PM, Marshall Schor m...@schor.com wrote:
Hi everyone,
I'm itching to get the 2.3.0 release done.
Of the issues that are open, reopened, or in-progress, most are now
being deferred to past this release.
The ones left that may need to be worked on before the release is done
include:
(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
(Eddie)UIMA-1611 https://issues.apache.org/jira/browse/UIMA-1611
UimacppServiceControlled need to implement isStopped()
https://issues.apache.org/jira/browse/UIMA-1611
(Marshall) UIMA-1539 https://issues.apache.org/jira/browse/UIMA-1539
Update READMEs for 2.3.0 release
https://issues.apache.org/jira/browse/UIMA-1539
(Jerry) UIMA-1153 https://issues.apache.org/jira/browse/UIMA-1153
thread safety issue with sample flow controller
AdvancedFixedFlowController
https://issues.apache.org/jira/browse/UIMA-1153
(Eddie)UIMA-1038
https://issues.apache.org/jira/browse/UIMA-1038setUimaClasspath.sh
should export library paths for interoperability with UIMA C++
https://issues.apache.org/jira/browse/UIMA-1038
(Jerry) UIMA-1531
https://issues.apache.org/jira/browse/UIMA-1531Need a script to launch
a UIMA-AS service via RunWithJarPath
https://issues.apache.org/jira/browse/UIMA-1531
(Jerry) UIMA-1484 https://issues.apache.org/jira/browse/UIMA-1484
Update UIMA-AS Documentation
https://issues.apache.org/jira/browse/UIMA-1484
Could the people in (parenthesis) take the lead in looking at these and
try and close out these issues?
Thanks! -Marshall
[jira] Commented: (UIMA-1611) UimacppServiceControlled need to implement isStopped()
[ https://issues.apache.org/jira/browse/UIMA-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12767344#action_12767344 ] Eddie Epstein commented on UIMA-1611: - Changes in the core patch file were aleady committed via uima-1616. UimacppServiceControlled need to implement isStopped() -- Key: UIMA-1611 URL: https://issues.apache.org/jira/browse/UIMA-1611 Project: UIMA Issue Type: Bug Reporter: Bhavani Iyer Assignee: Bhavani Iyer Attachments: UIMA-1611-uimaj-as-activemq.patch, UIMA-1611-uimaj-as-core.patch Required in order for UIMA_Service to undeploy and shutdown when handling a stop or quiesce and stop command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1611) UimacppServiceControlled need to implement isStopped()
[ https://issues.apache.org/jira/browse/UIMA-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eddie Epstein closed UIMA-1611. --- Resolution: Fixed UimacppServiceControlled need to implement isStopped() -- Key: UIMA-1611 URL: https://issues.apache.org/jira/browse/UIMA-1611 Project: UIMA Issue Type: Bug Reporter: Bhavani Iyer Assignee: Bhavani Iyer Attachments: UIMA-1611-uimaj-as-activemq.patch, UIMA-1611-uimaj-as-core.patch Required in order for UIMA_Service to undeploy and shutdown when handling a stop or quiesce and stop command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Issues not closed for 2.3.0 release
Jaroslaw Cwiklik wrote:
Marshall, I cant close https://issues.apache.org/jira/browse/UIMA-1531 yet.
Over the weekend I've discovered why the Logger ignores uima
formatter defined in Logger.properties and logs entries using the default
formatter (xml). It turns out that the java LogManager uses system
classloader to load the formatter class. Here is the method where this magic
occurs:
Formatter getFormatterProperty(String name, Formatter defaultValue) {
String val = getProperty(name);
try {
if (val != null) {
Class clz = ClassLoader.getSystemClassLoader().loadClass(val);
return (Formatter) clz.newInstance();
}
} catch (Exception ex) {
// We got one of a variety of exceptions in creating the
// class or creating an instance.
// Drop through.
}
// We got an exception. Return the defaultValue.
return defaultValue;
}
It surprising that that this java component silently ignores errors. Since
the uima formatter class is not loaded into the system classloader by the
UimaBootstrap, the LogManager returns a default formatter from the method
above.
I dont know how to fix this problem yet. One possibility is to change
UimaBootstrap to load jars/classes into the system classloader. Another
possibility is to load this one class into the system classloader although
I've failed trying to do this. I attempted to augment
the system classloader using reflection to inject a new URL like so:
URL url = new
URL(jar:file:/C:/uima/releases/2.3.3-04/apache-uima/lib/uima-core.jar!/java/util/logging/XMLFormatter.class);
Class[] parameters = new Class[]{URL.class};
URLClassLoader sysloader = (URLClassLoader)
ClassLoader.getSystemClassLoader();
Class sysclass = URLClassLoader.class;
try {
Method method = sysclass.getDeclaredMethod(addURL, parameters);
method.setAccessible(true);
method.invoke(sysloader, new Object[]{url});
} catch (Throwable t) {
t.printStackTrace();
throw new IOException(Error, could not add URL to system
classloader);
}//end try catch
Again, for some reason this doesnt work.I can inject jar files into the
system classloader using the above technique but not individual classes from
jars.
Because the system classloader only understands jars
and directories. You can load the class file into
memory and feed the byte[] to the classloader with
the same kind of reflection techniques you use above.
Note that I'm _not_ recommending this, simply pointing
it out.
--Thilo
Jerry
On Sun, Oct 18, 2009 at 4:22 PM, Marshall Schor m...@schor.com wrote:
Hi everyone,
I'm itching to get the 2.3.0 release done.
Of the issues that are open, reopened, or in-progress, most are now
being deferred to past this release.
The ones left that may need to be worked on before the release is done
include:
(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
(Eddie)UIMA-1611 https://issues.apache.org/jira/browse/UIMA-1611
UimacppServiceControlled need to implement isStopped()
https://issues.apache.org/jira/browse/UIMA-1611
(Marshall) UIMA-1539 https://issues.apache.org/jira/browse/UIMA-1539
Update READMEs for 2.3.0 release
https://issues.apache.org/jira/browse/UIMA-1539
(Jerry) UIMA-1153 https://issues.apache.org/jira/browse/UIMA-1153
thread safety issue with sample flow controller
AdvancedFixedFlowController
https://issues.apache.org/jira/browse/UIMA-1153
(Eddie)UIMA-1038
https://issues.apache.org/jira/browse/UIMA-1038setUimaClasspath.sh
should export library paths for interoperability with UIMA C++
https://issues.apache.org/jira/browse/UIMA-1038
(Jerry) UIMA-1531
https://issues.apache.org/jira/browse/UIMA-1531Need a script to launch
a UIMA-AS service via RunWithJarPath
https://issues.apache.org/jira/browse/UIMA-1531
(Jerry) UIMA-1484 https://issues.apache.org/jira/browse/UIMA-1484
Update UIMA-AS Documentation
https://issues.apache.org/jira/browse/UIMA-1484
Could the people in (parenthesis) take the lead in looking at these and
try and close out these issues?
Thanks! -Marshall
Re: Issues not closed for 2.3.0 release
Can we put the bootstrap class in uima-core so it will then have all those classes in the system path. - Burn.
[jira] Closed: (UIMA-1038) setUimaClasspath.sh should export library paths for interoperability with UIMA C++
[ https://issues.apache.org/jira/browse/UIMA-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eddie Epstein closed UIMA-1038. --- Resolution: Fixed Fix (to export) was checked in with changes for UIMA-1573 UIMA-1555 setUimaClasspath.sh should export library paths for interoperability with UIMA C++ -- Key: UIMA-1038 URL: https://issues.apache.org/jira/browse/UIMA-1038 Project: UIMA Issue Type: Bug Reporter: Eddie Epstein Assignee: Eddie Epstein Priority: Minor The current script only works if LD_LIBRARY_PATH (or DYLD_LIBRARY_PATH on Mac) has previously been exported in the current environment. This issue applies to both core framework and uima-as versions of the script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1624) Uima AS service should start listeners on its input queue on succesfull initialization only
Uima AS service should start listeners on its input queue on succesfull initialization only --- Key: UIMA-1624 URL: https://issues.apache.org/jira/browse/UIMA-1624 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Jerry Cwiklik Fix For: 2.3AS Currently UIMA AS service JMS listener starts as soon as it is initialized. There are two listeners started on an input queue each with a different selector. One listener is for processing GetMeta while the other for Process messages. The listeners start in separate threads and become active despite the fact that the rest of service components may not have finished initializing. This creates a problem if the service fails in annotator code while initializing. Since the GetMeta listener is active, it may fetch GetMeta request from a queue and try to process it. The current code prevents the GetMeta from being processed since the service has not finished initializing. If the AE initialization fails, the getMeta is never returned to the client. Fix input queue listeners so that they become active only after successful initialization of AEs. In case of aggregates, allow listeners on temp reply queues to start immediately so that GetMeta replies from delegates can be processed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1625) AnalysisEngmeManagementImpl getAnalysisTime() and getCasesProcessedPerSecond() should include remote service call time.
AnalysisEngmeManagementImpl getAnalysisTime() and getCasesProcessedPerSecond() should include remote service call time. --- Key: UIMA-1625 URL: https://issues.apache.org/jira/browse/UIMA-1625 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Bhavani Iyer Assignee: Bhavani Iyer Service call time is recorded but not included in analysis time and in computing CASes per second. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1625) AnalysisEngmeManagementImpl getAnalysisTime() and getCasesProcessedPerSecond() should include remote service call time.
[ https://issues.apache.org/jira/browse/UIMA-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavani Iyer updated UIMA-1625: --- Attachment: UIMA-1625-uimaj-core.patch getAnalysisTime() return sum of analysisTime and serviceCallTime. This way applications can call one API to get the time in AE and do not need to know whether AE is local or remote. getCASesPerSecond() returns getAnalysisTime() / numProcessed. numProcessed now accumulated for services. AnalysisEngmeManagementImpl getAnalysisTime() and getCasesProcessedPerSecond() should include remote service call time. --- Key: UIMA-1625 URL: https://issues.apache.org/jira/browse/UIMA-1625 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Bhavani Iyer Assignee: Bhavani Iyer Attachments: UIMA-1625-uimaj-core.patch Service call time is recorded but not included in analysis time and in computing CASes per second. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Issues not closed for 2.3.0 release
The basic issue seems to be that part of the initialization sequence for logging is not finding a handler class. The basic fix for this seems to be to arrange that the class for the handler be found in the initial application class path. This is what the System class path seems to mean (taken from the Javadocs for ClassLoader.getSystemClassLoader()). I noticed that the IBM Java loads this class slightly differently than the Java Jerry described. I didn't find a spec for this, so I suspect different Javas may load this in different ways. The IBM Java 5 uses the last non-system class loader on the call stack. This might be a fine distinction, coming into play only when loading from the extensions classes. A general solution with respect to using the bootstrap loader would be to not use the java -jar xxx form but instead use the java -cp org.apache.uima.bootstrap.UimaBootstrap etc. form, and put into the -cp classpath the uima-core jar, where the handler(s) are, along with the bootstrap jar. Another alternative would be to build the UimaBootstrap jar so that it included uimaj-core, or vice-versa. (I think that would work - but haven't test it). I'm not sure of all the implications of this, though. Putting the bootstrap class into uimaj-core, and setting the manifest to specify starting with the bootstrap, and then changing the start to java -jar uima-core.jar, is (in more detail) what Burn was suggesting below, I think. Both of these approaches put uimaj-core classes at the root level of the application (i.e., System) class-loader chain. I can't think of any cases where that would not be OK; can anyone else? -Marshall Burn Lewis wrote: Can we put the bootstrap class in uima-core so it will then have all those classes in the system path. - Burn.
[jira] Resolved: (UIMA-1625) AnalysisEngmeManagementImpl getAnalysisTime() and getCasesProcessedPerSecond() should include remote service call time.
[ https://issues.apache.org/jira/browse/UIMA-1625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eddie Epstein resolved UIMA-1625. - Resolution: Fixed AnalysisEngmeManagementImpl getAnalysisTime() and getCasesProcessedPerSecond() should include remote service call time. --- Key: UIMA-1625 URL: https://issues.apache.org/jira/browse/UIMA-1625 Project: UIMA Issue Type: Bug Components: Core Java Framework Reporter: Bhavani Iyer Assignee: Bhavani Iyer Attachments: UIMA-1625-uimaj-core.patch Service call time is recorded but not included in analysis time and in computing CASes per second. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
