Johannes Weberhofer (JIRA | 1 Jun 09:42 2016
Picon

[jira] [Created] (GERONIMODEVTOOLS-814) Eclipse Neon: Project facet osgi.app has not been defined. It is used in plugin org.apache.geronimo.st.v30.core.

Johannes Weberhofer created GERONIMODEVTOOLS-814:
----------------------------------------------------

             Summary: Eclipse Neon: Project facet osgi.app has not been defined. It is used in plugin org.apache.geronimo.st.v30.core.
                 Key: GERONIMODEVTOOLS-814
                 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-814
             Project: Geronimo-Devtools
          Issue Type: Bug
          Components: eclipse-plugin
    Affects Versions: 3.0.1
         Environment: Eclipse Neon RC
            Reporter: Johannes Weberhofer

------
STATUS
------
pluginId            org.eclipse.wst.common.project.facet.core
pluginVersion       1.4.300.v201111030423
code                0
severity            4
message             Project facet osgi.app has not been defined. It is used in plugin org.apache.geronimo.st.v30.core.
fingerprint         89462466aa739f3136ea55669b94681b

Exception:org.eclipse.epp.logging.aeri.core.util.NoStackTrace: This event was logged without a
stack trace. A synthetic stack trace was hence inserted.
	 at org.eclipse.wst.common.project.facet.core.internal.FacetCorePlugin.log(FacetCorePlugin.java:68)
	 at org.eclipse.wst.common.project.facet.core.internal.FacetCorePlugin.logError(FacetCorePlugin.java:91)
	 at org.eclipse.wst.common.project.facet.core.internal.ProblemLog.reportMissingFacet(ProblemLog.java:144)
	 at org.eclipse.wst.common.project.facet.core.internal.ProblemLog.reportMissingFacet(ProblemLog.java:131)
	 at org.eclipse.wst.common.project.facet.core.runtime.internal.RuntimeManagerImpl.readProjectFacetRef(RuntimeManagerImpl.java:971)
(Continue reading)

dev | 26 May 18:38 2016
Picon

Emailing: Image 05-26-2016, 87 55 35


Your message is ready to be sent with the following file or link
attachments:

Image 05-26-2016, 87 55 35

Note: To protect against computer viruses, e-mail programs may prevent
sending or receiving certain types of file attachments.  Check your e-mail
security settings to determine how attachments are handled.
Attachment (Image 05-26-2016, 87 55 35.zip): application/zip, 4624 bytes
eduardogt | 24 May 23:36 2016

Updates to Geronimo 3.0.x

Hello, today I updated and tested successfully in my local Geronimo 3.0.1
version the aries related files:
org.apache.aries.jpa.api-0.2-incubating
org.apache.aries.jpa.blueprint.aries-0.2-incubating
org.apache.aries.jpa.container-0.2-incubating
org.apache.aries.jpa.container.context-0.2-incubating

with version 0.3 which fixes some major bugs.  The one was affecting one of
my projects was related with a problem reading a persistence.xml larger than
8.1kb.

Another change I made (I have tested it for long), was upgrading
org.apache.myfaces.core/myfaces-bundle/2.1.10 to 2.1.17

Just wanted to know if it is possible to add any of this updates to the next
release of Geronimo-3.0.x

--
View this message in context: http://apache-geronimo.328035.n3.nabble.com/Updates-to-Geronimo-3-0-x-tp3990092.html
Sent from the Development mailing list archive at Nabble.com.

Abdessamed MANSOURI | 22 May 01:21 2016
Picon

Java EE 7

Hello all, how are you? i hope you are all fine :)

I just want to know, is there a plan to make Geronimo Java EE 7 certified?

--
Thanks,

Abdessamed MANSOURI
Alan Cabrera | 17 May 06:52 2016
Gravatar

[REPORT] Apache Geronimo - May 2016

## Description: 
Apache Geronimo is an open source server runtime that integrates the best open
source projects to create Java/OSGi server runtimes that meet the needs of
enterprise developers and system administrators.

