- Check the loop termination in readBytes() properly: currently it increments
totalBytesRead while also decrementing nBytesToRead, so when compared to
each other, the loop terminates when the buffer is half full. Only check
for nBytesToRead instead.
- Deal with the possibility of available() returning 0 in readSomeBytes().
Patch by: me
Cherry-picked from
https://github.com/apache/openoffice/commit/7e29bacc90c4b1b9788c3b71dfacd17daecde7a7
"Fix some errors in the scripting module's XInputStreamImpl:"
Change-Id: I951dc10565afa3519b0ddf98de559a7b585b1627
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149156
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
This reverts commit 418533f0af. Turned out that
closing the given URLClassLoader once the script's main class has been loaded
prevents the script from loading further classes located next to that main
class. So abandon the Coverity suggestion that such class loaders should be
closed promptly to avoid resource leaks.
Change-Id: I1bcf83117836cfe317eac9850d413f2c3767bd8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135158
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...from interface to abstract class, in 1c42afc194
"Respect DisableMacrosExecution option in javascript editor". It caused 3rd-
party code like ScriptProviderForooRexx.oxt to fail to install.
Change-Id: I532f27fdce806e471a8551646adbb3aecf80bcee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123745
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
At least on Fedora 34 when building with --with-jdk-home=/usr/lib/jvm/java-16
against java-latest-openjdk-headless-16.0.0.0.36-1.rolling.fc34.x86_64,
CustomTarget_odk/build-examples_java failed with
> ERROR: Exception occurred: An error occurred while enabling: SayHello .../desktop/source/deployment/registry/dp_backend.cxx:645
>
> ERROR: unopkg failed.
>
> make[2]: *** [Makefile:92: .../workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/ScriptingFramework/SayHello/devguide_scriptingframework_SayHello_register_scriptpkg.flag] Error 1
because of
> info:bridges:1209707:1209707:bridges/source/jni_uno/jni_uno2java.cxx:117: exception occurred uno->java: [com.sun.star.lang.WrappedTargetException] java.io.IOException
> java stack trace:
> com.sun.star.lang.WrappedTargetException: java.io.IOException
> at com.sun.star.script.framework.container.UnoPkgContainer.writeUnoPackageDB(UnoPkgContainer.java:279)
> at com.sun.star.script.framework.container.UnoPkgContainer.processUnoPackage(UnoPkgContainer.java:330)
> at com.sun.star.script.framework.provider.ScriptProvider.insertByName(ScriptProvider.java:563)
> Caused by: java.io.IOException
> at com.sun.star.script.framework.container.XMLParserFactory$DefaultParser.write(XMLParserFactory.java:190)
> at com.sun.star.script.framework.container.DeployedUnoPackagesDB.write(DeployedUnoPackagesDB.java:107)
> at com.sun.star.script.framework.container.UnoPkgContainer.writeUnoPackageDB(UnoPkgContainer.java:270)
> ... 2 more
> Caused by: java.lang.IllegalAccessException: class com.sun.star.script.framework.container.XMLParserFactory$DefaultParser cannot access class com.sun.org.apache.xml.internal.serialize.XMLSerializer (in module java.xml) because module java.xml does not export com.sun.org.apache.xml.internal.serialize to unnamed module @50860e85
> at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:385)
> at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:687)
> at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:489)
> at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:128)
> at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:350)
> at java.base/java.lang.Class.newInstance(Class.java:642)
> at com.sun.star.script.framework.container.XMLParserFactory$DefaultParser.write(XMLParserFactory.java:145)
> ... 4 more
The javax.xml.transform functionality appears to be available since Java 1.4, so
it should not be a problem if we unconditionally use it.
Change-Id: Idc31f8f6fb092b6603c537414497d24aec886ce7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113421
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which required the return type of
com.sun.star.script.framework.provider.ClassLoaderFactory.getURLClassLoader to
be changed. (In theory, there could be 3rd-party scripting providers that hook
into the framework and are affected by that incompatible change, but,
practically, chances should be low.)
Change-Id: I083c398726aaf62df7286d6da86b9d2056a5a8c1
Reviewed-on: https://gerrit.libreoffice.org/77146
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It was introduced with 980aa9b06c "#i19331#" (or
at least moved to its current place there, with older traces lost to history),
but its only actual use in the code has since been removed with
8087d5389f "Java new cannot return null".
(In theory, there could be 3rd-party scripting providers that hook into the
framework and use that class, but, practically, chances should be low.)
Change-Id: I8586fccf120c93391308ede547bbeec6fabf2743
Reviewed-on: https://gerrit.libreoffice.org/77142
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...(which is a RuntimeException) around a call of
com.sun.star.script.framework.provider.ClassLoaderFactory.getURLClassLoader.
The catch block was introduced in 3076ea9dc6
"INTEGRATION: CWS scriptingf2 (1.2.2); FILE MERGED", for no apparent reason. It
was introduced along with catch blocks for MalformedURLException and
NoSuitableClassLoaderException, but which have already been removed with
616b3ad504 "java: remove exceptions from throws
clauses that are not".
Change-Id: I8d2890aed1b0f50fe817002cb6f1610c550568f1
Reviewed-on: https://gerrit.libreoffice.org/77140
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Moved shift+tab check to the keyPressed function to provide continuous insertion
and compiled tab-pattern only once
Change-Id: Iffe847fea07295075dc1a280f0697e8c798e8d6f
Reviewed-on: https://gerrit.libreoffice.org/72580
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Beanshell to enable save button only upon modification of script.
Save button disables after script is successfully saved. Also, save
button will be disabled when there are no undoable changes.
ScriptEditorForBeanShell registers listener for unsaved changes.
PlainSourceView triggers listener calls upon modification of script or
after a successful save, which lets to enable/ disable the save button
accordingly.
Change-Id: I32a2fc473924a7c85cdd6004637ab6a0b60acf38
Reviewed-on: https://gerrit.libreoffice.org/69046
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
The Beanshell Editor has a "Close" button in the toolbar.This button can be removed as the window already has a close button.so i remove it from ScriptEditorForBeanShell.java easly .
Change-Id: Icf2e56f664df56a01a2cf1935700ebe1888a7156
Reviewed-on: https://gerrit.libreoffice.org/68273
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
As discussed in the mail thread starting at <http://mail-archives.apache.org/
mod_mbox/openoffice-dev/201806.mbox/%3c651c8fee-b467-421c-eae1-a8710f41692c
@apache.org%3e> "Just a little side note on the scripting framework ...",
external code that uses the Java class
com.sun.star.script.framework.provider.ClassLoaderFactory stopped working
because LO changed that class in binary (and compile-time) incompatible ways
over time.
The class is not listed at
<https://api.libreoffice.org/docs/java/ref/index.html> (and neither at
<http://www.openoffice.org/api/docs/java/ref/overview-summary.html>), so it was
not considered part of the stable URE interface. But it is apparently used by
external code, and it indeed seems to make sense that it is used by external
code that implements scripting providers. (A follow-up commit should therefore
mark the class as part of the stable URE interface. I keep that separate so
that it is easier to backport this functional fix.)
With ScriptProviderForooRexx.oxt from
https://svn.code.sf.net/p/bsf4oorexx/code@r589 installed in LO, "Tools - Macros
- Organize Macros - ooRexx... - My Macros - Create... - Library1 - OK -
Create... - Macro1 - OK - Edit" failed due to
> warn:cui.dialogs:21768:21768:cui/source/dialogs/scriptdlg.cxx:740: Caught exception trying to invoke N3com3sun4star3uno9ExceptionE msg: [jni_uno bridge error] UNO calling Java method invoke: non-UNO exception occurred: java.lang.NoSuchMethodError: com.sun.star.script.framework.provider.ClassLoaderFactory.getURLClassLoader(Lcom/sun/star/script/framework/container/ScriptMetaData;)Ljava/lang/ClassLoader;
> java stack trace:
> java.lang.NoSuchMethodError: com.sun.star.script.framework.provider.ClassLoaderFactory.getURLClassLoader(Lcom/sun/star/script/framework/container/ScriptMetaData;)Ljava/lang/ClassLoader;
> at com.sun.star.script.framework.provider.oorexx.ScriptEditorForooRexx.edit(ScriptEditorForooRexx.java:305)
> at com.sun.star.script.framework.browse.ScriptBrowseNode.invoke(ScriptBrowseNode.java:200)
cae57d2e58 "ClassLoader->URLClassLoader" (which
this commit reverts) had changed the return type of the two getURLClassLoader
overloads from ClassLoader to derived URLClassLoader (and ultimately only for
cosmetic effect; it was leftover from a previous attempt at fixing a Coverity
issue by using URLClassLoader.close(), but which is only available in Java 1.7,
so the attempt had been reverted). That caused the above failure.
And 68cd011c90 "java: reduce scope, make some
methods private" (which this commit also reverts) had changed the second
getURLClassLoader overload (which is not called in the above scenario) from
public to private, which is also a binary-incompatible change.
Other commits removed throws clauses, which is only a compile-time issue but not
a binary-incompatible change. I left those changes in for now, but if need be
they could also be reverted.
Change-Id: I98f533d88c7c1580956c3c281e72a1c78fa3f56f
Reviewed-on: https://gerrit.libreoffice.org/55871
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Add a toolbar A little enhasment for the editor has been done.
Added a toolbar for set of buttons that was previously in a JPanel
and now it is in Jtoolbar in the editor
Change-Id: Ie04232e7824c051f272d69cc109eec0e70ccf921
Reviewed-on: https://gerrit.libreoffice.org/29806
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
and
coverity#1371366 Resource leak on an exceptional path
coverity#1371376 Resource leak on an exceptional path
Change-Id: Ic0fd05f02b1d78a47d4ee924dee8f10811586d0d
Cloneable, odd additional equals overloads, odd hasCode implementation---all
smells like clueless cargo cult. And I see no place where it would get used.
Change-Id: Icca89531ce9181fb47eacfb6fae704f4f45012a9
Damjan Jovanovic