[jira] Created: (GERONIMODEVTOOLS-454) Add support to GEP for various Admin Console wizards like Database pool, Security realm etc
Add support to GEP for various Admin Console wizards like Database pool, Security realm etc --- Key: GERONIMODEVTOOLS-454 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-454 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Sainath Chowdary Fix For: 2.1.x Currently GEP has no support for creating application specific security realms, database pools and other message destinations etc., These features should be added to GEP to make it more robust instead of users creating the plan in admin console and then copying to deployment plan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-455) Add Database pool wizard in GEP to enable application specific pools
Add Database pool wizard in GEP to enable application specific pools Key: GERONIMODEVTOOLS-455 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-455 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Sainath Chowdary Assignee: Sainath Chowdary Fix For: 2.1.x -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-456) Add Security Realm Wizard to GEP to deploy security realm directly from GEP
Add Security Realm Wizard to GEP to deploy security realm directly from GEP --- Key: GERONIMODEVTOOLS-456 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-456 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Saurabh Sharma Assignee: Saurabh Sharma Fix For: 2.1.x -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Documentation of new 2.2 features in current wiki?
On Jul 30, 2008, at 6:46 PM, Kevan Miller wrote: On Jul 29, 2008, at 6:25 PM, David Jencks wrote: On Jul 29, 2008, at 2:06 PM, Jarek Gawor wrote: I think it would be nicer to create pages with 2.2 specific content somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now. Once we have 2.2 documentation space setup we can move the pages around. Or at least I don't think we should mix 2.2 content with 2.1 content. OK, but who exactly is going to do all this wiki maintenance that you are proposing? I suggest mixing the docs because I don't think it will be confusing with prominent enough labels and I don't think that wiki maintenance is going to happen, no matter how many good intentions people now have. Furthermore I would much rather that anyone with the knowledge to organize the documentation and interest in working on it spend it on content rather than continual reorganization. I agree with Jarek. I'd prefer that we keep 2.1 and 2.2 content separated. We've still got G 1.1 users. I don't see how a documentation super-set is going to be viable, in the long term. At some point, the documentation would need to be separated. Better, I think, to start out that way and keep things cleaner for 2.1 users. If the 2.1 docs are complete I suggest we immediately copy them to a set of 2.2 docs and I will happily document new features there. If not we need a plan. I think there have been two basic ideas so far: 1. put new 2.2 docs go into http://cwiki.apache.org/GMOxDEV. A quick glance suggests this is currently mostly a combination of advice on how to develop geronimo and documentation that applies to released versions of geronimo such as 2.0 and 2.1. I don't see any reason so far to think that this will be maintained better in the future and stuff moved from here to appropriate versioned docs. How would this work? 2. Add 2.2 docs to the current 2.1 docs, clearly marked as for 2.2 and later. If and when we copy the 2.1 docs to a 2.2 branch, we can remove these pages from the 2.1 docs and remove the since notices. My impression based on gossip is that while it's possible to copy an entire wiki space it isn't possible to move individual pages between spaces. Is this correct? If so IMNSHO (1) will never work with confluence. If not I think there's at least one page I'd like to move instructions would be great. Anyone have another idea? thanks david jencks --kevan
[jira] Updated: (GERONIMODEVTOOLS-455) Add Database pool wizard in GEP to enable application specific pools
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sainath Chowdary updated GERONIMODEVTOOLS-455: -- Attachment: GERONIMODEVTOOLS-455-456-consolidated.patch Please note that this patch doesn't add any functionality, it only adds the wizards to GEP (which are at present not invoked). We can invoke this wizards in EAR deployment plan to add application specific realms and database pools etc. Add Database pool wizard in GEP to enable application specific pools Key: GERONIMODEVTOOLS-455 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-455 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Sainath Chowdary Assignee: Sainath Chowdary Fix For: 2.1.x Attachments: GERONIMODEVTOOLS-455-456-consolidated.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-456) Add Security Realm Wizard to GEP to deploy security realm directly from GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saurabh Sharma updated GERONIMODEVTOOLS-456: Attachment: GERONIMODEVTOOLS-455-456-consolidated.patch This patch includes two wizards, one for Database plan and other for Security Realm plan generation.These wizards can be invoked independently.One way can be to put some two toolbar buttons on any page header(e.g deployment page in GEP) and invoking these wizards from the action attached with that toolbar. This Patch has a dependency on GERONIMODEVTOOLS-453.patch (https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-453) as it required JAXB class support for schema geronimo-login-config-2.0.xsd. Please review this patch. Add Security Realm Wizard to GEP to deploy security realm directly from GEP --- Key: GERONIMODEVTOOLS-456 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-456 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.x Reporter: Saurabh Sharma Assignee: Saurabh Sharma Fix For: 2.1.x Attachments: GERONIMODEVTOOLS-455-456-consolidated.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-453) JAXB Classes support for schema geronimo-login-config-2.0.xsd
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saurabh Sharma updated GERONIMODEVTOOLS-453: Attachment: jaxb-loginconfig.patch This patch includes JAXB classes for geronimo-login-config-2.0.xsd as it was required to create Security Realm plan in GEP.It was required while i was creating wizard for generation of Security Realm in GEP same as in admin console. I created these JAXB classes and while running newly created Security Realm wizard I was getting follwing error: com.sun.istack.SAXException2: unable to marshal type org.apache.geronimo.jee.loginconfig.LoginConfig as an element because it is missing an @XmlRootElement annotation So I added @XmlRootElement before class name in LoginConfig.java and it starts working fine now, but I'm not sure that approach is right or not. Someone please look into this and if there is some problem with this patch please include JAXB support to geronimo-login-config-2.0.xsd schema as its required in GERONIMODEVTOOLS-455-456-consolidated.patch(https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-456) JAXB Classes support for schema geronimo-login-config-2.0.xsd - Key: GERONIMODEVTOOLS-453 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-453 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.1.2, 2.1.x Reporter: Saurabh Sharma Assignee: Saurabh Sharma Fix For: 2.1.2, 2.1.x Attachments: jaxb-loginconfig.patch There is no JAXB class support for schema geronimo-login-config-2.0.xsd. Login Configuration settings must be specified as a element of xml-reference while generating security realm plan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4210) EJB Injection in JSF Managed Bean
[
https://issues.apache.org/jira/browse/GERONIMO-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
YunFeng Ma updated GERONIMO-4210:
-
Attachment: GERONIMO-4210.patch
Let's look what's going on with this problem:
For example, a web application has two managed been (or servlet, taget) like
bellow:
{noformat}
public class ABean {
@EJB(name = mybean)
private MyBean mybean;
}
public class BBean {
@EJB(name = mybean)
private MyBean mybean;
}
{noformat}
The EJBAnnotationHelper processes the above two annotations and generates the
following descriptor:
{noformat}
jav:ejb-local-ref
jav:ejb-ref-namemybean/jav:ejb-ref-name
jav:localtest.MyBean/jav:local
jav:injection-target
jav:injection-target-classtest.ABean/jav:injection-target-class
jav:injection-target-namemybean/jav:injection-target-name
/jav:injection-target
/jav:ejb-local-ref
{noformat}
According to the above descriptor, only mybean in ABean is injected, the mybean
in BBean is not injected.
The attached patch will generate the following descriptor:
{noformat}
jav:ejb-local-ref
jav:ejb-ref-namemybean/jav:ejb-ref-name
jav:localtest.MyBean/jav:local
jav:injection-target
jav:injection-target-classtest.ABean/jav:injection-target-class
jav:injection-target-namemybean/jav:injection-target-name
/jav:injection-target
jav:injection-target
jav:injection-target-classtest.BBean/jav:injection-target-class
jav:injection-target-namemybean/jav:injection-target-name
/jav:injection-target
/jav:ejb-local-ref
{noformat}
Then mybean in BBean is injected.
Please review the patch and if it's OK, I'll provide a patch for v2.1. Thanks.
EJB Injection in JSF Managed Bean
-
Key: GERONIMO-4210
URL: https://issues.apache.org/jira/browse/GERONIMO-4210
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.1.1
Environment: Linux antares 2.6.25-2-686 #1 SMP Fri Jun 27 03:23:20
UTC 2008 i686 GNU/Linux
Debian
java version 1.6.0_06
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)
Reporter: Matthias Berndt
Attachments: GERONIMO-4210.patch, ltg3.tar.gz
I've got two managed beans in a JSF 1.2 webapp. Both beans are quite equal. I
try to inject a stateless session bean (EJB3) into the managed beans.
@EJB(name = java:comp/env/ejb/CredentialData)
private CredentialData credentialData;
In the first managed bean the EJB is injected correctly in
CredentialDataController. The second bean with exactly the same injection
code does not get the EJB inCredentialTableBean. There is no error but at
runtime credentialData is null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3469) From console: database pool doesn't work well if the name contains a / like jdbc/EmployeeDataSource
[ https://issues.apache.org/jira/browse/GERONIMO-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reassigned GERONIMO-3469: - Assignee: Lin Sun From console: database pool doesn't work well if the name contains a / like jdbc/EmployeeDataSource --- Key: GERONIMO-3469 URL: https://issues.apache.org/jira/browse/GERONIMO-3469 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.0.1 Environment: winxp + Sun JDK 1.5 Reporter: Lin Sun Assignee: Lin Sun 1) If I create a database pool called jdbc/EmployeeDataSource, I won't be able to delete it from the database pool portlet page. 2) Also, while creating a new database pool, it seems not giving the option to have different input boxes for the artifact name and the database pool name. They are in the same input box. This was not true for previous releases IIRC. For example, if I name the database pool jdbc/EmployeeDataSource, the full artifact name will be console.dbpool/jdbc%2FEmployeeDatasource/1.0/rar. This is undesired and error prune, as I don't want that / in the artifact name. Seems fixing No. 2 may fix No. 1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Another samples issue ... how much does a user have to build?
I thought of converting this to a maven plugin today, but Joe, do you think this will still be an issue after we release the sample and publish the buildutil to a public maven repo? Lin On Fri, Jul 18, 2008 at 1:35 PM, Joe Bohn [EMAIL PROTECTED] wrote: Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323).
Re: Another samples issue ... how much does a user have to build?
Lin Sun wrote: I thought of converting this to a maven plugin today, but Joe, do you think this will still be an issue after we release the sample and publish the buildutil to a public maven repo? I don't think this will be an issue for the 2.1.2 samples once we have them published. It will continue to be an issue for any samples that are currently under development (SNAPSHOTs). For snapshots I think it is reasonable to expect the user to build from the top level first. I'm not sure if creating a maven plugin will improve things much. This plugin would still have to be built and released via some mechanism. If it ends up being similar to the car-maven-plugin on the server a bootstrap or something similar would be required prior to building an individual sample. From a user perspective, I don't see that being much different than what we have now. Joe Lin On Fri, Jul 18, 2008 at 1:35 PM, Joe Bohn [EMAIL PROTECTED] wrote: Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323).
Re: Another samples issue ... how much does a user have to build?
I agree with you that converting to a maven plugin will have the same issue. Since this only affect snapshot, I don't think this is a big deal. Lin On Thu, Jul 31, 2008 at 11:54 AM, Joe Bohn [EMAIL PROTECTED] wrote: Lin Sun wrote: I thought of converting this to a maven plugin today, but Joe, do you think this will still be an issue after we release the sample and publish the buildutil to a public maven repo? I don't think this will be an issue for the 2.1.2 samples once we have them published. It will continue to be an issue for any samples that are currently under development (SNAPSHOTs). For snapshots I think it is reasonable to expect the user to build from the top level first. I'm not sure if creating a maven plugin will improve things much. This plugin would still have to be built and released via some mechanism. If it ends up being similar to the car-maven-plugin on the server a bootstrap or something similar would be required prior to building an individual sample. From a user perspective, I don't see that being much different than what we have now. Joe Lin On Fri, Jul 18, 2008 at 1:35 PM, Joe Bohn [EMAIL PROTECTED] wrote: Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323).
[jira] Assigned: (GERONIMO-4224) Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M
[ https://issues.apache.org/jira/browse/GERONIMO-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-4224: - Assignee: Jarek Gawor Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M Key: GERONIMO-4224 URL: https://issues.apache.org/jira/browse/GERONIMO-4224 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.1 Environment: HW: Intel x86 Core 2 Duo, 2G Memory SW: Linux Reporter: Xia Ming Assignee: Jarek Gawor Priority: Minor Steps: 1. put a large access log in var/catalina/logs 2. start default server instance at port 8080 3. login admin console 4. filter access log including the timeframe the large access log spans Problem: Outofmemory exception thowed in the viewwebaccesslog portlet window. Instead of outofmemory exception throwed, suggest to either improve web access logging to split by size, or give a more friendly msg when log file size is too large. I would prefer the former one, because it will improve maintainability of geronimo in a long run environment. **exception msg** Error rendering portlet. javax.portlet.PortletException at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:191) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) 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:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at
Re: [VOTE] Geronimo Server 2.1.2 Release
Oh yeah ... here's my +1. Joe Joe Bohn wrote: All, I've prepared a release candidate of Geronimo Server 2.1.2 for your review and vote. The source for the Geronimo Server 2.1.2 release currently resides here: https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.2 When the release vote is approved, I will svn mv the code to https://svn.apache.org/repos/asf/geronimo/server/tags/2.1.2 An archive of this source code can be found here: http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.tar.gz OR http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-2.1.2-src.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/ contains the 10 Java EE, Minimal, and Framework server binary distributions to be released (framework, tomcat/jetty, Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES, README, NOTICE, LICENSE, DISCLAIMER, and source code archives for the release. These extra txt files were included so that they could be leveraged by GEP if necessary (they are also included in the assembly images). For your convenience, here are pointers to the urls for the distributions in zip format: http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-jetty6-javaee5-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-jetty6-minimal-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-tomcat6-javaee5-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-tomcat6-minimal-2.1.2-bin.zip http://people.apache.org/~jbohn/geronimo-2.1.2-dist/geronimo-framework-2.1.2-bin.zip The maven artifacts for the release can be found here: http://people.apache.org/~jbohn/staging-repo/geronimo-2.1.2/ When the release vote is approved, these maven artifacts will be moved to the m2-ibiblio-rsync-repository at Apache. [ ] +1 Release Geronimo 2.1.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.1.2 (please provide rationale) 72 hours would expire at 11:00PM ET on Saturday evening, 8/2. However, the vote may go longer while the tck results are verified. Joe Bohn
The application server does not start but crashes
The application server does not start but crashes. I receive NullPointerExceptions always as I want to start it -- View this message in context: http://www.nabble.com/The-application-server-does-not-start-but-crashes-tp18759198s134p18759198.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: The application server does not start but crashes
Hello, It would be easier to help you if you could provide us with more information. Ideally we'd like to see the full stack trace from the exception, as well as know what geronimo version you're using and what operating system environment you have. Thanks! On Thu, Jul 31, 2008 at 1:09 PM, lexer [EMAIL PROTECTED] wrote: The application server does not start but crashes. I receive NullPointerExceptions always as I want to start it -- View this message in context: http://www.nabble.com/The-application-server-does-not-start-but-crashes-tp18759198s134p18759198.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- ~Jason Warner
Re: The application server does not start but crashes
Thanks for the very fast reply. I managed to solve the problem. For some reason I had a geronimo instance running already and when i tryed to start geronimo from eclipse the port was blocked leading to a NullPointer Exception. Thanks again. Jason Warner wrote: Hello, It would be easier to help you if you could provide us with more information. Ideally we'd like to see the full stack trace from the exception, as well as know what geronimo version you're using and what operating system environment you have. Thanks! On Thu, Jul 31, 2008 at 1:09 PM, lexer [EMAIL PROTECTED] wrote: The application server does not start but crashes. I receive NullPointerExceptions always as I want to start it -- View this message in context: http://www.nabble.com/The-application-server-does-not-start-but-crashes-tp18759198s134p18759198.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- ~Jason Warner -- View this message in context: http://www.nabble.com/The-application-server-does-not-start-but-crashes-tp18759198s134p18759396.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Resolved: (GERONIMO-4224) Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M
[ https://issues.apache.org/jira/browse/GERONIMO-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4224. --- Resolution: Fixed Fix Version/s: 2.2 2.1.3 Changed the log manager code to read the log file line by line instead of loading the entire file into memory. Changes committed to trunk (revision 681419) and branches/2.1 (revision 681420). The problem was really with converting the mapped byte buffer into char byte buffer which allocates a new byte buffer in the heap. Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M Key: GERONIMO-4224 URL: https://issues.apache.org/jira/browse/GERONIMO-4224 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.1 Environment: HW: Intel x86 Core 2 Duo, 2G Memory SW: Linux Reporter: Xia Ming Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.3, 2.2 Steps: 1. put a large access log in var/catalina/logs 2. start default server instance at port 8080 3. login admin console 4. filter access log including the timeframe the large access log spans Problem: Outofmemory exception thowed in the viewwebaccesslog portlet window. Instead of outofmemory exception throwed, suggest to either improve web access logging to split by size, or give a more friendly msg when log file size is too large. I would prefer the former one, because it will improve maintainability of geronimo in a long run environment. **exception msg** Error rendering portlet. javax.portlet.PortletException at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:191) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) 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:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at
[jira] Reopened: (GERONIMO-4224) Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M
[ https://issues.apache.org/jira/browse/GERONIMO-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reopened GERONIMO-4224: --- Looks like the same problem applies to Derby log viewer and Server log viewer Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M Key: GERONIMO-4224 URL: https://issues.apache.org/jira/browse/GERONIMO-4224 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.1 Environment: HW: Intel x86 Core 2 Duo, 2G Memory SW: Linux Reporter: Xia Ming Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.3, 2.2 Steps: 1. put a large access log in var/catalina/logs 2. start default server instance at port 8080 3. login admin console 4. filter access log including the timeframe the large access log spans Problem: Outofmemory exception thowed in the viewwebaccesslog portlet window. Instead of outofmemory exception throwed, suggest to either improve web access logging to split by size, or give a more friendly msg when log file size is too large. I would prefer the former one, because it will improve maintainability of geronimo in a long run environment. **exception msg** Error rendering portlet. javax.portlet.PortletException at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:191) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) 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:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at
LDAP security realm across multiple instances
Geronimo: 2.1.1 JRE: 1.5.0_08-b03 - Sun Microsystems Inc. Hello, We have a security realm issue that we’re requesting some insight for. Searched the forums but couldn't find same issue. We are running multiple instances from one repository, and have configured a server-wide LDAP security realm in one instance that successfully authenticates for an application deployed from that instance. When an application is configured to use that same security realm in another instance running from the same repository, the credentials windows appears as normal, but when valid credentials are entered in the authentication box and committed, the box disappears as normal, but authentication fails. The only entry in the geronimo.out log file is “mortbay.log AUTH FAILURE: user foo” The realm is not visible from any instance other than the originating instance, and that is understandable, but is this a limitation with security realms and multiple instances? Does “server-wide” mean per instance only? Thank you -John -- View this message in context: http://www.nabble.com/LDAP-security-realm-across-multiple-instances-tp18760018s134p18760018.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: LDAP security realm across multiple instances
best to ask on only one list I answered on user. david jencks On Jul 31, 2008, at 10:50 AM, jbeaulau wrote: Geronimo: 2.1.1 JRE: 1.5.0_08-b03 - Sun Microsystems Inc. Hello, We have a security realm issue that we’re requesting some insight for. Searched the forums but couldn't find same issue. We are running multiple instances from one repository, and have configured a server-wide LDAP security realm in one instance that successfully authenticates for an application deployed from that instance. When an application is configured to use that same security realm in another instance running from the same repository, the credentials windows appears as normal, but when valid credentials are entered in the authentication box and committed, the box disappears as normal, but authentication fails. The only entry in the geronimo.out log file is “mortbay.log AUTH FAILURE: user foo” The realm is not visible from any instance other than the originating instance, and that is understandable, but is this a limitation with security realms and multiple instances? Does “server-wide” mean per instance only? Thank you -John -- View this message in context: http://www.nabble.com/LDAP-security-realm-across-multiple-instances-tp18760018s134p18760018.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Documentation of new 2.2 features in current wiki?
David Jencks wrote: On Jul 30, 2008, at 6:46 PM, Kevan Miller wrote: On Jul 29, 2008, at 6:25 PM, David Jencks wrote: On Jul 29, 2008, at 2:06 PM, Jarek Gawor wrote: I think it would be nicer to create pages with 2.2 specific content somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now. Once we have 2.2 documentation space setup we can move the pages around. Or at least I don't think we should mix 2.2 content with 2.1 content. OK, but who exactly is going to do all this wiki maintenance that you are proposing? I suggest mixing the docs because I don't think it will be confusing with prominent enough labels and I don't think that wiki maintenance is going to happen, no matter how many good intentions people now have. Furthermore I would much rather that anyone with the knowledge to organize the documentation and interest in working on it spend it on content rather than continual reorganization. I agree with Jarek. I'd prefer that we keep 2.1 and 2.2 content separated. We've still got G 1.1 users. I don't see how a documentation super-set is going to be viable, in the long term. At some point, the documentation would need to be separated. Better, I think, to start out that way and keep things cleaner for 2.1 users. If the 2.1 docs are complete I suggest we immediately copy them to a set of 2.2 docs and I will happily document new features there. If not we need a plan. I think there have been two basic ideas so far: 1. put new 2.2 docs go into http://cwiki.apache.org/GMOxDEV. A quick glance suggests this is currently mostly a combination of advice on how to develop geronimo and documentation that applies to released versions of geronimo such as 2.0 and 2.1. I don't see any reason so far to think that this will be maintained better in the future and stuff moved from here to appropriate versioned docs. How would this work? 2. Add 2.2 docs to the current 2.1 docs, clearly marked as for 2.2 and later. If and when we copy the 2.1 docs to a 2.2 branch, we can remove these pages from the 2.1 docs and remove the since notices. 3. Create a new space for Apache Geronimo 2.2 (similar to the spaces we have for 1.0, 1.1, 1.2, 2.0, and 2.1). Add new documents specific to 2.2 into this new space. It would be fairly sparse for now. When we complete the 2.1 docs we can clone them into the 2.2 space and integrate the 2.2 specific documents into the appropriate sections/structure. I can look into what would be necessary to create the 2.2 space and add a link to it on along side the other 5 releases. Joe My impression based on gossip is that while it's possible to copy an entire wiki space it isn't possible to move individual pages between spaces. Is this correct? If so IMNSHO (1) will never work with confluence. If not I think there's at least one page I'd like to move instructions would be great. Anyone have another idea? thanks david jencks --kevan
[jira] Resolved: (GERONIMO-4224) Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M
[ https://issues.apache.org/jira/browse/GERONIMO-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4224. --- Resolution: Fixed Committed similar fixes to trunk (revision 681472) and branches/2.1 (revision 681473) for Derby and Server log viewers. Outofmemory exception throwed by WebAccessLogViewer if the access log file size is too large, such as more than 200M Key: GERONIMO-4224 URL: https://issues.apache.org/jira/browse/GERONIMO-4224 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1.1 Environment: HW: Intel x86 Core 2 Duo, 2G Memory SW: Linux Reporter: Xia Ming Assignee: Jarek Gawor Priority: Minor Fix For: 2.1.3, 2.2 Steps: 1. put a large access log in var/catalina/logs 2. start default server instance at port 8080 3. login admin console 4. filter access log including the timeframe the large access log spans Problem: Outofmemory exception thowed in the viewwebaccesslog portlet window. Instead of outofmemory exception throwed, suggest to either improve web access logging to split by size, or give a more friendly msg when log file size is too large. I would prefer the former one, because it will improve maintainability of geronimo in a long run environment. **exception msg** Error rendering portlet. javax.portlet.PortletException at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:191) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) 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.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:151) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) 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:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at
[jira] Commented: (GERONIMO-3793) Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod
[ https://issues.apache.org/jira/browse/GERONIMO-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12618863#action_12618863 ] Manu T George commented on GERONIMO-3793: - In case of this issue. I added a package-info.class in each of the packages and still axis was unable to even find the package-info class. Another observation here is that the algorithm to find the packages to search for jaxb classes doesn't find the generated classes or even the Customer class in this case both of which are in different packages. I was unable to figure out how to the option to make wsgen generate an ObjectFactory for each package.I also see that the generated classes are in a different package than the one their namespace specifi Not Known To This Context JAXBException when attempting to return complex data type from a @WebMethod --- Key: GERONIMO-3793 URL: https://issues.apache.org/jira/browse/GERONIMO-3793 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.x, 2.1 Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+Axis2 Reporter: Cedric Hurst Assignee: Jarek Gawor Priority: Critical Attachments: ComplexDataTypeWSExampleEAR.ear, geronimo.log Original Estimate: 0h Remaining Estimate: 0h I'm attempting to return a @XmlRootElement annotated object called Customer from a @WebMethod. When calling the service, I get the following error in the server log: javax.xml.bind.JAXBException: [Lcom.gmail.at.cedrichurst.complexDataTypeWSExampleEJB.domain.Customer; is not known to this context at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:223) at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:238) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:85) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) ... 48 more From what I understand, the return type should be added to the JaxB context automatically. Just to make sure I wasn't doing something wrong in my Customer class, I added another method to my bean that returned a java.util.List of Strings. When calling this method, I also got the same sort of error: [javax.xml.bind.JAXBException: java.util.List is not known to this context] javax.xml.ws.WebServiceException: javax.xml.bind.MarshalException - with linked exception: [javax.xml.bind.JAXBException: java.util.List is not known to this context] at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:174) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:69) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:127) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl$2.run(JAXBBlockImpl.java:405) at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:76) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl.marshalByType(JAXBBlockImpl.java:321) at org.apache.axis2.jaxws.message.databinding.impl.JAXBBlockImpl._outputFromBO(JAXBBlockImpl.java:209) at org.apache.axis2.jaxws.message.impl.BlockImpl.outputTo(BlockImpl.java:327) at org.apache.axis2.jaxws.message.impl.BlockImpl.serialize(BlockImpl.java:252) at org.apache.axiom.om.impl.llom.OMSourcedElementImpl.internalSerializeAndConsume(OMSourcedElementImpl.java:599) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:785) at org.apache.axiom.om.impl.llom.OMElementImpl.internalSerializeAndConsume(OMElementImpl.java:814) at org.apache.axiom.soap.impl.llom.SOAPEnvelopeImpl.serializeInternally(SOAPEnvelopeImpl.java:237) at
Re: Documentation of new 2.2 features in current wiki?
Joe Bohn wrote: David Jencks wrote: On Jul 30, 2008, at 6:46 PM, Kevan Miller wrote: On Jul 29, 2008, at 6:25 PM, David Jencks wrote: On Jul 29, 2008, at 2:06 PM, Jarek Gawor wrote: I think it would be nicer to create pages with 2.2 specific content somewhere under http://cwiki.apache.org/GMOxDEV/index.html for now. Once we have 2.2 documentation space setup we can move the pages around. Or at least I don't think we should mix 2.2 content with 2.1 content. OK, but who exactly is going to do all this wiki maintenance that you are proposing? I suggest mixing the docs because I don't think it will be confusing with prominent enough labels and I don't think that wiki maintenance is going to happen, no matter how many good intentions people now have. Furthermore I would much rather that anyone with the knowledge to organize the documentation and interest in working on it spend it on content rather than continual reorganization. I agree with Jarek. I'd prefer that we keep 2.1 and 2.2 content separated. We've still got G 1.1 users. I don't see how a documentation super-set is going to be viable, in the long term. At some point, the documentation would need to be separated. Better, I think, to start out that way and keep things cleaner for 2.1 users. If the 2.1 docs are complete I suggest we immediately copy them to a set of 2.2 docs and I will happily document new features there. If not we need a plan. I think there have been two basic ideas so far: 1. put new 2.2 docs go into http://cwiki.apache.org/GMOxDEV. A quick glance suggests this is currently mostly a combination of advice on how to develop geronimo and documentation that applies to released versions of geronimo such as 2.0 and 2.1. I don't see any reason so far to think that this will be maintained better in the future and stuff moved from here to appropriate versioned docs. How would this work? 2. Add 2.2 docs to the current 2.1 docs, clearly marked as for 2.2 and later. If and when we copy the 2.1 docs to a 2.2 branch, we can remove these pages from the 2.1 docs and remove the since notices. 3. Create a new space for Apache Geronimo 2.2 (similar to the spaces we have for 1.0, 1.1, 1.2, 2.0, and 2.1). Add new documents specific to 2.2 into this new space. It would be fairly sparse for now. When we complete the 2.1 docs we can clone them into the 2.2 space and integrate the 2.2 specific documents into the appropriate sections/structure. I can look into what would be necessary to create the 2.2 space and add a link to it on along side the other 5 releases. I started to make a space for this but it really isn't ready for use yet. I need to catch up with Hernan to figure out how to get it set up correctly (and/or keep experimenting on my own). Joe My impression based on gossip is that while it's possible to copy an entire wiki space it isn't possible to move individual pages between spaces. Is this correct? If so IMNSHO (1) will never work with confluence. If not I think there's at least one page I'd like to move instructions would be great. Anyone have another idea? thanks david jencks --kevan
Re: [DISCUSS] Geronimo Server 2.1.2 Release
Just noticed that the DISCLAIMER.txt might be a little out of date. For example, CXF is no longer an incubator project. Jarek On Wed, Jul 30, 2008 at 10:52 PM, Joe Bohn [EMAIL PROTECTED] wrote: Discussion thread for the Geronimo Server 2.1.2 release vote.
[BUILD] trunk: Failed for Revision: 681573
Geronimo Revision: 681573 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080731/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080731
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 38 minutes 42 seconds
[INFO] Finished at: Thu Jul 31 21:45:28 EDT 2008
[INFO] Final Memory: 372M/1014M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080731/logs-2100-tomcat/test.log
Assembly: jetty
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20080731/logs-2100-jetty/test.log
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading: http://download.java.net/maven/1//woodstox/poms/wstx-asl-3.2.1.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository//woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
Downloading:
http://repo1.maven.org/maven2/woodstox/wstx-asl/3.2.1/wstx-asl-3.2.1.pom
[INFO] [geronimo:start-server {execution: start}]
[INFO] Using assembly configuration: jetty
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-jetty6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-jetty6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty6-javaee5/2.2-SNAPSHOT/geronimo-jetty6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:40.830
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 31 test build(s)
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deployRUNNING
[INFO] commands-testsuite/deploySUCCESS (0:01:02.248)
[INFO] commands-testsuite/gshellRUNNING
[INFO] commands-testsuite/gshellSUCCESS (0:00:29.572)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:18.340)
[INFO] concurrent-testsuite/concurrent-basicRUNNING
[INFO] concurrent-testsuite/concurrent-basicSUCCESS (0:06:18.293)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:01:21.570) Java
returned: 1
[INFO] console-testsuite/basic RUNNING
[INFO] console-testsuite/basic SUCCESS (0:01:50.202)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:43.694)
[INFO] corba-testsuite/corba-marshalRUNNING
[INFO] corba-testsuite/corba-marshalSUCCESS (0:01:06.709)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:44.036)
[INFO] deployment-testsuite/deployment-testsRUNNING
[INFO] deployment-testsuite/deployment-testsSUCCESS (0:00:30.662)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:29.736)
[INFO] deployment-testsuite/manifestcp-testsRUNNING
[INFO] deployment-testsuite/manifestcp-testsSUCCESS (0:00:31.096)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb
