[jira] [Resolved] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GERONIMO-4576. --- Resolution: Fixed Sending geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionImpl.java Transmitting file data .done Committing transaction... Committed revision 1769063. > Make persistence exceptions more visible to client > -- > > Key: GERONIMO-4576 > URL: https://issues.apache.org/jira/browse/GERONIMO-4576 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.2 > Environment: Linux, Windows >Reporter: Joe Bohn >Assignee: Guillaume Nodet >Priority: Minor > Fix For: Wish List > > Attachments: GERONIMO-4576-1.patch > > > See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the > original problem. That core problem was resolved. However, upon resolution > it was mentioned that it would be beneficial to report more specific failure > information back to the client. From GERONIMO-3907: > Ralf Baumhof - 06/May/08 06:17 AM > Today if have tested the new Geronimo release 2.1.1 (published on > 28.04.2008). The problem is now fixed. If the server gets an error on trying > a commit, this error is now thrown to the web bean. > Exception text: > javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, > presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback Root Cause: > javax.transaction.TransactionRolledbackException : Transaction was rolled > back, presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback > Unfortunately there is no proper root cause attached to the exception. So the > cause can only be seen in the server console, but can not be reported to the > user. It would be very nice if you could change this in a later release. > Thanks for your help. > Vincent MATHON - 06/Nov/08 02:03 AM > I agree that exceptions on the server side should not be thrown to the client > side since such exceptions types might not be known by the client. However, > for unit testing purpose, it is useful to attach the root cause to the > RollBackException. I have modified a few lines in > org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the > root cause in case of RollBackException and it works for my unit testing > purpose (I have not enough background on the java transaction architecture > topic to submit a patch for production). It would be great to define a > configuration parameter that permits to provide the root cause to the client > and keep the current behaviour that does not by default. > Geoff Callender - 22/Dec/08 03:36 AM > It's useful for more than unit testing - it's essential to be able to inform > the client what's wrong with the request. I've added some examples of this to > https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GERONIMO-4576: -- Component/s: (was: persistence) transaction manager > Make persistence exceptions more visible to client > -- > > Key: GERONIMO-4576 > URL: https://issues.apache.org/jira/browse/GERONIMO-4576 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 2.2 > Environment: Linux, Windows >Reporter: Joe Bohn >Assignee: Guillaume Nodet >Priority: Minor > Fix For: Wish List > > Attachments: GERONIMO-4576-1.patch > > > See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the > original problem. That core problem was resolved. However, upon resolution > it was mentioned that it would be beneficial to report more specific failure > information back to the client. From GERONIMO-3907: > Ralf Baumhof - 06/May/08 06:17 AM > Today if have tested the new Geronimo release 2.1.1 (published on > 28.04.2008). The problem is now fixed. If the server gets an error on trying > a commit, this error is now thrown to the web bean. > Exception text: > javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, > presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback Root Cause: > javax.transaction.TransactionRolledbackException : Transaction was rolled > back, presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback > Unfortunately there is no proper root cause attached to the exception. So the > cause can only be seen in the server console, but can not be reported to the > user. It would be very nice if you could change this in a later release. > Thanks for your help. > Vincent MATHON - 06/Nov/08 02:03 AM > I agree that exceptions on the server side should not be thrown to the client > side since such exceptions types might not be known by the client. However, > for unit testing purpose, it is useful to attach the root cause to the > RollBackException. I have modified a few lines in > org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the > root cause in case of RollBackException and it works for my unit testing > purpose (I have not enough background on the java transaction architecture > topic to submit a patch for production). It would be great to define a > configuration parameter that permits to provide the root cause to the client > and keep the current behaviour that does not by default. > Geoff Callender - 22/Dec/08 03:36 AM > It's useful for more than unit testing - it's essential to be able to inform > the client what's wrong with the request. I've added some examples of this to > https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GERONIMO-4576: - Assignee: Guillaume Nodet > Make persistence exceptions more visible to client > -- > > Key: GERONIMO-4576 > URL: https://issues.apache.org/jira/browse/GERONIMO-4576 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.2 > Environment: Linux, Windows >Reporter: Joe Bohn >Assignee: Guillaume Nodet >Priority: Minor > Fix For: Wish List > > Attachments: GERONIMO-4576-1.patch > > > See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the > original problem. That core problem was resolved. However, upon resolution > it was mentioned that it would be beneficial to report more specific failure > information back to the client. From GERONIMO-3907: > Ralf Baumhof - 06/May/08 06:17 AM > Today if have tested the new Geronimo release 2.1.1 (published on > 28.04.2008). The problem is now fixed. If the server gets an error on trying > a commit, this error is now thrown to the web bean. > Exception text: > javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, > presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback Root Cause: > javax.transaction.TransactionRolledbackException : Transaction was rolled > back, presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback > Unfortunately there is no proper root cause attached to the exception. So the > cause can only be seen in the server console, but can not be reported to the > user. It would be very nice if you could change this in a later release. > Thanks for your help. > Vincent MATHON - 06/Nov/08 02:03 AM > I agree that exceptions on the server side should not be thrown to the client > side since such exceptions types might not be known by the client. However, > for unit testing purpose, it is useful to attach the root cause to the > RollBackException. I have modified a few lines in > org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the > root cause in case of RollBackException and it works for my unit testing > purpose (I have not enough background on the java transaction architecture > topic to submit a patch for production). It would be great to define a > configuration parameter that permits to provide the root cause to the client > and keep the current behaviour that does not by default. > Geoff Callender - 22/Dec/08 03:36 AM > It's useful for more than unit testing - it's essential to be able to inform > the client what's wrong with the request. I've added some examples of this to > https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GERONIMO-6543) Aries/Geronimo XA transaction recovery not working for heuristically completed transactions
[
https://issues.apache.org/jira/browse/GERONIMO-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved GERONIMO-6543.
---
Resolution: Fixed
svn commit -m [GERONIMO-6543] Aries/Geronimo XA transaction recovery not
working for heuristically completed transactions
Sending
geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/RecoveryImpl.java
Transmitting file data .
Committed revision 1684215.
Aries/Geronimo XA transaction recovery not working for heuristically
completed transactions
---
Key: GERONIMO-6543
URL: https://issues.apache.org/jira/browse/GERONIMO-6543
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: transaction manager
Environment: Apache Karaf 2.3.0, JBoss Fuse 6.1-redhat-610379
Reporter: Jörn Gersdorf
Assignee: Guillaume Nodet
Attachments: GERONIMO-6543.patch
We´re facing a problem with XA transaction recovery when a resource manager
(like in our case Websphere MQ) is reporting heuristically completed
transactions.
The flow goes like that (see
{{org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(NamedXAResource)}}):
• We´re starting JBoss Fuse, data/txlog/* has been deleted before start.
• {{GenericResourceManager}} is starting recovery
• The {{NamedXAResourceFactory}} is enlisted
• Geronimo calls {{xa_recover(TM_STARTRSCAN | TMENDRSCAN)}} on the XA
Resource (Websphere MQ)
• Websphere MQ reports a XID which is to be recovered, Aries TxManager
does not know about the XID so it tries to send xa_rollback to MQ
• MQ already had the XID heuristically rolled back before, so it answers
with {{XA_HEURRB (6)}}.
• Geronimo logs the exception, but does not do anything about it
Since Geronimo does not do anything about the pending transaction, it stays
pending withing Websphere MQ, and the same error will occur upon next restart.
What´s missing here from our perspective is a call to xa_forget after
receiving a XA_HEURB.
Btw, in {{org.apache.geronimo.transaction.manager.RollbackTask.run()}}
{{XA_HEURRB}} seems to be handled correctly by sending an xa_forget.
Stack trace below.
We´re using following bundles:
{noformat}
[ 281] [Active ] [] [ ] [ 50]
mvn:org.apache.geronimo.components/geronimo-connector/3.1.1
[ 116] [Active ] [] [ ] [ 30]
mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.0.1.redhat-610379
[ 118] [Active ] [] [ ] [ 30]
mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/1.0.1.redhat-610379
[ 569] [Active ] [Created ] [ ] [ 50]
mvn:org.apache.activemq/activemq-osgi/5.9.0.redhat-610379
{noformat}
Looking at the upstream source code the problem exists there, too:
https://github.com/apache/geronimo-txmanager/blob/trunk/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/RecoveryImpl.java#L127.
{noformat}
2015-04-29 11:55:28,184 | TRACE | FelixStartLevel | WrapperNamedXAResource |
116 | Recover called on XAResource wmq-wpreconXA
flags: TMENDRSCAN TMSTARTRSCAN remaining: 25165824
2015-04-29 11:55:28,187 | TRACE | FelixStartLevel | WrapperNamedXAResource |
116 | Rollback called on XAResource wmq-wpreconXA
Xid: {JmqiXid@545310144: formatId(4765526f),
gtrid(8df91ce04c016f72672e6170616368652e61726965732e7472616e73616374696f6e),
bqual(0100308807e04c016170616368652e61726965732e7472616e73616374696f6e)}
2015-04-29 11:55:28,190 | ERROR | FelixStartLevel | Recovery | 116 | Could
not roll back
javax.transaction.xa.XAException: Methode 'xa_rollback' ist mit Fehlercode
'6' fehlgeschlagen.
at com.ibm.mq.jmqi.JmqiXAResource.rollback(JmqiXAResource.java:861)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:100)
at
org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(RecoveryImpl.java:127)
at
org.apache.geronimo.transaction.manager.RecoverTask.run(RecoverTask.java:52)
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.registerNamedXAResourceFactory(TransactionManagerImpl.java:353)
at
Proxyc5f66ef2_fefc_4587_80b8_fb531eb6b156.registerNamedXAResourceFactory(Unknown
Source)
at
org.apache.activemq.jms.pool.GenericResourceManager$Recovery.recover(GenericResourceManager.java:144)
at
org.apache.activemq.jms.pool.GenericResourceManager.recoverResource(GenericResourceManager.java:77)
[jira] [Updated] (GERONIMO-6543) Aries/Geronimo XA transaction recovery not working for heuristically completed transactions
[
https://issues.apache.org/jira/browse/GERONIMO-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated GERONIMO-6543:
--
Attachment: GERONIMO-6543.patch
Possible patch ...
Aries/Geronimo XA transaction recovery not working for heuristically
completed transactions
---
Key: GERONIMO-6543
URL: https://issues.apache.org/jira/browse/GERONIMO-6543
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: transaction manager
Environment: Apache Karaf 2.3.0, JBoss Fuse 6.1-redhat-610379
Reporter: Jörn Gersdorf
Assignee: Guillaume Nodet
Attachments: GERONIMO-6543.patch
We´re facing a problem with XA transaction recovery when a resource manager
(like in our case Websphere MQ) is reporting heuristically completed
transactions.
The flow goes like that (see
{{org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(NamedXAResource)}}):
• We´re starting JBoss Fuse, data/txlog/* has been deleted before start.
• {{GenericResourceManager}} is starting recovery
• The {{NamedXAResourceFactory}} is enlisted
• Geronimo calls {{xa_recover(TM_STARTRSCAN | TMENDRSCAN)}} on the XA
Resource (Websphere MQ)
• Websphere MQ reports a XID which is to be recovered, Aries TxManager
does not know about the XID so it tries to send xa_rollback to MQ
• MQ already had the XID heuristically rolled back before, so it answers
with {{XA_HEURRB (6)}}.
• Geronimo logs the exception, but does not do anything about it
Since Geronimo does not do anything about the pending transaction, it stays
pending withing Websphere MQ, and the same error will occur upon next restart.
What´s missing here from our perspective is a call to xa_forget after
receiving a XA_HEURB.
Btw, in {{org.apache.geronimo.transaction.manager.RollbackTask.run()}}
{{XA_HEURRB}} seems to be handled correctly by sending an xa_forget.
Stack trace below.
We´re using following bundles:
{noformat}
[ 281] [Active ] [] [ ] [ 50]
mvn:org.apache.geronimo.components/geronimo-connector/3.1.1
[ 116] [Active ] [] [ ] [ 30]
mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.0.1.redhat-610379
[ 118] [Active ] [] [ ] [ 30]
mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/1.0.1.redhat-610379
[ 569] [Active ] [Created ] [ ] [ 50]
mvn:org.apache.activemq/activemq-osgi/5.9.0.redhat-610379
{noformat}
Looking at the upstream source code the problem exists there, too:
https://github.com/apache/geronimo-txmanager/blob/trunk/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/RecoveryImpl.java#L127.
{noformat}
2015-04-29 11:55:28,184 | TRACE | FelixStartLevel | WrapperNamedXAResource |
116 | Recover called on XAResource wmq-wpreconXA
flags: TMENDRSCAN TMSTARTRSCAN remaining: 25165824
2015-04-29 11:55:28,187 | TRACE | FelixStartLevel | WrapperNamedXAResource |
116 | Rollback called on XAResource wmq-wpreconXA
Xid: {JmqiXid@545310144: formatId(4765526f),
gtrid(8df91ce04c016f72672e6170616368652e61726965732e7472616e73616374696f6e),
bqual(0100308807e04c016170616368652e61726965732e7472616e73616374696f6e)}
2015-04-29 11:55:28,190 | ERROR | FelixStartLevel | Recovery | 116 | Could
not roll back
javax.transaction.xa.XAException: Methode 'xa_rollback' ist mit Fehlercode
'6' fehlgeschlagen.
at com.ibm.mq.jmqi.JmqiXAResource.rollback(JmqiXAResource.java:861)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:100)
at
org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(RecoveryImpl.java:127)
at
org.apache.geronimo.transaction.manager.RecoverTask.run(RecoverTask.java:52)
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.registerNamedXAResourceFactory(TransactionManagerImpl.java:353)
at
Proxyc5f66ef2_fefc_4587_80b8_fb531eb6b156.registerNamedXAResourceFactory(Unknown
Source)
at
org.apache.activemq.jms.pool.GenericResourceManager$Recovery.recover(GenericResourceManager.java:144)
at
org.apache.activemq.jms.pool.GenericResourceManager.recoverResource(GenericResourceManager.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)[:1.7.0_45]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_45]
at
[jira] [Assigned] (GERONIMO-6543) Aries/Geronimo XA transaction recovery not working for heuristically completed transactions
[
https://issues.apache.org/jira/browse/GERONIMO-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned GERONIMO-6543:
-
Assignee: Guillaume Nodet
Aries/Geronimo XA transaction recovery not working for heuristically
completed transactions
---
Key: GERONIMO-6543
URL: https://issues.apache.org/jira/browse/GERONIMO-6543
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: transaction manager
Environment: Apache Karaf 2.3.0, JBoss Fuse 6.1-redhat-610379
Reporter: Jörn Gersdorf
Assignee: Guillaume Nodet
We´re facing a problem with XA transaction recovery when a resource manager
(like in our case Websphere MQ) is reporting heuristically completed
transactions.
The flow goes like that (see
{{org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(NamedXAResource)}}):
• We´re starting JBoss Fuse, data/txlog/* has been deleted before start.
• {{GenericResourceManager}} is starting recovery
• The {{NamedXAResourceFactory}} is enlisted
• Geronimo calls {{xa_recover(TM_STARTRSCAN | TMENDRSCAN)}} on the XA
Resource (Websphere MQ)
• Websphere MQ reports a XID which is to be recovered, Aries TxManager
does not know about the XID so it tries to send xa_rollback to MQ
• MQ already had the XID heuristically rolled back before, so it answers
with {{XA_HEURRB (6)}}.
• Geronimo logs the exception, but does not do anything about it
Since Geronimo does not do anything about the pending transaction, it stays
pending withing Websphere MQ, and the same error will occur upon next restart.
What´s missing here from our perspective is a call to xa_forget after
receiving a XA_HEURB.
Btw, in {{org.apache.geronimo.transaction.manager.RollbackTask.run()}}
{{XA_HEURRB}} seems to be handled correctly by sending an xa_forget.
Stack trace below.
We´re using following bundles:
{noformat}
[ 281] [Active ] [] [ ] [ 50]
mvn:org.apache.geronimo.components/geronimo-connector/3.1.1
[ 116] [Active ] [] [ ] [ 30]
mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/1.0.1.redhat-610379
[ 118] [Active ] [] [ ] [ 30]
mvn:org.apache.aries.transaction/org.apache.aries.transaction.jdbc/1.0.1.redhat-610379
[ 569] [Active ] [Created ] [ ] [ 50]
mvn:org.apache.activemq/activemq-osgi/5.9.0.redhat-610379
{noformat}
Looking at the upstream source code the problem exists there, too:
https://github.com/apache/geronimo-txmanager/blob/trunk/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/RecoveryImpl.java#L127.
{noformat}
2015-04-29 11:55:28,184 | TRACE | FelixStartLevel | WrapperNamedXAResource |
116 | Recover called on XAResource wmq-wpreconXA
flags: TMENDRSCAN TMSTARTRSCAN remaining: 25165824
2015-04-29 11:55:28,187 | TRACE | FelixStartLevel | WrapperNamedXAResource |
116 | Rollback called on XAResource wmq-wpreconXA
Xid: {JmqiXid@545310144: formatId(4765526f),
gtrid(8df91ce04c016f72672e6170616368652e61726965732e7472616e73616374696f6e),
bqual(0100308807e04c016170616368652e61726965732e7472616e73616374696f6e)}
2015-04-29 11:55:28,190 | ERROR | FelixStartLevel | Recovery | 116 | Could
not roll back
javax.transaction.xa.XAException: Methode 'xa_rollback' ist mit Fehlercode
'6' fehlgeschlagen.
at com.ibm.mq.jmqi.JmqiXAResource.rollback(JmqiXAResource.java:861)
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.rollback(WrapperNamedXAResource.java:100)
at
org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceManager(RecoveryImpl.java:127)
at
org.apache.geronimo.transaction.manager.RecoverTask.run(RecoverTask.java:52)
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.registerNamedXAResourceFactory(TransactionManagerImpl.java:353)
at
Proxyc5f66ef2_fefc_4587_80b8_fb531eb6b156.registerNamedXAResourceFactory(Unknown
Source)
at
org.apache.activemq.jms.pool.GenericResourceManager$Recovery.recover(GenericResourceManager.java:144)
at
org.apache.activemq.jms.pool.GenericResourceManager.recoverResource(GenericResourceManager.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)[:1.7.0_45]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_45]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_45]
at
[jira] [Updated] (GERONIMO-6541) NPE during XAResource recovery with invalid Xids
[ https://issues.apache.org/jira/browse/GERONIMO-6541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GERONIMO-6541: -- Summary: NPE during XAResource recovery with invalid Xids (was: NPE during XAResource recovery) NPE during XAResource recovery with invalid Xids Key: GERONIMO-6541 URL: https://issues.apache.org/jira/browse/GERONIMO-6541 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Reporter: Guillaume Nodet Assignee: Guillaume Nodet In rare cases, the Oracle database may return Xid with null global transaction id. While those are clearly invalid, it can cause NPE in the transaction manager during the recovery phase, causing the application to not restart properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GERONIMO-6541) NPE during XAResource recovery with invalid Xids
[ https://issues.apache.org/jira/browse/GERONIMO-6541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GERONIMO-6541. --- Resolution: Fixed http://svn.apache.org/viewvc?view=revisionrevision=1673231 NPE during XAResource recovery with invalid Xids Key: GERONIMO-6541 URL: https://issues.apache.org/jira/browse/GERONIMO-6541 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Reporter: Guillaume Nodet Assignee: Guillaume Nodet In rare cases, the Oracle database may return Xid with null global transaction id. While those are clearly invalid, it can cause NPE in the transaction manager during the recovery phase, causing the application to not restart properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GERONIMO-6541) NPE during XAResource recovery
Guillaume Nodet created GERONIMO-6541: - Summary: NPE during XAResource recovery Key: GERONIMO-6541 URL: https://issues.apache.org/jira/browse/GERONIMO-6541 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Reporter: Guillaume Nodet Assignee: Guillaume Nodet In rare cases, the Oracle database may return Xid with null global transaction id. While those are clearly invalid, it can cause NPE in the transaction manager during the recovery phase, causing the application to not restart properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GERONIMO-6532) Oracle does not support xa_end(TMFAIL)
Guillaume Nodet created GERONIMO-6532: - Summary: Oracle does not support xa_end(TMFAIL) Key: GERONIMO-6532 URL: https://issues.apache.org/jira/browse/GERONIMO-6532 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Reporter: Guillaume Nodet See http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_xa.htm#CHDEHGCJ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (XBEAN-266) xbean-reflect embeds asm5 even in not shaded version
[ https://issues.apache.org/jira/browse/XBEAN-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003342#comment-14003342 ] Guillaume Nodet commented on XBEAN-266: --- I can't deploy the jars on OSGi with your patch, as xbean-reflect is missing the org.apache.xbean.asm5.original.commons package. xbean-reflect embeds asm5 even in not shaded version Key: XBEAN-266 URL: https://issues.apache.org/jira/browse/XBEAN-266 Project: XBean Issue Type: Bug Affects Versions: 3.17 Reporter: Romain Manni-Bucau Attachments: XBEAN-reflect.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (XBEAN-266) xbean-reflect embeds asm5 even in not shaded version
[ https://issues.apache.org/jira/browse/XBEAN-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003342#comment-14003342 ] Guillaume Nodet edited comment on XBEAN-266 at 5/20/14 2:17 PM: I can't deploy the jars on OSGi with your patch, as xbean-reflect is missing the org.apache.xbean.asm5.original.commons package. Though I'm not sure it comes from your patch. was (Author: gnt): I can't deploy the jars on OSGi with your patch, as xbean-reflect is missing the org.apache.xbean.asm5.original.commons package. xbean-reflect embeds asm5 even in not shaded version Key: XBEAN-266 URL: https://issues.apache.org/jira/browse/XBEAN-266 Project: XBean Issue Type: Bug Affects Versions: 3.17 Reporter: Romain Manni-Bucau Attachments: XBEAN-reflect.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (XBEAN-266) xbean-reflect embeds asm5 even in not shaded version
[ https://issues.apache.org/jira/browse/XBEAN-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated XBEAN-266: -- Fix Version/s: 3.18 xbean-reflect embeds asm5 even in not shaded version Key: XBEAN-266 URL: https://issues.apache.org/jira/browse/XBEAN-266 Project: XBean Issue Type: Bug Affects Versions: 3.17 Reporter: Romain Manni-Bucau Fix For: 3.18 Attachments: XBEAN-reflect-osgi-01.patch, XBEAN-reflect.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (XBEAN-268) Fix osgi headers and missing package
[ https://issues.apache.org/jira/browse/XBEAN-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-268. - Resolution: Fixed Sendingpom.xml Sendingxbean-asm5-shaded/pom.xml Sendingxbean-finder/pom.xml Sendingxbean-finder-shaded/pom.xml Sendingxbean-reflect/pom.xml Transmitting file data . Committed revision 1596365. Fix osgi headers and missing package Key: XBEAN-268 URL: https://issues.apache.org/jira/browse/XBEAN-268 Project: XBean Issue Type: Bug Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.18 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (XBEAN-244) Upgrade xbean-finder to use ASM 4
[ https://issues.apache.org/jira/browse/XBEAN-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated XBEAN-244: -- Fix Version/s: 3.14 Upgrade xbean-finder to use ASM 4 - Key: XBEAN-244 URL: https://issues.apache.org/jira/browse/XBEAN-244 Project: XBean Issue Type: Improvement Components: finder Affects Versions: 3.13 Reporter: Matt Benson Priority: Minor Fix For: 3.14 Attachments: XBEAN-244.patch.txt The provided patch will also address the shaded artifacts and will shade ASM 4 into a different package structure and maven artifact than was done for ASM 3 to avoid breaking any downstream consumers (however ill-advised) of the shaded ASM 3 artifacts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (XBEAN-265) Regression: cannot find subclasses/implementations of external classes after forcing ClassInfo.get()
[
https://issues.apache.org/jira/browse/XBEAN-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated XBEAN-265:
--
Fix Version/s: 3.18
Regression: cannot find subclasses/implementations of external classes
after forcing ClassInfo.get()
--
Key: XBEAN-265
URL: https://issues.apache.org/jira/browse/XBEAN-265
Project: XBean
Issue Type: Bug
Components: finder
Affects Versions: 3.15, 3.16, 3.17
Reporter: Matt Benson
Labels: patch, test
Fix For: 3.18
By external I mean available in the archive's classloader but not its
iterated entries. In general it is rather difficult to test the class-based
portion of {{AnnotationFinder}}'s implementation, but it can be done by
calling {{#findAnnotatedClasses()}} before {{#link()}}. Then it is possible
to demonstrate the problem.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (XBEAN-267) Improve thread-safety of AsynchronousInheritanceAnnotationFinder using double-checked locking
[
https://issues.apache.org/jira/browse/XBEAN-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated XBEAN-267:
--
Fix Version/s: 3.18
Improve thread-safety of AsynchronousInheritanceAnnotationFinder using
double-checked locking
-
Key: XBEAN-267
URL: https://issues.apache.org/jira/browse/XBEAN-267
Project: XBean
Issue Type: Improvement
Components: finder
Affects Versions: 3.17
Reporter: Matt Benson
Labels: patch
Fix For: 3.18
where the {{CountDownLatch}} instances are created, use double-checked
locking idiom to ensure only one instance created.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (XBEAN-264) rat plugin should ignore .git files
[ https://issues.apache.org/jira/browse/XBEAN-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-264. - rat plugin should ignore .git files --- Key: XBEAN-264 URL: https://issues.apache.org/jira/browse/XBEAN-264 Project: XBean Issue Type: Bug Reporter: Matt Benson Labels: patch Fix For: 3.18 Can't build a checkout of the git mirror. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (XBEAN-266) xbean-reflect embeds asm5 even in not shaded version
[ https://issues.apache.org/jira/browse/XBEAN-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-266. - Resolution: Fixed xbean-reflect embeds asm5 even in not shaded version Key: XBEAN-266 URL: https://issues.apache.org/jira/browse/XBEAN-266 Project: XBean Issue Type: Bug Affects Versions: 3.17 Reporter: Romain Manni-Bucau Fix For: 3.18 Attachments: XBEAN-reflect-osgi-01.patch, XBEAN-reflect.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (XBEAN-263) creating ClassInfo for an annotated Class object throws NPE
[
https://issues.apache.org/jira/browse/XBEAN-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed XBEAN-263.
-
creating ClassInfo for an annotated Class object throws NPE
---
Key: XBEAN-263
URL: https://issues.apache.org/jira/browse/XBEAN-263
Project: XBean
Issue Type: Bug
Components: finder
Affects Versions: 3.17
Reporter: Matt Benson
Labels: patch, test
Fix For: 3.18
The class-based, as opposed to signature-based. portion of
{{AnnotationFinder}} is rather difficult to test, but I have been able to
create a failing test case. The issue is that
{{Annotatable(AnnotatedElement)}} calls the {{AnnotationInfo}} constructor
using the classname of the {{annotationType}} which, in turn, calls ASM's
{{Type.getType(String)}}; however, this method wants a type descriptor (the
method's Javadoc actually says a field or method type descriptor). Calling
{{AnnotationInfo(Class)}} instead solves the problem.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (GERONIMO-6509) XMLStreamException not calling super(th) in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13833867#comment-13833867 ] Guillaume Nodet commented on GERONIMO-6509: --- Sendingsrc/main/java/javax/xml/stream/FactoryConfigurationError.java Transmitting file data . Committed revision 1546068. XMLStreamException not calling super(th) in constructors -- Key: GERONIMO-6509 URL: https://issues.apache.org/jira/browse/GERONIMO-6509 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Reporter: Daniel Kulp Assignee: Guillaume Nodet The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or super(msg, th) for the constructors that take a throwable. There are two problems this causes: 1) The cause is never set so the exception.getCause() always returns null and potentially important information in the cause is discarded. 2) For the super(th) one, no message is set at all.Thus, all information that could be useful is lost unless I specifically cast the exception to an XMLStreamException and call the getNestedException(). Any generic exception handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (GERONIMO-6509) XMLStreamException not calling super(th) in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GERONIMO-6509: - Assignee: Guillaume Nodet XMLStreamException not calling super(th) in constructors -- Key: GERONIMO-6509 URL: https://issues.apache.org/jira/browse/GERONIMO-6509 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Reporter: Daniel Kulp Assignee: Guillaume Nodet The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or super(msg, th) for the constructors that take a throwable. There are two problems this causes: 1) The cause is never set so the exception.getCause() always returns null and potentially important information in the cause is discarded. 2) For the super(th) one, no message is set at all.Thus, all information that could be useful is lost unless I specifically cast the exception to an XMLStreamException and call the getNestedException(). Any generic exception handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (GERONIMO-6509) XMLStreamException not calling super(th) in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13833866#comment-13833866 ] Guillaume Nodet commented on GERONIMO-6509: --- Sendingsrc/main/java/javax/xml/stream/XMLStreamException.java Transmitting file data . Committed revision 1546066. XMLStreamException not calling super(th) in constructors -- Key: GERONIMO-6509 URL: https://issues.apache.org/jira/browse/GERONIMO-6509 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Reporter: Daniel Kulp Assignee: Guillaume Nodet The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or super(msg, th) for the constructors that take a throwable. There are two problems this causes: 1) The cause is never set so the exception.getCause() always returns null and potentially important information in the cause is discarded. 2) For the super(th) one, no message is set at all.Thus, all information that could be useful is lost unless I specifically cast the exception to an XMLStreamException and call the getNestedException(). Any generic exception handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (GERONIMO-6509) XMLStreamException not calling super(th) in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GERONIMO-6509: - Assignee: Guillaume Nodet XMLStreamException not calling super(th) in constructors -- Key: GERONIMO-6509 URL: https://issues.apache.org/jira/browse/GERONIMO-6509 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Reporter: Daniel Kulp Assignee: Guillaume Nodet The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or super(msg, th) for the constructors that take a throwable. There are two problems this causes: 1) The cause is never set so the exception.getCause() always returns null and potentially important information in the cause is discarded. 2) For the super(th) one, no message is set at all.Thus, all information that could be useful is lost unless I specifically cast the exception to an XMLStreamException and call the getNestedException(). Any generic exception handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (GERONIMO-6509) XMLStreamException not calling super(th) in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GERONIMO-6509. --- Resolution: Fixed XMLStreamException not calling super(th) in constructors -- Key: GERONIMO-6509 URL: https://issues.apache.org/jira/browse/GERONIMO-6509 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Reporter: Daniel Kulp Assignee: Guillaume Nodet The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or super(msg, th) for the constructors that take a throwable. There are two problems this causes: 1) The cause is never set so the exception.getCause() always returns null and potentially important information in the cause is discarded. 2) For the super(th) one, no message is set at all.Thus, all information that could be useful is lost unless I specifically cast the exception to an XMLStreamException and call the getNestedException(). Any generic exception handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (XBEAN-258) xbean-asm4-shaded should export org.apache.xbean.asm4.shade.commons package
[ https://issues.apache.org/jira/browse/XBEAN-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned XBEAN-258: - Assignee: Guillaume Nodet xbean-asm4-shaded should export org.apache.xbean.asm4.shade.commons package --- Key: XBEAN-258 URL: https://issues.apache.org/jira/browse/XBEAN-258 Project: XBean Issue Type: Bug Components: asm Affects Versions: 3.14 Reporter: Jean-Baptiste Onofré Assignee: Guillaume Nodet Attachments: XBEAN-258.patch The xbean-asm4-shaded bundle doesn't export the org.apache.xbean.asm4.shade.commons package. However, this package is imported by xbean-finder-shaded. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (XBEAN-258) xbean-asm4-shaded should export org.apache.xbean.asm4.shade.commons package
[ https://issues.apache.org/jira/browse/XBEAN-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-258. - Resolution: Fixed Fix Version/s: 3.16 xbean-asm4-shaded should export org.apache.xbean.asm4.shade.commons package --- Key: XBEAN-258 URL: https://issues.apache.org/jira/browse/XBEAN-258 Project: XBean Issue Type: Bug Components: asm Affects Versions: 3.14 Reporter: Jean-Baptiste Onofré Assignee: Guillaume Nodet Fix For: 3.16 Attachments: XBEAN-258.patch The xbean-asm4-shaded bundle doesn't export the org.apache.xbean.asm4.shade.commons package. However, this package is imported by xbean-finder-shaded. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (XBEAN-146) xsd for list elements should be unbounded, not max=1
[ https://issues.apache.org/jira/browse/XBEAN-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-146. - Resolution: Fixed Fix Version/s: 3.12 Assignee: Guillaume Nodet Sending xbean-blueprint/src/main/java/org/apache/xbean/blueprint/generator/XsdGenerator.java Sending xbean-spring/src/main/java/org/apache/xbean/spring/generator/XsdGenerator.java Transmitting file data .. Committed revision 1393335. xsd for list elements should be unbounded, not max=1 Key: XBEAN-146 URL: https://issues.apache.org/jira/browse/XBEAN-146 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.8, 3.7 Reporter: Karl Palsson Assignee: Guillaume Nodet Fix For: 3.12 Attachments: xbean-146.diff There's code to check whether an element is a collection type, and then the next line ignores the result. This leads to https://jax-ws-commons.dev.java.net/issues/show_bug.cgi?id=12 down the road (via the xbean-maven plugin) Patch coming... -- 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] (XBEAN-113) Set svn:eol-style=native on source files
[ https://issues.apache.org/jira/browse/XBEAN-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-113. - Resolution: Fixed Fix Version/s: 3.12 Assignee: Guillaume Nodet Transmitting file data ... Committed revision 1393346. Set svn:eol-style=native on source files Key: XBEAN-113 URL: https://issues.apache.org/jira/browse/XBEAN-113 Project: XBean Issue Type: Wish Reporter: Benjamin Bentmann Assignee: Guillaume Nodet Priority: Trivial Fix For: 3.12 Attachments: XBEAN-113.patch Proper svn props ease collaboration and contributions. See also [Configuring the Subversion client|http://www.apache.org/dev/version-control.html#https-svn-config]. -- 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] (XBEAN-121) Constructor injection doesn't work with constructor argument of type array
[
https://issues.apache.org/jira/browse/XBEAN-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed XBEAN-121.
-
Resolution: Fixed
Fix Version/s: 3.12
Assignee: Guillaume Nodet
Adding
src/test/java/org/apache/xbean/spring/context/Recipe2UsingXBeanTest.java
Adding src/test/java/org/apache/xbean/spring/example/RecipeService2.java
Adding
src/test/resources/org/apache/xbean/spring/context/recipe2-xbean.xml
Transmitting file data ...
Committed revision 1393363.
Constructor injection doesn't work with constructor argument of type array
--
Key: XBEAN-121
URL: https://issues.apache.org/jira/browse/XBEAN-121
Project: XBean
Issue Type: Bug
Affects Versions: 3.5
Reporter: Piotr Bzdyl
Assignee: Guillaume Nodet
Fix For: 3.12
A sample class:
package test;
public class SomeBean {
private final String[] arguments;
public SomeBean(String[] arguments) {
this.arguments = arguments;
}
}
And mapping configuration:
something = test.SomeBean
test.SomeBean(java.lang.String[]).parameterNames = arguments
Using:
myNs:something arguments=#.../
causes:
Caused by: org.springframework.beans.BeanInstantiationException: Could not
instantiate bean class [test.SomeBean]: No default constructor found; nested
exception is java.lang.NoSuchMethodException: test.SomeBean.init()
--
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] (XBEAN-200) be able to use annotationfinder for non runtime retention annotation
[ https://issues.apache.org/jira/browse/XBEAN-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-200. - Resolution: Fixed Fix Version/s: 3.12 Assignee: Guillaume Nodet Sendingsrc/main/java/org/apache/xbean/finder/AnnotationFinder.java Adding src/test/java/org/acme/ClassAnnotatedClass.java Adding src/test/java/org/acme/bar/ClassAnnotation.java Adding src/test/java/org/apache/xbean/finder/ClassAnnotationFinderTest.java Transmitting file data Committed revision 1393366. be able to use annotationfinder for non runtime retention annotation Key: XBEAN-200 URL: https://issues.apache.org/jira/browse/XBEAN-200 Project: XBean Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: Guillaume Nodet Fix For: 3.12 Attachments: XBEAN-200.patch -- 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] (XBEAN-184) Use wiring API for wired bundle calculation
[ https://issues.apache.org/jira/browse/XBEAN-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated XBEAN-184: -- Fix Version/s: (was: 3.12) 3.13 Use wiring API for wired bundle calculation --- Key: XBEAN-184 URL: https://issues.apache.org/jira/browse/XBEAN-184 Project: XBean Issue Type: New Feature Components: bundleutils Affects Versions: 3.8 Reporter: Ivan Assignee: Ivan Fix For: 3.13 With newly added wiring API, it should improve the wired bundles calculation, while package admin is used in the past, and we could fail over to package admin if the runtime does not support the new API. -- 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] (XBEAN-189) Add a new method in BundleUtils to determine which OSGi runtime is used now
[ https://issues.apache.org/jira/browse/XBEAN-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated XBEAN-189: -- Fix Version/s: (was: 3.12) 3.13 Add a new method in BundleUtils to determine which OSGi runtime is used now --- Key: XBEAN-189 URL: https://issues.apache.org/jira/browse/XBEAN-189 Project: XBean Issue Type: New Feature Components: bundleutils Affects Versions: 3.8 Reporter: Ivan Assignee: Ivan Fix For: 3.13 Sometimes, we might use some OSGi runtime dependent function in the codes, and it will be better to print some warning information if the runtime is not fulfilled. One possible solution is to get the runtime by bundle class name, e.g. eclipse means equonix etc. If there are other better choice, please comment on the jira. -- 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] [Created] (XBEAN-228) Support aries blueprint 1.0
Guillaume Nodet created XBEAN-228: - Summary: Support aries blueprint 1.0 Key: XBEAN-228 URL: https://issues.apache.org/jira/browse/XBEAN-228 Project: XBean Issue Type: Improvement Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.12 -- 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] [Created] (XBEAN-229) Make jexl an optional import on xbean-blueprint
Guillaume Nodet created XBEAN-229: - Summary: Make jexl an optional import on xbean-blueprint Key: XBEAN-229 URL: https://issues.apache.org/jira/browse/XBEAN-229 Project: XBean Issue Type: Improvement Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.12 -- 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] (XBEAN-229) Make jexl an optional import on xbean-blueprint
[ https://issues.apache.org/jira/browse/XBEAN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-229. - Resolution: Fixed Sendingpom.xml Transmitting file data . Committed revision 1393099. Make jexl an optional import on xbean-blueprint --- Key: XBEAN-229 URL: https://issues.apache.org/jira/browse/XBEAN-229 Project: XBean Issue Type: Improvement Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.12 -- 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] (XBEAN-228) Support aries blueprint 1.0
[ https://issues.apache.org/jira/browse/XBEAN-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-228. - Resolution: Fixed Sendingpom.xml Sending src/main/java/org/apache/xbean/blueprint/cm/CmNamespaceHandler.java Sending src/test/java/org/apache/xbean/blueprint/context/BlueprintTestSupport.java Transmitting file data ... Committed revision 1393098. Support aries blueprint 1.0 --- Key: XBEAN-228 URL: https://issues.apache.org/jira/browse/XBEAN-228 Project: XBean Issue Type: Improvement Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.12 -- 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] [Assigned] (XBEAN-227) Add support for Spring 3.1 bean profiles
[ https://issues.apache.org/jira/browse/XBEAN-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned XBEAN-227: - Assignee: Guillaume Nodet Add support for Spring 3.1 bean profiles Key: XBEAN-227 URL: https://issues.apache.org/jira/browse/XBEAN-227 Project: XBean Issue Type: Improvement Components: spring Affects Versions: 3.11 Reporter: Claus Ibsen Assignee: Guillaume Nodet Priority: Critical Attachments: XBEAN-227.patch When using the new feature of Spring 3.1 which is profiles, then the XBeanNamespaceHandler does not support parsing namespaces nested in beans which has a profile associated. See AMQ-3723. -- 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] [Assigned] (GERONIMO-6373) Expose HOWL flushPartialBuffer config via HOWLLog - useful under low concurrency
[
https://issues.apache.org/jira/browse/GERONIMO-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned GERONIMO-6373:
-
Assignee: Guillaume Nodet (was: David Jencks)
Expose HOWL flushPartialBuffer config via HOWLLog - useful under low
concurrency
Key: GERONIMO-6373
URL: https://issues.apache.org/jira/browse/GERONIMO-6373
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: transaction manager
Affects Versions: 2.2.1
Reporter: Gary Tully
Assignee: Guillaume Nodet
Attachments: GERONIMO-6372.patch
HOWL XALogger supports flushPartialBuffers which is not configurable via
Geronimo HOWLLog. It is useful in the case of low concurrency.
It would be great to have this exposed in the HOWLLog constructor so that it
be be configured.
{code} /**
* Indicates whether LogBufferManager should flush buffers
* before they are full.
*
* pNormally, buffers are flushed to disk only when
* they become full. In lightly loaded situations,
* one or more threads may have to wait until the
* flushSleepTime expires before the buffer is written.
* In the worst case, a single thread is using the
* log, and every put() with sync requested will
* be delayed flushSleepTime ms before the buffer is
* written.
*
* pSetting flushPartialBuffers true will allow
* the LogBufferManager to flush buffers to disk
* any time the channel is not busy. This improves
* throughput in single threaded and lightly loaded
* environments.
*
* pBy default, this feature is disabled (false) to
* provide compatability with earlier versions of
* this library.
*/
private boolean flushPartialBuffers = false;{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-6372) RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching
[ https://issues.apache.org/jira/browse/GERONIMO-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GERONIMO-6372: - Assignee: Guillaume Nodet RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching -- Key: GERONIMO-6372 URL: https://issues.apache.org/jira/browse/GERONIMO-6372 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.2 Environment: Aries, OSGI, camel, activemq Reporter: Gary Tully Assignee: Guillaume Nodet Attachments: GERONIMO-6372.patch Given a camel route with from(activemq:a).to(activemq:b) in a Geronimo managed XA transaction. On start/restart new transactions are created in parallel with recovery of the jms components. There are two issues: * The Recovery processing can match new transactions through the XidFactory.matchXX methods and rollback new work in error. (Note: a xa_recover of activemq correctly returns *all* prepared transactions) * The XidFactoryImpl(byte[] seed) can create duplicate xids which could potentially interfere with recovering transactions and makes it impossible to determine from the logs what is going on. Xids should be globally unique and recoverable. So they need a persistent unique seed (provided through configuration) and an ever increasing id. The current time provides a simple approach to an increasing id that negates the need to persist the last used id in the transaction recovery log. (It has the downside of regressing if the XidFactory is recreated in the same millisecond, but I think this is in practice improbable outside unit tests.) If the id component is keyed of the epoch, a recovering XidFactory can match only old Xids, ones created by it in a previous incarnation. In this way it can avoid completing newly created transactions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6373) Expose HOWL flushPartialBuffer config via HOWLLog - useful under low concurrency
[
https://issues.apache.org/jira/browse/GERONIMO-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved GERONIMO-6373.
---
Resolution: Fixed
Not sure which version I should put. djencks ?
Expose HOWL flushPartialBuffer config via HOWLLog - useful under low
concurrency
Key: GERONIMO-6373
URL: https://issues.apache.org/jira/browse/GERONIMO-6373
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: transaction manager
Affects Versions: 2.2.1
Reporter: Gary Tully
Assignee: Guillaume Nodet
Attachments: GERONIMO-6372.patch
HOWL XALogger supports flushPartialBuffers which is not configurable via
Geronimo HOWLLog. It is useful in the case of low concurrency.
It would be great to have this exposed in the HOWLLog constructor so that it
be be configured.
{code} /**
* Indicates whether LogBufferManager should flush buffers
* before they are full.
*
* pNormally, buffers are flushed to disk only when
* they become full. In lightly loaded situations,
* one or more threads may have to wait until the
* flushSleepTime expires before the buffer is written.
* In the worst case, a single thread is using the
* log, and every put() with sync requested will
* be delayed flushSleepTime ms before the buffer is
* written.
*
* pSetting flushPartialBuffers true will allow
* the LogBufferManager to flush buffers to disk
* any time the channel is not busy. This improves
* throughput in single threaded and lightly loaded
* environments.
*
* pBy default, this feature is disabled (false) to
* provide compatability with earlier versions of
* this library.
*/
private boolean flushPartialBuffers = false;{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6372) RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching
[ https://issues.apache.org/jira/browse/GERONIMO-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GERONIMO-6372. --- Resolution: Fixed Not sure which version I should put. djencks ? RecoveryImpl completing in-progress transactions, XidFactoryImpl needs to be smarter with matching -- Key: GERONIMO-6372 URL: https://issues.apache.org/jira/browse/GERONIMO-6372 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.2 Environment: Aries, OSGI, camel, activemq Reporter: Gary Tully Assignee: Guillaume Nodet Attachments: GERONIMO-6372.patch Given a camel route with from(activemq:a).to(activemq:b) in a Geronimo managed XA transaction. On start/restart new transactions are created in parallel with recovery of the jms components. There are two issues: * The Recovery processing can match new transactions through the XidFactory.matchXX methods and rollback new work in error. (Note: a xa_recover of activemq correctly returns *all* prepared transactions) * The XidFactoryImpl(byte[] seed) can create duplicate xids which could potentially interfere with recovering transactions and makes it impossible to determine from the logs what is going on. Xids should be globally unique and recoverable. So they need a persistent unique seed (provided through configuration) and an ever increasing id. The current time provides a simple approach to an increasing id that negates the need to persist the last used id in the transaction recovery log. (It has the downside of regressing if the XidFactory is recreated in the same millisecond, but I think this is in practice improbable outside unit tests.) If the id component is keyed of the epoch, a recovering XidFactory can match only old Xids, ones created by it in a previous incarnation. In this way it can avoid completing newly created transactions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (XBEAN-169) ClasspathArchive for traditional java classpath finder support
[ https://issues.apache.org/jira/browse/XBEAN-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-169. - Resolution: Fixed Fix Version/s: (was: 3.12) 3.8 ClasspathArchive for traditional java classpath finder support -- Key: XBEAN-169 URL: https://issues.apache.org/jira/browse/XBEAN-169 Project: XBean Issue Type: Sub-task Reporter: David Blevins Assignee: David Blevins Fix For: 3.8 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (XBEAN-159) Find Implementations
[ https://issues.apache.org/jira/browse/XBEAN-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-159. - Resolution: Fixed Fix Version/s: (was: 3.12) 3.8 Find Implementations Key: XBEAN-159 URL: https://issues.apache.org/jira/browse/XBEAN-159 Project: XBean Issue Type: New Feature Components: finder Reporter: David Blevins Assignee: David Blevins Fix For: 3.8 It is now possible to find implementations of an interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (XBEAN-160) Find subclasses
[ https://issues.apache.org/jira/browse/XBEAN-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-160. - Resolution: Fixed Fix Version/s: (was: 3.12) 3.8 Find subclasses --- Key: XBEAN-160 URL: https://issues.apache.org/jira/browse/XBEAN-160 Project: XBean Issue Type: New Feature Components: finder Reporter: David Blevins Assignee: David Blevins Fix For: 3.8 It is now possible to find subclasses of a given class -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (XBEAN-175) List annotated class names
[ https://issues.apache.org/jira/browse/XBEAN-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-175. - Resolution: Fixed Fix Version/s: (was: 3.12) 3.8 List annotated class names -- Key: XBEAN-175 URL: https://issues.apache.org/jira/browse/XBEAN-175 Project: XBean Issue Type: Improvement Components: finder Reporter: David Blevins Assignee: David Blevins Fix For: 3.8 Specifically for CDI it is very useful to be able to just list all the class names. This is somewhat temporary as the new Archive interface is already capable of listing class names. When everyone is switched over to the new finder, we may want to rethink this method. Perhaps just expose the Archive via a getter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (XBEAN-201) JarArchive and FileArchive cache results so re-iterating is cheap
[ https://issues.apache.org/jira/browse/XBEAN-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-201. - Resolution: Fixed Fix Version/s: (was: 3.12) 3.10 JarArchive and FileArchive cache results so re-iterating is cheap - Key: XBEAN-201 URL: https://issues.apache.org/jira/browse/XBEAN-201 Project: XBean Issue Type: Improvement Components: finder Reporter: David Blevins Assignee: David Blevins Fix For: 3.10 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (XBEAN-202) AnnotationFinder.select(String... classnames) allows narrowing of finder scope
[ https://issues.apache.org/jira/browse/XBEAN-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-202. - Resolution: Fixed Fix Version/s: (was: 3.12) 3.10 AnnotationFinder.select(String... classnames) allows narrowing of finder scope -- Key: XBEAN-202 URL: https://issues.apache.org/jira/browse/XBEAN-202 Project: XBean Issue Type: New Feature Components: finder Reporter: David Blevins Assignee: David Blevins Fix For: 3.10 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (XBEAN-205) JarArchive and Archive API reworked for greater performance
[ https://issues.apache.org/jira/browse/XBEAN-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-205. - Resolution: Fixed Fix Version/s: 3.11 JarArchive and Archive API reworked for greater performance --- Key: XBEAN-205 URL: https://issues.apache.org/jira/browse/XBEAN-205 Project: XBean Issue Type: Improvement Components: finder Reporter: David Blevins Assignee: David Blevins Fix For: 3.11 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (XBEAN-206) use jarfile instead of jarinputstream when possible
[ https://issues.apache.org/jira/browse/XBEAN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-206. - Resolution: Fixed Fix Version/s: 3.11 Assignee: David Blevins use jarfile instead of jarinputstream when possible --- Key: XBEAN-206 URL: https://issues.apache.org/jira/browse/XBEAN-206 Project: XBean Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: David Blevins Fix For: 3.11 Attachments: XBEAN-206.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (XBEAN-132) Class loading issues
[ https://issues.apache.org/jira/browse/XBEAN-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned XBEAN-132: - Assignee: Guillaume Nodet Class loading issues Key: XBEAN-132 URL: https://issues.apache.org/jira/browse/XBEAN-132 Project: XBean Issue Type: Bug Components: spring Affects Versions: 3.4.3 Environment: Equinox Reporter: Łukasz Dywicki Assignee: Guillaume Nodet Fix For: 3.6 Attachments: class-loading-short.patch, class-loading.patch The XBeanNamespaceHandler use thread context class loader for resolving bean classes. My patch add ResourceLoader to process. All tests are passed. I try use XBean to create Spring IDE plugin and this patch give posibility to embed XBean inside Eclipse Equinox. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (XBEAN-132) Class loading issues
[ https://issues.apache.org/jira/browse/XBEAN-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12751332#action_12751332 ] Guillaume Nodet commented on XBEAN-132: --- Sendingpom.xml Sending xbean-spring/src/main/java/org/apache/xbean/spring/context/v2c/XBeanNamespaceHandler.java Transmitting file data .. Committed revision 811229. Class loading issues Key: XBEAN-132 URL: https://issues.apache.org/jira/browse/XBEAN-132 Project: XBean Issue Type: Bug Components: spring Affects Versions: 3.4.3 Environment: Equinox Reporter: Łukasz Dywicki Assignee: Guillaume Nodet Fix For: 3.6 Attachments: class-loading-short.patch, class-loading.patch The XBeanNamespaceHandler use thread context class loader for resolving bean classes. My patch add ResourceLoader to process. All tests are passed. I try use XBean to create Spring IDE plugin and this patch give posibility to embed XBean inside Eclipse Equinox. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (XBEAN-132) Class loading issues
[ https://issues.apache.org/jira/browse/XBEAN-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-132. - Resolution: Fixed Fix Version/s: 3.6 parserContext.getReaderContext().getResourceLoader() Class loading issues Key: XBEAN-132 URL: https://issues.apache.org/jira/browse/XBEAN-132 Project: XBean Issue Type: Bug Components: spring Affects Versions: 3.4.3 Environment: Equinox Reporter: Łukasz Dywicki Assignee: Guillaume Nodet Fix For: 3.6 Attachments: class-loading-short.patch, class-loading.patch The XBeanNamespaceHandler use thread context class loader for resolving bean classes. My patch add ResourceLoader to process. All tests are passed. I try use XBean to create Spring IDE plugin and this patch give posibility to embed XBean inside Eclipse Equinox. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4727) Setting a parameterized pojo in blueprint throws exception
[
https://issues.apache.org/jira/browse/GERONIMO-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved GERONIMO-4727.
---
Resolution: Fixed
Such constructions have been explicitely forbidden.
The reason is that there is no way to make sure if the objects in the list are
actually compatible with what the generic information provides.
The only way to get around such a problem is to register a custom converter to
convert to the generic type.
Setting a parameterized pojo in blueprint throws exception
--
Key: GERONIMO-4727
URL: https://issues.apache.org/jira/browse/GERONIMO-4727
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Reporter: Gert Vanthienen
Attachments: GERONIMO-4727.diff, GERONIMO-4727.diff
When the setter of property uses a parameterized type (e.g.
*{{setLruList(LruListPaxLoggingEvent events)}}*) and the bean being
injected is the raw type (e.g. *{{new LruList()}}*, we get: this exception:
{noformat}
org.osgi.service.blueprint.container.ComponentDefinitionException:
Unable to convert property value from
org.apache.felix.karaf.gshell.log.LruList to
org.apache.felix.karaf.gshell.log.LruListorg.ops4j.pax.logging.spi.PaxLoggingEvent
for injection
public void
org.apache.felix.karaf.gshell.log.VmLogAppender.setEvents(org.apache.felix.karaf.gshell.log.LruList)
at
org.apache.geronimo.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:604)
at
org.apache.geronimo.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:571)
at
org.apache.geronimo.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:552)
at
org.apache.geronimo.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:501)
at
org.apache.geronimo.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:62)
at
org.apache.geronimo.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:60)
at
org.apache.geronimo.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:62)
...
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4591) Email attachments name can not be retrieved
[ https://issues.apache.org/jira/browse/GERONIMO-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GERONIMO-4591. --- Resolution: Fixed Assignee: Guillaume Nodet Sending geronimo-javamail_1.4_spec/src/main/java/javax/mail/internet/MimeMessage.java Sending geronimo-javamail_1.4_spec/src/main/java/javax/mail/internet/MimePartDataSource.java Sending geronimo-javamail_1.4_spec/src/test/java/javax/mail/internet/MimeTest.java Transmitting file data ... Committed revision 756013. Email attachments name can not be retrieved --- Key: GERONIMO-4591 URL: https://issues.apache.org/jira/browse/GERONIMO-4591 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4594) The javamail provider should have a way to decode attachment names
The javamail provider should have a way to decode attachment names
--
Key: GERONIMO-4594
URL: https://issues.apache.org/jira/browse/GERONIMO-4594
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Guillaume Nodet
Something has been written in the api, but not for the provider.
The IMAPMimeBodyPart code follows:
{code}
public String getFileName() throws MessagingException {
String filename = bodyStructure.disposition.getParameter(filename);
if (filename == null) {
filename = bodyStructure.mimeType.getParameter(name);
}
return filename;
}
{code}
I think it should be more something like:
{code}
public String getFileName() throws MessagingException {
String filename = bodyStructure.disposition.getParameter(filename);
if (filename == null) {
filename = bodyStructure.mimeType.getParameter(name);
}
if (filename != null
SessionUtil.getBooleanProperty(MIME_DECODEFILENAME, false)) {
try {
filename = MimeUtility.decodeText(filename);
} catch (UnsupportedEncodingException e) {
throw new MessagingException(Unable to decode filename, e);
}
}
return filename;
}
{code}
With the MIME_DECODEFILENAME being the same property as in the
javax.mail.internet.MimeBodyPart from the specs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4591) Email attachments name can not be retrieved
Email attachments name can not be retrieved --- Key: GERONIMO-4591 URL: https://issues.apache.org/jira/browse/GERONIMO-4591 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: specs Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4591) Email attachments name can not be retrieved
[
https://issues.apache.org/jira/browse/GERONIMO-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682701#action_12682701
]
Guillaume Nodet commented on GERONIMO-4591:
---
The following patch should work, but I'm waiting for a confirmation that it
actually works before committing it.
{code}
Index: src/main/java/javax/mail/internet/MimePartDataSource.java
===
--- src/main/java/javax/mail/internet/MimePartDataSource.java (revision
755277)
+++ src/main/java/javax/mail/internet/MimePartDataSource.java (working copy)
@@ -111,6 +111,13 @@
}
public String getName() {
+try {
+if (part instanceof MimeBodyPart) {
+return ((MimeBodyPart) part).getFileName();
+}
+} catch (MessagingException mex) {
+// ignore it
+}
return ;
}
Index: src/main/java/javax/mail/internet/MimeBodyPart.java
===
--- src/main/java/javax/mail/internet/MimeBodyPart.java (revision 755277)
+++ src/main/java/javax/mail/internet/MimeBodyPart.java (working copy)
@@ -296,7 +296,7 @@
public String getFileName() throws MessagingException {
// see if there is a disposition. If there is, parse off the filename
parameter.
-String disposition = getSingleHeader(Content-Disposition);
+String disposition = getDisposition();
String filename = null;
if (disposition != null) {
@@ -306,7 +306,7 @@
// if there's no filename on the disposition, there might be a name
parameter on a
// Content-Type header.
if (filename == null) {
-String type = getSingleHeader(Content-Type);
+String type = getContentType();
if (type != null) {
try {
filename = new ContentType(type).getParameter(name);
@@ -350,7 +350,7 @@
contentDisposition.setParameter(filename, name);
// serialize this back out and reset.
-setHeader(Content-Disposition, contentDisposition.toString());
+setDisposition(contentDisposition.toString());
// The Sun implementation appears to update the Content-type name
parameter too, based on
// another system property
{code}
Email attachments name can not be retrieved
---
Key: GERONIMO-4591
URL: https://issues.apache.org/jira/browse/GERONIMO-4591
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: specs
Reporter: Guillaume Nodet
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4584) Opening an IMAP folder with *logs* of emails is very expensive in terms of memory and cpu
Opening an IMAP folder with *logs* of emails is very expensive in terms of
memory and cpu
-
Key: GERONIMO-4584
URL: https://issues.apache.org/jira/browse/GERONIMO-4584
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: mail
Reporter: Guillaume Nodet
Priority: Minor
{code}
// this is a real pain, but because we need to track updates
// to message sequence numbers while the folder is open, the
// messages list needs to be populated with Message objects
// to keep track of things. The IMAPMessage objects will not
// retrieve information from the server until required, so
they're
// relatively lightweight at this point.
populateMessageCache();
{code}
{code}
/**
* Populate the message cache with dummy messages, ensuring we're filled
* up to the server-reported number of messages.
*
* @exception MessagingException
*/
protected void populateMessageCache() {
// spin through the server-reported number of messages and add a dummy
one to
// the cache. The message number is assigned from the id counter, the
// sequence number is the cache position + 1.
for (int i = messages.size(); i maxSequenceNumber; i++) {
messages.add(new IMAPMessage(this, ((IMAPStore)store),
nextMessageID++, i+1));
}
}
{code}
The above code comes from
http://svn.apache.org/repos/asf/geronimo/javamail/trunk/geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/main/java/org/apache/geronimo/javamail/store/imap/IMAPFolder.java.
When trying to open my gmail account using IMAP, this takes a long time and an
enormous amount of memory (500 Mb) just to open the folder.
It might be a good idea to revisit this code if possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4585) Disposition is incorrectly parsed on multiparts imap messages
Disposition is incorrectly parsed on multiparts imap messages - Key: GERONIMO-4585 URL: https://issues.apache.org/jira/browse/GERONIMO-4585 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: mail Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4585) Disposition is incorrectly parsed on multiparts imap messages
[ https://issues.apache.org/jira/browse/GERONIMO-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GERONIMO-4585: - Assignee: Guillaume Nodet Disposition is incorrectly parsed on multiparts imap messages - Key: GERONIMO-4585 URL: https://issues.apache.org/jira/browse/GERONIMO-4585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4585) Disposition is incorrectly parsed on multiparts imap messages
[ https://issues.apache.org/jira/browse/GERONIMO-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GERONIMO-4585: -- Attachment: GERONIMO-4585.patch This patch seems to fix the problem and passes the tests. I'd like a second look however before committing the patch. Disposition is incorrectly parsed on multiparts imap messages - Key: GERONIMO-4585 URL: https://issues.apache.org/jira/browse/GERONIMO-4585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: GERONIMO-4585.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4585) Disposition is incorrectly parsed on multiparts imap messages
[ https://issues.apache.org/jira/browse/GERONIMO-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed GERONIMO-4585. - Resolution: Fixed Sending geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/main/java/org/apache/geronimo/javamail/store/imap/connection/IMAPBodyStructure.java Sending geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/main/java/org/apache/geronimo/javamail/store/imap/connection/IMAPResponseTokenizer.java Sending geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/main/java/org/apache/geronimo/javamail/store/imap/connection/IMAPStatusResponse.java Adding geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/test/java/org/apache/geronimo/javamail/store/imap/connection Adding geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/test/java/org/apache/geronimo/javamail/store/imap/connection/IMAPBodyStructureTest.java Adding geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/test/resources/imap Adding geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/test/resources/imap/multipart.bodystructure Transmitting file data . Committed revision 753004. Not sure which version of geronimo this fix will be included in, so feel free to change the fix version as required. Disposition is incorrectly parsed on multiparts imap messages - Key: GERONIMO-4585 URL: https://issues.apache.org/jira/browse/GERONIMO-4585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: GERONIMO-4585.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-160) Aliases commands are executed with the wrong IO when used in piped commands
Aliases commands are executed with the wrong IO when used in piped commands --- Key: GSHELL-160 URL: https://issues.apache.org/jira/browse/GSHELL-160 Project: GShell Issue Type: Bug Security Level: public (Regular issues) Reporter: Guillaume Nodet Assignee: Jason Dillon Fix For: 1.0-alpha-3 See https://issues.apache.org/activemq/browse/SMX4KNL-205 and related fix -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-127) Support loading optional properties file for custom persistent configuration customization
[ https://issues.apache.org/jira/browse/GSHELL-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GSHELL-127: --- Fix Version/s: (was: 1.0-alpha-2) 1.0-alpha-3 Support loading optional properties file for custom persistent configuration customization -- Key: GSHELL-127 URL: https://issues.apache.org/jira/browse/GSHELL-127 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Bootstrap Reporter: Jason Dillon Assignee: Jason Dillon Priority: Critical Fix For: 1.0-alpha-3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-161) Command completers only work from the root.
Command completers only work from the root. - Key: GSHELL-161 URL: https://issues.apache.org/jira/browse/GSHELL-161 Project: GShell Issue Type: Bug Security Level: public (Regular issues) Reporter: Guillaume Nodet Assignee: Jason Dillon Fix For: 1.0-alpha-3 When inside a subshell, the commands completers of this subshell do not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-159) NegativeArraySizeException is thrown when using just the Shell Impementation when running tests.
[ https://issues.apache.org/jira/browse/GSHELL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GSHELL-159: -- Assignee: Guillaume Nodet (was: Jason Dillon) NegativeArraySizeException is thrown when using just the Shell Impementation when running tests. Key: GSHELL-159 URL: https://issues.apache.org/jira/browse/GSHELL-159 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Wisdom Affects Versions: 1.0-alpha-2 Reporter: Edell Nolan Assignee: Guillaume Nodet Attachments: gshell-159.patch If just using the shell implementation when running tests - a real teminal may not be created and as a result the teminalWidth results in a negative value. Example: Is using the servicemix kernel gshell itests [localShell] ERROR org.apache.servicemix.kernel.gshell.core.LocalConsole - Exiti ng shell due to caught exception java.lang.NegativeArraySizeException java.lang.NegativeArraySizeException at java.lang.AbstractStringBuilder.init(AbstractStringBuilder.java:44) at java.lang.StringBuilder.init(StringBuilder.java:81) at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.repeat(ShellImpl.ja va:265) at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.run(ShellImpl.java: 242) at org.apache.servicemix.kernel.gshell.core.ShellWrapper.run(ShellWrappe r.java:81) at org.apache.servicemix.kernel.gshell.core.LocalConsole.run(LocalConsol e.java:125) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GSHELL-159) NegativeArraySizeException is thrown when using just the Shell Impementation when running tests.
[ https://issues.apache.org/jira/browse/GSHELL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GSHELL-159. Resolution: Fixed Fix Version/s: 1.0-alpha-2 Sending gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/shell/ShellImpl.java Transmitting file data . Committed revision 744143. NegativeArraySizeException is thrown when using just the Shell Impementation when running tests. Key: GSHELL-159 URL: https://issues.apache.org/jira/browse/GSHELL-159 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Wisdom Affects Versions: 1.0-alpha-2 Reporter: Edell Nolan Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 Attachments: gshell-159.patch If just using the shell implementation when running tests - a real teminal may not be created and as a result the teminalWidth results in a negative value. Example: Is using the servicemix kernel gshell itests [localShell] ERROR org.apache.servicemix.kernel.gshell.core.LocalConsole - Exiti ng shell due to caught exception java.lang.NegativeArraySizeException java.lang.NegativeArraySizeException at java.lang.AbstractStringBuilder.init(AbstractStringBuilder.java:44) at java.lang.StringBuilder.init(StringBuilder.java:81) at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.repeat(ShellImpl.ja va:265) at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.run(ShellImpl.java: 242) at org.apache.servicemix.kernel.gshell.core.ShellWrapper.run(ShellWrappe r.java:81) at org.apache.servicemix.kernel.gshell.core.LocalConsole.run(LocalConsol e.java:125) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-159) NegativeArraySizeException is thrown when using just the Shell Impementation when running tests.
[
https://issues.apache.org/jira/browse/GSHELL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673271#action_12673271
]
Guillaume Nodet commented on GSHELL-159:
Should the IO class use
{code}
public Terminal getTerminal() {
return new AutoDetectedTerminal();
}
{code}
instead of
{code}
public Terminal getTerminal() {
return Terminal.getTerminal();
}
{code}
NegativeArraySizeException is thrown when using just the Shell Impementation
when running tests.
Key: GSHELL-159
URL: https://issues.apache.org/jira/browse/GSHELL-159
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: Wisdom
Affects Versions: 1.0-alpha-2
Reporter: Edell Nolan
Assignee: Guillaume Nodet
Fix For: 1.0-alpha-2
Attachments: gshell-159.patch
If just using the shell implementation when running tests - a real teminal
may not be created
and as a result the teminalWidth results in a negative value.
Example: Is using the servicemix kernel gshell itests
[localShell] ERROR org.apache.servicemix.kernel.gshell.core.LocalConsole -
Exiti
ng shell due to caught exception java.lang.NegativeArraySizeException
java.lang.NegativeArraySizeException
at java.lang.AbstractStringBuilder.init(AbstractStringBuilder.java:44)
at java.lang.StringBuilder.init(StringBuilder.java:81)
at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.repeat(ShellImpl.ja
va:265)
at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.run(ShellImpl.java:
242)
at org.apache.servicemix.kernel.gshell.core.ShellWrapper.run(ShellWrappe
r.java:81)
at org.apache.servicemix.kernel.gshell.core.LocalConsole.run(LocalConsol
e.java:125)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GSHELL-159) NegativeArraySizeException is thrown when using just the Shell Impementation when running tests.
[ https://issues.apache.org/jira/browse/GSHELL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reopened GSHELL-159: Needs more investigation NegativeArraySizeException is thrown when using just the Shell Impementation when running tests. Key: GSHELL-159 URL: https://issues.apache.org/jira/browse/GSHELL-159 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Wisdom Affects Versions: 1.0-alpha-2 Reporter: Edell Nolan Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 Attachments: gshell-159.patch If just using the shell implementation when running tests - a real teminal may not be created and as a result the teminalWidth results in a negative value. Example: Is using the servicemix kernel gshell itests [localShell] ERROR org.apache.servicemix.kernel.gshell.core.LocalConsole - Exiti ng shell due to caught exception java.lang.NegativeArraySizeException java.lang.NegativeArraySizeException at java.lang.AbstractStringBuilder.init(AbstractStringBuilder.java:44) at java.lang.StringBuilder.init(StringBuilder.java:81) at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.repeat(ShellImpl.ja va:265) at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.run(ShellImpl.java: 242) at org.apache.servicemix.kernel.gshell.core.ShellWrapper.run(ShellWrappe r.java:81) at org.apache.servicemix.kernel.gshell.core.LocalConsole.run(LocalConsol e.java:125) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-159) NegativeArraySizeException is thrown when using just the Shell Impementation when running tests.
[ https://issues.apache.org/jira/browse/GSHELL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed GSHELL-159. -- Resolution: Won't Fix Sending gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/shell/ShellImpl.java Transmitting file data . Committed revision 744148. Revert previous commit. The problem comes from the fact that jline.terminal system property was not correctly initialized in servicemix. NegativeArraySizeException is thrown when using just the Shell Impementation when running tests. Key: GSHELL-159 URL: https://issues.apache.org/jira/browse/GSHELL-159 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Wisdom Affects Versions: 1.0-alpha-2 Reporter: Edell Nolan Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 Attachments: gshell-159.patch If just using the shell implementation when running tests - a real teminal may not be created and as a result the teminalWidth results in a negative value. Example: Is using the servicemix kernel gshell itests [localShell] ERROR org.apache.servicemix.kernel.gshell.core.LocalConsole - Exiti ng shell due to caught exception java.lang.NegativeArraySizeException java.lang.NegativeArraySizeException at java.lang.AbstractStringBuilder.init(AbstractStringBuilder.java:44) at java.lang.StringBuilder.init(StringBuilder.java:81) at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.repeat(ShellImpl.ja va:265) at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.run(ShellImpl.java: 242) at org.apache.servicemix.kernel.gshell.core.ShellWrapper.run(ShellWrappe r.java:81) at org.apache.servicemix.kernel.gshell.core.LocalConsole.run(LocalConsol e.java:125) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-157) Dynamically adding / removing commands does not work well
Dynamically adding / removing commands does not work well - Key: GSHELL-157 URL: https://issues.apache.org/jira/browse/GSHELL-157 Project: GShell Issue Type: Bug Security Level: public (Regular issues) Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 When resolving commands, the command resolver uses a virtual file system. Unfortunately, the data for virtual file systems is always cached, which means that removing a command will still make it available for resolution. The cache problem is caused by the DelegateFileObject which does not refresh the underlying file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GSHELL-157) Dynamically adding / removing commands does not work well
[ https://issues.apache.org/jira/browse/GSHELL-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GSHELL-157. Resolution: Fixed Sending gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandResolverImpl.java Sending gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/GroupDirectoryResolver.java Transmitting file data .. Committed revision 741042. Dynamically adding / removing commands does not work well - Key: GSHELL-157 URL: https://issues.apache.org/jira/browse/GSHELL-157 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 When resolving commands, the command resolver uses a virtual file system. Unfortunately, the data for virtual file systems is always cached, which means that removing a command will still make it available for resolution. The cache problem is caused by the DelegateFileObject which does not refresh the underlying file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-158) The group.name has an incorrect value at the root when using '..' from a subshell
The group.name has an incorrect value at the root when using '..' from a subshell - Key: GSHELL-158 URL: https://issues.apache.org/jira/browse/GSHELL-158 Project: GShell Issue Type: Bug Security Level: public (Regular issues) Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GSHELL-158) The group.name has an incorrect value at the root when using '..' from a subshell
[ https://issues.apache.org/jira/browse/GSHELL-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GSHELL-158. Resolution: Fixed Sending gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandResolverImpl.java Transmitting file data . Committed revision 741078. The group.name has an incorrect value at the root when using '..' from a subshell - Key: GSHELL-158 URL: https://issues.apache.org/jira/browse/GSHELL-158 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-156) Disable system bell using the jline.nobell system property
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GSHELL-156: -- Assignee: Guillaume Nodet (was: Jason Dillon) Disable system bell using the jline.nobell system property -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Guillaume Nodet Priority: Minor Fix For: 1.0-alpha-2 Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GSHELL-156) Disable system bell using the jline.nobell system property
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GSHELL-156. Resolution: Fixed Fix Version/s: 1.0-alpha-2 Sending gshell-console/src/main/java/org/apache/geronimo/gshell/console/JLineConsole.java Transmitting file data . Committed revision 740396. Disable system bell using the jline.nobell system property -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Guillaume Nodet Priority: Minor Fix For: 1.0-alpha-2 Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-156) Disable system bell using the jline.nobell system property
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GSHELL-156: --- Summary: Disable system bell using the jline.nobell system property (was: Disable system bell by default) Disable system bell using the jline.nobell system property -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-156) Disable system bell by default
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669535#action_12669535 ] Guillaume Nodet commented on GSHELL-156: Though it would not harm to have a system property to control that. We can leave the current behavior as is in gshell and switch it off in servicemix ... Disable system bell by default -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-155) When remote logging through SSH, the shell variables are not set correctly (prompt, user, etc...)
When remote logging through SSH, the shell variables are not set correctly (prompt, user, etc...) - Key: GSHELL-155 URL: https://issues.apache.org/jira/browse/GSHELL-155 Project: GShell Issue Type: Bug Security Level: public (Regular issues) Components: Commands - SSH Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GSHELL-155) When remote logging through SSH, the shell variables are not set correctly (prompt, user, etc...)
[ https://issues.apache.org/jira/browse/GSHELL-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GSHELL-155. Resolution: Fixed Sending gshell-ssh/src/main/java/org/apache/geronimo/gshell/commands/ssh/ShellFactoryImpl.java Sendinggshell-ssh/src/main/resources/META-INF/gshell/components.xml Transmitting file data .. Committed revision 731517. When remote logging through SSH, the shell variables are not set correctly (prompt, user, etc...) - Key: GSHELL-155 URL: https://issues.apache.org/jira/browse/GSHELL-155 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Commands - SSH Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-154) Create classes to represent links and aliases
Create classes to represent links and aliases - Key: GSHELL-154 URL: https://issues.apache.org/jira/browse/GSHELL-154 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Reporter: Guillaume Nodet Assignee: Jason Dillon This allows the plugin parser to be decoupled from the command registry by parsing a list of commands, links and aliases to be later registered by the command bundle itself. This is a requirement if the parser has to be somewhat decoupled from the registries, as in ServiceMix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GSHELL-154) Create interfaces to represent links and aliases
[ https://issues.apache.org/jira/browse/GSHELL-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GSHELL-154. Resolution: Fixed Fix Version/s: 1.0-alpha-2 Assignee: Guillaume Nodet (was: Jason Dillon) Adding gshell-api/src/main/java/org/apache/geronimo/gshell/command/Alias.java Adding gshell-api/src/main/java/org/apache/geronimo/gshell/command/Link.java Adding gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/command/AliasImpl.java Adding gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/command/LinkImpl.java Sending gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/config/PluginParser.java Sending gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/plugin/bundle/CommandBundle.java Transmitting file data .. Committed revision 727321. Create interfaces to represent links and aliases Key: GSHELL-154 URL: https://issues.apache.org/jira/browse/GSHELL-154 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 This allows the plugin parser to be decoupled from the command registry by parsing a list of commands, links and aliases to be later registered by the command bundle itself. This is a requirement if the parser has to be somewhat decoupled from the registries, as in ServiceMix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-154) Create interfaces to represent links and aliases
[ https://issues.apache.org/jira/browse/GSHELL-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GSHELL-154: --- Summary: Create interfaces to represent links and aliases (was: Create classes to represent links and aliases) Create interfaces to represent links and aliases Key: GSHELL-154 URL: https://issues.apache.org/jira/browse/GSHELL-154 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Reporter: Guillaume Nodet Assignee: Jason Dillon Fix For: 1.0-alpha-2 This allows the plugin parser to be decoupled from the command registry by parsing a list of commands, links and aliases to be later registered by the command bundle itself. This is a requirement if the parser has to be somewhat decoupled from the registries, as in ServiceMix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-81) Depdendency on sun.* packages
[
https://issues.apache.org/jira/browse/GSHELL-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed GSHELL-81.
-
Resolution: Won't Fix
Depdendency on sun.* packages
-
Key: GSHELL-81
URL: https://issues.apache.org/jira/browse/GSHELL-81
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: Support - Marshal
Reporter: Guillaume Nodet
Assignee: Jason Dillon
Fix For: 1.0-alpha-3
It seems that GShell is currently unable to run without the sun.* packages in
the classloader.
The reason is that it uses xstream advanced mode which make use of these
packages.
If these packages are not on the classpath, xstream will default to the pure
java reflection provider which will cause exceptions like the following:
{noformat}
Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot
construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not
have a no-args constructor
Debugging information
message : Cannot construct
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a
no-args constructor
cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message : Cannot construct
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a
no-args constructor
class : org.apache.geronimo.gshell.layout.model.Layout
required-type : org.apache.geronimo.gshell.layout.model.CommandNode
path: /layout/nodes/command
---
{noformat}
I'm not sure if this is a good idea or if we should support that pure java
mode...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (XBEAN-110) Public Maven 3.3 xbean POM has version 3.3-SNAPSHOT : breaks dependant projects
[
https://issues.apache.org/jira/browse/XBEAN-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed XBEAN-110.
-
Resolution: Fixed
I think these issues have been fixed in 3.4.x releases, as this property is not
used anymore.
So the easiest fix is to upgrade to the latest version.
Public Maven 3.3 xbean POM has version 3.3-SNAPSHOT : breaks dependant
projects
---
Key: XBEAN-110
URL: https://issues.apache.org/jira/browse/XBEAN-110
Project: XBean
Issue Type: Bug
Affects Versions: 3.3
Environment: Maven 2.0.8
Reporter: Ramon Buckland
Priority: Blocker
Original Estimate: 0.33h
Remaining Estimate: 0.33h
== Problem Brief: ==
Release version org.apache.xbean:xbean:3.3 has property/version 3.3-SNAPSHOT
which breaks servicemix 3.2.2 builds
Inside the public
www.ibiblio.org/maven2/org/apache/xbean/xbean/3.3/xbean-3.3.pom
The propertyversion is set as 3.3-SNAPSHOT when it should be 3.3
There is a large comment which says that this MUST not be a SNAPSHOT version.
The Diff of
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/xbean/xbean/3.3/xbean-3.3.pom
is
61c61
version3.3-SNAPSHOT/version
---
version3.3/version
The follow is the comment inside the POM which alludes to the known issue,
but it has obviously been missed.
properties
!--
NOTE: Project version, to be used instead of ${pom.version} since that
value magically changes when using SNAPSHOT versions.
This value *must* be kept in sync with the value of the
version
element, and it will need to be changed manually before a
release,
as the maven-release-plugin will not update this value.
--
version3.3/version
== How this was found. ==
You can see how it breaks other projects by performing the following on an
clean empty repository.
Apache ServiceMix 3.2.2 depends on XBean 3.3 when starting out a simple
project.
mvn archetype:create \
-DarchetypeGroupId=org.apache.servicemix.tooling \
-DarchetypeArtifactId=servicemix-service-engine \
-DarchetypeVersion=3.2.2\
-DgroupId=org.my.company \
-DartifactId=my-binding-component
This is tagged as a blocker as it breaks the build of new ServiceMix project
which actually causes much problems for newcomers (see some of the following
mailinglist entries).
http://markmail.org/search/?q=list%3Aservicemix-users+xbean+3.3-snapshot#query:list%3Aservicemix-users%20xbean%203.3-snapshot+page:1+mid:goxhbom5obr4gbf5+state:results
http://markmail.org/search/?q=list%3Aservicemix-users+xbean+3.3-snapshot#query:list%3Aservicemix-users%20xbean%203.3-snapshot+page:1+mid:tror6oulroxfdpa6+state:results
Maven Error
Path to dependency:
1) org.my.company:my-binding-component:jbi-component:1.0-SNAPSHOT
2) org.apache.servicemix:servicemix-core:jar:3.2.2
3) org.apache.xbean:xbean-server:jar:3.3
4) org.apache.xbean:xbean-classloader:jar:3.3-SNAPSHOT
2) org.apache.xbean:xbean-kernel:jar:3.3-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.xbean
-DartifactId=xbean-kernel -Dversion=3.3-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=org.apache.xbean
-DartifactId=xbean-kernel -Dversion=3.3-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.my.company:my-binding-component:jbi-component:1.0-SNAPSHOT
2) org.apache.servicemix:servicemix-core:jar:3.2.2
3) org.apache.xbean:xbean-server:jar:3.3
4) org.apache.xbean:xbean-kernel:jar:3.3-SNAPSHOT
Can this please be rectified.
Kind Regards
Ramon Buckland
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (XBEAN-107) Problems with nested property/ elements when they are in the spring namespace
[ https://issues.apache.org/jira/browse/XBEAN-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-107. - Fix Version/s: 3.4.3 Problems with nested property/ elements when they are in the spring namespace --- Key: XBEAN-107 URL: https://issues.apache.org/jira/browse/XBEAN-107 Project: XBean Issue Type: Bug Components: spring Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.4.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (XBEAN-107) Problems with nested property/ elements when they are in the spring namespace
Problems with nested property/ elements when they are in the spring namespace --- Key: XBEAN-107 URL: https://issues.apache.org/jira/browse/XBEAN-107 Project: XBean Issue Type: Bug Components: spring Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (XBEAN-107) Problems with nested property/ elements when they are in the spring namespace
[ https://issues.apache.org/jira/browse/XBEAN-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608340#action_12608340 ] Guillaume Nodet commented on XBEAN-107: --- See https://issues.apache.org/activemq/browse/SM-1425 Problems with nested property/ elements when they are in the spring namespace --- Key: XBEAN-107 URL: https://issues.apache.org/jira/browse/XBEAN-107 Project: XBean Issue Type: Bug Components: spring Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (XBEAN-107) Problems with nested property/ elements when they are in the spring namespace
[ https://issues.apache.org/jira/browse/XBEAN-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed XBEAN-107. - Resolution: Fixed Assignee: Guillaume Nodet Problems with nested property/ elements when they are in the spring namespace --- Key: XBEAN-107 URL: https://issues.apache.org/jira/browse/XBEAN-107 Project: XBean Issue Type: Bug Components: spring Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (XBEAN-106) Id is required for elements when NOT used as a top-level tag
[ https://issues.apache.org/jira/browse/XBEAN-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608346#action_12608346 ] Guillaume Nodet commented on XBEAN-106: --- The problem with the property named property has just been fixed in XBEAN-107 Id is required for elements when NOT used as a top-level tag Key: XBEAN-106 URL: https://issues.apache.org/jira/browse/XBEAN-106 Project: XBean Issue Type: Bug Components: spring Affects Versions: 3.4 Environment: xbean-spring-3.4.1 spring-*-2.5.4 Reporter: Tuomas Kiviaho I was using org.apache.xbean.spring.context.ClassPathXmlApplicationContext in my beanRefContext.xml and noticed weird behaviour with util:properties (and util:map) bean class=org.apache.activemq.spring.ActiveMQConnectionFactory property name=properties util:properties location=classpath:jndi.properties / /property /bean Caused by: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Configuration problem: Id is required for element 'properties' when used as a top-level tag at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68) at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85) at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:72) at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:73) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1253) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseNestedCustomElement(BeanDefinitionParserDelegate.java:1302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate.internalParseNestedCustomElement(XBeanBeanDefinitionParserDelegate.java:90) at org.apache.xbean.spring.context.v2c.XBeanBeanDefinitionParserDelegate.parsePropertySubElement(XBeanBeanDefinitionParserDelegate.java:47) When using org.springframework.context.support.ClassPathXmlApplicationContext or supplying and id this problem disappeared. * * * IRRELEVANT FYI * * * I couldn't get ActiveMQ XBean variant to accept properties at all. amq:connectionFactory property name=properties util:properties id=foobar location=classpath:jndi.properties / /property /amq:connectionFactory It created PropertyValue named 'property' along with properties which naturally failed due to missing 'property' named property. amq:connectionFactory util:properties id=foobar location=classpath:jndi.properties / /amq:connectionFactory It resolved correctly but property type coercion lead to ManagedMap instead of property file. Here I revered from using ActiveMQ XBean to format used above. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar
[ https://issues.apache.org/jira/browse/GERONIMO-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599411#action_12599411 ] Guillaume Nodet commented on GERONIMO-3962: --- Yeah, i think so. Btw, I've started writing the jaxb 2.0 spec and will also need the jaxb 2.1 spec, so currently they are in servicemix, but it makes sense to move those to geronimo along with the other ones at some point. AL2 and OSGi friendy JAX-WS 2.0 spec jar Key: GERONIMO-3962 URL: https://issues.apache.org/jira/browse/GERONIMO-3962 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: jaxws-2.0.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-114) The LoginHandler default realm should be configurable
The LoginHandler default realm should be configurable - Key: GSHELL-114 URL: https://issues.apache.org/jira/browse/GSHELL-114 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 1.0-alpha-1 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GSHELL-114) The LoginHandler default realm should be configurable
[ https://issues.apache.org/jira/browse/GSHELL-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved GSHELL-114. Resolution: Fixed Sending src/main/java/org/apache/geronimo/gshell/remote/server/handler/LoginHandler.java Transmitting file data . Committed revision 658740. The LoginHandler default realm should be configurable - Key: GSHELL-114 URL: https://issues.apache.org/jira/browse/GSHELL-114 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 1.0-alpha-1 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3960) Make the spec jars OSGi friendly
Make the spec jars OSGi friendly Key: GERONIMO-3960 URL: https://issues.apache.org/jira/browse/GERONIMO-3960 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: specs Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3960) Make the spec jars OSGi friendly
[ https://issues.apache.org/jira/browse/GERONIMO-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GERONIMO-3960: -- Attachment: stax-osgi.diff Examples of OSGi friendly spec for stax Make the spec jars OSGi friendly Key: GERONIMO-3960 URL: https://issues.apache.org/jira/browse/GERONIMO-3960 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Attachments: stax-osgi.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3960) Make the spec jars OSGi friendly
[ https://issues.apache.org/jira/browse/GERONIMO-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590053#action_12590053 ] Guillaume Nodet commented on GERONIMO-3960: --- Yeah, not sure what events are exactly sent, but looking at the figure 4.26 (section 4.3.2 of the osgi r4 core spec), it seems like a bundle that is resolved will go back to the install stated after an update or a refresh, then back to the resolved state. If this is true, then the code should handle it correctly. I guess this would need to be property checked though. Make the spec jars OSGi friendly Key: GERONIMO-3960 URL: https://issues.apache.org/jira/browse/GERONIMO-3960 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Attachments: stax-osgi.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar
AL2 and OSGi friendy JAX-WS 2.0 spec jar Key: GERONIMO-3962 URL: https://issues.apache.org/jira/browse/GERONIMO-3962 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: specs Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar
[ https://issues.apache.org/jira/browse/GERONIMO-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GERONIMO-3962: -- Attachment: jaxws-2.0.diff AL2 and OSGi friendy JAX-WS 2.0 spec jar Key: GERONIMO-3962 URL: https://issues.apache.org/jira/browse/GERONIMO-3962 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: jaxws-2.0.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar
[ https://issues.apache.org/jira/browse/GERONIMO-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590142#action_12590142 ] Guillaume Nodet commented on GERONIMO-3962: --- Agreed, I'll do that. Actually, i thought axis was using the sun jar too so i rewrote that one quickly but it does not pass the tck. I'll create a patch from the axis2 version. And I agree with the duplication, but since there are so many spec jars in geronimo already, it makes more sense to move them here imho. AL2 and OSGi friendy JAX-WS 2.0 spec jar Key: GERONIMO-3962 URL: https://issues.apache.org/jira/browse/GERONIMO-3962 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: jaxws-2.0.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
