Re: How important is simplifying Creation/Updation of Geronimo Deployment Plans?

2007-05-22 Thread Kanchana Welagedara
Hi Shiva

Went through the proposal posted.Also believe Creating or updating of
Geronimo Deployment Plans has always been a tedious and erroneous task
since in geronimo, user has to work on so much of manual editing in
deployment plans.So it's obvious new users find problems and issues when
it comes to correctly creating Geronimo deployment plans.Also user has
no way to verify the deployment plan before the deployment process
starts.Deployment errors are tracked at the level of deployment.How
about a adding a deployment plan validator(setting the xsd in the xml
file and using the schema location) feature in this proposal for the
people who used to create deployment plans manually and can reuse it for
future developments.Because it will take time to come out this proposal
as a product.

Regards
Kanchana

On Tue, 2007-05-22 at 10:29 +0530, Shiva Kumar H R wrote:
> As recommended by Hernan, I have moved the proposal wiki page
> (mentioned at the beginning of mail chain) to another space. Please
> use this new link for accessing it:
> http://cwiki.apache.org/GMOxDEV/geronimo-deployment-plans-how-to-simplify-creation-or-updation.html
> 
> - Shiva
> 
> On 5/22/07, Shiva Kumar H R < [EMAIL PROTECTED]> wrote:
> Great. Thanks for your valuable comments Mark. 
> 
> As you suggest a "tool/wizard for auto creating Geronimo
> Deployment Plan by scanning the corresponding Java-EE
> plan/annotation" would fit best within "Admin Console", may be
> as an extension to the Deploy New tool.
> 
> In addition, as you point out, it could also be useful to
> enable Developers to specify Geronimo specific deployment
> information through Annotations (may be as JSR-175 annotations
> instead of XDoclet based Annotations). One our Committers
> 'Sachin Patel' had started one such discussion
> http://www.mail-archive.com/dev@geronimo.apache.org/msg39760.html. 
> Your feedback here has  helped clarify that discussion also. 
> 
> Thanks again Mark. User feedbacks have always been Gold Mines.
> Please keep pouring your suggestions and feedback in future. 
> 
> If I understand correctly David Jencks, Aaron Mulder, David
> Blevins, Tim McConnell and Others are the experts in Geronimo
> Deployment Plans and Annotations. It would be valuable if they
> too can post their view on this. 
> 
> Thanks,
> Shiva
> 
> 
> On 5/21/07, Mark Aufdencamp <[EMAIL PROTECTED]> wrote:
> It's definitely needed!  I'm the Architecture/Project
> Manager type with twenty years in the business.  I've
> been engaged in re-learning the JEE stack over the
> last six months with Geronimo.  I've been befuddled a
> half dozen times in the learning curve by the
> configuration files. This list has helped to resolve
> all of them:)
>  
> I've been using MyEclipse learning materials which are
> all JBoss based.  I've been able to use XDoclet to
> generate my ejb-jar.xml.  This has been very helpful,
> but I have had to hand translate the open-ejb.jar
> components.  This also applies to the geronimo-web.xml
> file.  It would have been very helpful to have these
> generated by the XDoclet annotations like the
> available JBoss tags.  I would also mention at this
> point that the lack of a global JNDI service created
> an additional learning knock about the container
> specific configuraion files:).  Yes, they have to be
> defined n the container config in order to be
> accessed.  That's the developer perspective in me.
>  
> Now for the Architect/PM side.  I very much believe in
> the seperation of duties, and auditability of
> application/server/network administration.  I don't
> believe that I can get my server administrators to
> create a hand crafted deployment plan that would have
> any chance at mashing up with generic code coming from
> my web developer or ejb/database developer!  A
> template system that incorporated creation of the
> container specific configuration based on the web.xml
> and ejb-jar.xml would be a valuable tool within the
> server administration tool set.  I would expect a tool
> like this to be available within the management
> console in direct proximity to the deploy application
> tool!  Setting deployment specific environment values
> falls within this s

Sun JSF RI alternate config

2007-05-22 Thread Don Hill

Hi,

I have a need to get Sun RI running on Geronimo 2.x, actually this is part
of a cross platform effort that I am working on, so with that here are a few
questions.

1.) has anyone created this config that will allow myfaces to to changed out
for Sun RI.
2.) Could someone explain to me, short story of the configs/gbeans that need
to be changed to get this working?

Any other advise is always appreciated ;)

Thanks.


Re: Ability to assign jira's to myself

2007-05-22 Thread Viet Hung Nguyen

Erik B. Craig wrote:

Haha, thanks.

On 5/21/07, *Jason Warner* <[EMAIL PROTECTED] 
> wrote:


Haha.  Fantastic.  Thanks again!


On 5/21/07, *Jason Dillon* < [EMAIL PROTECTED]
> wrote:

Go forth and code, and let they code be documented in jira
well for thy now hath ability to ownith thy issue.

-- the word of the jira master


On May 21, 2007, at 2:24 PM, Erik B. Craig wrote:


Jason,

The email I used for my Jira account is also
[EMAIL PROTECTED] 

Thanks!

On 5/21/07, *Jason Dillon * < [EMAIL PROTECTED]
> wrote:

Tell me the email addr you used for your jira account and
I can add
you to geronimo-contributor, so you can assign issues to
yourself.

--jason


On May 21, 2007, at 11:18 AM, Jason Warner wrote:

> When I first signed up to the issue tracker, I lacked
the ability
> to assign a jira to myself.  This was quickly remedied
by one of
> the kind community members.  I now find that I have, for
some
> reason, lost that ability.  Does anyone know why this
could be?  It
> doesn't really affect any work I do, but it does mean
that I lack a
> good way of informing people that I am working on a
certain jira.
> Any help that could be provided would be most appreciated.
>
> Thank you,
>
> Jason Warner




