[jira] Closed: (GERONIMO-1079) Better error for missing primkey-field

[Rakesh Midha (JIRA)]

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

Rakesh Midha closed GERONIMO-1079.
--

   Resolution: Fixed
Fix Version/s: (was: Verification Required)
   2.0-M1

Closing based on my previous comment
-
Looks like this problem is fixed in OpenEJB

If my primary key class is java.lang.Integer
I get failure with following message
Error: Unable to distribute myphonebook-ejb.jar: Could not deploy
module

Invalid primary key class: ejbName=MyPhonebookBean pkClass=class
java.lang.String

If my primary key class is any other class with non-static field
Error: Unable to distribute myphonebook-ejb.jar: Could not deploy module
caused by EJB [MyPhonebookBean] is misconfigured: could not find CMP
fields for following pk fields: [ABC] [XYZ]

The reason being a
If primary key class is provided and primary key name is not provided, deployer 
consider it as a compound key. Compound key with no non-static field is invalid 
primary key hence Invalid primary key class in case of java.lang.Integer. In 
other cases where compound key contains non-static field "could not found 
fields for following pk fields" for all the non-static fields.

I think this is working as required. Please confirm and close this JIRA.


> Better error for missing primkey-field
> --
>
> Key: GERONIMO-1079
> URL: https://issues.apache.org/jira/browse/GERONIMO-1079
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment, OpenEJB
>Affects Versions: 1.0-M5
>Reporter: Aaron Mulder
>Priority: Critical
> Fix For: 2.0-M1
>
>
> I forgot the primkey-field for my CMP entity, and I got this:
> Error: Unable to distribute LoadMagus.ear: Could not deploy module
> caused by EJB [TestRunMachine] is misconfigured: could not find CMP
> fields for following pk fields: [TYPE] [MAX_VALUE] [MIN_VALUE]
> Now, I don't know where it got TYPE, MAX_VALUE, and MIN_VALUE from -- those 
> are not fields on my EJB or the table or anything.  I did have a 
> prim-key-class set to java.lang.Integer, so perhaps it picked up the static 
> fields on java.lang.Integer (if so why?  I wouldn't have thought statics were 
> relevant).  It would be better if the error said "missing primkey-field or 
> prim-key-class does not have properties matching CMP field names" or 
> something like that.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-2707) Cannot deploy app client from ear

[Rakesh Midha (JIRA)]

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

Rakesh Midha closed GERONIMO-2707.
--

   Resolution: Invalid
Fix Version/s: 2.0


Closed this issue as a user error. (Invalid problem). The service was disabled 
and is enabled by default. So it is working as desired.

> Cannot deploy app client from ear
> -
>
> Key: GERONIMO-2707
> URL: https://issues.apache.org/jira/browse/GERONIMO-2707
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.1.1
> Environment: win xp, java 1.6.0, geronimo 1.1.1, core 2 duo 4GB, 
> myeclipse 5, wtp 1.5.2
>Reporter: Dario Andrade
> Fix For: 2.0
>
>
> When trying to deploy an ear with an application client, I get this error: 
> From the code, I can see the application client config builder is not defined 
> in the j2ee deployer.
> Publishing failed
>   Distribution of configuration failed.  See log for details.
> Cannot deploy app client; No app client deployer defined: 
> GManiaBatchClient.jar
> org.apache.geronimo.common.DeploymentException: Cannot deploy app client; 
> No app client deployer defined: GManiaBatchClient.jar
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:725)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:364)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:122)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>   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.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$601a27b4.getDeploymentPlan()
>   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232)
>   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
>   at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.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:122)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
>   at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338)
>   at 
> org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.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:122)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
>   at 
> org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1424)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1262)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1364)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:786)
>   at sun.reflect.GeneratedMethodAccessor271.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.M

Connecting to temporary queue

[MrRothstein]

Is there a way to connect to a temporary queue by name?'

I'm trying to do the following:
Component 1: Creates a jms message and a temp queue, puts the message on a
queue.
Component 2: Receives the jms message creates a request to another system,
sends the request.
Component 3: Receives a reply from the other system, creates a reply jms
message and puts in on the temporary queue for Component 1.

Is it possible to connect to the temp queue from component 3 if it doesn't
have a reference to the original request (can't do message.getJMSReplyTo())?

Thanks
-- 
View this message in context: 
http://www.nabble.com/Connecting-to-temporary-queue-tf2944008.html#a8232224
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: Web Builders

[anita kulshreshtha]

   The following classes are missing in geronimo-schema-jee-5 jar:
ConnectorDocument$Facty.class
ConnectorDocument.class
ConnectorType$Factory.class
ConnectorType.class
   Have they been renamed/moved? 

Thanks
Anita

--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:

> --- David Jencks <[EMAIL PROTECTED]> wrote:
> 
> > 
> > On Jan 8, 2007, at 9:20 PM, anita kulshreshtha wrote:
> > 
> > >Geronimo-web-2.5-builder uses geronimo-web-builder as a
> > dependency.
> > 
> > Yikes!!
> > > It brings in geronimo-servlet_2.4_spec and
> geronimo-schema-j2ee_1.4
> > as
> > > follows:
> > > web-builder - geronimo-servlet_2.4_spec
> > >   naming-builder --> j2ee-schema -->
> > > geronimo-schema-j2ee_1.4
> > > Should naming-builder be changed to use 1.5?
> > 
> > yes.
> > 
> > > Should we remove
> > > dependency on web-builder and move all the stuff to
> > web-2.5-builder?
> > 
> > Very definitely!!  It looks like both the jetty and tomcat builders
>  
> > are already using the web25 AbstractWebBuilder so there should be
> no 
> > 
> > problems there.
> > 
> > Can you do this?  Thanks for noticing this problem!!!
> 
> Sure..
> 
> Anita
> 
> > 
> > thanks
> > david jencks
> > 
> > >
> > > Thanks
> > > Anita
> > >
> > > __
> > > Do You Yahoo!?
> > > Tired of spam?  Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > 
> > 
> 
> 
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[jira] Created: (GERONIMO-2711) specs/trunk fails to build

[Donald Woods (JIRA)]

specs/trunk fails to build
--

 Key: GERONIMO-2711
 URL: https://issues.apache.org/jira/browse/GERONIMO-2711
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: specs
Affects Versions: 2.0-M2
Reporter: Donald Woods
 Assigned To: Donald Woods
 Fix For: 2.0-M2


geronimo-ejb_3.0_spec was released, but not removed from specs/trunk/pom.xml
geronimo-commonj_1.1_spec fails to build, because it is trying to use 
org.apache.geronimo.specs.specs version=1.2-SNAPSHOT instead of 1.2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r494291 - in /geronimo/server/branches/1.2: assemblies/geronimo-boilerplate-minimal/ modules/geronimo-client-builder/src/main/java/org/apache/geronimo/client/builder/jsr88/ modules/ger

[Jason Dillon]

On Jan 8, 2007, at 11:00 PM, David Jencks wrote:
I don't like adding more and more to lib. if this is only  
needed for jsr88 stuff I think we should consider starting up  
something on request to load the configurer gbeas and register  
them, using the repo.


Me either... if we can avoid adding more stuff to lib/ it would be  
better IMO.


--jason

Re: svn commit: r494291 - in /geronimo/server/branches/1.2: assemblies/geronimo-boilerplate-minimal/ modules/geronimo-client-builder/src/main/java/org/apache/geronimo/client/builder/jsr88/ modules/ger

[David Jencks]

On Jan 8, 2007, at 8:21 PM, [EMAIL PROTECTED] wrote:


Author: kevan
Date: Mon Jan  8 17:21:35 2007
New Revision: 494291

URL: http://svn.apache.org/viewvc?view=rev&rev=494291
Log:
Fix some deploy problems. geronimo-deploy-config needs to be in lib.


What goes wrong if it isn't?  I wondered if this would be a problem.


New Configurers needed to be serializable...


what happens if they aren't?  If we can't get away from this we  
should make ModuleConfigurer extend Serializable...


I don't like adding more and more to lib. if this is only needed  
for jsr88 stuff I think we should consider starting up something on  
request to load the configurer gbeas and register them, using the repo.


thanks
david jencks

Re: update on the Geronimo Plugin Central community site (longish)

[jason . dillon]

We can use the new plugin site to pay for stuff? Swet :-P

--jason

  

-Original Message-
From: Matt Hogstrom <[EMAIL PROTECTED]>
Date: Mon, 8 Jan 2007 21:52:15 
To:dev@geronimo.apache.org
Subject: Re: update on the Geronimo Plugin Central community site (longish)

Looks nice Paul...just got back from a trip but I'll pay with it more  
later :)


Matt Hogstrom
[EMAIL PROTECTED]

Re: update on the Geronimo Plugin Central community site (longish)

[Matt Hogstrom]

Looks nice Paul...just got back from a trip but I'll pay with it more  
later :)



Matt Hogstrom
[EMAIL PROTECTED]

Re: Web Builders

[anita kulshreshtha]

--- David Jencks <[EMAIL PROTECTED]> wrote:

> 
> On Jan 8, 2007, at 9:20 PM, anita kulshreshtha wrote:
> 
> >Geronimo-web-2.5-builder uses geronimo-web-builder as a
> dependency.
> 
> Yikes!!
> > It brings in geronimo-servlet_2.4_spec and geronimo-schema-j2ee_1.4
> as
> > follows:
> > web-builder - geronimo-servlet_2.4_spec
> >   naming-builder --> j2ee-schema -->
> > geronimo-schema-j2ee_1.4
> > Should naming-builder be changed to use 1.5?
> 
> yes.
> 
> > Should we remove
> > dependency on web-builder and move all the stuff to
> web-2.5-builder?
> 
> Very definitely!!  It looks like both the jetty and tomcat builders  
> are already using the web25 AbstractWebBuilder so there should be no 
> 
> problems there.
> 
> Can you do this?  Thanks for noticing this problem!!!

Sure..

Anita

> 
> thanks
> david jencks
> 
> >
> > Thanks
> > Anita
> >
> > __
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Web Builders

[David Jencks]

On Jan 8, 2007, at 9:20 PM, anita kulshreshtha wrote:


   Geronimo-web-2.5-builder uses geronimo-web-builder as a dependency.


Yikes!!

It brings in geronimo-servlet_2.4_spec and geronimo-schema-j2ee_1.4 as
follows:
web-builder - geronimo-servlet_2.4_spec
  naming-builder --> j2ee-schema -->
geronimo-schema-j2ee_1.4
Should naming-builder be changed to use 1.5?


yes.


Should we remove
dependency on web-builder and move all the stuff to web-2.5-builder?


Very definitely!!  It looks like both the jetty and tomcat builders  
are already using the web25 AbstractWebBuilder so there should be no  
problems there.


Can you do this?  Thanks for noticing this problem!!!

thanks
david jencks



Thanks
Anita

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Web Builders

[anita kulshreshtha]

   Geronimo-web-2.5-builder uses geronimo-web-builder as a dependency.
It brings in geronimo-servlet_2.4_spec and geronimo-schema-j2ee_1.4 as
follows:
web-builder - geronimo-servlet_2.4_spec
  naming-builder --> j2ee-schema -->
geronimo-schema-j2ee_1.4
Should naming-builder be changed to use 1.5? Should we remove
dependency on web-builder and move all the stuff to web-2.5-builder?

Thanks
Anita

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Integration with mainframe

[bradburyn]

Has anyone done any work using servicemix to integrate with mainframe
applications like CICS, DB2, IMS.

I have read that there is a MQSeries adapter that can be used using JMS, but
would like to know what is out there.


-- 
View this message in context: 
http://www.nabble.com/Integration-with-mainframe-tf2942838s12049.html#a8228905
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

[jira] Created: (GERONIMO-2710) Annotations Support Tasklist

[Tim McConnell (JIRA)]

Annotations Support Tasklist


 Key: GERONIMO-2710
 URL: https://issues.apache.org/jira/browse/GERONIMO-2710
 Project: Geronimo
  Issue Type: Task
  Security Level: public (Regular issues)
Affects Versions: 2.0
Reporter: Tim McConnell
 Assigned To: Tim McConnell
 Fix For: 2.0


All tasks required to support annotations for Geronimo

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2650) JSP 2.1 error in Jetty/Tomcat

[Prasad Kashyap (JIRA)]

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

Prasad Kashyap updated GERONIMO-2650:
-

Affects Version/s: 2.0
   2.0-M2
Fix Version/s: 2.0
   2.0-M2

> JSP 2.1 error in Jetty/Tomcat
> -
>
> Key: GERONIMO-2650
> URL: https://issues.apache.org/jira/browse/GERONIMO-2650
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 2.0-M1, 2.0-M2, 2.0
>Reporter: Krishnakumar B
> Assigned To: Joe Bohn
> Fix For: 2.0-M2, 2.0
>
> Attachments: SampleJSP.war
>
>
> Deploying a web application with JSP 2.1 features throws error in Jetty and 
> Tomcat
> On Tomcat 6:
> ---
> org.apache.jasper.JasperException: /SampleJSP.jsp(12,35) #{..} is not allowed 
> in template text
>  
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
>  org.apache.jasper.compiler.ErrorDispatcher.dispatch 
> (ErrorDispatcher.java:406)
>  org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:101)
>  
> org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:710)
>  org.apache.jasper.compiler.Node$ELExpression.accept (Node.java:935)
>  org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
>  org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386)
>  org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2392)
>  org.apache.jasper.compiler.Node$Root.accept (Node.java:489)
>  org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
>  org.apache.jasper.compiler.Validator.validate(Validator.java:1679)
>  org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:178) 
>  org.apache.jasper.compiler.Compiler.compile(Compiler.java:306)
>  org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
>  org.apache.jasper.compiler.Compiler.compile(Compiler.java:273)
>  org.apache.jasper.JspCompilationContext.compile 
> (JspCompilationContext.java:566)
>  
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:314)
>  org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
>  org.apache.jasper.servlet.JspServlet.service (JspServlet.java:266)
>  javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>  
> On Jetty 6.0:
> 
> org.apache.jasper.JasperException: /SampleJSP.jsp(12,35) #{..} is not allowed 
> in template text
> at 
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
> at org.apache.jasper.compiler.ErrorDispatcher.dispatch 
> (ErrorDispatcher.java:406)
> at 
> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:101)
> at 
> org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:710)
> at org.apache.jasper.compiler.Node$ELExpression.accept (Node.java:935)
> at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
> at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2386)
> at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2392) 
> at org.apache.jasper.compiler.Node$Root.accept(Node.java:489)
> at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2336)
> at org.apache.jasper.compiler.Validator.validate(Validator.java:1679)
> at org.apache.jasper.compiler.Compiler.generateJava (Compiler.java:178)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:306)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java :273)
> at 
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:566)
> at 
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:314)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:320)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java :459)
> at 
> org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:62)
> at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
> at org.apache.geronimo.jetty6.JettyServletHandler.doHandle 
> (JettyServletHandler.java:55)
> at 
> org.apache.geronimo.jetty6.JettyServletHandler$ActualJettyServletHandler.handle(JettyServletHandler.java:62)
> at org.apache.geronimo.jetty6.JettyServletHandler$NoOpChainedHandler.handle 
> (JettyServletHandler.java:70)
> at 
> org.apache.geronimo.jetty6.JettyServletHandler.handle(JettyServletHandler.java:47)
> at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
> at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle 
> (ThreadClassloaderH

[jira] Updated: (GERONIMO-2703) JSR-252 Tasklist (JSF 1.2)

[Tim McConnell (JIRA)]

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

Tim McConnell updated GERONIMO-2703:


Description: All tasks related to the integration of JSR-252 (JSF 1.2)  
(was: All tasks related to the integration of JSR-250 (JSF 1.2))
Summary: JSR-252 Tasklist  (JSF 1.2)  (was: JSR-250 Tasklist  (JSF 1.2))

> JSR-252 Tasklist  (JSF 1.2)
> ---
>
> Key: GERONIMO-2703
> URL: https://issues.apache.org/jira/browse/GERONIMO-2703
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 2.0
>Reporter: Tim McConnell
> Assigned To: Tim McConnell
> Fix For: 2.0
>
>
> All tasks related to the integration of JSR-252 (JSF 1.2)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-2709) Database creation pool wizard fails in Jetty

[Hernan Cunico (JIRA)]

Database creation pool wizard fails in Jetty


 Key: GERONIMO-2709
 URL: https://issues.apache.org/jira/browse/GERONIMO-2709
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: console, databases
Affects Versions: 2.0-M1, 2.0
 Environment: Jetty Dist. rev #494097. Related to GERONIMO-2685
Reporter: Hernan Cunico
Priority: Critical


DB Pool creation wizard fails on Jetty distribution. It will now list the 
available database types (step 1) but once you click next the console is gone. 

The following error is displayed on the terminal. I can't set log to DEBUG, if 
so I loose control on Jetty (wont even pass login screen - different issue)

2007-01-08 15:32:21.671::WARN:  EXCEPTION
java.lang.IllegalArgumentException: Qualifier patterns must be present when 
first URLPattern is an exact pattern
at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:98)
at 
javax.security.jacc.WebUserDataPermission.(WebUserDataPermission.java:86)
at 
org.apache.geronimo.jetty6.handler.JettySecurityHandler.checkSecurityConstraints(JettySecurityHandler.java:183)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:171)
at 
org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:133)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at 
org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46)
at 
org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47)
at 
org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:58)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:146)
at 
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:751)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:203)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at 
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:217)
at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Server shutdown begun
Server shutdown completed

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Assemblies assemblies everywhere and which one to ship?

[Dain Sundstrom]

On Jan 8, 2007, at 11:59 AM, Andrus Adamchik wrote:



On Jan 8, 2007, at 9:39 PM, Dain Sundstrom wrote:

Well, we depend on being able to listen to events on the EM which  
there is no spec interface for.  I'm sure Cayanne has and  
interface that can provide us with the events, and when they send  
us the info we can add a hook for their Impl.


What kind of events?


We need afterLoad, beforeStore, afterAttach, beforeDelete, and  
afterDetach so we can make the proper EJB Entity bean callbacks.  The  
code we use for OpenJPA is here:


http://svn.apache.org/viewvc/incubator/openejb/trunk/openejb3/ 
container/openejb-core/src/main/java/org/apache/openejb/core/cmp/jpa/ 
JpaCmpEngine.java?revision=492404&view=markup&pathrev=492419


