ibm-netrexx

Question ad JDBC and Java extensions

Classic

List

Threaded

12 messages Options

Rony G. Flatscher (wu-wien)

Question ad JDBC and Java extensions

Hi there,

a request for comments for those on this list who may have an idea about the root cause of the
behaviour described in <https://sourceforge.net/p/bsf4oorexx/mailman/message/32822060/> and opinions
about the next planned steps.

Brief background: if one places a jar file in one of the java.ext.dirs then all classes of such jars
extend Java and are available to all Java applications. Or with other words, there is no need to
place the jar on to the classpath.

In a project where the JavaPlugin for browsers is used to allow executing Rexx scripts embedded in
html-text by any browser on any operating system, currently one needs to create a jar that includes
the BSF4ooRexx jar, making the infrastructure very unhandy. Hence the motivation to place the ooRexx
scripting support to java.ext.dirs.

However, the JDBC samples do not run anymore as no connection can be successfully established. By
trial and error it turns out, that the JDBC sample works again, if moving the JDBC driver to one of
the java.ext.dirs directories as well.

It is unclear what the reason behind this is and whether this only a problem in the context of JDBC.

If one can reliably place the BSF4ooRexx jar into one of the java.ext.dirs, then ooRexx can be used
as a scripting language by all Java applications that know about it without a need to install the
BSF4ooRexx jar themselves. If this is possible, then it might be an option for the NetRexx jar as
well, hence asking this question in this list.

But please, follow up at the above BSF4ooRexx developer mailing list to not burden this list.

I would post the results of any discussions then in this forum, whatever the outcome is.

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Rony G. Flatscher (wu-wien)

Re: Question ad JDBC and Java extensions

Hi there,

the reason is probably with java.sql.DriverManager which uses the class loader of the application to
load the JDBC driver. The extension class loader is not able to see classes that are not in Java
extension directories.

Still, a feedback about the ramification at the bsf4oorexx developer list would be helpful about
placing the script language jar into a Java extension directory or not. Pro and contra arguments
might apply to NetRexx as well.

---rony

On 11.09.2014 20:18, Rony G. Flatscher (wu-wien) wrote:

> Hi there,
>
> a request for comments for those on this list who may have an idea about the root cause of the
> behaviour described in <https://sourceforge.net/p/bsf4oorexx/mailman/message/32822060/> and opinions
> about the next planned steps.
>
> Brief background: if one places a jar file in one of the java.ext.dirs then all classes of such jars
> extend Java and are available to all Java applications. Or with other words, there is no need to
> place the jar on to the classpath.
>
> In a project where the JavaPlugin for browsers is used to allow executing Rexx scripts embedded in
> html-text by any browser on any operating system, currently one needs to create a jar that includes
> the BSF4ooRexx jar, making the infrastructure very unhandy. Hence the motivation to place the ooRexx
> scripting support to java.ext.dirs.
>
> However, the JDBC samples do not run anymore as no connection can be successfully established. By
> trial and error it turns out, that the JDBC sample works again, if moving the JDBC driver to one of
> the java.ext.dirs directories as well.
>
> It is unclear what the reason behind this is and whether this only a problem in the context of JDBC.
>
> If one can reliably place the BSF4ooRexx jar into one of the java.ext.dirs, then ooRexx can be used
> as a scripting language by all Java applications that know about it without a need to install the
> BSF4ooRexx jar themselves. If this is possible, then it might be an option for the NetRexx jar as
> well, hence asking this question in this list.
>
> But please, follow up at the above BSF4ooRexx developer mailing list to not burden this list.
>
> I would post the results of any discussions then in this forum, whatever the outcome is.
>
> ---rony
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

ThSITC

Re: Question ad JDBC and Java extensions

Rony,

whilst I am *not* using bsf4oorexx at all (I'm working in NetRexx,
everyone does know) ...

... when You do have NetRexx/Java Testcases for Your issues with JDBC I
could try, when You
like/want ... ;-)

Thomas.

PS: See You at least at the next RexxLA Meeting in Vienna, 2015, anyway :-)
======================================================================
Am 11.09.2014 um 21:20 schrieb Rony G. Flatscher (wu-wien):

> Hi there,
>
> the reason is probably with java.sql.DriverManager which uses the class loader of the application to
> load the JDBC driver. The extension class loader is not able to see classes that are not in Java
> extension directories.
>
> Still, a feedback about the ramification at the bsf4oorexx developer list would be helpful about
> placing the script language jar into a Java extension directory or not. Pro and contra arguments
> might apply to NetRexx as well.
>
> ---rony
>
> On 11.09.2014 20:18, Rony G. Flatscher (wu-wien) wrote:
>> Hi there,
>>
>> a request for comments for those on this list who may have an idea about the root cause of the
>> behaviour described in <https://sourceforge.net/p/bsf4oorexx/mailman/message/32822060/> and opinions
>> about the next planned steps.
>>
>> Brief background: if one places a jar file in one of the java.ext.dirs then all classes of such jars
>> extend Java and are available to all Java applications. Or with other words, there is no need to
>> place the jar on to the classpath.
>>
>> In a project where the JavaPlugin for browsers is used to allow executing Rexx scripts embedded in
>> html-text by any browser on any operating system, currently one needs to create a jar that includes
>> the BSF4ooRexx jar, making the infrastructure very unhandy. Hence the motivation to place the ooRexx
>> scripting support to java.ext.dirs.
>>
>> However, the JDBC samples do not run anymore as no connection can be successfully established. By
>> trial and error it turns out, that the JDBC sample works again, if moving the JDBC driver to one of
>> the java.ext.dirs directories as well.
>>
>> It is unclear what the reason behind this is and whether this only a problem in the context of JDBC.
>>
>> If one can reliably place the BSF4ooRexx jar into one of the java.ext.dirs, then ooRexx can be used
>> as a scripting language by all Java applications that know about it without a need to install the
>> BSF4ooRexx jar themselves. If this is possible, then it might be an option for the NetRexx jar as
>> well, hence asking this question in this list.
>>
>> But please, follow up at the above BSF4ooRexx developer mailing list to not burden this list.
>>
>> I would post the results of any discussions then in this forum, whatever the outcome is.
>>
>> ---rony
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Thomas Schneider, Vienna, Austria (Europe) :-)

www.thsitc.com
www.db-123.com

ThSITC

Re: Question ad JDBC and Java extensions

In reply to this post by Rony G. Flatscher (wu-wien)

As nearly *all* of You do know, I did always *ADVOCATE* to avoid all
those CLASSPATH Mystics, and
put the classes to be used into the proper java Directories ...

BUT:

As I have been punished too much (for me) for my in-adequate ideas how
to extend and improve
NetRexx as a Language, for the future, which shall come along anyways ...

I did (nearly) SHUTUP as requested and wanted and need ;-)

Do everything in Your Life the Way You Want &/ Like to live Your Live !
Full-Stop :-) :-) :-)

(c) Thomas Schneider, * 11.08.1946 - oo (until his DEATH, of Course ...
;-) ;-) ;-))
=======================================================================
Am 11.09.2014 um 21:20 schrieb Rony G. Flatscher (wu-wien):

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Thomas Schneider, Vienna, Austria (Europe) :-)

www.thsitc.com
www.db-123.com

Kermit Kiser

Re: Question ad JDBC and Java extensions

In reply to this post by Rony G. Flatscher (wu-wien)

Hi Rony --

We fixed a similar problem with the NetRexx translator about two years
ago. The fix involved adding the thread context loader to the class
loader chain I think. See NetRexx issues 86 and 87 and associated
patches for more information.

-- Kermit

On 9/11/2014 12:20 PM, Rony G. Flatscher (wu-wien) wrote:

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

ThSITC

Re: Question ad JDBC and Java extensions

Anyway:

Both Ronys question as well as his (own) probable answer are *excellent*
information Sources for
all of us ...
... and (for me) Kermit Kiser is *My Master of the NetRexx Universe*
Anyway :-) :-) :-)

Thank You all, and Rony, please: FREEDOM and PIECE for all of us Developers!
What I really *do hate* are *intellectual*, and even more, *physical FIGHTS*

*Fighting is USELESS*, it does *NOT* solve any problems, it *does
create* ...

... most probably ...

MORE PROBLEMS

(as History seems to Show)

Thus: Let's meet all in Vienna, 2015, and have FUN here together
(besides straightforward work,
of course)´...

Kind regards from Vienna, Austria (Europe: No Kangoroohs, still, it's a
PITY :-;))

Thomas Schneider
IT-Consulting (ThSITC)

www.db-123.com
www.thsitc.com
==================================================================
Am 12.09.2014 um 00:03 schrieb Kermit Kiser:

> Hi Rony --
>
> We fixed a similar problem with the NetRexx translator about two years
> ago. The fix involved adding the thread context loader to the class
> loader chain I think. See NetRexx issues 86 and 87 and associated
> patches for more information.
>
> -- Kermit
>
> On 9/11/2014 12:20 PM, Rony G. Flatscher (wu-wien) wrote:
>> Hi there,
>>
>> the reason is probably with java.sql.DriverManager which uses the
>> class loader of the application to
>> load the JDBC driver. The extension class loader is not able to see
>> classes that are not in Java
>> extension directories.
>>
>> Still, a feedback about the ramification at the bsf4oorexx developer
>> list would be helpful about
>> placing the script language jar into a Java extension directory or
>> not. Pro and contra arguments
>> might apply to NetRexx as well.
>>
>> ---rony
>>
>> On 11.09.2014 20:18, Rony G. Flatscher (wu-wien) wrote:
>>> Hi there,
>>>
>>> a request for comments for those on this list who may have an idea
>>> about the root cause of the
>>> behaviour described in
>>> <https://sourceforge.net/p/bsf4oorexx/mailman/message/32822060/> and
>>> opinions
>>> about the next planned steps.
>>>
>>> Brief background: if one places a jar file in one of the
>>> java.ext.dirs then all classes of such jars
>>> extend Java and are available to all Java applications. Or with
>>> other words, there is no need to
>>> place the jar on to the classpath.
>>>
>>> In a project where the JavaPlugin for browsers is used to allow
>>> executing Rexx scripts embedded in
>>> html-text by any browser on any operating system, currently one
>>> needs to create a jar that includes
>>> the BSF4ooRexx jar, making the infrastructure very unhandy. Hence
>>> the motivation to place the ooRexx
>>> scripting support to java.ext.dirs.
>>>
>>> However, the JDBC samples do not run anymore as no connection can be
>>> successfully established. By
>>> trial and error it turns out, that the JDBC sample works again, if
>>> moving the JDBC driver to one of
>>> the java.ext.dirs directories as well.
>>>
>>> It is unclear what the reason behind this is and whether this only a
>>> problem in the context of JDBC.
>>>
>>> If one can reliably place the BSF4ooRexx jar into one of the
>>> java.ext.dirs, then ooRexx can be used
>>> as a scripting language by all Java applications that know about it
>>> without a need to install the
>>> BSF4ooRexx jar themselves. If this is possible, then it might be an
>>> option for the NetRexx jar as
>>> well, hence asking this question in this list.
>>>
>>> But please, follow up at the above BSF4ooRexx developer mailing list
>>> to not burden this list.
>>>
>>> I would post the results of any discussions then in this forum,
>>> whatever the outcome is.
>>>
>>> ---rony
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Thomas Schneider, Vienna, Austria (Europe) :-)

www.thsitc.com
www.db-123.com

Rony G. Flatscher (wu-wien)

Re: Question ad JDBC and Java extensions

In reply to this post by Kermit Kiser

Hi Kermit,

On 12.09.2014 00:03, Kermit Kiser wrote:

We fixed a similar problem with the NetRexx translator about two years ago. The fix involved
adding the thread context loader to the class loader chain I think. See NetRexx issues 86 and 87
and associated patches for more information.

As I have been following this list only, I have no working knowledge for the URLs to get to the
issues page to become quickly able to study the issues and the patches. Could you please provide an
URL to the issue tracker?

While testing this awkward behaviour I have checked on the class loaders that were in effect, the
thread context class loader was the application class loader and would have found the JDBC driver.
It is this subtlety that made me address this list as well. I would expect that NetRexx being put
into the Java extension directory (which would make sense, as then all Java-apps have access to it)
would exhibit the same problem. (Currently running extremely tight on time in an 80hrs week, hence
no free resources to transcribe the JDBC example. Will do it, whenever getting some longer time slot
in a piece.)

When testing, I found out that one could forgo copying the jars to the Java extension directory, if
at Java startup you supply

    -Djava.ext.dirs="...dirs..."

pointing to the directories where the jars (NetRexx and optionally derby) are located. The classes
in those jars will then be loaded with the extension class loader.

---rony

On 9/11/2014 12:20 PM, Rony G. Flatscher (wu-wien) wrote:

Hi there,

the reason is probably with java.sql.DriverManager which uses the class loader of the application to
load the JDBC driver. The extension class loader is not able to see classes that are not in Java
extension directories.

Still, a feedback about the ramification at the bsf4oorexx developer list would be helpful about
placing the script language jar into a Java extension directory or not. Pro and contra arguments
might apply to NetRexx as well.

---rony

On 11.09.2014 20:18, Rony G. Flatscher (wu-wien) wrote:

Hi there,

a request for comments for those on this list who may have an idea about the root cause of the
behaviour described in <https://sourceforge.net/p/bsf4oorexx/mailman/message/32822060/> and
opinions
about the next planned steps.

Brief background: if one places a jar file in one of the java.ext.dirs then all classes of such
jars
extend Java and are available to all Java applications. Or with other words, there is no need to
place the jar on to the classpath.

In a project where the JavaPlugin for browsers is used to allow executing Rexx scripts embedded in
html-text by any browser on any operating system, currently one needs to create a jar that includes
the BSF4ooRexx jar, making the infrastructure very unhandy. Hence the motivation to place the
ooRexx
scripting support to java.ext.dirs.

However, the JDBC samples do not run anymore as no connection can be successfully established. By
trial and error it turns out, that the JDBC sample works again, if moving the JDBC driver to one of
the java.ext.dirs directories as well.

It is unclear what the reason behind this is and whether this only a problem in the context of
JDBC.

If one can reliably place the BSF4ooRexx jar into one of the java.ext.dirs, then ooRexx can be used
as a scripting language by all Java applications that know about it without a need to install the
BSF4ooRexx jar themselves. If this is possible, then it might be an option for the NetRexx jar as
well, hence asking this question in this list.

But please, follow up at the above BSF4ooRexx developer mailing list to not burden this list.

I would post the results of any discussions then in this forum, whatever the outcome is.

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Kermit Kiser

Re: Question ad JDBC and Java extensions

Hi Rony;

The NetRexx project page with repository and issue tracking links is here:

https://kenai.com/projects/netrexx

Issue 86 was that interpreted NetRexx code could not access external modules if the translator was installed in a Java extensions directory.