-- 
Erik B. Craig

847.812.6347
[EMAIL PROTECTED] 






--
Erik B. Craig
847.812.6347
[EMAIL PROTECTED]  

I would like to get myself into this too.

[EMAIL PROTECTED]

Thanks,
Viet Nguyen


[jira] Created: (GERONIMO-3182) Damned servlet exception in Geronimo - bad stack trace.

2007-05-22 Thread Alexander Zynevich (JIRA)
Damned servlet exception in Geronimo - bad stack trace.
---

 Key: GERONIMO-3182
 URL: https://issues.apache.org/jira/browse/GERONIMO-3182
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: web
Affects Versions: 2.0-M6
Reporter: Alexander Zynevich
 Attachments: ServletException.jad

I trying to make JSF application working and get error messages like this in 
log:
javax.servlet.ServletException: Cannot convert [EMAIL PROTECTED] of type class 
$Proxy34 to class com.ibm.demo.managers.UserManagerImpl for bean 'SignonBean' 
check the configuration to make sure all properties correspond with get/set 
methods
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
com.ibm.democrm.common.AuthorizationFilter.doFilter(AuthorizationFilter.java:70)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at 
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at 
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:358)
at 
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java:619)

The problem is NOT this exception but in the way it presented.
This exception is wrapping some runtime or app-specific exception into Servlet 
exception. But geronimo is bundled with 
/org.apache.geronimo.specs/geronimo-servlet_2.5_spec// which has servlet 
exception as:
public class ServletException extends Exception
{

public ServletException()
{
}

public ServletException(String message)
{
super(message);
}

public ServletException(String message, Throwable rootCause)
{
super(message);
this.rootCause = rootCause;
}

public ServletException(Throwable rootCause)
{
super(rootCause.getLocalizedMessage());
this.rootCause = rootCause;
}

public Throwable getRootCause()
{
return rootCause;
}

private Throwable rootCause;
}
which of course does not expose class name and stack trace of wrapped exception 
(I decompile exactly from 
/org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1-SNAPSHOT/)
It makes stack trace absolutely unuseful!
My expectation is that ServletException should be the same as the latest 
revision in Tomcat project:
http://svn.apache.org/viewvc?view=rev&revision=467995
where the "rootCause" is hadled as "cause" in wrapping constructor of 
java.lang.Execption.

I am going to substitute this class in jar manually, to bypass it.

Of course I understand that this is because of Maven-build-ideology of Geronimo 
and real *bug* is in 
/org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1-SNAPSHOT/ artifact. On 
the othet hand this is very anoying! Could somebody fix centrally? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (GERONIMO-3182) Damned servlet exception in Geronimo - bad stack trace.

2007-05-22 Thread Alexander Zynevich (JIRA)

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

Alexander Zynevich updated GERONIMO-3182:
-

Attachment: ServletException.jad

> Damned servlet exception in Geronimo - bad stack trace.
> ---
>
> Key: GERONIMO-3182
> URL: https://issues.apache.org/jira/browse/GERONIMO-3182
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 2.0-M6
>Reporter: Alexander Zynevich
> Attachments: ServletException.jad
>
>
> I trying to make JSF application working and get error messages like this in 
> log:
> javax.servlet.ServletException: Cannot convert [EMAIL PROTECTED] of type 
> class $Proxy34 to class com.ibm.demo.managers.UserManagerImpl for bean 
> 'SignonBean' check the configuration to make sure all properties correspond 
> with get/set methods
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> com.ibm.democrm.common.AuthorizationFilter.doFilter(AuthorizationFilter.java:70)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>   at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
>   at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:358)
>   at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>   at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
>   at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>   at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>   at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>   at java.lang.Thread.run(Thread.java:619)
> The problem is NOT this exception but in the way it presented.
> This exception is wrapping some runtime or app-specific exception into 
> Servlet exception. But geronimo is bundled with 
> /org.apache.geronimo.specs/geronimo-servlet_2.5_spec// which has servlet 
> exception as:
> public class ServletException extends Exception
> {
> public ServletException()
> {
> }
> public ServletException(String message)
> {
> super(message);
> }
> public ServletException(String message, Throwable rootCause)
> {
> super(message);
> this.rootCause = rootCause;
> }
> public ServletException(Throwable rootCause)
> {
> super(rootCause.getLocalizedMessage());
> this.rootCause = rootCause;
> }
> public Throwable getRootCause()
> {
> return rootCause;
> }
> private Throwable rootCause;
> }
> which of course does not expose class name and stack trace of wrapped 
> exception (I decompile exactly from 
> /org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1-SNAPSHOT/)
> It makes stack trace absolutely unuseful!
> My expectation is that ServletException should be the same as the latest 
> revision in Tomcat project:
> http://svn.apache.org/viewvc?view=rev&revision=467995
> where the "rootCause" is hadled as "cause" in wrapping constructor of 
> java.lang.Execption.
> I am going to substitute this class in jar manually, to bypass it.
> Of course I understand that this is because of Maven-build-ideology of 
> Geronimo and real *bug* is in 
> /org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1-SNAPSHOT/ artifact. 
> On the othet hand this is very anoying! Could somebody fix centrally? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: [VOTE] Release ServiceMix 3.1.1 (2nd try)

2007-05-22 Thread Thomas TERMIN
+1