look for OpenJPALifecycleListener inner class.

-dain   

[jira] Closed: (GERONIMO-2642) welcome app not included in the jetty assembly.

[Joe Bohn (JIRA)]

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

Joe Bohn closed GERONIMO-2642.
--

Resolution: Fixed

> welcome app not included in the jetty assembly.
> ---
>
> Key: GERONIMO-2642
> URL: https://issues.apache.org/jira/browse/GERONIMO-2642
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: buildsystem
>Affects Versions: 2.0-M1
>Reporter: Prasad Kashyap
> Assigned To: Joe Bohn
> Fix For: 2.0-M1
>
>
> geronimo-welcome-jetty not included in the jetty assembly

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] Closed: (GERONIMO-2686) database creation pool wizzard fails to deploy

[Hernan Cunico]

OK, after openejb 2.3 snap was released, whacking the local repo and rebuilding 
(clean install) the problem is gone in Tomcat, Jetty however still have 
problems.
I'll test it further and open a JIRA.

Cheers!
Hernan

Hernan Cunico wrote:

Howdy,
I still see this behavior in rev #494097. Any ideas?

Cheers!
Hernan

David Jencks (JIRA) wrote:
 [ 
https://issues.apache.org/jira/browse/GERONIMO-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
]


David Jencks closed GERONIMO-2686.
--

Resolution: Fixed

Relevant stuff ported to 1.2 in rev 493252.

I can't find out what if any openejb2 version is supposed to go with g 
1.2 so if the correct version is not 2.3 openejb2 may not build.



database creation pool wizzard fails to deploy
--

Key: GERONIMO-2686
URL: https://issues.apache.org/jira/browse/GERONIMO-2686
Project: Geronimo
 Issue Type: Bug
 Security Level: public(Regular issues)Affects Versions: 1.2, 
2.0-M1

Environment: Tomcat distribution
   Reporter: Hernan Cunico
Assigned To: David Jencks
   Priority: Critical
Fix For: 1.2, 2.0-M2


From the console, the database creation pool wizzard does not create 
a plan and fails to deploy it with no warnings on the Administration 
Console. The terminal shows the following error:
ERROR [DatabasePoolPortlet] Unable to save connection 
pooljavax.enterprise.deploy.spi.exceptions.InvalidModuleException: 
Not supported at 
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:297) 
at 
org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) 
at 
org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:341) 
at 
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) 
at 
org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) 
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at 
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 
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:683) 
at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:585) 
at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505) 
at 
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) 
at 
org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) 
at 
org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) 
at 
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) 
at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at 
org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at 
org.apache.catalina.core.ApplicationF
ilterChain.internalDoFilter(ApplicationFilterChain.java:290) at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) 
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:325) 
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:105) 
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 
at org.apache.cata
lina.valves.AccessLogValve.invoke(AccessLogValve.java:542) at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) 
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818) 
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624) 
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) 
at java.lang.Thread.run(Thread.java:595)

Re: Assemblies assemblies everywhere and which one to ship?

[Andrus Adamchik]

On Jan 8, 2007, at 9:39 PM, Dain Sundstrom wrote:

Well, we depend on being able to listen to events on the EM which  
there is no spec interface for.  I'm sure Cayanne has and interface  
that can provide us with the events, and when they send us the info  
we can add a hook for their Impl.


What kind of events?

Andrus

Re: Assemblies assemblies everywhere and which one to ship?

[Andrus Adamchik]

On Jan 8, 2007, at 9:46 PM, Dain Sundstrom wrote:

FWIU, JPA has a separate TCK for certification.  You should ask on  
jcp-open at apache.org.


We'll try that - thanks!

Andrus

Re: Assemblies assemblies everywhere and which one to ship?

[Dain Sundstrom]

On Jan 8, 2007, at 10:18 AM, Andrus Adamchik wrote:


(I'm not sure of the state of Cayenne)


It looks like Geronimo are the caretakers of the Sun TCK at Apache  
(something we, Cayenne developers, still can't get access to).  
While Cayenne JPA provider requires fair amount of work to be  
compliant, it would be really helpful in our own testing effort if  
we could test our provider as a part of Geronimo assembly against  
the TCK. A decision on the readiness of a given assembly can be  
made around a release time, but it would be really nice if we could  
participate in the TCK testing. How can we help with this BTW?


FWIU, JPA has a separate TCK for certification.  You should ask on  
jcp-open at apache.org.


-dain

Re: trunk wont start

[Jason Dillon]

You would have had to nuke your repo or mvn -U

--jason


On Jan 8, 2007, at 2:15 PM, Hernan Cunico wrote:

I just did a clean install and still see the runtime issue. Do I  
have to wack the local repo and rebuild again?


Cheers!
Hernan

Kevan Miller wrote:

On Jan 8, 2007, at 11:48 AM, Jason Dillon wrote:

Can someone from the openejb team please publish new snaps.

OK. Current 2.3-SNAPSHOT has been published...
--kevan

Re: Assemblies assemblies everywhere and which one to ship?

[Dain Sundstrom]

On Jan 7, 2007, at 9:38 PM, David Jencks wrote:


On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote:

I was thinking about M2 this weekend and was considering many of  
the challenges we face in putting out certified releases.  Up till  
now the number of permutations has been pretty limited and that  
has been Jetty and Tomcat.  With Java EE 5.0 life is no longer  
that simple.  Here are the choices I know of today:


Web Container (Tomcat / Jetty)
WebServices (Axis 2 / CXF)
EJB 3.0 Persistence (OpenJPA / Cayenne)

I think this makes 6 different assemblies and of course 6 separate  
certification efforts.  Perhaps we can do this and perhaps we  
can't.  Based on where projects are at and their desire to  
participate in helping to integrate (and do TCK testing :).


ummm 2 * 2 * 2 == 8

I could be very wrong but I thought that the cmp 2.1 support in  
openejb3 was relying on openjpa-specific features.  If so I wonder  
if it will be tricky to run the tck on other jpa implementations.


Well, we depend on being able to listen to events on the EM which  
there is no spec interface for.  I'm sure Cayanne has and interface  
that can provide us with the events, and when they send us the info  
we can add a hook for their Impl.


In general, I think we should just pick a single JPA implementation  
to ship with G because it is very easy for an application to request  
a different implementation using specification defined properties.


Of course that will leave us with 4 javaee assemblies and 2 minimal  
assemblies.


-dain

[jira] Created: (SM-807) Add jboss-service.xml to servicemix component so they can be properly deployed in jboss.

[Eric Dofonsou (JIRA)]

Add jboss-service.xml to servicemix component so they can be properly deployed 
in jboss.


 Key: SM-807
 URL: https://issues.apache.org/activemq/browse/SM-807
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-assembly, servicemix-audit, servicemix-bpe, 
servicemix-common, servicemix-components, servicemix-core, servicemix-drools, 
servicemix-eip, servicemix-file, servicemix-ftp, servicemix-http, 
servicemix-jbi, servicemix-jms, servicemix-jsr181, servicemix-lwcontainer, 
servicemix-quartz, servicemix-saxon, servicemix-sca, servicemix-script, 
servicemix-soap, servicemix-wsn2005
Affects Versions: 3.1
 Environment: JBoss 4.0.5 GA
Reporter: Eric Dofonsou
 Fix For: 3.1


Right now there are no dependencies set on the servicemix components to ensure 
that they are loaded after the servicemix deployer.  This can cause bugs when 
the component are deployed before the servicemix deployer, and thus are not 
handled by servicemix (and therefore not available).

The fix for this is do include a dependence in the META-INF/jboss-service.xml 
of the component .zip file. here is the content of the file :
-


org.servicemix:service=Deployer


-

PS : The servicemix-http component already has a jboss-web.xml see issue 
(SM-584) file this should be deleted and the content of the new 
jboss-service.xml file should now be :
-


  



  org.apache.commons.httpclient:loader=commons-httpclient-3.0.jar



  

org.servicemix:service=Deployer



---

Eric,

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] Closed: (GERONIMO-2686) database creation pool wizzard fails to deploy

[Hernan Cunico]

Howdy,
I still see this behavior in rev #494097. Any ideas?

Cheers!
Hernan

David Jencks (JIRA) wrote:

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

David Jencks closed GERONIMO-2686.
--

Resolution: Fixed

Relevant stuff ported to 1.2 in rev 493252.

I can't find out what if any openejb2 version is supposed to go with g 1.2 so 
if the correct version is not 2.3 openejb2 may not build.


database creation pool wizzard fails to deploy
--

Key: GERONIMO-2686
URL: https://issues.apache.org/jira/browse/GERONIMO-2686
Project: Geronimo
 Issue Type: Bug
 Security Level: public(Regular issues) 
   Affects Versions: 1.2, 2.0-M1

Environment: Tomcat distribution
   Reporter: Hernan Cunico
Assigned To: David Jencks
   Priority: Critical
Fix For: 1.2, 2.0-M2


From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. 
The terminal shows the following error:

ERROR [DatabasePoolPortlet] Unable to save connection 
pooljavax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not 
supported at 
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:297)
 at 
org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880)
 at 
org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:341)
 at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at 
org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at 
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 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:683)
 at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:585)
 at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
 at 
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
 at 
org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
 at 
org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
 at 
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
 at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at 
org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:713) at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at 
org.apache.catalina.core.ApplicationF
ilterChain.internalDoFilter(ApplicationFilterChain.java:290) at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
 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:325)
 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:105) 
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.cata
lina.valves.AccessLogValve.invoke(AccessLogValve.java:542) at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818) at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at 
java.lang.Thread.run(Thread.java:595)

Re: trunk wont start

[Hernan Cunico]

I just did a clean install and still see the runtime issue. Do I have to wack 
the local repo and rebuild again?

Cheers!
Hernan

Kevan Miller wrote:


On Jan 8, 2007, at 11:48 AM, Jason Dillon wrote:


Can someone from the openejb team please publish new snaps.


OK. Current 2.3-SNAPSHOT has been published...

--kevan

[jira] Commented: (GERONIMO-2707) Cannot deploy app client from ear

[Dario Andrade (JIRA)]

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

Dario Andrade commented on GERONIMO-2707:
-

My apologies, I must have disabled the client-deployer system component at 
first place, since the distribution comes with that enabled by default. I 
believe the issue is now closed.

> Cannot deploy app client from ear
> -
>
> Key: GERONIMO-2707
> URL: https://issues.apache.org/jira/browse/GERONIMO-2707
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.1.1
> Environment: win xp, java 1.6.0, geronimo 1.1.1, core 2 duo 4GB, 
> myeclipse 5, wtp 1.5.2
>Reporter: Dario Andrade
>
> When trying to deploy an ear with an application client, I get this error: 
> From the code, I can see the application client config builder is not defined 
> in the j2ee deployer.
> Publishing failed
>   Distribution of configuration failed.  See log for details.
> Cannot deploy app client; No app client deployer defined: 
> GManiaBatchClient.jar
> org.apache.geronimo.common.DeploymentException: Cannot deploy app client; 
> No app client deployer defined: GManiaBatchClient.jar
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:725)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:364)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:122)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>   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.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$601a27b4.getDeploymentPlan()
>   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232)
>   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
>   at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.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:122)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
>   at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338)
>   at 
> org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.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:122)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
>   at 
> org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1424)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1262)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1364)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:786)
>   at sun.reflect.GeneratedMethodAccessor271.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.

[jira] Updated: (GERONIMO-2651) Servlet annotations are not supported

[Prasad Kashyap (JIRA)]

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

Prasad Kashyap updated GERONIMO-2651:
-

Affects Version/s: 2.0
Fix Version/s: 2.0
   2.0-M2

> Servlet annotations are not supported
> -
>
> Key: GERONIMO-2651
> URL: https://issues.apache.org/jira/browse/GERONIMO-2651
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 2.0-M1, 2.0-M2, 2.0
>Reporter: Krishnakumar B
> Assigned To: Paul McMahan
> Fix For: 2.0-M2, 2.0
>
>
> Servlet JEE5 annotations are not supported. ( I have tried @Resource in 
> servlet to get reference to a datasource.)
> Not sure which release this is targetted at so adding it to 2.0-M1 & 2.0-M2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (SM-806) Error when deploying a SA using the jbi maven plugin when a component is stopped

[Guillaume Nodet (JIRA)]

Error when deploying a SA using the jbi maven plugin when a component is stopped


 Key: SM-806
 URL: https://issues.apache.org/activemq/browse/SM-806
 Project: ServiceMix
  Issue Type: Bug
  Components: tooling
Reporter: Guillaume Nodet




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (GERONIMO-2651) Servlet annotations are not supported

[Prasad Kashyap (JIRA)]

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

Prasad Kashyap reassigned GERONIMO-2651:


Assignee: Paul McMahan

> Servlet annotations are not supported
> -
>
> Key: GERONIMO-2651
> URL: https://issues.apache.org/jira/browse/GERONIMO-2651
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 2.0-M1, 2.0-M2
>Reporter: Krishnakumar B
> Assigned To: Paul McMahan
>
> Servlet JEE5 annotations are not supported. ( I have tried @Resource in 
> servlet to get reference to a datasource.)
> Not sure which release this is targetted at so adding it to 2.0-M1 & 2.0-M2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2664) Servlet Filter Error

[Prasad Kashyap (JIRA)]

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

Prasad Kashyap updated GERONIMO-2664:
-

Affects Version/s: 2.0-M2

> Servlet Filter Error
> 
>
> Key: GERONIMO-2664
> URL: https://issues.apache.org/jira/browse/GERONIMO-2664
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Jetty, Tomcat
>Affects Versions: 2.0-M1, 2.0-M2, 2.0
>Reporter: Krishnakumar B
> Assigned To: Joe Bohn
> Fix For: 2.0-M2, 2.0
>
>
> Trying out servlet name with a wild card ( * ) in Filter throws exception in 
> Jetty. In tomcat the filter is not called at all
> 
>  Sample Filter
>  *
> 
> instead of
> Sample Filter
> 
> SampleServlet
> AnotherSampleServlet
> Jetty
> 14:21:50,780 ERROR [Deployer] Deployment failed due to
> java.lang.AssertionError:
> javax.management.MalformedObjectNameException: Invalid character `*'
> in value
>at 
> org.apache.geronimo.kernel.Jsr77Naming.createObjectName(Jsr77Naming.java:112)
>at 
> org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:80)
>at 
> org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:54)
>at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addFilterMappingsGBeans(JettyModuleBuilder.java:614)
>at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:483)
>at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.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:124)
>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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8c79360e.addGBeans()
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165)
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.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:124)
>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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8c79360e.addGBeans()
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:572)
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:124)
>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.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$c3a6b023.buildConfiguration()
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302)
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
>at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.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.j

[jira] Updated: (GERONIMO-2664) Servlet Filter Error

[Prasad Kashyap (JIRA)]

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

Prasad Kashyap updated GERONIMO-2664:
-

Affects Version/s: 2.0
Fix Version/s: 2.0
   2.0-M2

> Servlet Filter Error
> 
>
> Key: GERONIMO-2664
> URL: https://issues.apache.org/jira/browse/GERONIMO-2664
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Jetty, Tomcat
>Affects Versions: 2.0-M1, 2.0
>Reporter: Krishnakumar B
> Assigned To: Joe Bohn
> Fix For: 2.0-M2, 2.0
>
>
> Trying out servlet name with a wild card ( * ) in Filter throws exception in 
> Jetty. In tomcat the filter is not called at all
> 
>  Sample Filter
>  *
> 
> instead of
> Sample Filter
> 
> SampleServlet
> AnotherSampleServlet
> Jetty
> 14:21:50,780 ERROR [Deployer] Deployment failed due to
> java.lang.AssertionError:
> javax.management.MalformedObjectNameException: Invalid character `*'
> in value
>at 
> org.apache.geronimo.kernel.Jsr77Naming.createObjectName(Jsr77Naming.java:112)
>at 
> org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:80)
>at 
> org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:54)
>at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addFilterMappingsGBeans(JettyModuleBuilder.java:614)
>at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:483)
>at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.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:124)
>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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8c79360e.addGBeans()
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165)
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.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:124)
>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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8c79360e.addGBeans()
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:572)
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:124)
>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.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$c3a6b023.buildConfiguration()
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302)
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
>at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.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.

[jira] Assigned: (GERONIMO-2664) Servlet Filter Error

[Prasad Kashyap (JIRA)]

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

Prasad Kashyap reassigned GERONIMO-2664:


Assignee: Joe Bohn

http://www.nabble.com/forum/ViewPost.jtp?post=7869532&framed=y

