[jira] Updated: (GERONIMO-3819) Update JMS Resources Portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anish Pathadan updated GERONIMO-3819: - Attachment: JMS Resource Portlet_Main.jpg Main JMS Resource portlet.For Queues three new actions has been added (Browse,Send,Purge). For Topic one new action Send is added. Update JMS Resources Portlet Key: GERONIMO-3819 URL: https://issues.apache.org/jira/browse/GERONIMO-3819 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Reporter: Anish Pathadan Assignee: Anish Pathadan Attachments: JMS Resource Portlet_Main.jpg, JMSResource_portlet_1.0.patch Update the JMS Resources portlet to include the following information from the JMS Provider 1.Count of messages send to each queue/topic ,pending messages 2.Option to send messages to messages to particular queues/topics 3.Purge messages from queues/topics 4.Browse and send messages to queues/topics -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3819) Update JMS Resources Portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anish Pathadan updated GERONIMO-3819: - Attachment: Browse Messages.jpg This screen will show message properties like Priority,Message Id,Destination Physical Name,Time Stamp,Message Type,Correlation Id etc. for all the message in the selected Queue. Update JMS Resources Portlet Key: GERONIMO-3819 URL: https://issues.apache.org/jira/browse/GERONIMO-3819 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Reporter: Anish Pathadan Assignee: Anish Pathadan Attachments: Browse Messages.jpg, JMS Resource Portlet_Main.jpg, JMSResource_portlet_1.0.patch Update the JMS Resources portlet to include the following information from the JMS Provider 1.Count of messages send to each queue/topic ,pending messages 2.Option to send messages to messages to particular queues/topics 3.Purge messages from queues/topics 4.Browse and send messages to queues/topics -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3819) Update JMS Resources Portlet
[
https://issues.apache.org/jira/browse/GERONIMO-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573702#action_12573702
]
Vamsavardhana Reddy commented on GERONIMO-3819:
---
Anish,
A few comments on the patch. Use proper source code formatting (no tabs etc.),
add svn properties for the newly added files. Use resource bundles for all
field names shown in the JSPs.
Also, I am getting an exception when I shutdown the server after sending
messages to a topic. stack trace is given below.
{code}
17:11:06,406 WARN [[/activemq]] Cannot serialize session attribute javax.portle
t.p./activemq.JMSWizard!1082939780|0?messages for session 77583B5E383183289B0443
5198BFD4D2
java.io.NotSerializableException: org.apache.activemq.command.ActiveMQTextMessag
e
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at java.util.ArrayList.writeObject(ArrayList.java:569)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:91
7)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:13
39)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.jav
a:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at org.apache.catalina.session.StandardSession.writeObject(StandardSessi
on.java:1515)
at org.apache.catalina.session.StandardSession.writeObjectData(StandardS
ession.java:959)
at org.apache.catalina.session.StandardManager.doUnload(StandardManager.
java:517)
at org.apache.catalina.session.StandardManager.unload(StandardManager.ja
va:463)
at org.apache.catalina.session.StandardManager.stop(StandardManager.java
:667)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:45
31)
at org.apache.geronimo.tomcat.GeronimoStandardContext.kill(GeronimoStand
ardContext.java:238)
at org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContai
ner.java:370)
at org.apache.geronimo.tomcat.TomcatWebAppContext.doStop(TomcatWebAppCon
text.java:529)
at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBean
Instance.java:1161)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(
GBeanInstanceState.java:339)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan
ceState.java:188)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja
va:563)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja
va:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan
ceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja
va:563)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja
va:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan
ceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja
va:563)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja
va:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan
ceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja
va:563)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja
va:423)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan
ceState.java:180)
at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja
va:563)
at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja
va:423)
at org.apache.geronimo.kernel.config.KernelConfigurationManager$Shutdown
Hook.run(KernelConfigurationManager.java:316)
at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(Basi
cKernel.java:668)
at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.jav
a:645)
at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper$1.run(M
ainConfigurationBootstrapper.java:76)
17:11:16,125 WARN [ActiveMQManagedConnection] Connection failed: javax.jms.JMSE
xception: java.io.EOFException
17:11:16,125 WARN [GeronimoConnectionEventListener] connectionErrorOccurred cal
led with null
javax.jms.JMSException: java.io.EOFException
at
[jira] Updated: (GERONIMO-3819) Update JMS Resources Portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anish Pathadan updated GERONIMO-3819: - Attachment: Send Message.jpg Use this portlet to send text messages to the selected queue/Topic.. Update JMS Resources Portlet Key: GERONIMO-3819 URL: https://issues.apache.org/jira/browse/GERONIMO-3819 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: console Reporter: Anish Pathadan Assignee: Anish Pathadan Attachments: Browse Messages.jpg, JMS Resource Portlet_Main.jpg, JMSResource_portlet_1.0.patch, Send Message.jpg Update the JMS Resources portlet to include the following information from the JMS Provider 1.Count of messages send to each queue/topic ,pending messages 2.Option to send messages to messages to particular queues/topics 3.Purge messages from queues/topics 4.Browse and send messages to queues/topics -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [discuss] How do we improve the user experience of the geronimo server?
Some automated testcases which will make sure Admin Console portlets are not broken: (the ones I can think of immediately from a Deployment perspective:) 1) DB Manager 2) Database Pools 3) Security Realms 4) JMS Resources 5) Plan Creator -- Thanks, Shiva On Wed, Feb 27, 2008 at 2:14 AM, Lin Sun [EMAIL PROTECTED] wrote: Hi, I am interested in collecting ideas on how we can improve user experience with the geronimo 2.x server, particularly, what type of testing we can do for each geronimo major release to identify probs and resolve them. I think it would be nice to have a set of test (either automated or manually) other than tck that we run to verify various functions in geronimo for each major release. Currently, we probably only run a very small amount of testing other than tck, our automated testing during the build and the few samples we have. One thought is to add more test samples. Seems to me people are trying different things with geronimo server and most of the stuff they tried are not covered by our samples.Any ideas what other samples may be good to work with geronimo? The other thought is to grow test cases from our JIRA system or users. Encourage folks to attach/contribute their test cases. Also, what g functions do folks think we need more testing? Thanks, Lin
Re: [discuss] How do we improve the user experience of the geronimo server?
I think we should be able to use Selenium IDE to record a trip through these processes and then insert the recording into testcases in the test suite. Anyone care to investigate? thanks david jencks On Feb 29, 2008, at 6:42 AM, Vamsavardhana Reddy wrote: That reminds me... Security realms portlet is broken yet again. Editing a realm does not work :( ++Vamsi On Fri, Feb 29, 2008 at 8:05 PM, Shiva Kumar H R [EMAIL PROTECTED] wrote: Some automated testcases which will make sure Admin Console portlets are not broken: (the ones I can think of immediately from a Deployment perspective:) 1) DB Manager 2) Database Pools 3) Security Realms 4) JMS Resources 5) Plan Creator -- Thanks, Shiva On Wed, Feb 27, 2008 at 2:14 AM, Lin Sun [EMAIL PROTECTED] wrote: Hi, I am interested in collecting ideas on how we can improve user experience with the geronimo 2.x server, particularly, what type of testing we can do for each geronimo major release to identify probs and resolve them. I think it would be nice to have a set of test (either automated or manually) other than tck that we run to verify various functions in geronimo for each major release. Currently, we probably only run a very small amount of testing other than tck, our automated testing during the build and the few samples we have. One thought is to add more test samples. Seems to me people are trying different things with geronimo server and most of the stuff they tried are not covered by our samples.Any ideas what other samples may be good to work with geronimo? The other thought is to grow test cases from our JIRA system or users. Encourage folks to attach/contribute their test cases. Also, what g functions do folks think we need more testing? Thanks, Lin
[jira] Reopened: (GERONIMO-3880) PersistenceUnitInfo.getJarFileUrls() can return null
[ https://issues.apache.org/jira/browse/GERONIMO-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reopened GERONIMO-3880: Due to the same original refactoring we are also often supplying a null persistenceUnitRoot url. PersistenceUnitInfo.getJarFileUrls() can return null Key: GERONIMO-3880 URL: https://issues.apache.org/jira/browse/GERONIMO-3880 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0.x, 2.1.1, 2.2 Hibernate doesn't like null from PersistenceUnitInfo.getJarFileUrls(), see patch proposed in http://cwiki.apache.org/GMOxSAMPLES/running-jboss-seam-200ga-on-geronimo-21.html While we can argue hibernate should check for null, we shouldn't be supplying null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Entropy, or the heat death of the geronimo code base
On Feb 28, 2008, at 6:07 PM, David Jencks wrote: A few years ago I read about an information based perpetual motion machine someone came up with. IIRC many people studied it for quite a while before realizing that the flaw was an assumption that erasing information was free. It turned out to require the same energy as apparently extracted from the machine. By applying this green svn energy saving principle we have an unparalleled opportunity to assure that future visitors to our svn repo will have no way of finding the live code. OR... we could clean up the leftovers from completed refactoring efforts and releases. Here's the stuff I have located in a quick scan that I think has more recent versions elsewhere or is completely obsolete and can be removed, organized by last committer: pmcmahan: plugins/activemq plugins/console plugins/debugviews plugins/jee-management plugins/plancreator plugins/pluto plugins/system-database These plugins were created at that location as a result of our discussions about organizing the various source trees. http://tinyurl.com/2yakx6 But then later we copied those plugins into server/trunk in order to make releasing 2.1 easier: http://tinyurl.com/yw75fb The only value I can think of in keeping those plugins around would be if we want to use their svn maven structuring to implement the ideas we had discussed in the first thread. I won't be up to that task in the foreseeable future, so I'm fine with removing them unless someone else wants to start that effort back up again. Best wishes, Paul
Re: Entropy, or the heat death of the geronimo code base
prasad: sandbox/restructure This has served its purpose and is obsolete now. Feel free to delete it. Cheers Prasad On Thu, Feb 28, 2008 at 6:07 PM, David Jencks [EMAIL PROTECTED] wrote: A few years ago I read about an information based perpetual motion machine someone came up with. IIRC many people studied it for quite a while before realizing that the flaw was an assumption that erasing information was free. It turned out to require the same energy as apparently extracted from the machine. By applying this green svn energy saving principle we have an unparalleled opportunity to assure that future visitors to our svn repo will have no way of finding the live code. OR... we could clean up the leftovers from completed refactoring efforts and releases. Here's the stuff I have located in a quick scan that I think has more recent versions elsewhere or is completely obsolete and can be removed, organized by last committer: pmcmahan: plugins/activemq plugins/console plugins/debugviews plugins/jee-management plugins/plancreator plugins/pluto plugins/system-database djencks: sandbox/servlet-2.5 (I'm not the last committer but did merge this into trunk) (I've removed this) sandbox/geronimo-jaspi (I merged this into trunk, and removed it) jdillon sandbox/g1.1-activemq4 sandbox/repository (did this make it into the wiki? I'm planning to propose using http://maven.apache.org/developers/release/ releasing.html as the basis for releasing g. stuff, is this relevant?) dain: sandbox/plugins/global-jndi (I'm pretty sure I've got this all into trunk) prasad: sandbox/restructure kevan: sandbox/xsds Didn't these get moved somewhere more appropriate? rick: sandbox/mail (You had nothing to do with this, but could you look and check if there is anything useful inside?) alan: sandbox/james (this appears to be a basically unmodified copy of james) dblevins: server/branches/jpa-plugin (looks like a branch to play with jpa that never went anywhere) specs/branches/jee5-spec (See GERONIMO-2358 Not sure why this didn't get removed or is my svn messed up?) gnodet: specs/branches/geronimo-servlet_2.5_spec-1.1.1 specs/branches/geronimo-stax-api_1.0_spec-1.0.1 Does anyone have any clue what this is: sandbox/spring-assembly (last modified 2006) -- If you know about one of these and think it should stay please reply. If you know it should go you can remove it, tell me to remove it, or do nothing and I will in a few days. thanks david jencks
[BUILD] 2.2: Failed for Revision: 632322
Geronimo Revision: 632322 built with tests included See the full build-0900.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080229/build-0900.log Download the binaries from http://geronimo.apache.org/maven/server/binaries/trunk/20080229 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 31 minutes 15 seconds [INFO] Finished at: Fri Feb 29 09:37:53 EST 2008 [INFO] Final Memory: 309M/1012M [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/trunk/20080229/logs-0900-tomcat/test.log Assembly: jetty = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080229/logs-0900-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.825 sec FAILURE!
[jira] Resolved: (YOKO-418) Multiple problems marshalling object fields defined as java.util.List
[ https://issues.apache.org/jira/browse/YOKO-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved YOKO-418. --- Resolution: Fixed Committed revision 632352. Multiple problems marshalling object fields defined as java.util.List - Key: YOKO-418 URL: https://issues.apache.org/jira/browse/YOKO-418 Project: Yoko - CORBA Server Issue Type: Bug Security Level: public(Regular issues) Components: orb core, RMI-IIOP Affects Versions: v1.1.0 Reporter: Rick McGuire Assignee: Rick McGuire Fix For: v1.0.0 There are multiple serialization problems showing up when processing serialization using interface classes rather than concrete implementation classes. This problem shows up when a serializable object defines a field using an interface class. For example, this showed up using an object where the field was defined as a java.util.List and a Vector instance was stored in the field. There were multiple bugs that popped out with this scenario: 1) The serialization code was incorrectly treating the List type as an abstract interface rather than a value type, which caused problems on serialization/deserialization. 2) Once this was corrected, problems were found with correctly interpreting fields defined as arrays. 3) Once that was corrected, a problem was encountered with handling chunk boundaries during the deserialization of object arrays. These problems were very difficult to diagnose using the existing logging in the core orb and the RMI support, so some additional logging points should also be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3880) PersistenceUnitInfo.getJarFileUrls() can return null
[ https://issues.apache.org/jira/browse/GERONIMO-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3880. -- Resolution: Fixed trunk 632359 2.1 632360 2.0 632361 This also added the test to 2.1 and 2.0. PersistenceUnitInfo.getJarFileUrls() can return null Key: GERONIMO-3880 URL: https://issues.apache.org/jira/browse/GERONIMO-3880 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0.x, 2.1.1, 2.2 Hibernate doesn't like null from PersistenceUnitInfo.getJarFileUrls(), see patch proposed in http://cwiki.apache.org/GMOxSAMPLES/running-jboss-seam-200ga-on-geronimo-21.html While we can argue hibernate should check for null, we shouldn't be supplying null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (YOKO-418) Multiple problems marshalling object fields defined as java.util.List
Multiple problems marshalling object fields defined as java.util.List - Key: YOKO-418 URL: https://issues.apache.org/jira/browse/YOKO-418 Project: Yoko - CORBA Server Issue Type: Bug Security Level: public (Regular issues) Components: orb core, RMI-IIOP Affects Versions: v1.1.0 Reporter: Rick McGuire Assignee: Rick McGuire Fix For: v1.0.0 There are multiple serialization problems showing up when processing serialization using interface classes rather than concrete implementation classes. This problem shows up when a serializable object defines a field using an interface class. For example, this showed up using an object where the field was defined as a java.util.List and a Vector instance was stored in the field. There were multiple bugs that popped out with this scenario: 1) The serialization code was incorrectly treating the List type as an abstract interface rather than a value type, which caused problems on serialization/deserialization. 2) Once this was corrected, problems were found with correctly interpreting fields defined as arrays. 3) Once that was corrected, a problem was encountered with handling chunk boundaries during the deserialization of object arrays. These problems were very difficult to diagnose using the existing logging in the core orb and the RMI support, so some additional logging points should also be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Documentation mega index
That is sooo cool. I also noticed that there were version specific user and developer guides in the first column too. They can be merged into a single row as User Guide with appropriate links in the remaining columns. Cheers Prasad On Thu, Feb 28, 2008 at 5:22 PM, David Blevins [EMAIL PROTECTED] wrote: I created a very high level view of our documentation as it exists across the various versions. Hopefully a very macro few of things may help us clear the fog on documentation related thinking. At least I found it very difficult to see the whole elephant. http://cwiki.apache.org/GMOxDEV/mega-index.html The code I used to generate the page is attached to the page. It's pretty small. Should be a fairly easy manual process to regenerate the page once in a while if we find it useful. -David
Re: [discuss] How do we improve the user experience of the geronimo server?
That reminds me... Security realms portlet is broken yet again. Editing a realm does not work :( ++Vamsi On Fri, Feb 29, 2008 at 8:05 PM, Shiva Kumar H R [EMAIL PROTECTED] wrote: Some automated testcases which will make sure Admin Console portlets are not broken: (the ones I can think of immediately from a Deployment perspective:) 1) DB Manager 2) Database Pools 3) Security Realms 4) JMS Resources 5) Plan Creator -- Thanks, Shiva On Wed, Feb 27, 2008 at 2:14 AM, Lin Sun [EMAIL PROTECTED] wrote: Hi, I am interested in collecting ideas on how we can improve user experience with the geronimo 2.x server, particularly, what type of testing we can do for each geronimo major release to identify probs and resolve them. I think it would be nice to have a set of test (either automated or manually) other than tck that we run to verify various functions in geronimo for each major release. Currently, we probably only run a very small amount of testing other than tck, our automated testing during the build and the few samples we have. One thought is to add more test samples. Seems to me people are trying different things with geronimo server and most of the stuff they tried are not covered by our samples.Any ideas what other samples may be good to work with geronimo? The other thought is to grow test cases from our JIRA system or users. Encourage folks to attach/contribute their test cases. Also, what g functions do folks think we need more testing? Thanks, Lin
G2.1/SjAS'04 issue: OPENEJB-700
Hi, all, I'm once again trying to couple SPECjAppServer2004 with Geronimo, now version 2.1, and one of the problems I observe is: Issue OPENEJB-700 that is now closed as it was fixed in OpenEJB v3.0b2 that is used in G2.1, seems to be still actual for some reason. On G2.1 I still can't deploy SjAS unless the internet connection is present and proxy properly configured. The following error is shown by the Deployer: Error: Unable to distribute SPECjAppServer.ear: org.apache.openejb.OpenEJBException: Cannot read the ejb-jar.xml file: jar:file:/C:/Temp/geronimo-deploymentUtil48973.jar!/META-INF/ejb-jar.xml: Connection timed out: connect General Geronimo/SjAS configuration used is described in detail at [1]. The particular deployment plan causing a problem is [2]. Can anyone suppose if this is indeed a not-completely-fixed OPENEJB-700 or something else? Thanks! [1] http://cwiki.apache.org/confluence/display/GMOxDOC21/SPECjAppServer2004 [2] http://cwiki.apache.org/confluence/download/attachments/77088/sjas-app.xml Vasily
G2.1/SjAS'04 issue: others is null
Hi, all, Another problem with SPECjAppServer2004 on Geronimo v2 is, after successful deployment of SjAS I can't make it work effectively. The following error (see below) comes up in the console. The problem is complex to investigate, as it occurs in openejb.* class that seems to be probably a dynamic wrapper or something and is difficult to track. I have the state of the SetValuedCmr fields at the throw point, but that doesn't much help: source: [EMAIL PROTECTED] sourceProperty: customerInventoryEnt relatedType: openejb.org.spec.jappserver.corp.customerinventoryent.ejb.CustomerInventoryEnt relatedProperty: customer relatedInfo: DeploymentInfo(id=corp.jar/CustomerInventoryEnt) // the class is org.apache.openejb.core.CoreDeploymentInfo Maybe anyone has any idea on how to debug such a situation? General Geronimo/SjAS configuration used is described in detail at [1]. The particular deployment plan causing a problem is [2]. Thanks! javax.ejb.TransactionRolledbackLocalException: The transaction has been marked rollback only because the bean encountered a non-application exception: java.lang.NullPointerException : others is null at org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:350) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:323) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy70.getCustomerInventoryEnt(Unknown Source) at org.spec.jappserver.corp.customerses.ejb.CustomerSesEJB.getInventory(CustomerSesEJB.java:164) 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.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:146) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:129) at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210) ... 43 more Caused by: java.lang.NullPointerException: others is null at org.apache.openejb.core.cmp.cmp2.SetValuedCmr.get(SetValuedCmr.java:62) at openejb.org.spec.jappserver.corp.customerent.ejb.CustomerEnt.getCustomerInventoryEnt(Unknown Source) 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.openejb.core.cmp.CmpContainer.businessMethod(CmpContainer.java:492) at org.apache.openejb.core.cmp.CmpContainer.invoke(CmpContainer.java:277) 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) ... 54 more [1] http://cwiki.apache.org/confluence/display/GMOxDOC21/SPECjAppServer2004 [2] http://cwiki.apache.org/confluence/download/attachments/77088/sjas-app.xml Vasily
Re: Documentation mega index
Yep - this is very cool. One minor comment, I wonder if it is possible to indicate that a particular function starts with a particular release, say for instance, gshell is new starting with v2.1, so we don't really any gshell docs for any releases before v2.1.. for these gshell columns, instead of having the red links with green plus, we can just have N/A (doesn't apply). Lin On Fri, Feb 29, 2008 at 9:34 AM, Prasad Kashyap [EMAIL PROTECTED] wrote: That is sooo cool. I also noticed that there were version specific user and developer guides in the first column too. They can be merged into a single row as User Guide with appropriate links in the remaining columns. Cheers Prasad On Thu, Feb 28, 2008 at 5:22 PM, David Blevins [EMAIL PROTECTED] wrote: I created a very high level view of our documentation as it exists across the various versions. Hopefully a very macro few of things may help us clear the fog on documentation related thinking. At least I found it very difficult to see the whole elephant. http://cwiki.apache.org/GMOxDEV/mega-index.html The code I used to generate the page is attached to the page. It's pretty small. Should be a fairly easy manual process to regenerate the page once in a while if we find it useful. -David
G2.1/SjAS'04 issue: TranQL/OpenJPA
Hi, Matt, all, The third problem still actual for SPECjAppServer2004 is an old transaction isolation issue (GERONIMO-2128). A couple of months ago you were saying [1] that you're going to try to deal with the problem. Now we have G2.1 released, and some older issues are now fixed or workarounded, and I've provided the updated doc [2] and DDs [3][4][5] (to the best I could) for the new G2.1 version. Could you please check what our chances are on turning SjAS to OpenJPA and maybe a successful run, at last? :) Thanks! [1] http://thread.gmane.org/gmane.comp.java.geronimo.devel/54764/focus=54767 [2] http://cwiki.apache.org/confluence/display/GMOxDOC21/SPECjAppServer2004 (configs and DDs attached) [3] http://cwiki.apache.org/confluence/download/attachments/77088/sjas-app.xml - Application [4] http://cwiki.apache.org/confluence/download/attachments/77088/sjas-db.xml - Derby Database connector [5] http://cwiki.apache.org/confluence/download/attachments/77088/sjas-jms.xml - ActiveMQ JMS connector Vasily
[jira] Created: (GERONIMO-3887) After installing with wrong configuration unable to proceed with any new plugin installs
After installing with wrong configuration unable to proceed with any new plugin installs Key: GERONIMO-3887 URL: https://issues.apache.org/jira/browse/GERONIMO-3887 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong The plugin installer located in the administration console fails to install new plugins once it runs into an install that throws an exception for being the wrong configuration type. IE. trying to install a Jetty piece on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Release J2G 1.0.0 RC1
It looks like this did indeed fall completely by the wayside. I think at the bare minimum we should get a 1.0 release binary put out for this. Donald, are you still willing to push that? If not, I am willing to take that over... can I even do that without being PMC? If I can, I'll figure out what needs to be done and such. Thanks, Erik B. Craig [EMAIL PROTECTED] On Feb 26, 2008, at 10:17 AM, Jason Warner wrote: --=_Part_1659_18852684.1204042635536 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What happened to this vote? I checked the tags and the code was never moved over. Did this pass? Do we have an official binary I can link to on the wiki docs? On Mon, Nov 12, 2007 at 4:52 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Nov 6, 2007, at 9:03 PM, Lin Sun wrote: The .project and .classpath files are used when the plugins are loaded in Eclipse IDE.You are right they don't have ASL license headers but I don't see license headers associated with these files normally. The files in the geronimo eclipse plugin don't have ASL license headers either. Also, these files are not in the assembly. Are these files machine generated? Whether or not they end up in an assembly doesn't really matter... They seem non-trivial to me and should have a license header. I am not sure what we need to do with jboss here. Of course we are using it since it is a migration tool from jboss to geronimo. Any advice here? I did a little research for this. It seems we must avoid implying that JBoss is the source of this code. As long as the distribution name (and executable name, I would think) don't use JBoss in the name we're doing this. Internal file names should be fine. So, in my opinion, we're ok here... So, pending the license header and file permission questions, I'd say this looks good. --kevan -- ~Jason Warner --=_Part_1659_18852684.1204042635536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What happened to this vote?nbsp; I checked the tags and the code was never moved over.nbsp; Did this pass?nbsp; Do we have an official binary I can link to on the wiki docs?brbrdiv class=gmail_quoteOn Mon, Nov 12, 2007 at 4:52 PM, Kevan Miller lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/ agt; wrote:br blockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;div class=Ih2E3dbr On Nov 6, 2007, at 9:03 PM, Lin Sun wrote:br br gt; The .project and .classpath files are used when the plugins are loadedbr gt; in Eclipse IDE. nbsp; nbsp;You are right they don#39;t have ASL license headersbr gt; but I don#39;t see license headers associated with these files normally.br gt; The files in the geronimo eclipse plugin don#39;t have ASL licensebr gt; headers either. nbsp; Also, these files are not in the assembly.br br /divAre these files machine generated? Whether or not they end up in anbr assembly doesn#39;t really matter... They seem non-trivial to me andbr should have a license header.br div class=Ih2E3dbr gt;br gt;br gt; I am not sure what we need to do with jboss here. nbsp; Of course we arebr gt; using it since it is a migration tool from jboss to geronimo. nbsp;Anybr gt; advice here?br br br /divI did a little research for this. It seems we must avoid implying thatbr JBoss is the source of this code. As long as the distribution namebr (and executable name, I would think) don#39;t use quot;JBossquot; in the namebr we#39;re doing this. Internal file names should be fine. So, in mybr opinion, we#39;re ok here...br br So, pending the license header and file permission questions, I#39;d saybr this looks good.br font color=#88br --kevanbr br /font/blockquote/divbrbr clear=allbr-- br~Jason Warner --=_Part_1659_18852684.1204042635536--
Jars duplicated between lib/endorsed and repository
I was just doing some work with Yoko, and discovered that the yoko spec jars are getting included in the assemblies in both the lib/endorsed directory and the respository directories as well. Since these are in the minimal assemblies, we can eliminated 1.8Mb from the minimal assemblies if we can remove the repository versions. Does anybody know it it's possible to get the current assembly process to do this? Rick
Re: samples for 2.1?
Kevan Miller wrote: On Feb 26, 2008, at 10:13 AM, Joe Bohn wrote: Is there a plan on how to release the samples for 2.1 and forward? It looks like the changes in the build structure have necessitated that we do something to release samples independently (or perhaps it was other changes). In past releases it looks like the samples were built, voted on, and released as part of the Geronimo release itself. However, they are no longer included under our configs with the restructure and hence they were not included in the process. Should we create a tag for the 2.1 samples (thus far there are no tags in the samples svn (see https://svn.apache.org/repos/asf/geronimo/samples/ )? Do we need to create release candidates and vote on releasing samples now? I ran into this because I took a first pass at generating a new geronimo-plugins.xml for 2.1 yesterday since the old version was still referencing 2.1-SNAPSHOT for all of the plugins. To include the samples I built https://svn.apache.org/repos/asf/geronimo/samples/branches/2.1/ but the poms there are versioned as 2.1-SNAPSHOT and are dependent upon the Geornimo 2.1-SNAPSHOT release. Definitely something we need to do. Probably should have been something we did concurrently with a major release (e.g. 2.1). So, I certainly think we should be tagging sample releases, they should be dependent upon G 2.1, and they need to be voted on. It seems like we need to get a release of the samples available for 2.1 fairly soon. There are a few things I think we need to do to make that happen: 1) Ensure that the samples build with Geronimo 2.1. I've made some changes so they are now building but more may be necessary so that they are building correctly. At the moment all samples in samples/branches/2.1 build with dependencies on the released 2.1 server. 2) Create plugins for each sample? It has been suggested that we should have plugins available for each sample. Some of the samples already build plugins (jsp-examples, servlet-examples, and ldap-sample) but most do not. Should we create plugins of each sample? 3) Verify that each sample can deploy and is functional. I've verified the jsp servlet examples but it would be great if we could get folks to verify their favorite samples so that we have 100% coverage. 4) Branch for a 2.1 release or possibly use the maven-release-plugin to release the samples. Are there other things that I've missed? I was hoping that we could get a candidate release within a week or so. Ideally we should release the samples concurrent with the server release in the future (esp. the jsp servlet examples that are referenced from the geronimo welcome page /). For now, with the changes that I've already made in samples/branches/2.1 and the geronimo-plugins.xml, the jsp servlet examples from the 2.1-SNAPSHOT can be installed in a 2.1 server but the install still fails when attempted from the welcome page (I think it must not look in the snapshot repo for the sample to install). Joe
[jira] Commented: (GERONIMO-3833) Hard-coded gbean names and versions in monitoring code
[ https://issues.apache.org/jira/browse/GERONIMO-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12573962#action_12573962 ] Erik B. Craig commented on GERONIMO-3833: - Committed revision 632438 to Trunk removing hard coded paths from the .sql file Committed revision 632440 to 2.1 branch Hard-coded gbean names and versions in monitoring code -- Key: GERONIMO-3833 URL: https://issues.apache.org/jira/browse/GERONIMO-3833 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jarek Gawor Fix For: 2.1.1, 2.2 The monitoring code has hard-coded values in Java code and sql file: 1) The ./plugins/monitoring/mconsole-war/src/main/java/org/apache/geronimo/monitoring/console/MRCConnector.java contains the following constant: private static final String PATH = geronimo:ServiceModule=org.apache.geronimo.plugins.monitoring/agent-car-jmx/2.1-SNAPSHOT/car,J2EEServer=geronimo, name=MasterRemoteControlJMX,j2eeType=GBean; 2) The ./plugins/monitoring/mconsole-ear/src/main/resources/MonitoringClientDB.sql contains a bunch of the following values: 'geronimo:J2EEServer=geronimo,ServiceModule=org.apache.geronimo.configs/tomcat6/2.1/car,j2eeType=GBean,name=TomcatWebConnector' I'm not sure how these are used but in general these type of hardcoded values should be avoided. It's really hard to maintain and keep track of. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3888) AsyncHttpClient does not handle Set-Cookie directive with an empty value
AsyncHttpClient does not handle Set-Cookie directive with an empty value Key: GERONIMO-3888 URL: https://issues.apache.org/jira/browse/GERONIMO-3888 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: AsyncHttpClient Reporter: Alex Antonov Attachments: empty_cookie_value.patch The current version does not handle properly a case where a Set-Cookie header has an empty value for a name. i.e Set-Cookie=token=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT According to the rfc-2109 for the Set-Cookie header, the value is an optional property and could be blank. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3888) AsyncHttpClient does not handle Set-Cookie directive with an empty value
[ https://issues.apache.org/jira/browse/GERONIMO-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Antonov updated GERONIMO-3888: --- Attachment: empty_cookie_value.patch Attached is a patch to fix the empty cookie value handling problem. AsyncHttpClient does not handle Set-Cookie directive with an empty value Key: GERONIMO-3888 URL: https://issues.apache.org/jira/browse/GERONIMO-3888 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: AsyncHttpClient Reporter: Alex Antonov Attachments: empty_cookie_value.patch The current version does not handle properly a case where a Set-Cookie header has an empty value for a name. i.e Set-Cookie=token=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT According to the rfc-2109 for the Set-Cookie header, the value is an optional property and could be blank. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3889) HttpIoHandler shuts down the scheduled executor service even if it is passed in by caller
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 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.
Re: Selenium
On 29/02/2008, at 6:04 AM, David Jencks wrote: I went to a selenium get together Monday and think we have some great opportunities for improving and speeding up our testsuite. The bits I think would be of most benefit, from my perspective as a non-test-engineer, are: selenium grid. This lets you run basically any number of selenium tests in parallel against a single server. For instance we can run all the console tests in parallel. selenium IDE. This lets you record your actions on a web site as a test. You can also edit the results for e.g. better independence of the xpath expressions on the specific html Hi, IMHO, we should stay away from the recording feature provided by Selenium IDE: it generates code which is really hard to maintain on the long run. Or, generated code could be refactored to better abstract user interactions. Ideally, Selenium tests are written first and, based on many observations, this results in way better integration tests. I also believe that the xpath element selection style is weak and I think that location of elements by ids is a better way to go, especially as we have full control of the source code. Thanks, Gianny There's another tool that was discussed that lets you abstract the xpath expressions but I can't remember the name or find documentation about it. If our pages' formatting don't jump around too much it might not be incredibly useful for us. thanks david jencks
Re: [DISCUSS] Release J2G 1.0.0 RC1
On Fri, Feb 29, 2008 at 10:36 AM, Erik B. Craig [EMAIL PROTECTED] wrote: Donald, are you still willing to push that? If not, I am willing to take that over... can I even do that without being PMC? If I can, I'll figure out what needs to be done and such. Yes, you can. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Selenium
I usually start out using the IDE's record muck to get the basic clicks down, then generate Java code and then massage it to actually test something and drop it into a junit... --jason On Mar 1, 2008, at 7:30 AM, Gianny Damour wrote: On 29/02/2008, at 6:04 AM, David Jencks wrote: I went to a selenium get together Monday and think we have some great opportunities for improving and speeding up our testsuite. The bits I think would be of most benefit, from my perspective as a non-test-engineer, are: selenium grid. This lets you run basically any number of selenium tests in parallel against a single server. For instance we can run all the console tests in parallel. selenium IDE. This lets you record your actions on a web site as a test. You can also edit the results for e.g. better independence of the xpath expressions on the specific html Hi, IMHO, we should stay away from the recording feature provided by Selenium IDE: it generates code which is really hard to maintain on the long run. Or, generated code could be refactored to better abstract user interactions. Ideally, Selenium tests are written first and, based on many observations, this results in way better integration tests. I also believe that the xpath element selection style is weak and I think that location of elements by ids is a better way to go, especially as we have full control of the source code. Thanks, Gianny There's another tool that was discussed that lets you abstract the xpath expressions but I can't remember the name or find documentation about it. If our pages' formatting don't jump around too much it might not be incredibly useful for us. thanks david jencks