Guillaume Nodet wrote:
> I have uploaded a version of ServiceMix 3.1.1 in the standard repo
> for you to review. See
> http://incubator.apache.org/servicemix/servicemix-311.html
> for the future download page and release notes (these are also included in
> the
> distribution).  The distribution have been uploaded to
> 
> http://people.apache.org/~gnodet/servicemix-3.1.1-incubating/org/apache/servicemix/apache-servicemix/3.1.1-incubating/
> 
> 
> I send this mail both to the dev list and [EMAIL PROTECTED], as a first vote
> has
> been
> conducted on the ServiceMix dev list and some issues have been fixed since
> that, so hopefully this one will be fine.
> 
> [ ] +1 Release ServiceMix 3.1.1
> [ ] +/- 0
> [ ] -1 Do not release ServiceMix 3.1.1
> 
> The rat log is available at
> http://people.apache.org/~gnodet/rat-servicemix-3.1.1-incubating.txt
> 
> 
> Here's my +1
> 


-- 
Thomas Termin
___
blue elephant systems GmbH
Wollgrasweg 49
D-70599 Stuttgart

Tel:  (+49) 0711 - 45 10 17 676
Fax:  (+49) 0711 - 45 10 17 573
WWW:  http://www.blue-elephant-systems.com
Email  :  [EMAIL PROTECTED]

blue elephant systems GmbH
Firmensitz  : Wollgrasweg 49, D-70599 Stuttgart
Registergericht : Amtsgericht Stuttgart, HRB 24106
Geschäftsführer : Holger Dietrich, Thomas Gentsch, Joachim Hoernle



Do we still need sun's jaxws-api.jar?

2007-05-22 Thread Lin Sun

Hi,

I saw that we still use sun's jaxws-api in root pom.xml, jee-spec 
pom.xml, and a few webservices test.



javax.xml.ws
jaxws-api


I was under the impression both CXF and Axis2 use axis2's jaxws-api.  If 
so, can I remove/replace all the reference of sun's jaxws-api w/ axis2's 
jaxws-api?


Thanks, Lin


[jira] Updated: (GERONIMO-3182) Damned servlet exception in Geronimo - bad stack trace.

2007-05-22 Thread Alexander Zynevich (JIRA)

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

Alexander Zynevich updated GERONIMO-3182:
-

Attachment: geronimo-servlet_2.5_fix.zip

I appied this quick and dirty (zip-level) fix, and that is the difference:
18:12:09,468 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces 
Servlet threw exception
java.lang.IllegalArgumentException: Cannot convert [EMAIL PROTECTED] of type 
class $Proxy21 to class com.ibm.demo.managers.UserManagerImpl
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:374)
at 
org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
at 
org.apache.myfaces.config.ManagedBeanBuilder.coerceToType(ManagedBeanBuilder.java:272)
at 
org.apache.myfaces.config.ManagedBeanBuilder.initializeProperties(ManagedBeanBuilder.java:255)
at 
org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:88)
at 
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:196)
at 
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:162)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
at 
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$301(FacesCompositeELResolver.java:46)
at 
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$4.invoke(FacesCompositeELResolver.java:108)
at 
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke(FacesCompositeELResolver.java:148)
at 
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:104)
at 
org.apache.myfaces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:61)
at 
org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(DelegatingVariableResolver.java:108)
at 
org.apache.myfaces.el.convert.VariableResolverToELResolver.getValue(VariableResolverToELResolver.java:93)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
at 
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$301(FacesCompositeELResolver.java:46)
at 
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$4.invoke(FacesCompositeELResolver.java:108)
at 
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke(FacesCompositeELResolver.java:148)
at 
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:104)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:45)
at org.apache.el.parser.AstValue.getValue(AstValue.java:86)
at 
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at 
org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:101)
at javax.faces.component.UIOutput.getValue(UIOutput.java:68)
at 
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getStringValue(RendererUtils.java:224)
at 
org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.renderInput(HtmlTextRendererBase.java:139)
at 
org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.encodeEnd(HtmlTextRendererBase.java:54)
at 
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:539)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:250)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:247)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:247)
at 
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:308)
at 
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
at 
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
com.ibm.democrm.common.AuthorizationFilter.doFilter(AuthorizationFilter.java:70)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at 
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at 
org.apache.geronimo.tom

Re: svn commit: r540409 - in /geronimo/server/trunk: assemblies/geronimo-boilerplate-minimal/pom.xml pom.xml

2007-05-22 Thread Donald Woods
Can we put the addition of Xerces/Xalan in geronimo-boilerplate-jee5 instead 
of geronimo-boilerplate-minimal, which adds unnecessary bloat back into the 
minimal assemblies again?


-Donald

[EMAIL PROTECTED] wrote:

Author: kevan
Date: Mon May 21 20:18:08 2007
New Revision: 540409

URL: http://svn.apache.org/viewvc?view=rev&rev=540409
Log:
GERONIMO-3180 Override XML Parsing bugs in JRE 1.5 by providing our own xerces 
and xalan jars in lib/endorsed. Once JRE issues are resolved, we can consider 
removing these jars

Modified:
geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/pom.xml
geronimo/server/trunk/pom.xml

Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/pom.xml
URL: 
http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/pom.xml?view=diff&rev=540409&r1=540408&r2=540409
==
--- geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/pom.xml 
(original)
+++ geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/pom.xml Mon 
May 21 20:18:08 2007
@@ -122,6 +122,19 @@
 org.apache.yoko
 yoko-rmi-spec
 
+
+
+xalan
+xalan
+
+
+xerces
+xercesImpl
+
+
+xml-apis
+xml-apis
+
 
 
${project.build.directory}/classes/lib/endorsed
 