NETREXX-86: https://kenai.com/jira/browse/NETREXX-86

NetRexx interpreter fails to load classes from classpath or container environment if NetRexxC.jar is installed in the Java extensions library (lib\ext)

The fix applied to module RxProxyLoader was to use the thread context classloader if one is available rather than the extension loader.

The related Issue 87 was that the NetRexx translator could not load a Java compiler from the classpath if the translator module was installed in a Java extensions directory.

NETREXX-87: https://kenai.com/jira/browse/NETREXX-87

NetRexx compiler cannot load Java compiler from classpath if NetRexxC.jar is installed in Java extensions library (jre\lib\ext)

The fix applied to module RxTranslator was to load and call the Java compiler via reflection using the thread context classloader if the NetRexx translator is installed in a Java extensions directory (detected by checking if current classloader parent link is null).

Does that help any?

-- Kermit

On 9/12/2014 2:45 AM, Rony G. Flatscher (wu-wien) wrote:

Hi Kermit,

On 12.09.2014 00:03, Kermit Kiser wrote:

We fixed a similar problem with the NetRexx translator about two years ago. The fix involved
adding the thread context loader to the class loader chain I think. See NetRexx issues 86 and 87
and associated patches for more information.

As I have been following this list only, I have no working knowledge for the URLs to get to the
issues page to become quickly able to study the issues and the patches. Could you please provide an
URL to the issue tracker?

While testing this awkward behaviour I have checked on the class loaders that were in effect, the
thread context class loader was the application class loader and would have found the JDBC driver.
It is this subtlety that made me address this list as well. I would expect that NetRexx being put
into the Java extension directory (which would make sense, as then all Java-apps have access to it)
would exhibit the same problem. (Currently running extremely tight on time in an 80hrs week, hence
no free resources to transcribe the JDBC example. Will do it, whenever getting some longer time slot
in a piece.)

When testing, I found out that one could forgo copying the jars to the Java extension directory, if
at Java startup you supply

    -Djava.ext.dirs="...dirs..."

pointing to the directories where the jars (NetRexx and optionally derby) are located. The classes
in those jars will then be loaded with the extension class loader.

---rony

On 9/11/2014 12:20 PM, Rony G. Flatscher (wu-wien) wrote:

Hi there,

the reason is probably with java.sql.DriverManager which uses the class loader of the application to
load the JDBC driver. The extension class loader is not able to see classes that are not in Java
extension directories.

Still, a feedback about the ramification at the bsf4oorexx developer list would be helpful about
placing the script language jar into a Java extension directory or not. Pro and contra arguments
might apply to NetRexx as well.

---rony

On 11.09.2014 20:18, Rony G. Flatscher (wu-wien) wrote:

Hi there,

It is unclear what the reason behind this is and whether this only a problem in the context of
JDBC.

But please, follow up at the above BSF4ooRexx developer mailing list to not burden this list.

I would post the results of any discussions then in this forum, whatever the outcome is.

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Rony G. Flatscher (wu-wien)

Re: Question ad JDBC and Java extensions

Hi Kermit,

thank you very much for your kind information, including the links to the issues that got fixed!

The version of Apache BSF that I use (a set of Java classes) uses the thread context class loader first, then the classes class loader (the extension class loader) that is employed for carrying out the class loading on behalf of the script.

Will try later today to duplicate the setting with NetRexx later this day and will come back with my findings. (My take has been that the problem I face is a pure Java related problem and as such NetRexx may be prone to it as well.)

---rony

On 14.09.2014 05:19, Kermit Kiser wrote:

On 9/12/2014 2:45 AM, Rony G. Flatscher (wu-wien) wrote:

Hi Kermit,

On 12.09.2014 00:03, Kermit Kiser wrote:

We fixed a similar problem with the NetRexx translator about two years ago. The fix involved
adding the thread context loader to the class loader chain I think. See NetRexx issues 86 and 87
and associated patches for more information.

As I have been following this list only, I have no working knowledge for the URLs to get to the
issues page to become quickly able to study the issues and the patches. Could you please provide an
URL to the issue tracker?

While testing this awkward behaviour I have checked on the class loaders that were in effect, the
thread context class loader was the application class loader and would have found the JDBC driver.
It is this subtlety that made me address this list as well. I would expect that NetRexx being put
into the Java extension directory (which would make sense, as then all Java-apps have access to it)
would exhibit the same problem. (Currently running extremely tight on time in an 80hrs week, hence
no free resources to transcribe the JDBC example. Will do it, whenever getting some longer time slot
in a piece.)

When testing, I found out that one could forgo copying the jars to the Java extension directory, if
at Java startup you supply

    -Djava.ext.dirs="...dirs..."

pointing to the directories where the jars (NetRexx and optionally derby) are located. The classes
in those jars will then be loaded with the extension class loader.

---rony

On 9/11/2014 12:20 PM, Rony G. Flatscher (wu-wien) wrote:

Hi there,

the reason is probably with java.sql.DriverManager which uses the class loader of the application to
load the JDBC driver. The extension class loader is not able to see classes that are not in Java
extension directories.

Still, a feedback about the ramification at the bsf4oorexx developer list would be helpful about
placing the script language jar into a Java extension directory or not. Pro and contra arguments
might apply to NetRexx as well.

---rony

On 11.09.2014 20:18, Rony G. Flatscher (wu-wien) wrote:

Hi there,

It is unclear what the reason behind this is and whether this only a problem in the context of
JDBC.

But please, follow up at the above BSF4ooRexx developer mailing list to not burden this list.

I would post the results of any discussions then in this forum, whatever the outcome is.

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Rony G. Flatscher (wu-wien)