> Servlet Filter Error
> 
>
> Key: GERONIMO-2664
> URL: https://issues.apache.org/jira/browse/GERONIMO-2664
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Jetty, Tomcat
>Affects Versions: 2.0-M1, 2.0
>Reporter: Krishnakumar B
> Assigned To: Joe Bohn
> Fix For: 2.0-M2, 2.0
>
>
> Trying out servlet name with a wild card ( * ) in Filter throws exception in 
> Jetty. In tomcat the filter is not called at all
> 
>  Sample Filter
>  *
> 
> instead of
> Sample Filter
> 
> SampleServlet
> AnotherSampleServlet
> Jetty
> 14:21:50,780 ERROR [Deployer] Deployment failed due to
> java.lang.AssertionError:
> javax.management.MalformedObjectNameException: Invalid character `*'
> in value
>at 
> org.apache.geronimo.kernel.Jsr77Naming.createObjectName(Jsr77Naming.java:112)
>at 
> org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:80)
>at 
> org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:54)
>at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addFilterMappingsGBeans(JettyModuleBuilder.java:614)
>at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:483)
>at 
> org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.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:124)
>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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8c79360e.addGBeans()
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165)
>at 
> org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.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:124)
>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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$8c79360e.addGBeans()
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:572)
>at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:124)
>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.j2ee.deployment.CorbaGBeanNameSource$$EnhancerByCGLIB$$c3a6b023.buildConfiguration()
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302)
>at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
>at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.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.geroni

[jira] Commented: (AMQ-1121) Kaha DB hangs on restart

[Vadim Pesochinskiy (JIRA)]

[ 
https://issues.apache.org/activemq/browse/AMQ-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37838
 ] 

Vadim Pesochinskiy commented on AMQ-1121:
-

There are about 30 parties doing concurrent request / response messaging for 
about 20 minutes. At the end I stop AMQ and I get that error on restart. You 
just need to do more concurrent testing. It does not happen if I configure 
Journal JDBC with Derby. I am sorry I cannot write unit test at the moment.

> Kaha DB hangs on restart
> 
>
> Key: AMQ-1121
> URL: https://issues.apache.org/activemq/browse/AMQ-1121
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Message Store
>Affects Versions: 4.1.0
> Environment: Windows XP, NetApp
>Reporter: Vadim Pesochinskiy
> Assigned To: Rob Davies
>Priority: Blocker
> Fix For: 4.1.0
>
>
> I run a bunch or messages through AMQ, then restarted AMQ and it hangs. 
> Following are the last messages that I see. AMQ is not listening on the 
> configured port.
> 2007-01-06 01:35:29,723 [main   ] DEBUG DataManager   
>  - End of data file reached at (header was invalid): offset = 810, file = 1, 
> size = 219
> 2007-01-06 01:35:29,754 [JMX connector  ] INFO  ManagementContext 
>  - JMX consoles can connect to 
> service:jmx:rmi:///jndi/rmi://localhost:11099/jmxrmi
> 2007-01-06 01:35:32,660 [main   ] DEBUG DataManager   
>  - End of data file reached at (header was invalid): offset = 88244949, file 
> = 5, size = 100856

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

update on the Geronimo Plugin Central community site (longish)

[Paul McMahan]

I got a lot of great responses when I asked this list for feedback on
Geronimo Plugin Central a few months ago.  Since then I have been
devoting some spare bandwidth towards improving the site.   At this
point I would consider its readiness for the community at large to be
at the "beta" phase and thought you might be interested in taking
another look.  The URL is http://geronimoplugincentral.org/.

Here are some of the recent improvements to the site:
-  Installed new forum software (SMF) which is easier to use and
integrates better
  into the site
-  Installed a much better plugin directory and review system
-  Seeded the site with a few plugins, reviews, and discussion topics.
-  Relocated to a new hosting service that provides better administration and
   response time
-  Several improvements to the site design and organization

As a reminder,  Geronimo Plugin Central (GPIC) is a non-profit
community site for Geronimo plugin users and developers.  It is based
on the highly successful Eclipse Plugin Central which provides a
directory of Eclipse plugins with user reviews and discussion forums.
GPIC plays a complimentary role to Geronimo plugin repositories like
geronimoplugins.com by providing a central hub for the user community
where they can find and rate plugins as well and have discussions
about them.   My own personal goal is for this site to be eventually
governed by the Geronimo PMC, similar to how the Eclipse Foundation
governs Eclipse Plugin Central.  If you're interested in the
background discussion on GPIC see http://tinyurl.com/yaafrl for
starters.

If you would like to get involved with this effort then here are some
areas where help is needed:
-  enhancing (and proofing) the current content on the site
-  adding new content to the site -- discussion topics, new plugins
and reviews, etc.
  there are some more plugins at geronimoplugins.com that I think
should be listed
  if that's allowed
-  administration of the CMS that runs the site (Joomla).  for example
the RSS feed
  currently doesn't work
-  routine moderation of the site contents (user submitted plugins, reviews, and
  discussion topics).
-  improving the site templates for a better look and feel
-  enhance Geronimo's plugin schema to support multiple
versions/locations per plugin.
  this will greatly simplify the plugin download & install process.
-  automation of the site, e.g. adding the ability to import content
from a XML plugin catalog
-  any other improvements you can think of that would make the site better

Looking forward to your feedback and participation in this effort!

Best wishes,
Paul

Re: Assemblies assemblies everywhere and which one to ship?

[Andrus Adamchik]

(I'm not sure of the state of Cayenne)


It looks like Geronimo are the caretakers of the Sun TCK at Apache  
(something we, Cayenne developers, still can't get access to). While  
Cayenne JPA provider requires fair amount of work to be compliant, it  
would be really helpful in our own testing effort if we could test  
our provider as a part of Geronimo assembly against the TCK. A  
decision on the readiness of a given assembly can be made around a  
release time, but it would be really nice if we could participate in  
the TCK testing. How can we help with this BTW?


Andrus




On Jan 8, 2007, at 8:08 PM, Matt Hogstrom wrote:
I don't think its just TCK.  I agree we should scope the  
configuration to a limited set but I'm also concerned about making  
assemblies available.  Given my math challenged 6 which is really 8  
I don't think we would want to generate every one of them.  So I  
think from the download page perspective I think we need to  
identify the assemblies which may be something like:


Jetty  Axis OpenJPA
Tomcat CXF  OpenJPA

(I'm not sure of the state of Cayenne)

The provide a "stubbed out" version that would allow a user to  
install their preferred component via a plugin.


Just a thought.

On Jan 8, 2007, at 9:53 AM, Jason Dillon wrote:


On Jan 8, 2007, at 12:38 AM, David Jencks wrote:
rather than saying we'll only ship when we have all 6 it seems  
more appropriate to me to say that we'll ship the assemblies  
that people are willing to work on which includes TCK testing.   
Any other ideas on how to handle this?  Anyone interested in a  
specific configuration and want to step up to TCK testing?


I think maybe we should concentrate on packaging things as  
plugins, although this doesn't really affect what we run through  
the tck.


Do we really need to run the TCK on every possible permutation?  
Why don't we bless a specific configuration and then concentrate  
the TCK effort on that specific assembly?


--jason





Matt Hogstrom
[EMAIL PROTECTED]

Re: Assemblies assemblies everywhere and which one to ship?

[Matt Hogstrom]

I don't think its just TCK.  I agree we should scope the  
configuration to a limited set but I'm also concerned about making  
assemblies available.  Given my math challenged 6 which is really 8 I  
don't think we would want to generate every one of them.  So I think  
from the download page perspective I think we need to identify the  
assemblies which may be something like:


Jetty  Axis OpenJPA
Tomcat CXF  OpenJPA

(I'm not sure of the state of Cayenne)

The provide a "stubbed out" version that would allow a user to  
install their preferred component via a plugin.


Just a thought.

On Jan 8, 2007, at 9:53 AM, Jason Dillon wrote:


On Jan 8, 2007, at 12:38 AM, David Jencks wrote:
rather than saying we'll only ship when we have all 6 it seems  
more appropriate to me to say that we'll ship the assemblies that  
people are willing to work on which includes TCK testing.  Any  
other ideas on how to handle this?  Anyone interested in a  
specific configuration and want to step up to TCK testing?


I think maybe we should concentrate on packaging things as  
plugins, although this doesn't really affect what we run through  
the tck.


Do we really need to run the TCK on every possible permutation? Why  
don't we bless a specific configuration and then concentrate the  
TCK effort on that specific assembly?


--jason





Matt Hogstrom
[EMAIL PROTECTED]

Re: trunk wont start

[Kevan Miller]

On Jan 8, 2007, at 11:48 AM, Jason Dillon wrote:


Can someone from the openejb team please publish new snaps.


OK. Current 2.3-SNAPSHOT has been published...

--kevan

Re: ClassLoader, JNDI and Dependency views in console

[Christopher M. Cardona]

Hi Gianny,

That explains it. Your suggestion fixed the problem.

Thanks,
chris

Gianny Damour wrote:

Hi Chris,

I also had this problem. If you re-compile OpenEJB, then you should be 
fine. In a few words, ModuleConfigurer.getModuleType has been recently 
added and you are running with a EjbConfigurer which does not define 
this method.


Thanks,
Gianny


On 08/01/2007, at 10:15 PM, Christopher M. Cardona wrote:


Rakesh,

I tried combining your patches last time and I was able to build the 
server but the it fails on startup with the following error:


[*> ] 93%  20s  Loading 
org.apache.geronimo...19:29:49,3

12 ERROR [DeploymentFactoryImpl]
java.lang.AbstractMethodError
   at 
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia

lize(JMXDeploymentManager.java:83)
   at 
org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.
t>(LocalDeploymentManager.java:28)
   at 
org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl

.getDeploymentManager(DeploymentFactoryImpl.java:141)
   at 
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment

Manager(DirectoryHotDeployer.java:317)
   at 
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc

toryHotDeployer.java:157)
   at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI

nstance.java:984)
   at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart

(GBeanInstanceState.java:267)
...

Not sure if I missed something. I'll give your combined patch a shot 
and let you know.


Best wishes,
chris

Rakesh Midha wrote:


Posted combined patch 
https://issues.apache.org/jira/secure/attachment/12348488/allviews.patch 
in JIRA 2689


Please review and commit.

Thanks
Rakesh

On 1/8/07, *Rakesh Midha* <[EMAIL PROTECTED] 
> wrote:


Hello All,

Thanks for quick review,

Joe, You are right about the difference in two prespectivies, the
debug view - dependencies is to show the hirarchical dependencies
of all components, modules and it also list repository elements,
whereas Config Manager is to list the potential ramifications if a
configuration is removed.

Another major difference being the Config Manager only shows
serviceparents only, where as this view directly list the direct
dependencies as well as serviceparents.

Sachin, Prasad, David :
About

http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html 


it shows the static dependencies of the default server, and
doens't list any customized services, repository elements,
components and configurations deployed on server. The idea is to
show the dependency information for a particular server in its
console.

I hope it clear all the points discussed here.

Chris, As you suggested I will create a single patch for all three
and post it in one of the JIRA. (Will inform once it is done).

Thanks
Rakesh



On 1/5/07, *Christopher M. Cardona* <[EMAIL PROTECTED]
> wrote:

Hi Rakesh,

Thanks for the patches. I haven't looked at the source too but
the pix
looks good. It would be nice if you can create a combined
patch for the
3 jiras so people who wanted to check out the new debug views
can use
this as another option.

Best wishes,
chris

Rakesh Midha wrote:
> Hello
>
> First of all I am sorry for being missing from the list for
last few
> days, actually I have been trying to get this work item done.
I kinda
> liked the idea of having ClassLoader, JNDI and Dependency
views in
> console.
>
> We have discussed this before in dev list, please read the
discussion
> below.
>
> I got this thing working, so I created three JIRA's, Please
have a
> look at https://issues.apache.org/jira/browse/GERONIMO-2689
> https://issues.apache.org/jira/browse/GERONIMO-2690

> https://issues.apache.org/jira/browse/GERONIMO-2691
>
> These three JIRA's adds 3 view in console which shows
> 1. JNDIView
> This view shows all the JNDI names binded in various componet
contexts
> as well as Global context. Have a look at
> 
https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif 


> to get idea of what it will show. As we can see it shows JNDI
names
> for which are available at each component context level. For
details
> of how this is implemented please have a look  at comments of
this JIRA.
>
> 2. ClassloaderView
> This view shows all the classloaders and
cla

[jira] Commented: (GERONIMODEVTOOLS-126) Geronimo Fails to Start: Port 1099 in Use

[Arthur Ryman (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463081
 ] 

Arthur Ryman commented on GERONIMODEVTOOLS-126:
---

Sachin,

I don't understand your comment. When I change the port in Eclipse it should 
propagate that change to the server. That is the whole point of a server 
configuration editor, i.e. to relieve users of understanding the file format 
used by the server.

Thx.

> Geronimo Fails to Start: Port 1099 in Use
> -
>
> Key: GERONIMODEVTOOLS-126
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-126
> Project: Geronimo-Devtools
>  Issue Type: Bug
> Environment: Windows XP, WTP 1.5.2, Geronimo 1.1 with Tomcat
>Reporter: Arthur Ryman
>
> I installed Geronim 1.1 with Tomcat via the Server tools in a fresh WTP 
> workspace. I created a JSP and tried to run it. Geronimo failed to start 
> because it complained the port 1099 was in use. I edited the configuration, 
> changing the port to 8099 and restarted, but it still failed. It still tried 
> to use 1099. The new configuration wasn't read. BTW, how do I verify that 
> 1099 really is in use? I don't know why it would be.
> Here is the console in DEBUG mode:
> Booting Geronimo Kernel (in Java 1.4.2)...
> 11:41:37,343 DEBUG [Daemon] 
> java.endorsed.dirs=E:\ibm-java2-142\jre\lib\endorsed;E:\geronimo-1.1\geronimo-1.1.1\lib\endorsed
> 11:41:37,343 DEBUG [Daemon] 
> java.ext.dirs=E:\ibm-java2-142\jre\lib\ext;E:\geronimo-1.1\geronimo-1.1.1\lib\ext
> 11:41:37,353 DEBUG [BasicKernel] Starting boot
> 11:41:37,563 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/boot/none/car?role=kernel State changed from stopped to starting
> 11:41:37,563 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/boot/none/car?role=kernel State changed from starting to running
> 11:41:37,563 DEBUG [BasicKernel] Booted
> 11:41:37,664 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/j2ee-system/1.1.1/car?configurationName=geronimo/j2ee-system/1.1.1/car
>  State changed from stopped to starting
> 11:41:37,674 DEBUG [Configuration] ClassLoader structure for configuration 
> geronimo/j2ee-system/1.1.1/car
> Parent configurations:
> ClassPath:
> 11:41:37,804 DEBUG [Configuration] Started configuration 
> geronimo/j2ee-system/1.1.1/car
> 11:41:37,804 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/j2ee-system/1.1.1/car?configurationName=geronimo/j2ee-system/1.1.1/car
>  State changed from starting to running
> 11:41:38,154 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=Repository,name=Repository
>  State changed from stopped to starting
> 11:41:38,154 DEBUG [GBeanSingleReference] Waiting to start 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=Repository,name=Repository
>  because no targets are running for reference ServerInfo matching the 
> patterns 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=GBean,name=ServerInfo
> 11:41:38,154 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=SystemLog,name=Logger
>  State changed from stopped to starting
> 11:41:38,285 DEBUG [GBeanSingleReference] Waiting to start 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=SystemLog,name=Logger
>  because no targets are running for reference ServerInfo matching the 
> patterns 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=GBean,name=ServerInfo
> 11:41:38,285 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=ArtifactManager,name=ArtifactManager
>  State changed from stopped to starting
> 11:41:38,285 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=ArtifactManager,name=ArtifactManager
>  State changed from starting to running
> 11:41:38,285 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=ArtifactResolver,name=ArtifactResolver
>  State changed from stopped to starting
> 11:41:38,355 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=ArtifactResolver,name=ArtifactResolver
>  State changed from starting to running
> 11:41:38,355 DEBUG [GBeanInstanceState] GBeanInstanceState for: 
> geronimo/j2ee-system/1.1.1/car?ServiceModule=geronimo/j2ee-system/1.1.1/car,j2eeType=ConfigurationManager,name=ConfigurationManager

Re: Specs change(s)

[Jason Dillon]

I think this is about right given how things are setup.  Step one  
makes my brain hurt though...


 * * *

Since we really treat each spec as its own project, we should drop  
the uber "specs" project and promote each spec to a top-level  
project.  Then everyone will know how to update them, as it will be  
like every other project... no magical mystical svn mv back and forth.


--jason


On Jan 7, 2007, at 8:54 PM, Tim McConnell wrote:

Hi, I need to change one of the spec files for JSR-88 and am a  
little unclear about the process. So, here's what I've done thus  
far (on my local filesystem only) and was wondering if it seems  
correct ??


1) Copied the \specs\tags\1_1_1\geronimo-spec-j2ee-deployment  
directory to \specs\trunk\geronimo-spec-j2ee-deployment


2) To follow the convention I inferred under specs\trunk I then  
renamed that directory to \specs\trunk\geronimo-j2ee- 
deployment_1.2_spec


3) Edited files that I needed to updated...
(e.g., \specs\trunk\geronimo-j2ee-deployment_1.2_spec\src\main\java 
\javax\enterprise\deploy\spi.DeploymentManager.java)


4) Changed pom.xml under \specs\trunk\geronimo-spec-j2ee-deployment

5) Changed pom.xml under \trunk

Finally, do we want to rename specs which include "J2EE" to  
something that includes "JEE5". e.g., \specs\trunk\geronimo-jee5- 
deployment_1.2_spec


--
Thanks,
Tim McConnell

Re: Specs change(s)

[Jason Dillon]

On Jan 7, 2007, at 9:13 PM, David Jencks wrote:
That looks right to me except as someone pointed out it should  
really be jee rather than jee5 -- it wasn't j2ee14 :-)


Yup... jee or javaee, prolly the latter since its the correct term  
from sun and doesn't sound like "G" when spoken.


--jason

Re: trunk wont start

[Jason Dillon]

Can someone from the openejb team please publish new snaps.

--jason


On Jan 8, 2007, at 11:14 AM, Kevan Miller wrote:



On Jan 8, 2007, at 10:59 AM, Hernan Cunico wrote:


Hi All,
I just did a fresh build with NO ERRORS !!! however I can not run  
neither Jetty or Tomcat.
Both dists come to life partially but fail with the same error,  
see logs.


Anyone else seeing this problem?


Until a new OpenEJB snapshot is published, you'll need to build  
openejb/trunk/openejb2 locally...


--kevan

Re: possible 1.2 problem

[jason . dillon]

Okay, I thought there was a branch that depended on 2.0 artifacts at one 
point...

--jason


  

-Original Message-
From: Kevan Miller <[EMAIL PROTECTED]>
Date: Mon, 8 Jan 2007 11:12:33 
To:dev@geronimo.apache.org
Subject: Re: possible 1.2 problem


On Jan 8, 2007, at 10:55 AM, Jason Dillon wrote:

> What is the svn URL for this build?
>
> And do you know what the svn URL is for the OpenEJB codeline which  
> depends on G 2.x?

https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb2

There isn't a OpenEJB 2 branch that depends on 2.0-Mx. 2.2-SNAPSHOT  
is being used for both 1.2-SNAPSHOT and 2.0-M2-SNAPSHOT. Real soon  
now, OpenEJB 3 will replace OpenEJB in 2.0-M2-SNAPSHOT...

--kevan

Re: trunk wont start

[anita kulshreshtha]

   Building openejb might help. Please see:
http://www.nabble.com/Re%3A-ClassLoader%2C-JNDI-and-Dependency-views-in-console-p8216259.html

Thanks
Anita

--- Hernan Cunico <[EMAIL PROTECTED]> wrote:

> Hi All,
> I just did a fresh build with NO ERRORS !!! however I can not run
> neither Jetty or Tomcat.
> Both dists come to life partially but fail with the same error, see
> logs.
> 
> Anyone else seeing this problem?
> 
> Cheers!
> Hernan
> 
> > 10:52:06,046 INFO  [root]
> --
> 10:52:06,046 INFO  [root] Started Logging Service
> 10:52:06,046 INFO  [root] Runtime Information:
> 10:52:06,046 INFO  [root]   Install Directory =
> D:\geronimo-jetty6-jee5-2.0
> 10:52:06,046 INFO  [root]   JVM in use = Sun Microsystems Inc. Java
> 1.5.0_06
> 10:52:06,046 INFO  [root] Java Information:
> 10:52:06,046 INFO  [root]   System property [java.runtime.name]  =
> Java(TM) 2 Runtime Environment, Standard Edition
> 10:52:06,046 INFO  [root]   System property [java.runtime.version]  =
> 1.5.0_06-b05
> 10:52:06,046 INFO  [root]   System property [os.name] =
> Windows XP
> 10:52:06,046 INFO  [root]   System property [os.version]  =
> 5.1
> 10:52:06,046 INFO  [root]   System property [sun.os.patch.level]  =
> Service Pack 2
> 10:52:06,046 INFO  [root]   System property [os.arch] =
> x86
> 10:52:06,046 INFO  [root]   System property [java.class.version]  =
> 49.0
> 10:52:06,046 INFO  [root]   System property [locale]  =
> en_US
> 10:52:06,046 INFO  [root]   System property [unicode.encoding]=
> UnicodeLittle
> 10:52:06,046 INFO  [root]   System property [file.encoding]   =
> Cp1252
> 10:52:06,046 INFO  [root]   System property [java.vm.name]=
> Java HotSpot(TM) Client VM
> 10:52:06,046 INFO  [root]   System property [java.vm.vendor]  =
> Sun Microsystems Inc.
> 10:52:06,046 INFO  [root]   System property [java.vm.version] =
> 1.5.0_06-b05
> 10:52:06,046 INFO  [root]   System property [java.vm.info]=
> mixed mode
> 10:52:06,046 INFO  [root]   System property [java.home]   =
> C:\Java\jdk1.5.0_06\jre
> 10:52:06,046 INFO  [root]   System property [java.classpath]  =
> null
> 10:52:06,046 INFO  [root]   System property [java.library.path]   =
>
C:\Java\jdk1.5.0_06\jre\bin;.;C:\WINDOWS\system32;C:\WINDOWS;C:\Program
>
Files\ThinkPad\Utilities;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
> Files\IBM\Infoprint Select;C:\Program Files\Intel\DMIX;C:\Program
> Files\ATI Technologies\ATI.ACE\;C:\Program
> Files\ThinkPad\ConnectUtilities;C:\Program
> Files\Subversion\bin;C:\Java\jdk1.5.0_06\bin;D:\ant\bin;D:\Maven
> 1.1-beta-2\bin;C:\Program
>
Files\OpenSSH\bin;D:\maven-2.0.4\bin;D:\cygwin\bin;D:\SQLLIB\BIN;D:\SQLLIB\FUNCTION;D:\SQLLIB\SAMPLES\REPL;C:\Program
> Files\QuickTime\QTSystem\;D:\WinSCP3\;D:\MySQL5\bin
> 10:52:06,046 INFO  [root]   System property [java.endorsed.dirs]  =
>
C:\Java\jdk1.5.0_06\\jre\lib\endorsed;D:\geronimo-jetty6-jee5-2.0\lib\endorsed
> 10:52:06,046 INFO  [root]   System property [java.ext.dirs]   =
> C:\Java\jdk1.5.0_06\\jre/lib/ext;D:\geronimo-jetty6-jee5-2.0/lib/ext
> 10:52:06,046 INFO  [root]   System property [sun.boot.class.path] =
>
D:\geronimo-jetty6-jee5-2.0\lib\endorsed\xercesImpl-2.8.1.jar;D:\geronimo-jetty6-jee5-2.0\lib\endorsed\yoko-rmi-spec-1.0-incubating-M2-SNAPSHOT.jar;D:\geronimo-jetty6-jee5-2.0\lib\endorsed\yoko-spec-corba-1.0-incubating-M2-SNAPSHOT.jar;C:\Java\jdk1.5.0_06\jre\lib\rt.jar;C:\Java\jdk1.5.0_06\jre\lib\i18n.jar;C:\Java\jdk1.5.0_06\jre\lib\sunrsasign.jar;C:\Java\jdk1.5.0_06\jre\lib\jsse.jar;C:\Java\jdk1.5.0_06\jre\lib\jce.jar;C:\Java\jdk1.5.0_06\jre\lib\charsets.jar;C:\Java\jdk1.5.0_06\jre\classes
> 10:52:06,046 INFO  [root]
> --
> 10:52:23,296 ERROR [DeploymentFactoryImpl] 
> java.lang.AbstractMethodError
>   at
>
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initialize(JMXDeploymentManager.java:83)
>   at
>
org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.(LocalDeploymentManager.java:28)
>   at
>
org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManager(DeploymentFactoryImpl.java:141)
>   at
>
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeploymentManager(DirectoryHotDeployer.java:317)
>   at
>
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(DirectoryHotDeployer.java:157)
>   at
>
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:984)
>   at
>
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
>   at
>
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
>   at
>
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
>   at
>
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstan

Re: trunk wont start

[Kevan Miller]

On Jan 8, 2007, at 10:59 AM, Hernan Cunico wrote:


Hi All,
I just did a fresh build with NO ERRORS !!! however I can not run  
neither Jetty or Tomcat.
Both dists come to life partially but fail with the same error, see  
logs.


Anyone else seeing this problem?


Until a new OpenEJB snapshot is published, you'll need to build  
openejb/trunk/openejb2 locally...


--kevan

Re: possible 1.2 problem

[Kevan Miller]

On Jan 8, 2007, at 10:55 AM, Jason Dillon wrote:


What is the svn URL for this build?

And do you know what the svn URL is for the OpenEJB codeline which  
depends on G 2.x?


https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb2

There isn't a OpenEJB 2 branch that depends on 2.0-Mx. 2.2-SNAPSHOT  
is being used for both 1.2-SNAPSHOT and 2.0-M2-SNAPSHOT. Real soon  
now, OpenEJB 3 will replace OpenEJB in 2.0-M2-SNAPSHOT...


--kevan

Patches in RTC (Geronimo - 2007-01-08)

[dblevins]

Geronimo - Monday, January 8, 2007

  5 Patches in RTC

[GERONIMO-2638] Improve ModuleBuilder and ConfigurationBuilder interfaces 
to replace use of JarFile
  - Assignee: Sachin Patel
  - Reporter: Sachin Patel
  - Created:  Thu Dec 07 23:41:31 GMT 2006
  - Updated:  Fri Jan 05 17:38:22 GMT 2007
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2638

[GERONIMO-2485] PersistenceUnitGBean needs a NamespaceDrivenDeployer
  - Assignee: David Jencks
  - Reporter: David Jencks
  - Created:  Wed Oct 11 21:23:29 GMT 2006
  - Updated:  Thu Dec 07 20:28:27 GMT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2485

[GERONIMO-1277] Change group-id to org.apache.geronimo
  - Assignee: Jason Dillon
  - Reporter: Dain Sundstrom
  - Created:  Sat Dec 03 10:55:12 GMT 2005
  - Updated:  Tue Nov 07 23:57:44 GMT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-1277

[GERONIMO-2015] Let's replace JKS to PKCS12 key store type
  - Assignee: Unassigned
  - Reporter: Nikolay Chugunov
  - Created:  Fri May 12 21:54:17 GMT 2006
  - Updated:  Wed Dec 06 06:57:11 GMT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2015

[GERONIMODEVTOOLS-112] Loading deployment plan editor on empty file should 
auto-create plan
  - Assignee: Sachin Patel
  - Reporter: Sachin Patel
  - Created:  Wed Oct 11 21:45:57 GMT 2006
  - Updated:  Tue Jan 02 16:27:54 GMT 2007
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-112


NOTE: This email is generated and does not constitute and offical
vote or vote result.  All official voting is done on the dev list.

If you do not see your issue here, click the "Begin RTC Review"
link under the "Available Workflow Actions" of the JIRA page.

If you do not see your vote here, click the "Vote" link under the
"Operations" section of the JIRA page.


 *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE ***

Template: 
http://svn.apache.org/repos/asf/geronimo/gbuild/jirareports/patchesInRtc.vm

Re: possible 1.2 problem

[Jason Dillon]

What is the svn URL for this build?

And do you know what the svn URL is for the OpenEJB codeline which  
depends on G 2.x?


--jason


On Jan 8, 2007, at 10:46 AM, Kevan Miller wrote:



On Jan 8, 2007, at 10:21 AM, Jason Dillon wrote:


What version of Geronimo does that SNAPSHOT of OpenEJB depend on?


1.2-SNAPSHOT

--kevan

trunk wont start

[Hernan Cunico]

Hi All,
I just did a fresh build with NO ERRORS !!! however I can not run neither Jetty 
or Tomcat.
Both dists come to life partially but fail with the same error, see logs.

Anyone else seeing this problem?

Cheers!
Hernan

10:52:06,046 INFO  [root] --
10:52:06,046 INFO  [root] Started Logging Service
10:52:06,046 INFO  [root] Runtime Information:
10:52:06,046 INFO  [root]   Install Directory = D:\geronimo-jetty6-jee5-2.0
10:52:06,046 INFO  [root]   JVM in use = Sun Microsystems Inc. Java 1.5.0_06
10:52:06,046 INFO  [root] Java Information:
10:52:06,046 INFO  [root]   System property [java.runtime.name]  = Java(TM) 2 
Runtime Environment, Standard Edition
10:52:06,046 INFO  [root]   System property [java.runtime.version]  = 
1.5.0_06-b05
10:52:06,046 INFO  [root]   System property [os.name] = Windows XP
10:52:06,046 INFO  [root]   System property [os.version]  = 5.1
10:52:06,046 INFO  [root]   System property [sun.os.patch.level]  = Service 
Pack 2
10:52:06,046 INFO  [root]   System property [os.arch] = x86
10:52:06,046 INFO  [root]   System property [java.class.version]  = 49.0
10:52:06,046 INFO  [root]   System property [locale]  = en_US
10:52:06,046 INFO  [root]   System property [unicode.encoding]= 
UnicodeLittle
10:52:06,046 INFO  [root]   System property [file.encoding]   = Cp1252
10:52:06,046 INFO  [root]   System property [java.vm.name]= Java 
HotSpot(TM) Client VM
10:52:06,046 INFO  [root]   System property [java.vm.vendor]  = Sun 
Microsystems Inc.
10:52:06,046 INFO  [root]   System property [java.vm.version] = 1.5.0_06-b05
10:52:06,046 INFO  [root]   System property [java.vm.info]= mixed mode
10:52:06,046 INFO  [root]   System property [java.home]   = 
C:\Java\jdk1.5.0_06\jre
10:52:06,046 INFO  [root]   System property [java.classpath]  = null
10:52:06,046 INFO  [root]   System property [java.library.path]   = 
C:\Java\jdk1.5.0_06\jre\bin;.;C:\WINDOWS\system32;C:\WINDOWS;C:\Program 
Files\ThinkPad\Utilities;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
 Files\IBM\Infoprint Select;C:\Program Files\Intel\DMIX;C:\Program Files\ATI 
Technologies\ATI.ACE\;C:\Program Files\ThinkPad\ConnectUtilities;C:\Program 
Files\Subversion\bin;C:\Java\jdk1.5.0_06\bin;D:\ant\bin;D:\Maven 
1.1-beta-2\bin;C:\Program 
Files\OpenSSH\bin;D:\maven-2.0.4\bin;D:\cygwin\bin;D:\SQLLIB\BIN;D:\SQLLIB\FUNCTION;D:\SQLLIB\SAMPLES\REPL;C:\Program
 Files\QuickTime\QTSystem\;D:\WinSCP3\;D:\MySQL5\bin
10:52:06,046 INFO  [root]   System property [java.endorsed.dirs]  = 
C:\Java\jdk1.5.0_06\\jre\lib\endorsed;D:\geronimo-jetty6-jee5-2.0\lib\endorsed
10:52:06,046 INFO  [root]   System property [java.ext.dirs]   = 
C:\Java\jdk1.5.0_06\\jre/lib/ext;D:\geronimo-jetty6-jee5-2.0/lib/ext
10:52:06,046 INFO  [root]   System property [sun.boot.class.path] = 
D:\geronimo-jetty6-jee5-2.0\lib\endorsed\xercesImpl-2.8.1.jar;D:\geronimo-jetty6-jee5-2.0\lib\endorsed\yoko-rmi-spec-1.0-incubating-M2-SNAPSHOT.jar;D:\geronimo-jetty6-jee5-2.0\lib\endorsed\yoko-spec-corba-1.0-incubating-M2-SNAPSHOT.jar;C:\Java\jdk1.5.0_06\jre\lib\rt.jar;C:\Java\jdk1.5.0_06\jre\lib\i18n.jar;C:\Java\jdk1.5.0_06\jre\lib\sunrsasign.jar;C:\Java\jdk1.5.0_06\jre\lib\jsse.jar;C:\Java\jdk1.5.0_06\jre\lib\jce.jar;C:\Java\jdk1.5.0_06\jre\lib\charsets.jar;C:\Java\jdk1.5.0_06\jre\classes
10:52:06,046 INFO  [root] --
10:52:23,296 ERROR [DeploymentFactoryImpl] 
java.lang.AbstractMethodError
at 
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initialize(JMXDeploymentManager.java:83)
at 
org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.(LocalDeploymentManager.java:28)
at 
org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManager(DeploymentFactoryImpl.java:141)
at 
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeploymentManager(DirectoryHotDeployer.java:317)
at 
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(DirectoryHotDeployer.java:157)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:984)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:543)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:378)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.

Re: possible 1.2 problem

[Kevan Miller]

On Jan 8, 2007, at 10:20 AM, Jason Dillon wrote:


On Jan 8, 2007, at 6:01 AM, Kevan Miller wrote:
Are you building openejb by hand, or are the deployed snaps up to  
date?


I built OpenEJB locally. Looks like new snaps will need to be  
pushed out to pick up David J's changes...


This is one reason why I had chosen before to always build the  
server dependencies when I automated builds.  This was the reason  
why I wanted to build release branches for dependencies, so that  
the exact same configuration could be used to handle both SNAPSHOT  
and release artifacts.


If you look at this from a build automation perspective, the  
configuration of the automation tools really needs to be the  
same... and it needs to be able to handle the change of versions  
from released to SNAPSHOT as was made here.  Building everything  
from source is one of the easiest ways to accomplish this and get  
reliable builds which don't break so easily when a change like this  
is made.


BUT, since the OpenEJB branch keeps moving around, and because  
people keep telling me that I should just use release artifacts, I  
had removed that interim build of OpenEJB to support the automated  
build of the server.


If we want to do things the Maven-way, then when any change which  
will break compatibility is made on a dependency is made, then that  
project *MUST* publish new SNAPSHOTS after it has committed the  
change to SVN.  Otherwise projects which depend on them will  
essentially be broken.  I have been doing this with Genesis  
regularly, when a change is made that is needed by the server  
builds, then I publish the modules that change, so that with a  
clean repo, or mvn -U, the build will function as expected.


I didn't make the change to Geronimo/OpenEJB that broke the  
compatibility. I do/did realize that a publish needed to occur. I  
would have done it, if I knew how. I've never done it. I'm happy to  
learn...




I *don't* think it is good enough to use an automated nightly to  
publish SNAPSHOTS as the only mechanism for this either.  I think  
that automated nightly deployment is a good stop gab measure to  
help catch when people miss a deployed changed... so builds won't  
be broken for more than 24 hours when someone does forget.  But  
when they do forget, the build could be broken for the duration of  
the day until automated deploy kicks in which sucks IMO.  Build  
automation should be the trusted source for the state of the  
builds... if the automated build is broke, then the build is broke,  
if your local build is broke, but the automated build is fine, then  
you have an environmental problem or local code change which has  
broken your build.


Agreed.



 * * *

I believe that this is a critical process which we really need to  
help allow our developers to focus on code... and not on the  
build.  I have been trying to solve this problem for months now...  
though I have not been getting much support from the group :-(  I  
almost had it solved, and then the view of the world changed (the  
specs release mess that I was so upset about).


Due to the challenges of using Maven 2.x (mostly use of SNAPSHOTS  
and remote repos), as well as the interdependency between the  
server and OpenEJB, I believe that the only way to achieve this  
level of trustable build automation, is to build these components  
from source.  To help make that work, we need to use a very  
consistent policy for SVN branch layout.  Moving branches to tags  
and then back to branches is very harmful in this respect... and I  
would really like to see that practice abolished.


I think it's Dain that proposed the current policy of specs. So, I'll  
let him (or others) follow up on this...


--kevan

[jira] Created: (GERONIMO-2708) ConcurrentModificationException in ConnectionTracking with Daytrader 1.2 under load

[Christopher James Blythe (JIRA)]

ConcurrentModificationException in ConnectionTracking with Daytrader 1.2 under 
load
---

 Key: GERONIMO-2708
 URL: https://issues.apache.org/jira/browse/GERONIMO-2708
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: connector
Affects Versions: 1.2
 Environment: Geronimo 1.2 from geronimo/sever/branches/1.2 (01/04/2007)
RHEL 4
SUN 1.5.0_10 JDK

Reporter: Christopher James Blythe


Looks like are some concurrency issues with Connection Tracking in Geronimo 1.2.

- Built Geronimo from geronimo/sever/branches/1.2 (01/04/2007)
- Deployed Daytrader (built from geronimo/daytrader/branches/1.2)
- Stressed "EJB" and "Session to JDBC" mode with multiple clients using load 
driver

Both tests resulted in the following exception when more than 1 client was 
driven.

NOTE: I went back and double checked on Geronimo 1.1.1 and this does not occur.

java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.remove(HashMap.java:860)
at 
org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit(ConnectionTrackingCoordinator.java:92)
at 
org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.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:122)
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.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$8f3374f8.exit
 ()
at 
org.apache.openejb.NoConnectionEnlistingInterceptor.invoke(NoConnectionEnlistingInterceptor.java:70)
at 
org.apache.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java
 :35)
at 
org.apache.openejb.security.DefaultSubjectInterceptor.invoke(DefaultSubjectInterceptor.java:49)
at 
org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(DefaultStatelessEjbContainer.java
 :178)
at 
org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.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:122)
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.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$34d791e3.invoke()
at 
org.apache.openejb.AbstractEjbDeployment.invoke(AbstractEjbDeployment.java :195)
at 
org.apache.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:145)
at 
org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$3eb3ed90.getQuote()
at 
org.apache.geronimo.samples.daytrader.TradeAction.getQuote(TradeAction.java:331)
at 
org.apache.jsp.displayQuote_jsp._jspService(org.apache.jsp.displayQuote_jsp:71)
at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile 
(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter 
(ApplicationFilterChain.java:252)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java
 :672)
at 
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
at 
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
at 
org.apache.jasper.runtime.

Re: possible 1.2 problem

[Kevan Miller]

On Jan 8, 2007, at 10:21 AM, Jason Dillon wrote:


What version of Geronimo does that SNAPSHOT of OpenEJB depend on?


1.2-SNAPSHOT

--kevan

[jira] Resolved: (SM-800) jsr181 component, no such method "asList"

[Guillaume Nodet (JIRA)]

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

Guillaume Nodet resolved SM-800.


Resolution: Cannot Reproduce
  Assignee: Guillaume Nodet

> jsr181 component, no such method "asList"
> -
>
> Key: SM-800
> URL: https://issues.apache.org/activemq/browse/SM-800
> Project: ServiceMix
>  Issue Type: Bug
>  Components: servicemix-jsr181
>Affects Versions: 3.1
> Environment: Im using linux, Im trying to deploy a jsr181component on 
> lightweight
>Reporter: Eduardo Burgos
> Assigned To: Guillaume Nodet
>Priority: Minor
>
> I got a NoSuchMethodException when servicemix was trying to call the method 
> asList on the Jsr181Component class. I fixed it on my installation by 
> replacing line 54 of 
> /deployables/serviceengines/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/Jsr181Component.java
>  with 
> "return DefaultComponent.asList(endpoints);"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: possible 1.2 problem

[Jason Dillon]

What version of Geronimo does that SNAPSHOT of OpenEJB depend on?

--jason


On Jan 8, 2007, at 6:01 AM, Kevan Miller wrote:



On Jan 6, 2007, at 4:51 PM, Jason Dillon wrote:

Are you building openejb by hand, or are the deployed snaps up to  
date?


I built OpenEJB locally. Looks like new snaps will need to be  
pushed out to pick up David J's changes...


--kevan

Re: possible 1.2 problem

[Jason Dillon]

On Jan 8, 2007, at 6:01 AM, Kevan Miller wrote:
Are you building openejb by hand, or are the deployed snaps up to  
date?


I built OpenEJB locally. Looks like new snaps will need to be  
pushed out to pick up David J's changes...


This is one reason why I had chosen before to always build the server  
dependencies when I automated builds.  This was the reason why I  
wanted to build release branches for dependencies, so that the exact  
same configuration could be used to handle both SNAPSHOT and release  
artifacts.


If you look at this from a build automation perspective, the  
configuration of the automation tools really needs to be the same...  
and it needs to be able to handle the change of versions from  
released to SNAPSHOT as was made here.  Building everything from  
source is one of the easiest ways to accomplish this and get reliable  
builds which don't break so easily when a change like this is made.


BUT, since the OpenEJB branch keeps moving around, and because people  
keep telling me that I should just use release artifacts, I had  
removed that interim build of OpenEJB to support the automated build  
of the server.


If we want to do things the Maven-way, then when any change which  
will break compatibility is made on a dependency is made, then that  
project *MUST* publish new SNAPSHOTS after it has committed the  
change to SVN.  Otherwise projects which depend on them will  
essentially be broken.  I have been doing this with Genesis  
regularly, when a change is made that is needed by the server builds,  
then I publish the modules that change, so that with a clean repo, or  
mvn -U, the build will function as expected.


I *don't* think it is good enough to use an automated nightly to  
publish SNAPSHOTS as the only mechanism for this either.  I think  
that automated nightly deployment is a good stop gab measure to help  
catch when people miss a deployed changed... so builds won't be  
broken for more than 24 hours when someone does forget.  But when  
they do forget, the build could be broken for the duration of the day  
until automated deploy kicks in which sucks IMO.  Build automation  
should be the trusted source for the state of the builds... if the  
automated build is broke, then the build is broke, if your local  
build is broke, but the automated build is fine, then you have an  
environmental problem or local code change which has broken your build.


 * * *

I believe that this is a critical process which we really need to  
help allow our developers to focus on code... and not on the build.   
I have been trying to solve this problem for months now... though I  
have not been getting much support from the group :-(  I almost had  
it solved, and then the view of the world changed (the specs release  
mess that I was so upset about).


Due to the challenges of using Maven 2.x (mostly use of SNAPSHOTS and  
remote repos), as well as the interdependency between the server and  
OpenEJB, I believe that the only way to achieve this level of  
trustable build automation, is to build these components from  
source.  To help make that work, we need to use a very consistent  
policy for SVN branch layout.  Moving branches to tags and then back  
to branches is very harmful in this respect... and I would really  
like to see that practice abolished.


--jason

Re: ClassLoader, JNDI and Dependency views in console

[Paul McMahan]

I think these new UIs look great and are very useful.  I'm in favor of
integrating them into Geronimo.  However, I am concerned about how the
patch integrates them.  I would very strongly prefer that they be
integrated as plugins instead of directly into the admin console.  As
a matter of fact I think several of the portlets in the current admin
console should eventually be factored out as plugins.  Then, as the
admin console moves towards a more plugin-centric approach the user
can integrate these UIs directly into the console or keep them as
separate webapps.

Best wishes,
Paul


On 1/5/07, Rakesh Midha <[EMAIL PROTECTED]> wrote:

Hello

 First of all I am sorry for being missing from the list for last few days,
actually I have been trying to get this work item done. I kinda liked the
idea of having ClassLoader, JNDI and Dependency views in console.

 We have discussed this before in dev list, please read the discussion
below.

I got this thing working, so I created three JIRA's, Please have a look at
https://issues.apache.org/jira/browse/GERONIMO-2689
https://issues.apache.org/jira/browse/GERONIMO-2690
 https://issues.apache.org/jira/browse/GERONIMO-2691

These three JIRA's adds 3 view in console which shows
1. JNDIView
This view shows all the JNDI names binded in various componet contexts as
well as Global context. Have a look at
https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif
to get idea of what it will show. As we can see it shows JNDI names for
which are available at each component context level. For details of how this
is implemented please have a look  at comments of this JIRA.

2. ClassloaderView
This view shows all the classloaders and classes/interfaces  loaded by that
classloader in heirarchical fashion. Have a look at
https://issues.apache.org/jira/secure/attachment/12348333/12348333_classloader.gif
to get idea of what it will show. As we can see it shows classes and
interfaces for all the classloaders and its child classloaders. For details
of how this is implemented please have a look  at comments of this JIRA.

3. DependencyView
This view shows all the components and repository items and its dependencies
in hierarchical fashion in which they are loaded. To facilitate locating of
items of interest the tree view can be searched.. Have a look at
https://issues.apache.org/jira/secure/attachment/12348336/12348336_dependency.gif
to get idea of what it will show. As we can see it shows dependencies  for
each component. For details of how this is implemented please have a look
at comments of this JIRA.

This is a request that please try these patches and let me know your
comments on it. I think I liked it and these views will definatly be useful
for debugging purpose, and from my expierance I can tell that all these
views are trying to facilitate solving of problems which are difficult to
tackle otherwise.

Also notice that we may like to add another section in navigation for debug
views as shown in
https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif
this is not implemented for now but we may do it once we agree to put the
above views in console.

Thanks in advance, please do have a look and comment.
 Rakesh

On 7/20/06, Erin Mulder <[EMAIL PROTECTED]> wrote:
> Aaron Mulder wrote:
> > http://people.apache.org/~ammulder/classloaders.png
> >
> > However, I'm not sure how useful it will be -- it'll show you
> > dependencies at the class loader level, but it won't tell you which
> > class loaders hold a particular class or which class loader you're
> > actually getting at some point when an error is uncovered.
>
> Also, it still needs arrows. :)
>
> Right now, the code for that graph produces SVG.  It would be great to
> make it interactive so that you could drag the nodes around, click on a
> node to load a div that shows which classes are loaded in it, and maybe
> even collapse certain branches.  At JavaOne, I got a few simple
> JavaScript behaviors working with the graph prototype, but I'm not sure
> how complex it would be to add full-out drag and drop.
>
> Perhaps you can throw the code into the sandbox so other people can
> check it out and build on it?  If I recall correctly, I was careful to
> make sure that all of its dependencies have Apache-compatible licenses,
> (which was actually quite difficult).
>
> Alternatively, someone could create and share a non-ASF-hosted plugin
> that makes use of one of the many LGPL graph libraries out there.
>
> Cheers,
> Erin
>

Re: Assemblies assemblies everywhere and which one to ship?

[Jason Dillon]

On Jan 8, 2007, at 12:38 AM, David Jencks wrote:
rather than saying we'll only ship when we have all 6 it seems  
more appropriate to me to say that we'll ship the assemblies that  
people are willing to work on which includes TCK testing.  Any  
other ideas on how to handle this?  Anyone interested in a  
specific configuration and want to step up to TCK testing?


I think maybe we should concentrate on packaging things as plugins,  
although this doesn't really affect what we run through the tck.


Do we really need to run the TCK on every possible permutation? Why  
don't we bless a specific configuration and then concentrate the TCK  
effort on that specific assembly?


--jason

Re: Milestone 2 - Its coming :-0

[Jarek Gawor]

Here's a quick Web Services support update (of things I'm aware of):

1) The StAX and JAXB support has been recently added to Geronimo. This
addresses both Axis2 and CXF deliverables (since both will use the
same implementations of these API).

2) Basic JAX-WS support for POJOs is also working now (using CXF).
However, the  JAX-WS support for EJBs is not implemented yet. That's
something I'm looking into to do next (for M2 hopefully).

Jarek

On 1/7/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

I imagine for most everyone the first week back after the holidays is
a bit tough;  Digging through e-mail, getting back in the groove and
all that stuff.  I trust y'all had a good break and enjoyed some time
doing the things you enjoy.  For us, we hung out at home for the
first time in several years and it was really nice :)

Ok, so back to the item in the subject line which is Milestone 2.
The original timetable that was proposed was to ship the monster on
January 26th which is the last Friday in January.  Working back, we'd
need to branch around the the 19th which leaves a short runway.  I
think the OpenEJB crew indicated that the M2 date was about right so
I was wondering what y'all are thinking at this point.

For other items to get to an EE 5.0 server we have lots of items that
need to be done as well.  Here is a list off the top of my head so
I'd like to get your feedback and let's define what should be flowing
into M2.

EJB 3.0 (as they say for THX...the audience is waiting :)

Web Services related stuff...here is the report card that is on the
Wiki (http://cwiki.apache.org/GMOxPMGT/geronimo-java-ee-50-report-
card.html) .  Anyone want to chime in on this?

Deployment (JSR-88) sounds like Tim is working on this based on
recent traffic on the list.

There are also a number of non-spec related tasks that we musn't forget.

TCK - Of course we can't talk about TCK content on the dev list we
can talk about who wants / is working on that.  The long pull for a
lot of this will be getting through the TCK given the number of tests
we have to get through.  Certainly not an M2 goal we should be
starting this soon.  Any takers?

Samples and performance.   Daytrader still needs to get the EJB 3.0
programming model changes in...it already has JPA (thanks Mr.
Jencks).   I'll be spending some time there.

There are lots of Non functional things that we need to work on as
well.  Performance and monitoring, clustering, better messages,
better defaults and good patterns, not to mention tooling and the
like).  There is lots to do, so whose working on what?


Matt Hogstrom
[EMAIL PROTECTED]

[jira] Commented: (GERONIMO-2707) Cannot deploy app client from ear

[Rakesh Midha (JIRA)]

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

Rakesh Midha commented on GERONIMO-2707:



Hello Dario

I am not sure what source code are you looking at. I tried deploying a bank 
sample ear with bankclient.jar in it and I was able to deploy it.(I tried for 
both geronimo-1.1.1 and 2.0).  Here is the output

C:\geronimo\geronimo-1.1.1\bin>deploy.bat --user system --password manager deplo
y c:\geronimo\sample\bank\releases\Bank.ear
Using GERONIMO_BASE:   C:\geronimo\geronimo-1.1.1
Using GERONIMO_HOME:   C:\geronimo\geronimo-1.1.1
Using GERONIMO_TMPDIR: C:\geronimo\geronimo-1.1.1\var\temp
Using JRE_HOME:c:\Progra~1\Java\jdk1.5.0_01
Deployed samples/Bank/1.0/car
  `-> BankWeb.war @ http://libspie:8080/Bank
  `-> BankEJB.jar
  `-> bankclient.jar
  `-> tranql-connector-1.2.rar

Can you please share your application.xml, application-client.xml and geronimo 
deployment descriptors (if you are using).

Thanks
Rakesh

> Cannot deploy app client from ear
> -
>
> Key: GERONIMO-2707
> URL: https://issues.apache.org/jira/browse/GERONIMO-2707
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.1.1
> Environment: win xp, java 1.6.0, geronimo 1.1.1, core 2 duo 4GB, 
> myeclipse 5, wtp 1.5.2
>Reporter: Dario Andrade
>
> When trying to deploy an ear with an application client, I get this error: 
> From the code, I can see the application client config builder is not defined 
> in the j2ee deployer.
> Publishing failed
>   Distribution of configuration failed.  See log for details.
> Cannot deploy app client; No app client deployer defined: 
> GManiaBatchClient.jar
> org.apache.geronimo.common.DeploymentException: Cannot deploy app client; 
> No app client deployer defined: GManiaBatchClient.jar
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:725)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:364)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:263)
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:122)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
>   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.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$601a27b4.getDeploymentPlan()
>   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:232)
>   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124)
>   at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.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:122)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
>   at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338)
>   at 
> org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.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:122)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
>   at 
> org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1424)
>   at 
> 

[jira] Commented: (AMQ-1016) 4.1 RC1: META-INF/spring.schemas refers to building user "file:/Users/chirino/"

[JIRA]

[ 
https://issues.apache.org/activemq/browse/AMQ-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37835
 ] 

Endre Stølsvik commented on AMQ-1016:
-

Just wanted to point out that in the 4.1 release, the line in question reads

{code}http\://activemq.org/config/1.0=file:/home/foconer/logicblaze/activemq-temp/activemq-4.1.0/activemq-core/target/activemq.xsd{code}

This is still very wrong, and additionally, with the current file residing at 
the {{http://people.apache.../activemq-core-4.1-incubator-SNAPSHOT.xsd}} 
location (refer to my first comment), the entire xbeans-stuff doesn't seem able 
to "boot" at all anymore, giving a huge exception:

{code}
Exception in thread "main" 
org.springframework.beans.factory.BeanDefinitionStoreException: Line 113 in XML 
document from class path resource [com/picorg/SpringPicorg.xml] is invalid; 
nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.b: The 
content of element 'amq:transportConnector' is not complete. One of 
'{"http://activemq.org/config/1.0":broker, 
"http://activemq.org/config/1.0":brokerInfo, 
"http://activemq.org/config/1.0":discoveryAgent, 
"http://activemq.org/config/1.0":messageAuthorizationPolicy, 
"http://activemq.org/config/1.0":server, 
"http://activemq.org/config/1.0":taskRunnerFactory, 
WC[##other:"http://activemq.org/config/1.0"]}' is expected.
Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.b: The content 
of element 'amq:transportConnector' is not complete. One of 
'{"http://activemq.org/config/1.0":broker, 
"http://activemq.org/config/1.0":brokerInfo, 
"http://activemq.org/config/1.0":discoveryAgent, 
"http://activemq.org/config/1.0":messageAuthorizationPolicy, 
"http://activemq.org/config/1.0":server, 
"http://activemq.org/config/1.0":taskRunnerFactory, 
WC[##other:"http://activemq.org/config/1.0"]}' is expected.
at 
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195)
at 
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131)
at 
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384)
at 
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318)
at 
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:410)
at 
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3165)
at 
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.elementLocallyValidComplexType(XMLSchemaValidator.java:3129)
at 
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3076)
at 
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:2978)
at 
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2121)
at 
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.emptyElement(XMLSchemaValidator.java:714)
at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:377)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2740)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:645)
at 
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
at 
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:508)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
at 
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at 
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
at 
com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:225)
at 
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283)
at 
org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:77)
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:405)
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:357)
at 
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334)
at 
org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBe

Re: Assemblies assemblies everywhere and which one to ship?

[Jason Dillon]

2 is bad enough already... 6 or 8 or 10 or whatever is insane IMO.

Just because G is flexible enough to be configured in such different  
ways, does not mean that we need (or should) to ship assemblies with  
those configurations or run the TCK against them.


I think we really need to pick one and then use that for the assembly  
and TCK testing.


Our inability to pick between jetty and tomcat is already causing a  
bunch of unneeded burden on the team... I would really like to see us  
avoid that with other components, as well as finally picking a  
webcontainer.


--jason


On Jan 7, 2007, at 11:33 PM, Matt Hogstrom wrote:

I was thinking about M2 this weekend and was considering many of  
the challenges we face in putting out certified releases.  Up till  
now the number of permutations has been pretty limited and that has  
been Jetty and Tomcat.  With Java EE 5.0 life is no longer that  
simple.  Here are the choices I know of today:


Web Container (Tomcat / Jetty)
WebServices (Axis 2 / CXF)
EJB 3.0 Persistence (OpenJPA / Cayenne)

I think this makes 6 different assemblies and of course 6 separate  
certification efforts.  Perhaps we can do this and perhaps we  
can't.  Based on where projects are at and their desire to  
participate in helping to integrate (and do TCK testing :).


rather than saying we'll only ship when we have all 6 it seems more  
appropriate to me to say that we'll ship the assemblies that people  
are willing to work on which includes TCK testing.  Any other ideas  
on how to handle this?  Anyone interested in a specific  
configuration and want to step up to TCK testing?




Matt Hogstrom
[EMAIL PROTECTED]

[jira] Resolved: (SM-805) Incompatible BPELWSDLLocator between wsdl4j-1.5.2 and wsdl4j-1.6.1

[Guillaume Nodet (JIRA)]

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

Guillaume Nodet resolved SM-805.


   Resolution: Fixed
Fix Version/s: 3.1
 Assignee: Guillaume Nodet

Author: gnodet
Date: Mon Jan  8 06:08:38 2007
New Revision: 494077

URL: http://svn.apache.org/viewvc?view=rev&rev=494077
Log:
SM-805: Incompatible BPELWSDLLocator between wsdl4j-1.5.2 and wsdl4j-1.6.1

Modified:
   incubator/servicemix/trunk/pom.xml


> Incompatible BPELWSDLLocator between wsdl4j-1.5.2 and wsdl4j-1.6.1
> --
>
> Key: SM-805
> URL: https://issues.apache.org/activemq/browse/SM-805
> Project: ServiceMix
>  Issue Type: Bug
>  Components: servicemix-bpe
>Affects Versions: incubation
> Environment: Linux Java 5
>Reporter: Grégoire A.
> Assigned To: Guillaume Nodet
> Fix For: 3.1
>
> Attachments: BPELWSDLLocator.java.diff
>
>
> There is a incompatiblity with the new version of wsdl4j 1.6.2.
> we have this runtime exception when we deploy loan-broker-bpel (sample) 
> into the standard SMX. 
>  java.lang.AbstractMethodError: 
> org.apache.ode.bpe.deployment.bpel.BPELWSDLLocator.close()V
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at 
> org.apache.ode.bpe.deployment.bpel.ExtensibilityArtifacts.getRootWSDL(ExtensibilityArtifacts.java:759)
> at 
> org.apache.ode.bpe.deployment.bpel.ExtensibilityArtifacts.(ExtensibilityArtifacts.java:130)
> at 
> org.apache.ode.bpe.deployment.bpel.BPELRepositoryHandler.(BPELRepositoryHandler.java:92)
> at 
> org.apache.ode.bpe.deployment.bpel.BPELSAXHandler.(BPELSAXHandler.java:63)
> at 
> org.apache.ode.bpe.deployment.bpel.BPELParser.parseBPEL(BPELParser.java:94)
> at 
> org.apache.ode.bpe.deployment.bpel.BPELDeploy.deployJar(BPELDeploy.java:177)
> at 
> org.apache.ode.bpe.bped.unmanaged.BPELDeployerSLImpl.loadDefinition(BPELDeployerSLImpl.java:78)
> at org.apache.servicemix.bpe.BPEDeployer.deploy(BPEDeployer.java:86)
> org.apache.ode.bpe.deployment.bpel.BPELWSDLLocator didn't implements any 
> close method
> to close m_source object attribut. 
> NB: to work around use instead wsdl5j-1.5.2.jar
> a first fix could be into org.apache.ode.bpe.deployment.bpel.BPELWSDLLocator
>/**
> * @see javax.wsdl.xml.WSDLLocator#close()
> */
> public void close() {
> // Nothing To Do, m_source doesn't have any close method
> }
> Regards
> Grégoire A.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (SM-805) Incompatible BPELWSDLLocator between wsdl4j-1.5.2 and wsdl4j-1.6.1

[Guillaume Nodet (JIRA)]

[ 
https://issues.apache.org/activemq/browse/SM-805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37833
 ] 

Guillaume Nodet commented on SM-805:


Author: gnodet
Date: Mon Jan  8 05:57:23 2007
New Revision: 494073

URL: http://svn.apache.org/viewvc?view=rev&rev=494073
Log:
Ensure bpe code still works with wsdl4j 1.6.1

Modified:
   incubator/ode/scratch/bpe/pom.xml
   
incubator/ode/scratch/bpe/src/main/java/org/apache/ode/bpe/deployment/bpel/BPELWSDLLocator.java


> Incompatible BPELWSDLLocator between wsdl4j-1.5.2 and wsdl4j-1.6.1
> --
>
> Key: SM-805
> URL: https://issues.apache.org/activemq/browse/SM-805
> Project: ServiceMix
>  Issue Type: Bug
>  Components: servicemix-bpe
>Affects Versions: incubation
> Environment: Linux Java 5
>Reporter: Grégoire A.
> Attachments: BPELWSDLLocator.java.diff
>
>
> There is a incompatiblity with the new version of wsdl4j 1.6.2.
> we have this runtime exception when we deploy loan-broker-bpel (sample) 
> into the standard SMX. 
>  java.lang.AbstractMethodError: 
> org.apache.ode.bpe.deployment.bpel.BPELWSDLLocator.close()V
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at 
> org.apache.ode.bpe.deployment.bpel.ExtensibilityArtifacts.getRootWSDL(ExtensibilityArtifacts.java:759)
> at 
> org.apache.ode.bpe.deployment.bpel.ExtensibilityArtifacts.(ExtensibilityArtifacts.java:130)
> at 
> org.apache.ode.bpe.deployment.bpel.BPELRepositoryHandler.(BPELRepositoryHandler.java:92)
> at 
> org.apache.ode.bpe.deployment.bpel.BPELSAXHandler.(BPELSAXHandler.java:63)
> at 
> org.apache.ode.bpe.deployment.bpel.BPELParser.parseBPEL(BPELParser.java:94)
> at 
> org.apache.ode.bpe.deployment.bpel.BPELDeploy.deployJar(BPELDeploy.java:177)
> at 
> org.apache.ode.bpe.bped.unmanaged.BPELDeployerSLImpl.loadDefinition(BPELDeployerSLImpl.java:78)
> at org.apache.servicemix.bpe.BPEDeployer.deploy(BPEDeployer.java:86)
> org.apache.ode.bpe.deployment.bpel.BPELWSDLLocator didn't implements any 
> close method
> to close m_source object attribut. 
> NB: to work around use instead wsdl5j-1.5.2.jar
> a first fix could be into org.apache.ode.bpe.deployment.bpel.BPELWSDLLocator
>/**
> * @see javax.wsdl.xml.WSDLLocator#close()
> */
> public void close() {
> // Nothing To Do, m_source doesn't have any close method
> }
> Regards
> Grégoire A.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (AMQCPP-32) Stomp messages don't preserve property types: please document this behaviour

[Nathan Mittler (JIRA)]

[ 
https://issues.apache.org/activemq/browse/AMQCPP-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37832
 ] 

Nathan Mittler commented on AMQCPP-32:
--

I agree with Tim - this really should be commented on the wiki page.  The user 
isn't going to be looking into the code comments - rather, they should only be 
looking at the CMS API.  The CMS API isn't going to tell them the specific 
quirks of a particular implementation.  I'll take this issue and will update 
the wiki page accordingly.

> Stomp messages don't preserve property types: please document this behaviour
> 
>
> Key: AMQCPP-32
> URL: https://issues.apache.org/activemq/browse/AMQCPP-32
> Project: ActiveMQ C++ Client
>  Issue Type: Wish
>  Components: Stomp
>Affects Versions: 1.1
>Reporter: Albert Strasheim
> Assigned To: Nathan Mittler
>Priority: Trivial
> Fix For: 1.1
>
>
> I am producing messages from Java and C++ using ActiveMQ and AMQCPP, 
> respectively. Messages I produce have an int property set on them which I 
> want to select on, again in Java or C++.
> As far as I can tell from the [Stomp Protocol 
> specification|http://stomp.codehaus.org/Protocol] there is no way to specify 
> the types of message headers. As a result, all the messages end up with 
> String properties as can be be seen in the unmarshal method of 
> [org.apache.activemq.transport.stomp|http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/stomp/StompWireFormat.java?revision=470398&view=markup].
> I can work around this problem by selecting on id=123||id='123' in both Java 
> and C++, but it seems a bit suboptimal.
> At least, this issue should be documented somewhere in 
> activemq::connector::stomp::commands::StompMessage to help other people who 
> can't figure out why their selectors don't work.
> We could consider adding a function that allows the user to specify that 
> Stomp message properties should be sent in a type safe manner, and then 
> prepend some kind of string to the property name to indicate the type. 
> StompWireFormat on the Java side could check for this case and set the typed 
> properties accordingly. This is probably too much of a hack -- people who 
> want typed properties to work right can use Openwire in the (hopefully) near 
> future.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (AMQ-1020) Slow consumer terminally blocks both client and broker

[Rob Davies (JIRA)]

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

Rob Davies resolved AMQ-1020.
-

   Resolution: Fixed
Fix Version/s: 4.2.0

This is fixed by the default use of cursors and the spooling to disk for 
non-durable slow topic consumers

> Slow consumer terminally blocks both client and broker
> --
>
> Key: AMQ-1020
> URL: https://issues.apache.org/activemq/browse/AMQ-1020
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 4.0.2
> Environment: Broker: Windows XP, Sun JDK1.5  Client: activemq-dotnet 
> (Trunk)
>Reporter: Rob Lugt
> Assigned To: Rob Davies
> Fix For: 4.2.0
>
>
> I have a multi-threaded client (client1) which is acting as both a publisher 
> (Topic1) and subscriber (Topic2) using a single session.  There is another 
> client process (client2) which publishes on Topic2.
> I have witnessed the following repeatable scenario where both clients get 
> stuck, which can only be rectified by restarting the broker! :-
> Client1 publishes messages to Topic1 (rate = about 30 msgs/sec).
> Client2 publishes bursts of messages to Topic2 (rate = 500 msgs/sec) 
> Client1 is a slow subscriber on Topic2
> After running in this scenario for a couple of seconds, Client1 and Client2 
> become stuck.  Looking at a stack trace for Client1 I can see that it's 
> read_loop is stuck waiting for input, and it's publisher thread is stuck 
> waiting for an acknowledgement to the synchronous message send (the 
> acknowledgement never arrives because the broker won't sent any more 
> messages).
> Client2 is also stuck waiting for an acknowledgement to a synchronous send.
> My perception is that it appears the broker is throttling the connection 
> because the consumer is running slowly, but for some reason it gets into a 
> state where all message flow stops (even though the consumer is automatically 
> acknowledging messages, albeit slowly).  Furthermore, if I kill Client1 the 
> broker doesn't recover (using a JMX console the connection remains visible).
> The broker uses a vanilla configuration (i.e. no policies are set for the 
> topics in quedtion).
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (AMQ-1020) Slow consumer terminally blocks both client and broker

[Rob Davies (JIRA)]

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

Rob Davies reassigned AMQ-1020:
---

Assignee: Rob Davies

> Slow consumer terminally blocks both client and broker
> --
>
> Key: AMQ-1020
> URL: https://issues.apache.org/activemq/browse/AMQ-1020
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 4.0.2
> Environment: Broker: Windows XP, Sun JDK1.5  Client: activemq-dotnet 
> (Trunk)
>Reporter: Rob Lugt
> Assigned To: Rob Davies
>
> I have a multi-threaded client (client1) which is acting as both a publisher 
> (Topic1) and subscriber (Topic2) using a single session.  There is another 
> client process (client2) which publishes on Topic2.
> I have witnessed the following repeatable scenario where both clients get 
> stuck, which can only be rectified by restarting the broker! :-
> Client1 publishes messages to Topic1 (rate = about 30 msgs/sec).
> Client2 publishes bursts of messages to Topic2 (rate = 500 msgs/sec) 
> Client1 is a slow subscriber on Topic2
> After running in this scenario for a couple of seconds, Client1 and Client2 
> become stuck.  Looking at a stack trace for Client1 I can see that it's 
> read_loop is stuck waiting for input, and it's publisher thread is stuck 
> waiting for an acknowledgement to the synchronous message send (the 
> acknowledgement never arrives because the broker won't sent any more 
> messages).
> Client2 is also stuck waiting for an acknowledgement to a synchronous send.
> My perception is that it appears the broker is throttling the connection 
> because the consumer is running slowly, but for some reason it gets into a 
> state where all message flow stops (even though the consumer is automatically 
> acknowledging messages, albeit slowly).  Furthermore, if I kill Client1 the 
> broker doesn't recover (using a JMX console the connection remains visible).
> The broker uses a vanilla configuration (i.e. no policies are set for the 
> topics in quedtion).
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy closed GERONIMO-2695.
-

Resolution: Fixed

Fixed in rev 494061 in branches\1.1.

Verified that the fix in branches\1.1, branches\1.2.

> Requests using Non-secure HTTP connections cannot access unsecured web 
> resources
> 
>
> Key: GERONIMO-2695
> URL: https://issues.apache.org/jira/browse/GERONIMO-2695
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security, Tomcat, web
>Affects Versions: 1.1.1
> Environment: Geronimo running on Windows XP
>Reporter: Aman Nanner
> Assigned To: Jeff Genender
> Fix For: 1.1.2, 1.2, 2.0-M2
>
> Attachments: GERONIMO-2695-1.1.x.patch, test.war
>
>
> Consider the following fragment of my web.xml in my WAR:
> 
>
>   Unsecure Constraint
>   
>  Unsecure Resource Collection
>  /common/error/*
>  /common/includes/*
>  /common/Message.jsp
>  /common/resources/*
>  /common/security/login.jsp
>  /common/security/logout.jsp
>  /servlet/branding/*
>  /servlet/image/*
>  /servlet/login/*
>  /servlet/definecookie
>  GET
>  POST
>   
>   
>  NONE
>   
>
>
>   Secure Constraint
>   
>  Secure Resource Collection
>  /
>  GET
>  POST
>   
>   
>  MXSYSTEM
>   
>   
>  NONE
>   
>
>
>   FORM
>   
>  /common/security/PreLogin.jsp
>  /common/security/error.jsp
>   
>
>
>   Application System Role
>   MXSYSTEM
>
> 
> There are two sets of web resources defined: a secured web resource 
> collection, and an unsecured web resource collection.  The secured web 
> collection is by default everything that matches the "/" pattern.  In the 
> unsecured web collection, we use specific URL patterns so that certain 
> resources can be accessed prior to login.  Note that there is no security 
> role defined for the unsecured web resource collection, as these resources 
> should be available to every request.
> The problem is that access is denied to to the unsecured web resource 
> collection, even though they are defined as unsecured.  A blank HTML page is 
> returned instead of the appropriate resource.  After some debugging, I 
> discovered what seems to be a bug in the 
> org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class.  Consider the 
> following code fragment in the hasResourceCollection(...) method:
> 
> // Which user principal have we already authenticated?
> Principal principal = request.getUserPrincipal();
> //If we have no principal, then we should use the default.
> if (principal == null) {
> return request.isSecure();
> } else {
> Subject currentCaller = ((JAASTomcatPrincipal) 
> principal).getSubject();
> ContextManager.setCallers(currentCaller, currentCaller);
> }
> 
> When I make an HTTP connection to an unsecure web resource, I am 
> unauthenticated before I can login.  Thus, the principal in this case is 
> null.  In the case of a null principal, the code seems to base its 
> authorization on whether or not the request is secure!  This seems very 
> strange to me, as it should be able to accept normal, unauthenticated, HTTP 
> connections to unsecure web resources.
> I tried accessing the unsecured web resources over HTTPS, and sure enough, I 
> was able to access them because of the secure connection.  I'm not sure why 
> this works only over HTTPS...it should work in both cases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated GERONIMO-2695:
--

Fix Version/s: 2.0-M2
   1.2
   1.1.2

> Requests using Non-secure HTTP connections cannot access unsecured web 
> resources
> 
>
> Key: GERONIMO-2695
> URL: https://issues.apache.org/jira/browse/GERONIMO-2695
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security, Tomcat, web
>Affects Versions: 1.1.1
> Environment: Geronimo running on Windows XP
>Reporter: Aman Nanner
> Assigned To: Jeff Genender
> Fix For: 1.1.2, 1.2, 2.0-M2
>
> Attachments: GERONIMO-2695-1.1.x.patch, test.war
>
>
> Consider the following fragment of my web.xml in my WAR:
> 
>
>   Unsecure Constraint
>   
>  Unsecure Resource Collection
>  /common/error/*
>  /common/includes/*
>  /common/Message.jsp
>  /common/resources/*
>  /common/security/login.jsp
>  /common/security/logout.jsp
>  /servlet/branding/*
>  /servlet/image/*
>  /servlet/login/*
>  /servlet/definecookie
>  GET
>  POST
>   
>   
>  NONE
>   
>
>
>   Secure Constraint
>   
>  Secure Resource Collection
>  /
>  GET
>  POST
>   
>   
>  MXSYSTEM
>   
>   
>  NONE
>   
>
>
>   FORM
>   
>  /common/security/PreLogin.jsp
>  /common/security/error.jsp
>   
>
>
>   Application System Role
>   MXSYSTEM
>
> 
> There are two sets of web resources defined: a secured web resource 
> collection, and an unsecured web resource collection.  The secured web 
> collection is by default everything that matches the "/" pattern.  In the 
> unsecured web collection, we use specific URL patterns so that certain 
> resources can be accessed prior to login.  Note that there is no security 
> role defined for the unsecured web resource collection, as these resources 
> should be available to every request.
> The problem is that access is denied to to the unsecured web resource 
> collection, even though they are defined as unsecured.  A blank HTML page is 
> returned instead of the appropriate resource.  After some debugging, I 
> discovered what seems to be a bug in the 
> org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class.  Consider the 
> following code fragment in the hasResourceCollection(...) method:
> 
> // Which user principal have we already authenticated?
> Principal principal = request.getUserPrincipal();
> //If we have no principal, then we should use the default.
> if (principal == null) {
> return request.isSecure();
> } else {
> Subject currentCaller = ((JAASTomcatPrincipal) 
> principal).getSubject();
> ContextManager.setCallers(currentCaller, currentCaller);
> }
> 
> When I make an HTTP connection to an unsecure web resource, I am 
> unauthenticated before I can login.  Thus, the principal in this case is 
> null.  In the case of a null principal, the code seems to base its 
> authorization on whether or not the request is secure!  This seems very 
> strange to me, as it should be able to accept normal, unauthenticated, HTTP 
> connections to unsecure web resources.
> I tried accessing the unsecured web resources over HTTPS, and sure enough, I 
> was able to access them because of the secure connection.  I'm not sure why 
> this works only over HTTPS...it should work in both cases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: possible 1.2 problem

[anita kulshreshtha]

Thanks. I always wondered how it was working..
http://www.nabble.com/Re%3A-svn-commit%3A-r484869geronimo-server-trunk-pom.xml-p7769085.html

thanks
Anita

--- Kevan Miller <[EMAIL PROTECTED]> wrote:

> 
> On Jan 5, 2007, at 7:31 PM, David Jencks wrote:
> 
> > I fixed GERONIMO-2686 in 1.2 but have not been able to figure out  
> > what if any openejb2 version is supposed to go with it.  If the  
> > openejb2 version exists and is not 2.3 (trunk) the changes may have
>  
> > broken the openejb2 build.  See rev 493187 in openejb2
> 
> I've updated server/trunk/pom.xml and server/branches/1.2/pom.xml to 
> 
> specify the OpenEJB version as '2.3-incubating-SNAPSHOT' -- the  
> version of OpenEJB built by openejb/trunk/openejb2
> 
> I tested the JMS console wizard and it works for me...
> 
> --kevan
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources

[Jeff Genender (JIRA)]

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

Jeff Genender commented on GERONIMO-2695:
-

Vamsi, the patch looks great.  If you want to apply/commit it please feel free, 
and since you have been kind enough to test all the versions, feel free to 
close this out if you think I have fixed the problem.   I would commit the 
patch, but my maven 1 environment has not been working very well lately...so if 
you could do it, that would be great. Thanks!

> Requests using Non-secure HTTP connections cannot access unsecured web 
> resources
> 
>
> Key: GERONIMO-2695
> URL: https://issues.apache.org/jira/browse/GERONIMO-2695
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security, Tomcat, web
>Affects Versions: 1.1.1
> Environment: Geronimo running on Windows XP
>Reporter: Aman Nanner
> Assigned To: Jeff Genender
> Attachments: GERONIMO-2695-1.1.x.patch, test.war
>
>
> Consider the following fragment of my web.xml in my WAR:
> 
>
>   Unsecure Constraint
>   
>  Unsecure Resource Collection
>  /common/error/*
>  /common/includes/*
>  /common/Message.jsp
>  /common/resources/*
>  /common/security/login.jsp
>  /common/security/logout.jsp
>  /servlet/branding/*
>  /servlet/image/*
>  /servlet/login/*
>  /servlet/definecookie
>  GET
>  POST
>   
>   
>  NONE
>   
>
>
>   Secure Constraint
>   
>  Secure Resource Collection
>  /
>  GET
>  POST
>   
>   
>  MXSYSTEM
>   
>   
>  NONE
>   
>
>
>   FORM
>   
>  /common/security/PreLogin.jsp
>  /common/security/error.jsp
>   
>
>
>   Application System Role
>   MXSYSTEM
>
> 
> There are two sets of web resources defined: a secured web resource 
> collection, and an unsecured web resource collection.  The secured web 
> collection is by default everything that matches the "/" pattern.  In the 
> unsecured web collection, we use specific URL patterns so that certain 
> resources can be accessed prior to login.  Note that there is no security 
> role defined for the unsecured web resource collection, as these resources 
> should be available to every request.
> The problem is that access is denied to to the unsecured web resource 
> collection, even though they are defined as unsecured.  A blank HTML page is 
> returned instead of the appropriate resource.  After some debugging, I 
> discovered what seems to be a bug in the 
> org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class.  Consider the 
> following code fragment in the hasResourceCollection(...) method:
> 
> // Which user principal have we already authenticated?
> Principal principal = request.getUserPrincipal();
> //If we have no principal, then we should use the default.
> if (principal == null) {
> return request.isSecure();
> } else {
> Subject currentCaller = ((JAASTomcatPrincipal) 
> principal).getSubject();
> ContextManager.setCallers(currentCaller, currentCaller);
> }
> 
> When I make an HTTP connection to an unsecure web resource, I am 
> unauthenticated before I can login.  Thus, the principal in this case is 
> null.  In the case of a null principal, the code seems to base its 
> authorization on whether or not the request is secure!  This seems very 
> strange to me, as it should be able to accept normal, unauthenticated, HTTP 
> connections to unsecure web resources.
> I tried accessing the unsecured web resources over HTTPS, and sure enough, I 
> was able to access them because of the secure connection.  I'm not sure why 
> this works only over HTTPS...it should work in both cases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (AMQ-1096) activemq-console only has limited classpath/extensions directory functionality

[Adrian Co (JIRA)]

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

Adrian Co reassigned AMQ-1096:
--

Assignee: Adrian Co

> activemq-console only has limited classpath/extensions directory functionality
> --
>
> Key: AMQ-1096
> URL: https://issues.apache.org/activemq/browse/AMQ-1096
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 4.1.0
>Reporter: John Heitmann
> Assigned To: Adrian Co
>Priority: Minor
> Attachments: logpatch.diff
>
>
> Reproduction:
> 1) Untar the binary distribution.
> 2) Run bin/activemq and note what logging looks like (you should see output 
> to the console)
> 3) Stop the broker.
> 4) mv conf/log4j.properties foo/log4j.properties
> 5) export CLASSPATH=/path/to/foo/
> 6) export ACTIVEMQ_CLASSPATH=/path/to/foo/
> 7) Run './activemq --extdir /path/to/foo
> Now note there is no log output even though there are 3 different attempts to 
> set the proper directory. This is a regression from 4.0 to 4.1.
> There are 2 root problems in Main.java. First, 'classpaths' doesn't actually 
> pull from the classpath. The only thing that ever gets added to classpaths is 
> the hard coded 'conf' directory. Second, directories specified with --extdir 
> have jars and zips added, but not the directories themselves.
> The attached patch totally removes the vestigial classpaths, and fixes extdir 
> to pull in directories. This means that step 7 now works, but steps 5 and 6 
> are still useless. I like having only one way to specify classpath, but I 
> could see others wanting the CLASSPATH and ACTIVEMQ_CLASSPATH settings to 
> work.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (AMQ-1071) Activemq connection factory silently ignores the erroneous arguments in broker url

[Adrian Co (JIRA)]

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

Adrian Co reassigned AMQ-1071:
--

Assignee: Adrian Co

> Activemq connection factory silently ignores the erroneous arguments in 
> broker url
> --
>
> Key: AMQ-1071
> URL: https://issues.apache.org/activemq/browse/AMQ-1071
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
> Environment: Linux
>Reporter: Dileepan K
> Assigned To: Adrian Co
>Priority: Minor
>
> When an erroneous argument is passed to the broker url with failover, 
> activemq connection factory ignores the error. However if failover is 
> removed, it does throw exception. 
> Here is the example
> 1. 
> failover:(tcp://localhost:62012)?jms.prefetchPolicy.all=10&wireFormat.maxInactivityDuration=0&jms.optimizeAcknowledge=false
> 2. 
> tcp://localhost:62012?jms.prefetchPolicy.all=10&wireFormat.maxInactivityDuration=0&jms.optimizeAcknowledge=false
> Only the # 2 throws exception as jms.prefetchPolicy.all is an invalid 
> argument here

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy commented on GERONIMO-2695:
---

GERONIMO-2695-1.1.x.patch:

Jeff, I have verified on branches\1,2 that your fix addressed the dup 
GERONIMO-2339.  I have back-ported the fix to branches\1.1 and verified 
GERONIMO-2339.  Can you commit the fix to branches\1.1?  I have created 
GERONIMO-2695-1.1.x.patch for you to make it simpler.

> Requests using Non-secure HTTP connections cannot access unsecured web 
> resources
> 
>
> Key: GERONIMO-2695
> URL: https://issues.apache.org/jira/browse/GERONIMO-2695
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security, Tomcat, web
>Affects Versions: 1.1.1
> Environment: Geronimo running on Windows XP
>Reporter: Aman Nanner
> Assigned To: Jeff Genender
> Attachments: GERONIMO-2695-1.1.x.patch, test.war
>
>
> Consider the following fragment of my web.xml in my WAR:
> 
>
>   Unsecure Constraint
>   
>  Unsecure Resource Collection
>  /common/error/*
>  /common/includes/*
>  /common/Message.jsp
>  /common/resources/*
>  /common/security/login.jsp
>  /common/security/logout.jsp
>  /servlet/branding/*
>  /servlet/image/*
>  /servlet/login/*
>  /servlet/definecookie
>  GET
>  POST
>   
>   
>  NONE
>   
>
>
>   Secure Constraint
>   
>  Secure Resource Collection
>  /
>  GET
>  POST
>   
>   
>  MXSYSTEM
>   
>   
>  NONE
>   
>
>
>   FORM
>   
>  /common/security/PreLogin.jsp
>  /common/security/error.jsp
>   
>
>
>   Application System Role
>   MXSYSTEM
>
> 
> There are two sets of web resources defined: a secured web resource 
> collection, and an unsecured web resource collection.  The secured web 
> collection is by default everything that matches the "/" pattern.  In the 
> unsecured web collection, we use specific URL patterns so that certain 
> resources can be accessed prior to login.  Note that there is no security 
> role defined for the unsecured web resource collection, as these resources 
> should be available to every request.
> The problem is that access is denied to to the unsecured web resource 
> collection, even though they are defined as unsecured.  A blank HTML page is 
> returned instead of the appropriate resource.  After some debugging, I 
> discovered what seems to be a bug in the 
> org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class.  Consider the 
> following code fragment in the hasResourceCollection(...) method:
> 
> // Which user principal have we already authenticated?
> Principal principal = request.getUserPrincipal();
> //If we have no principal, then we should use the default.
> if (principal == null) {
> return request.isSecure();
> } else {
> Subject currentCaller = ((JAASTomcatPrincipal) 
> principal).getSubject();
> ContextManager.setCallers(currentCaller, currentCaller);
> }
> 
> When I make an HTTP connection to an unsecure web resource, I am 
> unauthenticated before I can login.  Thus, the principal in this case is 
> null.  In the case of a null principal, the code seems to base its 
> authorization on whether or not the request is secure!  This seems very 
> strange to me, as it should be able to accept normal, unauthenticated, HTTP 
> connections to unsecure web resources.
> I tried accessing the unsecured web resources over HTTPS, and sure enough, I 
> was able to access them because of the secure connection.  I'm not sure why 
> this works only over HTTPS...it should work in both cases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated GERONIMO-2695:
--

Attachment: GERONIMO-2695-1.1.x.patch

> Requests using Non-secure HTTP connections cannot access unsecured web 
> resources
> 
>
> Key: GERONIMO-2695
> URL: https://issues.apache.org/jira/browse/GERONIMO-2695
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security, Tomcat, web
>Affects Versions: 1.1.1
> Environment: Geronimo running on Windows XP
>Reporter: Aman Nanner
> Assigned To: Jeff Genender
> Attachments: GERONIMO-2695-1.1.x.patch, test.war
>
>
> Consider the following fragment of my web.xml in my WAR:
> 
>
>   Unsecure Constraint
>   
>  Unsecure Resource Collection
>  /common/error/*
>  /common/includes/*
>  /common/Message.jsp
>  /common/resources/*
>  /common/security/login.jsp
>  /common/security/logout.jsp
>  /servlet/branding/*
>  /servlet/image/*
>  /servlet/login/*
>  /servlet/definecookie
>  GET
>  POST
>   
>   
>  NONE
>   
>
>
>   Secure Constraint
>   
>  Secure Resource Collection
>  /
>  GET
>  POST
>   
>   
>  MXSYSTEM
>   
>   
>  NONE
>   
>
>
>   FORM
>   
>  /common/security/PreLogin.jsp
>  /common/security/error.jsp
>   
>
>
>   Application System Role
>   MXSYSTEM
>
> 
> There are two sets of web resources defined: a secured web resource 
> collection, and an unsecured web resource collection.  The secured web 
> collection is by default everything that matches the "/" pattern.  In the 
> unsecured web collection, we use specific URL patterns so that certain 
> resources can be accessed prior to login.  Note that there is no security 
> role defined for the unsecured web resource collection, as these resources 
> should be available to every request.
> The problem is that access is denied to to the unsecured web resource 
> collection, even though they are defined as unsecured.  A blank HTML page is 
> returned instead of the appropriate resource.  After some debugging, I 
> discovered what seems to be a bug in the 
> org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class.  Consider the 
> following code fragment in the hasResourceCollection(...) method:
> 
> // Which user principal have we already authenticated?
> Principal principal = request.getUserPrincipal();
> //If we have no principal, then we should use the default.
> if (principal == null) {
> return request.isSecure();
> } else {
> Subject currentCaller = ((JAASTomcatPrincipal) 
> principal).getSubject();
> ContextManager.setCallers(currentCaller, currentCaller);
> }
> 
> When I make an HTTP connection to an unsecure web resource, I am 
> unauthenticated before I can login.  Thus, the principal in this case is 
> null.  In the case of a null principal, the code seems to base its 
> authorization on whether or not the request is secure!  This seems very 
> strange to me, as it should be able to accept normal, unauthenticated, HTTP 
> connections to unsecure web resources.
> I tried accessing the unsecured web resources over HTTPS, and sure enough, I 
> was able to access them because of the secure connection.  I'm not sure why 
> this works only over HTTPS...it should work in both cases.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy commented on GERONIMO-1585:
---

Sorry if I added to the confusion.  Let us keep this JIRA on track.  Let us 
deal with each issue at the right place.

> Web app security on /* causes deployment exception
> --
>
> Key: GERONIMO-1585
> URL: https://issues.apache.org/jira/browse/GERONIMO-1585
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security, web
>Affects Versions: 1.1
> Environment: Geronimo 1.0 with Jetty and tomcat
>Reporter: Aaron Mulder
>Priority: Critical
> Fix For: 1.1.x
>
> Attachments: g1585-nologin.war, g1585.war, security.patch
>
>
> Deploying a web app with the following security block causes a deployment 
> error:
> 
> 
> All Pages
> /*
> GET
> POST
> PUT
> 
> 
> User
> 
> 
> Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 
> 2.4 spec).
> The error is:
> org.apache.geronimo.common.DeploymentException: Unable to initialize 
> webapp GBean
> at 
> org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842)
> ...
> Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the 
> URLPatternSpec cannot match the first URLPattern
> at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:54)
> at 
> javax.security.jacc.WebResourcePermission.(WebResourcePermission.java:54)
> at 
> org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215)
> at 
> org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821)
> ... 70 more
> Changing the url-pattern to / fixes the problem, but it seems to me that /* 
> ought to work too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Updated schema's in Geronimo website

[Rakesh Midha]

Can we update our website with latest Schema's. The link
http://geronimo.apache.org/schemas.html shows only 1.1 schema's, can we add
1.2 schema's also.

Thanks
Rakesh

Re: ClassLoader, JNDI and Dependency views in console

[Rakesh Midha]

Thanks Gianny

I didn't notice that I have recompiled openEJB, otherwise I would have
mentioned it in the comments. Thanks a lot, that saves my time :-)

Thanks
Rakesh

On 1/8/07, Gianny Damour <[EMAIL PROTECTED]> wrote:


Hi Chris,

I also had this problem. If you re-compile OpenEJB, then you should
be fine. In a few words, ModuleConfigurer.getModuleType has been
recently added and you are running with a EjbConfigurer which does
not define this method.

Thanks,
Gianny


On 08/01/2007, at 10:15 PM, Christopher M. Cardona wrote:

> Rakesh,
>
> I tried combining your patches last time and I was able to build
> the server but the it fails on startup with the following error:
>
> [*> ] 93%  20s  Loading
> org.apache.geronimo...19:29:49,3
> 12 ERROR [DeploymentFactoryImpl]
> java.lang.AbstractMethodError
>at
> org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia
> lize(JMXDeploymentManager.java:83)
>at
> org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager. t>(LocalDeploymentManager.java:28)
>at
> org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl
> .getDeploymentManager(DeploymentFactoryImpl.java:141)
>at
> org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment
> Manager(DirectoryHotDeployer.java:317)
>at
> org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc
> toryHotDeployer.java:157)
>at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
> nstance.java:984)
>at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
> (GBeanInstanceState.java:267)
> ...
>
> Not sure if I missed something. I'll give your combined patch a
> shot and let you know.
>
> Best wishes,
> chris
>
> Rakesh Midha wrote:
>>
>> Posted combined patch https://issues.apache.org/jira/secure/
>> attachment/12348488/allviews.patch in JIRA 2689
>>
>> Please review and commit.
>>
>> Thanks
>> Rakesh
>>
>> On 1/8/07, *Rakesh Midha* <[EMAIL PROTECTED]
>> > wrote:
>>
>> Hello All,
>>
>> Thanks for quick review,
>>
>> Joe, You are right about the difference in two prespectivies, the
>> debug view - dependencies is to show the hirarchical dependencies
>> of all components, modules and it also list repository elements,
>> whereas Config Manager is to list the potential ramifications
>> if a
>> configuration is removed.
>>
>> Another major difference being the Config Manager only shows
>> serviceparents only, where as this view directly list the direct
>> dependencies as well as serviceparents.
>>
>> Sachin, Prasad, David :
>> About
>> http://geronimo.apache.org/maven/server/modules/geronimo-
>> webservices-builder/dependencies.html
>> it shows the static dependencies of the default server, and
>> doens't list any customized services, repository elements,
>> components and configurations deployed on server. The idea is to
>> show the dependency information for a particular server in its
>> console.
>>
>> I hope it clear all the points discussed here.
>>
>> Chris, As you suggested I will create a single patch for all
>> three
>> and post it in one of the JIRA. (Will inform once it is done).
>>
>> Thanks
>> Rakesh
>>
>>
>>
>> On 1/5/07, *Christopher M. Cardona* <[EMAIL PROTECTED]
>> > wrote:
>>
>> Hi Rakesh,
>>
>> Thanks for the patches. I haven't looked at the source too
>> but
>> the pix
>> looks good. It would be nice if you can create a combined
>> patch for the
>> 3 jiras so people who wanted to check out the new debug views
>> can use
>> this as another option.
>>
>> Best wishes,
>> chris
>>
>> Rakesh Midha wrote:
>> > Hello
>> >
>> > First of all I am sorry for being missing from the list for
>> last few
>> > days, actually I have been trying to get this work item
>> done.
>> I kinda
>> > liked the idea of having ClassLoader, JNDI and Dependency
>> views in
>> > console.
>> >
>> > We have discussed this before in dev list, please read the
>> discussion
>> > below.
>> >
>> > I got this thing working, so I created three JIRA's, Please
>> have a
>> > look at https://issues.apache.org/jira/browse/GERONIMO-2689
>> > https://issues.apache.org/jira/browse/GERONIMO-2690
>> 
>> > https://issues.apache.org/jira/browse/GERONIMO-2691
>> >
>> > These three JIRA's adds 3 view in console which shows
>> > 1. JNDIView
>> > This view shows all the JNDI names binded in various
>> componet
>> contexts
>> > as well as Global context. Have a look at
>> > https://issues.apach

Re: ClassLoader, JNDI and Dependency views in console

[Rakesh Midha]

I am not sure what this problem is, please let me know what version of
geronimo you are using and I will try it and let you know.

Thanks
Rakesh

On 1/8/07, Christopher M. Cardona <[EMAIL PROTECTED]> wrote:


Rakesh,

I tried combining your patches last time and I was able to build the
server but the it fails on startup with the following error:

[*> ] 93%  20s  Loading
org.apache.geronimo...19:29:49,3
12 ERROR [DeploymentFactoryImpl]
java.lang.AbstractMethodError
at
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia
lize(JMXDeploymentManager.java:83)
at
org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.(LocalDeploymentManager.java:28)
at
org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl
.getDeploymentManager(DeploymentFactoryImpl.java:141)
at
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment
Manager(DirectoryHotDeployer.java:317)
at
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc
toryHotDeployer.java:157)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI
nstance.java:984)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart
(GBeanInstanceState.java:267)
...

Not sure if I missed something. I'll give your combined patch a shot and
let you know.

Best wishes,
chris

Rakesh Midha wrote:
>
> Posted combined patch
> https://issues.apache.org/jira/secure/attachment/12348488/allviews.patch
> in JIRA 2689
>
> Please review and commit.
>
> Thanks
> Rakesh
>
> On 1/8/07, *Rakesh Midha* <[EMAIL PROTECTED]
> > wrote:
>
> Hello All,
>
> Thanks for quick review,
>
> Joe, You are right about the difference in two prespectivies, the
> debug view - dependencies is to show the hirarchical dependencies
> of all components, modules and it also list repository elements,
> whereas Config Manager is to list the potential ramifications if a
> configuration is removed.
>
> Another major difference being the Config Manager only shows
> serviceparents only, where as this view directly list the direct
> dependencies as well as serviceparents.
>
> Sachin, Prasad, David :
> About
>
http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
> it shows the static dependencies of the default server, and
> doens't list any customized services, repository elements,
> components and configurations deployed on server. The idea is to
> show the dependency information for a particular server in its
> console.
>
> I hope it clear all the points discussed here.
>
> Chris, As you suggested I will create a single patch for all three
> and post it in one of the JIRA. (Will inform once it is done).
>
> Thanks
> Rakesh
>
>
>
> On 1/5/07, *Christopher M. Cardona* <[EMAIL PROTECTED]
> > wrote:
>
> Hi Rakesh,
>
> Thanks for the patches. I haven't looked at the source too but
> the pix
> looks good. It would be nice if you can create a combined
> patch for the
> 3 jiras so people who wanted to check out the new debug views
> can use
> this as another option.
>
> Best wishes,
> chris
>
> Rakesh Midha wrote:
> > Hello
> >
> > First of all I am sorry for being missing from the list for
> last few
> > days, actually I have been trying to get this work item done.
> I kinda
> > liked the idea of having ClassLoader, JNDI and Dependency
> views in
> > console.
> >
> > We have discussed this before in dev list, please read the
> discussion
> > below.
> >
> > I got this thing working, so I created three JIRA's, Please
> have a
> > look at https://issues.apache.org/jira/browse/GERONIMO-2689
> > https://issues.apache.org/jira/browse/GERONIMO-2690
> 
> > https://issues.apache.org/jira/browse/GERONIMO-2691
> >
> > These three JIRA's adds 3 view in console which shows
> > 1. JNDIView
> > This view shows all the JNDI names binded in various componet
> contexts
> > as well as Global context. Have a look at
> >
https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif
> > to get idea of what it will show. As we can see it shows JNDI
> names
> > for which are available at each component context level. For
> details
> > of how this is implemented please have a look  at comments of
> this JIRA.
> >
> > 2. ClassloaderView
> > This view shows all the classloaders and
> classes/interfaces  loaded by
> > that classloader in heir

Re: ClassLoader, JNDI and Dependency views in console

[Gianny Damour]

Hi Chris,

I also had this problem. If you re-compile OpenEJB, then you should  
be fine. In a few words, ModuleConfigurer.getModuleType has been  
recently added and you are running with a EjbConfigurer which does  
not define this method.


Thanks,
Gianny


On 08/01/2007, at 10:15 PM, Christopher M. Cardona wrote:


Rakesh,

I tried combining your patches last time and I was able to build  
the server but the it fails on startup with the following error:


[*> ] 93%  20s  Loading  
org.apache.geronimo...19:29:49,3

12 ERROR [DeploymentFactoryImpl]
java.lang.AbstractMethodError
   at  
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia

lize(JMXDeploymentManager.java:83)
   at  
org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.
t>(LocalDeploymentManager.java:28)
   at  
org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl

.getDeploymentManager(DeploymentFactoryImpl.java:141)
   at  
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment

Manager(DirectoryHotDeployer.java:317)
   at  
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc

toryHotDeployer.java:157)
   at  
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI

nstance.java:984)
   at  
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart

(GBeanInstanceState.java:267)
...

Not sure if I missed something. I'll give your combined patch a  
shot and let you know.


Best wishes,
chris

Rakesh Midha wrote:


Posted combined patch https://issues.apache.org/jira/secure/ 
attachment/12348488/allviews.patch in JIRA 2689


Please review and commit.

Thanks
Rakesh

On 1/8/07, *Rakesh Midha* <[EMAIL PROTECTED]  
> wrote:


Hello All,

Thanks for quick review,

Joe, You are right about the difference in two prespectivies, the
debug view - dependencies is to show the hirarchical dependencies
of all components, modules and it also list repository elements,
whereas Config Manager is to list the potential ramifications  
if a

configuration is removed.

Another major difference being the Config Manager only shows
serviceparents only, where as this view directly list the direct
dependencies as well as serviceparents.

Sachin, Prasad, David :
About
http://geronimo.apache.org/maven/server/modules/geronimo- 
webservices-builder/dependencies.html

it shows the static dependencies of the default server, and
doens't list any customized services, repository elements,
components and configurations deployed on server. The idea is to
show the dependency information for a particular server in its
console.

I hope it clear all the points discussed here.

Chris, As you suggested I will create a single patch for all  
three

and post it in one of the JIRA. (Will inform once it is done).

Thanks
Rakesh



On 1/5/07, *Christopher M. Cardona* <[EMAIL PROTECTED]
> wrote:

Hi Rakesh,

Thanks for the patches. I haven't looked at the source too  
but

the pix
looks good. It would be nice if you can create a combined
patch for the
3 jiras so people who wanted to check out the new debug views
can use
this as another option.

Best wishes,
chris

Rakesh Midha wrote:
> Hello
>
> First of all I am sorry for being missing from the list for
last few
> days, actually I have been trying to get this work item  
done.

I kinda
> liked the idea of having ClassLoader, JNDI and Dependency
views in
> console.
>
> We have discussed this before in dev list, please read the
discussion
> below.
>
> I got this thing working, so I created three JIRA's, Please
have a
> look at https://issues.apache.org/jira/browse/GERONIMO-2689
> https://issues.apache.org/jira/browse/GERONIMO-2690

> https://issues.apache.org/jira/browse/GERONIMO-2691
>
> These three JIRA's adds 3 view in console which shows
> 1. JNDIView
> This view shows all the JNDI names binded in various  
componet

contexts
> as well as Global context. Have a look at
> https://issues.apache.org/jira/secure/attachment/ 
12348327/12348327_jndi.gif
> to get idea of what it will show. As we can see it shows  
JNDI

names
> for which are available at each component context level.  
For

details
> of how this is implemented please have a look  at  
comments of

this JIRA.
>
> 2. ClassloaderView
> This view shows all the classloaders and
classes/interfaces  loaded by
> that classloader in heirarchica

Re: ClassLoader, JNDI and Dependency views in console

[Christopher M. Cardona]

Rakesh,

I tried combining your patches last time and I was able to build the 
server but the it fails on startup with the following error:


[*> ] 93%  20s  Loading 
org.apache.geronimo...19:29:49,3

12 ERROR [DeploymentFactoryImpl]
java.lang.AbstractMethodError
   at 
org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.initia

lize(JMXDeploymentManager.java:83)
   at 
org.apache.geronimo.deployment.plugin.jmx.LocalDeploymentManager.
t>(LocalDeploymentManager.java:28)
   at 
org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl

.getDeploymentManager(DeploymentFactoryImpl.java:141)
   at 
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment

Manager(DirectoryHotDeployer.java:317)
   at 
org.apache.geronimo.deployment.hot.DirectoryHotDeployer.doStart(Direc

toryHotDeployer.java:157)
   at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI

nstance.java:984)
   at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart

(GBeanInstanceState.java:267)
...

Not sure if I missed something. I'll give your combined patch a shot and 
let you know.


Best wishes,
chris

Rakesh Midha wrote:


Posted combined patch 
https://issues.apache.org/jira/secure/attachment/12348488/allviews.patch 
in JIRA 2689


Please review and commit.

Thanks
Rakesh

On 1/8/07, *Rakesh Midha* <[EMAIL PROTECTED] 
> wrote:


Hello All,

Thanks for quick review,

Joe, You are right about the difference in two prespectivies, the
debug view - dependencies is to show the hirarchical dependencies
of all components, modules and it also list repository elements,
whereas Config Manager is to list the potential ramifications if a
configuration is removed.

Another major difference being the Config Manager only shows
serviceparents only, where as this view directly list the direct
dependencies as well as serviceparents.

Sachin, Prasad, David :
About

http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
it shows the static dependencies of the default server, and
doens't list any customized services, repository elements,
components and configurations deployed on server. The idea is to
show the dependency information for a particular server in its
console.

I hope it clear all the points discussed here.

Chris, As you suggested I will create a single patch for all three
and post it in one of the JIRA. (Will inform once it is done).

Thanks
Rakesh



On 1/5/07, *Christopher M. Cardona* <[EMAIL PROTECTED]
> wrote:

Hi Rakesh,

Thanks for the patches. I haven't looked at the source too but
the pix
looks good. It would be nice if you can create a combined
patch for the
3 jiras so people who wanted to check out the new debug views
can use
this as another option.

Best wishes,
chris

Rakesh Midha wrote:
> Hello
>
> First of all I am sorry for being missing from the list for
last few
> days, actually I have been trying to get this work item done.
I kinda
> liked the idea of having ClassLoader, JNDI and Dependency
views in
> console.
>
> We have discussed this before in dev list, please read the
discussion
> below.
>
> I got this thing working, so I created three JIRA's, Please
have a
> look at https://issues.apache.org/jira/browse/GERONIMO-2689
> https://issues.apache.org/jira/browse/GERONIMO-2690

> https://issues.apache.org/jira/browse/GERONIMO-2691
>
> These three JIRA's adds 3 view in console which shows
> 1. JNDIView
> This view shows all the JNDI names binded in various componet
contexts
> as well as Global context. Have a look at
> 
https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif
> to get idea of what it will show. As we can see it shows JNDI
names
> for which are available at each component context level. For
details
> of how this is implemented please have a look  at comments of
this JIRA.
>
> 2. ClassloaderView
> This view shows all the classloaders and
classes/interfaces  loaded by
> that classloader in heirarchical fashion. Have a look at
> 
https://issues.apache.org/jira/secure/attachment/12348333/12348333_classloader.gif


> to get idea of what it will show. As we can see it shows
classes and
> interfaces for all the classloaders and its chi

Re: possible 1.2 problem

[Kevan Miller]

On Jan 6, 2007, at 4:51 PM, Jason Dillon wrote:

Are you building openejb by hand, or are the deployed snaps up to  
date?


I built OpenEJB locally. Looks like new snaps will need to be pushed  
out to pick up David J's changes...


--kevan

Re: ClassLoader, JNDI and Dependency views in console

[Rakesh Midha]

Posted combined patch
https://issues.apache.org/jira/secure/attachment/12348488/allviews.patch in
JIRA 2689

Please review and commit.

Thanks
Rakesh

On 1/8/07, Rakesh Midha <[EMAIL PROTECTED]> wrote:


Hello All,

Thanks for quick review,

Joe, You are right about the difference in two prespectivies, the debug
view - dependencies is to show the hirarchical dependencies of all
components, modules and it also list repository elements, whereas Config
Manager is to list the potential ramifications if a configuration is
removed.

Another major difference being the Config Manager only shows
serviceparents only, where as this view directly list the direct
dependencies as well as serviceparents.

Sachin, Prasad, David :
About
http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html
it shows the static dependencies of the default server, and doens't list
any customized services, repository elements, components and configurations
deployed on server. The idea is to show the dependency information for a
particular server in its console.

I hope it clear all the points discussed here.

Chris, As you suggested I will create a single patch for all three and
post it in one of the JIRA. (Will inform once it is done).

Thanks
Rakesh


On 1/5/07, Christopher M. Cardona <[EMAIL PROTECTED]> wrote:
>
> Hi Rakesh,
>
> Thanks for the patches. I haven't looked at the source too but the pix
> looks good. It would be nice if you can create a combined patch for the
> 3 jiras so people who wanted to check out the new debug views can use
> this as another option.
>
> Best wishes,
> chris
>
> Rakesh Midha wrote:
> > Hello
> >
> > First of all I am sorry for being missing from the list for last few
> > days, actually I have been trying to get this work item done. I kinda
> > liked the idea of having ClassLoader, JNDI and Dependency views in
> > console.
> >
> > We have discussed this before in dev list, please read the discussion
> > below.
> >
> > I got this thing working, so I created three JIRA's, Please have a
> > look at https://issues.apache.org/jira/browse/GERONIMO-2689
> > https://issues.apache.org/jira/browse/GERONIMO-2690
> > https://issues.apache.org/jira/browse/GERONIMO-2691
> >
> > These three JIRA's adds 3 view in console which shows
> > 1. JNDIView
> > This view shows all the JNDI names binded in various componet contexts
> > as well as Global context. Have a look at
> >
> https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif
> > to get idea of what it will show. As we can see it shows JNDI names
> > for which are available at each component context level. For details
> > of how this is implemented please have a look  at comments of this
> JIRA.
> >
> > 2. ClassloaderView
> > This view shows all the classloaders and classes/interfaces  loaded by
> > that classloader in heirarchical fashion. Have a look at
> >
> 
https://issues.apache.org/jira/secure/attachment/12348333/12348333_classloader.gif
> > to get idea of what it will show. As we can see it shows classes and
> > interfaces for all the classloaders and its child classloaders. For
> > details of how this is implemented please have a look  at comments of
> > this JIRA.
> >
> > 3. DependencyView
> > This view shows all the components and repository items and its
> > dependencies in hierarchical fashion in which they are loaded. To
> > facilitate locating of items of interest the tree view can be
> > searched.. Have a look at
> >
> 
https://issues.apache.org/jira/secure/attachment/12348336/12348336_dependency.gif
> > to get idea of what it will show. As we can see it shows dependencies
> > for each component. For details of how this is implemented please have
>
> > a look  at comments of this JIRA.
> >
> > This is a request that please try these patches and let me know your
> > comments on it. I think I liked it and these views will definatly be
> > useful for debugging purpose, and from my expierance I can tell that
> > all these views are trying to facilitate solving of problems which are
> > difficult to tackle otherwise.
> >
> > Also notice that we may like to add another section in navigation for
> > debug views as shown in
> >
> 
https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif
> > 
 >
> > this is not implemented for now but we may do it once we agree to put
> > the above views in console.
> >
> > Thanks in advance, please do have a look and comment.
> > Rakesh
> >
> > On 7/20/06, *Erin Mulder* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Aaron Mulder wrote:
> > > 
http://people.apache.org/~ammulder/classloaders.png
> > < http://people.apache.org/%7Eammulder/classloaders.png>
> > >
> > > However, I'm not sure how useful it will be -- it'll show you
> > > dependencies at the class loader le

[jira] Commented: (GERONIMO-2689) New View for JNDI name in all the contexts

[Rakesh Midha (JIRA)]

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

Rakesh Midha commented on GERONIMO-2689:



Posting a combined patch allview.patch which provides all the three views (JIRA 
2689, JIRA 2690 and JIRA 2691)


Please review and commit.
THanks

> New View for JNDI name in all the contexts
> --
>
> Key: GERONIMO-2689
> URL: https://issues.apache.org/jira/browse/GERONIMO-2689
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0
> Environment: Any
>Reporter: Rakesh Midha
> Assigned To: Rakesh Midha
> Fix For: 2.0
>
> Attachments: allviews.patch, common.patch, jndi.gif, 
> jndiview2689.patch, navigation.gif
>
>
> So many times we hit the Exception NamingNotFound, most of the times it 
> happens because of user error, missing references, wrong names or path or 
> user working in different context and system looking in some other context.
> I think it would be nice if in a console we can have a view of what all names 
> are binded or available in contexts of each application / module or component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2689) New View for JNDI name in all the contexts

[Rakesh Midha (JIRA)]

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

Rakesh Midha updated GERONIMO-2689:
---

Attachment: allviews.patch

> New View for JNDI name in all the contexts
> --
>
> Key: GERONIMO-2689
> URL: https://issues.apache.org/jira/browse/GERONIMO-2689
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0
> Environment: Any
>Reporter: Rakesh Midha
> Assigned To: Rakesh Midha
> Fix For: 2.0
>
> Attachments: allviews.patch, common.patch, jndi.gif, 
> jndiview2689.patch, navigation.gif
>
>
> So many times we hit the Exception NamingNotFound, most of the times it 
> happens because of user error, missing references, wrong names or path or 
> user working in different context and system looking in some other context.
> I think it would be nice if in a console we can have a view of what all names 
> are binded or available in contexts of each application / module or component.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira