[jira] Closed: (GERONIMO-3150) Cannot open mutliple connections to Derby from Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3150. -- Resolution: Cannot Reproduce Fix Version/s: 2.1 Assignee: David Jencks I installed the roller plugin (geronimo svn root/plugins/roller/trunk) and started it up which creates a database and a lot of tables and had no problems seeing the tables in the dbmanager page. I think this problem was fixed a long time ago. Please reopen with more details on how to reproduce if it is still a problem in 2.1 Cannot open mutliple connections to Derby from Geronimo --- Key: GERONIMO-3150 URL: https://issues.apache.org/jira/browse/GERONIMO-3150 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 1.1.1 Environment: Windows XP. 32-bit. Reporter: Rajiv M Assignee: David Jencks Fix For: 2.1 The below is a testcase to simulate the problem: Steps: Create a Derby database from DBManager Create a Derby database pool in Geronimo console Create a web app that uses DataSource/JNDI to connect to Derby I am able to reproduce the problem in 2 ways: 1. * Deploy the application and launch the web component that access the database * Run DBManager to do SQL operation on the same database * DBManager will report error - database booted by another instance 2. * Deploy the application and launch the web component that access the database without starting it * Run DBManager to do SQL operation on the same database * Launch the web app * Web app will report error - database booted by another instance Derby embedded should allow mutliple connections to a database from same JVM as documented in the Apache Derby website. But, appears that DBManager and webapplication cannot open connections at the same time. It is always first attempt wins. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2144) GBean for handling initial database population
[ https://issues.apache.org/jira/browse/GERONIMO-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2144. -- Resolution: Duplicate Assignee: David Jencks Duplicate of GERONIMO-2396 GBean for handling initial database population -- Key: GERONIMO-2144 URL: https://issues.apache.org/jira/browse/GERONIMO-2144 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: databases Affects Versions: Wish List Reporter: Paul McMahan Assignee: David Jencks Priority: Minor Some applications like daytrader and liferay need to have a database populated before they can run. It would be nice to have a GBean that could take a datasource and SQL as input and handling running the SQL when the application is started for the first time. The GBean would need to also provide a way to avoid running the SQL multiple times, perhaps by allowing the deployment plan to specify an SQL statement that the GBean can use to determine if the database has already been populated. This idea was originally proposed by David Jencks and discussed in this thread: http://mail-archives.apache.org/mod_mbox/geronimo-dev/200511.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2396) DatabaseInitializationGBean to run db scripts on startup
[ https://issues.apache.org/jira/browse/GERONIMO-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2396. -- Resolution: Fixed Fix Version/s: (was: Wish List) 2.1 This class is less than ideal but has been in place a long time... it could use some better error handling and maybe replacing with ant. DatabaseInitializationGBean to run db scripts on startup Key: GERONIMO-2396 URL: https://issues.apache.org/jira/browse/GERONIMO-2396 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: databases Affects Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Priority: Minor Fix For: 2.1 Attachments: GERONIMO-2396.patch I put together a gbean that will run an sql script when it starts. It has a testSQL so you can make it run only if the testSQL fails so you can e.g. do select * from MyTable where 1=2 to see if MyTable exists. This is pretty crude but seems useful: I stuck it in my daytrader plan instead of the gbean that copied a premade derby db out of the car file. I put it in connector since it needs a connector interface -- ConnectionFactorySource. This seems to me like absolutely the wrong place but I don't see a better place. Anyway I hope we can find a happy home for some improved version of this class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3440) DB2-XA: when trace file is not specified, it caused error when running the sample
[ https://issues.apache.org/jira/browse/GERONIMO-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563074#action_12563074 ] David Jencks commented on GERONIMO-3440: Patch applied in tranql rev 566. Still need to release tranql version. DB2-XA: when trace file is not specified, it caused error when running the sample - Key: GERONIMO-3440 URL: https://issues.apache.org/jira/browse/GERONIMO-3440 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Reporter: Lin Sun Priority: Minor Fix For: 2.1 Attachments: tranql-tracefile.patch This is a tranql issue found when I plug the db2-xa rar into G's console. Basically, if a user leaves the tracefile property to empty (meaning dont want any trace), I can deploy my sample fine. But when I run the sample, I got - --- Got DataSource: [EMAIL PROTECTED] com.ibm.db2.jcc.b.SqlException: Unable to open file at com.ibm.db2.jcc.b.ig.a(ig.java:93) A simple fix in DB2XA is to only settrace when it is a valid value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3440) DB2-XA: when trace file is not specified, it caused error when running the sample
[ https://issues.apache.org/jira/browse/GERONIMO-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-3440: -- Assignee: David Jencks DB2-XA: when trace file is not specified, it caused error when running the sample - Key: GERONIMO-3440 URL: https://issues.apache.org/jira/browse/GERONIMO-3440 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Reporter: Lin Sun Assignee: David Jencks Priority: Minor Fix For: 2.1 Attachments: tranql-tracefile.patch This is a tranql issue found when I plug the db2-xa rar into G's console. Basically, if a user leaves the tracefile property to empty (meaning dont want any trace), I can deploy my sample fine. But when I run the sample, I got - --- Got DataSource: [EMAIL PROTECTED] com.ibm.db2.jcc.b.SqlException: Unable to open file at com.ibm.db2.jcc.b.ig.a(ig.java:93) A simple fix in DB2XA is to only settrace when it is a valid value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2137) Empty datasource tracefile causes fatal error attempting to run web app
[
https://issues.apache.org/jira/browse/GERONIMO-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks closed GERONIMO-2137.
--
Resolution: Duplicate
Fix Version/s: 2.1
Assignee: David Jencks
I think this is a duplicate of GERONIMO-3440. The patch suggested there is
applied to tranql but the wrapper is not yet released.
Empty datasource tracefile causes fatal error attempting to run web app
---
Key: GERONIMO-2137
URL: https://issues.apache.org/jira/browse/GERONIMO-2137
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: databases
Affects Versions: 1.0
Environment: Issue was found on Windows, but unsure if it is limited
to Windows server 2003.
Reporter: Tim Pickett
Assignee: David Jencks
Fix For: 2.1
If you deploy a web applicaiton with a datasource(db2 in this instance) and
do not specify a tracefile, the application will run fine. Once you use the
admin console to change an attribute in the datasource, the application
server will add an empty tracefile attribute to the config.xml, and you will
no longer be able to run the web application if it attempt so access the
database. (Issue was found in CE)
WORKAROUND: remove the 2 attributes from the config.xml and it will work
fine, no attempt to trace occurs.
The attributes added are:
attribute name=TraceFile/attribute
attribute name=TraceFileAppendfalse/attribute
The entire section of the config.xml file for the datasource is as follows:
configuration name=Trade
gbean
name=geronimo.server:J2EEApplication=Trade,J2EEServer=geronimo,JCAResource=TradeDataSource,j2eeType=JCAManagedConnectionFactory,name=jdbc/TradeDataSource
attribute name=DatabaseNametradev/attribute
attribute name=Usertrade/attribute
attribute name=DriverType4/attribute
attribute
name=Password{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwECL7hrKO7YATsIUlVrzQ9VxwdAADQUVT/attribute
attribute name=PortNumber5/attribute
attribute name=ServerNameviper22/attribute
attribute name=TraceFile/attribute
attribute name=TraceFileAppendfalse/attribute
/gbean
gbean
name=geronimo.server:J2EEApplication=Trade,J2EEServer=geronimo,JCAResource=TradeDataSource,j2eeType=JCAConnectionManager,name=jdbc/TradeDataSource
attribute name=partitionMinSize0/attribute
attribute name=partitionMaxSize40/attribute
attribute name=blockingTimeoutMilliseconds5000/attribute
attribute name=idleTimeoutMinutes30/attribute
/gbean
/configuration
Stack trace follows:
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0
Arial;}}
{\*\generator Msftedit 5.41.21.2500;}\viewkind4\uc1\pard\f0\fs20
com.ibm.db2.jcc.a.SqlException: Unable to open file\par
at com.ibm.db2.jcc.a.xd.a(xd.java:93)\par
at
com.ibm.db2.jcc.DB2BaseDataSource.computePrintWriter(DB2BaseDataSourc\par
e.java:1955)\par
at
com.ibm.db2.jcc.DB2BaseDataSource.computeJccLogWriter(DB2BaseDataSour\par
ce.java:1848)\par
at
com.ibm.db2.jcc.DB2BaseDataSource.computeJccLogWriterForNewConnection\par
(DB2BaseDataSource.java:1808)\par
at
com.ibm.db2.jcc.DB2BaseDataSource.computeJccLogWriterForNewConnection\par
(DB2BaseDataSource.java:1768)\par
at
com.ibm.db2.jcc.DB2XADataSource.getXAConnection(DB2XADataSource.java:\par
62)\par
at
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnecti\par
on(AbstractXADataSourceMCF.java:74)\par
at
org.tranql.connector.db2.XAMCF.createManagedConnection(XAMCF.java:57)\par
\par
at
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCo\par
nnection(MCFConnectionInterceptor.java:41)\par
at
org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor\par
.getConnection(XAResourceInsertionInterceptor.java:41)\par
at
org.apache.geronimo.connector.outbound.SinglePoolConnectionIntercepto\par
r.internalGetConnection(SinglePoolConnectionInterceptor.java:63)\par
at
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionIn\par
terceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:73)\par
at
org.apache.geronimo.connector.outbound.TransactionEnlistingIntercepto\par
r.getConnection(TransactionEnlistingInterceptor.java:47)\par
at
org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.\par
getConnection(TransactionCachingInterceptor.java:86)\par
at
[jira] Closed: (GERONIMO-3382) InvalidConfigurationException is thrown when starting the plugins from the console
[ https://issues.apache.org/jira/browse/GERONIMO-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3382. -- Resolution: Invalid 2 comments that it's invalid I'll believe them. InvalidConfigurationException is thrown when starting the plugins from the console --- Key: GERONIMO-3382 URL: https://issues.apache.org/jira/browse/GERONIMO-3382 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0-M5 Environment: Windows xp x86-32 Reporter: Song Assignee: Lin Sun After successfully installed plugins provided by Geronimo, start the plugin just installed, InvalidConfigurationException exception is thrown from server The below steps can reproduce the error: 1) Login to admin console,click on Plugins in the left navigation bar. 2) Click on Update Repository List link in Create and Install Plugins portlet, and select http://geronimo.apache.org/plugins/geronimo-2.0/; in Repository field. 3) Click on Search for Plugins button. 4) Click on Jakarta JSP Examples (Tomcat) (2.0-SNAPSHOT) link,click on Continue button,click on Install Plugin button. 5) Click on Start org.apache.geronimo.configs/jsp-examples-tomcat/2.0-SNAPSHOT/car button. NO response at the current page, but from the server started console, the below error is thrown: --- 14:18:58,796 WARN [ConfigurationUtil] Could not load gbean org.apache.geronimo.configs/jsp-examples-tomcat/2.0-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=org.apache.geronimo.configs/jsp-examples-tomcat/2.0-SNAPSHOT/car org.apache.geronimo.gbean.InvalidConfigurationException: Getter method not found Attribute Name: URLFor, Type: class java.net.URL, GBeanInstance: Tomcat WebApplication Context at org.apache.geronimo.gbean.runtime.GBeanAttribute.init(GBeanAttribute.java:252) at org.apache.geronimo.gbean.runtime.GBeanInstance.init(GBeanInstance.java:245) at org.apache.geronimo.kernel.basic.BasicKernel.loadGBean(BasicKernel.java:354) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:433) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:511) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$3a7a5946.startConfiguration(generated) at org.apache.geronimo.console.car.ResultsHandler.actionAfterView(ResultsHandler.java:76) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:116) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) 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
[jira] Created: (GERONIMO-3794) Monitoring Console should give option of using JMX to connect to the Monitoring Agent
Monitoring Console should give option of using JMX to connect to the Monitoring Agent - Key: GERONIMO-3794 URL: https://issues.apache.org/jira/browse/GERONIMO-3794 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Reporter: Erik B. Craig Assignee: Erik B. Craig Fix For: 2.1 The Monitoring Console should be able to connect to either the EJB or the JMX flavor of the Monitoing agent, specified at the addition of a server to the connection list/database, all other differences being seamless -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3794) Monitoring Console should give option of using JMX to connect to the Monitoring Agent
[ https://issues.apache.org/jira/browse/GERONIMO-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3794: Remaining Estimate: (was: 12h) Original Estimate: (was: 12h) Monitoring Console should give option of using JMX to connect to the Monitoring Agent - Key: GERONIMO-3794 URL: https://issues.apache.org/jira/browse/GERONIMO-3794 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Reporter: Erik B. Craig Assignee: Erik B. Craig Fix For: 2.1 The Monitoring Console should be able to connect to either the EJB or the JMX flavor of the Monitoing agent, specified at the addition of a server to the connection list/database, all other differences being seamless -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2254) No way for users to list installed plugins
[ https://issues.apache.org/jira/browse/GERONIMO-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2254. -- Resolution: Fixed Fix Version/s: (was: 1.1.x) 2.1 Assignee: David Jencks (was: Aaron Mulder) Might not be ideal, but the first step in exporting a server either via gshell or the console involves displaying a list of all the pllugins in the current server so you can pick the ones you want. No way for users to list installed plugins -- Key: GERONIMO-2254 URL: https://issues.apache.org/jira/browse/GERONIMO-2254 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 2.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2311) Exporting plug-in configurations
[ https://issues.apache.org/jira/browse/GERONIMO-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-2311: -- Assignee: David Jencks Exporting plug-in configurations Key: GERONIMO-2311 URL: https://issues.apache.org/jira/browse/GERONIMO-2311 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1.2 Reporter: Krishnakumar B Assignee: David Jencks Priority: Minor Attachments: GERONIMO-2311.patch When i export a configuration from geronimo to plugin and save it to disk the file names are not legible for e.g) I exported a DataSource Saved as rar.0%2Frar I exported a War . Saved as war.0%2Fwar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (GERONIMO-3794) Monitoring Console should give option of using JMX to connect to the Monitoring Agent
[ https://issues.apache.org/jira/browse/GERONIMO-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig deleted GERONIMO-3794: Monitoring Console should give option of using JMX to connect to the Monitoring Agent - Key: GERONIMO-3794 URL: https://issues.apache.org/jira/browse/GERONIMO-3794 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Reporter: Erik B. Craig Assignee: Erik B. Craig The Monitoring Console should be able to connect to either the EJB or the JMX flavor of the Monitoing agent, specified at the addition of a server to the connection list/database, all other differences being seamless -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3786) Command deploy.bat/sh failed to start in the exported server
[ https://issues.apache.org/jira/browse/GERONIMO-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563079#action_12563079 ] YunFeng Ma commented on GERONIMO-3786: -- I included geronimo-boilerplate-minimal and org.apache.geronimo.configs/tomcat6/2.1-SNAPSHOT/car via the console to export the server. I'll try the gshell command. BTW, there is no var/config/client_artifact_aliases.properties in the exported server. Thanks. Command deploy.bat/sh failed to start in the exported server Key: GERONIMO-3786 URL: https://issues.apache.org/jira/browse/GERONIMO-3786 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: YunFeng Ma Fix For: 2.1 In the exported server, command deploy.bat/sh failed to start with error: H:\gt2.1\var\temp\--bin\-\bindeploy --user system --password manager list-modules Using GERONIMO_BASE: H:\gt2.1\var\temp\--bin\- Using GERONIMO_HOME: H:\gt2.1\var\temp\--bin\- Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:C:\Program Files\IBM\Java50\jre 09:44:04,171 ERROR [GBeanInstanceState] Error while starting; GBean is now in th e FAILED state: abstractName=org.apache.geronimo.framework/online-deployer/2.1- SNAPSHOT/car?configurationName=org.apache.geronimo.framework/online-deployer/2.1 -SNAPSHOT/car org.apache.geronimo.kernel.repository.MissingDependencyException: Missing depend ency: org.apache.geronimo.framework/geronimo-deploy-jsr88/2.1-SNAPSHOT/jar at org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(Confi gurationResolver.java:113) at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Config uration.java:405) at org.apache.geronimo.kernel.config.Configuration.createConfigurationCl asssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.init(Configuration. java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct orAccessorImpl.java:67) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC onstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:521) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:948) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:541) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.j ava:361) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf iguration(ConfigurationUtil.java:195) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf iguration(ConfigurationUtil.java:159) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBoo tConfiguration(MainConfigurationBootstrapper.java:84) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain (MainConfigurationBootstrapper.java:57) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma inConfigurationBootstrapper.java:38) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31 ) java.lang.IllegalStateException: GBean is not running: org.apache.geronimo.frame work/online-deployer/2.1-SNAPSHOT/car?configurationName=org.apache.geronimo.fram ework/online-deployer/2.1-SNAPSHOT/car at org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.jav a:304) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf iguration(ConfigurationUtil.java:197) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf iguration(ConfigurationUtil.java:159) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBoo tConfiguration(MainConfigurationBootstrapper.java:84) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain (MainConfigurationBootstrapper.java:57) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma inConfigurationBootstrapper.java:38) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31 ) -- This message is
TxManager / Connector as OSGi bundles
I've committed a patch to the transaction manager so that they are packaged as OSGi bundles. See http://svn.apache.org/viewvc?view=revrevision=615758 The impact should be null, but a review of the generated binaries (to make sure they include all what's needed and not more) would be appreciated. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Commented: (GERONIMO-3778) downloadStatus page in plugin installer isn't grabbing correct configIds array
[ https://issues.apache.org/jira/browse/GERONIMO-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563096#action_12563096 ] Joseph Leong commented on GERONIMO-3778: As suggested, switched to implementing a single DWR display line of the currentFile being processed instead of a possible overbearing list with jstl for loop. downloadStatus page in plugin installer isn't grabbing correct configIds array -- Key: GERONIMO-3778 URL: https://issues.apache.org/jira/browse/GERONIMO-3778 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Fix For: 2.1 Attachments: GERONIMO-3778.patch On the downloadStatus page of the plugin installer, the list of plugins to install shows null because the configIds array isn't being requested properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3786) Command deploy.bat/sh failed to start in the exported server
[ https://issues.apache.org/jira/browse/GERONIMO-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563107#action_12563107 ] YunFeng Ma commented on GERONIMO-3786: -- Failed to export a server via gshelll with the following error: [EMAIL PROTECTED]:/ deploy/assemble -g org.apache.geronimo.assemblies -a geronimo-tomcat -v 1.0-SNAPSHOT org.apache.geronimo.assemblies/geronimo-boilerplate-minimal/2.1-SNAPSHOT/jar org.apache.geronimo.configs/tomcat6/2.1-SNAPSHOT/car ERROR ProcessingException: No argument is allowed: org.apache.geronimo.assemblies/geronimo-boilerplate-minimal/2.1-SNAPSHOT/jar Command deploy.bat/sh failed to start in the exported server Key: GERONIMO-3786 URL: https://issues.apache.org/jira/browse/GERONIMO-3786 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: YunFeng Ma Fix For: 2.1 In the exported server, command deploy.bat/sh failed to start with error: H:\gt2.1\var\temp\--bin\-\bindeploy --user system --password manager list-modules Using GERONIMO_BASE: H:\gt2.1\var\temp\--bin\- Using GERONIMO_HOME: H:\gt2.1\var\temp\--bin\- Using GERONIMO_TMPDIR: var\temp Using JRE_HOME:C:\Program Files\IBM\Java50\jre 09:44:04,171 ERROR [GBeanInstanceState] Error while starting; GBean is now in th e FAILED state: abstractName=org.apache.geronimo.framework/online-deployer/2.1- SNAPSHOT/car?configurationName=org.apache.geronimo.framework/online-deployer/2.1 -SNAPSHOT/car org.apache.geronimo.kernel.repository.MissingDependencyException: Missing depend ency: org.apache.geronimo.framework/geronimo-deploy-jsr88/2.1-SNAPSHOT/jar at org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(Confi gurationResolver.java:113) at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Config uration.java:405) at org.apache.geronimo.kernel.config.Configuration.createConfigurationCl asssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.init(Configuration. java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct orAccessorImpl.java:67) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC onstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:521) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:948) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:541) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.j ava:361) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf iguration(ConfigurationUtil.java:195) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf iguration(ConfigurationUtil.java:159) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBoo tConfiguration(MainConfigurationBootstrapper.java:84) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain (MainConfigurationBootstrapper.java:57) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma inConfigurationBootstrapper.java:38) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31 ) java.lang.IllegalStateException: GBean is not running: org.apache.geronimo.frame work/online-deployer/2.1-SNAPSHOT/car?configurationName=org.apache.geronimo.fram ework/online-deployer/2.1-SNAPSHOT/car at org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.jav a:304) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf iguration(ConfigurationUtil.java:197) at org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConf iguration(ConfigurationUtil.java:159) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBoo tConfiguration(MainConfigurationBootstrapper.java:84) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain (MainConfigurationBootstrapper.java:57) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma inConfigurationBootstrapper.java:38) at
[jira] Commented: (GERONIMO-3781) Plugin Installer, CRSF issue when attempting to install a new plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563098#action_12563098 ] Joseph Leong commented on GERONIMO-3781: The cookie/session mismatch may have been a byproduct of not being redirected to ContinueForm after installation is complete. There the DWR session may properly close and allowing it to recreate a matching cookie/session the next time the plugin installer is called. Similar issue may exist in the Sys-Db portlet as well, will confirm and open separate JIRA. Plugin Installer, CRSF issue when attempting to install a new plugin Key: GERONIMO-3781 URL: https://issues.apache.org/jira/browse/GERONIMO-3781 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Fix For: 2.1 Plugin installer will not allow for you to install anymore plugins on a second attempt given that it threw an exception the first time. This is attributed to the exception thrown that doesn't properly exit and close off current sessions. So in the second attempt there is a cookie/session mismatch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3730) monitoring plugin to support jmx connections in mconsole
[ https://issues.apache.org/jira/browse/GERONIMO-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563113#action_12563113 ] Erik B. Craig commented on GERONIMO-3730: - Progress Committed revision 615847. Still need to implement MRCConnectorJMX add additional checks on protocol to determine which class to use monitoring plugin to support jmx connections in mconsole Key: GERONIMO-3730 URL: https://issues.apache.org/jira/browse/GERONIMO-3730 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Reporter: Viet Hung Nguyen Assignee: Viet Hung Nguyen There should be another collecting agent that does not use MEJB, but JMX instead. This should probably be a separate plugin than the existing agent because we do not want to pull in OpenEJB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3778) downloadStatus page in plugin installer isn't grabbing correct configIds array
[ https://issues.apache.org/jira/browse/GERONIMO-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563117#action_12563117 ] Joseph Leong commented on GERONIMO-3778: Single DWR display line implemented and will be reflected in the patch posted at https://issues.apache.org/jira/browse/GERONIMO-3746 along with the consolidation of several related JIRAS. Please refer to GERONIMO-3746 for future updates regarding this JIRA. Thanks, Joseph Leong downloadStatus page in plugin installer isn't grabbing correct configIds array -- Key: GERONIMO-3778 URL: https://issues.apache.org/jira/browse/GERONIMO-3778 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Fix For: 2.1 Attachments: GERONIMO-3778.patch On the downloadStatus page of the plugin installer, the list of plugins to install shows null because the configIds array isn't being requested properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3788) Plugin installer's continue form generating errors
[ https://issues.apache.org/jira/browse/GERONIMO-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563120#action_12563120 ] Joseph Leong commented on GERONIMO-3788: Due to the issue occurring in several overlapping files of other related JIRAS, please refer to GERONIMO-3746 for future updates regarding this bug. Thanks! Joseph Leong Plugin installer's continue form generating errors -- Key: GERONIMO-3788 URL: https://issues.apache.org/jira/browse/GERONIMO-3788 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Fix For: 2.1 After installing plugin components, the Continue Form page that the user is being redirected to is generating errors. 500 -Error -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3746) Plugin Progress Bar Not Updating
[ https://issues.apache.org/jira/browse/GERONIMO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563118#action_12563118 ] Joseph Leong commented on GERONIMO-3746: Update; This JIRA will now consolidate the progresses of JIRAS: GERONIMO-3778, GERONIMO-3788, GERONIMO-3781 due to the fact that these issues occur in several overlapping files. Thanks! Joseph Leong Plugin Progress Bar Not Updating Key: GERONIMO-3746 URL: https://issues.apache.org/jira/browse/GERONIMO-3746 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Reporter: Joseph Leong Assignee: Joseph Leong When installing any plugin from the repository, the progress bar fails to update correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3781) Plugin Installer, CRSF issue when attempting to install a new plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563121#action_12563121 ] Joseph Leong commented on GERONIMO-3781: Due to the issue occurring in several overlapping files of other related JIRAS, please refer to GERONIMO-3746 for future updates regarding this bug. Thanks! Joseph Leong Plugin Installer, CRSF issue when attempting to install a new plugin Key: GERONIMO-3781 URL: https://issues.apache.org/jira/browse/GERONIMO-3781 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Fix For: 2.1 Plugin installer will not allow for you to install anymore plugins on a second attempt given that it threw an exception the first time. This is attributed to the exception thrown that doesn't properly exit and close off current sessions. So in the second attempt there is a cookie/session mismatch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: How to change KeyStore type?
Here is an essence of the fix that went in to trunk (2.1): o Allow creation of all possible keystore types supported. Keystore type is no longer restricted to JKS. o Added a type parameter to create keystore methods. o Keystores portlet will now allow creating and managing all types of keystores. o This revision will simplify the configuration changes required to run G on a JVM that does not support JKS keystores (for e.g., Harmony). o Allow selecting any keystore type supported by the JVM in Tomcat HTTPS Connector pages. As this feature required some interface changes, for e.g. KeystoreManager, KeystoreInstance etc., I would like to hear from others on considering this for branches\2.0 as it may break compatibility. ++Vamsi On Jan 21, 2008 11:21 PM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Vamsi, Thanks for the detailed analysis. The problem indeed looks non-trivial. Step 1. This looks pretty simple, and I'm now creating a patch for that. This change seems very important to me, how about getting it to v2.0.3 /2.1? Step 2. This change also seems very important, but less critical than the first one, and it requires essential interface changes, so I tend to agree it certainly should wait till 2.1 or later. As of pitfalls, they seem unavoidable. Sure we want compatibility, but any compatibility has its limits. I suppose that changing JDK under a particular running installation of Geronimo is not a feature in great demand, and in a rare case when such a change would be necessary, a keystore conversion could be done manually (e.g. JKS-PKCS12 conversion can be done in Sun, PKCS12-BKS conversion can be done in Harmony etc.) Vasily -- *From:* Vamsavardhana Reddy [mailto:[EMAIL PROTECTED] *Sent:* Monday, January 21, 2008 8:23 PM *To:* dev@geronimo.apache.org *Subject:* Re: How to change KeyStore type? Providing a keystoreType attribute does not seem to be a big deal. But, if the Keystores portlet has to allow creating all types of keystores, it gets really messy. Here is one more observation. *IBMJDK does not allow storing an empty PKCS12 keystore to disk. * This prevents creating an empty PKCS12 keystore and then adding which ever keys and certificates the user wants to. Here is the approach I want to take. Step 1. Provide a keystoreType attribute in FileKeystoreInstance. Step 2. Update KeyStores portlet to allow creation of all keystore types that the JDK allows to store an empty keystore to disk. Step 1 will allow the users to replace a keystore file of one type with that of another type, change the keystoreType in config.xml and get the server running. Step 2 will allow users to manage all keystore types using Keystores portlet and there is no hard-coding of any keystoreType except for geronimo-default keystore which is JKS. Now to some pitfalls. 1. If keystore type other than JKS is in use, the user may not be able to switch JDK's for reasons like PKCS12 keystore created using IBMJDK are not readble using SUNJDK. 2. Though IBMJDK does not allow creating an empty PKCS12 (and a few other types) keystore as a starting point for managing a PKCS12 keystore, the users can always add a PKCS12 keystore to var/security/keystores and the gbean definition to config.xml. This will make the keystore manageable through KeyStores portlet as long as the keystore is not empty. This will require a change in org.apache.geronimo.management.geronimo.KeystoreManager interface, etc. I doubt if we can consider this change for branches\2.0. Comments? ++Vamsi On Jan 18, 2008 1:37 AM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Yes, sure, I fully agree. I've filed GERONIMO-3757 for this issue and now thinking of the patch to the trunk that would provide the necessary customization - unless any objections arise. As of GERONIMO-2015, I think we may close it, as there're objective reasons (stated there by Vamsavardhana Reddy) to not move from JKS on Sun. Vasily -Original Message- From: Alexey Petrenko [mailto: [EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 1:37 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? I think we should add PKCS12 to Geronimo. If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose what keystore to use? We can specify keystore in configs or choose type from available on current VM. SY, Alexey 2008/1/15, Zakharov, Vasily M [EMAIL PROTECTED]: Hi, all, Is there a way to change the geronimo-default keystore from JKS to, say, PKCS12 without patching the org.apache.geronimo.security.keystore.FileKeystore* classes? That way of patching sources is suggested at GERONIMO-2015, and it works, but it's probably not the best idea. I see the reasons of not making PKCS12 a default keystore type, but what about making it possible to change keystore type using
[jira] Commented: (GERONIMO-3783) MessageDrivenBean delivery problem
[ https://issues.apache.org/jira/browse/GERONIMO-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563136#action_12563136 ] Tomasz Mazan commented on GERONIMO-3783: I got exception when I try to set ThreadPool's attribute ipoolSize/i. I want to emphasize I use Geronimo 2.1-SNAPSHOT 14:06:48,968 WARN [ConfigurationUtil] Could not load gbean org.apache.geronimo.test.mdb/MessageReceiversDestinations/1.0/jar?J2EEApplicatio n=null,ResourceAdapterModule=org.apache.geronimo.test.mdb/MessageReceiversDestinations/1.0/jar,j2eeType=GBean,name=MRConnectorThreadPool org.apache.geronimo.gbean.InvalidConfigurationException: Could not inject configuration data into the GBean org.apache.geronimo.test.mdb/Mes sageReceiversDestinations/1.0/jar?J2EEApplication=null,ResourceAdapterModule=org.apache.geronimo.test.mdb/MessageReceiversDestinations/1.0/j ar,j2eeType=GBean,name=MRConnectorThreadPool at org.apache.geronimo.gbean.runtime.GBeanInstance.init(GBeanInstance.java:375) at org.apache.geronimo.kernel.basic.BasicKernel.loadGBean(BasicKernel.java:354) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:433) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:534) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:515) 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:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor144.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:865) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1426) at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1264) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1366) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.IllegalStateException: Attribute is not
Re: Geronimo v2.1 documentation
Jay D. McHugh wrote: Kevan Miller wrote: On Jan 25, 2008, at 11:22 AM, Hernan Cunico wrote: Guys, I've been trying to get your attention around Geronimo 2.1 documentation since October last year. Apache Geronimo is as good as you can communicate it to the users. How do you expect the users to know all the beeps and whistles? Not a best way to tell the users HOW TO do things in Geronimo than by having a good documentation. How much of your time it would actually take to write up a page describing a component or module and how to use it? It's you writing the code, why not you writing about that code and how to use it!? There are tons of questions on the user@ and dev@ lists about how to perform basic (and some times not so basic) tasks and configurations, we get these all the time. This is a clear sign that we need to improve the way we document the things. For 2.1 the situation is even worse, we pretty much don't have any documentation and we can't continue developing documentation the way we've been doing in the past. The way it looks now, Geronimo 2.1 won't have supporting documentation. Let's discuss here what areas need to be covered and who can work on documenting them. It is your turn now. Hernan, I hear your pain. And totally agree that good docs will make things much easier for our users (as well as ourselves). I know I'm as guilty (perhaps more so) as anyone else at failing to help pitch in. Everybody's pretty busy. Also, there's a definite tendency for skilled developers to be, well, skilled *developers*. Perhaps there are some alternate ways to help this process go faster? I wonder if it would be easier for people to discuss a particular topic with you on a phone call? Hopefully providing enough information for you to transform into flowery prose and lucid illustrations? If we want, we could make this a conference call (so interested parties could join). I don't think this technique can work for all docs. We can't expect you to write everything. However, it might help kickstart the process in some critical sections... --kevan If folks think that something like this could work - I would be happy to chip in as a typist. I took a look at the shell for the documentation and realized that I know far too little to be able to write the docs from scratch. Plus, it would be useful for me to be able to get more familiar with everything. Jay Hernan, Since I'm very new to Geronimo development, this would probably be a good place for me to get involved and see how things really work. Just let me know what I can help you out with. -- B.J.
Re: Geronimo v2.1 documentation
I'm really open to new ideas but I don't think phone calls will address this issue. If we want to catch up with the rest and have a decent documentation we all need to participate. I mean, we have not been too successful in having a documentation based discussion on the list, even about what topics to cover (just see this tread alone). What I think it would work best is to first chime in for the topics and structure discussion. Get to an agreement on what are the things that have changed from previous releases and what are the things the users need the most. We can break those topics into individual discussion threads on dev@ and use that as a reference for starting each doc. Or we can draft the content right there on the email, give it some shape and then we move it to the wiki and do the final fit finish. I don't want to rule out the phone calls, a holler may work for some cases, but in general I think the discussion over the dev@ would work best. PS. I'm willing to do, besides some of the classic writing ;-) , the formatting and editing and taking the bullet for any pain related to putting the content into the wiki. So, let's start with a brain dump, don't worry about the styling or super refining the content. This would be a great start, we'll take it from there. Cheers! Hernan Kevan Miller wrote: On Jan 25, 2008, at 11:22 AM, Hernan Cunico wrote: Guys, I've been trying to get your attention around Geronimo 2.1 documentation since October last year. Apache Geronimo is as good as you can communicate it to the users. How do you expect the users to know all the beeps and whistles? Not a best way to tell the users HOW TO do things in Geronimo than by having a good documentation. How much of your time it would actually take to write up a page describing a component or module and how to use it? It's you writing the code, why not you writing about that code and how to use it!? There are tons of questions on the user@ and dev@ lists about how to perform basic (and some times not so basic) tasks and configurations, we get these all the time. This is a clear sign that we need to improve the way we document the things. For 2.1 the situation is even worse, we pretty much don't have any documentation and we can't continue developing documentation the way we've been doing in the past. The way it looks now, Geronimo 2.1 won't have supporting documentation. Let's discuss here what areas need to be covered and who can work on documenting them. It is your turn now. Hernan, I hear your pain. And totally agree that good docs will make things much easier for our users (as well as ourselves). I know I'm as guilty (perhaps more so) as anyone else at failing to help pitch in. Everybody's pretty busy. Also, there's a definite tendency for skilled developers to be, well, skilled *developers*. Perhaps there are some alternate ways to help this process go faster? I wonder if it would be easier for people to discuss a particular topic with you on a phone call? Hopefully providing enough information for you to transform into flowery prose and lucid illustrations? If we want, we could make this a conference call (so interested parties could join). I don't think this technique can work for all docs. We can't expect you to write everything. However, it might help kickstart the process in some critical sections... --kevan
Re: Geronimo v2.1 documentation
Hi Jay, as I said on another reply, don't worry about the wiki format, doc structure or refined content, I'll take that bullet. We need to focus on what to cover and how. When we have the content, it is easier to move it around within the wiki, edit it and to give it a consistent look with the rest of the docs. If you want to look into the formatting we've been using in the past, I created this page long time ago to help me (and everybody adding content) be consistent with the existing doc. http://cwiki.apache.org/geronimo/tips-for-writing-and-formatting-documentation.html I'm about to shoot a separate thread for discussing the content, pls chime in with your ideas, I'll put there mine as well ;-) Cheers! Hernan Jay D. McHugh wrote: Kevan Miller wrote: On Jan 25, 2008, at 11:22 AM, Hernan Cunico wrote: Guys, I've been trying to get your attention around Geronimo 2.1 documentation since October last year. Apache Geronimo is as good as you can communicate it to the users. How do you expect the users to know all the beeps and whistles? Not a best way to tell the users HOW TO do things in Geronimo than by having a good documentation. How much of your time it would actually take to write up a page describing a component or module and how to use it? It's you writing the code, why not you writing about that code and how to use it!? There are tons of questions on the user@ and dev@ lists about how to perform basic (and some times not so basic) tasks and configurations, we get these all the time. This is a clear sign that we need to improve the way we document the things. For 2.1 the situation is even worse, we pretty much don't have any documentation and we can't continue developing documentation the way we've been doing in the past. The way it looks now, Geronimo 2.1 won't have supporting documentation. Let's discuss here what areas need to be covered and who can work on documenting them. It is your turn now. Hernan, I hear your pain. And totally agree that good docs will make things much easier for our users (as well as ourselves). I know I'm as guilty (perhaps more so) as anyone else at failing to help pitch in. Everybody's pretty busy. Also, there's a definite tendency for skilled developers to be, well, skilled *developers*. Perhaps there are some alternate ways to help this process go faster? I wonder if it would be easier for people to discuss a particular topic with you on a phone call? Hopefully providing enough information for you to transform into flowery prose and lucid illustrations? If we want, we could make this a conference call (so interested parties could join). I don't think this technique can work for all docs. We can't expect you to write everything. However, it might help kickstart the process in some critical sections... --kevan If folks think that something like this could work - I would be happy to chip in as a typist. I took a look at the shell for the documentation and realized that I know far too little to be able to write the docs from scratch. Plus, it would be useful for me to be able to get more familiar with everything. Jay
Re: svn commit: r615397 - /geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java
David,
It appears that this change causes an error (NPE) when the old, longer
names are used. We get a NPE because options.get(SERVER_URI_KEY)
returns null and therefore causes the URI.create() to fail. Would
something like this be better?
String serverURIshort = (String) options.get(SERVER_URI_KEY);
if (serverURIshort == null) {
serverURI = URI.create((String)
options.get(SERVER_URI_KEY_LONG));
}
else {
serverURI = URI.create((String) options.get(SERVER_URI_KEY));
}
Thanks,
Joe
[EMAIL PROTECTED] wrote:
Author: djencks
Date: Fri Jan 25 15:28:58 2008
New Revision: 615397
URL: http://svn.apache.org/viewvc?rev=615397view=rev
Log:
GERONIMO-3744 Shorten option names in OpenEjbRemoteLoginModule. Preserver the
long ones too
Modified:
geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java
Modified:
geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java?rev=615397r1=615396r2=615397view=diff
==
---
geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java
(original)
+++
geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java
Fri Jan 25 15:28:58 2008
@@ -58,9 +58,12 @@
public class OpenejbRemoteLoginModule implements LoginModule {
private static Log log = LogFactory.getLog(OpenejbRemoteLoginModule.class);
-private static final String SECURITY_REALM_KEY = org.apache.geronimo.openejb.OpenejbRemoteLoginModule.RemoteSecurityRealm;
-private static final String SERVER_URI_KEY =
org.apache.geronimo.openejb.OpenejbRemoteLoginModule.ServerURI;
-public final static ListString supportedOptions =
Collections.unmodifiableList(Arrays.asList(SECURITY_REALM_KEY, SERVER_URI_KEY));
+
+private static final String SECURITY_REALM_KEY = RemoteSecurityRealm;
+private static final String SECURITY_REALM_KEY_LONG =
OpenejbRemoteLoginModule.class.getName() + . + SECURITY_REALM_KEY;
+private static final String SERVER_URI_KEY = ServerURI;
+private static final String SERVER_URI_KEY_LONG =
OpenejbRemoteLoginModule.class.getName() + . + SERVER_URI_KEY;
+public final static ListString supportedOptions =
Collections.unmodifiableList(Arrays.asList(SECURITY_REALM_KEY, SERVER_URI_KEY,
SECURITY_REALM_KEY_LONG, SERVER_URI_KEY_LONG));
private Subject subject;
private CallbackHandler callbackHandler;
@@ -79,7 +82,13 @@
}
}
securityRealm = (String) options.get(SECURITY_REALM_KEY);
+if (securityRealm == null) {
+securityRealm = (String) options.get(SECURITY_REALM_KEY_LONG);
+}
serverURI = URI.create((String) options.get(SERVER_URI_KEY));
+if (serverURI == null) {
+serverURI = URI.create((String) options.get(SERVER_URI_KEY_LONG));
+}
}
public boolean login() throws LoginException {
[jira] Resolved: (GERONIMO-3518) UnsupportedClassVersionError: Bad version number in .class file causes Install New Applications to hang
[ https://issues.apache.org/jira/browse/GERONIMO-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3518. --- Resolution: Fixed Fix Version/s: 2.1 2.0.x Assignee: Jarek Gawor I think this problem has been addressed by GERONIMO-3767 and I'm unable to replicate this problem with latest code. UnsupportedClassVersionError: Bad version number in .class file causes Install New Applications to hang - Key: GERONIMO-3518 URL: https://issues.apache.org/jira/browse/GERONIMO-3518 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: Jacek Laskowski Assignee: Jarek Gawor Fix For: 2.0.x, 2.1 I built a webapp with Java 6 whereas Geronimo run on Java 5. During deployment from the web console Geronimo threw exception ICVE, but the console kept waiting for the server response. java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:308) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:260) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:422) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.geronimo.jaxws.builder.WARWebServiceFinder.discoverPOJOWebServices(WARWebServiceFinder.java:109) at org.apache.geronimo.jaxws.builder.WARWebServiceFinder.discoverWebServices(WARWebServiceFinder.java:58) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.discoverWebServices(JAXWSServiceBuilder.java:97) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder.findWebServices(JAXWSServiceBuilder.java:80) at org.apache.geronimo.jaxws.builder.JAXWSServiceBuilder$$FastClassByCGLIB$$5b2252ff.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$3420fdf8.findWebServices(generated) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.basicInitContext(AbstractWebModuleBuilder.java:353) at org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.initContext(JettyModuleBuilder.java:322) at org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.invoke(generated) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo v2.1 documentation
Hey BJ, I think the newer the better :D We need to capture all the questions you are having about Geronimo as a new user and merge them with the other questions we see from the user's list and feed it back into the table of contents. Being a new user gives you a perspective that sometimes we may overlook. I'll initiate a separate thread to discuss the topics to cover. Everybody pls chime into that thread for content discussion. Cheers! Hernan B.J. Reed wrote: Jay D. McHugh wrote: Kevan Miller wrote: On Jan 25, 2008, at 11:22 AM, Hernan Cunico wrote: Guys, I've been trying to get your attention around Geronimo 2.1 documentation since October last year. Apache Geronimo is as good as you can communicate it to the users. How do you expect the users to know all the beeps and whistles? Not a best way to tell the users HOW TO do things in Geronimo than by having a good documentation. How much of your time it would actually take to write up a page describing a component or module and how to use it? It's you writing the code, why not you writing about that code and how to use it!? There are tons of questions on the user@ and dev@ lists about how to perform basic (and some times not so basic) tasks and configurations, we get these all the time. This is a clear sign that we need to improve the way we document the things. For 2.1 the situation is even worse, we pretty much don't have any documentation and we can't continue developing documentation the way we've been doing in the past. The way it looks now, Geronimo 2.1 won't have supporting documentation. Let's discuss here what areas need to be covered and who can work on documenting them. It is your turn now. Hernan, I hear your pain. And totally agree that good docs will make things much easier for our users (as well as ourselves). I know I'm as guilty (perhaps more so) as anyone else at failing to help pitch in. Everybody's pretty busy. Also, there's a definite tendency for skilled developers to be, well, skilled *developers*. Perhaps there are some alternate ways to help this process go faster? I wonder if it would be easier for people to discuss a particular topic with you on a phone call? Hopefully providing enough information for you to transform into flowery prose and lucid illustrations? If we want, we could make this a conference call (so interested parties could join). I don't think this technique can work for all docs. We can't expect you to write everything. However, it might help kickstart the process in some critical sections... --kevan If folks think that something like this could work - I would be happy to chip in as a typist. I took a look at the shell for the documentation and realized that I know far too little to be able to write the docs from scratch. Plus, it would be useful for me to be able to get more familiar with everything. Jay Hernan, Since I'm very new to Geronimo development, this would probably be a good place for me to get involved and see how things really work. Just let me know what I can help you out with. -- B.J.
RE: How to change KeyStore type?
Vamsi, Thanks a lot for the patch! I'm voting for getting the change into the nearest release, as it allows Geronimo to run on Harmony and maybe other VMs - current release can't do that, and adding this feature is a good bonus to Geronimo flexibility and compatibility. Thanks, Vasily From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED] Sent: Monday, January 28, 2008 4:23 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? Here is an essence of the fix that went in to trunk (2.1): o Allow creation of all possible keystore types supported. Keystore type is no longer restricted to JKS. o Added a type parameter to create keystore methods. o Keystores portlet will now allow creating and managing all types of keystores. o This revision will simplify the configuration changes required to run G on a JVM that does not support JKS keystores (for e.g., Harmony). o Allow selecting any keystore type supported by the JVM in Tomcat HTTPS Connector pages. As this feature required some interface changes, for e.g. KeystoreManager, KeystoreInstance etc., I would like to hear from others on considering this for branches\2.0 as it may break compatibility. ++Vamsi On Jan 21, 2008 11:21 PM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Vamsi, Thanks for the detailed analysis. The problem indeed looks non-trivial. Step 1. This looks pretty simple, and I'm now creating a patch for that. This change seems very important to me, how about getting it to v2.0.3/2.1? Step 2. This change also seems very important, but less critical than the first one, and it requires essential interface changes, so I tend to agree it certainly should wait till 2.1 or later. As of pitfalls, they seem unavoidable. Sure we want compatibility, but any compatibility has its limits. I suppose that changing JDK under a particular running installation of Geronimo is not a feature in great demand, and in a rare case when such a change would be necessary, a keystore conversion could be done manually (e.g. JKS-PKCS12 conversion can be done in Sun, PKCS12-BKS conversion can be done in Harmony etc.) Vasily From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED] Sent: Monday, January 21, 2008 8:23 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? Providing a keystoreType attribute does not seem to be a big deal. But, if the Keystores portlet has to allow creating all types of keystores, it gets really messy. Here is one more observation. IBMJDK does not allow storing an empty PKCS12 keystore to disk. This prevents creating an empty PKCS12 keystore and then adding which ever keys and certificates the user wants to. Here is the approach I want to take. Step 1. Provide a keystoreType attribute in FileKeystoreInstance. Step 2. Update KeyStores portlet to allow creation of all keystore types that the JDK allows to store an empty keystore to disk. Step 1 will allow the users to replace a keystore file of one type with that of another type, change the keystoreType in config.xml and get the server running. Step 2 will allow users to manage all keystore types using Keystores portlet and there is no hard-coding of any keystoreType except for geronimo-default keystore which is JKS. Now to some pitfalls. 1. If keystore type other than JKS is in use, the user may not be able to switch JDK's for reasons like PKCS12 keystore created using IBMJDK are not readble using SUNJDK. 2. Though IBMJDK does not allow creating an empty PKCS12 (and a few other types) keystore as a starting point for managing a PKCS12 keystore, the users can always add a PKCS12 keystore to var/security/keystores and the gbean definition to config.xml. This will make the keystore manageable through KeyStores portlet as long as the keystore is not empty. This will require a change in org.apache.geronimo.management.geronimo.KeystoreManager interface, etc. I doubt if we can consider this change for branches\2.0. Comments? ++Vamsi On Jan 18, 2008 1:37 AM, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Yes, sure, I fully agree. I've filed GERONIMO-3757 for this issue and now thinking of the patch to the trunk that would provide the necessary customization - unless any objections arise. As of GERONIMO-2015, I think we may close it, as there're objective reasons (stated there by Vamsavardhana Reddy) to not move from JKS on Sun. Vasily -Original Message- From: Alexey Petrenko [mailto: [EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 1:37 PM To: dev@geronimo.apache.org Subject: Re: How to change KeyStore type? I think we should add PKCS12 to Geronimo. If we afraid of possible incompatibilities and not full support of JKS or PKCS12 why not to let user choose what keystore to use? We can specify keystore in configs or choose type from available on current VM. SY, Alexey 2008/1/15, Zakharov, Vasily M [EMAIL
[jira] Commented: (GERONIMO-3783) MessageDrivenBean delivery problem
[ https://issues.apache.org/jira/browse/GERONIMO-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563159#action_12563159 ] Kevan Miller commented on GERONIMO-3783: Hi Tomasz, the pool size attributes settable on ThreadPool are: minPoolSize maxPoolSize MessageDrivenBean delivery problem -- Key: GERONIMO-3783 URL: https://issues.apache.org/jira/browse/GERONIMO-3783 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.1 Environment: Windows XP Professional, 2GB ram, Java6SE, Geronimo 2.1-snapshot (2008-01-02) Reporter: Tomasz Mazan Priority: Critical Attachments: mdb-issue.zip MessageDrivenBean that listens on the Queue receive (and process) some messages and then stop receiving any new message until next module's restart. After restart a few next messages are delivered to MDB, and it stops again. Some additional information I put here http://www.nabble.com/Strange-plug-with-delivering-messages-to-MDB-td14923100s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3783) MessageDrivenBean delivery problem
[ https://issues.apache.org/jira/browse/GERONIMO-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563154#action_12563154 ] Tomasz Mazan commented on GERONIMO-3783: Nonetheless exception above Setting maxSessions == maxMessagesPerSessions could avoid stop in processing messages MessageDrivenBean delivery problem -- Key: GERONIMO-3783 URL: https://issues.apache.org/jira/browse/GERONIMO-3783 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.1 Environment: Windows XP Professional, 2GB ram, Java6SE, Geronimo 2.1-snapshot (2008-01-02) Reporter: Tomasz Mazan Priority: Critical Attachments: mdb-issue.zip MessageDrivenBean that listens on the Queue receive (and process) some messages and then stop receiving any new message until next module's restart. After restart a few next messages are delivered to MDB, and it stops again. Some additional information I put here http://www.nabble.com/Strange-plug-with-delivering-messages-to-MDB-td14923100s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3796) Upgrade to 3.3 version of xbean-finder, xbean-naming, and xbean-reflect
Upgrade to 3.3 version of xbean-finder, xbean-naming, and xbean-reflect --- Key: GERONIMO-3796 URL: https://issues.apache.org/jira/browse/GERONIMO-3796 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 2.1 Reporter: Joe Bohn Assignee: Joe Bohn To eliminate snapshots and get on a consistent xbean delivery we need to upgrade xbean-finder, xbean-naming, and xbean-reflect to the 3.3 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3789) ConfigurationUtil ERROR log when executing gsh command
[ https://issues.apache.org/jira/browse/GERONIMO-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3789. --- Resolution: Fixed Fix committed in revision 615985. Moved the code in ConfigurationUtil to figure out the bootDirectory from a static block to a separate function so that it is initialized/called only when necessary. ConfigurationUtil ERROR log when executing gsh command -- Key: GERONIMO-3789 URL: https://issues.apache.org/jira/browse/GERONIMO-3789 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.1 When executing the following command: 'gsh deploy/list-modules', I received the following log ERROR message: coltrane:bin kevan$ ./gsh deploy/list-modules Apache Geronimo (2.1-SNAPSHOT) Type 'help' for more information. -- Connecting to Geronimo server: localhost:1099 Username: system Password: *** 18:42:21,866 ERROR [ConfigurationUtil] Cound not determine the installation directory of Apache Geronimo, because the startup jar could not be found in the current class loader. Connection established Found 84 modules + org.apache.geronimo.configs/activemq-broker/2.1-SNAPSHOT/car -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSSION] Geronimo v2.1 documentation - Content
Hernan, I have been working on the monitoring documentation, once finished with that, I can take up the J2G as well if you would like Thanks, Erik B. Craig [EMAIL PROTECTED] On Jan 28, 2008, at 10:48 AM, Hernan Cunico wrote: Hi All, these are some of the topics I think we should cover for the 2.1 documentation. It is not a full list so we need your help to make it as complete as possible. Pls chime in with the topics you would like to see addressed in the documentation. * What's new in 2.1? ** New features ** Component versions ** Configuration changes ** Backwards compatibility * Geronimo architecture ** GBeans ** Subprojects ** Components *** Distributions ** Repositories ** Configuration ** Customize the server * Installation ** Planning ** Binary ** Source ** Configuration *** Ports interaction *** Repositories *** Logging *** Security * Deployment ** What changed? ** New deployment options *** Command line - standard *** Command line - GShell *** Plugins *** Console Deployment plan wizard * Geronimo Administration Console ** What changed? ** Console enhancements ** The pluggable console ** Expert mode ** Deployment plans wizard ** CA helper * GShell ** What is it? ** Benefits ** What it does/replaces ** Tools and commands ** How-to samples * Monitoring ** What is it? ** What can I monitor ** Impact on the server workload? ** Install ** Customization * Pluggable console ** What is it? ** Benefits ** Architecture ** Install/deploy ** Customization ** Developing new portlets * Plugin infrastructure ** What are the plugins? ** Enhancements from previous releases ** Plugin infrastructure/architecture ** plugin.xml ** Plugins install ** Pluggable console ** GShell commands option * Security ** Enhancements ** Planning ** Configuration * Tooling ** Devtools *** Geronimo eclipse plugin ** j2g * Clustering * Sample applications * Tutorials Now that you see this list we also need your help to *develop* some of these topics. Pls chime in. Cheers! Hernan
[jira] Created: (GERONIMO-3795) Upgrade to MyFaces 1.2.2 release
Upgrade to MyFaces 1.2.2 release Key: GERONIMO-3795 URL: https://issues.apache.org/jira/browse/GERONIMO-3795 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Affects Versions: 2.1 Reporter: Joe Bohn Assignee: Joe Bohn MyFaces just released 1.2.2 that fixes a number of issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (YOKO-417) Simplify class hierarchies in org.apache.yoko.orb.OB (remove operations, helper and holder classes)
Simplify class hierarchies in org.apache.yoko.orb.OB (remove operations, helper and holder classes) --- Key: YOKO-417 URL: https://issues.apache.org/jira/browse/YOKO-417 Project: Yoko - CORBA Server Issue Type: Improvement Security Level: public (Regular issues) Components: orb core Reporter: Lars Kühne Assignee: Lars Kühne Fix For: v1.1.0 See yoko-dev dicussion in http://mail-archives.apache.org/mod_mbox/incubator-yoko-dev/200707.mbox/[EMAIL PROTECTED]: Core bits of the ORB code appear to have been once generated from IDL, but are no longer. These classes follow the IDL generated conventions of having operations classes, helpers, holders, etc., even though these classes are only used internally within the ORB and are never accessed as CORBA objects. The org.apache.yoko.orb.OB package has a lot of these, for example. The code is there, and follows the conventions used with idl-generated classes. The original IDL is no longer available, which makes enhancing some of these classes a royal pain to deal with. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3797) The plugin 'org.apache.geronimo.buildsupport:car-maven-plugin' does not exist or no valid version could be found in samples subproject
The plugin 'org.apache.geronimo.buildsupport:car-maven-plugin' does not exist or no valid version could be found in samples subproject -- Key: GERONIMO-3797 URL: https://issues.apache.org/jira/browse/GERONIMO-3797 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: car-maven-plugin, sample apps Affects Versions: 2.1 Reporter: Jacek Laskowski Checked out the latest samples sources. [EMAIL PROTECTED] /cygdrive/c/oss/geronimo-samples $ svn up ... Updated to revision 616023. Upon building them, the following error has been thrown: [EMAIL PROTECTED] /cygdrive/c/oss/geronimo-samples $ mvn clean install ... [INFO] artifact org.apache.geronimo.buildsupport:car-maven-plugin: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.geronimo.buildsupport:car-maven-plugin' does not exist or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 18 seconds [INFO] Finished at: Mon Jan 28 21:44:11 CET 2008 [INFO] Final Memory: 7M/254M [INFO] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[DISCUSSION] Geronimo v2.1 documentation - Content
Hi All, these are some of the topics I think we should cover for the 2.1 documentation. It is not a full list so we need your help to make it as complete as possible. Pls chime in with the topics you would like to see addressed in the documentation. * What's new in 2.1? ** New features ** Component versions ** Configuration changes ** Backwards compatibility * Geronimo architecture ** GBeans ** Subprojects ** Components *** Distributions ** Repositories ** Configuration ** Customize the server * Installation ** Planning ** Binary ** Source ** Configuration *** Ports interaction *** Repositories *** Logging *** Security * Deployment ** What changed? ** New deployment options *** Command line - standard *** Command line - GShell *** Plugins *** Console Deployment plan wizard * Geronimo Administration Console ** What changed? ** Console enhancements ** The pluggable console ** Expert mode ** Deployment plans wizard ** CA helper * GShell ** What is it? ** Benefits ** What it does/replaces ** Tools and commands ** How-to samples * Monitoring ** What is it? ** What can I monitor ** Impact on the server workload? ** Install ** Customization * Pluggable console ** What is it? ** Benefits ** Architecture ** Install/deploy ** Customization ** Developing new portlets * Plugin infrastructure ** What are the plugins? ** Enhancements from previous releases ** Plugin infrastructure/architecture ** plugin.xml ** Plugins install ** Pluggable console ** GShell commands option * Security ** Enhancements ** Planning ** Configuration * Tooling ** Devtools *** Geronimo eclipse plugin ** j2g * Clustering * Sample applications * Tutorials Now that you see this list we also need your help to *develop* some of these topics. Pls chime in. Cheers! Hernan
[jira] Resolved: (GERONIMO-3792) Requesting result from a @WebService fails with NoClassDefFoundError using CXF
[ https://issues.apache.org/jira/browse/GERONIMO-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3792. --- Resolution: Won't Fix Fix Version/s: 2.1 2.0.x Assignee: Jarek Gawor This is a known issue with Sun's SAAJ implementation. Thanks to Daniel for listing the work-arounds. I also updated Geronimo documentation with this information: http://cwiki.apache.org/confluence/display/GMOxDOC20/Configure+JAX-WS+engine Requesting result from a @WebService fails with NoClassDefFoundError using CXF -- Key: GERONIMO-3792 URL: https://issues.apache.org/jira/browse/GERONIMO-3792 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.2, 2.0.x Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+CXF Reporter: Cedric Hurst Assignee: Jarek Gawor Fix For: 2.0.x, 2.1 Attachments: geronimo.log, HelloWorldServiceEAR.ear I'm attempting to create a very simple Hello World web service using CXF as the JAX-WS provider. Whenever I make a call to the web service, I get the following error in the server log: 20:01:15,906 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.NoClassDefFoundError: com.sun.org.apache.xerces.internal.dom.DocumentImpl at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:228) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:308) at java.security.AccessController.doPrivileged(AccessController.java:275) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:260) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:422) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:573) at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.init(SOAPPartImpl.java:88) at com.sun.xml.messaging.saaj.soap.ver1_1.Message1_1Impl.getSOAPPart(Message1_1Impl.java:78) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:85) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:63) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73) at org.apache.geronimo.cxf.GeronimoDestination.invoke(GeronimoDestination.java:115) at org.apache.geronimo.cxf.CXFWebServiceContainer.processPOST(CXFWebServiceContainer.java:107) at org.apache.geronimo.cxf.CXFWebServiceContainer.invoke(CXFWebServiceContainer.java:83) at org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.invoke(TomcatEJBWebServiceContext.java:180) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 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:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:801) I will attach both the EAR and geronimo.log. I've tested against both the latest 2.0.3-SNAPSHOT and the TCK-certified build for jee5-2.0-M6-rc1. Also, I don't seem to encounter this problem when using Axis2 as the JAX-WS provider. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3797) The plugin 'org.apache.geronimo.buildsupport:car-maven-plugin' does not exist or no valid version could be found in samples subproject
[ https://issues.apache.org/jira/browse/GERONIMO-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563298#action_12563298 ] Jason Dillon commented on GERONIMO-3797: The samples top-level pom probably does not configure a pluginManagement element for the car-maven-plugin, it should... and it should set the version to 2.1-SNAPSHOT. The plugin 'org.apache.geronimo.buildsupport:car-maven-plugin' does not exist or no valid version could be found in samples subproject -- Key: GERONIMO-3797 URL: https://issues.apache.org/jira/browse/GERONIMO-3797 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: car-maven-plugin, sample apps Affects Versions: 2.1 Reporter: Jacek Laskowski Checked out the latest samples sources. [EMAIL PROTECTED] /cygdrive/c/oss/geronimo-samples $ svn up ... Updated to revision 616023. Upon building them, the following error has been thrown: [EMAIL PROTECTED] /cygdrive/c/oss/geronimo-samples $ mvn clean install ... [INFO] artifact org.apache.geronimo.buildsupport:car-maven-plugin: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.geronimo.buildsupport:car-maven-plugin' does not exist or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 18 seconds [INFO] Finished at: Mon Jan 28 21:44:11 CET 2008 [INFO] Final Memory: 7M/254M [INFO] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3795) Upgrade to MyFaces 1.2.2 release
[ https://issues.apache.org/jira/browse/GERONIMO-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn resolved GERONIMO-3795. Resolution: Fixed Fix Version/s: 2.1 Upgrade to MyFaces 1.2.2 release Key: GERONIMO-3795 URL: https://issues.apache.org/jira/browse/GERONIMO-3795 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1 MyFaces just released 1.2.2 that fixes a number of issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3787) Deployment on Minimal Assemblies fails complaining of a missing yoko dependency
[ https://issues.apache.org/jira/browse/GERONIMO-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn reassigned GERONIMO-3787: -- Assignee: Joe Bohn Deployment on Minimal Assemblies fails complaining of a missing yoko dependency --- Key: GERONIMO-3787 URL: https://issues.apache.org/jira/browse/GERONIMO-3787 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Reporter: Joe Bohn Assignee: Joe Bohn I started the tomcat minimal assembly and attempted to deploy a simple web application. I hit the following error: tetra:~/g-images/trunk/geronimo-tomcat6-minimal-2.1-SNAPSHOT/bin bohn$ ./deploy.sh deploy ~/ServerApplications/snoop.war Using GERONIMO_BASE: /Users/bohn/g-images/trunk/geronimo-tomcat6-minimal-2.1-SNAPSHOT Using GERONIMO_HOME: /Users/bohn/g-images/trunk/geronimo-tomcat6-minimal-2.1-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/Home org.apache.geronimo.kernel.config.LifecycleException: load of default/snoop/1201271106727/war failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:299) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:280) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:255) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1410) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1350) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784) 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:613) Caused by:
Deployment broken on minimal assemblies
I discovered last Friday that deployment is broken on the Minimal Assemblies. (see https://issues.apache.org/jira/browse/GERONIMO-3787) Attempting to deploy a simple web app that contains just a jsp (with or without a deployment plan) we hit an error that there is a missing dependency: Missing dependency: org.apache.geronimo.configs/j2ee-corba-yoko//car Does this mean that we have a DefaultEnvironment setting or something similar someplace that is attempting to add j2ee-corba-yoko as a dependency to every web app being deployed? Aside from the specs, I don't believe that we should include anything from yoko in the minimal assemblies. Looking at the config.xml for the server it appears this is getting included via the connector-deployer config and its ResourceRefBuilder GBean's EnvironmentBuilder. Looking at the connector-deployer pom it appears this defaultEnvironment has been for a long time, so I don't know why it should start to cause a problem now. The only relatively recent change I see http://svn.apache.org/viewvc?rev=603109view=rev . Is it possible this had an impact on the minimal deployments such that they now require a require this car to be available whereas it was optional before? Any pointers? Joe
[jira] Updated: (YOKO-417) Simplify class hierarchies in org.apache.yoko.orb.OB (remove operations, helper and holder classes)
[ https://issues.apache.org/jira/browse/YOKO-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Kühne updated YOKO-417: Description: See yoko-dev dicussion in http://mail-archives.apache.org/mod_mbox/incubator-yoko-dev/200707.mbox/[EMAIL PROTECTED] Core bits of the ORB code appear to have been once generated from IDL, but are no longer. These classes follow the IDL generated conventions of having operations classes, helpers, holders, etc., even though these classes are only used internally within the ORB and are never accessed as CORBA objects. The org.apache.yoko.orb.OB package has a lot of these, for example. The code is there, and follows the conventions used with idl-generated classes. The original IDL is no longer available, which makes enhancing some of these classes a royal pain to deal with. was: See yoko-dev dicussion in http://mail-archives.apache.org/mod_mbox/incubator-yoko-dev/200707.mbox/[EMAIL PROTECTED]: Core bits of the ORB code appear to have been once generated from IDL, but are no longer. These classes follow the IDL generated conventions of having operations classes, helpers, holders, etc., even though these classes are only used internally within the ORB and are never accessed as CORBA objects. The org.apache.yoko.orb.OB package has a lot of these, for example. The code is there, and follows the conventions used with idl-generated classes. The original IDL is no longer available, which makes enhancing some of these classes a royal pain to deal with. Simplify class hierarchies in org.apache.yoko.orb.OB (remove operations, helper and holder classes) --- Key: YOKO-417 URL: https://issues.apache.org/jira/browse/YOKO-417 Project: Yoko - CORBA Server Issue Type: Improvement Security Level: public(Regular issues) Components: orb core Reporter: Lars Kühne Assignee: Lars Kühne Fix For: v1.1.0 See yoko-dev dicussion in http://mail-archives.apache.org/mod_mbox/incubator-yoko-dev/200707.mbox/[EMAIL PROTECTED] Core bits of the ORB code appear to have been once generated from IDL, but are no longer. These classes follow the IDL generated conventions of having operations classes, helpers, holders, etc., even though these classes are only used internally within the ORB and are never accessed as CORBA objects. The org.apache.yoko.orb.OB package has a lot of these, for example. The code is there, and follows the conventions used with idl-generated classes. The original IDL is no longer available, which makes enhancing some of these classes a royal pain to deal with. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r615397 - /geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java
Joe Bohn wrote:
David,
It appears that this change causes an error (NPE) when the old, longer
names are used. We get a NPE because options.get(SERVER_URI_KEY)
returns null and therefore causes the URI.create() to fail. Would
something like this be better?
String serverURIshort = (String) options.get(SERVER_URI_KEY);
if (serverURIshort == null) {
serverURI = URI.create((String)
options.get(SERVER_URI_KEY_LONG));
}
else {
serverURI = URI.create((String) options.get(SERVER_URI_KEY));
}
I went ahead and checked in this change since this was causing some
problems running the TCK.
http://svn.apache.org/viewvc?rev=616098view=rev
Please correct if necessary.
Thanks,
Joe
[EMAIL PROTECTED] wrote:
Author: djencks
Date: Fri Jan 25 15:28:58 2008
New Revision: 615397
URL: http://svn.apache.org/viewvc?rev=615397view=rev
Log:
GERONIMO-3744 Shorten option names in OpenEjbRemoteLoginModule.
Preserver the long ones too
Modified:
geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java
Modified:
geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java?rev=615397r1=615396r2=615397view=diff
==
---
geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java
(original)
+++
geronimo/server/trunk/plugins/openejb/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenejbRemoteLoginModule.java
Fri Jan 25 15:28:58 2008
@@ -58,9 +58,12 @@
public class OpenejbRemoteLoginModule implements LoginModule {
private static Log log =
LogFactory.getLog(OpenejbRemoteLoginModule.class);
-private static final String SECURITY_REALM_KEY =
org.apache.geronimo.openejb.OpenejbRemoteLoginModule.RemoteSecurityRealm;
-private static final String SERVER_URI_KEY =
org.apache.geronimo.openejb.OpenejbRemoteLoginModule.ServerURI;
-public final static ListString supportedOptions =
Collections.unmodifiableList(Arrays.asList(SECURITY_REALM_KEY,
SERVER_URI_KEY));
+
+private static final String SECURITY_REALM_KEY =
RemoteSecurityRealm;
+private static final String SECURITY_REALM_KEY_LONG =
OpenejbRemoteLoginModule.class.getName() + . + SECURITY_REALM_KEY;
+private static final String SERVER_URI_KEY = ServerURI;
+private static final String SERVER_URI_KEY_LONG =
OpenejbRemoteLoginModule.class.getName() + . + SERVER_URI_KEY;
+public final static ListString supportedOptions =
Collections.unmodifiableList(Arrays.asList(SECURITY_REALM_KEY,
SERVER_URI_KEY, SECURITY_REALM_KEY_LONG, SERVER_URI_KEY_LONG));
private Subject subject;
private CallbackHandler callbackHandler;
@@ -79,7 +82,13 @@
}
}
securityRealm = (String) options.get(SECURITY_REALM_KEY);
+if (securityRealm == null) {
+securityRealm = (String)
options.get(SECURITY_REALM_KEY_LONG);
+}
serverURI = URI.create((String) options.get(SERVER_URI_KEY));
+if (serverURI == null) {
+serverURI = URI.create((String)
options.get(SERVER_URI_KEY_LONG));
+}
}
public boolean login() throws LoginException {
[jira] Closed: (GERONIMO-3797) The plugin 'org.apache.geronimo.buildsupport:car-maven-plugin' does not exist or no valid version could be found in samples subproject
[ https://issues.apache.org/jira/browse/GERONIMO-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Laskowski closed GERONIMO-3797. - Resolution: Fixed Fix Version/s: 2.1 Assignee: Jarek Gawor With Jarek's help and his fix - svn commit: r616064 - /geronimo/samples/trunk/samples/pom.xml - samples built fine. The plugin 'org.apache.geronimo.buildsupport:car-maven-plugin' does not exist or no valid version could be found in samples subproject -- Key: GERONIMO-3797 URL: https://issues.apache.org/jira/browse/GERONIMO-3797 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: car-maven-plugin, sample apps Affects Versions: 2.1 Reporter: Jacek Laskowski Assignee: Jarek Gawor Fix For: 2.1 Checked out the latest samples sources. [EMAIL PROTECTED] /cygdrive/c/oss/geronimo-samples $ svn up ... Updated to revision 616023. Upon building them, the following error has been thrown: [EMAIL PROTECTED] /cygdrive/c/oss/geronimo-samples $ mvn clean install ... [INFO] artifact org.apache.geronimo.buildsupport:car-maven-plugin: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.geronimo.buildsupport:car-maven-plugin' does not exist or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 18 seconds [INFO] Finished at: Mon Jan 28 21:44:11 CET 2008 [INFO] Final Memory: 7M/254M [INFO] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3789) ConfigurationUtil ERROR log when executing gsh command
[ https://issues.apache.org/jira/browse/GERONIMO-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor reassigned GERONIMO-3789: - Assignee: Jarek Gawor ConfigurationUtil ERROR log when executing gsh command -- Key: GERONIMO-3789 URL: https://issues.apache.org/jira/browse/GERONIMO-3789 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Kevan Miller Assignee: Jarek Gawor Fix For: 2.1 When executing the following command: 'gsh deploy/list-modules', I received the following log ERROR message: coltrane:bin kevan$ ./gsh deploy/list-modules Apache Geronimo (2.1-SNAPSHOT) Type 'help' for more information. -- Connecting to Geronimo server: localhost:1099 Username: system Password: *** 18:42:21,866 ERROR [ConfigurationUtil] Cound not determine the installation directory of Apache Geronimo, because the startup jar could not be found in the current class loader. Connection established Found 84 modules + org.apache.geronimo.configs/activemq-broker/2.1-SNAPSHOT/car -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3661) Optimize GShell libs for G server assemblies
[ https://issues.apache.org/jira/browse/GERONIMO-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-3661: --- Affects Version/s: 2.1 Fix Version/s: (was: 2.1) 2.1.1 Optimize GShell libs for G server assemblies Key: GERONIMO-3661 URL: https://issues.apache.org/jira/browse/GERONIMO-3661 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Jason Dillon Assignee: Jason Dillon Priority: Blocker Fix For: 2.1.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3651) gshell should make it dead simple to run geronimo with remote debugging
[ https://issues.apache.org/jira/browse/GERONIMO-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-3651: --- Fix Version/s: (was: 2.1) 2.1.1 gshell should make it dead simple to run geronimo with remote debugging --- Key: GERONIMO-3651 URL: https://issues.apache.org/jira/browse/GERONIMO-3651 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1 Reporter: David Jencks Assignee: Jason Dillon Priority: Blocker Fix For: 2.1.1 we need some options for start-server so g. starts up with debugging. I think we should be able to set the port and suspend as persistent options in the environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3709) multiple wadi WARN messages during server start
[ https://issues.apache.org/jira/browse/GERONIMO-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-3709. -- Resolution: Invalid Problem has been fixed. Not sure when or by whom multiple wadi WARN messages during server start --- Key: GERONIMO-3709 URL: https://issues.apache.org/jira/browse/GERONIMO-3709 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1 Reporter: Kevan Miller Fix For: 2.1 I'm seeing lots of WARNING messages from WADI during server start. The messages really look like info messages to me. I've also seen warning messages and exception stack traces during shutdown. We need to get things quieted down... Here's a sample: bash-3.2$ ./geronimo.sh run --long Using GERONIMO_BASE: /Users/kevan/geronimo/server/trunk/target/geronimo-jetty6-javaee5-2.1-SNAPSHOT Using GERONIMO_HOME: /Users/kevan/geronimo/server/trunk/target/geronimo-jetty6-javaee5-2.1-SNAPSHOT Using GERONIMO_TMPDIR: var/temp Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home 09:27:57,977 WARN [AbstractGBeanReference] GBean references are not using proxies Booting Geronimo Kernel (in Java 1.5.0_13)... Module 1/59 org.apache.geronimo.configs/ca-helper-jetty/2.1-SNAPSHOT/car started in 1.715s Module 2/59 org.apache.geronimo.configs/jasper/2.1-SNAPSHOT/car started in .000s Module 3/59 org.apache.geronimo.configs/j2ee-server/2.1-SNAPSHOT/car started in .000s Module 4/59 org.apache.geronimo.configs/rmi-naming/2.1-SNAPSHOT/car started in .000s Module 5/59 org.apache.geronimo.configs/j2ee-system/2.1-SNAPSHOT/car started in .000s Module 6/59 org.apache.geronimo.configs/jee-specs/2.1-SNAPSHOT/car started in .000s Module 7/59 org.apache.geronimo.configs/server-security-config/2.1-SNAPSHOT/car started in .000s Module 8/59 org.apache.geronimo.configs/j2ee-security/2.1-SNAPSHOT/car started in .000s Module 9/59 org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car started in .000s Module 10/59 org.apache.geronimo.configs/myfaces-deployer/2.1-SNAPSHOT/car started in .627s Module 11/59 org.apache.geronimo.configs/myfaces/2.1-SNAPSHOT/car started in .007s Module 12/59 org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car started in .000s Module 13/59 org.apache.geronimo.configs/geronimo-gbean-deployer/2.1-SNAPSHOT/car started in .000s Module 14/59 org.apache.geronimo.configs/xmlbeans/2.1-SNAPSHOT/car started in .000s Module 15/59 org.apache.geronimo.configs/activemq-ra/2.1-SNAPSHOT/car started in 3.145s Module 16/59 org.apache.geronimo.configs/activemq-broker/2.1-SNAPSHOT/car started in .001s Module 17/59 org.apache.geronimo.configs/system-database/2.1-SNAPSHOT/car started in .000s Module 18/59 org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car started in .090s Module 19/59 org.apache.geronimo.configs/jasper-deployer/2.1-SNAPSHOT/car started in .016s Module 20/59 org.apache.geronimo.configs/jetty6-deployer/2.1-SNAPSHOT/car started in .101s Module 21/59 org.apache.geronimo.configs/jetty6/2.1-SNAPSHOT/car started in .000s Module 22/59 org.apache.geronimo.configs/clustering/2.1-SNAPSHOT/car started in .074s Module 23/59 org.apache.geronimo.configs/webservices-common/2.1-SNAPSHOT/car started in .000s Module 24/59 org.apache.geronimo.configs/jaxws-ejb-deployer/2.1-SNAPSHOT/car started in .090s Module 25/59 org.apache.geronimo.configs/jaxws-deployer/2.1-SNAPSHOT/car started in .000s Module 26/59 org.apache.geronimo.configs/openejb-deployer/2.1-SNAPSHOT/car started in .000s Module 27/59 org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car started in .575s Module 28/59 org.apache.geronimo.configs/openjpa/2.1-SNAPSHOT/car started in .000s Module 29/59 org.apache.geronimo.configs/axis2/2.1-SNAPSHOT/car started in .000s Module 30/59 org.apache.geronimo.configs/axis2-ejb/2.1-SNAPSHOT/car started in .000s Module 31/59 org.apache.geronimo.plugins/system-database-jetty/2.1-SNAPSHOT/car started in 4.422s Module 32/59 org.apache.geronimo.plugins/console-jetty/2.1-SNAPSHOT/car