Modified: geronimo/server/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?view=diff&rev=540409&r1=540408&r2=540409
==
--- geronimo/server/trunk/pom.xml (original)
+++ geronimo/server/trunk/pom.xml Mon May 21 20:18:08 2007
@@ -525,7 +525,7 @@
 
 xalan
 xalan
-2.6.0
+2.7.0
 
 
 







smime.p7s
Description: S/MIME Cryptographic Signature


[jira] Created: (GERONIMO-3183) fix offline deployment in minimal configurations

2007-05-22 Thread toby cabot (JIRA)
fix offline deployment in minimal configurations


 Key: GERONIMO-3183
 URL: https://issues.apache.org/jira/browse/GERONIMO-3183
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 2.0-M6
 Environment: Fedora Core 4
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)

Reporter: toby cabot
 Fix For: 2.0-M6


The deployer's offline mode in the jetty6-minimal and tomcat6-minimal 
assemblies throws:

org.apache.geronimo.kernel.config.LifecycleException: load of 
org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at 
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
at 
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at 
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at 
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at 
org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration()
at 
org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120)
at 
org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71)
at 
org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102)
at 
org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90)
at 
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at 
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: 
org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
... 19 more



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (GERONIMO-3182) Damned servlet exception in Geronimo - bad stack trace.

2007-05-22 Thread Donald Woods (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497911
 ] 

Donald Woods commented on GERONIMO-3182:


The source code for this spec can be found at -
 
http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_2.5_spec/

Can you create and submit a patch against the current code above?


> Damned servlet exception in Geronimo - bad stack trace.
> ---
>
> Key: GERONIMO-3182
> URL: https://issues.apache.org/jira/browse/GERONIMO-3182
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 2.0-M6
>Reporter: Alexander Zynevich
> Attachments: geronimo-servlet_2.5_fix.zip, ServletException.jad
>
>
> I trying to make JSF application working and get error messages like this in 
> log:
> javax.servlet.ServletException: Cannot convert [EMAIL PROTECTED] of type 
> class $Proxy34 to class com.ibm.demo.managers.UserManagerImpl for bean 
> 'SignonBean' check the configuration to make sure all properties correspond 
> with get/set methods
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> com.ibm.democrm.common.AuthorizationFilter.doFilter(AuthorizationFilter.java:70)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>   at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
>   at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:358)
>   at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>   at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
>   at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>   at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>   at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>   at java.lang.Thread.run(Thread.java:619)
> The problem is NOT this exception but in the way it presented.
> This exception is wrapping some runtime or app-specific exception into 
> Servlet exception. But geronimo is bundled with 
> /org.apache.geronimo.specs/geronimo-servlet_2.5_spec// which has servlet 
> exception as:
> public class ServletException extends Exception
> {
> public ServletException()
> {
> }
> public ServletException(String message)
> {
> super(message);
> }
> public ServletException(String message, Throwable rootCause)
> {
> super(message);
> this.rootCause = rootCause;
> }
> public ServletException(Throwable rootCause)
> {
> super(rootCause.getLocalizedMessage());
> this.rootCause = rootCause;
> }
> public Throwable getRootCause()
> {
> return rootCause;
> }
> private Throwable rootCause;
> }
> which of course does not expose class name and stack trace of wrapped 
> exception (I decompile exactly from 
> /org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1-SNAPSHOT/)
> It makes stack trace absolutely unuseful!
> My expectation is that ServletException should be the same as the latest 
> revision in Tomcat project:
> http://svn.apache.org/viewvc?view=rev&revision=467995
> where the "rootCause" is hadled as "cause" in wrapping constructor of 
> java.lang.Execption.
> I am going to substitute this class in jar manually, to bypass it.
> Of course I understand that this is because of Maven-build-ideology of 
> Geronimo and real *bug* is in 
> /org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1-SNAPSHOT/ artifact. 
> On the othet hand this is very anoying! Could somebody fix centrally? 

-- 
This message is automatically generated by JIRA.
-
You can reply to

Re: Sun JSF RI alternate config

2007-05-22 Thread David Jencks


On May 22, 2007, at 5:23 AM, Don Hill wrote:


Hi,

I have a need to get Sun RI running on Geronimo 2.x, actually this  
is part of a cross platform effort that I am working on, so with  
that here are a few questions.


1.) has anyone created this config that will allow myfaces to to  
changed out for Sun RI.


No one has said anything about it, I doubt it very much.

2.) Could someone explain to me, short story of the configs/gbeans  
that need to be changed to get this working?


You need to write 2 modules and 2 configs to replace the geronimo- 
myfaces, geronimo-myfaces-builder modules and myfaces and myfaces- 
deployer configs, then you need to build a server with these instead  
of the myfaces ones, or just add them, but turn on the ri-deployer  
module instead of the myfaces-deployer module.


The hard part will be dealing with annotations.  IIUC the jsf ri uses  
something like the tomcat AnnotationProcessor interface that I seem  
to have been able to talk both myfaces and tomcat out of using.  If  
you don't need annotation support then integration should be pretty  
easy, just write a no-op annotation processor.




Any other advise is always appreciated ;)


Are you interested/able to contribute your work back to geronimo?

thanks
david jencks



Thanks.






[jira] Commented: (GERONIMO-3183) fix offline deployment in minimal configurations

2007-05-22 Thread toby cabot (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497916
 ] 

toby cabot commented on GERONIMO-3183:
--

Chunks 5-8 fix these stack traces.  They're unlikely to appear in normal 
operations but might be seen during development:

