Re: New threads launched from an EJB do not run as the same Subject as the launching thread

[David Jencks]

On Aug 26, 2007, at 11:05 PM, Vamsavardhana Reddy wrote:

New threads launched from an EJB context do not run as the same  
Subject as the thread that launched it.  This causes a failure when  
this new thread calls an EJB with restricted method permissions.   
Looks like JBoss and BEA Weblogic carry over Subjects to new  
threads that are launched from within an EJB.  Should we consider  
this functionality for Geronimo?



Aren't we supposed to prevent ejbs from starting threads?  Does the  
commonj thread pool have a facility for supplying the security  
context from the request submitting thread to the worker thread?


I guess we should do this, and I think we just need to use an  
InheritableThreadLocal in ContextManager.


thanks
david jencks

[jira] Created: (GERONIMO-3443) Error in Tomcat-Version: Webfront + Admin console stopped working

[Karsten Voges (JIRA)]

Error in Tomcat-Version: Webfront + Admin console stopped working
-

 Key: GERONIMO-3443
 URL: https://issues.apache.org/jira/browse/GERONIMO-3443
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Affects Versions: 2.0.x
 Environment: Windows XP
SUN JDK 1.6.0_02

Reporter: Karsten Voges


Error in Tomcat-Version: Webfront + Admin console stopped working. Pluto errors 
and nothing works after I tried to restart dojo-Application. After a complete 
Geronimo restart even the admin web console was not working.

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

[jira] Updated: (GERONIMO-3443) Error in Tomcat-Version: Webfront + Admin console stopped working

[Karsten Voges (JIRA)]

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

Karsten Voges updated GERONIMO-3443:


Attachment: 0.0.0.0_access_log.2007-08-27.txt
geronimo.log

See attached the Geronimo log for the errors and the access log where all the 
requests are captured, that lead to the error.
Hope that helps.
If you need further help, do not hesitate to contact me.

> Error in Tomcat-Version: Webfront + Admin console stopped working
> -
>
> Key: GERONIMO-3443
> URL: https://issues.apache.org/jira/browse/GERONIMO-3443
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0.x
> Environment: Windows XP
> SUN JDK 1.6.0_02
>Reporter: Karsten Voges
> Attachments: 0.0.0.0_access_log.2007-08-27.txt, geronimo.log
>
>
> Error in Tomcat-Version: Webfront + Admin console stopped working. Pluto 
> errors and nothing works after I tried to restart dojo-Application. After a 
> complete Geronimo restart even the admin web console was not working.

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

[jira] Commented: (GERONIMO-1602) Switching from Tomcat causes error in JAAS module: "Unable to instantiate login module"

[Karsten Voges (JIRA)]

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

Karsten Voges commented on GERONIMO-1602:
-

Sorry for not replying earlier. I have switched companies, so I cannot test the 
problem anymore. Sorry.

> Switching from Tomcat causes error in JAAS module: "Unable to instantiate 
> login module"
> ---
>
> Key: GERONIMO-1602
> URL: https://issues.apache.org/jira/browse/GERONIMO-1602
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security, Tomcat
>Affects Versions: 1.0
> Environment: Windows XP Prof, JDK 1.5.0_06, Geronimo 1.0 (Tomcat, 
> .zip)
>Reporter: Karsten Voges
> Fix For: 1.1.x
>
> Attachments: geronimo-JAAS-login-error.txt
>
>
> I have a problem with porting a Tomcat application to Geronimo. The error 
> stacktrace is attached.
> I deployed the war without any deployment plan and the app seams to be 
> working (JSPs work and the startup-servlet works as well)
> But the JAASLoginModule was missing, so I could not log in. -> so far no 
> Problem!
> Afterwards I configured a security realm with the console and after a restart 
> my app does not complain about a missing LoginModule but throws the attached 
> error stacktrace.
> For Tomcat I do the following:
> in catalina.properties I set
> ###JAAS
> java.security.auth.login.config=${catalina.base}/conf/login.config
> and the login.config looks like this:
> MyApp {
> de.jato.security.auth.module.JatoServletLoginModule Sufficient 
> loginServlet="/login/login.jsp";
> };
> I tried to use a special geronimo-web.xml where I set the
> true
> But I still get the same error:
> javax.security.auth.login.LoginException: 
> org.apache.geronimo.common.GeronimoSecurityException: Unable to instantiate 
> login module
> Caused by: java.lang.ClassNotFoundException: 
> de.jato.security.auth.module.JatoServletLoginModule
> Am I doing something wrong? The class is in the war I deployed, and 
> everything works fine in Tomcat.

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

should there be a TAG geronimo-txmanager-parent-2.0.1?

[Vamsavardhana Reddy]

When I am building G 2.0.1, I am noticing a
geronimo-txmanager-parent-2.0.1.jar.  But I do not see a
geronimo-txmanager-parent-2.0.1 tag under
https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags.  Should
there be one?

Vamsi

Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)

[Eric Dofonsou]

+1

- Original Message 
From: Daryl Richter <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Monday, August 27, 2007 7:34:08 AM
Subject: Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)


On Aug 25, 2007, at 2:12 AM, Nodet Guillaume wrote:

> Ok, sounds like we have enough people.
> So we just need to find a data and an hour.
> What about Friday 3 pm GMT,  11 am EST, 8 am PST
> Adrian, I'm not sure how to find a time that would suits you...
> Other propositions are welcome...

+1

>
> Cheers,
> Guillaume Nodet
>
>
-- 
Daryl
http://itsallsemantics.com

"Under capitalism, man exploits man.
  Under communism, it's just the opposite."
 -- John Kenneth Galbraith


   

Building a website is a piece of cake. Yahoo! Small Business gives you all the 
tools to get online.
http://smallbusiness.yahoo.com/webhosting

[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application

[Paul McMahan (JIRA)]

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

Paul McMahan commented on GERONIMO-2964:


Donald, that is right, and when combined with the schema change this is IMO a 
good reason to only apply the change to the 2.1 branch.  Apologies to Aman for 
accidentally overlooking this patch for 2.0.1.  Vamsi, I'll follow up on this 
JIRA unless you were already planning to.

> Cannot specify the Tomcat work directory for a web application
> --
>
> Key: GERONIMO-2964
> URL: https://issues.apache.org/jira/browse/GERONIMO-2964
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.2, 2.0-M5
>Reporter: Aman Nanner
>Priority: Minor
> Fix For: 1.2, 2.1
>
> Attachments: tomcat-config-workdir.patch, tomcat-workdir.patch
>
>
> In Tomcat, a work directory can be specified for a web application in a 
> WEB-INF/context.xml file.  The GeronimoStandardContext does not permit the 
> user to specify a work directory, and so the work directory defaults to 
> var/catalina/work/.
> I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to 
> permit the user to optionally specify a work directory.  This work directory 
> is then propagated into the TomcatContext.  I've tested this and it seems to 
> work well.

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

Re: removal of spring dependencies from cxf module

[Kevan Miller]

On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote:



From my standpoint, it would be greatly preferred if you could find  
a way

to leave spring for CXF.   There is definitely a lot of functionality
that would be lost if spring is not available.  In particular, if a  
user

want to configure various things like message logging or
WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc...,
without the spring config, it becomes quite a bit harder.   For very
basic usage, spring is optional.   But once you want some
customizations, you really need it.


OK. First I've heard of loss of functionality... Is there loss of  
functionality? Or things become harder without Spring? If things  
become harder, an important question is who pays the price? The  
embedder (i.e. us)? Or the user?


I have no real issue with our CXF server module requiring Spring.

I'm less happy if we're requiring that Spring be accessible from a  
client application module to configure CXF web services client  
capabilities.


I'm way less happy if we require the same Spring instance be  
accessible from the CXF server module and the client application  
module. This is the case, at the moment. I think this needs to be  
changed.




I suppose one option might be to document how to put spring back in if
someone needs it.   We could then add more advanced thing to those  
docs

like where to get the additional jars for WS-RM/WS-A/WS-Security, JMS
transports, etc   Kind of an "Advanced WebServices with CXF" type
docs.


Can you point me to documentation on how a user configures this  
functionality currently?


--kevan

[jira] Commented: (GERONIMO-3401) Stop of module from "System Modules" in console should warn user of destructive action

[Joe Bohn (JIRA)]

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

Joe Bohn commented on GERONIMO-3401:


Uninstall breaks the server on those components listed regardless of it being 
initiated from the console or command line.   I haven't yet run through all of 
the system modules but for openejb stopping only prevents the console from 
functioning and doesn't  prevent the server from a restart.  The console 
function can be easily restored in the stop scenario by a command line start of 
the console.

Paul, Geronimo-3443 is somewhat related but I don't think it is directly 
related.  It's a restart scenario.  In our restart we must stop the specified 
component and all depent components (such as the console for DOJO) which is 
somewhat related to this issue.  However, I think the real issue there is that 
in a restart scenario we only "restart" the subject component and do nothing 
more with components that were stopped with dependencies upon that component.  
I think the expected user behavior in that cause would be to restart not only 
the subject component but all components that were subsequently stopped due to 
dependencies.  

> Stop of module from "System Modules" in console should warn user of 
> destructive action
> --
>
> Key: GERONIMO-3401
> URL: https://issues.apache.org/jira/browse/GERONIMO-3401
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0, 2.0.x
> Environment: Geronimo 2.0.1-SNAPSHOT using Tomcat JEE assembly.  Most 
> likely affects others as well
>Reporter: Matt Hogstrom
>Assignee: Joe Bohn
> Fix For: 2.0.x
>
>
> When using the Geronimo Console to stop of a module a 404 is received in the 
> console.  In this case an attempt to stop OpenEJB.  The console then becomes 
> unusable and also does not survive a restart.  It appears the console needs 
> to be re-installed.
> {panel:title=Error reported to Browser| borderStyle=dashed| borderColor=#ccc| 
> titleBGColor=#F7D6C1| bgColor=#CE} 
> HTTP Status 404 - 
> /console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view
> type Status report
> message 
> /console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view
> description The requested resource 
> (/console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view)
>  is not available.
> {panel}
> {panel:title=Exception LoggedMy Title| borderStyle=dashed| borderColor=#ccc| 
> titleBGColor=#F7D6C1| bgColor=#CE}
> [] received stop signal
> 00:59:03,833 ERROR [Servlet] Exception caught: 
> org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid 
> to gbean: 
> org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car,j2eeType=JCAConnectionTracker,name=ConnectionTracker
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:87)
> at 
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$4301e6fc.exit()
> at 
> org.apache.geronimo.tomcat.interceptor.InstanceContextBeforeAfter.after(InstanceContextBeforeAfter.java:73)
> at 
> org.apache.geronimo.tomcat.interceptor.ComponentContextBeforeAfter.after(ComponentContextBeforeAfter.java:46)
> at 
> org.apache.geronimo.tomcat.interceptor.PolicyContextBeforeAfter.after(PolicyContextBeforeAfter.java:70)
> at 
> org.apache.geronimo.tomcat.interceptor.UserTransactionBeforeAfter.after(UserTransactionBeforeAfter.java:47)
> at 
> org.apache.geronimo.tomcat.listener.DispatchListener.afterDispatch(DispatchListener.java:86)
> at 
> org.apache.geronimo.tomcat.listener.DispatchListener.instanceEvent(DispatchListener.java:59)
> at 
> org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:275)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:682)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.j

[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy commented on GERONIMO-2964:
---

Paul, Donald,

I don't think it is necessary to change the constructor.  Since the only way 
the new workDir parameter it is used in the constructor is to initialize a 
member "this.workDir", we can do away by adding a setter method.  Let me see if 
I can come up with a new patch that does not change the constructor.  If not, 
we can forgo the fix for 2.0.2 and fix it in 2.1.  The only thing I was 
concerned is whether a schema change from 2.0.1 to 2.0.2 is acceptable.  May be 
it is if we don't break compatibility.  Will report back soon.

Aman,
Will it be possible for you to post a simple test war file to verify if my new 
patch (if any).  If not now, it will anyway be useful later when the issue is 
addressed.

Thanks

> Cannot specify the Tomcat work directory for a web application
> --
>
> Key: GERONIMO-2964
> URL: https://issues.apache.org/jira/browse/GERONIMO-2964
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.2, 2.0-M5
>Reporter: Aman Nanner
>Priority: Minor
> Fix For: 1.2, 2.1
>
> Attachments: tomcat-config-workdir.patch, tomcat-workdir.patch
>
>
> In Tomcat, a work directory can be specified for a web application in a 
> WEB-INF/context.xml file.  The GeronimoStandardContext does not permit the 
> user to specify a work directory, and so the work directory defaults to 
> var/catalina/work/.
> I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to 
> permit the user to optionally specify a work directory.  This work directory 
> is then propagated into the TomcatContext.  I've tested this and it seems to 
> work well.

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

[jira] Commented: (GERONIMO-3401) Stop of module from "System Modules" in console should warn user of destructive action

[Paul McMahan (JIRA)]

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

Paul McMahan commented on GERONIMO-3401:


{quote}
However, I think the real issue there is that in a restart scenario we only 
"restart" the subject component and do nothing more with components that were 
stopped with dependencies upon that component. I think the expected user 
behavior in that cause would be to restart not only the subject component but 
all components that were subsequently stopped due to dependencies.
{quote}

Agreed.  These two cases could be handled separately or we could consider 
generalizing the user interface for component lifecycle to address these and 
other potentially confusing scenarios that will arise all at one go.I think 
that right now the user interface is technically correct but is not intuitive.  
For the command line client maybe that is OK, but for the graphical UI we could 
 allow the user to make more informed decisions by providing a better visual 
representation of the component hierarchy.  Attaching the lifecycle controls to 
the Dependency Viewer might be a good first step.  Also, the lifecycle controls 
for components that are in the console's dependency path could be disabled 
since they are required by the viewer itself (they can still be controlled from 
the CLI).   Just throwing out some ideas.

> Stop of module from "System Modules" in console should warn user of 
> destructive action
> --
>
> Key: GERONIMO-3401
> URL: https://issues.apache.org/jira/browse/GERONIMO-3401
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0, 2.0.x
> Environment: Geronimo 2.0.1-SNAPSHOT using Tomcat JEE assembly.  Most 
> likely affects others as well
>Reporter: Matt Hogstrom
>Assignee: Joe Bohn
> Fix For: 2.0.x
>
>
> When using the Geronimo Console to stop of a module a 404 is received in the 
> console.  In this case an attempt to stop OpenEJB.  The console then becomes 
> unusable and also does not survive a restart.  It appears the console needs 
> to be re-installed.
> {panel:title=Error reported to Browser| borderStyle=dashed| borderColor=#ccc| 
> titleBGColor=#F7D6C1| bgColor=#CE} 
> HTTP Status 404 - 
> /console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view
> type Status report
> message 
> /console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view
> description The requested resource 
> (/console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view)
>  is not available.
> {panel}
> {panel:title=Exception LoggedMy Title| borderStyle=dashed| borderColor=#ccc| 
> titleBGColor=#F7D6C1| bgColor=#CE}
> [] received stop signal
> 00:59:03,833 ERROR [Servlet] Exception caught: 
> org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid 
> to gbean: 
> org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car,j2eeType=JCAConnectionTracker,name=ConnectionTracker
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:87)
> at 
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$4301e6fc.exit()
> at 
> org.apache.geronimo.tomcat.interceptor.InstanceContextBeforeAfter.after(InstanceContextBeforeAfter.java:73)
> at 
> org.apache.geronimo.tomcat.interceptor.ComponentContextBeforeAfter.after(ComponentContextBeforeAfter.java:46)
> at 
> org.apache.geronimo.tomcat.interceptor.PolicyContextBeforeAfter.after(PolicyContextBeforeAfter.java:70)
> at 
> org.apache.geronimo.tomcat.interceptor.UserTransactionBeforeAfter.after(UserTransactionBeforeAfter.java:47)
> at 
> org.apache.geronimo.tomcat.listener.DispatchListener.afterDispatch(DispatchListener.java:86)
> at 
> org.apache.geronimo.tomcat.listener.DispatchListener.instanceEvent(DispatchListener.java:59)
> at 
> org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:275)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:682)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
>   

[jira] Closed: (GERONIMO-3240) Unable to obtain physical connection to jdbc:derby:

[Donald Woods (JIRA)]

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

Donald Woods closed GERONIMO-3240.
--

   Resolution: Duplicate
Fix Version/s: 2.1
   2.0.x

GERONIMO-3380 documented the same problem, which was fixed by GERONIMO-3374.

> Unable to obtain physical connection to jdbc:derby:
> ---
>
> Key: GERONIMO-3240
> URL: https://issues.apache.org/jira/browse/GERONIMO-3240
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.0-M6
> Environment: Geronimo v2.0-M6-rc3
>Reporter: Hernan Cunico
> Fix For: 2.0.x, 2.1
>
> Attachments: geronimo-3240.patch
>
>
> Created a sample db on the embedded Derby database using the admin console. 
> Created a connection pool to that database with the wizard, the "Test 
> Connection" works fine during pool creation.
> When I try to access that pool from an application I get an error as if the 
> database wouldn't exists.
> 13:28:24,218 ERROR [MCFConnectionInterceptor] Error occurred creating 
> ManagedConnection for [EMAIL PROTECTED]
> javax.resource.spi.ResourceAllocationException: Unable to obtain physical 
> connection to jdbc:derby:sample
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection(JDBCDriverMCF.java:98)
> at 
> org.tranql.connector.jdbc.JDBCDriverMCF.createManagedConnection(JDBCDriverMCF.java:73)
> at 
> org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getConnection(MCFConnectionInterceptor.java:48)
> at 
> org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterceptor.getConnection(LocalXAResourceInsertionInterceptor.java:41)
> at 
> org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor.internalGetConnection(SinglePoolConnectionInterceptor.java:66)
> at 
> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
> at 
> org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.getConnection(TransactionEnlistingInterceptor.java:46)
> at 
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.getConnection(TransactionCachingInterceptor.java:95)
> at 
> org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getConnection(ConnectionHandleInterceptor.java:43)
> at 
> org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCCLInterceptor.java:39)
> at 
> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.getConnection(ConnectionTrackingInterceptor.java:66)
> at 
> org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:61)
> at 
> org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56)
> at 
> org.apache.geronimo.samples.dbtester.beans.DBManagerBean.getTableList(DBManagerBean.java:76)
> at 
> org.apache.geronimo.samples.dbtester.web.ListTablesServlet.listTables(ListTablesServlet.java:32)
> at 
> org.apache.geronimo.samples.dbtester.web.ListTablesServlet.doGet(ListTablesServlet.java:17)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:358)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandl

[jira] Created: (SM-1042) Build fails in Java 6: Cannot find symbol StandardMBean(Object, Class)

[Gert Vanthienen (JIRA)]

Build fails in Java 6: Cannot find symbol StandardMBean(Object, Class)
-

 Key: SM-1042
 URL: https://issues.apache.org/activemq/browse/SM-1042
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-core
Affects Versions: 3.1.1
Reporter: Gert Vanthienen
Assignee: Gert Vanthienen


Seems to be a problem that is mentioned in the adoption guide: 
http://java.sun.com/javase/6/webnotes/adoption/adoptionguide.html#2.2.1

{noformat}
[INFO] Compilation failure
C:\projects\servicemix\core\servicemix-core\src\main\java\org\apache\servicemix\jbi\management\BaseStandardMBean.java:[117,8]
 cannot
 find symbol
symbol  : constructor 
StandardMBean(java.lang.Object,java.lang.Class)
location: class javax.management.StandardMBean
{noformat}

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

Re: removal of spring dependencies from cxf module

[Jeff Genender]

Kevan Miller wrote:
> 
> On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote:
> 
>>
>> From my standpoint, it would be greatly preferred if you could find a way
>> to leave spring for CXF.   There is definitely a lot of functionality
>> that would be lost if spring is not available.  In particular, if a user
>> want to configure various things like message logging or
>> WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc...,
>> without the spring config, it becomes quite a bit harder.   For very
>> basic usage, spring is optional.   But once you want some
>> customizations, you really need it.
> 
> OK. First I've heard of loss of functionality... Is there loss of
> functionality? Or things become harder without Spring? If things become
> harder, an important question is who pays the price? The embedder (i.e.
> us)? Or the user?

I have to agree with Dan on this.  This is clearly our problem.  It's
Geronimo's classloaders that are causing the issue.  We are taking away
functionality at the expense of our inability to handle Spring.

> 
> I have no real issue with our CXF server module requiring Spring.
> 
> I'm less happy if we're requiring that Spring be accessible from a
> client application module to configure CXF web services client
> capabilities.
> 
> I'm way less happy if we require the same Spring instance be accessible
> from the CXF server module and the client application module. This is
> the case, at the moment. I think this needs to be changed.
> 

Why should it be changed?  This seems to work with someone using
Tomcat...just not Geronimo.

>>
>> I suppose one option might be to document how to put spring back in if
>> someone needs it.   We could then add more advanced thing to those docs
>> like where to get the additional jars for WS-RM/WS-A/WS-Security, JMS
>> transports, etc   Kind of an "Advanced WebServices with CXF" type
>> docs.
> 
> Can you point me to documentation on how a user configures this
> functionality currently?
> 
> --kevan

Re: removal of spring dependencies from cxf module

[Daniel Kulp]

Kevan,

On Monday 27 August 2007, Kevan Miller wrote:
> On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote:
> > From my standpoint, it would be greatly preferred if you could find
> > a way
> > to leave spring for CXF.   There is definitely a lot of
> > functionality that would be lost if spring is not available.  In
> > particular, if a user
> > want to configure various things like message logging or
> > WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking,
> > etc..., without the spring config, it becomes quite a bit harder.  
> > For very basic usage, spring is optional.   But once you want some
> > customizations, you really need it.
>
> OK. First I've heard of loss of functionality... Is there loss of
> functionality? Or things become harder without Spring?

For the most part, it's "things become much harder," mostly because we 
really only document the Spring way of doing things.  Doing 
things "non-spring" requires a bunch of casting of JAX-WS things into 
proprietary things, calling semi-hidden API's, etc...   The spring way 
is very clean, documented, etc...   See:
http://cwiki.apache.org/CXF20DOC/configuration.html
particularly the sub-pages listed at the bottom.

One area that definitely doesn't work without spring is the ws-policy 
stuff.   Turning on policy requires some spring stuff right now.   I 
think that's logged as a bug.

> If things 
> become harder, an important question is who pays the price? The
> embedder (i.e. us)? Or the user?

Definitely the user IF they need something outside the normal "soap/http" 
cases.   For just straight JAX-WS TCK compliance stuff, it doesn't 
matter one way or the other. 

One example:  lets say your using a JAX-WS client in your application 
that needs to talk to an OLD .NET service.   The older .NET stuff 
sometimes doesn't like HTTP chunking.There are docs at:
http://cwiki.apache.org/CXF20DOC/client-http-transport.html
to describe how to configure the client to not use chunking.   There's 
also a bunch of things there for configuring the SSL connections, etc...


> I have no real issue with our CXF server module requiring Spring.
>
> I'm less happy if we're requiring that Spring be accessible from a
> client application module to configure CXF web services client
> capabilities.

Can it be optional?   Set some filtering thing so if they want/need the 
spring stuff, they can get it?

That all said, I DON'T know if Geronimo current exposes a spring context 
or anything that would currently allow any of that to work.   My gut 
feeling says no, but I'm not really sure. It's quite possible that 
it doesn't work in Geronimo right now anyway.   It's probably that the 
spring stuff in Geronimo is on a more "global" basis and wouldn't allow 
per-application configuration anyway.   Probably Jarek would need to 
weigh in how that currently works as I don't really know.

Ideally to me, if the app has a META-INF/cxf.xml or similar (some other 
key or something), the spring stuff would allow configuring of a bunch 
of the things specific for that application.

Dan


> I'm way less happy if we require the same Spring instance be
> accessible from the CXF server module and the client application
> module. This is the case, at the moment. I think this needs to be
> changed.
>
> > I suppose one option might be to document how to put spring back in
> > if someone needs it.   We could then add more advanced thing to
> > those docs
> > like where to get the additional jars for WS-RM/WS-A/WS-Security,
> > JMS transports, etc   Kind of an "Advanced WebServices with CXF"
> > type docs.
>
> Can you point me to documentation on how a user configures this
> functionality currently?
>
> --kevan



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog

[jira] Commented: (GERONIMO-3401) Stop of module from "System Modules" in console should warn user of destructive action

[Joe Bohn (JIRA)]

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

Joe Bohn commented on GERONIMO-3401:


{quote}
Agreed.  These two cases could be handled separately or we could consider 
generalizing the user interface for component lifecycle to address these and 
other potentially confusing scenarios that will arise all at one go.I think 
that right now the user interface is technically correct but is not intuitive.  
{quote}
I'm not as sure that either the UI or the command line are technically correct 
today regarding restart ... but it's probably a bike shed issue.  I think a 
reasonable expectation of a user after a restart is that the system is in the 
same state WRT active components prior to the restart.  If we choose to keep 
the current behavior then we need to do a better job warning the user of the 
consequences and help by listing the components that are stopped and not 
restarted.  

{quote}
For the command line client maybe that is OK, but for the graphical UI we could 
 allow the user to make more informed decisions by providing a better visual 
