Bad OSGi Import-Package directives in 1.4.177

[Anders Engström]

Hi!

I noticed that the Import-Package directives in the JAR-file weird. The bundle exports all "org.h2" packages with the version "1.4.177" as expected, but the Import-Package directive for those packages is "[1.4.177,1.4.0)". This results in a "negative" version range (all versions between 1.4.177 and 1.4.0 (!)) and at least Apache Felix barfs on this.

I suspect that the upper version is a left-over from the 1.3 development branch?

The proper version range should be "[1.4.177,1.5.0)".

I'm reporting this on the mailing list instead of through the Google Code issues since 1.4 is still (?) in beta.

(Also - it would be nice if the dependency on org.osgi.service.jdbc was optional and that the DataSourceFactory was only published if that package is available)

Best Regards //Anders

[Anders Engström]

Of course a was a bit too quick.. it looks like this have been fixed in trunk (although the new code have not been released yet). :)

To make me look better I created a patch for the optional DataSourceFactory instead: http://code.google.com/p/h2database/issues/detail?id=559&sort=-id

Best regards //Anders

[Thomas Mueller]

Hi,

Yes, I fixed the version problem in the code. About your patch (I like to discuss it here in the mailing list, as there are only very few looking at the issue tracker):

>The DataSouceFactory specification is not supported by default in most OSGi frameworks.

In which framework and version is it not supported?

I don't like to use System.err.print. Is there an alternative?

Regards,
Thomas

--
You received this message because you are subscribed to the Google Groups "H2 Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to h2-database...@googlegroups.com.
To post to this group, send email to h2-da...@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.

[Anders Engström]

Hi Thomas!

On Wednesday, April 23, 2014 9:05:26 PM UTC+2, Thomas Mueller wrote:

Hi,

Yes, I fixed the version problem in the code.

Just a quick follow up on that: when is the 1.4 release scheduled for release (it's still beta, right)?
 

About your patch (I like to discuss it here in the mailing list, as there are only very few looking at the issue tracker):

>The DataSouceFactory specification is not supported by default in most OSGi frameworks.

In which framework and version is it not supported?

Maybe I was a bit unclear - it is if course supported in basically every framework (Felix, Equinox, Knoplerfish etc) *provided* that you manually install a bundle that can provide the 'org.osgi.service.jdbc' package. Installing the

At least in Apache Karaf the package isn't available by default.

My reasoning is basically that h2 should *require* as few dependencies as possible. 
 

I don't like to use System.err.print. Is there an alternative?

Heh - I didn't like that either *smile*. I didn't find any standard logging strategy in the h2 code base (on the other hand I didn't search very hard for it).

Best regards //Anders

 

[Thomas Mueller]

Hi,

> when is the 1.4 release scheduled for release (it's still beta, right)?

Yes, 1.4 is still beta. It's too early to tell when it is no longer beta, but I expect it will be in a few months.

> At least in Apache Karaf the package isn't available by default. 

OK, good to know.

> h2 should *require* as few dependencies as possible

Yes, that's true.

> I didn't find any standard logging strategy in the h2 code base

Well, at this level there is none (I don't want to hardcode SLF4J or use java.utils.logging). Maybe the best option is not to log. But is it possible to use Class.forName instead, similar to how it's done in org.h2.value.DataType.GEOMETRY_CLASS_NAME / GEOMETRY_CLASS, with Class.forName()?

Regards,

Thomas

[Anders Engström]

Hi again!

On 04/24/2014 09:09 PM, Thomas Mueller wrote:
>>I didn't find any standard logging strategy in the h2 code base
>
> Well, at this level there is none (I don't want to hardcode SLF4J or
> use java.utils.logging). Maybe the best option is not to log.

Sure - I can remove the System.err call from the patch. One alternative
would be to use org.osgi.service.log.LogService (if *that one* is
available) - but it feels like an over-engineered solution at this
point.

> But is it possible to use Class.forName instead, similar to how it's
> done in org.h2.value.DataType.GEOMETRY_CLASS_NAME / GEOMETRY_CLASS,
> with Class.forName()?
>

Are you referring to using `Utils.loadUserClass` to check if the class
is available or not (before trying to create the `OsgiDataSourceFactory`
and register it as a service)?

[snip]

Best regards //Anders

[Thomas Mueller]

Hi,

> One alternative would be to use org.osgi.service.log.LogService 

> (if *that one* is available)

No, I wouldn't use that, as it might also not be available.

> Are you referring to using `Utils.loadUserClass` to check if the class
> is available or not (before trying to create the `OsgiDataSourceFactory`
> and register it as a service)?

Yes.

Regards,

Thomas

Best regards //Anders

--
You received this message because you are subscribed to the Google Groups "H2 Database" group.

To unsubscribe from this group and stop receiving emails from it, send an email to h2-database+unsubscribe@googlegroups.com.

[Anders Engström]

Howdy!

On Friday, April 25, 2014 3:38:27 PM UTC+2, Thomas Mueller wrote:

 

> Are you referring to using `Utils.loadUserClass` to check if the class
> is available or not (before trying to create the `OsgiDataSourceFactory`
> and register it as a service)?

Yes.

I'll adjust the patch accordingly :) I'll ping back here when I've attached a new patch to the issue :)

//Anders
 

On Fri, Apr 25, 2014 at 12:01 PM, Anders Engström <epir...@gmail.com> wrote:

Hi again!

On 04/24/2014 09:09 PM, Thomas Mueller wrote:

I didn't find any standard logging strategy in the h2 code base

Well, at this level there is none (I don't want to hardcode SLF4J or
use java.utils.logging). Maybe the best option is not to log.

Sure - I can remove the System.err call from the patch. One alternative
would be to use org.osgi.service.log.LogService (if *that one* is
available) - but it feels like an over-engineered solution at this
point.

But is it possible to use Class.forName instead, similar to how it's
done in org.h2.value.DataType.GEOMETRY_CLASS_NAME / GEOMETRY_CLASS,
with Class.forName()?

Are you referring to using `Utils.loadUserClass` to check if the class
is available or not (before trying to create the `OsgiDataSourceFactory`
and register it as a service)?

[snip]

Best regards //Anders

--
You received this message because you are subscribed to the Google Groups "H2 Database" group.

To unsubscribe from this group and stop receiving emails from it, send an email to h2-database...@googlegroups.com.

[Anders Engström]

Hi again!

Sorry for the delay. I've created a new patch where I'm using the loadUserClass instead.

Please have a look at it :)

Best regards //Anders

[Anders Engström]

If this patch is accepted - what are the odds for getting it backported to 1.3? :)

//Anders

[Thomas Mueller]

Hi,

If there is a new 1.3.x version, it will be included.

Regards,

Thomas

[Anders Engström]

That's great news.  Thanks for accepting the patch :)

/Anders

You received this message because you are subscribed to a topic in the Google Groups "H2 Database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/h2-database/1FECeOv0hQA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to h2-database...@googlegroups.com.