Romain Manni-Bucau | 6 Jul 16:54 2015
Picon

xbean 4.4

Hi guys,

identified https://issues.apache.org/jira/browse/XBEAN-286 and therefore I'd like to release ti let depending projects upgrading ASAP.

Anyone having something pending? Happy to wait few days to have a "bigger" release.

PS: think we already discussed it but can't recall and find the answer: why don't we use 3 digits for xbean? like doing a 4.3.1 now.

Romain Manni-Bucau
<at> rmannibucau |  Blog | Github | LinkedIn | Tomitriber
Rory O'Donnell | 2 Jul 10:43 2015
Picon

Geronimo dependencies on JDK-Internal APIs


Hi ,

My name is Rory O'Donnell, I am the OpenJDK Quality Group Lead. 

I'm contacting you because your open source project seems to be a very popular dependency for other open source projects.
As part of the preparations for JDK 9, Oracle’s engineers have been analyzing open source projects like yours to understand usage. One area of concern involves identifying compatibility problems, such as reliance on JDK-internal APIs.

Our engineers have already prepared guidance on migrating some of the more common usage patterns of JDK-internal APIs to supported public interfaces.  The list is on the OpenJDK wiki [0].

As part of the ongoing development of JDK 9, I would like to inquire about your usage of  JDK-internal APIs and to encourage migration towards supported Java APIs if necessary.

The first step is to identify if your application(s) is leveraging internal APIs.

  Step 1: Download JDeps.
Just download a preview release of JDK8(JDeps Download). You do not need to actually test or run your application on JDK8.  JDeps(Docs) looks through JAR files and identifies which JAR files use internal APIs and then lists those APIs.   
  Step 2: To run JDeps against an application. The command looks like:
jdk8/bin/jdeps -P -jdkinternals *.jar > your-application.jdeps.txt

The output inside your-application.jdeps.txt will look like:

your.package (Filename.jar)
      -> com.sun.corba.se            JDK internal API (rt.jar)
3rd party library using Internal APIs:
If your analysis uncovers a third-party component that you rely on, you can contact the provider and let them know of the upcoming changes. You can then either work with the provider to get an updated library that won't rely on Internal APIs, or you can find an alternative provider for the capabilities that the offending library provides.

Dynamic use of Internal APIs:
JDeps can not detect dynamic use of internal APIs, for example through reflection, service loaders and similar mechanisms.

Rgds,Rory