representation of the component hierarchy.  Attaching the lifecycle controls to 
the Dependency Viewer might be a good first step.  
{quote}
Perhaps ... but the dependency viewer sometimes make it difficult to locate the 
module that you want to operate on and the dependencies are actually inverted 
from what is needed for these operations (the current dependencies show what 
cars/jars this module is dependent upon rather than which modules are dependent 
upon it which would be the ones affected by the operation).

{quote}
Also, the lifecycle controls for components that are in the console's 
dependency path could be disabled since they are required by the viewer itself 
(they can still be controlled from the CLI).   Just throwing out some ideas.
{quote}
Yes, that is certainly the quick and easy way out ... which is also why I did 
some digging to understand the components that actually create problems for the 
console and/or the server.  The real answer here is   I think I need to take 
this discussion to the dev list soon but I'd like to get some more details 
first.



> Stop of module from "System Modules" in console should warn user of 
> destructive action
> --
>
> Key: GERONIMO-3401
> URL: https://issues.apache.org/jira/browse/GERONIMO-3401
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0, 2.0.x
> Environment: Geronimo 2.0.1-SNAPSHOT using Tomcat JEE assembly.  Most 
> likely affects others as well
>Reporter: Matt Hogstrom
>Assignee: Joe Bohn
> Fix For: 2.0.x
>
>
> When using the Geronimo Console to stop of a module a 404 is received in the 
> console.  In this case an attempt to stop OpenEJB.  The console then becomes 
> unusable and also does not survive a restart.  It appears the console needs 
> to be re-installed.
> {panel:title=Error reported to Browser| borderStyle=dashed| borderColor=#ccc| 
> titleBGColor=#F7D6C1| bgColor=#CE} 
> HTTP Status 404 - 
> /console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view
> type Status report
> message 
> /console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view
> description The requested resource 
> (/console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view)
>  is not available.
> {panel}
> {panel:title=Exception LoggedMy Title| borderStyle=dashed| borderColor=#ccc| 
> titleBGColor=#F7D6C1| bgColor=#CE}
> [] received stop signal
> 00:59:03,833 ERROR [Servlet] Exception caught: 
> org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid 
> to gbean: 
> org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car,j2eeType=JCAConnectionTracker,name=ConnectionTracker
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:87)
> at 
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$4301e6fc.exit()
> at 
> org.apache.geronimo.tomcat.interceptor.InstanceContextBeforeAfter.after(InstanceContextBeforeAfter.java:73)
> at 
> org.apache.geronimo.tomcat.interceptor.ComponentContextBeforeAfter.after(ComponentContextBeforeAfter.java:46)
> at 
> org.apache.geronimo.tomcat.inte

Re: Server monitoring and management

[Erik B. Craig]

Paul,

I agree that an integration of the JMX view and the work we are doing is
something we should be doing (and are now planning on), as well as moving
towards using JSR77 as Anita has also mentioned. As far as the 'big picture'
with what we're working on goes, I believe the best approach would be
integrate what is currently done with the JMX viewer into the plug-in that
we're developing, as you have mentioned, expanding it's capability to view
any of the machines that the monitoring node would able to view.

As far as the Hyperic plug-in goes... I'd definitely be willing to work
towards that, however with the goal of this project resulting in more of a
'Management plug-in with some monitoring abilities' instead of a 'Monitoring
plug-in with some management abilities', I'm wondering if it would be worth
the focus at present? I suppose it really depends on how closely we can
align the two goals, given the licensing differences between Geronimo and
Hyperic (GPL2 if I'm not mistaken).

What you mentioned about collaborating with the terracotta guys, that would
be incredibly helpful in outlining some basic things to strive for, I would
definitely like to go down this avenue if possible. However, I'm not
entirely sure who I would contact or how I would go about doing it, the same
goes for Hyperic.


Thanks
Erik B. Craig

On 8/24/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>
> Erik,  this is some very interesting work.  Thanks for posting all
> these details.
>
> Like Anita's comment in GERONIMO-3441, I'm wondering whether or not
> it would make sense to implement these new capabilities more tightly
> with the JMX capabilities already in the server.  I don't have her
> depth of knowledge to follow on all the details, but from a
> conceptual point of view I do tend agree with her.  All that console
> refactoring you mentioned is still a work in progress.  But FYI I
> included the JMX viewer in a "debug views" plugin [1] that also
> contains those other dojo based viewers (classloader, dependency,
> JNDI, and LDAP).Given the amount of additional capabilities that
> we could add around the JMX view (i.e. the work you have described
> here) I think we could actually make it part of a separate management
> plugin instead.
>
> On a related note, for some time I have thought it would be cool to
> have a Hyperic plugin for Geronimo.  It would provide many of the
> capabilities you have described.  From a technical point of view I
> think its possible because its uses j2ee as its runtime framework,
> but there may be non-technical issues someone could point out.  If
> there's interest we could look into collaborating with them on a
> plugin as part of the investigation you have described below.
>
> One more thing -- I don't know if its within the scope of this work,
> but I think it would be very useful we could also think about
> providing some generic way to manage and configure clusters in
> Geronimo.  Clustering technology is coming at us pretty fast right
> now and our users are going to need some way to interact with all
> those knobs and dials without cracking open a bunch of XML files.
> Last I heard the Terracotta guys were working on a portlet for the
> admin console.  Maybe they can suggest some functionality that can/
> should be implemented in a generic way within a management view.
>
> Best wishes,
> Paul
>
> [1] http://svn.apache.org/repos/asf/geronimo/plugins/debugviews
>
>
> On Aug 23, 2007, at 5:56 PM, Erik B. Craig wrote:
>
> > All,
> >
> > Recently Viet Nguyen and myself have been working on a project that
> > would ultimately assist a great deal in monitoring and managing
> > services within a single geronimo instance, as well as in a cluster
> > environment with upwards of thousands of machines. While it is
> > currently in its infant stages, we felt it best to get some basic
> > framework down and take it here as soon as possible to get as much
> > community involvement in the project as possible, hopefully
> > resulting in a much more polished product at the end.
> >
> > Currently what we have is a collection agent (MBean) that will run
> > on a given instance of geronimo (can be anything minimal and up),
> > collecting data from Tomcat only at present (No worries, we haven't
> > forgotten about jetty and our other core component friends). This
> > is done at a set interval and thrown into an XML file residing in
> > the /var directory. This mbean also serves as a jmx server
> > connection, ultimately providing the gateway to any number of
> > operations and data requests (deploy/undeploys, star/stops,
> > attribute modifications) from a 'management node' to the machine
> > running this mbean in a clustered environment.
> >
> > In conjuction with this, we have also been doing the basic work on
> > a porlet designed around the new (improved) much more plugable
> > admin console that Paul has been doing a lot of work on lately.
> > Currently it is utilizing dojo chart to generate graphs on req

Re: Adding j2g to site

[Erik B. Craig]

I do believe that the devtools subproject is indeed the best place for it
given it's purpose and functionality, that said, here are some proposed
changes to the devtools subproject page.

Add a section identical to the existing 'Eclipse Plug-in' that contains the
following:
--
 J2G Migration Tool

JBoss to Geronimo (J2G(link to
http://cwiki.apache.org/confluence/display/GMOxDOC20/J2G+Migration+Tool)) is
a tool set built as Eclipse SDK plug-ins designed to assist in migrating the
sources of an application written for the JBoss application server or
written for Java 2 Enterprise Edition (J2EE) to the Apache Geronimo
platform.
Prerequisites

   -

   Sun JDK 5.0+ (J2SE 1.5)
   -

   Eclipse SDK 3.3 with JDT Core Plug-in
   -

   Apache Geronimo 1.1.1 and up
   -

   Application written for JBoss 3.2 and up or J2EE 1.2 and up.

--
In addition to this, revamp the 'Downloads' section of the page to contain
the following:
---
 Downloads

*Eclipse Plug-in Latest Release - Version 1.2.0*
Version 1.2.0 of the Eclipse Plug-in has been released. The plugin can be
installed directly from within WTP version
1.5.2,
by clicking on the "Don't see your server
listed?"
link when defining a runtime in WTP.

Alternatively, the plugin can be also be installed via the update manager by
creating a new remote site pointing to
http://geronimo.apache.org/devtools
.

The latest release supports deployment to Geronimo 1.1.x and all previous
versions. See the release
notesfor
additional information.

*J2G Migration Tool 1.0*

The first release of the J2G migration tool can be downloaded from the wiki
page for the tool here(link to
http://cwiki.apache.org/confluence/display/GMOxDOC20/J2G+Migration+Tool).

--

What are your thoughts?


Thanks,
-Erik B. Craig

[jira] Updated: (GERONIMO-3208) In-place deployment fails when renaming file

[Aman Nanner (JIRA)]

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

Aman Nanner updated GERONIMO-3208:
--

Attachment: nestedjarfile.patch

Here is a patch that I use to get around this problem.  I'm not sure that this 
is the best solution to the problem.

> In-place deployment fails when renaming file
> 
>
> Key: GERONIMO-3208
> URL: https://issues.apache.org/jira/browse/GERONIMO-3208
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6
> Environment: Windows XP SP2
>Reporter: Aman Nanner
>Priority: Blocker
> Attachments: inplace-deployment-fails.ear.zip, nestedjarfile.patch
>
>
> I am using the latest SNAPSHOT of Geronimo.
> I was trying to deploy my custom application with Geronimo using "in-place" 
> deployment, but it would fail with a ZipException and an "Access denied" 
> message at the following line:
> {code}
> System Thread [RMI TCP Connection(189)-192.168.12.66] (Suspended (breakpoint 
> at line 127 in InPlaceResourceContext))  
>   InPlaceResourceContext.flush() line: 127
>   EARContext(DeploymentContext).flush() line: 428 
>   TomcatModuleBuilder(AbstractWebModuleBuilder).installModule(JarFile, 
> EARContext, Module, Collection, ConfigurationStore, Collection) line: 312  
>   AbstractWebModuleBuilder$$FastClassByCGLIB$$8523248f.invoke(int, 
> Object, Object[]) line: not available  
> {code}
> So I tried creating a small EAR file for testing purposes, and deployment of 
> it also failed but at a different point:
> {code}
>  [java] Error: Unable to distribute testing.ear: Problem closing war 
> context
>  [java] Cannot rename file
>  [java] 
> D:\Development\mx0706\build\geronimo\maintenix\testing.ear\testing.war
>  [java] to
>  [java] 
> D:\Development\mx0706\build\geronimo\maintenix\testing.ear\testing.war.saved
> {code}
> This failed at line 121 in the {{InPlaceResourceContext}} class.  I've 
> attached the sample EAR file that was causing me this problem.

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

[jira] Updated: (SM-1029) Bug in HTTP BC when configuring managed keystore for SSL

[Martin Krasser (JIRA)]

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

Martin Krasser updated SM-1029:
---

Attachment: ServiceMixSslSocketConnector.patch

I had the same problem with the consumer endpoint. Attached is a patch file 
that fixes this issue.

>  Bug in HTTP BC when configuring managed keystore for SSL 
> --
>
> Key: SM-1029
> URL: https://issues.apache.org/activemq/browse/SM-1029
> Project: ServiceMix
>  Issue Type: Bug
>  Components: servicemix-http
>Affects Versions: 3.1.1
> Environment: ServiceMix deployed on Windows XP
>Reporter: Will Franco
>Priority: Minor
> Attachments: ServiceMixSslSocketConnector.patch
>
>
> The problem is that ServiceMixSslSocketConnector extends SslSocketConnector, 
> and it is providing its own data member and getter/setter for the trust 
> store, named "trustStore".  However, SslSocketConnector already declares a 
> data member and getter/setter for the trust store, named "_truststore".   
> The bug is manifested in JettyContextManager.createServer(URL url, 
> SslParameters ssl) method, when the "managed=true" is included in your 
> SslParameters.   The initialization of the ServiceMixSslSocketConnector calls 
> "setTruststore" method which sets the "_truststore", eventually, there is a 
> call to  ServiceMixSslSocketConnector.createFactory() method, and in its 
> implementation, it passes in the value of the "trustStore" that has never 
> been set, instead of the value of "_truststore". 
> This bug is affecting the option of having a managed trust store for SSL. 

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

[jira] Updated: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated GERONIMO-2964:
--

Attachment: GERONIMO-2964.patch

Aman, can you check if GERONIMO-2964.patch addresses this issue?  Patch to be 
used on branches\2.0 or tags\2.0.1.

> Cannot specify the Tomcat work directory for a web application
> --
>
> Key: GERONIMO-2964
> URL: https://issues.apache.org/jira/browse/GERONIMO-2964
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.2, 2.0-M5
>Reporter: Aman Nanner
>Priority: Minor
> Fix For: 1.2, 2.1
>
> Attachments: GERONIMO-2964.patch, tomcat-config-workdir.patch, 
> tomcat-workdir.patch
>
>
> In Tomcat, a work directory can be specified for a web application in a 
> WEB-INF/context.xml file.  The GeronimoStandardContext does not permit the 
> user to specify a work directory, and so the work directory defaults to 
> var/catalina/work/.
> I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to 
> permit the user to optionally specify a work directory.  This work directory 
> is then propagated into the TomcatContext.  I've tested this and it seems to 
> work well.

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

Re: Adding j2g to site

[Jason Warner]

I like it.  I just glanced through it real quick but I think it might be
prudent to mention what versions of geronimo the tool is for on the
downloads page.  I'm sure it's on the migration tool page already, but I
don't think it would hurt to reiterate that early on.

Thanks,

-Jason Warner

On 8/27/07, Erik B. Craig <[EMAIL PROTECTED]> wrote:
>
> I do believe that the devtools subproject is indeed the best place for it
> given it's purpose and functionality, that said, here are some proposed
> changes to the devtools subproject page.
>
> Add a section identical to the existing 'Eclipse Plug-in' that contains
> the following:
> --
> J2G Migration Tool
>
> JBoss to Geronimo (J2G(link to
> http://cwiki.apache.org/confluence/display/GMOxDOC20/J2G+Migration+Tool))
> is a tool set built as Eclipse SDK plug-ins designed to assist in migrating
> the sources of an application written for the JBoss application server or
> written for Java 2 Enterprise Edition (J2EE) to the Apache Geronimo
> platform.
> Prerequisites
>
>-
>
>Sun JDK 5.0+ (J2SE 1.5)
>-
>
>Eclipse SDK 3.3 with JDT Core Plug-in
>-
>
>Apache Geronimo 1.1.1 and up
>-
>
>Application written for JBoss 3.2 and up or J2EE 1.2 and up.
>
> --
> In addition to this, revamp the 'Downloads' section of the page to contain
> the following:
> ---
> Downloads
>
> *Eclipse Plug-in Latest Release - Version 1.2.0*
> Version 1.2.0 of the Eclipse Plug-in has been released. The plugin can be
> installed directly from within WTP version 
> 1.5.2
> ,
> by clicking on the "Don't see your server 
> listed?
> "
> link when defining a runtime in WTP.
>
> Alternatively, the plugin can be also be installed via the update manager
> by creating a new remote site pointing to
> http://geronimo.apache.org/devtools 
> 
> .
>
> The latest release supports deployment to Geronimo 1.1.x and all previous
> versions. See the release 
> notes
> for
>  additional information.
>
> *J2G Migration Tool 1.0*
>
> The first release of the J2G migration tool can be downloaded from the
> wiki page for the tool here(link to
> http://cwiki.apache.org/confluence/display/GMOxDOC20/J2G+Migration+Tool).
>
> --
>
> What are your thoughts?
>
>
> Thanks,
> -Erik B. Craig
>

Re: removal of spring dependencies from cxf module

[Kevan Miller]

On Aug 27, 2007, at 10:11 AM, Jeff Genender wrote:




Kevan Miller wrote:


On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote:



From my standpoint, it would be greatly preferred if you could  
find a way
to leave spring for CXF.   There is definitely a lot of  
functionality
that would be lost if spring is not available.  In particular, if  
a user

want to configure various things like message logging or
WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking,  
etc...,

without the spring config, it becomes quite a bit harder.   For very
basic usage, spring is optional.   But once you want some
customizations, you really need it.


OK. First I've heard of loss of functionality... Is there loss of
functionality? Or things become harder without Spring? If things  
become
harder, an important question is who pays the price? The embedder  
(i.e.

us)? Or the user?


I have to agree with Dan on this.  This is clearly our problem.  It's
Geronimo's classloaders that are causing the issue.  We are taking  
away

functionality at the expense of our inability to handle Spring.


K. Can you explain to me what functionality is being taken away? Dan  
said function would be lost, but then listed functionality and said  
that configuring them "becomes quite a bit harder". Nor do I know how  
this increased complexity would be who bears the burden for things  
becoming quite a bit harder.


I want the client application to be in control of the Spring version.  
I don't want the Geronimo server environment to dictate the version  
of Spring used by the client application. At present, we are  
dictating the version of Spring. I think this needs to change. I  
don't think this is a result of our ClassLoader structure.






I have no real issue with our CXF server module requiring Spring.

I'm less happy if we're requiring that Spring be accessible from a
client application module to configure CXF web services client
capabilities.

I'm way less happy if we require the same Spring instance be  
accessible

from the CXF server module and the client application module. This is
the case, at the moment. I think this needs to be changed.



Why should it be changed?  This seems to work with someone using
Tomcat...just not Geronimo.


Does Tomcat embed CXF? Does CXF distribute Tomcat binaries configured  
to provide CXF-based web services? Or does CXF distribute CXF and  
associated dependent jars which can be packaged into a WAR and  
subsequently deployed into a web container?


I believe it's the latter. In which case, you're not giving me an  
apples-to-apples comparison, IMO.


--kevan

[jira] Updated: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated GERONIMO-2964:
--

Attachment: g2964.war

Verified that GERONIMO-2964.patch solves the problem.  Deploy g2964.war which 
uses a workDir "g2964" under var/catalina.  Access http://localhost:8080/g2964 
once the app is deployed.

Caution: GERONIMO-2964.patch can not be committed as we will need to change the 
versions of the two schema files and this requires (a lot of) other changes.

> Cannot specify the Tomcat work directory for a web application
> --
>
> Key: GERONIMO-2964
> URL: https://issues.apache.org/jira/browse/GERONIMO-2964
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.2, 2.0-M5
>Reporter: Aman Nanner
>Priority: Minor
> Fix For: 1.2, 2.1
>
> Attachments: g2964.war, GERONIMO-2964.patch, 
> tomcat-config-workdir.patch, tomcat-workdir.patch
>
>
> In Tomcat, a work directory can be specified for a web application in a 
> WEB-INF/context.xml file.  The GeronimoStandardContext does not permit the 
> user to specify a work directory, and so the work directory defaults to 
> var/catalina/work/.
> I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to 
> permit the user to optionally specify a work directory.  This work directory 
> is then propagated into the TomcatContext.  I've tested this and it seems to 
> work well.

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

[jira] Commented: (SM-1029) Bug in HTTP BC when configuring managed keystore for SSL

[Will Franco (JIRA)]

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

Will Franco commented on SM-1029:
-

thanks 



>  Bug in HTTP BC when configuring managed keystore for SSL 
> --
>
> Key: SM-1029
> URL: https://issues.apache.org/activemq/browse/SM-1029
> Project: ServiceMix
>  Issue Type: Bug
>  Components: servicemix-http
>Affects Versions: 3.1.1
> Environment: ServiceMix deployed on Windows XP
>Reporter: Will Franco
>Priority: Minor
> Attachments: ServiceMixSslSocketConnector.patch
>
>
> The problem is that ServiceMixSslSocketConnector extends SslSocketConnector, 
> and it is providing its own data member and getter/setter for the trust 
> store, named "trustStore".  However, SslSocketConnector already declares a 
> data member and getter/setter for the trust store, named "_truststore".   
> The bug is manifested in JettyContextManager.createServer(URL url, 
> SslParameters ssl) method, when the "managed=true" is included in your 
> SslParameters.   The initialization of the ServiceMixSslSocketConnector calls 
> "setTruststore" method which sets the "_truststore", eventually, there is a 
> call to  ServiceMixSslSocketConnector.createFactory() method, and in its 
> implementation, it passes in the value of the "trustStore" that has never 
> been set, instead of the value of "_truststore". 
> This bug is affecting the option of having a managed trust store for SSL. 

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

Re: removal of spring dependencies from cxf module

[Jeff Genender]

Kevan Miller wrote:
> K. Can you explain to me what functionality is being taken away? Dan
> said function would be lost, but then listed functionality and said that
> configuring them "becomes quite a bit harder". Nor do I know how this
> increased complexity would be who bears the burden for things becoming
> quite a bit harder.
>

Read Dan's comment/answer.  The functionality is the ease of
configuration, etc.  For someone who has used Spring extensively, I
think its a huge loss not to be able to leverage it.

> I want the client application to be in control of the Spring version. I
> don't want the Geronimo server environment to dictate the version of
> Spring used by the client application. At present, we are dictating the
> version of Spring. I think this needs to change. I don't think this is a
> result of our ClassLoader structure.
>

What are you talking about...this is clearly a classloader problem.  The
fact the client and the server are fighting over whose version of Spring
is the "right one" points its finger at a classloader issue.  The fact
the client has to set the hidden classes attribute on plans clearly
shows this is a classloader problem.  Am I missing or not seeing
something here?  If so, please point it out...perhaps I'm simply not
getting it.  Clashing versions is about as classloader related as it gets.


>>
>>>
>>> I have no real issue with our CXF server module requiring Spring.
>>>
>>> I'm less happy if we're requiring that Spring be accessible from a
>>> client application module to configure CXF web services client
>>> capabilities.
>>>
>>> I'm way less happy if we require the same Spring instance be accessible
>>> from the CXF server module and the client application module. This is
>>> the case, at the moment. I think this needs to be changed.
>>>
>>
>> Why should it be changed?  This seems to work with someone using
>> Tomcat...just not Geronimo.
> 
> Does Tomcat embed CXF? Does CXF distribute Tomcat binaries configured to
> provide CXF-based web services? Or does CXF distribute CXF and
> associated dependent jars which can be packaged into a WAR and
> subsequently deployed into a web container?

CXF can certainly be used in Tomcat.  Tomcat doesn't distribute it, but
it certainly can be used with that web container.  It appears the only
project who has this problem is Geronimo :-/


> 
> I believe it's the latter. In which case, you're not giving me an
> apples-to-apples comparison, IMO.
> 

Well...lets agree to disagree.  The bottom line is we are castrating
other projects because we have messed up classloaders.  That, IMNSHO,
has nothing to do with apples-to-apples comparison and we are creating a
treatment to the problem rather than a panacea.

Do as you may, but call my issue with how we are handling this a
dissenting voice.  I am not in agreement with this action.

> --kevan
> 

[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application

[Aman Nanner (JIRA)]

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

Aman Nanner commented on GERONIMO-2964:
---

I have verified that the GERONIMO-2964.patch does indeed fix our issue.

> Cannot specify the Tomcat work directory for a web application
> --
>
> Key: GERONIMO-2964
> URL: https://issues.apache.org/jira/browse/GERONIMO-2964
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.2, 2.0-M5
>Reporter: Aman Nanner
>Priority: Minor
> Fix For: 1.2, 2.1
>
> Attachments: g2964.war, GERONIMO-2964.patch, 
> tomcat-config-workdir.patch, tomcat-workdir.patch
>
>
> In Tomcat, a work directory can be specified for a web application in a 
> WEB-INF/context.xml file.  The GeronimoStandardContext does not permit the 
> user to specify a work directory, and so the work directory defaults to 
> var/catalina/work/.
> I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to 
> permit the user to optionally specify a work directory.  This work directory 
> is then propagated into the TomcatContext.  I've tested this and it seems to 
> work well.

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

[jira] Updated: (GERONIMO-3254) Admin Console Wizard to auto generate geronimo-web.xml

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated GERONIMO-3254:
--

Fix Version/s: (was: 2.0.x)
   2.1

Changed fix version to 2.1

> Admin Console Wizard to auto generate geronimo-web.xml
> --
>
> Key: GERONIMO-3254
> URL: https://issues.apache.org/jira/browse/GERONIMO-3254
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: console, deployment, usability
>Affects Versions: 2.0-M7
>Reporter: Shiva Kumar H R
> Fix For: 2.1
>
> Attachments: 1WelcomePage.gif, 2BasicSettings.gif, 
> 3ResolveReferences.gif, 4AddDependencies.gif, 5DisplaysCreatedPlan.gif, 
> 6DeployStatus.gif, 7SecurityHandling_1.gif, 7SecurityHandling_2.gif, 
> 7SecurityHandling_3.gif, buildCreatePlanPortlet.bat, 
> buildCreatePlanPortlet2.bat, consolidated 3254 3394 3395 3396 3397 
> 3398.patch, GERONIMO-3254.patch, PoC.patch, PoC_2(annotations).patch, 
> SampleWebAppsWithAnnotations.zip, TestCreatePlanPortlet.zip, 
> TestSecuritySettings.zip
>
>
> For a background about this work, please see the discussion thread: 
> http://www.mail-archive.com/dev@geronimo.apache.org/msg46831.html

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

[jira] Assigned: (GERONIMO-3254) Admin Console Wizard to auto generate geronimo-web.xml

[Shiva Kumar H R (JIRA)]

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

Shiva Kumar H R reassigned GERONIMO-3254:
-

Assignee: Shiva Kumar H R

> Admin Console Wizard to auto generate geronimo-web.xml
> --
>
> Key: GERONIMO-3254
> URL: https://issues.apache.org/jira/browse/GERONIMO-3254
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: console, deployment, usability
>Affects Versions: 2.0-M7
>Reporter: Shiva Kumar H R
>Assignee: Shiva Kumar H R
> Fix For: 2.1
>
> Attachments: 1WelcomePage.gif, 2BasicSettings.gif, 
> 3ResolveReferences.gif, 4AddDependencies.gif, 5DisplaysCreatedPlan.gif, 
> 6DeployStatus.gif, 7SecurityHandling_1.gif, 7SecurityHandling_2.gif, 
> 7SecurityHandling_3.gif, buildCreatePlanPortlet.bat, 
> buildCreatePlanPortlet2.bat, consolidated 3254 3394 3395 3396 3397 
> 3398.patch, GERONIMO-3254.patch, PoC.patch, PoC_2(annotations).patch, 
> SampleWebAppsWithAnnotations.zip, TestCreatePlanPortlet.zip, 
> TestSecuritySettings.zip
>
>
> For a background about this work, please see the discussion thread: 
> http://www.mail-archive.com/dev@geronimo.apache.org/msg46831.html

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

Re: removal of spring dependencies from cxf module

[Kevan Miller]

I've CC:ed you. However, I'd prefer that you respond to the dev list,  
only (or cc: me, not reply directly). My mail rules for email  
addressed directly to me puts mail in my personal folder. I monitor  
Geronimo mail more frequently than personal mail... ;-) Perhaps I  
need to tweak my rules a bit...


On Aug 27, 2007, at 10:35 AM, Daniel Kulp wrote:



Kevan,

On Monday 27 August 2007, Kevan Miller wrote:

On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote:

From my standpoint, it would be greatly preferred if you could find
a way
to leave spring for CXF.   There is definitely a lot of
functionality that would be lost if spring is not available.  In
particular, if a user
want to configure various things like message logging or
WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking,
etc..., without the spring config, it becomes quite a bit harder.
For very basic usage, spring is optional.   But once you want some
customizations, you really need it.


OK. First I've heard of loss of functionality... Is there loss of
functionality? Or things become harder without Spring?


For the most part, it's "things become much harder," mostly because we
really only document the Spring way of doing things.  Doing
things "non-spring" requires a bunch of casting of JAX-WS things into
proprietary things, calling semi-hidden API's, etc...   The spring way
is very clean, documented, etc...   See:
http://cwiki.apache.org/CXF20DOC/configuration.html
particularly the sub-pages listed at the bottom.


Thanks much for the info...



One area that definitely doesn't work without spring is the ws-policy
stuff.   Turning on policy requires some spring stuff right now.   I
think that's logged as a bug.


Hmm. That's interesting. IIRC, it was a WS-POLICY test that prevented  
us from fixing this problem prior to G 2.0.







I have no real issue with our CXF server module requiring Spring.

I'm less happy if we're requiring that Spring be accessible from a
client application module to configure CXF web services client
capabilities.


Can it be optional?   Set some filtering thing so if they want/need  
the

spring stuff, they can get it?


Certainly. One potentially simple option: if the user needs to set a  
cxf-specific configuration options in client applications, they'd  
need to include Spring jars in their application or declare Spring  
dependencies in their deployment plan. This may be an additional  
burden on the user, but may not be a big issue given they've started  
down a customization route... There's still one issue with this,  
approach, however. Will have to dust off the failing tests get to the  
bottom of the issue, I guess...




That all said, I DON'T know if Geronimo current exposes a spring  
context

or anything that would currently allow any of that to work.   My gut
feeling says no, but I'm not really sure. It's quite possible that
it doesn't work in Geronimo right now anyway.   It's probably that the
spring stuff in Geronimo is on a more "global" basis and wouldn't  
allow

per-application configuration anyway.   Probably Jarek would need to
weigh in how that currently works as I don't really know.


Agreed. Quite likely that we'll need Jarek's knowledge of the  
internals of our CXF integration to resolve this issue.




Ideally to me, if the app has a META-INF/cxf.xml or similar (some  
other

key or something), the spring stuff would allow configuring of a bunch
of the things specific for that application.


We can certainly consider some automatic trigger.

--kevan

Re: ServiceMix 4.0

[Bruce Snyder]

On 8/27/07, James Strachan <[EMAIL PROTECTED]> wrote:

> > > 1. Use slf4j as the logging framework. (http://www.slf4j.org/) -> btw,
> > > I'm not sure if its a better option, but I did hear some good stuff
> > > about it.
> >
> > Yes, SMX should switch to using the slf4j-api which will allow any
> > logging framework to be plugged in at deployment time.
>
> how's that different from commons-logging (other than adding yet
> another dependency, since many things SMX depends on also depends on
> commons logging)

There are a lot of reasons, including an extremely good writeup about
JCL that Ceki did back in 2004 that is available here:

http://www.qos.ch/logging/thinkAgain.jsp

But the most important point of all is that the use of JCL is most
oftentimes incorrect from an architecture standpoint. At least this is
what the creator of JCL says:

'...The purpose of Commons Logging is not to somehow take the logging
world by storm. In fact, there are very limited circumstances in which
Commons Logging is useful. If you're building a stand-alone
application, don't use commons-logging. If you're building an
application server, don't use commons-logging. If you're building a
moderately large framework, don't use commons-logging. If however,
like the Jakarta Commons project, you're building a tiny little
component that you intend for other developers to embed in their
applications and frameworks, and you believe that logging information
might be useful to those clients, and you can't be sure what logging
framework they're going to want to use, then commons-logging might be
useful to you...'

See Rod's full blog entry here: http://radio.weblogs.com/0122027/2003/08/15.html

Bruce
-- 
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/

Re: New GShell-based Geronimo Server launcher now in server/trunk

[Jason Dillon]

On Aug 23, 2007, at 8:40 AM, Joe Bohn wrote:

Jason,

I finally got around to looking at this.  It's really cool!


:-)


This is a great way to address the environment and java opt issues  
in a more dynamic way to plugins to potentially exploit.


In addition to some of the items David mentioned it would also be  
great to have some more query capabilities both in gsh and the  
start-server script.  For example; the ability to list all  
environment variables, list system or geronimo properties set, list  
javaopts, list of all scripts to be run prior to the starting  
server, etc...


Sure, thats all uber simple to add.


One curious thing I noticed was that it seemed to drag a bit when I  
terminated geronimo from the console.  It might have nothing to do  
with gsh but it seemed to take a long time before the gsh showed  
the server finally terminated ... just fyi and fwiw ... may be  
nothing to do with gsh.


No, its not anything to do with gsh directly, its just that you  
aren't seeing the messages on the console when the server shuts  
down.  I'm not really sure how to capture that stuff actually, same  
problem happens with the geronimo:start-sever goal.


I did however add a message to the console when a shutdown is  
detected to let the user know what was going on.


--jason

Re: New GShell-based Geronimo Server launcher now in server/trunk

[Jason Dillon]

So, is this something that I should pursue?  I've seen a few positive  
comments on this functionality, nothing negative...


Should I invest more time in making this feature complete and set it  
up as the default system for launching the server?


--jason


On Aug 21, 2007, at 3:05 PM, Jeff Genender wrote:


Oh man this is sweet...

I'd *really* like to see this in 2.0.2...

Jeff

Jason Dillon wrote:
Hiya folks, I finally got around to finishing up my POC of using  
GShell
to launch the Geronimo Server and I have committed the bits that  
make it
work to server/trunk.  The new module which contains the GShell  
command

implementation (and support) classes is:

modules/geronimo-commands

And a new assembly which has the GShell bits all in place for  
folks to

test with is:

assemblies/geronimo-jetty6-javaee5-gshell

The assembly is not hooked up by default, but the code module is.   
So,

to test it out, you need to do something like:

svn co https://svn.apache.org/repos/asf/geronimo/server/trunk  
server

cd server
mvn
assemblies/geronimo-jetty6-javaee5-gshell
mvn

Then unzip the assembly:

unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip

And then finally try it out.  First lets get the basic GShell
command-line help:

./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help

This should spit out something like:


      _  _ _
  / ___/ ___|| |__   ___| | |
 | |  _\___ \| '_ \ / _ \ | |
 | |_| |___) | | | |  __/ | |
  \|/|_| |_|\___|_|_|

 GShell -- Geronimo command-line shell

usage: gsh [options]  [args]
-n,--non-interactiveRun in non-interactive mode
-D,--define Define a system property
-V,--versionDisplay GShell version
-c,--commands   Read commands from string
-debug,--debug  Enable DEBUG logging output
-h,--help   Display this help message
-i,--interactiveRun in interactive mode
-quiet,--quiet  Limit logging output to ERROR
-verbose,--verbose  Enable INFO logging output


Then lets run the interactive-shell:

./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh

This should leave you at a very plain prompt at the moment:



_



At this point you can type something like this to list all of the  
known

commands:


help commands


Which should spit back:


Available commands (and aliases):
  start-server ( start )
  set
  exit ( quit, bye )
  unset
  source
  help


The command that I added is called 'start-server', with an alias of
'start'.  This is basically an augmented and enhanced version of what
the geronimo:start-server goal does in the geronimo-maven-plugin.  To
see its options run this:


start-server --help


And it says:


start-server -- Starts a new Geronimo server instance

usage: start-server [options]
-A,--javaagent   Use a specific Java Agent, set to
'none' to
  disable
-D,--property Set a system property
-H,--homeUse a specific Geronimo home  
directory

-J,--javaopt  Set a JVM flag
-b,--background   Run the server process in the  
background.

-h,--help Display this help message
-j,--jvm Use a specific Java Virtual Machine
for server
  process
-l,--logfileCapture console output to file
-m,--module Start up a specific module by name.
-q,--quietSuppress informative and warning  
messages

-t,--timeout Specify the timeout for the server
process in
  seconds
-v,--verbose  Enable verbose output; specify
multipule times
  to increase verbosity.


NOTE: Use -vv for --veryverbose ;-)

And then give it a whirl and try to start the server up from the  
shell:



start-server


or if you prefer more output:


start-server -v


And so on...

This will actually create a newly forked JVM to run the server in,  
and

will eventually have a robust node manager thingy, but I've not done
that yet ;-)

The platform scripts are now super simple!!!  All of the logic is  
now in

the command implementation.  And eventually we can probably have the
geronimo-maven-plugin just invoke the command so that *everything*  
uses

the exact same method for launching the server process.

 * * *

As requested by Jeff, I added support to read in some scripts to  
augment

the launching of the server... so that plugins can add properties and
such easily.  Right now this is the directory which is inspected for
scripts:

etc/rc.d

And currently the scripts need to be named like this:

   ,.groovy

I've created a default one for you to look at:

etc/rc.d/start-server,default.groovy

Which simply sets the max heap size to 512m:


command.javaFlags << '-Xmx512m'


When running the

Re: removal of spring dependencies from cxf module

[David Jencks]

On Aug 27, 2007, at 9:06 AM, Jeff Genender wrote:




Kevan Miller wrote:

K. Can you explain to me what functionality is being taken away? Dan
said function would be lost, but then listed functionality and  
said that

configuring them "becomes quite a bit harder". Nor do I know how this
increased complexity would be who bears the burden for things  
becoming

quite a bit harder.



Read Dan's comment/answer.  The functionality is the ease of
configuration, etc.  For someone who has used Spring extensively, I
think its a huge loss not to be able to leverage it.

I want the client application to be in control of the Spring  
version. I

don't want the Geronimo server environment to dictate the version of
Spring used by the client application. At present, we are  
dictating the
version of Spring. I think this needs to change. I don't think  
this is a

result of our ClassLoader structure.



What are you talking about...this is clearly a classloader  
problem.  The
fact the client and the server are fighting over whose version of  
Spring

is the "right one" points its finger at a classloader issue.  The fact
the client has to set the hidden classes attribute on plans clearly
shows this is a classloader problem.  Am I missing or not seeing
something here?  If so, please point it out...perhaps I'm simply not
getting it.  Clashing versions is about as classloader related as  
it gets.







I have no real issue with our CXF server module requiring Spring.

I'm less happy if we're requiring that Spring be accessible from a
client application module to configure CXF web services client
capabilities.

I'm way less happy if we require the same Spring instance be  
accessible
from the CXF server module and the client application module.  
This is

the case, at the moment. I think this needs to be changed.



Why should it be changed?  This seems to work with someone using
Tomcat...just not Geronimo.


Does Tomcat embed CXF? Does CXF distribute Tomcat binaries  
configured to

provide CXF-based web services? Or does CXF distribute CXF and
associated dependent jars which can be packaged into a WAR and
subsequently deployed into a web container?


CXF can certainly be used in Tomcat.  Tomcat doesn't distribute it,  
but

it certainly can be used with that web container.  It appears the only
project who has this problem is Geronimo :-/


Cool down a minute and think about this.  What happens in tomcat if  
you want to use cxf + an incompatible version of spring in your app?   
You bundle cxf + springA + springB into your web-app and then what  
happens?


IMO we are talking about trying to get geronimo to generically solve  
a problem that tomcat forces its users to deal with on an per-app basis.


It's by no means obvious to me that treating this as a problem with  
the coding of our classloaders is appropriate.  Here  are some  
possibilities I can think of off the top of my head:


1. cxf generates some code  for each web service client/service that  
directly use spring classes.  In this case there is AFAIK no way for  
an app to use a different spring version since these generated  
classes are going to be loaded in the application classloader and  
they need access to cxf's copy of spring classes.  If this is what is  
going on I hope it's possible for cxf to stop doing this.


2. If putting spring in the apps hidden-classes works and allows the  
app to use a different spring version, then evidently (1) isn't a  
problem.  In this case if we automatically add spring to hidden- 
classes of every app we would be preventing all apps from using our  
copy of spring which seems undesirable to me.  hidden-classes  
currently means "don't import these classes from parents".  We could  
look into also having a "don't export these classes to children"  
filter in our classloader.


3. With just the "don't export" filter proposed in (2), people adding  
the spring jars to their dependency list would be getting spring  
loaded in a different classloader for their app and for cxf.  This  
might not be desirable.  We could make a spring configuration to  
provide a single classloader to load spring in that cxf and apps  
could depend on.


thanks
david jencks






I believe it's the latter. In which case, you're not giving me an
apples-to-apples comparison, IMO.



Well...lets agree to disagree.  The bottom line is we are castrating
other projects because we have messed up classloaders.  That, IMNSHO,
has nothing to do with apples-to-apples comparison and we are  
creating a

treatment to the problem rather than a panacea.

Do as you may, but call my issue with how we are handling this a
dissenting voice.  I am not in agreement with this action.


--kevan

Re: New GShell-based Geronimo Server launcher now in server/trunk

[Jeff Genender]

Jason Dillon wrote:
> So, is this something that I should pursue?  I've seen a few positive
> comments on this functionality, nothing negative...
> 
> Should I invest more time in making this feature complete and set it up
> as the default system for launching the server?

Yes!


> 
> --jason
> 
> 
> On Aug 21, 2007, at 3:05 PM, Jeff Genender wrote:
> 
>> Oh man this is sweet...
>>
>> I'd *really* like to see this in 2.0.2...
>>
>> Jeff
>>
>> Jason Dillon wrote:
>>> Hiya folks, I finally got around to finishing up my POC of using GShell
>>> to launch the Geronimo Server and I have committed the bits that make it
>>> work to server/trunk.  The new module which contains the GShell command
>>> implementation (and support) classes is:
>>>
>>> modules/geronimo-commands
>>>
>>> And a new assembly which has the GShell bits all in place for folks to
>>> test with is:
>>>
>>> assemblies/geronimo-jetty6-javaee5-gshell
>>>
>>> The assembly is not hooked up by default, but the code module is.  So,
>>> to test it out, you need to do something like:
>>>
>>> svn co https://svn.apache.org/repos/asf/geronimo/server/trunk server
>>> cd server
>>> mvn
>>> assemblies/geronimo-jetty6-javaee5-gshell
>>> mvn
>>>
>>> Then unzip the assembly:
>>>
>>> unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
>>>
>>> And then finally try it out.  First lets get the basic GShell
>>> command-line help:
>>>
>>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
>>>
>>> This should spit out something like:
>>>
>>> 
>>>   _  _ _
>>>   / ___/ ___|| |__   ___| | |
>>>  | |  _\___ \| '_ \ / _ \ | |
>>>  | |_| |___) | | | |  __/ | |
>>>   \|/|_| |_|\___|_|_|
>>>
>>>  GShell -- Geronimo command-line shell
>>>
>>> usage: gsh [options]  [args]
>>> -n,--non-interactiveRun in non-interactive mode
>>> -D,--define Define a system property
>>> -V,--versionDisplay GShell version
>>> -c,--commands   Read commands from string
>>> -debug,--debug  Enable DEBUG logging output
>>> -h,--help   Display this help message
>>> -i,--interactiveRun in interactive mode
>>> -quiet,--quiet  Limit logging output to ERROR
>>> -verbose,--verbose  Enable INFO logging output
>>> 
>>>
>>> Then lets run the interactive-shell:
>>>
>>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
>>>
>>> This should leave you at a very plain prompt at the moment:
>>>
>>> 
 _
>>> 
>>>
>>> At this point you can type something like this to list all of the known
>>> commands:
>>>
>>> 
>>> help commands
>>> 
>>>
>>> Which should spit back:
>>>
>>> 
>>> Available commands (and aliases):
>>>   start-server ( start )
>>>   set
>>>   exit ( quit, bye )
>>>   unset
>>>   source
>>>   help
>>> 
>>>
>>> The command that I added is called 'start-server', with an alias of
>>> 'start'.  This is basically an augmented and enhanced version of what
>>> the geronimo:start-server goal does in the geronimo-maven-plugin.  To
>>> see its options run this:
>>>
>>> 
>>> start-server --help
>>> 
>>>
>>> And it says:
>>>
>>> 
>>> start-server -- Starts a new Geronimo server instance
>>>
>>> usage: start-server [options]
>>> -A,--javaagent   Use a specific Java Agent, set to
>>> 'none' to
>>>   disable
>>> -D,--property Set a system property
>>> -H,--homeUse a specific Geronimo home directory
>>> -J,--javaopt  Set a JVM flag
>>> -b,--background   Run the server process in the
>>> background.
>>> -h,--help Display this help message
>>> -j,--jvm Use a specific Java Virtual Machine
>>> for server
>>>   process
>>> -l,--logfileCapture console output to file
>>> -m,--module Start up a specific module by name.
>>> -q,--quietSuppress informative and warning
>>> messages
>>> -t,--timeout Specify the timeout for the server
>>> process in
>>>   seconds
>>> -v,--verbose  Enable verbose output; specify
>>> multipule times
>>>   to increase verbosity.
>>> 
>>>
>>> NOTE: Use -vv for --veryverbose ;-)
>>>
>>> And then give it a whirl and try to start the server up from the shell:
>>>
>>> 
>>> start-server
>>> 
>>>
>>> or if you prefer more output:
>>>
>>> 
>>> start-server -v
>>> 
>>>
>>> And so on...
>>>
>>> This will actually create a newly forked JVM to run the server in, and
>>> will eventually have a robust node manager thingy, but I've not done
>>> that yet ;-)
>>>
>>> The platform scripts are now super simple!!!  All of the logic is now in
>>> the command implementation.  And eventually we can probably have the
>>> geronimo-maven-plugin just invoke the command so that *everything* 

Re: removal of spring dependencies from cxf module

[Jeff Genender]

David,

So perhaps I am missing something and you could help clarify this.  You
say "It's by no means obvious to me that treating this as a problem with
the coding of our classloaders is appropriate."  Yet in your 1, 2, and 3
options, you seem to be saying its basically a problem with
classloading.  Is it our classloaders, or is it Spring's (or other)?

Jeff

David Jencks wrote:

> Cool down a minute and think about this.  What happens in tomcat if you
> want to use cxf + an incompatible version of spring in your app?  You
> bundle cxf + springA + springB into your web-app and then what happens?
> 
> IMO we are talking about trying to get geronimo to generically solve a
> problem that tomcat forces its users to deal with on an per-app basis.
> 
> It's by no means obvious to me that treating this as a problem with the
> coding of our classloaders is appropriate.  Here  are some possibilities
> I can think of off the top of my head:
> 
> 1. cxf generates some code  for each web service client/service that
> directly use spring classes.  In this case there is AFAIK no way for an
> app to use a different spring version since these generated classes are
> going to be loaded in the application classloader and they need access
> to cxf's copy of spring classes.  If this is what is going on I hope
> it's possible for cxf to stop doing this.
> 
> 2. If putting spring in the apps hidden-classes works and allows the app
> to use a different spring version, then evidently (1) isn't a problem. 
> In this case if we automatically add spring to hidden-classes of every
> app we would be preventing all apps from using our copy of spring which
> seems undesirable to me.  hidden-classes currently means "don't import
> these classes from parents".  We could look into also having a "don't
> export these classes to children" filter in our classloader.
> 
> 3. With just the "don't export" filter proposed in (2), people adding
> the spring jars to their dependency list would be getting spring loaded
> in a different classloader for their app and for cxf.  This might not be
> desirable.  We could make a spring configuration to provide a single
> classloader to load spring in that cxf and apps could depend on.
> 
> thanks
> david jencks
> 
>>
>>
>>>
>>> I believe it's the latter. In which case, you're not giving me an
>>> apples-to-apples comparison, IMO.
>>>
>>
>> Well...lets agree to disagree.  The bottom line is we are castrating
>> other projects because we have messed up classloaders.  That, IMNSHO,
>> has nothing to do with apples-to-apples comparison and we are creating a
>> treatment to the problem rather than a panacea.
>>
>> Do as you may, but call my issue with how we are handling this a
>> dissenting voice.  I am not in agreement with this action.
>>
>>> --kevan
>>>

[jira] Closed: (GERONIMODEVTOOLS-141) Installation/Activation of other Plugins fail after installing Devtools plugin

[Jacek Laskowski (JIRA)]

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

Jacek Laskowski closed GERONIMODEVTOOLS-141.


Resolution: Fixed  (was: Won't Fix)

As per user's request.

> Installation/Activation of other Plugins fail after installing Devtools plugin
> --
>
> Key: GERONIMODEVTOOLS-141
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-141
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.0
> Environment: Windows XP SP2, Java 1.6.0_01, Eclipse 3.3 M6, WST 2.0 M6
>Reporter: Stefan
>Assignee: Tim McConnell
>Priority: Blocker
> Fix For: 2.0
>
> Attachments: GD-141-2.patch, GD-141.patch
>
>
> Via Eclipse function to download additional server adapters you can choose 
> and install the plugin.
> But after restart Eclipse the plugin is disabled. If you try to enable it, 
> you get:
> Requested operation cannot be performed because it would invalidate the 
> current configuration. See details for more information. 
> org.apache.geronimo.feature (1.2.0) requires plug-in 
> "com.ibm.etools.emf.event".

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

Cries for help on the TSS thread

[David Blevins]

Or something like that

http://www.theserverside.com/news/thread.tss?thread_id=46658

-David

Re: Updating the WebSite for 2.0.1

[Jacek Laskowski]

On 8/25/07, Anita Kulshreshtha <[EMAIL PROTECTED]> wrote:

>What do others feel?

Exclude'em.

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: New threads launched from an EJB do not run as the same Subject as the launching thread

[Jacek Laskowski]

On 8/27/07, David Jencks <[EMAIL PROTECTED]> wrote:

> Aren't we supposed to prevent ejbs from starting threads?  Does the
> commonj thread pool have a facility for supplying the security
> context from the request submitting thread to the worker thread?

Absolutely we are. I'm not sure about commonj, but threads aren't
supposed to be fired off from ejbs. Wouldn't it be possible with
appropriate SecurityManager settings? Or are there better approaches?

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

Re: Cries for help on the TSS thread

[Kevan Miller]

On Aug 27, 2007, at 2:44 PM, David Blevins wrote:


Or something like that

http://www.theserverside.com/news/thread.tss?thread_id=46658


I've responded to both reports of a problem. Neither were a problem  
that I've seen before (or a search of our dev/user/jira lists). If  
somebody thinks they understand their problem, please post a reply...


--kevan

Re: ServiceMix 4.0

[Nodet Guillaume]

I would say the opposite.  The OSGi classloaders are much more
powerful and you can more easily control the visibility of classes.
In addition, if JCL is required by a given bundle A, it does not
mean that it will be visible by a bundle using bundle A.

Obviously, this means to be tested (or maybe OSGi experts could
help there...)

Cheers,
Guillaume Nodet

On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote:


Also, moving toward an architecture based on OSGi almost guarantees
that we will run into classloader issues with JCL.

Bruce

Re: removal of spring dependencies from cxf module

[Kevan Miller]

On Aug 27, 2007, at 2:16 PM, David Jencks wrote:



On Aug 27, 2007, at 9:06 AM, Jeff Genender wrote:




Kevan Miller wrote:






Cool down a minute and think about this.  What happens in tomcat if  
you want to use cxf + an incompatible version of spring in your  
app?  You bundle cxf + springA + springB into your web-app and then  
what happens?


IMO we are talking about trying to get geronimo to generically  
solve a problem that tomcat forces its users to deal with on an per- 
app basis.


It's by no means obvious to me that treating this as a problem with  
the coding of our classloaders is appropriate.  Here  are some  
possibilities I can think of off the top of my head:


1. cxf generates some code  for each web service client/service  
that directly use spring classes.  In this case there is AFAIK no  
way for an app to use a different spring version since these  
generated classes are going to be loaded in the application  
classloader and they need access to cxf's copy of spring classes.   
If this is what is going on I hope it's possible for cxf to stop  
doing this.


2. If putting spring in the apps hidden-classes works and allows  
the app to use a different spring version, then evidently (1) isn't  
a problem.  In this case if we automatically add spring to hidden- 
classes of every app we would be preventing all apps from using our  
copy of spring which seems undesirable to me.  hidden-classes  
currently means "don't import these classes from parents".  We  
could look into also having a "don't export these classes to  
children" filter in our classloader.


Mostly correct, I think. IIRC, this worked except for one measly WS- 
Policy test case in testsuite. This test failed with Spring hidden- 
classes. I then attempted to get a unique instance of Spring running  
in the application classloader and the test still failed. It would  
only work if Spring was loaded from the parent ClassLoader. Given  
what I've learned from Dan, I'm starting to think that this was  
likely a configuration problem. If we were not able to read a server- 
wide CXF configuration (because it was hidden), then the client  
application might not have had the expected configuration -- thus the  
test failure. This is pure speculation, at the moment...




3. With just the "don't export" filter proposed in (2), people  
adding the spring jars to their dependency list would be getting  
spring loaded in a different classloader for their app and for  
cxf.  This might not be desirable.  We could make a spring  
configuration to provide a single classloader to load spring in  
that cxf and apps could depend on.


Hmm. Maybe. Definitely worth investigating.

--kevan

[jira] Created: (GERONIMO-3444) EJBContext

[Aman Nanner (JIRA)]

EJBContext
--

 Key: GERONIMO-3444
 URL: https://issues.apache.org/jira/browse/GERONIMO-3444
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: OpenEJB
Affects Versions: 2.0.x
 Environment: Windows XP SP2
Reporter: Aman Nanner
 Fix For: 2.0.x, 2.1


During the initial running of our J2EE application, the following error 
inconsistently occurs:

{panel:title="Stack Trace"}
16:49:57,268 ERROR [OpenEJB] The bean instance null threw a system 
exception:javax.naming.NameAlreadyBoundException: EJBContext
javax.naming.NameAlreadyBoundException: EJBContext
at 
org.apache.xbean.naming.context.WritableContext.addBinding(WritableContext.java:91)
at 
org.apache.xbean.naming.context.WritableContext$NestedWritableContext.addBinding(WritableContext.java:235)
at 
org.apache.xbean.naming.context.AbstractContext.addBinding(AbstractContext.java:320)
at 
org.apache.xbean.naming.context.AbstractContext.addDeepBinding(AbstractContext.java:240)
at 
org.apache.xbean.naming.context.AbstractContext.bind(AbstractContext.java:652)
at 
org.apache.xbean.naming.context.AbstractContext.bind(AbstractContext.java:643)
at 
org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:111)
at 
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:156)
at 
org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:211)
at 
org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:65)
at 
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:320)
at 
org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
at $Proxy164.executeUpdate(Unknown Source)
at 
com.mxi.mx.common.ejb.job.StaleJobResetJobBean.processMessage(StaleJobResetJobBean.java:79)
at 
com.mxi.mx.common.ejb.job.MxMessageDrivenBean.onMessage(MxMessageDrivenBean.java:135)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:146)
at 
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:129)
at 
org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67)
at 
org.apache.openejb.core.mdb.MdbContainer._invoke(MdbContainer.java:332)
at 
org.apache.openejb.core.mdb.MdbContainer.invoke(MdbContainer.java:304)
at 
org.apache.openejb.core.mdb.EndpointHandler.deliverMessage(EndpointHandler.java:229)
at 
org.apache.openejb.core.mdb.EndpointHandler.invoke(EndpointHandler.java:170)
at $Proxy163.onMessage(Unknown Source)
at 
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:121)
at 
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:61)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:696)
at 
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:165)
at 
org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:290)
at 
org.apache.geronimo.connector.work.pool.NamedRunnable.run(NamedRunnable.java:32)
at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:201)
at 
org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
16:49:57,284 ERROR [MxMessageDrivenBean] Error executing stale job reset job
javax.ejb.EJBException: Cannot obtain a free instance.; nested exception is: 
javax.naming.NameAlreadyBoundException: EJBContext
at 
org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:365)
at 
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:322)
at 
org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
at $Proxy164.executeUpdate(Unknown Source)
at 
com.mxi.mx.common.ejb.job.StaleJobResetJobBean.processMessage(StaleJobResetJobBean.java:79)
at 
com.mxi.mx.common.ejb.job.MxMessageDrivenBean.onMessage(MxMessageDrivenBean.java:135)
 