A problem moving 3.03GA2 to java.ext.dirs (Re: Question ad JDBC and Java extensions

Hi Kermit,

while coming up with a transcription to NetRexx and starting to test (and then, if being able to reproduce, making the transcribed code nicer), I ran into a problem when moving NetRexxC.jar to java.ext.dirs:

... cut ... 
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
 86 +++ exit
    +++ ^^^^
    +++ Severe Error: Internal error: RxParser checknest CLASS 40
# Tokens: SBS(SOS.S.S,SOS)BS; {method} {dropTable}({stmt}<=>{java}.{sql}.{Statement},{tableName}<=>{String}) {static}; x02
Processing of 'jdbc.nrx' failed [41 errors]
... cut ...

This happened the moment I issued the command to interpret having NetRexxC.jar in java.ext.dirs (either copied physically or using netrexx_java to do a -Djava.ext.dirs=path2NetRexxCJar-dir):

NetRexxC.bat -exec jdbc

Trying to compile with:

NetRexxC.bat jdbc

yields in essence the same error, starting out

F:\work\svn\netrexx\netrexxc\tags\3.03GA2\bin>java -cp E:\jdk1.7.0_25\lib\tools.jar;.;E:\jdk1.7.0_25\db\lib\derby.jar;.  org.
netrexx.process.NetRexxC jdbc
NetRexx portable processor 3.03 NetRexx '3.03', build 6-20140505-2347
Copyright (c) RexxLA, 2011,2014.   All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program jdbc.nrx
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
... cut ...
 86 +++ exit
    +++ ^^^^
    +++ Severe Error: Internal error: RxParser checknest CLASS 40
# Tokens: SBS(SOS.S.S,SOS)BS; {method} {dropTable}({stmt}<=>{java}.{sql}.{Statement},{tableName}<=>{String}) {static}; x02
java.lang.Exception: # RxQuit traceback for internal.error
        at org.netrexx.process.RxQuit.<init>(RxQuit.nrx:57)
        at org.netrexx.process.RxQuit.<init>(RxQuit.nrx:43)
        at org.netrexx.process.RxParser.checknest(RxParser.nrx:1120)
        at org.netrexx.process.RxMethod.endmethod2(RxMethod.nrx:1040)
        at org.netrexx.process.RxMethod.endmethod(RxMethod.nrx:1029)
        at org.netrexx.process.RxParser.parseprogram(RxParser.nrx:190)
        at org.netrexx.process.RxTranslator.dotranslate(RxTranslator.nrx:434)
        at org.netrexx.process.RxTranslator.translate(RxTranslator.nrx:260)
        at org.netrexx.process.NetRexxC.process(NetRexxC.nrx:241)
        at org.netrexx.process.NetRexxC.main2(NetRexxC.nrx:171)
        at org.netrexx.process.NetRexxC.main2(NetRexxC.nrx:160)
        at org.netrexx.process.NetRexxC.main2(NetRexxC.nrx:158)
        at org.netrexx.process.NetRexxC.main(NetRexxC.nrx:97)
Compilation of 'jdbc.nrx' failed [41 errors]

Removibing NetRexxC.jar from java.ext.dirs and adding it to back to the classpath resolves the issue and the program runs, in interpreted and in compiled mode.

---

This is with NetRexx 3.03GA2 (from svn's tags directory), using Java 32-bit 1.7.0_25 and using derby from that JDK (jdk1.7.0_25\db\lib\derby.jar) on Windows XP SP3.

Short of time, here's the (ugly, because in the first stages of debugging) code, named "jdbc.nrx":

import java.sql.

/* ... cut commented BSF4ooRexx code, so line numbers may be different, if you get an error! ... */
 
-- tmpDriverMgr = java.sql.DriverManager.class
tmpDriverMgr = DriverManager.class
say (tmpDriverMgr.toString())":"     pp(DriverManager.class)
say DriverManager.class.getClassLoader()

    do
         

say Thread.class.toString()
-- currThread=ThreadClz.currentThread()
currThread=Thread.currentThread()
ctCll=currThread.getContextClassLoader()
say "contextClassLoader="ctCll ctCll.toString()


say "---"

      tmp=org.apache.derby.jdbc.EmbeddedDriver.class
      tmp.newInstance()
say "tmp               ="pp(tmp.toString())
say "tmp.getClassLoader()="pp(tmp.getClassLoader()) pp(tmp.toString())
say "---"

         -- make the dbms connection and create a statement
      props      = java.util.Properties()
      props.put("user", "user1")
      props.put("password", "user1")

ctCll=currThread.getContextClassLoader()
say "current thread's contextClassLoader:" pp(ctCll.toString()) "BEFORE driverMgr.getConnection(...)"
say "---"
      -- conn = driverMgr.getConnection('jdbc:derby:derbyDB;create=true',props)
      conn=java.sql.DriverManager.getConnection('jdbc:derby:derbyDB;create=true',props)
      statement=conn.createStatement()
    end -- when do

dropTable( statement, "test") -- make sure table gets dropped, if it exists (from a previous run)
   -- create the table
statement.executeUpdate("CREATE TABLE test( name char(42), place char(42))")

   -- insert some rows
statement.executeUpdate("INSERT INTO test (name, place) VALUES('Kermit Kieser',    'Hawaii'   )")
statement.executeUpdate("INSERT INTO test (name, place) VALUES('Rene Jansen',      'Amsterdam')")
statement.executeUpdate("INSERT INTO test (name, place) VALUES('Rony G. Flatscher','Vienna'   )")

   -- select database content: specify query and execute to get result set
rs = statement.executeQuery('select name, place from test order by name')
loop while rs.next()              -- iterate over rows in result set
  say (rs.getString("name")) "from" (rs.getString("place"))
end
say

   -- use an aggregate query, defining an alias name (for retrieval by column name)
rs = statement.executeQuery('select count(*) as total_fans from test')
   -- calculate total
loop while rs.next()
   -- the following statement uses the alias name to address the column
  say "NetRexx has at least" rs.getString("Total_Fans") "fans! (Using alias name 'Total_Fans' as argument.)"

   /* the following statement forces a specific signature to be used, making it clear
      that the Rexx string is to be used as a Java int(eger);
      using the message "bsf.invokeStrict" expects the name of the method first and then
      pairs of typeIndicator, value for each argument: */
  idx1=int 1
  say "NetRexx has at least" rs.getString(idx1) "fans! (Using positional argument.)"
end
exit


method dropTable(stmt=java.sql.Statement, tableName=String) static          -- drop a table
  do -- loop for 1
      stmt.executeUpdate("DROP TABLE" tableName)
  catch Exception
      say "table does not exist?"
  end


method pp(str=Object) static
  return "["str.toString()"]"

Running the above program successfully (having everything on classpath), yields e.g.:

F:\work\svn\netrexx\netrexxc\tags\3.03GA2\bin>java jdbc
class java.sql.DriverManager: [class java.sql.DriverManager]

class java.lang.Thread
contextClassLoader=sun.misc.Launcher$AppClassLoader@7ced01 sun.misc.Launcher$AppClassLoader@7ced01
---
tmp               =[class org.apache.derby.jdbc.EmbeddedDriver]
tmp.getClassLoader()=[sun.misc.Launcher$AppClassLoader@7ced01] [class org.apache.derby.jdbc.EmbeddedDriver]
---
current thread's contextClassLoader: [sun.misc.Launcher$AppClassLoader@7ced01] BEFORE driverMgr.getConnection(...)
---
Kermit Kieser                              from Hawaii
Rene Jansen                                from Amsterdam
Rony G. Flatscher                          from Vienna

NetRexx has at least 3 fans! (Using alias name 'Total_Fans' as argument.)
NetRexx has at least 3 fans! (Using positional argument.)

The challenge would be to get the code running in interpreted mode, when a) NetRexxC.jar is in java.ext.dirs and derby.jar is on classpath.

---rony

P.S.: Would have a zip created showing the command, containing the program, the environment and the output, in case an issue should be opened for this (being really tight on time and not having an id on Kenai to be allowed to file an issue, maybe I can send it as an attachment to someone, if more information is needed?).

On 14.09.2014 12:37, Rony G. Flatscher (wu-wien) wrote:

Hi Kermit,

thank you very much for your kind information, including the links to the issues that got fixed!

The version of Apache BSF that I use (a set of Java classes) uses the thread context class loader first, then the classes class loader (the extension class loader) that is employed for carrying out the class loading on behalf of the script.

Will try later today to duplicate the setting with NetRexx later this day and will come back with my findings. (My take has been that the problem I face is a pure Java related problem and as such NetRexx may be prone to it as well.)

---rony

On 14.09.2014 05:19, Kermit Kiser wrote:
Hi Rony;

The NetRexx project page with repository and issue tracking links is here:

https://kenai.com/projects/netrexx

Issue 86 was that interpreted NetRexx code could not access external modules if the translator was installed in a Java extensions directory.

NETREXX-86: https://kenai.com/jira/browse/NETREXX-86

NetRexx interpreter fails to load classes from classpath or container environment if NetRexxC.jar is installed in the Java extensions library (lib\ext)

The fix applied to module RxProxyLoader was to use the thread context classloader if one is available rather than the extension loader.

The related Issue 87 was that the NetRexx translator could not load a Java compiler from the classpath if the translator module was installed in a Java extensions directory.

NETREXX-87: https://kenai.com/jira/browse/NETREXX-87

NetRexx compiler cannot load Java compiler from classpath if NetRexxC.jar is installed in Java extensions library (jre\lib\ext)

The fix applied to module RxTranslator was to load and call the Java compiler via reflection using the thread context classloader if the NetRexx translator is installed in a Java extensions directory (detected by checking if current classloader parent link is null).

Does that help any?

-- Kermit

On 9/12/2014 2:45 AM, Rony G. Flatscher (wu-wien) wrote:
Hi Kermit,

On 12.09.2014 00:03, Kermit Kiser wrote:
We fixed a similar problem with the NetRexx translator about two years ago. The fix involved
adding the thread context loader to the class loader chain I think. See NetRexx issues 86 and 87
and associated patches for more information.
As I have been following this list only, I have no working knowledge for the URLs to get to the
issues page to become quickly able to study the issues and the patches. Could you please provide an
URL to the issue tracker?

While testing this awkward behaviour I have checked on the class loaders that were in effect, the
thread context class loader was the application class loader and would have found the JDBC driver.
It is this subtlety that made me address this list as well. I would expect that NetRexx being put
into the Java extension directory (which would make sense, as then all Java-apps have access to it)
would exhibit the same problem. (Currently running extremely tight on time in an 80hrs week, hence
no free resources to transcribe the JDBC example. Will do it, whenever getting some longer time slot
in a piece.)

When testing, I found out that one could forgo copying the jars to the Java extension directory, if
at Java startup you supply

    -Djava.ext.dirs="...dirs..."

pointing to the directories where the jars (NetRexx and optionally derby) are located. The classes
in those jars will then be loaded with the extension class loader.

---rony
On 9/11/2014 12:20 PM, Rony G. Flatscher (wu-wien) wrote:
Hi there,

the reason is probably with java.sql.DriverManager which uses the class loader of the application to
load the JDBC driver. The extension class loader is not able to see classes that are not in Java
extension directories.

Still, a feedback about the ramification at the bsf4oorexx developer list would be helpful about
placing the script language jar into a Java extension directory or not. Pro and contra arguments
might apply to NetRexx as well.

---rony

On 11.09.2014 20:18, Rony G. Flatscher (wu-wien) wrote:
Hi there,

a request for comments for those on this list who may have an idea about the root cause of the
behaviour described in <https://sourceforge.net/p/bsf4oorexx/mailman/message/32822060/> and
opinions
about the next planned steps.

Brief background: if one places a jar file in one of the java.ext.dirs then all classes of such
jars
extend Java and are available to all Java applications. Or with other words, there is no need to
place the jar on to the classpath.

In a project where the JavaPlugin for browsers is used to allow executing Rexx scripts embedded in
html-text by any browser on any operating system, currently one needs to create a jar that includes
the BSF4ooRexx jar, making the infrastructure very unhandy. Hence the motivation to place the
ooRexx
scripting support to java.ext.dirs.

However, the JDBC samples do not run anymore as no connection can be successfully established. By
trial and error it turns out, that the JDBC sample works again, if moving the JDBC driver to one of
the java.ext.dirs directories as well.

It is unclear what the reason behind this is and whether this only a problem in the context of
JDBC.

If one can reliably place the BSF4ooRexx jar into one of the java.ext.dirs, then ooRexx can be used
as a scripting language by all Java applications that know about it without a need to install the
BSF4ooRexx jar themselves. If this is possible, then it might be an option for the NetRexx jar as
well, hence asking this question in this list.

But please, follow up at the above BSF4ooRexx developer mailing list to not burden this list.

I would post the results of any discussions then in this forum, whatever the outcome is.

---rony 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Rony G. Flatscher (wu-wien)

A working alternative ... (Re: A problem moving 3.03GA2 to java.ext.dirs (Re: Question ad JDBC and Java extensions

Hi there,

will try to open a bug report with java.sql.DriverManager.

In the meantime I tried another approach to accessing the derby database using a class that implements the DataSource interface. This works! So one is able to place the scripting library into java.ext.dirs and have the path to the database library on classpath, which is a great workaround. In addition Oracle suggests to use this newer technique for connecting to databases using JDBC.

Here's the relevant sequence for Apache Derby in ooRexx notation, which you can straightforwardly transcribe to NetRexx:

ds=.bsf~new("org.apache.derby.jdbc.EmbeddedDataSource") -- create an instance of this class
ds~setDatabaseName("RexxTestDB")
ds~setCreateDatabase("create")      -- always create it, if it does not exist

conn=ds~getConnection("user1","user1") -- userid/pwd
statement=conn~createStatement

---rony

On 14.09.2014 17:17, Rony G. Flatscher (wu-wien) wrote:

... cut ... 
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
 86 +++ exit
    +++ ^^^^
    +++ Severe Error: Internal error: RxParser checknest CLASS 40
# Tokens: SBS(SOS.S.S,SOS)BS; {method} {dropTable}({stmt}<=>{java}.{sql}.{Statement},{tableName}<=>{String}) {static}; x02
Processing of 'jdbc.nrx' failed [41 errors]
... cut ...

This happened the moment I issued the command to interpret having NetRexxC.jar in java.ext.dirs (either copied physically or using netrexx_java to do a -Djava.ext.dirs=path2NetRexxCJar-dir):

NetRexxC.bat -exec jdbc

Trying to compile with:

NetRexxC.bat jdbc

yields in essence the same error, starting out

F:\work\svn\netrexx\netrexxc\tags\3.03GA2\bin>java -cp E:\jdk1.7.0_25\lib\tools.jar;.;E:\jdk1.7.0_25\db\lib\derby.jar;.  org.
netrexx.process.NetRexxC jdbc
NetRexx portable processor 3.03 NetRexx '3.03', build 6-20140505-2347
Copyright (c) RexxLA, 2011,2014.   All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program jdbc.nrx
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
... cut ...
 86 +++ exit
    +++ ^^^^
    +++ Severe Error: Internal error: RxParser checknest CLASS 40
# Tokens: SBS(SOS.S.S,SOS)BS; {method} {dropTable}({stmt}<=>{java}.{sql}.{Statement},{tableName}<=>{String}) {static}; x02
java.lang.Exception: # RxQuit traceback for internal.error
        at org.netrexx.process.RxQuit.<init>(RxQuit.nrx:57)
        at org.netrexx.process.RxQuit.<init>(RxQuit.nrx:43)
        at org.netrexx.process.RxParser.checknest(RxParser.nrx:1120)
        at org.netrexx.process.RxMethod.endmethod2(RxMethod.nrx:1040)
        at org.netrexx.process.RxMethod.endmethod(RxMethod.nrx:1029)
        at org.netrexx.process.RxParser.parseprogram(RxParser.nrx:190)
        at org.netrexx.process.RxTranslator.dotranslate(RxTranslator.nrx:434)
        at org.netrexx.process.RxTranslator.translate(RxTranslator.nrx:260)
        at org.netrexx.process.NetRexxC.process(NetRexxC.nrx:241)
        at org.netrexx.process.NetRexxC.main2(NetRexxC.nrx:171)
        at org.netrexx.process.NetRexxC.main2(NetRexxC.nrx:160)
        at org.netrexx.process.NetRexxC.main2(NetRexxC.nrx:158)
        at org.netrexx.process.NetRexxC.main(NetRexxC.nrx:97)
Compilation of 'jdbc.nrx' failed [41 errors]

import java.sql.

/* ... cut commented BSF4ooRexx code, so line numbers may be different, if you get an error! ... */
 
-- tmpDriverMgr = java.sql.DriverManager.class
tmpDriverMgr = DriverManager.class
say (tmpDriverMgr.toString())":"     pp(DriverManager.class)
say DriverManager.class.getClassLoader()

    do
         

say Thread.class.toString()
-- currThread=ThreadClz.currentThread()
currThread=Thread.currentThread()
ctCll=currThread.getContextClassLoader()
say "contextClassLoader="ctCll ctCll.toString()


say "---"

      tmp=org.apache.derby.jdbc.EmbeddedDriver.class
      tmp.newInstance()
say "tmp               ="pp(tmp.toString())
say "tmp.getClassLoader()="pp(tmp.getClassLoader()) pp(tmp.toString())
say "---"

         -- make the dbms connection and create a statement
      props      = java.util.Properties()
      props.put("user", "user1")
      props.put("password", "user1")

ctCll=currThread.getContextClassLoader()
say "current thread's contextClassLoader:" pp(ctCll.toString()) "BEFORE driverMgr.getConnection(...)"
say "---"
      -- conn = driverMgr.getConnection('jdbc:derby:derbyDB;create=true',props)
      conn=java.sql.DriverManager.getConnection('jdbc:derby:derbyDB;create=true',props)
      statement=conn.createStatement()
    end -- when do

dropTable( statement, "test") -- make sure table gets dropped, if it exists (from a previous run)
   -- create the table
statement.executeUpdate("CREATE TABLE test( name char(42), place char(42))")

   -- insert some rows
statement.executeUpdate("INSERT INTO test (name, place) VALUES('Kermit Kieser',    'Hawaii'   )")
statement.executeUpdate("INSERT INTO test (name, place) VALUES('Rene Jansen',      'Amsterdam')")
statement.executeUpdate("INSERT INTO test (name, place) VALUES('Rony G. Flatscher','Vienna'   )")

   -- select database content: specify query and execute to get result set
rs = statement.executeQuery('select name, place from test order by name')
loop while rs.next()              -- iterate over rows in result set
  say (rs.getString("name")) "from" (rs.getString("place"))
end
say

   -- use an aggregate query, defining an alias name (for retrieval by column name)
rs = statement.executeQuery('select count(*) as total_fans from test')
   -- calculate total
loop while rs.next()
   -- the following statement uses the alias name to address the column
  say "NetRexx has at least" rs.getString("Total_Fans") "fans! (Using alias name 'Total_Fans' as argument.)"

   /* the following statement forces a specific signature to be used, making it clear
      that the Rexx string is to be used as a Java int(eger);
      using the message "bsf.invokeStrict" expects the name of the method first and then
      pairs of typeIndicator, value for each argument: */
  idx1=int 1
  say "NetRexx has at least" rs.getString(idx1) "fans! (Using positional argument.)"
end
exit


method dropTable(stmt=java.sql.Statement, tableName=String) static          -- drop a table
  do -- loop for 1
      stmt.executeUpdate("DROP TABLE" tableName)
  catch Exception
      say "table does not exist?"
  end


method pp(str=Object) static
  return "["str.toString()"]"

Running the above program successfully (having everything on classpath), yields e.g.:

F:\work\svn\netrexx\netrexxc\tags\3.03GA2\bin>java jdbc
class java.sql.DriverManager: [class java.sql.DriverManager]

class java.lang.Thread
contextClassLoader=sun.misc.Launcher$AppClassLoader@7ced01 sun.misc.Launcher$AppClassLoader@7ced01
---
tmp               =[class org.apache.derby.jdbc.EmbeddedDriver]
tmp.getClassLoader()=[sun.misc.Launcher$AppClassLoader@7ced01] [class org.apache.derby.jdbc.EmbeddedDriver]
---
current thread's contextClassLoader: [sun.misc.Launcher$AppClassLoader@7ced01] BEFORE driverMgr.getConnection(...)
---
Kermit Kieser                              from Hawaii
Rene Jansen                                from Amsterdam
Rony G. Flatscher                          from Vienna

NetRexx has at least 3 fans! (Using alias name 'Total_Fans' as argument.)
NetRexx has at least 3 fans! (Using positional argument.)

On 14.09.2014 12:37, Rony G. Flatscher (wu-wien) wrote:

Hi Kermit,

thank you very much for your kind information, including the links to the issues that got fixed!

The version of Apache BSF that I use (a set of Java classes) uses the thread context class loader first, then the classes class loader (the extension class loader) that is employed for carrying out the class loading on behalf of the script.

Will try later today to duplicate the setting with NetRexx later this day and will come back with my findings. (My take has been that the problem I face is a pure Java related problem and as such NetRexx may be prone to it as well.)

---rony

On 14.09.2014 05:19, Kermit Kiser wrote:
Hi Rony;

The NetRexx project page with repository and issue tracking links is here:

https://kenai.com/projects/netrexx

Issue 86 was that interpreted NetRexx code could not access external modules if the translator was installed in a Java extensions directory.

NETREXX-86: https://kenai.com/jira/browse/NETREXX-86

NetRexx interpreter fails to load classes from classpath or container environment if NetRexxC.jar is installed in the Java extensions library (lib\ext)

The fix applied to module RxProxyLoader was to use the thread context classloader if one is available rather than the extension loader.

The related Issue 87 was that the NetRexx translator could not load a Java compiler from the classpath if the translator module was installed in a Java extensions directory.

NETREXX-87: https://kenai.com/jira/browse/NETREXX-87

NetRexx compiler cannot load Java compiler from classpath if NetRexxC.jar is installed in Java extensions library (jre\lib\ext)

The fix applied to module RxTranslator was to load and call the Java compiler via reflection using the thread context classloader if the NetRexx translator is installed in a Java extensions directory (detected by checking if current classloader parent link is null).

Does that help any?

-- Kermit

On 9/12/2014 2:45 AM, Rony G. Flatscher (wu-wien) wrote:
Hi Kermit,

On 12.09.2014 00:03, Kermit Kiser wrote:
We fixed a similar problem with the NetRexx translator about two years ago. The fix involved
adding the thread context loader to the class loader chain I think. See NetRexx issues 86 and 87
and associated patches for more information.
As I have been following this list only, I have no working knowledge for the URLs to get to the
issues page to become quickly able to study the issues and the patches. Could you please provide an
URL to the issue tracker?

While testing this awkward behaviour I have checked on the class loaders that were in effect, the
thread context class loader was the application class loader and would have found the JDBC driver.
It is this subtlety that made me address this list as well. I would expect that NetRexx being put
into the Java extension directory (which would make sense, as then all Java-apps have access to it)
would exhibit the same problem. (Currently running extremely tight on time in an 80hrs week, hence
no free resources to transcribe the JDBC example. Will do it, whenever getting some longer time slot
in a piece.)

When testing, I found out that one could forgo copying the jars to the Java extension directory, if
at Java startup you supply

    -Djava.ext.dirs="...dirs..."

pointing to the directories where the jars (NetRexx and optionally derby) are located. The classes
in those jars will then be loaded with the extension class loader.

---rony
On 9/11/2014 12:20 PM, Rony G. Flatscher (wu-wien) wrote:
Hi there,

the reason is probably with java.sql.DriverManager which uses the class loader of the application to
load the JDBC driver. The extension class loader is not able to see classes that are not in Java
extension directories.

Still, a feedback about the ramification at the bsf4oorexx developer list would be helpful about
placing the script language jar into a Java extension directory or not. Pro and contra arguments
might apply to NetRexx as well.

---rony

On 11.09.2014 20:18, Rony G. Flatscher (wu-wien) wrote:
Hi there,

a request for comments for those on this list who may have an idea about the root cause of the
behaviour described in <https://sourceforge.net/p/bsf4oorexx/mailman/message/32822060/> and
opinions
about the next planned steps.

Brief background: if one places a jar file in one of the java.ext.dirs then all classes of such
jars
extend Java and are available to all Java applications. Or with other words, there is no need to
place the jar on to the classpath.

In a project where the JavaPlugin for browsers is used to allow executing Rexx scripts embedded in
html-text by any browser on any operating system, currently one needs to create a jar that includes
the BSF4ooRexx jar, making the infrastructure very unhandy. Hence the motivation to place the
ooRexx
scripting support to java.ext.dirs.

However, the JDBC samples do not run anymore as no connection can be successfully established. By
trial and error it turns out, that the JDBC sample works again, if moving the JDBC driver to one of
the java.ext.dirs directories as well.

It is unclear what the reason behind this is and whether this only a problem in the context of
JDBC.

If one can reliably place the BSF4ooRexx jar into one of the java.ext.dirs, then ooRexx can be used
as a scripting language by all Java applications that know about it without a need to install the
BSF4ooRexx jar themselves. If this is possible, then it might be an option for the NetRexx jar as
well, hence asking this question in this list.

But please, follow up at the above BSF4ooRexx developer mailing list to not burden this list.

I would post the results of any discussions then in this forum, whatever the outcome is.

---rony 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

ThSITC

Re: A working alternative ... (Re: A problem moving 3.03GA2 to java.ext.dirs (Re: Question ad JDBC and Java extensions

Rony,

I shall want&need to *personally APOLOGIZE* for any *wrong comments* I did make here on IBM-NetRexx
about Your Intentions.

Please accept, and let Us All Continue to Make Up a Better Use of the ...

#################################################################
# Family of Rexx Languages
#################################################################

Looking forward to SEE You all next Year at the Vienna RexxLA meeting :-)

By the way:

Is the RexxLA Group still alive, *or* have I been thrown out due to lack of money,
and therefore Payments of any annual fees ?

*OR* did the RexxLA Group beome so quiet nowadays ?

Watching (quietly !) the ooRexx News (weekly) but ...
... my impression is, that both Groups are becoming less and less NEW message-full :-(

Correct me, all, when I'm wrong, pls !

Thomas Schneider
************************************************************************

Am 15.09.2014 um 16:11 schrieb Rony G. Flatscher (wu-wien):

ds=.bsf~new("org.apache.derby.jdbc.EmbeddedDataSource") -- create an instance of this class
ds~setDatabaseName("RexxTestDB")
ds~setCreateDatabase("create")      -- always create it, if it does not exist

conn=ds~getConnection("user1","user1") -- userid/pwd
statement=conn~createStatement

---rony

On 14.09.2014 17:17, Rony G. Flatscher (wu-wien) wrote:

... cut ... 
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
 86 +++ exit
    +++ ^^^^
    +++ Severe Error: Internal error: RxParser checknest CLASS 40
# Tokens: SBS(SOS.S.S,SOS)BS; {method} {dropTable}({stmt}<=>{java}.{sql}.{Statement},{tableName}<=>{String}) {static}; x02
Processing of 'jdbc.nrx' failed [41 errors]
... cut ...

This happened the moment I issued the command to interpret having NetRexxC.jar in java.ext.dirs (either copied physically or using netrexx_java to do a -Djava.ext.dirs=path2NetRexxCJar-dir):

NetRexxC.bat -exec jdbc

Trying to compile with:

NetRexxC.bat jdbc

yields in essence the same error, starting out

F:\work\svn\netrexx\netrexxc\tags\3.03GA2\bin>java -cp E:\jdk1.7.0_25\lib\tools.jar;.;E:\jdk1.7.0_25\db\lib\derby.jar;.  org.
netrexx.process.NetRexxC jdbc
NetRexx portable processor 3.03 NetRexx '3.03', build 6-20140505-2347
Copyright (c) RexxLA, 2011,2014.   All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program jdbc.nrx
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
    +++ Error: The class 'netrexx.lang.Rexx' cannot be found
... cut ...
 86 +++ exit
    +++ ^^^^
    +++ Severe Error: Internal error: RxParser checknest CLASS 40
# Tokens: SBS(SOS.S.S,SOS)BS; {method} {dropTable}({stmt}<=>{java}.{sql}.{Statement},{tableName}<=>{String}) {static}; x02
java.lang.Exception: # RxQuit traceback for internal.error
        at org.netrexx.process.RxQuit.<init>(RxQuit.nrx:57)
        at org.netrexx.process.RxQuit.<init>(RxQuit.nrx:43)
        at org.netrexx.process.RxParser.checknest(RxParser.nrx:1120)
        at org.netrexx.process.RxMethod.endmethod2(RxMethod.nrx:1040)
        at org.netrexx.process.RxMethod.endmethod(RxMethod.nrx:1029)
        at org.netrexx.process.RxParser.parseprogram(RxParser.nrx:190)
        at org.netrexx.process.RxTranslator.dotranslate(RxTranslator.nrx:434)
        at org.netrexx.process.RxTranslator.translate(RxTranslator.nrx:260)
        at org.netrexx.process.NetRexxC.process(NetRexxC.nrx:241)
        at org.netrexx.process.NetRexxC.main2(NetRexxC.nrx:171)
        at org.netrexx.process.NetRexxC.main2(NetRexxC.nrx:160)
        at org.netrexx.process.NetRexxC.main2(NetRexxC.nrx:158)
        at org.netrexx.process.NetRexxC.main(NetRexxC.nrx:97)
Compilation of 'jdbc.nrx' failed [41 errors]

import java.sql.

/* ... cut commented BSF4ooRexx code, so line numbers may be different, if you get an error! ... */
 
-- tmpDriverMgr = java.sql.DriverManager.class
tmpDriverMgr = DriverManager.class
say (tmpDriverMgr.toString())":"     pp(DriverManager.class)
say DriverManager.class.getClassLoader()

    do
         

say Thread.class.toString()
-- currThread=ThreadClz.currentThread()
currThread=Thread.currentThread()
ctCll=currThread.getContextClassLoader()
say "contextClassLoader="ctCll ctCll.toString()


say "---"

      tmp=org.apache.derby.jdbc.EmbeddedDriver.class
      tmp.newInstance()
say "tmp               ="pp(tmp.toString())
say "tmp.getClassLoader()="pp(tmp.getClassLoader()) pp(tmp.toString())
say "---"

         -- make the dbms connection and create a statement
      props      = java.util.Properties()
      props.put("user", "user1")
      props.put("password", "user1")

ctCll=currThread.getContextClassLoader()
say "current thread's contextClassLoader:" pp(ctCll.toString()) "BEFORE driverMgr.getConnection(...)"
say "---"
      -- conn = driverMgr.getConnection('jdbc:derby:derbyDB;create=true',props)
      conn=java.sql.DriverManager.getConnection('jdbc:derby:derbyDB;create=true',props)
      statement=conn.createStatement()
    end -- when do

dropTable( statement, "test") -- make sure table gets dropped, if it exists (from a previous run)
   -- create the table
statement.executeUpdate("CREATE TABLE test( name char(42), place char(42))")

   -- insert some rows
statement.executeUpdate("INSERT INTO test (name, place) VALUES('Kermit Kieser',    'Hawaii'   )")
statement.executeUpdate("INSERT INTO test (name, place) VALUES('Rene Jansen',      'Amsterdam')")
statement.executeUpdate("INSERT INTO test (name, place) VALUES('Rony G. Flatscher','Vienna'   )")

   -- select database content: specify query and execute to get result set
rs = statement.executeQuery('select name, place from test order by name')
loop while rs.next()              -- iterate over rows in result set
  say (rs.getString("name")) "from" (rs.getString("place"))
end
say

   -- use an aggregate query, defining an alias name (for retrieval by column name)
rs = statement.executeQuery('select count(*) as total_fans from test')
   -- calculate total
loop while rs.next()
   -- the following statement uses the alias name to address the column
  say "NetRexx has at least" rs.getString("Total_Fans") "fans! (Using alias name 'Total_Fans' as argument.)"

   /* the following statement forces a specific signature to be used, making it clear
      that the Rexx string is to be used as a Java int(eger);
      using the message "bsf.invokeStrict" expects the name of the method first and then
      pairs of typeIndicator, value for each argument: */
  idx1=int 1
  say "NetRexx has at least" rs.getString(idx1) "fans! (Using positional argument.)"
end
exit


method dropTable(stmt=java.sql.Statement, tableName=String) static          -- drop a table
  do -- loop for 1
      stmt.executeUpdate("DROP TABLE" tableName)
  catch Exception
      say "table does not exist?"
  end


method pp(str=Object) static
  return "["str.toString()"]"

Running the above program successfully (having everything on classpath), yields e.g.:

F:\work\svn\netrexx\netrexxc\tags\3.03GA2\bin>java jdbc
class java.sql.DriverManager: [class java.sql.DriverManager]

class java.lang.Thread
contextClassLoader=sun.misc.Launcher$AppClassLoader@7ced01 sun.misc.Launcher$AppClassLoader@7ced01
---
tmp               =[class org.apache.derby.jdbc.EmbeddedDriver]
tmp.getClassLoader()=[sun.misc.Launcher$AppClassLoader@7ced01] [class org.apache.derby.jdbc.EmbeddedDriver]
---
current thread's contextClassLoader: [sun.misc.Launcher$AppClassLoader@7ced01] BEFORE driverMgr.getConnection(...)
---
Kermit Kieser                              from Hawaii
Rene Jansen                                from Amsterdam
Rony G. Flatscher                          from Vienna

NetRexx has at least 3 fans! (Using alias name 'Total_Fans' as argument.)
NetRexx has at least 3 fans! (Using positional argument.)

On 14.09.2014 12:37, Rony G. Flatscher (wu-wien) wrote:

Hi Kermit,

thank you very much for your kind information, including the links to the issues that got fixed!

The version of Apache BSF that I use (a set of Java classes) uses the thread context class loader first, then the classes class loader (the extension class loader) that is employed for carrying out the class loading on behalf of the script.

Will try later today to duplicate the setting with NetRexx later this day and will come back with my findings. (My take has been that the problem I face is a pure Java related problem and as such NetRexx may be prone to it as well.)

---rony

On 14.09.2014 05:19, Kermit Kiser wrote:
Hi Rony;

The NetRexx project page with repository and issue tracking links is here:

https://kenai.com/projects/netrexx

Issue 86 was that interpreted NetRexx code could not access external modules if the translator was installed in a Java extensions directory.

NETREXX-86: https://kenai.com/jira/browse/NETREXX-86

NetRexx interpreter fails to load classes from classpath or container environment if NetRexxC.jar is installed in the Java extensions library (lib\ext)

The fix applied to module RxProxyLoader was to use the thread context classloader if one is available rather than the extension loader.

The related Issue 87 was that the NetRexx translator could not load a Java compiler from the classpath if the translator module was installed in a Java extensions directory.

NETREXX-87: https://kenai.com/jira/browse/NETREXX-87

NetRexx compiler cannot load Java compiler from classpath if NetRexxC.jar is installed in Java extensions library (jre\lib\ext)

The fix applied to module RxTranslator was to load and call the Java compiler via reflection using the thread context classloader if the NetRexx translator is installed in a Java extensions directory (detected by checking if current classloader parent link is null).

Does that help any?

-- Kermit

On 9/12/2014 2:45 AM, Rony G. Flatscher (wu-wien) wrote:
Hi Kermit,

On 12.09.2014 00:03, Kermit Kiser wrote:
We fixed a similar problem with the NetRexx translator about two years ago. The fix involved
adding the thread context loader to the class loader chain I think. See NetRexx issues 86 and 87
and associated patches for more information.
As I have been following this list only, I have no working knowledge for the URLs to get to the
issues page to become quickly able to study the issues and the patches. Could you please provide an
URL to the issue tracker?

While testing this awkward behaviour I have checked on the class loaders that were in effect, the
thread context class loader was the application class loader and would have found the JDBC driver.
It is this subtlety that made me address this list as well. I would expect that NetRexx being put
into the Java extension directory (which would make sense, as then all Java-apps have access to it)
would exhibit the same problem. (Currently running extremely tight on time in an 80hrs week, hence
no free resources to transcribe the JDBC example. Will do it, whenever getting some longer time slot
in a piece.)

When testing, I found out that one could forgo copying the jars to the Java extension directory, if
at Java startup you supply

    -Djava.ext.dirs="...dirs..."

pointing to the directories where the jars (NetRexx and optionally derby) are located. The classes
in those jars will then be loaded with the extension class loader.

---rony
On 9/11/2014 12:20 PM, Rony G. Flatscher (wu-wien) wrote:
Hi there,

the reason is probably with java.sql.DriverManager which uses the class loader of the application to
load the JDBC driver. The extension class loader is not able to see classes that are not in Java
extension directories.

Still, a feedback about the ramification at the bsf4oorexx developer list would be helpful about
placing the script language jar into a Java extension directory or not. Pro and contra arguments
might apply to NetRexx as well.

---rony

On 11.09.2014 20:18, Rony G. Flatscher (wu-wien) wrote:
Hi there,

a request for comments for those on this list who may have an idea about the root cause of the
behaviour described in <https://sourceforge.net/p/bsf4oorexx/mailman/message/32822060/> and
opinions
about the next planned steps.

Brief background: if one places a jar file in one of the java.ext.dirs then all classes of such
jars
extend Java and are available to all Java applications. Or with other words, there is no need to
place the jar on to the classpath.

In a project where the JavaPlugin for browsers is used to allow executing Rexx scripts embedded in
html-text by any browser on any operating system, currently one needs to create a jar that includes
the BSF4ooRexx jar, making the infrastructure very unhandy. Hence the motivation to place the
ooRexx
scripting support to java.ext.dirs.

However, the JDBC samples do not run anymore as no connection can be successfully established. By
trial and error it turns out, that the JDBC sample works again, if moving the JDBC driver to one of
the java.ext.dirs directories as well.

It is unclear what the reason behind this is and whether this only a problem in the context of
JDBC.

If one can reliably place the BSF4ooRexx jar into one of the java.ext.dirs, then ooRexx can be used
as a scripting language by all Java applications that know about it without a need to install the
BSF4ooRexx jar themselves. If this is possible, then it might be an option for the NetRexx jar as
well, hence asking this question in this list.

But please, follow up at the above BSF4ooRexx developer mailing list to not burden this list.

I would post the results of any discussions then in this forum, whatever the outcome is.

---rony 

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Thomas Schneider, Vienna, Austria (Europe) :-)

www.thsitc.com
www.db-123.com