[jira] [Resolved] (JCS-190) [JCACHE] listener onExpired callback not always called
[ https://issues.apache.org/jira/browse/JCS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-190. Resolution: Fixed > [JCACHE] listener onExpired callback not always called > -- > > Key: JCS-190 > URL: https://issues.apache.org/jira/browse/JCS-190 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: jcs-2.2.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JCS-190) [JCACHE] listener onExpired callback not always called
Romain Manni-Bucau created JCS-190: -- Summary: [JCACHE] listener onExpired callback not always called Key: JCS-190 URL: https://issues.apache.org/jira/browse/JCS-190 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.2.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JCS-184) Unexpected dispose() in CompositeCacheManager.release()
[ https://issues.apache.org/jira/browse/JCS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-184. Resolution: Fixed backported to 2.2.x > Unexpected dispose() in CompositeCacheManager.release() > --- > > Key: JCS-184 > URL: https://issues.apache.org/jira/browse/JCS-184 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.2 >Reporter: at >Assignee: Bruno P. Kinoshita > Fix For: jcs-2.2.1 > > > If debug-logging is *not* enabled the return-statement is ignored and the > code falls-through to cache.dispose(). > See Line 739 in > http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java?revision=1803806=markup -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-184) Unexpected dispose() in CompositeCacheManager.release()
[ https://issues.apache.org/jira/browse/JCS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205047#comment-16205047 ] Romain Manni-Bucau commented on JCS-184: Sounds good yes > Unexpected dispose() in CompositeCacheManager.release() > --- > > Key: JCS-184 > URL: https://issues.apache.org/jira/browse/JCS-184 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.2 >Reporter: at >Assignee: Bruno P. Kinoshita > Fix For: jcs-3.0 > > > If debug-logging is *not* enabled the return-statement is ignored and the > code falls-through to cache.dispose(). > See Line 739 in > http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java?revision=1803806=markup -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-184) Unexpected dispose() in CompositeCacheManager.release()
[ https://issues.apache.org/jira/browse/JCS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204622#comment-16204622 ] Romain Manni-Bucau commented on JCS-184: [~tv] there is a 2.2.x which will be the starting point for the release - http://svn.apache.org/repos/asf/commons/proper/jcs/branches/commons-jcs-2.2.x/ > Unexpected dispose() in CompositeCacheManager.release() > --- > > Key: JCS-184 > URL: https://issues.apache.org/jira/browse/JCS-184 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.2 >Reporter: at >Assignee: Bruno P. Kinoshita > Fix For: jcs-3.0 > > > If debug-logging is *not* enabled the return-statement is ignored and the > code falls-through to cache.dispose(). > See Line 739 in > http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCacheManager.java?revision=1803806=markup -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCS-183) JCache CDI integration is slow
[ https://issues.apache.org/jira/browse/JCS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-183: --- Fix Version/s: jcs-2.2.1 > JCache CDI integration is slow > -- > > Key: JCS-183 > URL: https://issues.apache.org/jira/browse/JCS-183 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.2.1, jcs-2.3 > > > JCache CDI integration uses too much reflection to be performant at runtime, > this task is about reducing it as much as possible -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCS-183) JCache CDI integration is slow
[ https://issues.apache.org/jira/browse/JCS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-183: --- Fix Version/s: jcs-2.3 > JCache CDI integration is slow > -- > > Key: JCS-183 > URL: https://issues.apache.org/jira/browse/JCS-183 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.3 > > > JCache CDI integration uses too much reflection to be performant at runtime, > this task is about reducing it as much as possible -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCS-183) JCache CDI integration is slow
[ https://issues.apache.org/jira/browse/JCS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-183: --- Fix Version/s: (was: jcs-2.2) > JCache CDI integration is slow > -- > > Key: JCS-183 > URL: https://issues.apache.org/jira/browse/JCS-183 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > > JCache CDI integration uses too much reflection to be performant at runtime, > this task is about reducing it as much as possible -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JCS-183) JCache CDI integration is slow
[ https://issues.apache.org/jira/browse/JCS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-183: --- Fix Version/s: jcs-2.2 > JCache CDI integration is slow > -- > > Key: JCS-183 > URL: https://issues.apache.org/jira/browse/JCS-183 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.2 > > > JCache CDI integration uses too much reflection to be performant at runtime, > this task is about reducing it as much as possible -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (JCS-183) JCache CDI integration is slow
[ https://issues.apache.org/jira/browse/JCS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-183. Resolution: Fixed > JCache CDI integration is slow > -- > > Key: JCS-183 > URL: https://issues.apache.org/jira/browse/JCS-183 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > > JCache CDI integration uses too much reflection to be performant at runtime, > this task is about reducing it as much as possible -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JCS-183) JCache CDI integration is slow
Romain Manni-Bucau created JCS-183: -- Summary: JCache CDI integration is slow Key: JCS-183 URL: https://issues.apache.org/jira/browse/JCS-183 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau JCache CDI integration uses too much reflection to be performant at runtime, this task is about reducing it as much as possible -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (JCS-180) CacheInvocationContextImpl NPE if method doesnt have any argument
[ https://issues.apache.org/jira/browse/JCS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-180. Resolution: Fixed > CacheInvocationContextImpl NPE if method doesnt have any argument > - > > Key: JCS-180 > URL: https://issues.apache.org/jira/browse/JCS-180 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JCS-180) CacheInvocationContextImpl NPE if method doesnt have any argument
Romain Manni-Bucau created JCS-180: -- Summary: CacheInvocationContextImpl NPE if method doesnt have any argument Key: JCS-180 URL: https://issues.apache.org/jira/browse/JCS-180 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-178) client using RemoteCache are not working
[ https://issues.apache.org/jira/browse/JCS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050081#comment-16050081 ] Romain Manni-Bucau commented on JCS-178: Ok, let me know if you need help for the test part or something else. I can find a slot where I can (really) work on it next week. > client using RemoteCache are not working > > > Key: JCS-178 > URL: https://issues.apache.org/jira/browse/JCS-178 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade is not usable cause of its constructor loop > (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-178) client using RemoteCache are not working
[ https://issues.apache.org/jira/browse/JCS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049544#comment-16049544 ] Romain Manni-Bucau commented on JCS-178: Sounds good, here is the original commit https://github.com/apache/commons-jcs/commit/eee7e7c4b278274240ad7458da9d9073b7374415. At the beginning the list was empty but missed we just get the reference now. We can desire to keep the list copy (not the references) but [~lucianc] proposal sounds very good > client using RemoteCache are not working > > > Key: JCS-178 > URL: https://issues.apache.org/jira/browse/JCS-178 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade is not usable cause of its constructor loop > (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JCS-178) client using RemoteCache are not working
[ https://issues.apache.org/jira/browse/JCS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049333#comment-16049333 ] Romain Manni-Bucau commented on JCS-178: [~tv] you are probably right, just got a user reported the beta examples don't work anymore (examples I showed during a JUG) so checked why it was failing, found the ConcurrentModificationException and finally found the commit having refactored based on some automated tool the class to change the loop. You can see it as a partial revert so think it solved the actual issue but agree we should add some coverage here. > client using RemoteCache are not working > > > Key: JCS-178 > URL: https://issues.apache.org/jira/browse/JCS-178 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Thomas Vandahl > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade is not usable cause of its constructor loop > (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JCS-178) client using RemoteCache are not working
Romain Manni-Bucau created JCS-178: -- Summary: client using RemoteCache are not working Key: JCS-178 URL: https://issues.apache.org/jira/browse/JCS-178 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.2 RemoteCacheNoWaitFacade is not usable cause of its constructor loop (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (JCS-178) client using RemoteCache are not working
[ https://issues.apache.org/jira/browse/JCS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-178. Resolution: Fixed > client using RemoteCache are not working > > > Key: JCS-178 > URL: https://issues.apache.org/jira/browse/JCS-178 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.2 > > > RemoteCacheNoWaitFacade is not usable cause of its constructor loop > (concurrent modification) leading to the remote cache not being usable. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (JCS-174) ClassLoaderAwareCache shouldnt impose the object type to be serializable
[ https://issues.apache.org/jira/browse/JCS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-174. Resolution: Fixed > ClassLoaderAwareCache shouldnt impose the object type to be serializable > > > Key: JCS-174 > URL: https://issues.apache.org/jira/browse/JCS-174 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (JCS-174) ClassLoaderAwareCache shouldnt impose the object type to be serializable
Romain Manni-Bucau created JCS-174: -- Summary: ClassLoaderAwareCache shouldnt impose the object type to be serializable Key: JCS-174 URL: https://issues.apache.org/jira/browse/JCS-174 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (JCS-173) cdi integration doesnt find static annotations on interfaces of (java) proxies
[ https://issues.apache.org/jira/browse/JCS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-173. Resolution: Fixed > cdi integration doesnt find static annotations on interfaces of (java) proxies > -- > > Key: JCS-173 > URL: https://issues.apache.org/jira/browse/JCS-173 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (JCS-173) cdi integration doesnt find static annotations on interfaces of (java) proxies
Romain Manni-Bucau created JCS-173: -- Summary: cdi integration doesnt find static annotations on interfaces of (java) proxies Key: JCS-173 URL: https://issues.apache.org/jira/browse/JCS-173 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.2 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (JCS-170) [JCache] cache name can make JMX registration fail
[ https://issues.apache.org/jira/browse/JCS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-170: --- Summary: [JCache] cache name can make JMX registration fail (was: cache name can make JMX registration fail) > [JCache] cache name can make JMX registration fail > -- > > Key: JCS-170 > URL: https://issues.apache.org/jira/browse/JCS-170 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCS-170) cache name can make JMX registration fail
[ https://issues.apache.org/jira/browse/JCS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-170. Resolution: Fixed > cache name can make JMX registration fail > - > > Key: JCS-170 > URL: https://issues.apache.org/jira/browse/JCS-170 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-170) cache name can make JMX registration fail
Romain Manni-Bucau created JCS-170: -- Summary: cache name can make JMX registration fail Key: JCS-170 URL: https://issues.apache.org/jira/browse/JCS-170 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCS-169) [JCache] Access Expiry not respected
[ https://issues.apache.org/jira/browse/JCS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-169. Resolution: Fixed > [JCache] Access Expiry not respected > > > Key: JCS-169 > URL: https://issues.apache.org/jira/browse/JCS-169 > Project: Commons JCS > Issue Type: Bug >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-169) [JCache] Access Expiry not respected
Romain Manni-Bucau created JCS-169: -- Summary: [JCache] Access Expiry not respected Key: JCS-169 URL: https://issues.apache.org/jira/browse/JCS-169 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCS-168) cdi/nocdi jcache jar doesnt contain the right META-INF/services/javax.enterprise.inject.spi.Extension file
[ https://issues.apache.org/jira/browse/JCS-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-168. Resolution: Fixed Assignee: Romain Manni-Bucau > cdi/nocdi jcache jar doesnt contain the right > META-INF/services/javax.enterprise.inject.spi.Extension file > -- > > Key: JCS-168 > URL: https://issues.apache.org/jira/browse/JCS-168 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-2 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-168) cdi/nocdi jcache jar doesnt contain the right META-INF/services/javax.enterprise.inject.spi.Extension file
Romain Manni-Bucau created JCS-168: -- Summary: cdi/nocdi jcache jar doesnt contain the right META-INF/services/javax.enterprise.inject.spi.Extension file Key: JCS-168 URL: https://issues.apache.org/jira/browse/JCS-168 Project: Commons JCS Issue Type: Bug Affects Versions: jcs-2.0-beta-2 Reporter: Romain Manni-Bucau Fix For: jcs-2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DBCP-464) managed shared connections can lead to a NPE on close
[
https://issues.apache.org/jira/browse/DBCP-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated DBCP-464:
Description:
in CompletionListener the delegate will be set to false but the connection will
not be closed so when calling close later and if the connection exited a
transaction context then it will try to close it and lead to a NPE
Here my workaround:
{code}
@Override
protected DataSource createDataSourceInstance() throws SQLException {
final TransactionRegistry transactionRegistry =
getTransactionRegistry();
if (transactionRegistry == null) {
throw new IllegalStateException("TransactionRegistry has not been
set");
}
if (getConnectionPool() == null) {
throw new IllegalStateException("Pool has not been set");
}
final PoolingDataSource pds = new
ManagedDataSource(getConnectionPool(), transactionRegistry)
{
@Override
public Connection getConnection() throws SQLException {
return new ManagedConnection(getPool(),
transactionRegistry, isAccessToUnderlyingConnectionAllowed()) {
@Override
public void close() throws SQLException {
if (!isClosedInternal()) {
try {
if (null != getDelegateInternal()) {
super.close();
}
} finally {
setClosedInternal(true);
}
}
}
@Override
public boolean isClosed() throws SQLException {
return isClosedInternal() || null !=
getDelegateInternal() && getDelegateInternal().isClosed();
}
};
}
};
pds.setAccessToUnderlyingConnectionAllowed(isAccessToUnderlyingConnectionAllowed());
return pds;
}
{code}
was:
in CompletionListener the delegate will be set to false but the connection will
not be closed so when calling close later and if the connection exited a
transaction context then it will try to close it and lead to a NPE
Here my workaround:
{code}
@Override
protected DataSource createDataSourceInstance() throws SQLException {
final TransactionRegistry transactionRegistry =
getTransactionRegistry();
if (transactionRegistry == null) {
throw new IllegalStateException("TransactionRegistry has not been
set");
}
if (getConnectionPool() == null) {
throw new IllegalStateException("Pool has not been set");
}
final PoolingDataSource pds = new
ManagedDataSource(getConnectionPool(), transactionRegistry)
{
@Override
public Connection getConnection() throws SQLException {
return new ManagedConnection(getPool(),
transactionRegistry, isAccessToUnderlyingConnectionAllowed()) {
@Override
public void close() throws SQLException {
// here is the additional check to do
if (getDelegateInternal() == null) {
return;
}
super.close();
}
};
}
};
pds.setAccessToUnderlyingConnectionAllowed(isAccessToUnderlyingConnectionAllowed());
return pds;
}
{code}
> managed shared connections can lead to a NPE on close
> -
>
> Key: DBCP-464
> URL: https://issues.apache.org/jira/browse/DBCP-464
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.4, 2.1
>Reporter: Romain Manni-Bucau
>
> in CompletionListener the delegate will be set to false but the connection
> will not be closed so when calling close later and if the connection exited a
> transaction context then it will try to close it and lead to a NPE
> Here my workaround:
> {code}
> @Override
> protected DataSource createDataSourceInstance() throws SQLException {
> final TransactionRegistry transactionRegistry =
> getTransactionRegistry();
> if (transactionRegistry == null) {
> throw new IllegalStateException("TransactionRegistry has not been
> set");
> }
> if (getConnectionPool() == null) {
> throw new IllegalStateException("Pool has not been set");
> }
> final PoolingDataSource pds = new
> ManagedDataSource(getConnectionPool(),
> transactionRegistry) {
> @Override
> public Connection getConnection() throws SQLException {
> return new ManagedConnection(getPool(),
>
[jira] [Updated] (DBCP-464) managed shared connections can lead to a NPE on close
[
https://issues.apache.org/jira/browse/DBCP-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated DBCP-464:
Affects Version/s: 1.4
2.1
> managed shared connections can lead to a NPE on close
> -
>
> Key: DBCP-464
> URL: https://issues.apache.org/jira/browse/DBCP-464
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 1.4, 2.1
>Reporter: Romain Manni-Bucau
>
> in CompletionListener the delegate will be set to false but the connection
> will not be closed so when calling close later and if the connection exited a
> transaction context then it will try to close it and lead to a NPE
> Here my workaround:
> {code}
> @Override
> protected DataSource createDataSourceInstance() throws SQLException {
> final TransactionRegistry transactionRegistry =
> getTransactionRegistry();
> if (transactionRegistry == null) {
> throw new IllegalStateException("TransactionRegistry has not been
> set");
> }
> if (getConnectionPool() == null) {
> throw new IllegalStateException("Pool has not been set");
> }
> final PoolingDataSource pds = new
> ManagedDataSource(getConnectionPool(),
> transactionRegistry) {
> @Override
> public Connection getConnection() throws SQLException {
> return new ManagedConnection(getPool(),
> transactionRegistry, isAccessToUnderlyingConnectionAllowed()) {
> @Override
> public void close() throws SQLException {
> // here is the additional check to do
> if (getDelegateInternal() == null) {
> return;
> }
> super.close();
> }
> };
> }
> };
>
> pds.setAccessToUnderlyingConnectionAllowed(isAccessToUnderlyingConnectionAllowed());
> return pds;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DBCP-464) managed shared connections can lead to a NPE on close
Romain Manni-Bucau created DBCP-464:
---
Summary: managed shared connections can lead to a NPE on close
Key: DBCP-464
URL: https://issues.apache.org/jira/browse/DBCP-464
Project: Commons Dbcp
Issue Type: Bug
Reporter: Romain Manni-Bucau
in CompletionListener the delegate will be set to false but the connection will
not be closed so when calling close later and if the connection exited a
transaction context then it will try to close it and lead to a NPE
Here my workaround:
{code}
@Override
protected DataSource createDataSourceInstance() throws SQLException {
final TransactionRegistry transactionRegistry =
getTransactionRegistry();
if (transactionRegistry == null) {
throw new IllegalStateException("TransactionRegistry has not been
set");
}
if (getConnectionPool() == null) {
throw new IllegalStateException("Pool has not been set");
}
final PoolingDataSource pds = new
ManagedDataSource(getConnectionPool(), transactionRegistry)
{
@Override
public Connection getConnection() throws SQLException {
return new ManagedConnection(getPool(),
transactionRegistry, isAccessToUnderlyingConnectionAllowed()) {
@Override
public void close() throws SQLException {
// here is the additional check to do
if (getDelegateInternal() == null) {
return;
}
super.close();
}
};
}
};
pds.setAccessToUnderlyingConnectionAllowed(isAccessToUnderlyingConnectionAllowed());
return pds;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCS-160) Not possible to deploy Java Caching System on WebSphere
[ https://issues.apache.org/jira/browse/JCS-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276296#comment-15276296 ] Romain Manni-Bucau commented on JCS-160: Hi Urvish, all is correctly setup, please have a look to https://github.com/apache/commons-jcs/blob/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/MakeJCacheCDIInterceptorFriendly.java#L83 Maybe websphere doesnt pick up correctly this extension or just has a old CDI implementation not supporting it. > Not possible to deploy Java Caching System on WebSphere > --- > > Key: JCS-160 > URL: https://issues.apache.org/jira/browse/JCS-160 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-2 >Reporter: urvish >Assignee: Romain Manni-Bucau >Priority: Blocker > > Currently we are using JCS as implementation of JSR 107. When we deploy > application on WebSphere version 8.5 the following exception occurs. > commons-jcs-jcache-2.0-beta-1.jar!/META-INF/beans.xml is failed. Reason is : > Interceptor class : org.apache.commons.jcs.jcache.cdi.CachePutInterceptor > must have at least one @InterceptorBindingType > I think the cause is that there is no InterceptorBindingType in the > CachePutInterceptor as required by the specification and the CDI > implementation of the WebSphere (OpenWebBeans) does not accept Interceptors > without bindings. > I think InterceptorBindingType is missing on all Inceptors defined in Bean.xml > Can you please have look? > Kr, > Urvish -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (WEAVER-11) bytecode generated with java 7 or 8 is different and can break on earlier versions
Romain Manni-Bucau created WEAVER-11: Summary: bytecode generated with java 7 or 8 is different and can break on earlier versions Key: WEAVER-11 URL: https://issues.apache.org/jira/browse/WEAVER-11 Project: Commons Weaver Issue Type: Bug Reporter: Romain Manni-Bucau Encountered on bval where building with java 8 makes the bytecode java 8 compliant and breaks under java 7. See org.apache.bval.util.reflection.Reflection#setAccessible where Utf8 java/lang/reflect/Executable is injected with java 8 and Executable is a java 8 class only. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-155) baclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream
Romain Manni-Bucau created JCS-155: -- Summary: baclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream Key: JCS-155 URL: https://issues.apache.org/jira/browse/JCS-155 Project: Commons JCS Issue Type: Bug Affects Versions: jcs-2.0-beta-1 Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.0-beta-2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCS-155) blacklist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream
[ https://issues.apache.org/jira/browse/JCS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-155: --- Summary: blacklist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream (was: blaclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream) > blacklist > org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan > in our custom ObjectInputStream > > > Key: JCS-155 > URL: https://issues.apache.org/jira/browse/JCS-155 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-1 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0-beta-2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCS-155) blaclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream
[ https://issues.apache.org/jira/browse/JCS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-155: --- Summary: blaclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream (was: baclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream) > blaclist > org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan > in our custom ObjectInputStream > --- > > Key: JCS-155 > URL: https://issues.apache.org/jira/browse/JCS-155 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-1 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0-beta-2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCS-155) baclist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in our custom ObjectInputStream
[ https://issues.apache.org/jira/browse/JCS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-155. Resolution: Fixed > baclist > org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan > in our custom ObjectInputStream > -- > > Key: JCS-155 > URL: https://issues.apache.org/jira/browse/JCS-155 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-1 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0-beta-2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-164) Support duplicate header names
[
https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021924#comment-15021924
]
Romain Manni-Bucau commented on CSV-164:
This is what I proposed early: if you do get("duplicatedColumnName") then you
should fail but get("uniqueColumnName") should still work. Doesnt remove the
access (parse) feature since you can still access it by index.
Typically in batchee mapping we have a thin layer on top of [csv] where you can
map CSV on an object either by index or name. If you use name then you define
header names but index access is priviledged over name access which makes this
case pretty smooth: in
https://github.com/apache/incubator-batchee/blob/master/extensions/commons-csv/src/main/java/org/apache/batchee/csv/mapper/DefaultMapper.java#L89
the values of fieldByPosition and fieldByName are unique (ie fieldByName
doesnt have any duplicate with fieldByPosition) to guaratee all of this to work.
The access by header name is a nice API most of the time but not the way CSV
really works (column index by definition) so I like this API but it has some
limits we hit with this issue.
> Support duplicate header names
> --
>
> Key: CSV-164
> URL: https://issues.apache.org/jira/browse/CSV-164
> Project: Commons CSV
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> nothing prevents a CSV to have the same time the same header name so
> validation at the end of org.apache.commons.csv.CSVFormat#validate should
> likely disappear or should support a flag to disable it
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-164) Support duplicate header names
[ https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CSV-164: --- Affects Version/s: 1.2 > Support duplicate header names > -- > > Key: CSV-164 > URL: https://issues.apache.org/jira/browse/CSV-164 > Project: Commons CSV > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Romain Manni-Bucau > > nothing prevents a CSV to have the same time the same header name so > validation at the end of org.apache.commons.csv.CSVFormat#validate should > likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-164) support duplicate headers
[ https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021734#comment-15021734 ] Romain Manni-Bucau commented on CSV-164: Format is used for both parsing and printing. In the issue description I didnt specifically spoke about parsing. I have a chain where i read, change few field values then write the file using the same format for instance. > support duplicate headers > - > > Key: CSV-164 > URL: https://issues.apache.org/jira/browse/CSV-164 > Project: Commons CSV > Issue Type: Bug >Reporter: Romain Manni-Bucau > > nothing prevents a CSV to have the same time the same header name so > validation at the end of org.apache.commons.csv.CSVFormat#validate should > likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-163) add a basic mapping feature
[
https://issues.apache.org/jira/browse/CSV-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023197#comment-15023197
]
Romain Manni-Bucau commented on CSV-163:
so what would be a good place @asf since it is not a single project need (= it
is a "commons" need)? Very few modern application use low level API (get()).
> add a basic mapping feature
> ---
>
> Key: CSV-163
> URL: https://issues.apache.org/jira/browse/CSV-163
> Project: Commons CSV
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> would be neat to be able to map records instead of using string based access:
> {code}
> public class MyRecored {
> @Csv(position = 1) String name;
> @Csv(name = "city") String city;
> // ...
> }
> {code}
> Think it is acceptable to support only basic types (primitives + String/Date
> to start). This constraint would keep the code light and simple - no
> converter - but easier to use than "map"-like API .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CSV-164) support duplicate headers
[ https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021229#comment-15021229 ] Romain Manni-Bucau commented on CSV-164: Well goal would be to respect withHeaders using the printer. Here you changed the expected output. > support duplicate headers > - > > Key: CSV-164 > URL: https://issues.apache.org/jira/browse/CSV-164 > Project: Commons CSV > Issue Type: Bug >Reporter: Romain Manni-Bucau > > nothing prevents a CSV to have the same time the same header name so > validation at the end of org.apache.commons.csv.CSVFormat#validate should > likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-164) support duplicate headers
[ https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15020903#comment-15020903 ] Romain Manni-Bucau commented on CSV-164: Hmm, keeping headers allows to output more nicely/without wrappers. A built in solution would be nicer but sure with wrapping and duplicating some code it can be achieved. It is however not elegant. > support duplicate headers > - > > Key: CSV-164 > URL: https://issues.apache.org/jira/browse/CSV-164 > Project: Commons CSV > Issue Type: Bug >Reporter: Romain Manni-Bucau > > nothing prevents a CSV to have the same time the same header name so > validation at the end of org.apache.commons.csv.CSVFormat#validate should > likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-164) support duplicate headers
[ https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15020652#comment-15020652 ] Romain Manni-Bucau commented on CSV-164: Well I tend to agree it is a bad case but my point is it is common enough to be supported - jsefa, beanio support it btw. An example is top 10 extraction "inline" where you can get something like next sample without much control in $$ softwares: Top1;Score;Top2;Score;Top3;Score Said otherwise i d prefer to not assume in [csv] the design is well done but would be nicer for end users to be flexible. Code to support it is not much and would be better to concentrate all csv code in a single project @asf than in multiple. Does it make sense? > support duplicate headers > - > > Key: CSV-164 > URL: https://issues.apache.org/jira/browse/CSV-164 > Project: Commons CSV > Issue Type: Bug >Reporter: Romain Manni-Bucau > > nothing prevents a CSV to have the same time the same header name so > validation at the end of org.apache.commons.csv.CSVFormat#validate should > likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CSV-163) add a basic mapping feature
Romain Manni-Bucau created CSV-163:
--
Summary: add a basic mapping feature
Key: CSV-163
URL: https://issues.apache.org/jira/browse/CSV-163
Project: Commons CSV
Issue Type: New Feature
Reporter: Romain Manni-Bucau
would be neat to be able to map records instead of using string based access:
{code}
public class MyRecored {
@Csv(position = 1) String name;
@Csv(name = "city") String city;
// ...
}
{code}
Think it is acceptable to support only basic types (primitives + String/Date to
start). This constraint would keep the code light and simple - no converter -
but easier to use than "map"-like API .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CSV-163) add a basic mapping feature
[
https://issues.apache.org/jira/browse/CSV-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018556#comment-15018556
]
Romain Manni-Bucau commented on CSV-163:
was to show we need both. For read we can either use index of named access
(CSVRecord.get()) depending the user mapping/desire and for write we likely
need both to be able to generate the headers if needed.
I'll push a light feature close to tht to batchee likely this week or early
next week but would be awesome to kind of merge. I'll put the link to the
sample there once done.
> add a basic mapping feature
> ---
>
> Key: CSV-163
> URL: https://issues.apache.org/jira/browse/CSV-163
> Project: Commons CSV
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> would be neat to be able to map records instead of using string based access:
> {code}
> public class MyRecored {
> @Csv(position = 1) String name;
> @Csv(name = "city") String city;
> // ...
> }
> {code}
> Think it is acceptable to support only basic types (primitives + String/Date
> to start). This constraint would keep the code light and simple - no
> converter - but easier to use than "map"-like API .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CSV-163) add a basic mapping feature
[
https://issues.apache.org/jira/browse/CSV-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018556#comment-15018556
]
Romain Manni-Bucau edited comment on CSV-163 at 11/20/15 10:10 PM:
---
was to show we need both. For read we can either use index of named access
(CSVRecord.get()) depending the user mapping/desire and for write we likely
need both to be able to generate the headers if needed.
I'll push a light feature close to tht to batchee likely this week or early
next week but would be awesome to kind of merge. I'll put the link to the
sample there once done.
edit: here the experimental feature:
https://github.com/apache/incubator-batchee/blob/20fad4b9d3a00a710a5b0b5736b8fdc0eced5ec9/extensions/commons-csv/src/test/java/org/apache/batchee/csv/CommonsCsvReaderWithDefaultMapperTest.java#L90
was (Author: romain.manni-bucau):
was to show we need both. For read we can either use index of named access
(CSVRecord.get()) depending the user mapping/desire and for write we likely
need both to be able to generate the headers if needed.
I'll push a light feature close to tht to batchee likely this week or early
next week but would be awesome to kind of merge. I'll put the link to the
sample there once done.
> add a basic mapping feature
> ---
>
> Key: CSV-163
> URL: https://issues.apache.org/jira/browse/CSV-163
> Project: Commons CSV
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>
> would be neat to be able to map records instead of using string based access:
> {code}
> public class MyRecored {
> @Csv(position = 1) String name;
> @Csv(name = "city") String city;
> // ...
> }
> {code}
> Think it is acceptable to support only basic types (primitives + String/Date
> to start). This constraint would keep the code light and simple - no
> converter - but easier to use than "map"-like API .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CSV-164) support duplicate headers
[
https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15019133#comment-15019133
]
Romain Manni-Bucau commented on CSV-164:
yep:
{code}
A,B,C,A,b2,C
1,2,3,4,5,6
{code}
A is twice a column but it is a valid CSV file - actually just renamed an
export from a proprietary tool.
> support duplicate headers
> -
>
> Key: CSV-164
> URL: https://issues.apache.org/jira/browse/CSV-164
> Project: Commons CSV
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> nothing prevents a CSV to have the same time the same header name so
> validation at the end of org.apache.commons.csv.CSVFormat#validate should
> likely disappear or should support a flag to disable it
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CSV-164) support duplicate headers
Romain Manni-Bucau created CSV-164: -- Summary: support duplicate headers Key: CSV-164 URL: https://issues.apache.org/jira/browse/CSV-164 Project: Commons CSV Issue Type: Bug Reporter: Romain Manni-Bucau nothing prevents a CSV to have the same time the same header name so validation at the end of org.apache.commons.csv.CSVFormat#validate should likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-164) support duplicate headers
[
https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15019194#comment-15019194
]
Romain Manni-Bucau commented on CSV-164:
If you see the header as a key to access the entries the key is actually the
position.
I know CSVRecord.get("header") would suffer from it.
My proposal is:
- keep current logic *by default*
- keep track of duplicated records if a flag is set
(supportsDuplicatedHeaders?) - note: can log a warning
- if CSVRecord.get(aDuplicatedHeader) is called then throw an exception
Allows to use CSVRecord.get(index) without issues
wdyt?
> support duplicate headers
> -
>
> Key: CSV-164
> URL: https://issues.apache.org/jira/browse/CSV-164
> Project: Commons CSV
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>
> nothing prevents a CSV to have the same time the same header name so
> validation at the end of org.apache.commons.csv.CSVFormat#validate should
> likely disappear or should support a flag to disable it
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CSV-164) support duplicate headers
[ https://issues.apache.org/jira/browse/CSV-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15019273#comment-15019273 ] Romain Manni-Bucau commented on CSV-164: @Gary: I didnt invent this format - I just cant share the actual header names. This is a big (very expensive) system doing an export after some custom querying/extraction. The output headers contains duplicates. If you supply headers (withHeader()) you end up in the same validate() method which makes the call failling - this is what I do actually. Current code uses jsefa which supports it - it doesn't use name indexation at all. I am not sure to follow why [csv] can't support index access - which is the only valid for CSV actually - and header usage as a nice higher level API instead - which means this last one can hit this issue. Side note: you can easily get the exact same issue with excel exports and you can't argue to everybody that their inputs are just garbage - not saying that I disagree, just that i think real life here is stronger than what we can think. > support duplicate headers > - > > Key: CSV-164 > URL: https://issues.apache.org/jira/browse/CSV-164 > Project: Commons CSV > Issue Type: Bug >Reporter: Romain Manni-Bucau > > nothing prevents a CSV to have the same time the same header name so > validation at the end of org.apache.commons.csv.CSVFormat#validate should > likely disappear or should support a flag to disable it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-152) hard to override jcache.ccf
Romain Manni-Bucau created JCS-152: -- Summary: hard to override jcache.ccf Key: JCS-152 URL: https://issues.apache.org/jira/browse/JCS-152 Project: Commons JCS Issue Type: Bug Affects Versions: jcs-2.0-beta-1 Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.0-beta-2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCS-152) hard to override jcache.ccf
[ https://issues.apache.org/jira/browse/JCS-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-152. Resolution: Fixed > hard to override jcache.ccf > > > Key: JCS-152 > URL: https://issues.apache.org/jira/browse/JCS-152 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-1 >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau > Fix For: jcs-2.0-beta-2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-151) defauts CacheKeyGenerator not respected
Romain Manni-Bucau created JCS-151: -- Summary: defauts CacheKeyGenerator not respected Key: JCS-151 URL: https://issues.apache.org/jira/browse/JCS-151 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.0-beta-2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCS-151) defaults CacheKeyGenerator not respected for default case
[ https://issues.apache.org/jira/browse/JCS-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-151: --- Summary: defaults CacheKeyGenerator not respected for default case (was: defauts CacheKeyGenerator not respected) defaults CacheKeyGenerator not respected for default case - Key: JCS-151 URL: https://issues.apache.org/jira/browse/JCS-151 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.0-beta-2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JCS-151) defaults CacheKeyGenerator not respected for default case
[ https://issues.apache.org/jira/browse/JCS-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau closed JCS-151. -- Resolution: Fixed defaults CacheKeyGenerator not respected for default case - Key: JCS-151 URL: https://issues.apache.org/jira/browse/JCS-151 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.0-beta-2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCS-125) Make a jar with the 2.0 code available for download
[ https://issues.apache.org/jira/browse/JCS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14491953#comment-14491953 ] Romain Manni-Bucau commented on JCS-125: [~tv] hi Thomas, hey are http://repo1.maven.org/maven2/org/apache/commons/commons-jcs-dist/2.0-beta-1/ but I can't finish the release since I don't have the perms (asked help on the list but without much success) Make a jar with the 2.0 code available for download --- Key: JCS-125 URL: https://issues.apache.org/jira/browse/JCS-125 Project: Commons JCS Issue Type: Wish Components: Composite Cache Affects Versions: jcs-2.0-beta-1 Environment: Testing Reporter: Richard Eigenmann Assignee: Romain Manni-Bucau Fix For: jcs-2.0-beta-2 For those desiring to try out the 2.0 version it would be very helpful to have the 2.0 jars available for download under the download link on the JCS page. For the 1.3 users it would also be helpful to link to the repo where the concurrent jar can be downloaded. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCS-140) JCacheFilter code logic error
[
https://issues.apache.org/jira/browse/JCS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14481625#comment-14481625
]
Romain Manni-Bucau commented on JCS-140:
[~tv] done, thanks for the reminder!
JCacheFilter code logic error
-
Key: JCS-140
URL: https://issues.apache.org/jira/browse/JCS-140
Project: Commons JCS
Issue Type: Bug
Reporter: liangjiarui
Assignee: Romain Manni-Bucau
Fix For: jcs-2.0-beta-2
final PageKey key = new PageKey(key(servletRequest), gzip);
Page page = cache.get(key);
if (page == null)
{
}
if (page.status == SC_OK) {
checkResponse(httpServletResponse);
the last line always throw exception for the first time the specified url is
requested,because the response is commited in the previous if.
I think the logic of doFilter should be like this:
String key=getKeyFromRequest();
Page page=cache.get(key);
if(page==null){
chain.doFilter();
cache.put(key,response);
}else{
response.write(cache);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCS-140) JCacheFilter code logic error
[
https://issues.apache.org/jira/browse/JCS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14390980#comment-14390980
]
Romain Manni-Bucau commented on JCS-140:
[~tv] sure
JCacheFilter code logic error
-
Key: JCS-140
URL: https://issues.apache.org/jira/browse/JCS-140
Project: Commons JCS
Issue Type: Bug
Reporter: liangjiarui
Assignee: Romain Manni-Bucau
Fix For: jcs-2.0-beta-2
final PageKey key = new PageKey(key(servletRequest), gzip);
Page page = cache.get(key);
if (page == null)
{
}
if (page.status == SC_OK) {
checkResponse(httpServletResponse);
the last line always throw exception for the first time the specified url is
requested,because the response is commited in the previous if.
I think the logic of doFilter should be like this:
String key=getKeyFromRequest();
Page page=cache.get(key);
if(page==null){
chain.doFilter();
cache.put(key,response);
}else{
response.write(cache);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCS-140) JCacheFilter code logic error
[
https://issues.apache.org/jira/browse/JCS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau resolved JCS-140.
Resolution: Fixed
Fix Version/s: jcs-2.0-beta-2
JCacheFilter code logic error
-
Key: JCS-140
URL: https://issues.apache.org/jira/browse/JCS-140
Project: Commons JCS
Issue Type: Bug
Reporter: liangjiarui
Assignee: Romain Manni-Bucau
Fix For: jcs-2.0-beta-2
final PageKey key = new PageKey(key(servletRequest), gzip);
Page page = cache.get(key);
if (page == null)
{
}
if (page.status == SC_OK) {
checkResponse(httpServletResponse);
the last line always throw exception for the first time the specified url is
requested,because the response is commited in the previous if.
I think the logic of doFilter should be like this:
String key=getKeyFromRequest();
Page page=cache.get(key);
if(page==null){
chain.doFilter();
cache.put(key,response);
}else{
response.write(cache);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JCS-142) CDI extension doesn't work if not scanned
[ https://issues.apache.org/jira/browse/JCS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-142. Resolution: Fixed Fix Version/s: jcs-2.0-alpha-2 CDI extension doesn't work if not scanned - Key: JCS-142 URL: https://issues.apache.org/jira/browse/JCS-142 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.0-alpha-2 With CDI 1.1 we can solve it properly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCS-142) CDI extension doesn't work if not scanned
[ https://issues.apache.org/jira/browse/JCS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-142: --- Description: With CDI 1.1 we can solve it properly CDI extension doesn't work if not scanned - Key: JCS-142 URL: https://issues.apache.org/jira/browse/JCS-142 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: jcs-2.0-alpha-2 With CDI 1.1 we can solve it properly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCS-142) CDI extension doesn't work if not scanned
[ https://issues.apache.org/jira/browse/JCS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-142: --- Summary: CDI extension doesn't work if not scanned (was: CDi extension doesn't work if not scanned) CDI extension doesn't work if not scanned - Key: JCS-142 URL: https://issues.apache.org/jira/browse/JCS-142 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCS-142) CDi extension doesn't work if not scanned
Romain Manni-Bucau created JCS-142: -- Summary: CDi extension doesn't work if not scanned Key: JCS-142 URL: https://issues.apache.org/jira/browse/JCS-142 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMMONSSITE-79) maven-remote-resources-plugin is skipped by default + recent apache parent pom uses the same version
[ https://issues.apache.org/jira/browse/COMMONSSITE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14246562#comment-14246562 ] Romain Manni-Bucau commented on COMMONSSITE-79: --- it means that if I dont have NOTICE/LICENSE files then I'm compliant with commons parent pom. Exact same subproject but with apache parent pom works fine. maven-remote-resources-plugin is skipped by default + recent apache parent pom uses the same version Key: COMMONSSITE-79 URL: https://issues.apache.org/jira/browse/COMMONSSITE-79 Project: Commons All Issue Type: Bug Reporter: Romain Manni-Bucau Solution: remove declaration of this plugin in commons parent pom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMMONSSITE-79) maven-remote-resources-plugin is skipped by default + recent apache parent pom uses the same version
[ https://issues.apache.org/jira/browse/COMMONSSITE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14246577#comment-14246577 ] Romain Manni-Bucau commented on COMMONSSITE-79: --- commons parent skips maven-remote-resources-plugin plugin so remote notice/license are not added to the project (which is the behavior of apache parent pom). This means when creating a commons project if you don't redefine this plugin to not skip it then you miss these files. If there are duplicated files it means some commons project should be fixed but not the parent IMO maven-remote-resources-plugin is skipped by default + recent apache parent pom uses the same version Key: COMMONSSITE-79 URL: https://issues.apache.org/jira/browse/COMMONSSITE-79 Project: Commons All Issue Type: Bug Reporter: Romain Manni-Bucau Solution: remove declaration of this plugin in commons parent pom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMMONSSITE-79) maven-remote-resources-plugin is skipped by default + recent apache parent pom uses the same version
[ https://issues.apache.org/jira/browse/COMMONSSITE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14246606#comment-14246606 ] Romain Manni-Bucau commented on COMMONSSITE-79: --- I dont get the point when the project is not a donation. If so then apache parent pom should be aligned maven-remote-resources-plugin is skipped by default + recent apache parent pom uses the same version Key: COMMONSSITE-79 URL: https://issues.apache.org/jira/browse/COMMONSSITE-79 Project: Commons All Issue Type: Bug Reporter: Romain Manni-Bucau Solution: remove declaration of this plugin in commons parent pom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMMONSSITE-79) maven-remote-resources-plugin is skipped by default + recent apache parent pom uses the same version
[ https://issues.apache.org/jira/browse/COMMONSSITE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14246622#comment-14246622 ] Romain Manni-Bucau commented on COMMONSSITE-79: --- So basically we consider this doesn't have to work OOTB? If so you can close this issue but it doesn't help [commons] IMO maven-remote-resources-plugin is skipped by default + recent apache parent pom uses the same version Key: COMMONSSITE-79 URL: https://issues.apache.org/jira/browse/COMMONSSITE-79 Project: Commons All Issue Type: Bug Reporter: Romain Manni-Bucau Solution: remove declaration of this plugin in commons parent pom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COMMONSSITE-79) maven-remote-resources-plugin is skipped by default + recent apache parent pom uses the same version
Romain Manni-Bucau created COMMONSSITE-79: - Summary: maven-remote-resources-plugin is skipped by default + recent apache parent pom uses the same version Key: COMMONSSITE-79 URL: https://issues.apache.org/jira/browse/COMMONSSITE-79 Project: Commons All Issue Type: Bug Reporter: Romain Manni-Bucau Solution: remove declaration of this plugin in commons parent pom -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCS-119) replace synchronized blocks by java locks or concurrenhashmap
[ https://issues.apache.org/jira/browse/JCS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14117979#comment-14117979 ] Romain Manni-Bucau commented on JCS-119: [~yogu13] sure and yes java 6 replace synchronized blocks by java locks or concurrenhashmap - Key: JCS-119 URL: https://issues.apache.org/jira/browse/JCS-119 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: jcs-2.0 A cache is typically used in a concurrent environment. Since Java 6 using a ReentrantLock is faster than synchronized so can be interesting to replace synchronized blocks by a lock. Places i'm thinking about: * CompositeCache * AbstractDoubleLinkedListMemoryCache * LHMLRUMemoryCache * DoubleLinkedList * LRUMap * SingleLinkedList * SortedPreferentialArray Some places where replacing a HashMap by a ConcurrentHashMap can allow to get rid of synchronized without needing a lock: * CacheEventQueue * AbstractDiskCache * CacheWatchRepairable There are other places but this is the main I saw. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103512#comment-14103512 ] Romain Manni-Bucau commented on JCS-122: Slf4j will work but doesn't help making logging not consistent (if we are able to get rid of sl4j in tomee we would be very happy). Since we own the code we should be able to allow to switch the facade). Nothing preventing a 2.0 BTW. rework logging? --- Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103742#comment-14103742 ] Romain Manni-Bucau commented on JCS-122: that's why it needs to be pluggable (that's 2 small classes). slf4j is broken in hierarchic classloaders. JUL too but is adapted in containers (Tomcat, TomEE, JBoss...) to work. In all cases I think this task will go for 2.1. rework logging? --- Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103771#comment-14103771 ] Romain Manni-Bucau commented on JCS-122: Exactly, it does nothing with classloaders (as [logging]) so if you have slf4j in the container and the app it is really a nightmare for the app if the container doesn't help. TomEE helps app to work as expected but it is smoother with JUL since it is built it and integrated. Logging thread are infinite and the need is just trivial - all EE libs of Apache have their thin layer to solve it - so not sure that's the moment (we want to release) to start it now. rework logging? --- Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103816#comment-14103816 ] Romain Manni-Bucau commented on JCS-122: Guess it was a bulk update to force us to take attention to it. Not a show stopper (I'll send my feedback tonight normally on open issues) rework logging? --- Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (LANG-1027) org.apache.commons.lang3.SystemUtils#isJavaVersionAtLeast should return true by default
[ https://issues.apache.org/jira/browse/LANG-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14067890#comment-14067890 ] Romain Manni-Bucau commented on LANG-1027: -- Hehe, true, not yet used to it. Added JAVA_RECENT as version to solve it. Actually current model could be reworked since java 1.10 will more or less break it as far as I saw and java 2.x will not be supported. JAVA_RECENT should tolerate it (goal of this task) but this is not the nominal case. Pushed a fix. Will surely need some cycles to get it right since it poped up previous issues. org.apache.commons.lang3.SystemUtils#isJavaVersionAtLeast should return true by default --- Key: LANG-1027 URL: https://issues.apache.org/jira/browse/LANG-1027 Project: Commons Lang Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: 3.4 Hi last [lang] release doesn't support java 9 (not in JavaVersion enum). However it shouldn't break the org.apache.commons.lang3.SystemUtils#isJavaVersionAtLeast method which should return true when java version is not known (not known = older) My proposal is to add UNKNOWN to the enum and override atLeast for this particular value to return true. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (LANG-1027) org.apache.commons.lang3.SystemUtils#isJavaVersionAtLeast should return true by default
[ https://issues.apache.org/jira/browse/LANG-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved LANG-1027. -- Resolution: Fixed Fix Version/s: (was: Patch Needed) 3.4 org.apache.commons.lang3.SystemUtils#isJavaVersionAtLeast should return true by default --- Key: LANG-1027 URL: https://issues.apache.org/jira/browse/LANG-1027 Project: Commons Lang Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: 3.4 Hi last [lang] release doesn't support java 9 (not in JavaVersion enum). However it shouldn't break the org.apache.commons.lang3.SystemUtils#isJavaVersionAtLeast method which should return true when java version is not known (not known = older) My proposal is to add UNKNOWN to the enum and override atLeast for this particular value to return true. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (LANG-1027) org.apache.commons.lang3.SystemUtils#isJavaVersionAtLeast should return true by default
Romain Manni-Bucau created LANG-1027: Summary: org.apache.commons.lang3.SystemUtils#isJavaVersionAtLeast should return true by default Key: LANG-1027 URL: https://issues.apache.org/jira/browse/LANG-1027 Project: Commons Lang Issue Type: Improvement Reporter: Romain Manni-Bucau Hi last [lang] release doesn't support java 9 (not in JavaVersion enum). However it shouldn't break the org.apache.commons.lang3.SystemUtils#isJavaVersionAtLeast method which should return true when java version is not known (not known = older) My proposal is to add UNKNOWN to the enum and override atLeast for this particular value to return true. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JCS-129) don't log stats on dispose
Romain Manni-Bucau created JCS-129: -- Summary: don't log stats on dispose Key: JCS-129 URL: https://issues.apache.org/jira/browse/JCS-129 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (JCS-127) JCache implementation backed by a concurrenthashmap
[ https://issues.apache.org/jira/browse/JCS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau closed JCS-127. -- Resolution: Won't Fix JCache implementation backed by a concurrenthashmap --- Key: JCS-127 URL: https://issues.apache.org/jira/browse/JCS-127 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 Attachments: JCS-concurrentHashMap.patch, concurrenthashmap-noproxy.patch, concurrenthashmap.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (JCS-127) JCache implementation backed by a concurrenthashmap
[ https://issues.apache.org/jira/browse/JCS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau reopened JCS-127: JCache implementation backed by a concurrenthashmap --- Key: JCS-127 URL: https://issues.apache.org/jira/browse/JCS-127 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 Attachments: JCS-concurrentHashMap.patch, concurrenthashmap-noproxy.patch, concurrenthashmap.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-126) JCache allows Closeable for components
[ https://issues.apache.org/jira/browse/JCS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-126: --- Attachment: JCS-closeable.patch previous JCS-closeable had references to RemoteCache which was wrong JCache allows Closeable for components -- Key: JCS-126 URL: https://issues.apache.org/jira/browse/JCS-126 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Attachments: JCS-closeable-evictionstats.patch, JCS-closeable.patch, JCS-closeable.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (JCS-126) JCache allows Closeable for components
[ https://issues.apache.org/jira/browse/JCS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-126. Resolution: Fixed JCache allows Closeable for components -- Key: JCS-126 URL: https://issues.apache.org/jira/browse/JCS-126 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Attachments: JCS-closeable-evictionstats.patch, JCS-closeable-rebase.patch, JCS-closeable.patch, JCS-closeable.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JCS-127) JCache implementation backed by a concurrenthashmap
Romain Manni-Bucau created JCS-127: -- Summary: JCache implementation backed by a concurrenthashmap Key: JCS-127 URL: https://issues.apache.org/jira/browse/JCS-127 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Attachments: JCS-concurrentHashMap.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-127) JCache implementation backed by a concurrenthashmap
[ https://issues.apache.org/jira/browse/JCS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-127: --- Attachment: JCS-concurrentHashMap.patch patch using a concurrenthashmap and no more jcs-core to implement jcache (will be easier to exchange on this topic on the list thenà JCache implementation backed by a concurrenthashmap --- Key: JCS-127 URL: https://issues.apache.org/jira/browse/JCS-127 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Attachments: JCS-concurrentHashMap.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-127) JCache implementation backed by a concurrenthashmap
[ https://issues.apache.org/jira/browse/JCS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-127: --- Attachment: (was: JCS-concurrentHashMap.patch) JCache implementation backed by a concurrenthashmap --- Key: JCS-127 URL: https://issues.apache.org/jira/browse/JCS-127 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (JCS-127) JCache implementation backed by a concurrenthashmap
[ https://issues.apache.org/jira/browse/JCS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990524#comment-13990524 ] Romain Manni-Bucau edited comment on JCS-127 at 5/6/14 10:44 AM: - patch using a concurrenthashmap and no more jcs-core to implement jcache (will be easier to exchange on this topic on the list then) was (Author: romain.manni-bucau): patch using a concurrenthashmap and no more jcs-core to implement jcache (will be easier to exchange on this topic on the list thenà JCache implementation backed by a concurrenthashmap --- Key: JCS-127 URL: https://issues.apache.org/jira/browse/JCS-127 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-127) JCache implementation backed by a concurrenthashmap
[ https://issues.apache.org/jira/browse/JCS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-127: --- Attachment: JCS-concurrentHashMap.patch JCache implementation backed by a concurrenthashmap --- Key: JCS-127 URL: https://issues.apache.org/jira/browse/JCS-127 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Attachments: JCS-concurrentHashMap.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-127) JCache implementation backed by a concurrenthashmap
[ https://issues.apache.org/jira/browse/JCS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-127: --- Attachment: concurrenthashmap.patch better patch with cleanup (concurrenthashmap.patch) JCache implementation backed by a concurrenthashmap --- Key: JCS-127 URL: https://issues.apache.org/jira/browse/JCS-127 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Attachments: JCS-concurrentHashMap.patch, concurrenthashmap.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-127) JCache implementation backed by a concurrenthashmap
[ https://issues.apache.org/jira/browse/JCS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-127: --- Attachment: concurrenthashmap-noproxy.patch noproxy patch getting rid of Proxy which slows down too much the cache so using a standard delegate pattern JCache implementation backed by a concurrenthashmap --- Key: JCS-127 URL: https://issues.apache.org/jira/browse/JCS-127 Project: Commons JCS Issue Type: Bug Reporter: Romain Manni-Bucau Attachments: JCS-concurrentHashMap.patch, concurrenthashmap-noproxy.patch, concurrenthashmap.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-126) JCache allows Closeable for components
[ https://issues.apache.org/jira/browse/JCS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-126: --- Attachment: JCS-closeable-evictionstats.patch JCache allows Closeable for components -- Key: JCS-126 URL: https://issues.apache.org/jira/browse/JCS-126 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Attachments: JCS-closeable-evictionstats.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JCS-126) JCache allows Closeable for components
Romain Manni-Bucau created JCS-126: -- Summary: JCache allows Closeable for components Key: JCS-126 URL: https://issues.apache.org/jira/browse/JCS-126 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Attachments: JCS-closeable-evictionstats.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-126) JCache allows Closeable for components
[ https://issues.apache.org/jira/browse/JCS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-126: --- Attachment: JCS-closeable.patch oops, previous patch was containing work in progress, please us JCS-closeable.patch only JCache allows Closeable for components -- Key: JCS-126 URL: https://issues.apache.org/jira/browse/JCS-126 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Attachments: JCS-closeable-evictionstats.patch, JCS-closeable.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-120) cleanup mvn deps + add missing headers
[ https://issues.apache.org/jira/browse/JCS-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-120: --- Attachment: JCS-fix.patch JCS-fix fixes current build cleanup mvn deps + add missing headers -- Key: JCS-120 URL: https://issues.apache.org/jira/browse/JCS-120 Project: Commons JCS Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Thomas Vandahl Fix For: jcs-2.0.0 Attachments: JCS-fix.patch, JCS.patch, diff -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-120) cleanup mvn deps + add missing headers
[ https://issues.apache.org/jira/browse/JCS-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated JCS-120: --- Attachment: JCS-withcdi.patch JCS-withcdi.patch replaces all previous patches and makes jcs passing all TCKs (including CDI) cleanup mvn deps + add missing headers -- Key: JCS-120 URL: https://issues.apache.org/jira/browse/JCS-120 Project: Commons JCS Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Thomas Vandahl Fix For: jcs-2.0.0 Attachments: JCS-fix.patch, JCS-withcdi.patch, JCS.patch, diff -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JCS-122) rework logging?
Romain Manni-Bucau created JCS-122: -- Summary: rework logging? Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13987967#comment-13987967 ] Romain Manni-Bucau commented on JCS-122: Yes but reality today is a lot rely on slf4j and the other point is we'll need JUL for tomee without commons-logging. rework logging? --- Key: JCS-122 URL: https://issues.apache.org/jira/browse/JCS-122 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau currently JCS relies on [logging] Would be great to get rid of this dependency. Solutions I see: 1) use JUL (with extensibility like in http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) 2) write a little factory with a jcs.Logger to be able to switch Goal is to be able to adapt to frameworks and users. Guess first will be often JUL (TomEE), second SLF4J, [logging]... I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JCS-120) cleanup mvn deps + add missing headers
Romain Manni-Bucau created JCS-120: -- Summary: cleanup mvn deps + add missing headers Key: JCS-120 URL: https://issues.apache.org/jira/browse/JCS-120 Project: Commons JCS Issue Type: Task Reporter: Romain Manni-Bucau -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (JCS-120) cleanup mvn deps + add missing headers
[ https://issues.apache.org/jira/browse/JCS-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau reopened JCS-120: JCS.patch was not correctly applied, some assertNotNull are still missing cleanup mvn deps + add missing headers -- Key: JCS-120 URL: https://issues.apache.org/jira/browse/JCS-120 Project: Commons JCS Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Thomas Vandahl Fix For: jcs-2.0.0 Attachments: JCS.patch, diff -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (JCS-118) implement JCache (JSR 107)
[ https://issues.apache.org/jira/browse/JCS-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13982081#comment-13982081 ] Romain Manni-Bucau edited comment on JCS-118 at 4/27/14 10:04 PM: -- Hi you can see the last 3 commits on https://github.com/rmannibucau/commons-jcs/commits/trunk basically my github fork is up to date edit: here is the full patch: https://github.com/apache/commons-jcs/pull/1.diff was (Author: romain.manni-bucau): Hi you can see the last 3 commits on https://github.com/rmannibucau/commons-jcs/commits/trunk basically my github fork is up to date implement JCache (JSR 107) -- Key: JCS-118 URL: https://issues.apache.org/jira/browse/JCS-118 Project: Commons JCS Issue Type: New Feature Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 Attachments: JCS-jcache-beginning-with-TCK.patch, JCS-jcache-beginning.patch, JCS-jcache-beginning.patch, JCS-tck-471_107_70.diff, JCS-tck.diff Would be great to get a JCache impl @Apache and JCS seems the most adapted -- This message was sent by Atlassian JIRA (v6.2#6252)