[EMAIL PROTECTED]:/download$ geronimo-jetty6-minimal-2.0-SNAPSHOT/bin/deploy.sh 
-o list-modules 
Using GERONIMO_BASE:   /download/geronimo-jetty6-minimal-2.0-SNAPSHOT
Using GERONIMO_HOME:   /download/geronimo-jetty6-minimal-2.0-SNAPSHOT
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:/usr/java/jdk1.6.0_01/jre
Error: Unable to query modules
javax.enterprise.deploy.spi.exceptions.TargetException
at 
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:175)
at 
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getRunningModules(JMXDeploymentManager.java:136)
at 
org.apache.geronimo.deployment.cli.CommandListModules.execute(CommandListModules.java:63)
at 
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at 
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
Caused by: java.lang.NullPointerException
at 
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.getModules(JMXDeploymentManager.java:149)
... 6 more

... and ...

[EMAIL PROTECTED]:/download$ geronimo-jetty6-minimal-2.0-SNAPSHOT/bin/deploy.sh 
-o list-targets 
Using GERONIMO_BASE:   /download/geronimo-jetty6-minimal-2.0-SNAPSHOT
Using GERONIMO_HOME:   /download/geronimo-jetty6-minimal-2.0-SNAPSHOT
Using GERONIMO_TMPDIR: var/temp
Using JRE_HOME:/usr/java/jdk1.6.0_01/jre
Available Targets:
Exception in thread "main" java.lang.NullPointerException
at 
org.apache.geronimo.deployment.cli.CommandListTargets.execute(CommandListTargets.java:37)
at 
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:161)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at 
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)


> fix offline deployment in minimal configurations
> 
>
> Key: GERONIMO-3183
> URL: https://issues.apache.org/jira/browse/GERONIMO-3183
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6
> Environment: Fedora Core 4
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
>Reporter: toby cabot
> Fix For: 2.0-M6
>
> Attachments: minimal-offline-patch.txt
>
>
> The deployer's offline mode in the jetty6-minimal and tomcat6-minimal 
> assemblies throws:
> org.apache.geronimo.kernel.config.LifecycleException: load of 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration()
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120)
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.

Re: Sun JSF RI alternate config

2007-05-22 Thread Don Hill

David,

Thanks for the info.

As far as contributing it back, I am able to and will be contributing it
back.

I will let you know if I have any other questions. ;)

Thanks..


On 5/22/07, David Jencks <[EMAIL PROTECTED]> wrote:



On May 22, 2007, at 5:23 AM, Don Hill wrote:

> Hi,
>
> I have a need to get Sun RI running on Geronimo 2.x, actually this
> is part of a cross platform effort that I am working on, so with
> that here are a few questions.
>
> 1.) has anyone created this config that will allow myfaces to to
> changed out for Sun RI.

No one has said anything about it, I doubt it very much.

> 2.) Could someone explain to me, short story of the configs/gbeans
> that need to be changed to get this working?

You need to write 2 modules and 2 configs to replace the geronimo-
myfaces, geronimo-myfaces-builder modules and myfaces and myfaces-
deployer configs, then you need to build a server with these instead
of the myfaces ones, or just add them, but turn on the ri-deployer
module instead of the myfaces-deployer module.

The hard part will be dealing with annotations.  IIUC the jsf ri uses
something like the tomcat AnnotationProcessor interface that I seem
to have been able to talk both myfaces and tomcat out of using.  If
you don't need annotation support then integration should be pretty
easy, just write a no-op annotation processor.

>
> Any other advise is always appreciated ;)

Are you interested/able to contribute your work back to geronimo?

thanks
david jencks

>
> Thanks.
>
>




[jira] Updated: (GERONIMO-3183) fix offline deployment in minimal configurations

2007-05-22 Thread toby cabot (JIRA)

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

toby cabot updated GERONIMO-3183:
-

Attachment: minimal-offline-patch.txt

This patch makes a few changes.  The most important are to add 
persistence-jpa10-deployer to the minimal assembly pom.xml files, add the 
j2ee-system config to the offline-deployer-config.xml files and sync the jetty 
and tomcat offline-deployer-config.xml files.

Along the way I fixed some stack traces caused when no modules or targets can 
be found (which is not a typical condition) and improved the diagnostics when 
more than one ConfigurationManager is found (which is also not typical).



> fix offline deployment in minimal configurations
> 
>
> Key: GERONIMO-3183
> URL: https://issues.apache.org/jira/browse/GERONIMO-3183
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6
> Environment: Fedora Core 4
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
>Reporter: toby cabot
> Fix For: 2.0-M6
>
> Attachments: minimal-offline-patch.txt
>
>
> The deployer's offline mode in the jetty6-minimal and tomcat6-minimal 
> assemblies throws:
> org.apache.geronimo.kernel.config.LifecycleException: load of 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration()
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120)
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90)
> at 
> org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at 
> org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
> Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
> ... 19 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (GERONIMO-3182) Damned servlet exception in Geronimo - bad stack trace.

2007-05-22 Thread Paul McMahan (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497921
 ] 

Paul McMahan commented on GERONIMO-3182:


on [EMAIL PROTECTED] we're discussing publishing their implementation of the 
specs to ibiblio, and it's looking like that will work out.   in that case I 
think we should switch geronimo to use tomcat's implementation of the servlet, 
jsp, and el specs since what we're using now was originally copied from 
tomcat's svn anyway (before their jars were available to maven).  I'll keep an 
eye on that discussion and propose making these changes to geronimo if/when 
tomcat's spec jars become available.

