Re: Release Connector/Transaction components
Hi devs, any news on the availability? Thanks Jean-Louis 2011/7/7 David Jencks > I'm still not sure about the instructions, but releasing from the 2.2 > branch should be fine. I only want to review the trunk code. > > also, replying to a different message, if you run release:prepare with > -DdryRun=true, then you can't continue since there is no svn tag :-) > > thanks > david jencks > On Jul 6, 2011, at 2:24 PM, David Blevins wrote: > > > > > On Jul 5, 2011, at 11:29 AM, Jacek Laskowski wrote: > > > >> On Thu, Jun 30, 2011 at 12:26 PM, Jacek Laskowski > >> wrote: > >> > >>> It's been a while since I was more active wrt Geronimo and there's a > >>> chance to change it - I may run the release process if no one objects. > >> > >> Hi, > >> > >> No one raised your hand to object or accept my offer, so I'm taking it > on. > >> > >> As I understood it's to release > >> https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/. > > > > Doing both would be fine, but it's this one that is needed for OpenEJB > 3.2: > > > > > http://svn.apache.org/repos/asf/geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.2/ > > > > > > -David > > > >
Re: Is it time to release YOKO 1.2 for G 3.0?
+1 David has created some tasks to track these snapshot dependencies. Yoko one: https://issues.apache.org/jira/browse/GERONIMO-6063 On Tue, Jul 12, 2011 at 12:31 PM, Forrest Xia wrote: > Hi All, > > I think we come to a point to determine whether to release YOKO 1.2 for G > 3.0 release. > > Since rest of YOKO related tck failures are due to RI' problem we think, I > would think we could release YOKO 1.2 now. > > If any objection, please speak out, otherwise, I start a vote for that > soon. > > Thank you for your attention. > > Forrest -- Shawn
Re: buildbot failure in ASF Buildbot on geronimo-server-trunk
The build works for me anyone else seeing problems? thanks david jencks On Jul 11, 2011, at 8:25 PM, build...@apache.org wrote: > The Buildbot has detected a new failure on builder geronimo-server-trunk > while building ASF Buildbot. > Full details are available at: > http://ci.apache.org/builders/geronimo-server-trunk/builds/179 > > Buildbot URL: http://ci.apache.org/ > > Buildslave for this Build: hemera_ubuntu > > Build Reason: scheduler > Build Source Stamp: [branch geronimo/server/trunk] 1145439 > Blamelist: djencks,rwonly > > BUILD FAILED: failed compile > > sincerely, > -The Buildbot >
Is it time to release YOKO 1.2 for G 3.0?
Hi All, I think we come to a point to determine whether to release YOKO 1.2 for G 3.0 release. Since rest of YOKO related tck failures are due to RI' problem we think, I would think we could release YOKO 1.2 now. If any objection, please speak out, otherwise, I start a vote for that soon. Thank you for your attention. Forrest
[jira] [Created] (GERONIMO-6072) Geronimo TxManager 3.1.1-SNAPSHOT
Geronimo TxManager 3.1.1-SNAPSHOT - Key: GERONIMO-6072 URL: https://issues.apache.org/jira/browse/GERONIMO-6072 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6071) Axis 1.4_2-SNAPSHOT
Axis 1.4_2-SNAPSHOT --- Key: GERONIMO-6071 URL: https://issues.apache.org/jira/browse/GERONIMO-6071 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6070) Axis2 1.7.0_1-SNAPSHOT
Axis2 1.7.0_1-SNAPSHOT -- Key: GERONIMO-6070 URL: https://issues.apache.org/jira/browse/GERONIMO-6070 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (GERONIMO-5651) Add a own authenticator for Spnego login
[ https://issues.apache.org/jira/browse/GERONIMO-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shenghao Fang reassigned GERONIMO-5651: --- Assignee: Shenghao Fang (was: Ashish Jain) > Add a own authenticator for Spnego login > > > Key: GERONIMO-5651 > URL: https://issues.apache.org/jira/browse/GERONIMO-5651 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) >Affects Versions: 2.2.1, 3.0 >Reporter: Ashish Jain >Assignee: Shenghao Fang > > Continuation of GERONIMO-5196 for 2.2 and 3.0. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Pull Tomcat 7.0.18 to Geronimo side
They accepted the patch partly, now they use the InstanceManager to create the instance, but some other changes are not included, you might check the commit history :-) 2011/7/12 David Jencks > DId tomcat accept the change of creating AsyncListeners using the > InstanceManager? If so, then the change in geronimo's copy is all that is > needed. > > thanks! > david jencks > > On Jul 10, 2011, at 11:53 PM, Ivan wrote: > > I merged all of the changes mentioned in the thread > http://old.nabble.com/Preparing-for-a-7.0.19-tag-td32031213.html , now the > 7.0.18.0 branch from Geronimo side has the same contents with the Tomcat > trunk rev.1144976GERONIMO-5622 > Also, an extra changes from Geronimo side is also added, GERONIMO-5622. it > will be better that someone could also help to review those changes. > > If we would release this 7.0.18 branch, which version should be used ? > 7.0.18.0 or 7.0.18.1, which is mentioned in the past. The reason for > 7.0.18.1 is that, it indicates that some extra changes are done comparing > the 7.0.18 code base from Tomcat. > Thanks. > > 2011/7/11 Ivan > >> Yes, I will go ahead to pull the codes of 7.0.18, and apply those fixes on >> our code base, it is better to know whether the TCK is fine with the new >> version, also it looks to me that some integration changes are required. >> And it depends on whether Tomcat will release 7.0.19 soon, we could pull >> the latest 7.0.19 or release a 7.0.18.1 version with Geronimo 3.0. >> >> 2011/7/10 Kevan Miller >> >>> >>> On Jul 10, 2011, at 10:14 AM, Ivan wrote: >>> >>> > Seems that there are some issues with 7.0.18, and Tomcat community is >>> preparing for 7.0.19. >>> >>> So I see... I read the tomcat list last night, not this morning ;-) >>> >>> It would be a good idea to pull in an early version and identify any >>> integration or tck issues. >>> >>> Anyway, thanks for tracking this... >>> >>> --kevan >> >> >> >> >> -- >> Ivan >> > > > > -- > Ivan > > > -- Ivan
[jira] [Created] (GERONIMO-6069) JavaMail 1.8.3-SNAPSHOT
JavaMail 1.8.3-SNAPSHOT --- Key: GERONIMO-6069 URL: https://issues.apache.org/jira/browse/GERONIMO-6069 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6068) Tomcat 7.0.18.0-SNAPSHOT
Tomcat 7.0.18.0-SNAPSHOT Key: GERONIMO-6068 URL: https://issues.apache.org/jira/browse/GERONIMO-6068 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6064) OpenWebBeans 1.1.1-SNAPSHOT
OpenWebBeans 1.1.1-SNAPSHOT --- Key: GERONIMO-6064 URL: https://issues.apache.org/jira/browse/GERONIMO-6064 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6065) OpenJPA 2.1.1-SNAPSHOT
OpenJPA 2.1.1-SNAPSHOT -- Key: GERONIMO-6065 URL: https://issues.apache.org/jira/browse/GERONIMO-6065 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6067) MyFaces 2.0.8-SNAPSHOT
MyFaces 2.0.8-SNAPSHOT -- Key: GERONIMO-6067 URL: https://issues.apache.org/jira/browse/GERONIMO-6067 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6066) OpenEJB 4.0.0-SNAPSHOT
OpenEJB 4.0.0-SNAPSHOT -- Key: GERONIMO-6066 URL: https://issues.apache.org/jira/browse/GERONIMO-6066 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Pull Tomcat 7.0.18 to Geronimo side
DId tomcat accept the change of creating AsyncListeners using the InstanceManager? If so, then the change in geronimo's copy is all that is needed. thanks! david jencks On Jul 10, 2011, at 11:53 PM, Ivan wrote: > I merged all of the changes mentioned in the thread > http://old.nabble.com/Preparing-for-a-7.0.19-tag-td32031213.html , now the > 7.0.18.0 branch from Geronimo side has the same contents with the Tomcat > trunk rev.1144976GERONIMO-5622 > Also, an extra changes from Geronimo side is also added, GERONIMO-5622. it > will be better that someone could also help to review those changes. > > If we would release this 7.0.18 branch, which version should be used ? > 7.0.18.0 or 7.0.18.1, which is mentioned in the past. The reason for 7.0.18.1 > is that, it indicates that some extra changes are done comparing the 7.0.18 > code base from Tomcat. > Thanks. > > 2011/7/11 Ivan > Yes, I will go ahead to pull the codes of 7.0.18, and apply those fixes on > our code base, it is better to know whether the TCK is fine with the new > version, also it looks to me that some integration changes are required. > And it depends on whether Tomcat will release 7.0.19 soon, we could pull the > latest 7.0.19 or release a 7.0.18.1 version with Geronimo 3.0. > > 2011/7/10 Kevan Miller > > On Jul 10, 2011, at 10:14 AM, Ivan wrote: > > > Seems that there are some issues with 7.0.18, and Tomcat community is > > preparing for 7.0.19. > > So I see... I read the tomcat list last night, not this morning ;-) > > It would be a good idea to pull in an early version and identify any > integration or tck issues. > > Anyway, thanks for tracking this... > > --kevan > > > > -- > Ivan > > > > -- > Ivan
[jira] [Created] (GERONIMO-6063) Yoko 1.2-SNAPSHOT
Yoko 1.2-SNAPSHOT - Key: GERONIMO-6063 URL: https://issues.apache.org/jira/browse/GERONIMO-6063 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (GERONIMO-6014) Got "javax.ejb.EJBException" when running javaee 6 sample jpa20demo-javaee6
[ https://issues.apache.org/jira/browse/GERONIMO-6014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu closed GERONIMO-6014. -- Resolution: Invalid Should create a db first. so close it. > Got "javax.ejb.EJBException" when running javaee 6 sample jpa20demo-javaee6 > --- > > Key: GERONIMO-6014 > URL: https://issues.apache.org/jira/browse/GERONIMO-6014 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: sample apps >Affects Versions: 3.0 > Environment: OS:winxp > jdk:ibm jdk >Reporter: viola.lu >Priority: Minor > Fix For: 3.0 > > > 1.Build javaee6 sample jpa20demo-javaee6 and deploy > 2.Access http://localhost:8080/jpa20demo-javaee6/, click add, but got > javax.ejb.EJBException: The bean encountered a non-application exception; > nested exception is: > org.apache.openjpa.persistence.ArgumentException: A connection could not be > obtained for driver class "org.apache.derby.jdbc.ClientDriver" and URL > "jdbc:derby://localhost:1527/jpa20demodb". You may have specified an invalid > URL -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6061) Geronimo 3.0 trunk SNAPSHOT dependencies
Geronimo 3.0 trunk SNAPSHOT dependencies Key: GERONIMO-6061 URL: https://issues.apache.org/jira/browse/GERONIMO-6061 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Reporter: David Blevins Fix For: 3.0-M2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6062) XBean 3.8-SNAPSHOT
XBean 3.8-SNAPSHOT -- Key: GERONIMO-6062 URL: https://issues.apache.org/jira/browse/GERONIMO-6062 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: David Blevins -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMODEVTOOLS-706) Consider enabling Karaf shell in Eclipse console
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063655#comment-13063655 ] Yi Xiao commented on GERONIMODEVTOOLS-706: -- I try to reproduce the issue, however, I even could not execute any karaf shell commands in eclipse console. It always throw a "NoSuchElementException", now , I'm looking the karaf codes and trying to figure it out. > Consider enabling Karaf shell in Eclipse console > > > Key: GERONIMODEVTOOLS-706 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-706 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 3.0-M2 >Reporter: Jarek Gawor >Assignee: Ted Kirby > > (If possible) I think it would be pretty nice to have an option to enable and > access Karaf shell directly in Eclipse console window. If that can be done > make sure to start Geronimo server with > -Djline.terminal=jline.UnsupportedTerminal option. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5599) Reenable monitoring admin console portlets
[ https://issues.apache.org/jira/browse/GERONIMO-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shenghao Fang updated GERONIMO-5599: Attachment: GERONIMO-5599-20110712-1.patch Attach an updated patch since the files should be deleted were missed in the previous one. > Reenable monitoring admin console portlets > -- > > Key: GERONIMO-5599 > URL: https://issues.apache.org/jira/browse/GERONIMO-5599 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Forrest Xia >Assignee: Shenghao Fang > Attachments: GERONIMO-5599-20110629.patch, > GERONIMO-5599-20110712-1.patch, GERONIMO-5599-20110712.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6033) testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6033. - Resolution: Won't Fix This will go away with the merge of David Jencks' OSGi friendly code that always uses OpenEJB with OpenWebBeans and CDI. > testSettingInjectionTargetReplacesIt(org.jboss.jsr299.tck.tests.extensions.producer.ProducerTest) > - > > Key: GERONIMO-6033 > URL: https://issues.apache.org/jira/browse/GERONIMO-6033 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6032) testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest)
[ https://issues.apache.org/jira/browse/GERONIMO-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins resolved GERONIMO-6032. - Resolution: Fixed > testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest) > -- > > Key: GERONIMO-6032 > URL: https://issues.apache.org/jira/browse/GERONIMO-6032 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: David Blevins >Assignee: David Blevins > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Is there possible for 1.7.0 release ?
OK, I forget to reply to Axis2 mail list again ... 2011/7/12 Ivan > > > 2011/7/12 Andreas Veithen > >> The changes for Neethi 3.0.x (including the three changes mentioned in >> your mail) should now be included in the latest 1.6.1-SNAPSHOT build. >> The release vote for Neethi 3.0.1 has started a couple of hours ago. >> Once that release is complete, we can switch to the Neethi 3.0.1 >> release version on the 1.6 branch and Axis2 1.6.1 will be ready for >> release. >> >>Thanks, Andreas, I will try to switch to Axis2 1.6.1-SNAPSHOT soon. > > >> Regarding the list of JIRA issues, if I understand this correctly, the >> Geronimo project has a sort of patching mechanism so that they are not >> on the critical path for the Geronimo release, which means that we >> have the time to review them properly and first apply them to the >> trunk, without delaying any Geronimo release. Can you confirm this? >> > >Hmm, I would say that the patching mechanism used now is somewhat a > 'temporary' solution, and it is not expected to do that. Geronimo needs to > bundle the axis2 components, that gave us a chance to modify codes. >We do hope that those patches could be reviewed and included in Axis2 > code base. And yes, they work well now, but it is better to have your Axis2 > experts' view for them. Also, from other sides, most of them are related to > JAX-WS 2.2 support. I guess that they are also important for Axis2 ;-) >Anyway, it depends on your schedule, and your guys really helped us a > lot in the past. >Thanks. > >> >> Andreas >> >> On Sun, Jul 10, 2011 at 15:58, Ivan wrote: >> > Hi, Axis2 devs, any thought to port those listed changes to 1.6 branch ? >> > Thanks. >> > >> > 2011/7/8 Ivan >> >> >> >> Just add the geronimo mail address. >> >> >> >> 2011/7/8 Ivan >> >>> >> >>> Hi, the initial reason for moving to 1.7.0-SNAPSHOT is for the Policy >> >>> support, the changes are list below. If they could be ported to 1.6 >> branch, >> >>> we are fine to try to turn to 1.6 branch. >> >>> Also, understand that you guys are busy with some other stuffs, will >> be >> >>> very appreciated if those web services patches could be reviewed and >> >>> included in the 1.6 branch. I pasted the Jira list in the end of the >> mail. >> >>> The initial thread could be found >> >>> http://www.mail-archive.com/java-dev@axis.apache.org/msg06438.html >> >>> Thanks. >> >>> ---> >> >>> Revision: 1090457 >> >>> Author: veithen >> >>> Date: 5:36:59 AM, Saturday, April 09, 2011 >> >>> Message: >> >>> Exclude the transitive Woodstox dependency from Neethi. Otherwise we >> will >> >>> end up with two versions of Woodstox. >> >>> >> >>> Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml >> >>> Revision: 1090429 >> >>> Author: veithen >> >>> Date: 4:19:38 AM, Saturday, April 09, 2011 >> >>> Message: >> >>> Neethi now supports DOM elements. Therefore we don't need to convert >> DOM >> >>> elements to stream any more. Alos, DOM2Writer seems to have a bug that >> >>> causes processing of some policies to fail. >> >>> >> >>> Modified : >> >>> >> /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java >> >>> Revision: 1089989 >> >>> Author: veithen >> >>> Date: 4:27:37 AM, Friday, April 08, 2011 >> >>> Message: >> >>> Updated Neethi dependency and fixed PolicyUtil such that it supports >> all >> >>> WS-Policy namespaces supported by Neethi. >> >>> >> >>> Modified : >> >>> >> /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java >> >>> Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml >> >>> <--- >> >>> Jira list: >> >>> (AXIS2-5062) Connection is not released while using JAXWS >> client >> >>> API >> >>> (AXIS2-5039) Override the SOAPAction from the SOAPMessage MIME header >> if >> >>> it is explicitly configured later >> >>> (AXIS2-5023) Ambigious use of isElementData in the Block interface >> >>> (AXIS2-5022) Support addressing meta data with policy 1.5 framework >> >>> (AXIS2-5040) Ignore the methods while no webmethod annotation and no >> >>> webservice annotation on the declaring class >> >>> (AXIS2-5034) Incorrect exception name is used for fault message while >> >>> creating AxisService from WSDL >> >>> (AXIS2-5001) SOAPMessage.getSOAPHeaders() return null while no headers >> in >> >>> the soap envelope >> >>> (AXIS2-4996) Exclude content-length header while chunked is enabled >> >>> 2011/7/8 Andreas Veithen >> >> Ivan, >> >> There are no plans for a 1.7.0 release, but we can do a 1.6.1 >> maintenance release. For that you need to let us know which changes >> you want to see included in that release, so that we can merge them >> to >> the 1.6 branch. The goal is to make Geronimo work with >> 1.6.1-SNAPSHOT. >> Once that is done, we can create the 1.6.1 release anytime you want. >> >> Andreas >> >> On Fri, Jul 8, 2011 at 04:31, Ivan wrote: >> > Hi, Axi
Re: Is there possible for 1.7.0 release ?
2011/7/12 Andreas Veithen > The changes for Neethi 3.0.x (including the three changes mentioned in > your mail) should now be included in the latest 1.6.1-SNAPSHOT build. > The release vote for Neethi 3.0.1 has started a couple of hours ago. > Once that release is complete, we can switch to the Neethi 3.0.1 > release version on the 1.6 branch and Axis2 1.6.1 will be ready for > release. > >Thanks, Andreas, I will try to switch to Axis2 1.6.1-SNAPSHOT soon. > Regarding the list of JIRA issues, if I understand this correctly, the > Geronimo project has a sort of patching mechanism so that they are not > on the critical path for the Geronimo release, which means that we > have the time to review them properly and first apply them to the > trunk, without delaying any Geronimo release. Can you confirm this? > Hmm, I would say that the patching mechanism used now is somewhat a 'temporary' solution, and it is not expected to do that. Geronimo needs to bundle the axis2 components, that gave us a chance to modify codes. We do hope that those patches could be reviewed and included in Axis2 code base. And yes, they work well now, but it is better to have your Axis2 experts' view for them. Also, from other sides, most of them are related to JAX-WS 2.2 support. I guess that they are also important for Axis2 ;-) Anyway, it depends on your schedule, and your guys really helped us a lot in the past. Thanks. > > Andreas > > On Sun, Jul 10, 2011 at 15:58, Ivan wrote: > > Hi, Axis2 devs, any thought to port those listed changes to 1.6 branch ? > > Thanks. > > > > 2011/7/8 Ivan > >> > >> Just add the geronimo mail address. > >> > >> 2011/7/8 Ivan > >>> > >>> Hi, the initial reason for moving to 1.7.0-SNAPSHOT is for the Policy > >>> support, the changes are list below. If they could be ported to 1.6 > branch, > >>> we are fine to try to turn to 1.6 branch. > >>> Also, understand that you guys are busy with some other stuffs, will be > >>> very appreciated if those web services patches could be reviewed and > >>> included in the 1.6 branch. I pasted the Jira list in the end of the > mail. > >>> The initial thread could be found > >>> http://www.mail-archive.com/java-dev@axis.apache.org/msg06438.html > >>> Thanks. > >>> ---> > >>> Revision: 1090457 > >>> Author: veithen > >>> Date: 5:36:59 AM, Saturday, April 09, 2011 > >>> Message: > >>> Exclude the transitive Woodstox dependency from Neethi. Otherwise we > will > >>> end up with two versions of Woodstox. > >>> > >>> Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml > >>> Revision: 1090429 > >>> Author: veithen > >>> Date: 4:19:38 AM, Saturday, April 09, 2011 > >>> Message: > >>> Neethi now supports DOM elements. Therefore we don't need to convert > DOM > >>> elements to stream any more. Alos, DOM2Writer seems to have a bug that > >>> causes processing of some policies to fail. > >>> > >>> Modified : > >>> > /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java > >>> Revision: 1089989 > >>> Author: veithen > >>> Date: 4:27:37 AM, Friday, April 08, 2011 > >>> Message: > >>> Updated Neethi dependency and fixed PolicyUtil such that it supports > all > >>> WS-Policy namespaces supported by Neethi. > >>> > >>> Modified : > >>> > /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java > >>> Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml > >>> <--- > >>> Jira list: > >>> (AXIS2-5062) Connection is not released while using JAXWS > client > >>> API > >>> (AXIS2-5039) Override the SOAPAction from the SOAPMessage MIME header > if > >>> it is explicitly configured later > >>> (AXIS2-5023) Ambigious use of isElementData in the Block interface > >>> (AXIS2-5022) Support addressing meta data with policy 1.5 framework > >>> (AXIS2-5040) Ignore the methods while no webmethod annotation and no > >>> webservice annotation on the declaring class > >>> (AXIS2-5034) Incorrect exception name is used for fault message while > >>> creating AxisService from WSDL > >>> (AXIS2-5001) SOAPMessage.getSOAPHeaders() return null while no headers > in > >>> the soap envelope > >>> (AXIS2-4996) Exclude content-length header while chunked is enabled > >>> 2011/7/8 Andreas Veithen > > Ivan, > > There are no plans for a 1.7.0 release, but we can do a 1.6.1 > maintenance release. For that you need to let us know which changes > you want to see included in that release, so that we can merge them to > the 1.6 branch. The goal is to make Geronimo work with 1.6.1-SNAPSHOT. > Once that is done, we can create the 1.6.1 release anytime you want. > > Andreas > > On Fri, Jul 8, 2011 at 04:31, Ivan wrote: > > Hi, Axis2 devs, > > Geronimo bundles the some Axis2 components of 1.7.0-SNAPSHOT, > and > > it is > > obviously that we could not release these bundles with snapshot. I > am > > wondering that whe
Re: Is there possible for 1.7.0 release ?
The changes for Neethi 3.0.x (including the three changes mentioned in your mail) should now be included in the latest 1.6.1-SNAPSHOT build. The release vote for Neethi 3.0.1 has started a couple of hours ago. Once that release is complete, we can switch to the Neethi 3.0.1 release version on the 1.6 branch and Axis2 1.6.1 will be ready for release. Regarding the list of JIRA issues, if I understand this correctly, the Geronimo project has a sort of patching mechanism so that they are not on the critical path for the Geronimo release, which means that we have the time to review them properly and first apply them to the trunk, without delaying any Geronimo release. Can you confirm this? Andreas On Sun, Jul 10, 2011 at 15:58, Ivan wrote: > Hi, Axis2 devs, any thought to port those listed changes to 1.6 branch ? > Thanks. > > 2011/7/8 Ivan >> >> Just add the geronimo mail address. >> >> 2011/7/8 Ivan >>> >>> Hi, the initial reason for moving to 1.7.0-SNAPSHOT is for the Policy >>> support, the changes are list below. If they could be ported to 1.6 branch, >>> we are fine to try to turn to 1.6 branch. >>> Also, understand that you guys are busy with some other stuffs, will be >>> very appreciated if those web services patches could be reviewed and >>> included in the 1.6 branch. I pasted the Jira list in the end of the mail. >>> The initial thread could be found >>> http://www.mail-archive.com/java-dev@axis.apache.org/msg06438.html >>> Thanks. >>> ---> >>> Revision: 1090457 >>> Author: veithen >>> Date: 5:36:59 AM, Saturday, April 09, 2011 >>> Message: >>> Exclude the transitive Woodstox dependency from Neethi. Otherwise we will >>> end up with two versions of Woodstox. >>> >>> Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml >>> Revision: 1090429 >>> Author: veithen >>> Date: 4:19:38 AM, Saturday, April 09, 2011 >>> Message: >>> Neethi now supports DOM elements. Therefore we don't need to convert DOM >>> elements to stream any more. Alos, DOM2Writer seems to have a bug that >>> causes processing of some policies to fail. >>> >>> Modified : >>> /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java >>> Revision: 1089989 >>> Author: veithen >>> Date: 4:27:37 AM, Friday, April 08, 2011 >>> Message: >>> Updated Neethi dependency and fixed PolicyUtil such that it supports all >>> WS-Policy namespaces supported by Neethi. >>> >>> Modified : >>> /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java >>> Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml >>> <--- >>> Jira list: >>> (AXIS2-5062) Connection is not released while using JAXWS client >>> API >>> (AXIS2-5039) Override the SOAPAction from the SOAPMessage MIME header if >>> it is explicitly configured later >>> (AXIS2-5023) Ambigious use of isElementData in the Block interface >>> (AXIS2-5022) Support addressing meta data with policy 1.5 framework >>> (AXIS2-5040) Ignore the methods while no webmethod annotation and no >>> webservice annotation on the declaring class >>> (AXIS2-5034) Incorrect exception name is used for fault message while >>> creating AxisService from WSDL >>> (AXIS2-5001) SOAPMessage.getSOAPHeaders() return null while no headers in >>> the soap envelope >>> (AXIS2-4996) Exclude content-length header while chunked is enabled >>> 2011/7/8 Andreas Veithen Ivan, There are no plans for a 1.7.0 release, but we can do a 1.6.1 maintenance release. For that you need to let us know which changes you want to see included in that release, so that we can merge them to the 1.6 branch. The goal is to make Geronimo work with 1.6.1-SNAPSHOT. Once that is done, we can create the 1.6.1 release anytime you want. Andreas On Fri, Jul 8, 2011 at 04:31, Ivan wrote: > Hi, Axis2 devs, > Geronimo bundles the some Axis2 components of 1.7.0-SNAPSHOT, and > it is > obviously that we could not release these bundles with snapshot. I am > wondering that whether Axis2 could have chance to have a 1.7.0 > release, or > maybe a milestone release ? > thanks. > -- > Ivan > - To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org For additional commands, e-mail: java-dev-h...@axis.apache.org >>> >>> >>> >>> -- >>> Ivan >> >> >> >> -- >> Ivan > > > > -- > Ivan >
[jira] [Reopened] (GERONIMO-5764) Support Bundles Deployment in deployment command line
[ https://issues.apache.org/jira/browse/GERONIMO-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reopened GERONIMO-5764: --- While working on the GEP side of this feature I ran into two problems so far: 1) Fragment bundles are not supported. The server will fail to start if a fragment bundle is added to startup.properties file. 2) Right now it is possible for a bundle added to startup.properties to start before any of the required Geronimo configuration modules are even installed. Which means the bundle might not startup properly. This I believe might be fixed by ensuring the deployed bundles are started after all the configuration bundles are started - via configuring the right start level. This needs to be investigated and fixed. > Support Bundles Deployment in deployment command line > - > > Key: GERONIMO-5764 > URL: https://issues.apache.org/jira/browse/GERONIMO-5764 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: commands, console, deployment >Affects Versions: 3.0 >Reporter: viola.lu >Assignee: Rex Wang >Priority: Critical > Fix For: 3.0 > > Attachments: GERONIMO-5764-install-bundle.patch, > GERONIMO-5764-install-uninstall-bundle.patch, > GERONIMO-5764-record-bundle.patch, GERONIMO-5764.patch > > > Now we have to deploy a regular bundle via karaf shell: osgi:install > file:/[bunlde_path], not deployer command line, so open this jira to track > this feature enablement. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMODEVTOOLS-759) Using the new APIs to manage the bundles status both in GEP and Server side
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063449#comment-13063449 ] Jarek Gawor commented on GERONIMODEVTOOLS-759: -- In revision 1145251 I refactored the module handling code. I separated it into two separate classes - one for handling the Java EE modules and EBAs and second one for handling OSGi bundles. I also simplified the OSGi handling code. Please review in case I missed something. > Using the new APIs to manage the bundles status both in GEP and Server side > > > Key: GERONIMODEVTOOLS-759 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-759 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 3.0 > Environment: WinXP sp3 32bit& Win7 64bit, Oracle JDK 1.6, > Eclipse3.6SR1&SR2 >Reporter: Yi Xiao >Assignee: Jarek Gawor > Labels: OSGI, bundle > Fix For: 3.0 > > Attachments: OSGIBundleDeploy.patch, > OSGIBundleDeploy_changeAPI.patch, OSGIBundleDeploy_changeAPI2_759.patch, > OSGIBundleDeploy_changePOM_759.patch > > > This improvement depends on the server's modules, so, if the server side does > not update timely, it may cause the GEP compile failure! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6055) improve server startup time
[ https://issues.apache.org/jira/browse/GERONIMO-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063447#comment-13063447 ] Kevan Miller commented on GERONIMO-6055: Some of the data from the .png attachments seems a bit skewed. So, I instrumented some code to look at where we're spending some time... Here's some of the results: _Startup completed in 19.411s seconds_ Of that time, we spent nearly half of that time in o.a.g.bval.ValidatorFactoryGBean.createDefaultFactory() and o.a.g.tomcat.TomcatContainer.addContext() (following times are in milliseconds): _ValidatorFactoryGBean.createDefaultFactory() time: 249, Cumulative time: 4064, Average: 254_ and _TomcatContainer.addContext() time: 1704, Cumulative time: 5454, Average: 495_ Of the addContext() time, we spent nearly all of the time in the following 2 methods during the addContext() processing: _GeronimoStandardContext.setContextProperties() time: 321, Cumulative time: 3266, Average: 296_ _GeronimoStandardContext.startInternal() time: 1382, Cumulative time: 2125, Average: 193_ This final startInternal() call occurred during the start of uddi-tomcat. > improve server startup time > --- > > Key: GERONIMO-6055 > URL: https://issues.apache.org/jira/browse/GERONIMO-6055 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Affects Versions: 3.0 >Reporter: Kevan Miller > Attachments: BeanValidationCallStack.png, OpenWebBeansCallStack.png > > > 3.0 server startup has gotten kind of slow. Time to see if we can boost it, a > bit. > I've made some measurements of server startup time using YourKit Java > Profiler (which I think is a great memory and performance analysis tool). If > anybody is trying to use it with Geronimo, you need to update > etc/config.properties in order to run YourKit with Geronimo 3.0. Add > "com.yourkit.*" to the org.osgi.framework.bootdelegation setting. > There are a few surprising hot spots. There may be some improvements that we > can suggest to the Equinox project. However, I think there are some > improvements that we should be making, also... > I'll attach some screen captures that should illustrate some of the issues. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-5599) Reenable monitoring admin console portlets
[ https://issues.apache.org/jira/browse/GERONIMO-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shenghao Fang updated GERONIMO-5599: Attachment: GERONIMO-5599-20110712.patch An updated patch for some bug fixes. > Reenable monitoring admin console portlets > -- > > Key: GERONIMO-5599 > URL: https://issues.apache.org/jira/browse/GERONIMO-5599 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Forrest Xia >Assignee: Shenghao Fang > Attachments: GERONIMO-5599-20110629.patch, > GERONIMO-5599-20110712.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6060) ClassCastException thrown in RunAsLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang resolved GERONIMO-6060. --- Resolution: Fixed Thanks Shenghao Fang for the patch ! -- Author: genspring Date: Mon Jul 11 12:40:38 2011 New Revision: 1145150 URL: http://svn.apache.org/viewvc?rev=1145150&view=rev Log: > ClassCastException thrown in RunAsLoginModule > - > > Key: GERONIMO-6060 > URL: https://issues.apache.org/jira/browse/GERONIMO-6060 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 3.0 >Reporter: Shenghao Fang >Assignee: Shenghao Fang > Attachments: GERONIMO-6060.patch > > > ClassCastException thrown in RunAsLoginModule. > Cannot cast BundleHost to ClassLoader. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6060) ClassCastException thrown in RunAsLoginModule
[ https://issues.apache.org/jira/browse/GERONIMO-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shenghao Fang updated GERONIMO-6060: Attachment: GERONIMO-6060.patch Patch is attached. > ClassCastException thrown in RunAsLoginModule > - > > Key: GERONIMO-6060 > URL: https://issues.apache.org/jira/browse/GERONIMO-6060 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 3.0 >Reporter: Shenghao Fang >Assignee: Shenghao Fang > Attachments: GERONIMO-6060.patch > > > ClassCastException thrown in RunAsLoginModule. > Cannot cast BundleHost to ClassLoader. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GERONIMO-6060) ClassCastException thrown in RunAsLoginModule
ClassCastException thrown in RunAsLoginModule - Key: GERONIMO-6060 URL: https://issues.apache.org/jira/browse/GERONIMO-6060 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 3.0 Reporter: Shenghao Fang Assignee: Shenghao Fang ClassCastException thrown in RunAsLoginModule. Cannot cast BundleHost to ClassLoader. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Is there possible for 1.7.0 release ?
Geronimo needs a release with a well delimited set of changes. Doing this as a 1.6.1 maintenance release represents less work and is less likely to get delayed because of changes or pending issues unrelated to the request from Geronimo. Andreas On Mon, Jul 11, 2011 at 04:39, Sanjiva Weerawarana wrote: > Andreas if we making a whole bunch of changes why not simply release trunk > as 1.7? > Sanjiva. > > On Sun, Jul 10, 2011 at 7:20 PM, Andreas Veithen > wrote: >> >> Ivan, >> >> I have an entire list of changes that I want to include in 1.6.1 and >> that I need to merge from the trunk. I will include the changes >> relevant for Geronimo as well. >> >> Note to the Axis2 folks: this will require upgrading the 1.6 branch to >> Neethi 3.0.x (from Neethi 2.0.x). If anybody sees an issue, please >> shout. >> >> Andreas >> >> On Sun, Jul 10, 2011 at 15:58, Ivan wrote: >> > Hi, Axis2 devs, any thought to port those listed changes to 1.6 branch ? >> > Thanks. >> > >> > 2011/7/8 Ivan >> >> >> >> Just add the geronimo mail address. >> >> >> >> 2011/7/8 Ivan >> >>> >> >>> Hi, the initial reason for moving to 1.7.0-SNAPSHOT is for the Policy >> >>> support, the changes are list below. If they could be ported to 1.6 >> >>> branch, >> >>> we are fine to try to turn to 1.6 branch. >> >>> Also, understand that you guys are busy with some other stuffs, will >> >>> be >> >>> very appreciated if those web services patches could be reviewed and >> >>> included in the 1.6 branch. I pasted the Jira list in the end of the >> >>> mail. >> >>> The initial thread could be found >> >>> http://www.mail-archive.com/java-dev@axis.apache.org/msg06438.html >> >>> Thanks. >> >>> ---> >> >>> Revision: 1090457 >> >>> Author: veithen >> >>> Date: 5:36:59 AM, Saturday, April 09, 2011 >> >>> Message: >> >>> Exclude the transitive Woodstox dependency from Neethi. Otherwise we >> >>> will >> >>> end up with two versions of Woodstox. >> >>> >> >>> Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml >> >>> Revision: 1090429 >> >>> Author: veithen >> >>> Date: 4:19:38 AM, Saturday, April 09, 2011 >> >>> Message: >> >>> Neethi now supports DOM elements. Therefore we don't need to convert >> >>> DOM >> >>> elements to stream any more. Alos, DOM2Writer seems to have a bug that >> >>> causes processing of some policies to fail. >> >>> >> >>> Modified : >> >>> >> >>> /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java >> >>> Revision: 1089989 >> >>> Author: veithen >> >>> Date: 4:27:37 AM, Friday, April 08, 2011 >> >>> Message: >> >>> Updated Neethi dependency and fixed PolicyUtil such that it supports >> >>> all >> >>> WS-Policy namespaces supported by Neethi. >> >>> >> >>> Modified : >> >>> >> >>> /axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/util/PolicyUtil.java >> >>> Modified : /axis/axis2/java/core/trunk/modules/parent/pom.xml >> >>> <--- >> >>> Jira list: >> >>> (AXIS2-5062) Connection is not released while using JAXWS >> >>> client >> >>> API >> >>> (AXIS2-5039) Override the SOAPAction from the SOAPMessage MIME header >> >>> if >> >>> it is explicitly configured later >> >>> (AXIS2-5023) Ambigious use of isElementData in the Block interface >> >>> (AXIS2-5022) Support addressing meta data with policy 1.5 framework >> >>> (AXIS2-5040) Ignore the methods while no webmethod annotation and no >> >>> webservice annotation on the declaring class >> >>> (AXIS2-5034) Incorrect exception name is used for fault message while >> >>> creating AxisService from WSDL >> >>> (AXIS2-5001) SOAPMessage.getSOAPHeaders() return null while no headers >> >>> in >> >>> the soap envelope >> >>> (AXIS2-4996) Exclude content-length header while chunked is enabled >> >>> 2011/7/8 Andreas Veithen >> >> Ivan, >> >> There are no plans for a 1.7.0 release, but we can do a 1.6.1 >> maintenance release. For that you need to let us know which changes >> you want to see included in that release, so that we can merge them >> to >> the 1.6 branch. The goal is to make Geronimo work with >> 1.6.1-SNAPSHOT. >> Once that is done, we can create the 1.6.1 release anytime you want. >> >> Andreas >> >> On Fri, Jul 8, 2011 at 04:31, Ivan wrote: >> > Hi, Axis2 devs, >> > Geronimo bundles the some Axis2 components of 1.7.0-SNAPSHOT, >> > and >> > it is >> > obviously that we could not release these bundles with snapshot. I >> > am >> > wondering that whether Axis2 could have chance to have a 1.7.0 >> > release, or >> > maybe a milestone release ? >> > thanks. >> > -- >> > Ivan >> > >> >> - >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >> For additional commands, e-mail: java-dev-h...@axis.apache.org >> >> >>> >> >>> >> >>> >> >>> -- >> >>> Ivan >> >> >> >> >>
[jira] [Resolved] (GERONIMO-6027) fail to create BIO HTTPS connector for Tomcat using admin console
[ https://issues.apache.org/jira/browse/GERONIMO-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang resolved GERONIMO-6027. --- Resolution: Fixed trunk@1145027, thanks Shenghao Fang for the patch ! > fail to create BIO HTTPS connector for Tomcat using admin console > - > > Key: GERONIMO-6027 > URL: https://issues.apache.org/jira/browse/GERONIMO-6027 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, Tomcat >Reporter: Chi Runhua >Assignee: Shenghao Fang >Priority: Minor > Fix For: 3.0 > > Attachments: GERONIMO-6027-1.patch, GERONIMO-6027.patch > > > Tried to create a BIO https connector using admin console, and input all > required fields, then click save. > The connector fails to start. > 2011-06-29 15:31:47,433 WARN [ConnectorGBean] test_BIOHTTPS connector failed > 2011-06-29 15:31:47,433 ERROR [GBeanInstanceState] Error while starting; > GBean is now in the FAILED state: > abstractName="org.apache.geronimo.configs/tomcat7/3.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat7/3.0-SNAPSHOT/car,j2eeType=GBean,name=test_BIOHTTPS" > org.apache.xbean.recipe.ConstructionException: Error creating gbean of class: > org.apache.geronimo.tomcat.connector.Https11ConnectorGBean, attempting to set > nonexistent properties: [clientAuth] > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:955) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:567) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.tomcat.connector.Https11Protocol$$EnhancerByCGLIB$$c056c043.startRecursive() > at > org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction(ConnectorPortlet.java:152) > at > org.apache.pluto.driver.services.container.FilterChainImpl.doFilter(FilterChainImpl.java:117) > at > org.apache.pluto.driver.services.container.FilterChainImpl.processFilter(FilterChainImpl.java:84) > at > org.apache.pluto.driver.services.container.FilterManagerImpl.processFilter(FilterManagerImpl.java:112) > at > org.apache.pluto.container.driver.PortletServlet.dispatch(PortletServlet.java:359) > at > org.apache.pluto.container.driver.PortletServlet.doPost(PortletServlet.java:267) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:306) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:581) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:518) > at > org.apache.pluto.driver.container.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:233) > at > org.apache.pluto.driver.container.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:101) > at > org.apache.pluto.container.impl.PortletContainerImpl.doAction(PortletContainerImpl.java:251) > at > org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:135) > at > org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:205) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:306) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.geronimo.console.filter.RedirectByHashFilter.doFilter(RedirectByHashFilter.java:116) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:244) >
[jira] [Resolved] (GERONIMO-6057) HttpServletRequest.isUserInRole() returns wrong value
[
https://issues.apache.org/jira/browse/GERONIMO-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan resolved GERONIMO-6057.
Resolution: Fixed
Fix Version/s: 3.0
Commit the changes to trunk at r1145056. Thanks, Fang Sheng Hao.
> HttpServletRequest.isUserInRole() returns wrong value
> -
>
> Key: GERONIMO-6057
> URL: https://issues.apache.org/jira/browse/GERONIMO-6057
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: console, security
>Affects Versions: 3.0
> Environment: Tomcat
>Reporter: Shenghao Fang
>Assignee: Ivan
> Fix For: 3.0
>
> Attachments: GERONIMO-6057.patch
>
>
> HttpServletRequest.isUserInRole("admin") always returns false in Admin
> Console although loginned by 'system'. (eg. welcomeNormal.jsp:59)
> I did some investigation and found that current implementation in
> JACCRealm.hasRole uses wrapper.getName() to get the servlet name.
> {code:title=JACCRealm.java|borderStyle=solid}
> public boolean hasRole(Wrapper wrapper, Principal principal, String role)
> {
> AccessControlContext acc = ContextManager.getCurrentContext();
> String name = wrapper.getName();
> /**
> * JACC v1.0 secion B.19
> */
> if (name == null || name.equals("jsp")) {
> name = "";
> }
> try {
> acc.checkPermission(new WebRoleRefPermission(name, role));
> return true;
> } catch (AccessControlException e) {
> return false;
> }
> }
> {code}
> But implementation in previous version uses currentRequestWrapperName.get()
> to get the servlet name.
> {code:title=JACCRealm.java|borderStyle=solid}
> public boolean hasRole(Principal principal, String role) {
> AccessControlContext acc = ContextManager.getCurrentContext();
> String name = currentRequestWrapperName.get();
> /**
> * JACC v1.0 secion B.19
> */
> if (name == null || name.equals("jsp")) {
> name = "";
> }
> try {
> acc.checkPermission(new WebRoleRefPermission(name, role));
> return true;
> } catch (AccessControlException e) {
> return false;
> }
> }
> {code}
> currentRequestWrapperName is a ThreadLocal variable and is set by
> DispatchListener.beforeDispatch()
> {code:title=DispatchListener|borderStyle=solid}
> private void beforeDispatch(GeronimoStandardContext webContext,
> ServletRequest request, ServletResponse response) {
> BeforeAfter beforeAfter = webContext.getBeforeAfter();
> if (beforeAfter != null) {
> Stack stack = currentContext.get();
> BeforeAfterContext beforeAfterContext = new
> BeforeAfterContext(webContext.getContextCount() + 2);
> String wrapperName = getWrapperName(request, webContext);
> beforeAfterContext.contexts[webContext.getContextCount()] =
> JACCRealm.setRequestWrapperName(wrapperName);
> beforeAfterContext.contexts[webContext.getContextCount() + 1] =
> PolicyContext.getContextID();
> PolicyContext.setContextID(webContext.getPolicyContextId());
> beforeAfter.before(beforeAfterContext, request, response,
> BeforeAfter.DISPATCHED);
> stack.push(beforeAfterContext);
> }
> }
> private String getWrapperName(ServletRequest request,
> GeronimoStandardContext webContext) {
> MappingData mappingData = new MappingData();
> Mapper mapper = webContext.getMapper();
> MessageBytes mb = MessageBytes.newInstance();
> String dispatchPath = (String)
> request.getAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR);
> mb.setString(webContext.getName() + dispatchPath);
> try {
> mapper.map(mb, mappingData);
> StandardWrapper wrapper = (StandardWrapper) mappingData.wrapper;
> return wrapper.getName();
> } catch (Exception e) {
> log.error(e.getMessage(), e);
> }
> return null;
> }
> }
> {code}
> It looks to me that wrapper.getName() returns the name of the initial servlet
> instead of the current servlet.
> I thought using currentRequestWrapperName.get() leads to the right behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
less-osgi-friendly code drop
I've back-ported the owb/jcdi related changes on the osgi-friendly branch to trunk and pushed a code drop to http://people.apache.org/~djencks/less-osgi-geronimo-3.0-SNAPSHOT-source-release.zip So far all I know is that it compiles for me and the tomcat full server starts. With the osgi-friendly code I was down to these jcdi results: Failed tests: testRequestScopeDestroyedAfterCallToEjbTimeoutMethod(org.jboss.jsr299.tck.tests.context.request.ejb.EJBRequestContextTest) testSessionContextDestroyedWhenHttpSessionTimesOut(org.jboss.jsr299.tck.tests.context.session.SessionContextTest) testSessionContextSharedBetweenServletRequestsInSameHttpSession(org.jboss.jsr299.tck.tests.context.session.SessionContextTest) testSessionContextDestroyedWhenHttpSessionInvalidated(org.jboss.jsr299.tck.tests.context.session.SessionContextTest) testStereotypeWithNonEmptyNamed(org.jboss.jsr299.tck.tests.definition.stereotype.broken.nonEmptyNamed.NonEmptyNamedTest) testStereotypeWithTooManyScopeTypes(org.jboss.jsr299.tck.tests.definition.stereotype.broken.tooManyScopes.TooManyScopeTypesTest) test(org.jboss.jsr299.tck.tests.deployment.packaging.bundledLibrary.LibraryInEarTest) testPrincipalBean(org.jboss.jsr299.tck.tests.implementation.builtin.BuiltInBeansTest) testSerializeSFSB(org.jboss.jsr299.tck.tests.implementation.enterprise.lifecycle.EnterpriseBeanLifecycleTest) testApplicationCannotCallRemoveMethodOnNonDependentScopedSessionEnterpriseBean(org.jboss.jsr299.tck.tests.implementation.enterprise.remove.EnterpriseBeanRemoveMethodTest) testPassivationOfEjbs(org.jboss.jsr299.tck.tests.implementation.simple.resource.ejb.EjbInjectionTest) testSpecializedBeanNotInstantiated(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationIntegrationTest) testSpecializingBeanHasBindingsOfSpecializedAndSpecializingBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest) testSpecializingBeanHasNameOfSpecializedBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest) testSpecializingClassDirectlyExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsNothing.DirectlyExtendsNothingTest) testSpecializingClassDirectlyExtendsSimpleBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsSimpleBean.DirectlyExtendsSimpleBeanTest) testSpecializingClassImplementsInterfaceAndExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.implementInterfaceAndExtendsNothing.ImplementsInterfaceAndExtendsNothingTest) testSpecializingAndSpecializedBeanHasName(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.sameName.SameNameTest) testNonExistantClassInBeansXmlNotOk(org.jboss.jsr299.tck.tests.interceptors.definition.broken.nonExistantClassInBeansXml.NonExistantClassInBeansXmlTest) testNonContextualSessionBeanReferenceIsIntercepted(org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest) testELResolverRegisteredWithServletContainer(org.jboss.jsr299.tck.tests.lookup.el.integration.IntegrationWithUnifiedELTest) Tests run: 845, Failures: 21, Errors: 0, Skipped: 0 (note that one of the built-in bean tests that was working for a while isn't right now). If I can convince myself this is unlikely to have broken much I'll probably commit to svn tomorrow if it won't get in dblevin's way. thanks david jencks
[jira] [Assigned] (GERONIMO-6057) HttpServletRequest.isUserInRole() returns wrong value
[
https://issues.apache.org/jira/browse/GERONIMO-6057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan reassigned GERONIMO-6057:
--
Assignee: Ivan (was: Shenghao Fang)
> HttpServletRequest.isUserInRole() returns wrong value
> -
>
> Key: GERONIMO-6057
> URL: https://issues.apache.org/jira/browse/GERONIMO-6057
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: console, security
>Affects Versions: 3.0
> Environment: Tomcat
>Reporter: Shenghao Fang
>Assignee: Ivan
> Attachments: GERONIMO-6057.patch
>
>
> HttpServletRequest.isUserInRole("admin") always returns false in Admin
> Console although loginned by 'system'. (eg. welcomeNormal.jsp:59)
> I did some investigation and found that current implementation in
> JACCRealm.hasRole uses wrapper.getName() to get the servlet name.
> {code:title=JACCRealm.java|borderStyle=solid}
> public boolean hasRole(Wrapper wrapper, Principal principal, String role)
> {
> AccessControlContext acc = ContextManager.getCurrentContext();
> String name = wrapper.getName();
> /**
> * JACC v1.0 secion B.19
> */
> if (name == null || name.equals("jsp")) {
> name = "";
> }
> try {
> acc.checkPermission(new WebRoleRefPermission(name, role));
> return true;
> } catch (AccessControlException e) {
> return false;
> }
> }
> {code}
> But implementation in previous version uses currentRequestWrapperName.get()
> to get the servlet name.
> {code:title=JACCRealm.java|borderStyle=solid}
> public boolean hasRole(Principal principal, String role) {
> AccessControlContext acc = ContextManager.getCurrentContext();
> String name = currentRequestWrapperName.get();
> /**
> * JACC v1.0 secion B.19
> */
> if (name == null || name.equals("jsp")) {
> name = "";
> }
> try {
> acc.checkPermission(new WebRoleRefPermission(name, role));
> return true;
> } catch (AccessControlException e) {
> return false;
> }
> }
> {code}
> currentRequestWrapperName is a ThreadLocal variable and is set by
> DispatchListener.beforeDispatch()
> {code:title=DispatchListener|borderStyle=solid}
> private void beforeDispatch(GeronimoStandardContext webContext,
> ServletRequest request, ServletResponse response) {
> BeforeAfter beforeAfter = webContext.getBeforeAfter();
> if (beforeAfter != null) {
> Stack stack = currentContext.get();
> BeforeAfterContext beforeAfterContext = new
> BeforeAfterContext(webContext.getContextCount() + 2);
> String wrapperName = getWrapperName(request, webContext);
> beforeAfterContext.contexts[webContext.getContextCount()] =
> JACCRealm.setRequestWrapperName(wrapperName);
> beforeAfterContext.contexts[webContext.getContextCount() + 1] =
> PolicyContext.getContextID();
> PolicyContext.setContextID(webContext.getPolicyContextId());
> beforeAfter.before(beforeAfterContext, request, response,
> BeforeAfter.DISPATCHED);
> stack.push(beforeAfterContext);
> }
> }
> private String getWrapperName(ServletRequest request,
> GeronimoStandardContext webContext) {
> MappingData mappingData = new MappingData();
> Mapper mapper = webContext.getMapper();
> MessageBytes mb = MessageBytes.newInstance();
> String dispatchPath = (String)
> request.getAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR);
> mb.setString(webContext.getName() + dispatchPath);
> try {
> mapper.map(mb, mappingData);
> StandardWrapper wrapper = (StandardWrapper) mappingData.wrapper;
> return wrapper.getName();
> } catch (Exception e) {
> log.error(e.getMessage(), e);
> }
> return null;
> }
> }
> {code}
> It looks to me that wrapper.getName() returns the name of the initial servlet
> instead of the current servlet.
> I thought using currentRequestWrapperName.get() leads to the right behavior.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6059) New look and feel of Geronimo 3.0 admin console
[ https://issues.apache.org/jira/browse/GERONIMO-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-6059: --- Attachment: old-cosole-full-opened-navigation-tree.png > New look and feel of Geronimo 3.0 admin console > --- > > Key: GERONIMO-6059 > URL: https://issues.apache.org/jira/browse/GERONIMO-6059 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Affects Versions: 3.0 >Reporter: Rex Wang >Assignee: Rex Wang > Fix For: 3.0 > > Attachments: Geronimo-3.0-New-UI-Proposal-advanced-navigator.png, > Geronimo-3.0-New-UI-Proposal-basic-navigator.png, > old-cosole-full-opened-navigation-tree.png > > > Geronimo 3.0 is milestone release that contains a lot of new features. So I > think it's time to change the UI design of admin console to provide user a > brand new look and feel. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GERONIMO-6059) New look and feel of Geronimo 3.0 admin console
[ https://issues.apache.org/jira/browse/GERONIMO-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062878#comment-13062878 ] Rex Wang commented on GERONIMO-6059: well, the problem is we have more and more items adding to the tree, which makes the default-opened navigation tree very long. So, that's why we have a basic mode of Navigator currently. The idea is that user can put the ones they always use to the Basic Navigator panel as a shortcut. Different users always have different working set, right? thanks, -Rex. > New look and feel of Geronimo 3.0 admin console > --- > > Key: GERONIMO-6059 > URL: https://issues.apache.org/jira/browse/GERONIMO-6059 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console >Affects Versions: 3.0 >Reporter: Rex Wang >Assignee: Rex Wang > Fix For: 3.0 > > Attachments: Geronimo-3.0-New-UI-Proposal-advanced-navigator.png, > Geronimo-3.0-New-UI-Proposal-basic-navigator.png > > > Geronimo 3.0 is milestone release that contains a lot of new features. So I > think it's time to change the UI design of admin console to provide user a > brand new look and feel. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
