[jira] [Commented] (LANG-1049) SerializationUtils.deserialize() can not be used within OSGi
[ https://issues.apache.org/jira/browse/LANG-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14982110#comment-14982110 ] Christian Schneider commented on LANG-1049: --- I can imagine your frustration. I am no committer on commons-lang though. I will open a new issue and see if it gets some attention. > SerializationUtils.deserialize() can not be used within OSGi > > > Key: LANG-1049 > URL: https://issues.apache.org/jira/browse/LANG-1049 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.6 > Environment: Equinox >Reporter: Marcus Klein >Priority: Blocker > > SerializationUtils.deserialize() throws a SerializationException if objects > should be deserialized that can not be resolved by OSGi classloader of > org.apache.commons.lang bundle. > To solve this problem I suggest to allow buddy classloading within > commons.lang to allow other bundles to register their class loaders. > Please add > Eclipse-BuddyPolicy: registered > to the MANIFEST.MF of commons.lang to solve this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (LANG-1049) SerializationUtils.deserialize() can not be used within OSGi
[ https://issues.apache.org/jira/browse/LANG-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14982083#comment-14982083 ] Christian Schneider edited comment on LANG-1049 at 10/30/15 7:51 AM: - Strange timing to close the issue as soon as I propose a fix. Should I open a new issue? was (Author: ch...@die-schneider.net): Strange timing to close the issue as soon as I propose a fix. > SerializationUtils.deserialize() can not be used within OSGi > > > Key: LANG-1049 > URL: https://issues.apache.org/jira/browse/LANG-1049 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.6 > Environment: Equinox >Reporter: Marcus Klein >Priority: Blocker > > SerializationUtils.deserialize() throws a SerializationException if objects > should be deserialized that can not be resolved by OSGi classloader of > org.apache.commons.lang bundle. > To solve this problem I suggest to allow buddy classloading within > commons.lang to allow other bundles to register their class loaders. > Please add > Eclipse-BuddyPolicy: registered > to the MANIFEST.MF of commons.lang to solve this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1049) SerializationUtils.deserialize() can not be used within OSGi
[ https://issues.apache.org/jira/browse/LANG-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14982083#comment-14982083 ] Christian Schneider commented on LANG-1049: --- Strange timing to close the issue as soon as I propose a fix. > SerializationUtils.deserialize() can not be used within OSGi > > > Key: LANG-1049 > URL: https://issues.apache.org/jira/browse/LANG-1049 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.6 > Environment: Equinox >Reporter: Marcus Klein >Priority: Blocker > > SerializationUtils.deserialize() throws a SerializationException if objects > should be deserialized that can not be resolved by OSGi classloader of > org.apache.commons.lang bundle. > To solve this problem I suggest to allow buddy classloading within > commons.lang to allow other bundles to register their class loaders. > Please add > Eclipse-BuddyPolicy: registered > to the MANIFEST.MF of commons.lang to solve this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1049) SerializationUtils.deserialize() can not be used within OSGi
[ https://issues.apache.org/jira/browse/LANG-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14981501#comment-14981501 ] Christian Schneider commented on LANG-1049: --- I found the class org.apache.commons.io.input.ClassLoaderObjectInputStream in commons-io. Using this class it should be easy to implement this. To not create a new dependency we could copy the code over? WDYT? > SerializationUtils.deserialize() can not be used within OSGi > > > Key: LANG-1049 > URL: https://issues.apache.org/jira/browse/LANG-1049 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.6 > Environment: Equinox >Reporter: Marcus Klein >Priority: Blocker > > SerializationUtils.deserialize() throws a SerializationException if objects > should be deserialized that can not be resolved by OSGi classloader of > org.apache.commons.lang bundle. > To solve this problem I suggest to allow buddy classloading within > commons.lang to allow other bundles to register their class loaders. > Please add > Eclipse-BuddyPolicy: registered > to the MANIFEST.MF of commons.lang to solve this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBCP-423) PoolingDataSource should implement Closeable
[
https://issues.apache.org/jira/browse/DBCP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262815#comment-14262815
]
Christian Schneider commented on DBCP-423:
--
I think if I open a DataSource in try with resources then I would also expect
it to be closed at the end. So I do not see a big problem with that one.
Can you imagine an example where somone creates a DataSource in try with
resources but does not want it to be closed?
> PoolingDataSource should implement Closeable
>
>
> Key: DBCP-423
> URL: https://issues.apache.org/jira/browse/DBCP-423
> Project: Commons Dbcp
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Christian Schneider
> Fix For: 2.1
>
>
> Currently PoolingDataSource only implements DataSource.
> I have the following case in ops4j pax-jdbc. I offer a DataSourceFactory in
> one bundle that can create a pooling DataSource.
> Then in another bundle I create DataSources based on config in
> ConfigurationAdmin. So when the config appears I create the DataSource, when
> the config goes away I have to destroy it.
> It is important to correctly dispose the DataSource as the pool has to be
> closed. As I can not depend on dbcp in the bundle that destroys the
> DataSource I currently have no simple way to destroy the DataSource.
> This is where I create the DataSource:
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool/src/main/java/org/ops4j/pax/jdbc/pool/impl/PooledDataSourceFactory.java
> I was able to solve it by a kind of hack. I extended the PoolingDataSource
> with a class that supports Closeable. So from the other bundle I could check
> if the object implements Closeable and call close.
> It would be a lot easier if PoolingDataSource would implement Closeable like
> I did. The same is true for GenericObjectPool and the other pools. If they
> would implement Closeable then handling them would be a lot easier.
> They already support a close method so it would be a small change.
>
> public class CloseablePoolingDataSource extends
> PoolingDataSource implements Closeable {
> public CloseablePoolingDataSource(ObjectPool pool) {
> super(pool);
> }
> @Override
> public void close() throws IOException {
> getPool().close();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DBCP-423) PoolingDataSource should implement Closeable
[
https://issues.apache.org/jira/browse/DBCP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262652#comment-14262652
]
Christian Schneider commented on DBCP-423:
--
For me having a close in PoolingDataSource would not help. I close the
DataSource in pax-jdbc-config. There only DataSource is known and the module
should have no dependency on dbcp. This is why I used Closeable as it is
present in the jdk. So basically what I need is that the PoolingDataSource impl
implements a standard java interface with a close method.
Honestly I think that not implementing something like Closeable in many Java
APIs is the real smell .. together with Closeable.close throwing a checked
exception which totally sucks from a client perspective. Still Closeable is the
only present interface to mark that something can be closed. Btw. If you look
at newer Java APIs like jms 2.0 you see that they extend AutoClosable. So I
think the spec designers understood that they left out an important part by not
having a universal closing facility and corrected this.
So of course extending Autoclosable would be the even better thing but it is
Java 7 only so I do not know if it is ok for dbcp.
> PoolingDataSource should implement Closeable
>
>
> Key: DBCP-423
> URL: https://issues.apache.org/jira/browse/DBCP-423
> Project: Commons Dbcp
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Christian Schneider
> Fix For: 2.1
>
>
> Currently PoolingDataSource only implements DataSource.
> I have the following case in ops4j pax-jdbc. I offer a DataSourceFactory in
> one bundle that can create a pooling DataSource.
> Then in another bundle I create DataSources based on config in
> ConfigurationAdmin. So when the config appears I create the DataSource, when
> the config goes away I have to destroy it.
> It is important to correctly dispose the DataSource as the pool has to be
> closed. As I can not depend on dbcp in the bundle that destroys the
> DataSource I currently have no simple way to destroy the DataSource.
> This is where I create the DataSource:
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool/src/main/java/org/ops4j/pax/jdbc/pool/impl/PooledDataSourceFactory.java
> I was able to solve it by a kind of hack. I extended the PoolingDataSource
> with a class that supports Closeable. So from the other bundle I could check
> if the object implements Closeable and call close.
> It would be a lot easier if PoolingDataSource would implement Closeable like
> I did. The same is true for GenericObjectPool and the other pools. If they
> would implement Closeable then handling them would be a lot easier.
> They already support a close method so it would be a small change.
>
> public class CloseablePoolingDataSource extends
> PoolingDataSource implements Closeable {
> public CloseablePoolingDataSource(ObjectPool pool) {
> super(pool);
> }
> @Override
> public void close() throws IOException {
> getPool().close();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBCP-423) PoolingDataSource should implement Closeable
[
https://issues.apache.org/jira/browse/DBCP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated DBCP-423:
-
Issue Type: Improvement (was: New Feature)
> PoolingDataSource should implement Closeable
>
>
> Key: DBCP-423
> URL: https://issues.apache.org/jira/browse/DBCP-423
> Project: Commons Dbcp
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Christian Schneider
> Fix For: 2.0.1
>
>
> Currently PoolingDataSource only implements DataSource.
> I have the following case in ops4j pax-jdbc. I offer a DataSourceFactory in
> one bundle that can create a pooling DataSource.
> Then in another bundle I create DataSources based on config in
> ConfigurationAdmin. So when the config appears I create the DataSource, when
> the config goes away I have to destroy it.
> It is important to correctly dispose the DataSource as the pool has to be
> closed. As I can not depend on dbcp in the bundle that destroys the
> DataSource I currently have no simple way to destroy the DataSource.
> This is where I create the DataSource:
> https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool/src/main/java/org/ops4j/pax/jdbc/pool/impl/PooledDataSourceFactory.java
> I was able to solve it by a kind of hack. I extended the PoolingDataSource
> with a class that supports Closeable. So from the other bundle I could check
> if the object implements Closeable and call close.
> It would be a lot easier if PoolingDataSource would implement Closeable like
> I did. The same is true for GenericObjectPool and the other pools. If they
> would implement Closeable then handling them would be a lot easier.
> They already support a close method so it would be a small change.
>
> public class CloseablePoolingDataSource extends
> PoolingDataSource implements Closeable {
> public CloseablePoolingDataSource(ObjectPool pool) {
> super(pool);
> }
> @Override
> public void close() throws IOException {
> getPool().close();
> }
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (DBCP-423) PoolingDataSource should implement Closeable
Christian Schneider created DBCP-423:
Summary: PoolingDataSource should implement Closeable
Key: DBCP-423
URL: https://issues.apache.org/jira/browse/DBCP-423
Project: Commons Dbcp
Issue Type: New Feature
Affects Versions: 2.0
Reporter: Christian Schneider
Fix For: 2.0.1
Currently PoolingDataSource only implements DataSource.
I have the following case in ops4j pax-jdbc. I offer a DataSourceFactory in one
bundle that can create a pooling DataSource.
Then in another bundle I create DataSources based on config in
ConfigurationAdmin. So when the config appears I create the DataSource, when
the config goes away I have to destroy it.
It is important to correctly dispose the DataSource as the pool has to be
closed. As I can not depend on dbcp in the bundle that destroys the DataSource
I currently have no simple way to destroy the DataSource.
This is where I create the DataSource:
https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool/src/main/java/org/ops4j/pax/jdbc/pool/impl/PooledDataSourceFactory.java
I was able to solve it by a kind of hack. I extended the PoolingDataSource with
a class that supports Closeable. So from the other bundle I could check if the
object implements Closeable and call close.
It would be a lot easier if PoolingDataSource would implement Closeable like I
did. The same is true for GenericObjectPool and the other pools. If they would
implement Closeable then handling them would be a lot easier.
They already support a close method so it would be a small change.
public class CloseablePoolingDataSource extends
PoolingDataSource implements Closeable {
public CloseablePoolingDataSource(ObjectPool pool) {
super(pool);
}
@Override
public void close() throws IOException {
getPool().close();
}
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LOGGING-124) Commons logging does not work in an osgi environment
[ https://issues.apache.org/jira/browse/LOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585130#comment-13585130 ] Christian Schneider commented on LOGGING-124: - About the symbolic name. I was just setting it so you can see how to do it. It may be a good idea to leave it on the default value which I think is groupId.artifactId. Packaging bundle allows the bundle plugin to tap into more lifecycle phases. I am not sure if it is absolutely necessary but it is the recommended way to run the bundle plugin. With the several packagings we may have some problems if a package is exported by e.g api and full. So the better way would be to have API and impl jars that have no common packages. In OSGi a package of a certain version can only come from one bundle. Of course it is not a good idea to change the packaging in a bugfix release but perhaps this could be considered for the next minor or majpr release. > Commons logging does not work in an osgi environment > > > Key: LOGGING-124 > URL: https://issues.apache.org/jira/browse/LOGGING-124 > Project: Commons Logging > Issue Type: Improvement >Affects Versions: 1.1.1 >Reporter: Christian Schneider > Attachments: LOGGING-124.patch > > > Commons logging should provide Manifest information for using it as an OSGI > bundle. Eventually detection of logging engines and loading of configs should > also be changed to make commons-logging osgi ready. > I have given this problem the critical priority as currently many people are > working on osgi projects and as many open source libs use commons-logging > this is an important thing to solve. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOGGING-124) Commons logging does not work in an osgi environment
[ https://issues.apache.org/jira/browse/LOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated LOGGING-124: Attachment: LOGGING-124.patch Patch to add the maven bundle plugin to the build. The imports and exports look good. I found a strange thing though. The build creates three jars from the same source. API, adapters and the normal commons-logging jar. Strangely the api and the normal jar both seem to contain the impl package. Is that intended. > Commons logging does not work in an osgi environment > > > Key: LOGGING-124 > URL: https://issues.apache.org/jira/browse/LOGGING-124 > Project: Commons Logging > Issue Type: Improvement >Affects Versions: 1.1.1 >Reporter: Christian Schneider > Attachments: LOGGING-124.patch > > > Commons logging should provide Manifest information for using it as an OSGI > bundle. Eventually detection of logging engines and loading of configs should > also be changed to make commons-logging osgi ready. > I have given this problem the critical priority as currently many people are > working on osgi projects and as many open source libs use commons-logging > this is an important thing to solve. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (BEANUTILS-378) BeanMap does not work in osgi class not found org.apache.commons.collections.Transformer
[ https://issues.apache.org/jira/browse/BEANUTILS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider closed BEANUTILS-378. - > BeanMap does not work in osgi class not found > org.apache.commons.collections.Transformer > > > Key: BEANUTILS-378 > URL: https://issues.apache.org/jira/browse/BEANUTILS-378 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.3 >Reporter: Christian Schneider > Fix For: 1.8.4 > > > BeanMap needs org.apache.commons.collections.Transformer. > So beanutils should import the package org.apache.commons.collections in the > Manifest -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (BEANUTILS-378) BeanMap does not work in osgi class not found org.apache.commons.collections.Transformer
[ https://issues.apache.org/jira/browse/BEANUTILS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905834#action_12905834 ] Christian Schneider commented on BEANUTILS-378: --- That sounds good. I think there should be no classes that are offered by two jars. Having a non optional dependency to commons collections would be no problem for me. > BeanMap does not work in osgi class not found > org.apache.commons.collections.Transformer > > > Key: BEANUTILS-378 > URL: https://issues.apache.org/jira/browse/BEANUTILS-378 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.8.3 >Reporter: Christian Schneider > > BeanMap needs org.apache.commons.collections.Transformer. > So beanutils should import the package org.apache.commons.collections in the > Manifest -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (BEANUTILS-378) BeanMap does not work in osgi class not found org.apache.commons.collections.Transformer
BeanMap does not work in osgi class not found org.apache.commons.collections.Transformer Key: BEANUTILS-378 URL: https://issues.apache.org/jira/browse/BEANUTILS-378 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.8.3 Reporter: Christian Schneider BeanMap needs org.apache.commons.collections.Transformer. So beanutils should import the package org.apache.commons.collections in the Manifest -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOGGING-124) Commons logging does not work in an osgi environment
[ https://issues.apache.org/jira/browse/LOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623172#action_12623172 ] Christian Schneider commented on LOGGING-124: - I have read some more about the different logging engines. As it seems people agree that commons-logging has many class loading issues. What is the opinion of the people here on the project? Should people switch to slf4j and use the commons-logging compatibility or is it better to solve the classloading issues in commons-logging? > Commons logging does not work in an osgi environment > > > Key: LOGGING-124 > URL: https://issues.apache.org/jira/browse/LOGGING-124 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Christian Schneider >Priority: Critical > > Commons logging should provide Manifest information for using it as an OSGI > bundle. Eventually detection of logging engines and loading of configs should > also be changed to make commons-logging osgi ready. > I have given this problem the critical priority as currently many people are > working on osgi projects and as many open source libs use commons-logging > this is an important thing to solve. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOGGING-124) Commons logging does not work in an osgi environment
[ https://issues.apache.org/jira/browse/LOGGING-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623171#action_12623171 ] Christian Schneider commented on LOGGING-124: - Ok .. I read the thread on the mailing list. But this will not really help. The last mail says : Please don´t support OSGI as it won´t work with commons-logging anyway. Personally I think this is quite counter productive. We have an urgent problem here. Many Open Source libraries use commons-logging and when they move to osgi the users of these libraries have problems. I do not think the answer can be: let all people switch to pax-logging (or yet another logging framework). I think either commons-logging should make the move to osgi or be discontinued. If things stay as they are people will only move away from commons-logging over time and the problems will continue to exist over a long time. The minimal thing would be to explain in the commons-logging documentation what people have to do to make their apps work. The better thing would be to provide a commons-logging jar that simply works in osgi. I am sure the bootstrapping and detection of frameworks can be changed in a way that is not as problematic as today. > Commons logging does not work in an osgi environment > > > Key: LOGGING-124 > URL: https://issues.apache.org/jira/browse/LOGGING-124 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.1.1 >Reporter: Christian Schneider >Priority: Critical > > Commons logging should provide Manifest information for using it as an OSGI > bundle. Eventually detection of logging engines and loading of configs should > also be changed to make commons-logging osgi ready. > I have given this problem the critical priority as currently many people are > working on osgi projects and as many open source libs use commons-logging > this is an important thing to solve. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LOGGING-124) Commons logging does not work in an osgi environment
Commons logging does not work in an osgi environment Key: LOGGING-124 URL: https://issues.apache.org/jira/browse/LOGGING-124 Project: Commons Logging Issue Type: Bug Affects Versions: 1.1.1 Reporter: Christian Schneider Priority: Critical Commons logging should provide Manifest information for using it as an OSGI bundle. Eventually detection of logging engines and loading of configs should also be changed to make commons-logging osgi ready. I have given this problem the critical priority as currently many people are working on osgi projects and as many open source libs use commons-logging this is an important thing to solve. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