## Issues: 
- We are concerned with our current level of community activity.
- There are outstanding concerns about the inability to obtain a
  compatible JEE TCK and how that will ultimately affect the project.
- The PMC has missed quarterly reports.
- Still chasing down getting IBM’s WAS Liberty application server
  fixes to the Yoko ORB integrated.  Hoping to get the original
  engineers to perform the integration.

## Activity: 
 - No releases
 - Patch to JavaMail 1.4 to be released soon

## Health report: 
- Last quarter was a very light quarter for Apache Geronimo. 

## PMC changes: 

 - Currently 42 PMC members. 
 - No new PMC members added in the last 3 months 
 - Last PMC addition was Romain Manni-Bucau on Wed Aug 06 2014 

## Committer base changes: 

 - Currently 69 committers. 
 - No new committers added in the last 3 months 
 - Last committer addition was Hendrik Saly at Thu Oct 23 2014 

## Releases: 

 - Last release was 3.18 on Tue May 20 2014 

## Mailing list activity: 

 - Activity is low.  Community responds reasinably quickly
   to submitted patches

 - dev@...:  
    - 356 subscribers (down -1 in the last 3 months): 
    - 44 emails sent to list (23 in previous quarter) 

 - geronimo-tck@...:  
    - 43 subscribers (down -1 in the last 3 months) 

 - scm@...:  
    - 99 subscribers (down -1 in the last 3 months): 
    - 24 emails sent to list (1 in previous quarter) 

 - servicemix-tck@...:  
    - 10 subscribers (up 0 in the last 3 months) 

 - tck-commits@...:  
    - 6 subscribers (up 1 in the last 3 months) 

 - user@...:  
    - 450 subscribers (down -4 in the last 3 months): 
    - 7 emails sent to list (8 in previous quarter) 

 - xbean-dev@...:  
    - 35 subscribers (up 1 in the last 3 months): 
    - 5 emails sent to list (3 in previous quarter) 

 - xbean-scm@...:  
    - 17 subscribers (up 0 in the last 3 months): 
    - 0 emails sent to list (3 in previous quarter) 

 - xbean-user@...:  
    - 34 subscribers (up 1 in the last 3 months): 
    - 1 emails sent to list (1 in previous quarter) 

   
## JIRA activity: 

 - 1 JIRA tickets created in the last 3 months 
 - 1 JIRA tickets closed/resolved in the last 3 months 

dev | 12 May 16:05 2016
Picon

Document


Attachment (Document 2.docm): application/vnd.ms-word.document.macroenabled.12, 63 KiB
Jörn Gersdorf (JIRA | 11 May 22:57 2016
Picon

[jira] [Closed] (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 ]

Jörn Gersdorf closed GERONIMO-6543.
-----------------------------------

> 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 <at> 545310144: formatId(4765526f),
gtrid(8df91ce04c0100006f72672e6170616368652e61726965732e7472616e73616374696f6e00000000000000000000000000000000000000000000000000000000), bqual(01000000308807e04c0100006170616368652e61726965732e7472616e73616374696f6e00000000000000000000000000000000000000000000000000000000)}
> 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 java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_45]
>         at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>        at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_45]
>         at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:676)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:374)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:270)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:233)[9:org.apache.aries.blueprint.core:1.0.1.redhat-610379]
>         at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[11:org.apache.aries.util:1.0.1.redhat-610379]
>         at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[11:org.apache.aries.util:1.0.1.redhat-610379]
>         at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[11:org.apache.aries.util:1.0.1.redhat-610379]
>         at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[11:org.apache.aries.util:1.0.1.redhat-610379]
>         at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[11:org.apache.aries.util:1.0.1.redhat-610379]
>         at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
>         at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:696)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
>         at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:484)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
>         at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4650)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
>         at org.apache.felix.framework.Felix$4.run(Felix.java:2123)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
>         at org.apache.felix.framework.Felix.runInContext(Felix.java:2147)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
>         at org.apache.felix.framework.Felix.startBundle(Felix.java:2121)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
>         at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1317)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
>         at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)[org.apache.felix.framework-4.0.3.redhat-610379.jar:]
>         at java.lang.Thread.run(Thread.java:744)[:1.7.0_45]
> {noformat}
> ==============
> 2. start of fuse: note that the same transaction is again causing problems.
> {noformat}
> 2015-04-29 11:56:44,623 | TRACE | FelixStartLevel | WrapperNamedXAResource | 116  | Rollback called on
XAResource wmq-wpreconXA
> Xid: {JmqiXid <at> 67301323: formatId(4765526f),
gtrid(8df91ce04c0100006f72672e6170616368652e61726965732e7472616e73616374696f6e00000000000000000000000000000000000000000000000000000000), bqual(01000000308807e04c0100006170616368652e61726965732e7472616e73616374696f6e00000000000000000000000000000000000000000000000000000000)}
> 2015-04-29 11:56:44,626 | 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)
> {noformat}

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

Alan Cabrera | 11 May 16:15 2016

Need quarterly board report for this month

We missed last month’s report.  Would someone like to take a crack at this month’s?

Regards,
Alan

Alan Cabrera (JIRA | 1 May 00:11 2016
Picon

[jira] [Closed] (GERONIMO-6552) Javamail module not fully reads SMTP server responses


     [
https://issues.apache.org/jira/browse/GERONIMO-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alan Cabrera closed GERONIMO-6552.
----------------------------------
    Resolution: Fixed

> Javamail module not fully reads SMTP server responses
> -----------------------------------------------------
>
>                 Key: GERONIMO-6552
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-6552
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: mail
>            Reporter: Alexei Osipov
>            Assignee: Alan Cabrera
>            Priority: Minor
>         Attachments: GERONIMO_6552_Read_all_lines_after_sending_content.patch
>
>
> Method {{sendData(MimeMessage msg)}} of class {{SMTPConnection}} in module
{{geronimo-javamail_1.4_provider}} reads only first line of response after sending content.
> This causes two problems in case of *multi-line* response:
> 1) Only the first line of response is received from remote server. So the SMPT session is left in
inconsistent state.
> 2) In case of error only the first line of error message is passed to exception.
> The problem is present in geronimo-javamail_1.4_provider version 1.8.4 and in trunk.

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

Alan Cabrera | 1 May 00:09 2016

geronimo-javamail_1.4-1.9.0 release?

I’ve just committed GERONIMO-6552.  I think it’s time to do a 1.9.0 release of geronimo-javamail_1.4. 
Any objections?

Regards,
Alan

Alan Cabrera (JIRA | 30 Apr 21:33 2016
Picon

[jira] [Assigned] (GERONIMO-6552) Javamail module not fully reads SMTP server responses


     [
https://issues.apache.org/jira/browse/GERONIMO-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alan Cabrera reassigned GERONIMO-6552:
--------------------------------------

    Assignee: Alan Cabrera

> Javamail module not fully reads SMTP server responses
> -----------------------------------------------------
>
>                 Key: GERONIMO-6552
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-6552
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: mail
>            Reporter: Alexei Osipov
>            Assignee: Alan Cabrera
>            Priority: Minor
>         Attachments: GERONIMO_6552_Read_all_lines_after_sending_content.patch
>
>
> Method {{sendData(MimeMessage msg)}} of class {{SMTPConnection}} in module
{{geronimo-javamail_1.4_provider}} reads only first line of response after sending content.
> This causes two problems in case of *multi-line* response:
> 1) Only the first line of response is received from remote server. So the SMPT session is left in
inconsistent state.
> 2) In case of error only the first line of error message is passed to exception.
> The problem is present in geronimo-javamail_1.4_provider version 1.8.4 and in trunk.

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


Gmane