Questions about release aftermath...
The maven plugin release instructions I copied suggest... 14. Add the release to the next board report, in the private subversion area. 15. Add the release to the wiki, under the Recent Releases section of the front page and on the Releases page. These seem to me like a good idea but I have been stymied by not being able to find either one. Do we have a next board report? If so where is it? Do we have a suitable recent releases section in the wiki? If so where is it? thanks david jencks
[jira] Closed: (GERONIMO-3896) Error processing HEAD method by default HttpServlet#doHead()
[
https://issues.apache.org/jira/browse/GERONIMO-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks closed GERONIMO-3896.
--
Resolution: Fixed
Fix Version/s: 2.0.x
After spec jar release, update server builds to use it.
branches/2.0 rev 637748
branches/2.1 rev 637749
trunk rev 637750
Error processing HEAD method by default HttpServlet#doHead()
Key: GERONIMO-3896
URL: https://issues.apache.org/jira/browse/GERONIMO-3896
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: specs
Affects Versions: 2.0.2
Environment: Geronimo 2.0.2/Tomcat, Geronimo 2.1?
Reporter: Andrey Utkin
Assignee: David Jencks
Priority: Blocker
Fix For: 2.0.x, 2.1.1, 2.2
Attachments: GERONIMO-3896.patch,
geronimo-servlet_2.5_spec-1.1.1-fake.jar
I have Servlet with use RequestDispatcher.include()/forward() to JSP.
My Servlet extends HttpServlet. I don`t overwrite doHead() method.
While processing HEAD method following exception throws:
{code}
09:18:57,647 ERROR [[SimpleDispatchServlet]] Servlet.service() for servlet
SimpleDispatchServlet threw exception
javax.servlet.ServletException: Original SevletResponse or wrapped original
ServletResponse not passed to
RequestDispatcher in violation of SRV.8.2 and SRV.14.2.5.1
at
org.apache.catalina.core.ApplicationDispatcher.checkSameObjects(ApplicationDispatcher.java:985)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:493)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
at
com.km.webapp.test.simple.SimpleDispatchServlet.doGet(SimpleDispatchServlet.java:26)
at javax.servlet.http.HttpServlet.doHead(HttpServlet.java:274)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:353)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
{code}
Exploring code I found that Tomcat`s implementation of RequestDispatcher
expects that passed Response/Request objects is original objects or is
wrapped by ServletRequestWrapper/ServletResponseWrapper. But
geronimo-servlet_2.5_spec/HttpServlet.java#doHead() use NoBodyResponse class
which is not instance of ServletResponseWrapper. So, exception thrown.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579354#action_12579354 ] Ralf Baumhof commented on GERONIMO-3907: Of course entityManager.flush() works. But this is not an appropriate solution. We have a big project and we can not rely on the programmers always to write flush after each persist call. What i mean is a configuration setting that always forces the EntityManager to write changes through to databse. I have tried to disable caching but this does not work. Now, i'am currently evaluating: property name=openjpa.DataCacheTimeout value=0 /. This seems to work. This means, data in the cache will expire at once. But will there be any serious side effects if we enable this setting I consider this problem as very serious because container transaction managment must be reliable. It's the main point for using an application server. Persistence Exception is not visible/lost for client. -- Key: GERONIMO-3907 URL: https://issues.apache.org/jira/browse/GERONIMO-3907 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0.2, 2.1 Environment: Linux, Windows Reporter: Ralf Baumhof Priority: Blocker Original Estimate: 0.08h Remaining Estimate: 0.08h I am trying an insert on a table. The Entity class is wrong annotated, one column was renamed in the table. Then the following situation occurs. The call to persist(entity) is successfully, no exception is thrown. On leaving the ejb container and returning to tomact a commit is performed (it's a managed datasource, so container performs commit). This leads to the insert on database. This insert fails, a rollback is performed. On return to the JSF bean no exception can be seen by the bean. In the same class i have got a query method. If i replace the call to persist with the call to the query method everything works ok. The exception is thrown and is visible at the client site. This is the geronimo console output. The last line comes from the JSB bean which reports a successful insert. 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.1-r420667:592145 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy75.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579356#action_12579356 ] Ralf Baumhof commented on GERONIMO-3907: Sorry, i was wrong. The setting property name=openjpa.DataCacheTimeout value=0 / does not work. So, if there is no nearby solution for this problem, we must think about stopping the project and first port to an another application container. Persistence Exception is not visible/lost for client. -- Key: GERONIMO-3907 URL: https://issues.apache.org/jira/browse/GERONIMO-3907 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0.2, 2.1 Environment: Linux, Windows Reporter: Ralf Baumhof Priority: Blocker Original Estimate: 0.08h Remaining Estimate: 0.08h I am trying an insert on a table. The Entity class is wrong annotated, one column was renamed in the table. Then the following situation occurs. The call to persist(entity) is successfully, no exception is thrown. On leaving the ejb container and returning to tomact a commit is performed (it's a managed datasource, so container performs commit). This leads to the insert on database. This insert fails, a rollback is performed. On return to the JSF bean no exception can be seen by the bean. In the same class i have got a query method. If i replace the call to persist with the call to the query method everything works ok. The exception is thrown and is visible at the client site. This is the geronimo console output. The last line comes from the JSB bean which reports a successful insert. 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.1-r420667:592145 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy75.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54)
[jira] Created: (GERONIMO-3923) Login established without tomcat notification
Login established without tomcat notification - Key: GERONIMO-3923 URL: https://issues.apache.org/jira/browse/GERONIMO-3923 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.1, 2.0.2 Environment: Windows, Linux Reporter: Ralf Baumhof I have set up a security realm (sql realm). In web.xml tomcat is advised to keep a watch an all pages lying in directory /pages. I use a form login. If the login form is designed to use j_security_check action, the servlet authentication works. The first try to access a page in /pages/* area leads to the login form and after successful login the page is diplayed. However, the application has strong security impacts, so we would prefer to use a JSF backing bean which performs a LoginContext method for login to geronimo. This also works. The login succeeds and i get a principal. But the application is not logged in at tomcat webcontainer. It's not possible to access the pages in /pages/* area. Is this a bug or a feature What must be done if one want's to use the LoginContext way??? According to the geronimo wiki i suggest that it should work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ANN] Geronimo -ApacheDS plugin 1.0 released
We should be thanking you David, for your hard work to just get this done. Thanks, Alex On Mon, Mar 17, 2008 at 1:53 AM, David Jencks [EMAIL PROTECTED] wrote: The Geronimo team is pleased to announce the release of the Apache Geronimo - Apache Directory Server plugin 1.0 This plugin allows installing and running the ApacheDS server version 1.5.1 in an Apache Geronimo 2.1 server. The ApacheDS server can be configured through a server.xml file just as with a standalone server. This is the initial release of this plugin. Many thanks -The Geronimo team
Re: [ANN] Geronimo -ApacheDS plugin 1.0 released
David Jencks wrote: The Geronimo team is pleased to announce the release of the Apache Geronimo - Apache Directory Server plugin 1.0 This plugin allows installing and running the ApacheDS server version 1.5.1 in an Apache Geronimo 2.1 server. The ApacheDS server can be configured through a server.xml file just as with a standalone server. This is the initial release of this plugin. Many thanks -The Geronimo team Congrats !!! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Questions about release aftermath...
David Jencks wrote: The maven plugin release instructions I copied suggest... 14. Add the release to the next board report, in the private subversion area. 15. Add the release to the wiki, under the Recent Releases section of the front page and on the Releases page. These seem to me like a good idea but I have been stymied by not being able to find either one. Do we have a next board report? If so where is it? We have a Board Report section on the wiki, http://cwiki.apache.org/GMOxPMGT/apache-geronimo-board-reports.html Next report should be due by early April, we could add a new page now and start putting content there. Do we have a suitable recent releases section in the wiki? If so where is it? Not on the wiki but we should make some mention in the News section, Geronimo's web site front page. We should list there at least the ApacheDS plugin release, not too sure about Genesis and the specs. These last 2 would certainly not hurt there but we may need to add some description for each of these. Cheers! Hernan thanks david jencks
Re: [DISCUSS] Geronimo 2.1.1 release
Vasily Zakharov wrote: Another question I can remind of is in G2.0.2 we had tranql-connector-derby-embed-xa version 1.4, and in G2.1 it's version 1.3. Probably this should be corrected for G2.1.1. It looks like Donald updated these earlier this month. in branches/2.1 (2.1.1-SNAPSHOT). That did get me to check the other tranql-connector-* dependencies though for mysql, oracle, and postgresql. It looks to me like these are all now using the latest versions available. Thanks, Joe Vasily On Tue, Mar 11, 2008 at 6:53 PM, Joe Bohn [EMAIL PROTECTED] wrote: I think it's about time we got a 2.1.1 release out. The main motivation is to deliver a fix for the PortletSecurityException when using https on the admin console (https://issues.apache.org/jira/browse/GERONIMO-3855). but there are a lot of other fixes that have been integrated as well. The TCK looked good with a recent run ... so I think that should not be an issue. As far as snapshots go, it looks like we're now pulling in a snapshot for javamail that we would need to resolve (geronimo-javamail_1.4_mail-1.4-SNAPSHOT.jar). I think that's the only one. Are there any other changes/fixes that we should be looking to include prior to a release? I am willing to get my feet wet as the release manager unless somebody else wants to pick it up. Joe
Re: start-server command and default user credentials
On Sat, Mar 15, 2008 at 12:28 AM, Jason Dillon [EMAIL PROTECTED] wrote: On Mar 15, 2008, at 12:34 AM, Donald Woods wrote: Jarek Gawor wrote: Jason, I thought TCK was using the maven plugin to start the server. I'm not proposing to change that. But even if start-server command is used by TCK, I don't think that alone should dictate how the command should behave. I'm thinking what happens if you start any command in the background in a regular shell or even use geronimo.sh run or The --background option is not intended to behave like a shells operator... and some daemons do fork right away and return while the child continues, but other more robust daemons fork, then wait for the child to become booted, then return, so that any error status can be returned to the invoking shell for handling. IMO this is how Geronimo should behave... Adding a --wait or --nowait option might be useful, though I'd really like to solve the username/passwd problem... I think we need any anonymous way to query the status... Whether to poll and how to poll are two separate issues to me. I agree that we do need a way to anonymously query the status but I don't think we need to query the status in the normal/default case in the first place. When executing a script we'll need to know the status of the server and polling will be necessary but when starting the server in foreground polling is unnecessary. Jarek
Re: Upgrading Axis2 version / Geronimo's JAXWS 2.1 plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Geronimo folks, Any feedback? - -- dims Davanum Srinivas wrote: | Folks, | | At Axis2, we are trying to push out a 1.4 Release soon. Planning an RC1 | this weekend/monday. | | So questions, What's the plan to upgrade to JAXWS 2.1? I believe the cxf | folks are already at JAXWS 2.1. | | Could we please upgrade both (if not already) to get some TCK coverage | and make sure we fix anything that crops up by | the time we cut Axis2 1.4? | | thanks, | dims -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFH3oqDgNg6eWEDv1kRAkwdAKCRDKMcWRgo59VFuJ08KRC4AOL7NQCggrsC cQOddo7iHoJTx4AcONi1l5k= =FVvu -END PGP SIGNATURE-
Re: Upgrading Axis2 version / Geronimo's JAXWS 2.1 plan
Dims, It is my understanding that if we do upgrade to JAX-WS 2.1 we will be breaking Java EE 5 TCK (becuase there are some additional API in JAX-WS 2.1 / JAX-B 2.1). Also, since JAX-WS 2.1 requires JAX-B 2.1 and in Geronimo we use JAX-B in a bunch of components, upgrading them might take a little bit of time and effort to make sure everything still works as supposed to. Jarek On Thu, Mar 13, 2008 at 10:24 PM, Davanum Srinivas [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, At Axis2, we are trying to push out a 1.4 Release soon. Planning an RC1 this weekend/monday. So questions, What's the plan to upgrade to JAXWS 2.1? I believe the cxf folks are already at JAXWS 2.1. Could we please upgrade both (if not already) to get some TCK coverage and make sure we fix anything that crops up by the time we cut Axis2 1.4? thanks, dims -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFH2eHUgNg6eWEDv1kRAkcCAKCJHdRVrvq7eQXDYQdzVk5RaoHoqgCfYzUj wH0CdAi/fLegy77jrcprAnM= =b9Xg -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Geronimo 2.1 samples - zip files
On Thu, Mar 13, 2008 at 4:15 PM, Joe Bohn [EMAIL PROTECTED] wrote: Donald Woods wrote: User wouldn't have to build anything if each sample was a plug-in That would be true if the value in a sample just in running it. However, I think most users want to dig into the source, make minor changes and tweak it as a way to jump start their own development. Sometime they are more interested in looking at the geronimo deployment plans and experimenting with different deploy options. For those types of activities, they would need more than just a plugin ... they would need the source, build poms, ears/wars, deployment plans, etc I agree with Joe. Maybe we should agree/decide on who is the target audience of these samples. For example, if average developers is the target audience then they should be able to use svn/cvs and therefore there should be no need for these zip files. However, if we expect the target audience not to know how to use svn then I guess we would need to provide those zip files. But if we do provide them, we must make it so it is extremely easy to (re)generate them. Jarek
[jira] Assigned: (GERONIMO-3923) Login established without tomcat notification
[ https://issues.apache.org/jira/browse/GERONIMO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-3923: -- Assignee: David Jencks Login established without tomcat notification - Key: GERONIMO-3923 URL: https://issues.apache.org/jira/browse/GERONIMO-3923 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.1 Environment: Windows, Linux Reporter: Ralf Baumhof Assignee: David Jencks I have set up a security realm (sql realm). In web.xml tomcat is advised to keep a watch an all pages lying in directory /pages. I use a form login. If the login form is designed to use j_security_check action, the servlet authentication works. The first try to access a page in /pages/* area leads to the login form and after successful login the page is diplayed. However, the application has strong security impacts, so we would prefer to use a JSF backing bean which performs a LoginContext method for login to geronimo. This also works. The login succeeds and i get a principal. But the application is not logged in at tomcat webcontainer. It's not possible to access the pages in /pages/* area. Is this a bug or a feature What must be done if one want's to use the LoginContext way??? According to the geronimo wiki i suggest that it should work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3923) Login established without tomcat notification
[ https://issues.apache.org/jira/browse/GERONIMO-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579503#action_12579503 ] David Jencks commented on GERONIMO-3923: Could you please ask about this on the user mailing list? So far you haven't described anything that looks like a bug to me. JavaEE security is designed for the container to do the login, not the application, so its not too surprising that having your application do the login doesn't work. In your post please describe the jsf bean code, whether you wrote it and have control over it, and where you are looking in the wiki. I think I may have dealt with a similar issue once integrating the jetspeed 2 portal. Hopefully we will be able to find a solution that is consistent with javaee and does what you need. Login established without tomcat notification - Key: GERONIMO-3923 URL: https://issues.apache.org/jira/browse/GERONIMO-3923 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.1 Environment: Windows, Linux Reporter: Ralf Baumhof Assignee: David Jencks I have set up a security realm (sql realm). In web.xml tomcat is advised to keep a watch an all pages lying in directory /pages. I use a form login. If the login form is designed to use j_security_check action, the servlet authentication works. The first try to access a page in /pages/* area leads to the login form and after successful login the page is diplayed. However, the application has strong security impacts, so we would prefer to use a JSF backing bean which performs a LoginContext method for login to geronimo. This also works. The login succeeds and i get a principal. But the application is not logged in at tomcat webcontainer. It's not possible to access the pages in /pages/* area. Is this a bug or a feature What must be done if one want's to use the LoginContext way??? According to the geronimo wiki i suggest that it should work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3924) Make car-maven-plugin assembly independent of tools-maven-plugin
Make car-maven-plugin assembly independent of tools-maven-plugin Key: GERONIMO-3924 URL: https://issues.apache.org/jira/browse/GERONIMO-3924 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: David Jencks Fix For: 2.1.1, 2.2 In order to get the car-maven-plugin to assemble a server you need to set up the extensions from the tools-maven-plugin even if you aren't using it for anything else. Maybe there's some maven config in the tools-maven-plugin that could be moved? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3924) Make car-maven-plugin assembly independent of tools-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579513#action_12579513 ] Jason Dillon commented on GERONIMO-3924: Probably best to drop use of the application-assembly packaging (which is from tools-m-p) and just use jar. Make car-maven-plugin assembly independent of tools-maven-plugin Key: GERONIMO-3924 URL: https://issues.apache.org/jira/browse/GERONIMO-3924 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: David Jencks Fix For: 2.1.1, 2.2 In order to get the car-maven-plugin to assemble a server you need to set up the extensions from the tools-maven-plugin even if you aren't using it for anything else. Maybe there's some maven config in the tools-maven-plugin that could be moved? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3799) incorrect connect time computation in TimeMonitor
[ https://issues.apache.org/jira/browse/GERONIMO-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee closed GERONIMO-3799. - incorrect connect time computation in TimeMonitor - Key: GERONIMO-3799 URL: https://issues.apache.org/jira/browse/GERONIMO-3799 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Attachments: GERONIMO-3799.patch A bug in TimeMonitor.notification() causes incorrect connect time computation. Connect start time is set only if you're opening a new connection. If a connection is reused, then connect start time is cleared (i.e. reset to 0). In TimeMonitor, one should check to see connect start time is set before recording the connect time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3751) callbacks may not be completed when caller uses future.get() too to complete request handling
[ https://issues.apache.org/jira/browse/GERONIMO-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee closed GERONIMO-3751. - callbacks may not be completed when caller uses future.get() too to complete request handling - Key: GERONIMO-3751 URL: https://issues.apache.org/jira/browse/GERONIMO-3751 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Priority: Minor Attachments: GERONIMO-3751.patch Currently the callback methods from AsyncHttpClientCallback get called *after* the response future object is completed. I think this causes a subtle bug that may prevent the callback methods from being completed if one uses both the callback and the future. For example, consider the following case: ResponseFuture future = client.invoke(..., callback); // callback is not null HttpResponseMessage response = future.get(); // this blocks until future is complete Since the future is completed before the callback is invoked, the caller thread in this case gets unblocked before the callback is called. If the caller thread goes away, then there is possibility that the callback may not be completed or may not even be called, depending on the timing. This strikes me as a bug... I propose we invoke the callback first and then complete the future so the callbacks are guaranteed to be completed even if future is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3860) HttpResponseDecoder does not handle folded headers properly
[ https://issues.apache.org/jira/browse/GERONIMO-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee closed GERONIMO-3860. - HttpResponseDecoder does not handle folded headers properly --- Key: GERONIMO-3860 URL: https://issues.apache.org/jira/browse/GERONIMO-3860 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Priority: Minor Attachments: GERONIMO-3860.patch HttpResponseDecoder makes an assumption that headers complete in a single line ended by CRLF. The HTTP RFC (along with RFC 822) permits a single header spanning multiple lines. Such folding can be detected by detecting the leading LWSP char (either a space or a horizontal tab). HttpResponseDecoder needs to handle this properly. Currently it throws a ProtocolDecoderException (StringIndexOutOfBoundsException underneath). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3862) header names are handled in a case-sensitive manner
[ https://issues.apache.org/jira/browse/GERONIMO-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee closed GERONIMO-3862. - header names are handled in a case-sensitive manner --- Key: GERONIMO-3862 URL: https://issues.apache.org/jira/browse/GERONIMO-3862 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: GERONIMO-3862.patch The HTTP header names are supposed to be case-insensitive. When we get or remove headers, however, header names are used in a case sensitive manner. It should be made case-insensitive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3846) cookies are not carried over when requests are redirected
[ https://issues.apache.org/jira/browse/GERONIMO-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee closed GERONIMO-3846. - cookies are not carried over when requests are redirected - Key: GERONIMO-3846 URL: https://issues.apache.org/jira/browse/GERONIMO-3846 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Priority: Minor Attachments: GERONIMO-3846.patch When you send a request and receive a redirect response (301 or 302), the response may contain cookies (via Set-Cookie header). For subsequent redirect requests, these cookies need to be sent. Currently AHC does not send any cookies unless explicitly set by the caller. Two cases where this should be done are redirects and auth challenges. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3861) cookies need to be validated and filtered
[ https://issues.apache.org/jira/browse/GERONIMO-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee closed GERONIMO-3861. - cookies need to be validated and filtered - Key: GERONIMO-3861 URL: https://issues.apache.org/jira/browse/GERONIMO-3861 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Priority: Minor Attachments: GERONIMO-3861-v2.patch, GERONIMO-3861.patch Today AHC simply accepts all cookies from the response and emit all cookies in the request. However, the attributes need to be taken into consideration when we set the cookies as well as when we send them. Two parts of the issue: [1] When we emit the cookies in the request, we need to check - if the domain matches - if the path matches - if the cookie has not expired - and if the cookie is secure (if the request protocol is http) before adding it to the Cookie header. [2] When we accept the cookies in the response, we need to check for the domain and the path. Note that we do not discard expired cookies, as that's often a way to delete an existing cookie. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3857) response header parsing is done incorrectly
[ https://issues.apache.org/jira/browse/GERONIMO-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee closed GERONIMO-3857. - response header parsing is done incorrectly --- Key: GERONIMO-3857 URL: https://issues.apache.org/jira/browse/GERONIMO-3857 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: GERONIMO-3857.patch When we decode response headers, HttpDecoder separates name from value using : (note the *single*space after the colon). This is incorrect. The HTTP spec says - The field value MAY be preceded by any amount of LWS, though a single SP is preferred. The separator pattern should be simply :. Then any preceding or trailing LWSP characters (SP or HT) should be removed from the value. This is a rather critical issue. I had headers like Server: Foo Content-Length:62 Connection: close (notice lack of space after Content-Length:) HttpResponseDecoder cannot properly parse the above headers, and throws a StringIndexOutOfBoundsException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3872) proxy connect for https tunneling times out
[ https://issues.apache.org/jira/browse/GERONIMO-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee closed GERONIMO-3872. - proxy connect for https tunneling times out --- Key: GERONIMO-3872 URL: https://issues.apache.org/jira/browse/GERONIMO-3872 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Attachments: GERONIMO-3872.patch Proxy connect requests (for handling SSL tunneling) are timing out. This is a bug introduced when we started handling terminating response message bodies when servers close connections. Responses to proxy connect requests are 200 responses, but they often do not have any headers including Content-Length. The following is one example of such a response: HTTP/1.1 200 Connection established\r\n \r\n But the server keeps the connection alive for SSL tunneling. If Content-Length is not specified, the response decoder will keep trying to read the response until the connection is closed, which will not happen in this case. Eventually the connection will time out and the connect handshake ends up failing. The response decoder needs to be smarter about cases where no content is expected. Such cases include - certain response status codes (204 and 304) - Content-Length: 0 explicitly specified - proxy connect responses In these cases, the response decoder should recognize it and finish decoding immediately. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3877) AsyncHttpClient should provide a method that returns monitoring listeners
[ https://issues.apache.org/jira/browse/GERONIMO-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee closed GERONIMO-3877. - AsyncHttpClient should provide a method that returns monitoring listeners - Key: GERONIMO-3877 URL: https://issues.apache.org/jira/browse/GERONIMO-3877 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Priority: Minor Attachments: GERONIMO-3877.patch Currently AsyncHttpClient lacks a method that returns monitoring listeners that are registered on it. This is something it should support... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3889) HttpIoHandler shuts down the scheduled executor service even if it is passed in by caller
[ https://issues.apache.org/jira/browse/GERONIMO-3889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee closed GERONIMO-3889. - HttpIoHandler shuts down the scheduled executor service even if it is passed in by caller - Key: GERONIMO-3889 URL: https://issues.apache.org/jira/browse/GERONIMO-3889 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Affects Versions: 1.x Reporter: Sangjin Lee Assignee: Rick McGuire Priority: Minor Attachments: GERONIMO-3889.patch HttpIoHandler uses a scheduled executor service to handle timing out requests. It can either take one from the caller, or it will create one by itself. Therefore, the ownership becomes confusing if the caller passes in one. This effectively prevents multiple instances of AsyncHttpClient from sharing a single scheduled executor service. It should allow them to share a scheduled executor service. I'll see if I can come up with a good way to address this... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3719) Monitoring agent uses sun classes
[ https://issues.apache.org/jira/browse/GERONIMO-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig resolved GERONIMO-3719. - Resolution: Fixed Committed revision 638039 to trunk, revision 638040 to branches/2.1 to remove remnants. Will open new jira for further tweaks Monitoring agent uses sun classes - Key: GERONIMO-3719 URL: https://issues.apache.org/jira/browse/GERONIMO-3719 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1, 2.1.1, 2.2 Reporter: David Jencks Assignee: Viet Hung Nguyen Fix For: 2.1.1, 2.2 SnapshotConfigXMLBuilder uses a couple sun classes to write out xml. This doesn't work on non-sun jvms. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3925) Monitoring agent should use JAXB to do XML manipulation
Monitoring agent should use JAXB to do XML manipulation --- Key: GERONIMO-3925 URL: https://issues.apache.org/jira/browse/GERONIMO-3925 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1.1, 2.2 Reporter: Erik B. Craig xmlbeans is currently used to write out the xml in the monitoring agent. JAXB should be used to manipulation XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3926) Add a Derby config/plugin for easier inclusion of Derby jars without a system-database depend
Add a Derby config/plugin for easier inclusion of Derby jars without a system-database depend - Key: GERONIMO-3926 URL: https://issues.apache.org/jira/browse/GERONIMO-3926 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.1, 2.0.x, 2.1.1, 2.2 Reporter: Donald Woods Assignee: Donald Woods Priority: Minor Fix For: 2.1.1, 2.2 Create a config/plugin similar to the Spring CAR which can be used to easily include the Derby jarfiles in a minimal assembly or application without pulling in the system-database CAR. Will update the system-database, geronimo-derby and geronimo-timer to include a depend on this new CAR, instead of listing specific Derby jarfile depends. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579576#action_12579576 ] David Jencks commented on GERONIMO-3907: I wasn't suggesting that flush was a solution, just a temporary workaround. Preliminary investigation suggests that there may be a problem with org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction. Hopefully we can investigate and fix this shortly. IIRC the spec rules about what to do in this situation are a little hard to understand. Persistence Exception is not visible/lost for client. -- Key: GERONIMO-3907 URL: https://issues.apache.org/jira/browse/GERONIMO-3907 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0.2, 2.1 Environment: Linux, Windows Reporter: Ralf Baumhof Priority: Blocker Original Estimate: 0.08h Remaining Estimate: 0.08h I am trying an insert on a table. The Entity class is wrong annotated, one column was renamed in the table. Then the following situation occurs. The call to persist(entity) is successfully, no exception is thrown. On leaving the ejb container and returning to tomact a commit is performed (it's a managed datasource, so container performs commit). This leads to the insert on database. This insert fails, a rollback is performed. On return to the JSF bean no exception can be seen by the bean. In the same class i have got a query method. If i replace the call to persist with the call to the query method everything works ok. The exception is thrown and is visible at the client site. This is the geronimo console output. The last line comes from the JSB bean which reports a successful insert. 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.1-r420667:592145 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy75.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at
[jira] Closed: (GERONIMO-3926) Add a Derby config/plugin for easier inclusion of Derby jars without a system-database depend
[ https://issues.apache.org/jira/browse/GERONIMO-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-3926. -- Resolution: Fixed Committed in branches/2.1 as Rev638049 Committed in trunk as Rev638053 Add a Derby config/plugin for easier inclusion of Derby jars without a system-database depend - Key: GERONIMO-3926 URL: https://issues.apache.org/jira/browse/GERONIMO-3926 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Donald Woods Assignee: Donald Woods Priority: Minor Fix For: 2.1.1, 2.2 Create a config/plugin similar to the Spring CAR which can be used to easily include the Derby jarfiles in a minimal assembly or application without pulling in the system-database CAR. Will update the system-database, geronimo-derby and geronimo-timer to include a depend on this new CAR, instead of listing specific Derby jarfile depends. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] branches/2.1: Failed for Revision: 637992
Geronimo Revision: 637992 built with tests included See the full build-1400.log file at http://geronimo.apache.org/maven/server/binaries/2.1/20080317/build-1400.log Download the binaries from http://geronimo.apache.org/maven/server/binaries/2.1/20080317 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 32 minutes 11 seconds [INFO] Finished at: Mon Mar 17 14:49:21 EDT 2008 [INFO] Final Memory: 302M/981M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://geronimo.apache.org/maven/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/2.1/20080317/logs-1400-tomcat/test.log Assembly: jetty = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/2.1/20080317/logs-1400-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 74.188 sec FAILURE! Samples: branches/2.1 = Log: http://geronimo.apache.org/maven/server/binaries/2.1/20080317/samples-1400.log Build status: OK
[jira] Commented: (GERONIMO-3856) Assemble a Server Confirmation Page
[ https://issues.apache.org/jira/browse/GERONIMO-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579585#action_12579585 ] Joseph Leong commented on GERONIMO-3856: Testing patch on a windows deployed AG to verify 3) before posting patch. -Joseph Leong Assemble a Server Confirmation Page --- Key: GERONIMO-3856 URL: https://issues.apache.org/jira/browse/GERONIMO-3856 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Improvements for the Assemble a Server Confirmation Page 1) At minimum the user should provide an artifact id otherwise assembly named --bin.tar.gz will be created. The portlet should check for empty artifact id. 2) If no plugins are selected and 'assemble' button is pressed a nasty exception will be displayed. The portlet should check if at least one plugin was selected. 3) On the confirmation screen and on Windows the server path location will contain / and \. For example c:\geronimo/var/temp/foo.tar.gz. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3927) Plugin installer can't unpack much from jars
Plugin installer can't unpack much from jars Key: GERONIMO-3927 URL: https://issues.apache.org/jira/browse/GERONIMO-3927 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.1, 2.1.1, 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1.1, 2.2 the plugin installer can only unpack everything from a (packed) jar, not fish around inside for directories or individual files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3927) Plugin installer can't unpack much from jars
[ https://issues.apache.org/jira/browse/GERONIMO-3927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3927. -- Resolution: Fixed It appears that the ZipEntry code cannot distinguish between a file and an empty directory !!! Aside from this truly amazing problem, implemented in rev 638129 for trunk and rev 638131 for branches/2.1 So, you can't copy an empty directory out of a jar file. Plugin installer can't unpack much from jars Key: GERONIMO-3927 URL: https://issues.apache.org/jira/browse/GERONIMO-3927 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1, 2.1.1, 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1.1, 2.2 the plugin installer can only unpack everything from a (packed) jar, not fish around inside for directories or individual files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3924) Make car-maven-plugin assembly independent of tools-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3924. -- Resolution: Fixed Assignee: David Jencks Added some lifecycle configuration similar to what's in the tools-maven-plugin to the car-maven-plugin but adapted to the car-maven-plugin. Modified the assembly archetype a little bit to match. So the big change is there is a server-lifecycle packaging that automatically calls the appropriate car-maven-plugin mojos without any configuration. However you still need to configure the server-instances somewhere in the ancestry of the pom. trunk rev 638137. branches 2.1 rev 638148 Make car-maven-plugin assembly independent of tools-maven-plugin Key: GERONIMO-3924 URL: https://issues.apache.org/jira/browse/GERONIMO-3924 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1.1, 2.2 In order to get the car-maven-plugin to assemble a server you need to set up the extensions from the tools-maven-plugin even if you aren't using it for anything else. Maybe there's some maven config in the tools-maven-plugin that could be moved? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3924) Make car-maven-plugin assembly independent of tools-maven-plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579678#action_12579678 ] David Jencks commented on GERONIMO-3924: btw jar packaging didn't work for reasons I couldn't discern. It looked like the empty output jar was added to the dependencies before the install modules mojo was called ??? Anyway having a custom lifecycle allows no-config assembiles so IMO its a good idea anyway. Make car-maven-plugin assembly independent of tools-maven-plugin Key: GERONIMO-3924 URL: https://issues.apache.org/jira/browse/GERONIMO-3924 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1.1, 2.2 In order to get the car-maven-plugin to assemble a server you need to set up the extensions from the tools-maven-plugin even if you aren't using it for anything else. Maybe there's some maven config in the tools-maven-plugin that could be moved? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3907) Persistence Exception is not visible/lost for client.
[ https://issues.apache.org/jira/browse/GERONIMO-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579679#action_12579679 ] David Jencks commented on GERONIMO-3907: Looks like EJB 3 core spec 14.3.10 says we should be throwing an EJBException or maybe RemoteException here. See https://issues.apache.org/jira/browse/OPENEJB-782. Persistence Exception is not visible/lost for client. -- Key: GERONIMO-3907 URL: https://issues.apache.org/jira/browse/GERONIMO-3907 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0.2, 2.1 Environment: Linux, Windows Reporter: Ralf Baumhof Priority: Blocker Original Estimate: 0.08h Remaining Estimate: 0.08h I am trying an insert on a table. The Entity class is wrong annotated, one column was renamed in the table. Then the following situation occurs. The call to persist(entity) is successfully, no exception is thrown. On leaving the ejb container and returning to tomact a commit is performed (it's a managed datasource, so container performs commit). This leads to the insert on database. This insert fails, a rollback is performed. On return to the JSF bean no exception can be seen by the bean. In the same class i have got a query method. If i replace the call to persist with the call to the query method everything works ok. The exception is thrown and is visible at the client site. This is the geronimo console output. The last line comes from the JSB bean which reports a successful insert. 11:58:04,390 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.1-r420667:592145 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2107) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1954) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1852) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1770) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:141) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy75.anlegenBenutzer(Unknown Source) at de.nrw.hagen.ggrz.benutzer.controler.BenutzerControler.anlegenBenutzer(BenutzerControler.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.el.parser.AstValue.invoke(AstValue.java:131) at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276) at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68) at javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75) at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54) at javax.faces.component.UICommand.broadcast(UICommand.java:121)
geronimo-web.xml for geronimo 2.0.1
I am a beginner with Geronimo and would like to know the different steps that needs to be followed while writing my first geronimo-web.xml While I was searching for some samples on the net, I came across several elements in geronimo-web.xml, which was quite confusing to me, like environment, moduleId and artifactId. I had mentioned context-root for my application, but is that alone not enough for my application to be deployed and run? Please do help me in this regard with a suitable reply. Thanks Remya -- View this message in context: http://www.nabble.com/geronimo-web.xml-for-geronimo-2.0.1-tp16111044s134p16111044.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Fw: [VOTE]: Pluto 1.1.5 Release
Should we investigate the below release for trunk and a future 2.1.2 release?
-Donald
- Forwarded Message
From: Elliot Metsger [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 17, 2008 9:47:30 AM
Subject: Re: [VOTE]: Pluto 1.1.5 Release
+1
Thanks Craig :)
cdoremus wrote:
+1
Thanks for taking the lead on this release, Elliot.
/Craig
Elliot Metsger-3 wrote:
The Pluto 1.1.5 test build has been cut and is available as indicated
below. Many thanks to community for finding bugs, supplying patches,
and implementing improvments!
No determination as to the quality ('alpha,' 'beta,' or 'GA') of Pluto
1.1.5 has been made, and at this time it is simply a test build.
The results of this vote will be posted no earlier than 76 hours from
the time this email is sent. 3 +1 votes from Apache Portals PMC members
will be required to meet quorum, but all community members (committers,
contributors, and users) are invited to vote. We welcome any comments
you may have, and will take all feedback into account.
Distribution:
* http://people.apache.org/builds/portals-pluto/
Maven 2 staging repository:
* http://people.apache.org/builds/portals-pluto/m2-staging-repository/
Release Notes:
Bug
* [PLUTO-356] - Pluto Driver not using injected Portal URL Parser
* [PLUTO-361] - Error when parsing the portal url
* [PLUTO-397] - Copyright at bottom of Portal Driver content needs
to be updated to 2007
* [PLUTO-399] - Link and documentation on source-repository.html
page is incorrect
* [PLUTO-421] - PortletRequest.getParameterMap() must return an
unmodifiable map (PLT.11.1.1)
* [PLUTO-439] - Assembly code cannot parse Servlet 2.4 web.xml
containing jsp-config tags
* [PLUTO-446] - No way to set default page encoding for Pluto
* [PLUTO-447] - Old version of junit included via commons-cli in
pluto-util
* [PLUTO-448] - No way to know if expiration cache value was set
via PortletDD
* [PLUTO-449] - portlet-skin.jsp does not have the JSTL core taglib
directive
* [PLUTO-450] - ExternalAppScopedAttributeTest.jsp has a minor
javascript error
* [PLUTO-451] - JSP21ExpressionEvaluatorProxy is causing an
exception in Tomcat 6.0 if compiled using JDK 5.0
* [PLUTO-452] - Assembler ant task fails on WAR with no manifest
* [PLUTO-455] - Assembler emitts non-validating web.xml for servlet
2.3 and 2.4
* [PLUTO-457] - PortletContainerException doesn't chain Throwable
* [PLUTO-460] - PortletPreferenceDD doesn't descriminate between no
(null) values and empty values (new String[0])
* [PLUTO-461] - AbstractVersionedWebAppDescriptorTest based tests
may fails based on available XML libraries
* [PLUTO-462] - isPortletModeAllowed and isWindowStateAllowed do
case-sensitve checks
* [PLUTO-473] - XML Schema Location for
pluto-portal-driver-config.xsd points to obsolete schema definition
* [PLUTO-474] - CLONE -portlet session should not be invalidated
when lastAccessedTime is 0
* [PLUTO-475] - Default Portlet Skin and WindowStateAnchorTag emit
invalid markup
Improvement
* [PLUTO-360] - FileAssemblerTest cannot be executed offline
* [PLUTO-394] - o.a.p.tags.el.ParamTag does not evaluate EL on
name attribute
* [PLUTO-417] - PortletResponseImpl doesn't allow wsrp rewrite urls
* [PLUTO-456] - fix line endings on files.
* [PLUTO-458] - Improve exception handling with
AbstractCastorDescriptorService
* [PLUTO-465] - Automatic determination of JAXP usage
* [PLUTO-472] - Fix Pluto Maven 2 release assemblies so they
actually work.
[jira] Created: (GERONIMO-3928) Exception on stopping server after sending a non persistent message
Exception on stopping server after sending a non persistent message --- Key: GERONIMO-3928 URL: https://issues.apache.org/jira/browse/GERONIMO-3928 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ Reporter: Anish Pathadan Fix For: 2.2 Hi, I am getting the following exception on stopping the server after sending a non persistent message to a queue. I have attached a test case for this. Steps to reproduce the issue:- 1).Deploy the attached sendMessage.war 2).Access http://localhost:8080/sendMessage/SendMessage to send a non persistent message. 3).Stop the server using Ctrl-C Following is the stack trace 07:39:08,828 WARN [ActiveMQManagedConnection] Connection failed: javax.jms.JMSE xception: java.io.EOFException 07:39:08,843 WARN [GeronimoConnectionEventListener] connectionErrorOccurred cal led with null javax.jms.JMSException: java.io.EOFException at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSuppo rt.java:46) at org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConne ction.java:1519) at org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection .java:1535) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.ResponseCorrelator.onException(Response Correlator.java:114) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.WireFormatNegotiator.onException(WireFo rmatNegotiator.java:147) at org.apache.activemq.transport.InactivityMonitor.onException(Inactivit yMonitor.java:150) at org.apache.activemq.transport.TransportSupport.onException(TransportS upport.java:97) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java: 150) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:358) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat. java:267) at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTranspo rt.java:156) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java: 136) ... 1 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3928) Exception on stopping server after sending a non persistent message
[ https://issues.apache.org/jira/browse/GERONIMO-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anish Pathadan updated GERONIMO-3928: - Attachment: sendMessage.war Exception on stopping server after sending a non persistent message --- Key: GERONIMO-3928 URL: https://issues.apache.org/jira/browse/GERONIMO-3928 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Reporter: Anish Pathadan Fix For: 2.2 Attachments: sendMessage.war Hi, I am getting the following exception on stopping the server after sending a non persistent message to a queue. I have attached a test case for this. Steps to reproduce the issue:- 1).Deploy the attached sendMessage.war 2).Access http://localhost:8080/sendMessage/SendMessage to send a non persistent message. 3).Stop the server using Ctrl-C Following is the stack trace 07:39:08,828 WARN [ActiveMQManagedConnection] Connection failed: javax.jms.JMSE xception: java.io.EOFException 07:39:08,843 WARN [GeronimoConnectionEventListener] connectionErrorOccurred cal led with null javax.jms.JMSException: java.io.EOFException at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSuppo rt.java:46) at org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConne ction.java:1519) at org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection .java:1535) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.ResponseCorrelator.onException(Response Correlator.java:114) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.TransportFilter.onException(TransportFi lter.java:96) at org.apache.activemq.transport.WireFormatNegotiator.onException(WireFo rmatNegotiator.java:147) at org.apache.activemq.transport.InactivityMonitor.onException(Inactivit yMonitor.java:150) at org.apache.activemq.transport.TransportSupport.onException(TransportS upport.java:97) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java: 150) at java.lang.Thread.run(Thread.java:595) Caused by: java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:358) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat. java:267) at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTranspo rt.java:156) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java: 136) ... 1 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