> Damned servlet exception in Geronimo - bad stack trace.
> ---
>
> Key: GERONIMO-3182
> URL: https://issues.apache.org/jira/browse/GERONIMO-3182
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 2.0-M6
>Reporter: Alexander Zynevich
> Attachments: geronimo-servlet_2.5_fix.zip, ServletException.jad
>
>
> I trying to make JSF application working and get error messages like this in 
> log:
> javax.servlet.ServletException: Cannot convert [EMAIL PROTECTED] of type 
> class $Proxy34 to class com.ibm.demo.managers.UserManagerImpl for bean 
> 'SignonBean' check the configuration to make sure all properties correspond 
> with get/set methods
>   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> com.ibm.democrm.common.AuthorizationFilter.doFilter(AuthorizationFilter.java:70)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
>   at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
>   at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:358)
>   at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>   at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
>   at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>   at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
>   at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
>   at java.lang.Thread.run(Thread.java:619)
> The problem is NOT this exception but in the way it presented.
> This exception is wrapping some runtime or app-specific exception into 
> Servlet exception. But geronimo is bundled with 
> /org.apache.geronimo.specs/geronimo-servlet_2.5_spec// which has servlet 
> exception as:
> public class ServletException extends Exception
> {
> public ServletException()
> {
> }
> public ServletException(String message)
> {
> super(message);
> }
> public ServletException(String message, Throwable rootCause)
> {
> super(message);
> this.rootCause = rootCause;
> }
> public ServletException(Throwable rootCause)
> {
> super(rootCause.getLocalizedMessage());
> this.rootCause = rootCause;
> }
> public Throwable getRootCause()
> {
> return rootCause;
> }
> private Throwable rootCause;
> }
> which of course does not expose class name and stack trace of wrapped 
> exception (I decompile exactly from 
> /org.apache.geronimo.specs/geronimo-servlet_2.5_spec/1.1-SNAPSHOT/)
> It makes stack trace absolutely unuseful!
> My expectation is that ServletException should be the same as the latest 
> revision in Tomcat project:
> http://svn.apache.org/viewvc?view=rev&revision=467995
> where the "rootCause" is hadled as "cause" in wrapping constructor of 
> java.lang.Execption.
> I am going to substitute this class in jar manually, to bypass it.
> Of course I understand that t

[jira] Commented: (GERONIMO-2885) JSF is leaking application ClassLoaders

2007-05-22 Thread Paul McMahan (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-2885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497923
 ] 

Paul McMahan commented on GERONIMO-2885:


Kevan I think this is fixed now, correct?

> JSF is leaking application ClassLoaders
> ---
>
> Key: GERONIMO-2885
> URL: https://issues.apache.org/jira/browse/GERONIMO-2885
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Jetty, Tomcat
>Affects Versions: 2.0-M3, 2.0-M5
>Reporter: Kevan Miller
> Fix For: 2.0-M5
>
>
> javax.faces.FactoryFinder is holding onto application ClassLoaders. This 
> prevents the ClassLoaders from being GC'ed after an undeploy.
> Need to call FactoryFinder.releaseFactories() during undeploy. This will 
> release the current ContextClassLoader.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: svn commit: r540409 - in /geronimo/server/trunk: assemblies/geronimo-boilerplate-minimal/pom.xml pom.xml

2007-05-22 Thread Kevan Miller


On May 22, 2007, at 11:38 AM, Donald Woods wrote:

Can we put the addition of Xerces/Xalan in geronimo-boilerplate- 
jee5 instead of geronimo-boilerplate-minimal, which adds  
unnecessary bloat back into the minimal assemblies again?


We could consider it. Putting them back into boilerplate-minimal was  
consistent with our G 1.1 and 1.2 structure. I certainly wouldn't  
call it "unecessary" and could do without painting the issue with  
words like "bloat". I could similarly describe your proposal as --  
"could we remove Xerces/Xalan from the minimal server, so that we can  
break xml processing in that environment?


Good chance that we'll be pulling the xalan jar out, for other  
reasons. Since xalan is the biggest jar, I assume this helps?


--kevan


Re: svn commit: r540409 - in /geronimo/server/trunk: assemblies/geronimo-boilerplate-minimal/pom.xml pom.xml

2007-05-22 Thread Donald Woods
If the XML failures are in TCK tests that relate to modules not included in 
the minimal assemblies, then what would we be breaking by removing Xerces/Xalan?


I was just hoping that we could keep them out of the minimal assemblies if 
they are not needed, since some users will want to use Java 5 and others are 
wanting Java 6 support, which both provide their own implementations at 
different feature levels



-Donald


Kevan Miller wrote:


On May 22, 2007, at 11:38 AM, Donald Woods wrote:

Can we put the addition of Xerces/Xalan in geronimo-boilerplate-jee5 
instead of geronimo-boilerplate-minimal, which adds unnecessary bloat 
back into the minimal assemblies again?


We could consider it. Putting them back into boilerplate-minimal was 
consistent with our G 1.1 and 1.2 structure. I certainly wouldn't call 
it "unecessary" and could do without painting the issue with words like 
"bloat". I could similarly describe your proposal as -- "could we remove 
Xerces/Xalan from the minimal server, so that we can break xml 
processing in that environment?


Good chance that we'll be pulling the xalan jar out, for other reasons. 
Since xalan is the biggest jar, I assume this helps?


--kevan




smime.p7s
Description: S/MIME Cryptographic Signature


[jira] Assigned: (GERONIMO-3183) fix offline deployment in minimal configurations

2007-05-22 Thread Donald Woods (JIRA)

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

Donald Woods reassigned GERONIMO-3183:
--

Assignee: Donald Woods

> fix offline deployment in minimal configurations
> 
>
> Key: GERONIMO-3183
> URL: https://issues.apache.org/jira/browse/GERONIMO-3183
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6
> Environment: Fedora Core 4
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
>Reporter: toby cabot
> Assigned To: Donald Woods
> Fix For: 2.0-M6
>
> Attachments: minimal-offline-patch.txt
>
>
> The deployer's offline mode in the jetty6-minimal and tomcat6-minimal 
> assemblies throws:
> org.apache.geronimo.kernel.config.LifecycleException: load of 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration()
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120)
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90)
> at 
> org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at 
> org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
> Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
> ... 19 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (GERONIMO-2775) Enabling web statistics collection for jetty fails from the admin console

2007-05-22 Thread Viet Hung Nguyen (JIRA)

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

Viet Hung Nguyen updated GERONIMO-2775:
---

Attachment: geronimo-2775.patch

I have made the 'enable' link to attempt to show the stats. But the statistics 
are currently being worked on, so what is shown does not mean anything.

> Enabling web statistics collection for jetty fails from the admin console
> -
>
> Key: GERONIMO-2775
> URL: https://issues.apache.org/jira/browse/GERONIMO-2775
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console, Jetty
>Affects Versions: 2.0-M2
> Environment: 2.0-SNAPSHOT jetty6 jee5 assembly
>Reporter: Paul McMahan
> Attachments: geronimo-2775.patch
>
>
> in the Web Server Manager portlet in the jetty assembly click on the "enable" 
> link for enabling statistics collection.  The click is ignored.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (SM-955) Archetype created files (e.g. xbean.xml) should not be Apache licensed.

2007-05-22 Thread Ken Geis (JIRA)
Archetype created files (e.g. xbean.xml) should not be Apache licensed.
---

 Key: SM-955
 URL: https://issues.apache.org/activemq/browse/SM-955
 Project: ServiceMix
  Issue Type: Wish
  Components: tooling
Affects Versions: 3.1
Reporter: Ken Geis
Priority: Minor


Do files generated by a Maven archetype like xbean.xml really need to have the 
Apache license on them?  This is burdensome.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (GERONIMO-3184) Add support for

2007-05-22 Thread Michael Malgeri (JIRA)
Add support for  
---

 Key: GERONIMO-3184
 URL: https://issues.apache.org/jira/browse/GERONIMO-3184
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: Tomcat
Reporter: Michael Malgeri


In tomcat if the following line, among other things,  is added to the serve.xml 
file



Tomcat will auto generate a mod_jk.conf file in the 
/usr/lib/apache-tomcat/conf/auto/ directory

The procedure is described at the following URL

http://www.howtoforge.com/apache2_tomcat5_mod_jk

Geronimo currently does not support the  tag in the config.xml file

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (GERONIMO-3184) Add support for

2007-05-22 Thread Jeff Genender (JIRA)

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

Jeff Genender reassigned GERONIMO-3184:
---

Assignee: Jeff Genender

> Add support for  
> ---
>
> Key: GERONIMO-3184
> URL: https://issues.apache.org/jira/browse/GERONIMO-3184
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Reporter: Michael Malgeri
> Assigned To: Jeff Genender
>
> In tomcat if the following line, among other things,  is added to the 
> serve.xml file
>  modJk="/usr/lib/apache2/modules/mod_jk.so" 
> workersConfig="/etc/apache2/workers.properties"/>
> Tomcat will auto generate a mod_jk.conf file in the 
> /usr/lib/apache-tomcat/conf/auto/ directory
> The procedure is described at the following URL
> http://www.howtoforge.com/apache2_tomcat5_mod_jk
> Geronimo currently does not support the  tag in the config.xml file

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (GERONIMO-2775) Enabling web statistics collection for jetty fails from the admin console

2007-05-22 Thread Anita Kulshreshtha (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498055
 ] 

Anita Kulshreshtha commented on GERONIMO-2775:
--

you should not need to add dependency on  geronimo-tomcat6. Also keeping the 
patch free of white space editing is very helpful.

> Enabling web statistics collection for jetty fails from the admin console
> -
>
> Key: GERONIMO-2775
> URL: https://issues.apache.org/jira/browse/GERONIMO-2775
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console, Jetty
>Affects Versions: 2.0-M2
> Environment: 2.0-SNAPSHOT jetty6 jee5 assembly
>Reporter: Paul McMahan
> Attachments: geronimo-2775.patch
>
>
> in the Web Server Manager portlet in the jetty assembly click on the "enable" 
> link for enabling statistics collection.  The click is ignored.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (GERONIMO-3183) fix offline deployment in minimal configurations

2007-05-22 Thread Donald Woods (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498059
 ] 

Donald Woods commented on GERONIMO-3183:


When I apply the patch, I still cannot deploy the Servlet-Examples war to the 
minimal Tomcat assembly using

   deploy -o deploy servlet-examples-2.0-SNAPSHOT.war

due to the persistant-jpa-deployer having a dependency on the openjpa config -

Caused by:
org.apache.geronimo.kernel.repository.MissingDependencyException:
Unable to resolve dependency
org.apache.geronimo.configs/openjpa//car


> fix offline deployment in minimal configurations
> 
>
> Key: GERONIMO-3183
> URL: https://issues.apache.org/jira/browse/GERONIMO-3183
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6
> Environment: Fedora Core 4
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
>Reporter: toby cabot
> Assigned To: Donald Woods
> Fix For: 2.0-M6
>
> Attachments: minimal-offline-patch.txt
>
>
> The deployer's offline mode in the jetty6-minimal and tomcat6-minimal 
> assemblies throws:
> org.apache.geronimo.kernel.config.LifecycleException: load of 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration()
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120)
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90)
> at 
> org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at 
> org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
> Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
> ... 19 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (GERONIMO-3183) fix offline deployment in minimal configurations