[0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
Clebert Suconic | 30 Jun 16:08 2015
Picon

jms 2.0 spec jar

Is it possible someone make a cut of the JMS 2.0 spec jar?

We need a new release cut to fix this version:
https://issues.apache.org/jira/browse/ARTEMIS-148

vishnu (JIRA | 28 Jun 05:31 2015
Picon

[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client


    [
https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14604498#comment-14604498
] 

vishnu commented on GERONIMO-4576:
----------------------------------

i have checked the geronimo-transaction-3.1.2 and geronimo-transaction-3.1.3 jars for the patch 

GERONIMO-4576-1.patch[ 12684899 ] in TransactionImpl.class , don't see .

By the way which version has this patch.

> 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
>            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)

vishnu (JIRA | 28 Jun 04:46 2015
Picon

[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client


    [
https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14604475#comment-14604475
] 

vishnu commented on GERONIMO-4576:
----------------------------------

I am also facing below issue sometimes if ran test scenarion multiple times  and intermediate .
Caused by: javax.persistence.TransactionRequiredException: no transaction is in progress
	at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:301)
I have looked at all the transaction isolation levels and other exeption handling to roll back transaction
properly.No luck.
do you think this is also kind of issue of hiding original exception .Because i don't see any thing loosing of
transaction in the middle as everything handled correctly.

Thanks 

> 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
>            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)

vishnu (JIRA | 28 Jun 04:36 2015
Picon

[jira] [Commented] (GERONIMO-4576) Make persistence exceptions more visible to client


    [
https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14604473#comment-14604473
] 

vishnu commented on GERONIMO-4576:
----------------------------------

I am also facing similar kind of issue with tomee 1.6.1 with java 1.6 .

Any idea which verstion of tomee has this fix from geronimo.Is it possible use class file TransactionImp
directly to fix this issue in tomee library open-core 

> 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
>            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)

soleger | 23 Jun 17:12 2015
Picon

[GitHub] geronimo-xbean pull request: Update Import-Package to include Spri...

GitHub user soleger opened a pull request:

    https://github.com/apache/geronimo-xbean/pull/11

    Update Import-Package to include Spring 4

    Spring 4.X is available as OSGi bundles from Apache ServiceMix and since I believe that XBean is compatible
with Spring 4, it should be included in the OSGi Import-Package directive.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/soleger/geronimo-xbean patch-1

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/geronimo-xbean/pull/11.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #11

----
commit 9e61bd1efaa15b9d89c928f63a27fdf5dcda103f
Author: Seth Leger <seth@...>
Date:   2015-06-23T15:11:46Z

    Update Import-Package to include Spring 4

    Spring 4.X is available as OSGi bundles from Apache ServiceMix and since I believe that XBean is compatible
with Spring 4, it should be included in the OSGi Import-Package directive.

----

---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@... or file a JIRA ticket
with INFRA.
---

Guillaume Nodet | 19 Jun 16:21 2015
Picon

[RESULT] [VOTE] Release Transaction Manager 3.1.3

Closing this vote with 5 +1s.
Thx to all !

Cheers,
Guillaume Nodet

2015-06-13 8:31 GMT+02:00 Mark Struberg <struberg-LWAfsSFWpa4@public.gmane.org>:
+1

LieGrue,
strub

> Am 09.06.2015 um 09:24 schrieb Guillaume Nodet <gnodet-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org>:
>
> I've uploaded a 3.1.3 release of the transaction manager component at
>   https://repository.apache.org/content/repositories/orgapachegeronimo-1020
>
> This fixes the following issues:
>       •   GERONIMO-6543: Aries/Geronimo XA transaction recovery not working for heuristically completed transactions
>
> Please review and vote !
>
> Cheers,
> Guillaume Nodet
>


Benjamin Graf (JIRA | 18 Jun 08:23 2015
Picon

[jira] [Commented] (GERONIMO-6545) Replace TranQL


    [
https://issues.apache.org/jira/browse/GERONIMO-6545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14591331#comment-14591331
] 

Benjamin Graf commented on GERONIMO-6545:
-----------------------------------------

Well, that depends on how much should be done in the next time. :-)

IMHO first the right place should be considered. Maybe the geronimo umbrella itself
(geronimo-connector) as it is build on top?
I Think on the roadmap should be:
- Refactoring (after migration to apache?)
- JDBC 4.x (java7/java8)
- Bugfixing
- Improvements?

I think there has been done some effort on the whole stack for Aries JDBC. Maybe those improvments should be
backported to Tranql and Geronimo.

> Replace TranQL
> --------------
>
>                 Key: GERONIMO-6545
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-6545
>             Project: Geronimo
>          Issue Type: Task
>      Security Level: public(Regular issues) 
>          Components: connector
>    Affects Versions: 3.0.1
>            Reporter: Benjamin Graf
>
> TranQL is dead after codehaus shutdown and needs to be replaced.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

David Jencks (JIRA | 17 Jun 00:04 2015
Picon

[jira] [Commented] (GERONIMO-6545) Replace TranQL


    [
https://issues.apache.org/jira/browse/GERONIMO-6545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14588873#comment-14588873
] 

David Jencks commented on GERONIMO-6545:
----------------------------------------

IUC the svn history is available somewhere, I think we need to migrate the code to github.  Do you have any time
to contribute to this?

> Replace TranQL
> --------------
>
>                 Key: GERONIMO-6545
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-6545
>             Project: Geronimo
>          Issue Type: Task
>      Security Level: public(Regular issues) 
>          Components: connector
>    Affects Versions: 3.0.1
>            Reporter: Benjamin Graf
>
> TranQL is dead after codehaus shutdown and needs to be replaced.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Benjamin Graf (JIRA | 16 Jun 20:10 2015
Picon

[jira] [Created] (GERONIMO-6545) Replace TranQL

Benjamin Graf created GERONIMO-6545:
---------------------------------------

             Summary: Replace TranQL
                 Key: GERONIMO-6545
                 URL: https://issues.apache.org/jira/browse/GERONIMO-6545
             Project: Geronimo
          Issue Type: Task
      Security Level: public (Regular issues)
          Components: connector
    Affects Versions: 3.0.1
            Reporter: Benjamin Graf

TranQL is dead after codehaus shutdown and needs to be replaced.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Gmane