Re: removal of spring dependencies from cxf module

[David Jencks]

On Aug 27, 2007, at 11:26 AM, Jeff Genender wrote:


David,

So perhaps I am missing something and you could help clarify this.   
You
say "It's by no means obvious to me that treating this as a problem  
with
the coding of our classloaders is appropriate."  Yet in your 1, 2,  
and 3

options, you seem to be saying its basically a problem with
classloading.  Is it our classloaders, or is it Spring's (or other)?


Sorry I'm not being clear.
1>> problem with cxf that no amount of changing our classloader code  
or configuration will fix.  The same problem would occur in tomcat if  
you tried to use a spring version incompatible with cxf.


2>> our classloader works as long as you provide spring in the web  
app for use by the web app.  We could optionally enhance our  
classloader so a user would not need spring added to hidden-classes  
for the web app.


3>> For ease in making sure the classes from our copy of spring are  
normally loaded in the same classloader no matter who is using them,  
we might consider have a spring configuration with just the spring  
classes in it.  This would be more useful if the optional enhancement  
suggested in (2) was made.


So I don't see any way the code in our classloaders is wrong.  We  
might be able to make some things more convenient, and one of those  
things would involve a new feature in our classloaders.


I know there's a good chance I'm still writing incomprehensibly, so  
don't be shy if this still doesn't make sense :-)


thanks
david jencks



Jeff

David Jencks wrote:

Cool down a minute and think about this.  What happens in tomcat  
if you

want to use cxf + an incompatible version of spring in your app?  You
bundle cxf + springA + springB into your web-app and then what  
happens?


IMO we are talking about trying to get geronimo to generically  
solve a
problem that tomcat forces its users to deal with on an per-app  
basis.


It's by no means obvious to me that treating this as a problem  
with the
coding of our classloaders is appropriate.  Here  are some  
possibilities

I can think of off the top of my head:

1. cxf generates some code  for each web service client/service that
directly use spring classes.  In this case there is AFAIK no way  
for an
app to use a different spring version since these generated  
classes are
going to be loaded in the application classloader and they need  
access

to cxf's copy of spring classes.  If this is what is going on I hope
it's possible for cxf to stop doing this.

2. If putting spring in the apps hidden-classes works and allows  
the app
to use a different spring version, then evidently (1) isn't a  
problem.
In this case if we automatically add spring to hidden-classes of  
every
app we would be preventing all apps from using our copy of spring  
which
seems undesirable to me.  hidden-classes currently means "don't  
import

these classes from parents".  We could look into also having a "don't
export these classes to children" filter in our classloader.

3. With just the "don't export" filter proposed in (2), people adding
the spring jars to their dependency list would be getting spring  
loaded
in a different classloader for their app and for cxf.  This might  
not be

desirable.  We could make a spring configuration to provide a single
classloader to load spring in that cxf and apps could depend on.

thanks
david jencks






I believe it's the latter. In which case, you're not giving me an
apples-to-apples comparison, IMO.



Well...lets agree to disagree.  The bottom line is we are castrating
other projects because we have messed up classloaders.  That,  
IMNSHO,
has nothing to do with apples-to-apples comparison and we are  
creating a

treatment to the problem rather than a panacea.

Do as you may, but call my issue with how we are handling this a
dissenting voice.  I am not in agreement with this action.


--kevan

Re: removal of spring dependencies from cxf module

[Jeff Genender]

No...that made much more sense to me ;-)

I think convenience is the way to go.  I am following you now.

Thanks,

Jeff

David Jencks wrote:
> 
> On Aug 27, 2007, at 11:26 AM, Jeff Genender wrote:
> 
>> David,
>>
>> So perhaps I am missing something and you could help clarify this.  You
>> say "It's by no means obvious to me that treating this as a problem with
>> the coding of our classloaders is appropriate."  Yet in your 1, 2, and 3
>> options, you seem to be saying its basically a problem with
>> classloading.  Is it our classloaders, or is it Spring's (or other)?
> 
> Sorry I'm not being clear.
> 1>> problem with cxf that no amount of changing our classloader code or
> configuration will fix.  The same problem would occur in tomcat if you
> tried to use a spring version incompatible with cxf.
> 
> 2>> our classloader works as long as you provide spring in the web app
> for use by the web app.  We could optionally enhance our classloader so
> a user would not need spring added to hidden-classes for the web app.
> 
> 3>> For ease in making sure the classes from our copy of spring are
> normally loaded in the same classloader no matter who is using them, we
> might consider have a spring configuration with just the spring classes
> in it.  This would be more useful if the optional enhancement suggested
> in (2) was made.
> 
> So I don't see any way the code in our classloaders is wrong.  We might
> be able to make some things more convenient, and one of those things
> would involve a new feature in our classloaders.
> 
> I know there's a good chance I'm still writing incomprehensibly, so
> don't be shy if this still doesn't make sense :-)
> 
> thanks
> david jencks
> 
>>
>> Jeff
>>
>> David Jencks wrote:
>>
>>> Cool down a minute and think about this.  What happens in tomcat if you
>>> want to use cxf + an incompatible version of spring in your app?  You
>>> bundle cxf + springA + springB into your web-app and then what happens?
>>>
>>> IMO we are talking about trying to get geronimo to generically solve a
>>> problem that tomcat forces its users to deal with on an per-app basis.
>>>
>>> It's by no means obvious to me that treating this as a problem with the
>>> coding of our classloaders is appropriate.  Here  are some possibilities
>>> I can think of off the top of my head:
>>>
>>> 1. cxf generates some code  for each web service client/service that
>>> directly use spring classes.  In this case there is AFAIK no way for an
>>> app to use a different spring version since these generated classes are
>>> going to be loaded in the application classloader and they need access
>>> to cxf's copy of spring classes.  If this is what is going on I hope
>>> it's possible for cxf to stop doing this.
>>>
>>> 2. If putting spring in the apps hidden-classes works and allows the app
>>> to use a different spring version, then evidently (1) isn't a problem.
>>> In this case if we automatically add spring to hidden-classes of every
>>> app we would be preventing all apps from using our copy of spring which
>>> seems undesirable to me.  hidden-classes currently means "don't import
>>> these classes from parents".  We could look into also having a "don't
>>> export these classes to children" filter in our classloader.
>>>
>>> 3. With just the "don't export" filter proposed in (2), people adding
>>> the spring jars to their dependency list would be getting spring loaded
>>> in a different classloader for their app and for cxf.  This might not be
>>> desirable.  We could make a spring configuration to provide a single
>>> classloader to load spring in that cxf and apps could depend on.
>>>
>>> thanks
>>> david jencks
>>>


>
> I believe it's the latter. In which case, you're not giving me an
> apples-to-apples comparison, IMO.
>

 Well...lets agree to disagree.  The bottom line is we are castrating
 other projects because we have messed up classloaders.  That, IMNSHO,
 has nothing to do with apples-to-apples comparison and we are
 creating a
 treatment to the problem rather than a panacea.

 Do as you may, but call my issue with how we are handling this a
 dissenting voice.  I am not in agreement with this action.

> --kevan
>

Re: ServiceMix 4.0

[Chris Custine]

I would highly recommend switching to slf4j for internal logging, and then
use the slf4j over jcl facade to permanently get rid of commons-logging.  If
you are going to use OSGi in the future, you will have trouble with the
dynamic classloading issue introduced by JCL.  The slf4j facade will
alleviate this because the linkage is static (based on which jar you choose
to use).

I blogged about this a while back here:
http://blog.organicelement.com/2006/12/21/commons-logging-classloader-woes

Also slf4j is fairly OSGi friendly in that it has OSGi manifest headers
already built in so you can deploy with OSGi and make the logging package
available to all bundles.

Chris

On 8/27/07, Bruce Snyder <[EMAIL PROTECTED]> wrote:
>
> On 8/27/07, James Strachan <[EMAIL PROTECTED]> wrote:
>
> > > > 1. Use slf4j as the logging framework. (http://www.slf4j.org/) ->
> btw,
> > > > I'm not sure if its a better option, but I did hear some good stuff
> > > > about it.
> > >
> > > Yes, SMX should switch to using the slf4j-api which will allow any
> > > logging framework to be plugged in at deployment time.
> >
> > how's that different from commons-logging (other than adding yet
> > another dependency, since many things SMX depends on also depends on
> > commons logging)
>
> There are a lot of reasons, including an extremely good writeup about
> JCL that Ceki did back in 2004 that is available here:
>
> http://www.qos.ch/logging/thinkAgain.jsp
>
> But the most important point of all is that the use of JCL is most
> oftentimes incorrect from an architecture standpoint. At least this is
> what the creator of JCL says:
>
> '...The purpose of Commons Logging is not to somehow take the logging
> world by storm. In fact, there are very limited circumstances in which
> Commons Logging is useful. If you're building a stand-alone
> application, don't use commons-logging. If you're building an
> application server, don't use commons-logging. If you're building a
> moderately large framework, don't use commons-logging. If however,
> like the Jakarta Commons project, you're building a tiny little
> component that you intend for other developers to embed in their
> applications and frameworks, and you believe that logging information
> might be useful to those clients, and you can't be sure what logging
> framework they're going to want to use, then commons-logging might be
> useful to you...'
>
> See Rod's full blog entry here:
> http://radio.weblogs.com/0122027/2003/08/15.html
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
>

[jira] Updated: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated GERONIMO-2964:
--

Attachment: GERONIMO-2964-combined.patch

GERONIMO-2964-combined.patch: This patch features a work-dir setting for both 
tomcat and jetty.  Once again the schema files need to be renamed (which is not 
done by this patch).

I was chatting with David Jencks on IRC channel and he suggested that 
irrespective of not changing the constructors, we might be breaking 
compatibility as we have added new GBean attributes :o(

> Cannot specify the Tomcat work directory for a web application
> --
>
> Key: GERONIMO-2964
> URL: https://issues.apache.org/jira/browse/GERONIMO-2964
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.2, 2.0-M5
>Reporter: Aman Nanner
>Priority: Minor
> Fix For: 1.2, 2.1
>
> Attachments: g2964.war, GERONIMO-2964-combined.patch, 
> GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch
>
>
> In Tomcat, a work directory can be specified for a web application in a 
> WEB-INF/context.xml file.  The GeronimoStandardContext does not permit the 
> user to specify a work directory, and so the work directory defaults to 
> var/catalina/work/.
> I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to 
> permit the user to optionally specify a work directory.  This work directory 
> is then propagated into the TomcatContext.  I've tested this and it seems to 
> work well.

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

ServiceMix 4.0 api

[Nodet Guillaume]

I've refactored a few things in the api and introduced back the  
listeners and flows.

For those who prefer to read javadoc, take a look at:
 http://people.apache.org/~gnodet/servicemix-4.0/site/apidocs/

The javadoc is quite low on comments right now, so if any area  
appears to be unclear,

ask for comments and I will improve the doc asap.
Although any ideas, feedback, patches are always welcome.

To test the API, I have started a really dumb implementation of it in  
the branch,

but don't expect much at this point ;-)
http://svn.apache.org/repos/asf/incubator/servicemix/branches/ 
servicemix-4.0/


Cheers,
Guillaume Nodet

[jira] Commented: (GERONIMO-3423) Ensure that users can change the ejb jndi name format

[David Blevins (JIRA)]

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

David Blevins commented on GERONIMO-3423:
-

Fixed in 2.1 trunk.


> Ensure that users can change the ejb jndi name format
> -
>
> Key: GERONIMO-3423
> URL: https://issues.apache.org/jira/browse/GERONIMO-3423
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.0, 2.0.x
>Reporter: David Blevins
>Assignee: David Blevins
> Fix For: 2.0.x, 2.1
>
>
> Right now OpenEjbSystemGBean is hard coded to always set a value for 
> "openejb.jndiname.format".  We should check to see if it's set first and if 
> so, not reset it.  We should log a warning message if it's changed that 
> javaee app client's will not work.

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

[jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories

[David Blevins (JIRA)]

Verify log levels can be changed for openejb related log categories
---

 Key: GERONIMO-3445
 URL: https://issues.apache.org/jira/browse/GERONIMO-3445
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Affects Versions: 2.0
Reporter: David Blevins


Some users have reported inability to change log levels for log categories 
pertaining to OpenEJB.  This needs to be investigated, verified and fixed if 
found to be an issue or better documented if found not to be an issue.


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

Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories

[Karan Malhi]

How do the users of geronimo set log levels?

On 8/27/07, David Blevins (JIRA) <[EMAIL PROTECTED]> wrote:
> Verify log levels can be changed for openejb related log categories
> ---
>
>  Key: GERONIMO-3445
>  URL: https://issues.apache.org/jira/browse/GERONIMO-3445
>  Project: Geronimo
>   Issue Type: Bug
>   Security Level: public (Regular issues)
> Affects Versions: 2.0
> Reporter: David Blevins
>
>
> Some users have reported inability to change log levels for log categories 
> pertaining to OpenEJB.  This needs to be investigated, verified and fixed if 
> found to be an issue or better documented if found not to be an issue.
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>


-- 
Karan Singh Malhi

[jira] Commented: (GERONIMO-3438) context-root error

[lucols (JIRA)]

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

lucols commented on GERONIMO-3438:
--

any one can help?

> context-root error
> --
>
> Key: GERONIMO-3438
> URL: https://issues.apache.org/jira/browse/GERONIMO-3438
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.1
> Environment: debian 3.1/4.0   
> sun jdk 1.5.0_11-b03 
> apache 2.0.59/2.2.4
>Reporter: lucols
>
> In geronimo-web.xml , I configure  context-root  to nothing , like this :
> 
> thr problem is : i got then contextPath is "/" ,not expected  " ", so error 
> occur: the web container cannot  right lookup the file.
> you can test like this:
> index.jsp: 
> 
> test.jsp:
> <%
> out.println("request context:"+request.getContextPath());
> %>
> geronimo-web.xml:
> 
>xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1";> 
>  ...
> 
> 
> after deploy, test this in IE broswer:
> http://hostname:8080/index.jsp

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

Re: Cron <[EMAIL PROTECTED]> /home/jdillon/ws/site/bin/sync

[Matt Hogstrom]

Uncle

On Aug 27, 2007, at 9:10 PM, Jason Dillon wrote:


Oh, this is fun...

--jason


Begin forwarded message:


From: [EMAIL PROTECTED] (Cron Daemon)
Date: August 27, 2007 6:06:52 PM PDT
To: [EMAIL PROTECTED]
Subject: Cron <[EMAIL PROTECTED]> /home/jdillon/ws/site/bin/sync

chmod: /www/geronimo.apache.org/xbean/images/border/ 
border_bottom.gif: Operation not permitted
chmod: /www/geronimo.apache.org/xbean/images/border/spacer.gif:  
Operation not permitted

Re: New GShell-based Geronimo Server launcher now in server/trunk

[Prasad Kashyap]

I wanted to see how much Jason really really luvs Windows. So I
began trying GShell on that OS :-)

First, I was surprised it even had batch files to support Windows
users. Thanx Jason. You really have gone out of your way :-)... Just
kidding !

gsh.bat had a small typo. svn commit: r570296 fixes that.

Next, in the interactive mode, I tried "start-server help". It threw
the following error
> start-server  help
23:02:42,030 ERROR [InteractiveConsole] Error
java.lang.NoClassDefFoundError: groovy/lang/GroovyObject
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)

I'll try to debug this tomorrow morning. However, I believe GShell
will be of great use/help when we want to build a stackable server
starting from a bare-bones framework that won't even have a console.
For this we'll need plugin install capabilities in the GShell.

Go Jason, Go !

Whether you like it or not, there's a sizeable number of our users who
will be on Windows. And whether I like it or not, I or somebody will
have to try our popular features on that hated OS :-(

Cheers
Prasad

On 8/21/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
> Hiya folks, I finally got around to finishing up my POC of using
> GShell to launch the Geronimo Server and I have committed the bits
> that make it work to server/trunk.  The new module which contains the
> GShell command implementation (and support) classes is:
>
>  modules/geronimo-commands
>
> And a new assembly which has the GShell bits all in place for folks
> to test with is:
>
>  assemblies/geronimo-jetty6-javaee5-gshell
>
> The assembly is not hooked up by default, but the code module is.
> So, to test it out, you need to do something like:
>
>  svn co https://svn.apache.org/repos/asf/geronimo/server/trunk
> server
>  cd server
>  mvn
>  assemblies/geronimo-jetty6-javaee5-gshell
>  mvn
>
> Then unzip the assembly:
>
>  unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
>
> And then finally try it out.  First lets get the basic GShell command-
> line help:
>
>  ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
>
> This should spit out something like:
>
> 
>    _  _ _
>/ ___/ ___|| |__   ___| | |
>   | |  _\___ \| '_ \ / _ \ | |
>   | |_| |___) | | | |  __/ | |
>\|/|_| |_|\___|_|_|
>
>   GShell -- Geronimo command-line shell
>
> usage: gsh [options]  [args]
>  -n,--non-interactiveRun in non-interactive mode
>  -D,--define Define a system property
>  -V,--versionDisplay GShell version
>  -c,--commands   Read commands from string
>  -debug,--debug  Enable DEBUG logging output
>  -h,--help   Display this help message
>  -i,--interactiveRun in interactive mode
>  -quiet,--quiet  Limit logging output to ERROR
>  -verbose,--verbose  Enable INFO logging output
> 
>
> Then lets run the interactive-shell:
>
>  ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
>
> This should leave you at a very plain prompt at the moment:
>
> 
>  > _
> 
>
> At this point you can type something like this to list all of the
> known commands:
>
> 
> help commands
> 
>
> Which should spit back:
>
> 
> Available commands (and aliases):
>start-server ( start )
>set
>exit ( quit, bye )
>unset
>source
>help
> 
>
> The command that I added is called 'start-server', with an alias of
> 'start'.  This is basically an augmented and enhanced version of what
> the geronimo:start-server goal does in the geronimo-maven-plugin.  To
> see its options run this:
>
> 
> start-server --help
> 
>
> And it says:
>
> 
> start-server -- Starts a new Geronimo server instance
>
> usage: start-server [options]
>  -A,--javaagent   Use a specific Java Agent, set to
> 'none' to
>disable
>  -D,--property Set a system property
>  -H,--homeUse a specific Geronimo home
> directory
>  -J,--javaopt  Set a JVM flag
>  -b,--background   Run the server process in the
> background.
>  -h,--help Display this help message
>  -j,--jvm Use a specific Java Virtual
> Machine for server
>process
>  -l,--logfileCapture console output to file
>  -m,--module Start up a specific module by name.
>  -q,--quietSuppress informative and warning
> messages
>  -t,--timeout Specify the timeout for the server
> process in
>seconds
>  -v,--verbose  Enable verbose output; specify
> multipule times
>to increase verbosity.
> 
>
> NOTE: Use -vv 

Re: Adding j2g to site

[Matt Hogstrom]

Erik, Jason and Viet.  This is really good.  Since we're making a  
SNAPSHOT available is there some point where we should declare a 1.0 ?



On Aug 23, 2007, at 4:30 PM, Erik B. Craig wrote:


All,

After the recent round of changes and improvements around j2g  
(usable from within the Eclipse IDE UI, Annotations support,  
improved logging/information output, support for EJB 3), as well as  
a bit of interest out in the general open source community in  
moving applications from Jboss to Geronimo (such as today's inquiry  
on theserverside.com), I feel as though it would be of some benefit  
to have j2g, at least the content in our confluence wiki ( http:// 
cwiki.apache.org/GMOxDOC20/j2g-migration-tool.html) linked  
somewhere on the actual geronimo homepage. I was thinking either as  
it's own link under 'Subprojects', much as Development Tools,  
GBuild, or XBean are situated, or as an addition inside the  
Development Tools page, much as the current Eclipse Plug-in section  
rests within there.


I am willing to commit to doing a bit of additional writing (beyond  
what is on the wiki) if it were to be under it's own section, or a  
subsection of development tools if necessary, but I think it would  
be good to get it up and out there sooner rather than later,  
especially to coincide with the recent release of 2.0.1 to perhaps  
show those out there remotely interested in migrating, there are  
tools available to assist and perhaps 'hold their hand' a bit.



Thoughts? Comments? Objections?

Thanks
--
Erik B. Craig