2007-05-22 Thread Donald Woods (JIRA)

[ 
https://issues.apache.org/jira/browse/GERONIMO-3183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498080
 ] 

Donald Woods commented on GERONIMO-3183:


Committed revision 540803 in trunk.
Applied the second-half of the patch, which adds some improved diagnostics.
Offline deployment still fails in the minimal assemblies for the Servlet 
examples war


> fix offline deployment in minimal configurations
> 
>
> Key: GERONIMO-3183
> URL: https://issues.apache.org/jira/browse/GERONIMO-3183
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6
> Environment: Fedora Core 4
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
>Reporter: toby cabot
> Assigned To: Donald Woods
> Fix For: 2.0-M6
>
> Attachments: minimal-offline-patch.txt
>
>
> The deployer's offline mode in the jetty6-minimal and tomcat6-minimal 
> assemblies throws:
> org.apache.geronimo.kernel.config.LifecycleException: load of 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration()
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120)
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90)
> at 
> org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at 
> org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
> Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
> ... 19 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (GERONIMO-2775) Enabling web statistics collection for jetty fails from the admin console

2007-05-22 Thread Viet Hung Nguyen (JIRA)

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

Viet Hung Nguyen updated GERONIMO-2775:
---

Attachment: geronimo-2775.patch

I have gotten rid of the extra things. Here is the updated patch.

> Enabling web statistics collection for jetty fails from the admin console
> -
>
> Key: GERONIMO-2775
> URL: https://issues.apache.org/jira/browse/GERONIMO-2775
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console, Jetty
>Affects Versions: 2.0-M2
> Environment: 2.0-SNAPSHOT jetty6 jee5 assembly
>Reporter: Paul McMahan
> Attachments: geronimo-2775.patch, geronimo-2775.patch
>
>
> in the Web Server Manager portlet in the jetty assembly click on the "enable" 
> link for enabling statistics collection.  The click is ignored.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (GERONIMO-3183) fix offline deployment in minimal configurations

2007-05-22 Thread Donald Woods (JIRA)

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

Donald Woods resolved GERONIMO-3183.


Resolution: Fixed
Regression: [Regression]

Committed revision 540815 in trunk.
Updated offline deplyer configs and verified that servlets-examples can be 
deployed to the minimal-tomcat assembly.
The minimal configs no longer include the jpa10-deployer, as they did not 
include openjpa.
Toby, thanks for testing this and supplying a patch.

> fix offline deployment in minimal configurations
> 
>
> Key: GERONIMO-3183
> URL: https://issues.apache.org/jira/browse/GERONIMO-3183
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6
> Environment: Fedora Core 4
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
>Reporter: toby cabot
> Assigned To: Donald Woods
> Fix For: 2.0-M6
>
> Attachments: minimal-offline-patch.txt
>
>
> The deployer's offline mode in the jetty6-minimal and tomcat6-minimal 
> assemblies throws:
> org.apache.geronimo.kernel.config.LifecycleException: load of 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car failed
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:274)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:253)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke()
> at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
> at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
> at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:127)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
> at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$26ac0679.loadConfiguration()
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.startPersistentOfflineConfigurations(OfflineDeployerStarter.java:120)
> at 
> org.apache.geronimo.deployment.cli.OfflineDeployerStarter.start(OfflineDeployerStarter.java:71)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.startOfflineDeployer(ServerConnection.java:102)
> at 
> org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:90)
> at 
> org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158)
> at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
> at 
> org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at 
> org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31)
> Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: 
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.0-SNAPSHOT/car
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:457)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:271)
> ... 19 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (GERONIMODEVTOOLS-146) Server won't start nicely due to missing setting of java.endorsed.dirs for Yoko

2007-05-22 Thread Ted Kirby (JIRA)

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

Ted Kirby updated GERONIMODEVTOOLS-146:
---

Attachment: GD146-3.patch

OK, done.  

I also set the org.apache.geronimo.base.dir and java.io.tmpdir system 
properties to fully match the geronimo start script.

server starts successfully.

> Server won't start nicely due to missing setting of java.endorsed.dirs for 
> Yoko
> ---
>
> Key: GERONIMODEVTOOLS-146
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-146
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.0
>Reporter: Ted Kirby
>Priority: Critical
> Attachments: GD146-2.patch, GD146-3.patch, GD146.patch
>
>
> Here are console messages:
> Booting Geronimo Kernel (in Java 1.5.0)...
> 17:03:26,609 ERROR [NameService] Incorrect level of org.omg.CORBA classes 
> found.
> Likely cause is an incorrect java.endorsed.dirs configuration
> 17:03:26,609 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="org.apache.geronimo.configs/j2ee-corba-yoko/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-corba-yoko/2.0-SNAPSHOT/car,j2eeType=CORBANameService,name=NameServer"
> org.apache.geronimo.gbean.InvalidConfigurationException: CORBA usage requires 
> Yoko CORBA spec classes in java.endorsed.dirs classpath
>   at org.apache.geronimo.corba.NameService.doStart(NameService.java:168)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:986)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> Need to set 
> -Djava.endorsed.dirs="%GERONIMO_BASE%\lib\endorsed;%JRE_HOME%\lib\endorsed", 
> like in geronimo.{sh,bat}
> If I set this manually as a server VM argument for the server instance, the 
> server starts fine.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.