testing against jar files

[Rick Hillegas <Ri...@Sun.COM>]

I'm working on a feature which only surfaces if you are running against 
jar files. Is there a template for writing a test which only executes 
when derbyall runs against jar files?

Thanks,
-Rick

Re: testing against jar files

["David W. Van Couvering" <Da...@Sun.COM>]

As part of my classloader work I had written a utility that finds out 
where a class was loaded from, and you can tell if you were loaded from 
a jar file or not -- (codesource.endsWith(".jar") -- I'd be happy to 
pass this code your way if nothing else surfaces.

David

Rick Hillegas wrote:
> I'm working on a feature which only surfaces if you are running against 
> jar files. Is there a template for writing a test which only executes 
> when derbyall runs against jar files?
> 
> Thanks,
> -Rick

Re: testing against jar files

[Rick Hillegas <Ri...@Sun.COM>]

Hi David,

Yes, please. Thanks-Rick

David W. Van Couvering wrote:

> I had a jar-only test working, using the mechanism I mentioned to see 
> if the test class was loaded from a jar or not.  This is with the 
> assumption that if the test class is loaded from a jar, then 
> everything is loaded from jars.  Alternately one could load a Derby 
> class and see if it was loaded from a jar.
>
> Rick, if you're interested, I'll send you the code.
>
> David
>
> Daniel John Debrunner wrote:
>
>> Rick Hillegas wrote:
>>
>>
>>>> Be interesting to see what cannot be run when using the classes
>>>> directly
>>>>
>>>>
>>>
>>> I'm building the JDBC4 support for autoloading the driver. This 
>>> involves
>>> writing your driver name into a special location in the jar file. The
>>> autoloading test needs to get a connection to Derby without ever
>>> mentioning the Derby driver. This should only succeed if run against 
>>> jar
>>> files under jdk1.6.
>>
>>
>>
>> Cool I'd hoped someone was going to add that.
>>
>> You could have/simulate the same behaviour for classes and pre-jdk 1.6
>> by using the System property jdbc.drivers. Something that isn't
>> currently tested.
>>
>> If you do go the jar only route, for purely selfish reasons a jar only
>> suite would be useful for me in the future. I've been thinking about
>> tests to ensure the packages are sealed, by having procedures or
>> functions load classes that extend derby classes. But I'm a long way off
>> getting round to attempting it.
>>
>> Thanks,
>> Dan.
>>

Re: testing against jar files

["David W. Van Couvering" <Da...@Sun.COM>]

I had a jar-only test working, using the mechanism I mentioned to see if 
the test class was loaded from a jar or not.  This is with the 
assumption that if the test class is loaded from a jar, then everything 
is loaded from jars.  Alternately one could load a Derby class and see 
if it was loaded from a jar.

Rick, if you're interested, I'll send you the code.

David

Daniel John Debrunner wrote:
> Rick Hillegas wrote:
> 
> 
>>>Be interesting to see what cannot be run when using the classes
>>>directly
>>> 
>>>
>>
>>I'm building the JDBC4 support for autoloading the driver. This involves
>>writing your driver name into a special location in the jar file. The
>>autoloading test needs to get a connection to Derby without ever
>>mentioning the Derby driver. This should only succeed if run against jar
>>files under jdk1.6.
> 
> 
> Cool I'd hoped someone was going to add that.
> 
> You could have/simulate the same behaviour for classes and pre-jdk 1.6
> by using the System property jdbc.drivers. Something that isn't
> currently tested.
> 
> If you do go the jar only route, for purely selfish reasons a jar only
> suite would be useful for me in the future. I've been thinking about
> tests to ensure the packages are sealed, by having procedures or
> functions load classes that extend derby classes. But I'm a long way off
> getting round to attempting it.
> 
> Thanks,
> Dan.
> 

Re: testing against jar files

[Daniel John Debrunner <dj...@apache.org>]

Rick Hillegas wrote:

> 
>> Be interesting to see what cannot be run when using the classes
>> directly
>>  
>>
> I'm building the JDBC4 support for autoloading the driver. This involves
> writing your driver name into a special location in the jar file. The
> autoloading test needs to get a connection to Derby without ever
> mentioning the Derby driver. This should only succeed if run against jar
> files under jdk1.6.

Cool I'd hoped someone was going to add that.

You could have/simulate the same behaviour for classes and pre-jdk 1.6
by using the System property jdbc.drivers. Something that isn't
currently tested.

If you do go the jar only route, for purely selfish reasons a jar only
suite would be useful for me in the future. I've been thinking about
tests to ensure the packages are sealed, by having procedures or
functions load classes that extend derby classes. But I'm a long way off
getting round to attempting it.

Thanks,
Dan.

Re: testing against jar files

[Rick Hillegas <Ri...@Sun.COM>]

>Be interesting to see what cannot be run when using the classes
>directly
>  
>
I'm building the JDBC4 support for autoloading the driver. This involves 
writing your driver name into a special location in the jar file. The 
autoloading test needs to get a connection to Derby without ever 
mentioning the Derby driver. This should only succeed if run against jar 
files under jdk1.6.

Cheers,
-Rick

Re: testing against jar files

[Daniel John Debrunner <dj...@apache.org>]

Rick Hillegas wrote:

> I'm working on a feature which only surfaces if you are running against
> jar files. Is there a template for writing a test which only executes
> when derbyall runs against jar files?

No, but the properties set up for the policy file would tell you what
the harness thought the class path was.

>From the testing policy file:

// derbyTesting.codejar - URL to the jar files when they are in the
classpath
// derbyTesting.codeclasses - URL to the classes directory when it is in
the classpath
//
// Only one of derbyTesting.codejar and derbyTesting.codeclasses will be
valid, the
// other will be set to a bogus URL like file://unused


In the future it may be that only one of these properties would be set.
There is no requirement to have one not in use being set to
file://unused, so don't depend on that.

Be interesting to see what cannot be run when using the classes
directly, sharing your ideas on the list might allow others to find ways
to achieve that, that's one of the benefits of open source development.

Dan.