[jira] [Commented] (DERBY-6586) CLONE - derbyclient.jar conflict with derby.jar on package export, which is problematic on OSGI environment
[ https://issues.apache.org/jira/browse/DERBY-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181915#comment-15181915 ] Bryan Pendleton commented on DERBY-6586: Ah. somehow I had missed the fact that this issue involved the "Embedded Server" configuration, in which a single JVM hosts both the server(+engine) as well as the client. Yes, I can see that this would be problematic if you are using a runtime system that enforces that certain packages come only from a single jar. > CLONE - derbyclient.jar conflict with derby.jar on package export, which is > problematic on OSGI environment > --- > > Key: DERBY-6586 > URL: https://issues.apache.org/jira/browse/DERBY-6586 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.10.2.0 > Environment: OSGi >Reporter: Charlie Mordant > > The manifest in derbyclient.jar is incomplete for usage in OSGi. There are > no packages exported. This appears to only be a problem in standalone > equinox (outside of eclipse). Note that I did not try other OSGi containers. > The fix is relatively simple. Adding the Export-Package manifest header > should take care of the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DERBY-6586) CLONE - derbyclient.jar conflict with derby.jar on package export, which is problematic on OSGI environment
[ https://issues.apache.org/jira/browse/DERBY-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181846#comment-15181846 ] Charlie Mordant edited comment on DERBY-6586 at 3/5/16 9:08 PM: Hi, The OSGi bundle's rule (jars) are pretty easy to understand: * You can't have two different bundles (jars) exporting the same packages otherwise they must have different versions (and shall respect the semantic versioning paradigm: macro qualifier for major api changes (e.g. consumer api), minor for minor changes (e.g. developper api), micro for patches. Otherwise, these bundles (jar) cannot coexist within the same OSGi runtime. * Also, jars cannot have circular package dependencies (com.foo having classes importing ones from com.bar having importing some from a package which import one from com.foo) As derby.server and derby.client are exporting the same packages (there classes in the org.apache.derby package in the derby-client jar and also in the derby-server jar), they can't really coexist in an OSGi runtime (there are hacks like using Require-Bundle Manifest option instead of the Import-Package one, or making a super-bundle encompassing these two, but this breaks to some modularity capabilities and it's just evil). The solution is kind simple: * Moving all classes of derby-client in a package named org.apache.derby.client.**.* * Moving all classes of derby-server in a package named org.apache.derby.server.**.* * Moving all classes of derby-network in a package named org.apache.derby.network.**.* Etc... was (Author: tcharl): Hi, The OSGi bundle's rule (jars) are pretty easy to understand: * You can't have two different bundles (jars) exporting the same packages otherwise they must have different versions (and shall respect the semantic versioning paradigm: macro qualifier for major api changes (e.g. consumer api), minor for minor changes (e.g. developper api), micro for patches. Otherwise, these bundles (jar) cannot coexist within the same OSGi runtime. * Also, jars cannot have circular package dependencies (com.foo having classes importing ones from com.bar having importing some from a package which import one from com.foo) As derby.server and derby.client are exporting the same packages (there classes in the org.apache.derby package in the derby-client jar and also in the derby-server jar), they can't really coexist in an OSGi runtime (there are hacks like using Require-Bundle Manifest option instead of the Import-Package one, or making a super-bundle encompassing these two, but this breaks to some modularity capabilities and it's just evil). > CLONE - derbyclient.jar conflict with derby.jar on package export, which is > problematic on OSGI environment > --- > > Key: DERBY-6586 > URL: https://issues.apache.org/jira/browse/DERBY-6586 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.10.2.0 > Environment: OSGi >Reporter: Charlie Mordant > > The manifest in derbyclient.jar is incomplete for usage in OSGi. There are > no packages exported. This appears to only be a problem in standalone > equinox (outside of eclipse). Note that I did not try other OSGi containers. > The fix is relatively simple. Adding the Export-Package manifest header > should take care of the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-1773) insertRow() and updateRow() fail with syntax error when column has an alias
[ https://issues.apache.org/jira/browse/DERBY-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-1773: --- Attachment: anyVsAll.diff updatedToHeadMarch2016.diff Uhm, I guess I lost track of this issue, for it's been 6 years! :) The first thing I did was to bring the previous patch up to date, since a lot can change in 6 years. 'updatedToHeadMarch2016.diff' is the result, and it builds and passes tests with the head of trunk. Upon closely re-reading Knut Anders's comments from 6 years ago, I remembered that I had not addressed his observation that it would be possible for some, but not all, of the columns in the result list to be aliased, and only those columns which are aliased should be non-updatable; the unaliased columns should still be updatable. After thinking about that for a while, it seemed to me that this merely required changing the proposed ResultColumnList.columnsAreUpdatable() method so that it tested whether *any* columns in the list were updatable, as opposed to requiring that *all* columns in the list were updatable. So I did that, and added a few additional test cases, and the results appear to be satisfactory. The revised patch is attached as anyVsAll.diff. I'm running tests on it now, to see how it behaves. Sorry for the 6 year gap, but if anyone is still interested in this issue, feedback would be gratefully received. > insertRow() and updateRow() fail with syntax error when column has an alias > --- > > Key: DERBY-1773 > URL: https://issues.apache.org/jira/browse/DERBY-1773 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.2.1.6 >Reporter: Knut Anders Hatlen >Assignee: Bryan Pendleton >Priority: Minor > Labels: derby_triage10_5_2 > Attachments: ASF.LICENSE.NOT.GRANTED--Alias.java, > NoUpdatesToAliasedColumnsWithTest.diff, anyVsAll.diff, > updatedToHeadMarch2010.diff, updatedToHeadMarch2016.diff > > > When the select query used in an updatable result set has column aliases, a > syntax error is thrown when executing ResultSet.insertRow() and > ResultSet.updateRow(). The problem is seen on embedded and client. Repro is > attached. > Exception in thread "main" ERROR 42X14: 'A1' is not a column in table or VTI > 'APP.T'. > at > org.apache.derby.iapi.error.StandardException.newException(StandardException.java:316) > at > org.apache.derby.impl.sql.compile.ResultColumn.bindResultColumnByName(ResultColumn.java:677) > at > org.apache.derby.impl.sql.compile.ResultColumnList.bindResultColumnsByName(ResultColumnList.java:682) > at > org.apache.derby.impl.sql.compile.ResultSetNode.bindResultColumns(ResultSetNode.java:683) > at > org.apache.derby.impl.sql.compile.SelectNode.bindResultColumns(SelectNode.java:742) > at > org.apache.derby.impl.sql.compile.UpdateNode.bind(UpdateNode.java:349) > at > org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:345) > at > org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:111) > at > org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:723) > at > org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(EmbedResultSet.java:3734) > at Alias.main(Alias.java:15) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DERBY-6586) CLONE - derbyclient.jar conflict with derby.jar on package export, which is problematic on OSGI environment
[ https://issues.apache.org/jira/browse/DERBY-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181846#comment-15181846 ] Charlie Mordant edited comment on DERBY-6586 at 3/5/16 9:06 PM: Hi, The OSGi bundle's rule (jars) are pretty easy to understand: * You can't have two different bundles (jars) exporting the same packages otherwise they must have different versions (and shall respect the semantic versioning paradigm: macro qualifier for major api changes (e.g. consumer api), minor for minor changes (e.g. developper api), micro for patches. Otherwise, these bundles (jar) cannot coexist within the same OSGi runtime. * Also, jars cannot have circular packages dependencies (com.foo having classes importing ones from com.bar having importing some from a package which import one from com.foo) As derby.server and derby.client are exporting the same packages (there classes in the org.apache.derby package in the derby-client jar and also in the derby-server jar), they can't really coexist in an OSGi runtime (there are hacks like using Require-Bundle Manifest option instead of the Import-Package one, or making a super-bundle encompassing these two, but this breaks to some modularity capabilities and it's just evil). was (Author: tcharl): Hi, The OSGi bundle's rule (jars) are pretty easy to understand: * You can't have two different bundles (jars) exporting the same packages otherwise they must have different versions (and shall respect the semantic versioning paradigm: macro qualifier for major api changes (e.g. consumer api), minor for minor changes (e.g. developper api), micro for patches. Otherwise, these bundles (jar) cannot coexist within the same OSGi runtime. As derby.server and derby.client are exporting the same packages (there classes in the org.apache.derby package in the derby-client jar and also in the derby-server jar), they can't really coexist in an OSGi runtime (there are hacks like using Require-Bundle Manifest option instead of the Import-Package one, or making a super-bundle encompassing these two, but this breaks to some modularity capabilities and it's just evil). > CLONE - derbyclient.jar conflict with derby.jar on package export, which is > problematic on OSGI environment > --- > > Key: DERBY-6586 > URL: https://issues.apache.org/jira/browse/DERBY-6586 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.10.2.0 > Environment: OSGi >Reporter: Charlie Mordant > > The manifest in derbyclient.jar is incomplete for usage in OSGi. There are > no packages exported. This appears to only be a problem in standalone > equinox (outside of eclipse). Note that I did not try other OSGi containers. > The fix is relatively simple. Adding the Export-Package manifest header > should take care of the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DERBY-6586) CLONE - derbyclient.jar conflict with derby.jar on package export, which is problematic on OSGI environment
[ https://issues.apache.org/jira/browse/DERBY-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181846#comment-15181846 ] Charlie Mordant edited comment on DERBY-6586 at 3/5/16 9:06 PM: Hi, The OSGi bundle's rule (jars) are pretty easy to understand: * You can't have two different bundles (jars) exporting the same packages otherwise they must have different versions (and shall respect the semantic versioning paradigm: macro qualifier for major api changes (e.g. consumer api), minor for minor changes (e.g. developper api), micro for patches. Otherwise, these bundles (jar) cannot coexist within the same OSGi runtime. * Also, jars cannot have circular package dependencies (com.foo having classes importing ones from com.bar having importing some from a package which import one from com.foo) As derby.server and derby.client are exporting the same packages (there classes in the org.apache.derby package in the derby-client jar and also in the derby-server jar), they can't really coexist in an OSGi runtime (there are hacks like using Require-Bundle Manifest option instead of the Import-Package one, or making a super-bundle encompassing these two, but this breaks to some modularity capabilities and it's just evil). was (Author: tcharl): Hi, The OSGi bundle's rule (jars) are pretty easy to understand: * You can't have two different bundles (jars) exporting the same packages otherwise they must have different versions (and shall respect the semantic versioning paradigm: macro qualifier for major api changes (e.g. consumer api), minor for minor changes (e.g. developper api), micro for patches. Otherwise, these bundles (jar) cannot coexist within the same OSGi runtime. * Also, jars cannot have circular packages dependencies (com.foo having classes importing ones from com.bar having importing some from a package which import one from com.foo) As derby.server and derby.client are exporting the same packages (there classes in the org.apache.derby package in the derby-client jar and also in the derby-server jar), they can't really coexist in an OSGi runtime (there are hacks like using Require-Bundle Manifest option instead of the Import-Package one, or making a super-bundle encompassing these two, but this breaks to some modularity capabilities and it's just evil). > CLONE - derbyclient.jar conflict with derby.jar on package export, which is > problematic on OSGI environment > --- > > Key: DERBY-6586 > URL: https://issues.apache.org/jira/browse/DERBY-6586 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.10.2.0 > Environment: OSGi >Reporter: Charlie Mordant > > The manifest in derbyclient.jar is incomplete for usage in OSGi. There are > no packages exported. This appears to only be a problem in standalone > equinox (outside of eclipse). Note that I did not try other OSGi containers. > The fix is relatively simple. Adding the Export-Package manifest header > should take care of the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6586) CLONE - derbyclient.jar conflict with derby.jar on package export, which is problematic on OSGI environment
[ https://issues.apache.org/jira/browse/DERBY-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181846#comment-15181846 ] Charlie Mordant commented on DERBY-6586: Hi, The OSGi bundle's rule (jars) are pretty easy to understand: * You can't have two different bundles (jars) exporting the same packages otherwise they must have different versions (and shall respect the semantic versioning paradigm: macro qualifier for major api changes (e.g. consumer api), minor for minor changes (e.g. developper api), micro for patches. Otherwise, these bundles (jar) cannot coexist within the same OSGi runtime. As derby.server and derby.client are exporting the same packages (there classes in the org.apache.derby package in the derby-client jar and also in the derby-server jar), they can't really coexist in an OSGi runtime (there are hacks like using Require-Bundle Manifest option instead of the Import-Package one, or making a super-bundle encompassing these two, but this breaks to some modularity capabilities and it's just evil). > CLONE - derbyclient.jar conflict with derby.jar on package export, which is > problematic on OSGI environment > --- > > Key: DERBY-6586 > URL: https://issues.apache.org/jira/browse/DERBY-6586 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.10.2.0 > Environment: OSGi >Reporter: Charlie Mordant > > The manifest in derbyclient.jar is incomplete for usage in OSGi. There are > no packages exported. This appears to only be a problem in standalone > equinox (outside of eclipse). Note that I did not try other OSGi containers. > The fix is relatively simple. Adding the Export-Package manifest header > should take care of the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6586) CLONE - derbyclient.jar conflict with derby.jar on package export, which is problematic on OSGI environment
[ https://issues.apache.org/jira/browse/DERBY-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181771#comment-15181771 ] Bryan Pendleton commented on DERBY-6586: I removed myself from being assigned. I don't use OSGI and am not sure of the details of the required change. > CLONE - derbyclient.jar conflict with derby.jar on package export, which is > problematic on OSGI environment > --- > > Key: DERBY-6586 > URL: https://issues.apache.org/jira/browse/DERBY-6586 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.10.2.0 > Environment: OSGi >Reporter: Charlie Mordant > > The manifest in derbyclient.jar is incomplete for usage in OSGi. There are > no packages exported. This appears to only be a problem in standalone > equinox (outside of eclipse). Note that I did not try other OSGi containers. > The fix is relatively simple. Adding the Export-Package manifest header > should take care of the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6586) CLONE - derbyclient.jar conflict with derby.jar on package export, which is problematic on OSGI environment
[ https://issues.apache.org/jira/browse/DERBY-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Pendleton updated DERBY-6586: --- Assignee: (was: Bryan Pendleton) > CLONE - derbyclient.jar conflict with derby.jar on package export, which is > problematic on OSGI environment > --- > > Key: DERBY-6586 > URL: https://issues.apache.org/jira/browse/DERBY-6586 > Project: Derby > Issue Type: Bug > Components: Network Client, Network Server >Affects Versions: 10.10.2.0 > Environment: OSGi >Reporter: Charlie Mordant > > The manifest in derbyclient.jar is incomplete for usage in OSGi. There are > no packages exported. This appears to only be a problem in standalone > equinox (outside of eclipse). Note that I did not try other OSGi containers. > The fix is relatively simple. Adding the Export-Package manifest header > should take care of the problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
