Corba app client error
Hi, I'm trying to invoke an EJB with an application client using CORBA. However, when I invoke my client I'm getting a very perplexing exception which I've not seen before. Does anyone have any idea what might be causing this ?? It seems to somehow relate to the system-database which I'm not even using. Thanks for any assistance. Tim C:\TEMP\TRUNK\geronimo-tomcat6-jee5-2.0-SNAPSHOT>java -Djava.endorsed.dirs=lib/endorsed -jar bin\client.jar org.apache.geronimo.samples/corba-hello-world-client/2.0-SNAPSHOT/car 02:18:39,734 INFO [CommandLine] Client startup begun 02:18:45,140 ERROR [MCFConnectionInterceptor] Error occurred creating ManagedConnection for [EMAIL PROTECTED] javax.resource.spi.ResourceAdapterInternalException: Unable to obtain physical connection to [EMAIL PROTECTED] at org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnection(AbstractXADataSourceMCF.java:76) at org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection(EmbeddedXAMCF.java:52) at org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getConnection(MCFConnectionInterceptor.java:48) at org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor.getConnection(XAResourceInsertionInterceptor.java:41) at org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor.internalGetConnection(SinglePoolConnectionInterceptor.java:66) at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78) at org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.getConnection(TransactionEnlistingInterceptor.java:46) at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.getConnection(TransactionCachingInterceptor.java:95) at org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getConnection(ConnectionHandleInterceptor.java:43) at org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCCLInterceptor.java:39) at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.getConnection(ConnectionTrackingInterceptor.java:66) at org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:61) at org.tranql.connector.jdbc.DataSource.getConnection(DataSource.java:56) at $javax.sql.DataSource$$FastClassByCGLIB$$6525cafd.invoke() at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149) at org.apache.geronimo.connector.ConnectorMethodInterceptor.intercept(ConnectorMethodInterceptor.java:54) at $javax.sql.DataSource$$EnhancerByCGLIB$$de67a1d6.getConnection() at org.apache.geronimo.timer.jdbc.JDBCWorkerPersistence.execSQL(JDBCWorkerPersistence.java:315) at org.apache.geronimo.timer.jdbc.JDBCWorkerPersistence.(JDBCWorkerPersistence.java:68) at org.apache.geronimo.timer.jdbc.JDBCStoreThreadPooledNonTransactionalTimer.(JDBCStoreThreadPooledNonTransactionalTimer.java:44) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:529) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.run
[jira] Updated: (GERONIMODEVTOOLS-146) Server won't start nicely due to missing setting of java.endorsed.dirs for Yoko
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Kirby updated GERONIMODEVTOOLS-146:
---
Attachment: GD146.patch
Added code to set java.endorsed.dirs in vmArgs
> Server won't start nicely due to missing setting of java.endorsed.dirs for
> Yoko
> ---
>
> Key: GERONIMODEVTOOLS-146
> URL:
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-146
> Project: Geronimo-Devtools
> Issue Type: Bug
> Components: eclipse-plugin
>Affects Versions: 2.0
>Reporter: Ted Kirby
>Priority: Critical
> Attachments: GD146.patch
>
>
> Here are console messages:
> Booting Geronimo Kernel (in Java 1.5.0)...
> 17:03:26,609 ERROR [NameService] Incorrect level of org.omg.CORBA classes
> found.
> Likely cause is an incorrect java.endorsed.dirs configuration
> 17:03:26,609 ERROR [GBeanInstanceState] Error while starting; GBean is now in
> the FAILED state:
> abstractName="org.apache.geronimo.configs/j2ee-corba-yoko/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-corba-yoko/2.0-SNAPSHOT/car,j2eeType=CORBANameService,name=NameServer"
> org.apache.geronimo.gbean.InvalidConfigurationException: CORBA usage requires
> Yoko CORBA spec classes in java.endorsed.dirs classpath
> at org.apache.geronimo.corba.NameService.doStart(NameService.java:168)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:986)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> Need to set
> -Djava.endorsed.dirs="%GERONIMO_BASE%\lib\endorsed;%JRE_HOME%\lib\endorsed",
> like in geronimo.{sh,bat}
> If I set this manually as a server VM argument for the server instance, the
> server starts fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3164) Axis2: support bindingtype overwrite from wsdl to annotation
[ https://issues.apache.org/jira/browse/GERONIMO-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-3164: -- Attachment: G3164.patch Will test a bit more on the patch on Monday before commit it... I tried different approaches before coming up with this patch - 1) tried to use what Axis2 uses to get bindingtype from serviceDescription, but that didn't work as the validation failed during the creation of createServiceDescriptionFromDBCMap. And serviceDescriptionImpl's constructor is not public so I cannot create my own serviceDescription in geronimo. 2) Tried to use getType from AxisBinding which can be obtained from AxisService, but that shows the transporturi not really the bindingtype I need. 3) Tried to see how Axis2 set the bindingtype from wsdl when there is no binding specified in annotation and find out it just defaults to the default binding type which is SOAP11HTTP_BINDING. Lin > Axis2: support bindingtype overwrite from wsdl to annotation > > > Key: GERONIMO-3164 > URL: https://issues.apache.org/jira/browse/GERONIMO-3164 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 2.0-M6 > Environment: Win XP + Sun 1.5 SDK >Reporter: Lin Sun > Assigned To: Lin Sun > Fix For: 2.0-M6 > > Attachments: G3164.patch > > > If a user has a jax-ws module that has different bindingtype in wsdl and > webservice annotation, the deployment of the module would fail but it doesn't > pass the axis2 validation - > The service J2EEApplication= did not start because Throwable during > start of gbean: > java.lang.RuntimeException: javax.xml.ws.WebServiceException: The > ServiceDescription failed to validate due to the following errors: > :: Endpoint failed validation :: :: Invalid binding; wsdl = > http://schemas.xmlsoap.org/wsdl/soap/, annotation = > http://www.w3.org/2004/08/wsdl/http -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3142) Geronimo / Jetty fails to startup under Sun Java 1.6 update 1
[ https://issues.apache.org/jira/browse/GERONIMO-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-3142. Resolution: Fixed Fix Version/s: 2.0-M6 Committed revision 539676 in trunk. Applied the patch from Toby and verified that the Tomcat JEE5 assembly built with Sun 1.5.0_11 starts with both the Sun 1.5.0_11 and Sun 1.6.0_01 JDKs. Toby, thanks for the patch. > Geronimo / Jetty fails to startup under Sun Java 1.6 update 1 > - > > Key: GERONIMO-3142 > URL: https://issues.apache.org/jira/browse/GERONIMO-3142 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: JVM-compatibility >Affects Versions: 1.1.1, 1.2 > Environment: CentOS 5 (~RHEL 5), Java 1.6 update 1 >Reporter: Nikla Ratinen > Assigned To: Donald Woods > Fix For: 2.0-M6 > > Attachments: geronimo.log, geronimo.out, j6-patch-classloader.txt > > > Vanilla Geronimo / Jetty 1.1.1 and 1.2-beta fail to start under JDK 1.6 > update 1. JDK 1.5 seems to work though. > Logs show ClassNotFoundException resolving key manager: > ... > Caused by: java.lang.ClassNotFoundException: [Ljavax.net.ssl.KeyManager; in > classloader org.apache.geronimo.configs/jetty/1.2-beta/car > at > org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:298) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:310) > ... 53 more > An easy way to disable SSL entirely would fix this for me ;) > I'll attach relevant logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3142) Geronimo / Jetty fails to startup under Sun Java 1.6 update 1
[ https://issues.apache.org/jira/browse/GERONIMO-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3142: -- Assignee: Donald Woods > Geronimo / Jetty fails to startup under Sun Java 1.6 update 1 > - > > Key: GERONIMO-3142 > URL: https://issues.apache.org/jira/browse/GERONIMO-3142 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: JVM-compatibility >Affects Versions: 1.1.1, 1.2 > Environment: CentOS 5 (~RHEL 5), Java 1.6 update 1 >Reporter: Nikla Ratinen > Assigned To: Donald Woods > Attachments: geronimo.log, geronimo.out, j6-patch-classloader.txt > > > Vanilla Geronimo / Jetty 1.1.1 and 1.2-beta fail to start under JDK 1.6 > update 1. JDK 1.5 seems to work though. > Logs show ClassNotFoundException resolving key manager: > ... > Caused by: java.lang.ClassNotFoundException: [Ljavax.net.ssl.KeyManager; in > classloader org.apache.geronimo.configs/jetty/1.2-beta/car > at > org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:298) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:310) > ... 53 more > An easy way to disable SSL entirely would fix this for me ;) > I'll attach relevant logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: turn on/off restriction of WARs programmatically
On May 18, 2007, at 7:03 AM, Олег Тимофеев wrote: I'm going to code a Geronimo system module which is a realization of SAML Service Provide(for POJO web-services). I need manage processing requests to user-WARs.In other words sys admin must have a possibility to turn on/off restriction of WARs. When admin to turn on restriction of WARs I must process queries to a server. I can't set global request handler, because my SAML CAR must be deploy and undeploy from console without manual changes in config files. To process queries to a server I intend to use servlet filters. When admin turn on/off restriction of WARs my ConsoleGBean will add a servlet filter programmatically. I imagine that you want to be able to turn things on and off without redeploying the wars? If so I think you need to install a filter in all wars and have the filter delegate to something like the console gbean you speak of (if it's present). I believe for tomcat you can do this by adding a filter to the "default" web.xml with the appropriate filter mapping. For jetty at the moment there's no way to add a default filter mapping. The filter could be set up as a default filter, but the mapping for it would have to be added to every web.xml "by hand". It is probably easy to uncomment the default filter mapping code in JettyModuleBuilder and make it work, but right now it isn't working. Could you please advise on how can I programmatically add a servlet filter using Geronimo WebModule GBean? I don't think this is possible. I recently learned about jsr-196, jaspi, and suspect from my very limited understanding of what it's for and what SAML is that SAML support could be implemented through that spec. Do you know anything about this? Would you be interested in working on implementing JSR-196 or (if SAML support would really fit with that) SAML through jaspi? thanks, and if you can share details of what you come up with that would be great! david jencks
[jira] Created: (GERONIMODEVTOOLS-146) Server won't start nicely due to missing setting of java.endorsed.dirs for Yoko
Server won't start nicely due to missing setting of java.endorsed.dirs for Yoko
---
Key: GERONIMODEVTOOLS-146
URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-146
Project: Geronimo-Devtools
Issue Type: Bug
Components: eclipse-plugin
Affects Versions: 2.0
Reporter: Ted Kirby
Priority: Critical
Here are console messages:
Booting Geronimo Kernel (in Java 1.5.0)...
17:03:26,609 ERROR [NameService] Incorrect level of org.omg.CORBA classes found.
Likely cause is an incorrect java.endorsed.dirs configuration
17:03:26,609 ERROR [GBeanInstanceState] Error while starting; GBean is now in
the FAILED state:
abstractName="org.apache.geronimo.configs/j2ee-corba-yoko/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-corba-yoko/2.0-SNAPSHOT/car,j2eeType=CORBANameService,name=NameServer"
org.apache.geronimo.gbean.InvalidConfigurationException: CORBA usage requires
Yoko CORBA spec classes in java.endorsed.dirs classpath
at org.apache.geronimo.corba.NameService.doStart(NameService.java:168)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:986)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
Need to set
-Djava.endorsed.dirs="%GERONIMO_BASE%\lib\endorsed;%JRE_HOME%\lib\endorsed",
like in geronimo.{sh,bat}
If I set this manually as a server VM argument for the server instance, the
server starts fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3174) Can't start server with eclipse plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby updated GERONIMO-3174: Attachment: G3174.patch I just needed to add a dependency of geronimo-kernel on geronimo-cli. I took code from Daemon and bent it to my will... Passing an object as a parameter is a bit dangerous/promiscuous! With the attached patch, I was able to start the server from the eclipse plugin. > Can't start server with eclipse plugin > -- > > Key: GERONIMO-3174 > URL: https://issues.apache.org/jira/browse/GERONIMO-3174 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: eclipse-plugin >Affects Versions: 2.0-M6 >Reporter: Ted Kirby >Priority: Critical > Fix For: 2.0-M6 > > Attachments: G3174.patch > > > I am using rev 539255. When I start the server, I get: > Exception in thread "main" java.lang.IllegalArgumentException: Argument type > is [class [Ljava.lang.String;]; expected [class > org.apache.geronimo.cli.daemon.DaemonCLParser] > at > org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:56) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:33) > It looks like this code-path was missed in recent CLI refactoring, which > occurred after last eclipse plugin update. > I tried having the eclise plugin start org.apache.geronimo.system.main.Daemon > instead of org.apache.geronimo.kernel.util.MainConfigurationBootstrapper, but > the server never seemed to come up. > My next attempt will be to fix MainConfigurationBootstrapper.main(String[] > args) like Daemon.main(String[] args), tho I am not sure that have > geronimo-kernel depend on geronimo-system will work or is proper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3142) Geronimo / Jetty fails to startup under Sun Java 1.6 update 1
[ https://issues.apache.org/jira/browse/GERONIMO-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3142: - Description: Vanilla Geronimo / Jetty 1.1.1 and 1.2-beta fail to start under JDK 1.6 update 1. JDK 1.5 seems to work though. Logs show ClassNotFoundException resolving key manager: ... Caused by: java.lang.ClassNotFoundException: [Ljavax.net.ssl.KeyManager; in classloader org.apache.geronimo.configs/jetty/1.2-beta/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:298) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:310) ... 53 more An easy way to disable SSL entirely would fix this for me ;) I'll attach relevant logs. was: Vanilla Geronimo / Jetty 1.1.1 and 1.2-beta fail to start under JDK 1.6 update 1. JDK 1.5 seems to work though. Logs show ClassNotFoundException resolving key manager: ... Caused by: java.lang.ClassNotFoundException: [Ljavax.net.ssl.KeyManager; in classloader org.apache.geronimo.configs/jetty/1.2-beta/car at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:298) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:310) ... 53 more An easy way to disable SSL entirely would fix this for me ;) I'll attach relevant logs. Patch Info: [Patch Available] > Geronimo / Jetty fails to startup under Sun Java 1.6 update 1 > - > > Key: GERONIMO-3142 > URL: https://issues.apache.org/jira/browse/GERONIMO-3142 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: JVM-compatibility >Affects Versions: 1.1.1, 1.2 > Environment: CentOS 5 (~RHEL 5), Java 1.6 update 1 >Reporter: Nikla Ratinen > Attachments: geronimo.log, geronimo.out, j6-patch-classloader.txt > > > Vanilla Geronimo / Jetty 1.1.1 and 1.2-beta fail to start under JDK 1.6 > update 1. JDK 1.5 seems to work though. > Logs show ClassNotFoundException resolving key manager: > ... > Caused by: java.lang.ClassNotFoundException: [Ljavax.net.ssl.KeyManager; in > classloader org.apache.geronimo.configs/jetty/1.2-beta/car > at > org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:298) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:310) > ... 53 more > An easy way to disable SSL entirely would fix this for me ;) > I'll attach relevant logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3142) Geronimo / Jetty fails to startup under Sun Java 1.6 update 1
[ https://issues.apache.org/jira/browse/GERONIMO-3142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] toby cabot updated GERONIMO-3142: - Attachment: j6-patch-classloader.txt This bug appears to be caused by a change in the behavior of ClassLoader.loadClass(). It used to accept array syntax but the version in 1.6 doesn't. I trolled Sun's bug tracker and saw some comments to the effect that it was never considered to be a documented feature and didn't always work, but it always worked for me until Java 1.6. Oh well. In any case, a couple of the comments suggested using Class.forName() instead, so I tried that and it seems to work for 1.5 and 1.6. Will probably work for 1.4 also but I haven't tried it since I'm working on the trunk for now. If anyone cares I can try the same fix on a branch. For background, see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446627 - Reading Serialized arrays of objects throws ClassNotFoundException - one of the comments suggests using the 3-argument Class.forName() instead. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6516909 - Clarify that ClassLoader.loadClass() is not meant to be used for array classes http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6249970 - clarification needed: binary name of array type in ClassLoader.loadClass http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4976356 - S1AS 7 calling ClassLoader.loadClass with array syntax > Geronimo / Jetty fails to startup under Sun Java 1.6 update 1 > - > > Key: GERONIMO-3142 > URL: https://issues.apache.org/jira/browse/GERONIMO-3142 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: JVM-compatibility >Affects Versions: 1.1.1, 1.2 > Environment: CentOS 5 (~RHEL 5), Java 1.6 update 1 >Reporter: Nikla Ratinen > Attachments: geronimo.log, geronimo.out, j6-patch-classloader.txt > > > Vanilla Geronimo / Jetty 1.1.1 and 1.2-beta fail to start under JDK 1.6 > update 1. JDK 1.5 seems to work though. > Logs show ClassNotFoundException resolving key manager: > ... > Caused by: java.lang.ClassNotFoundException: [Ljavax.net.ssl.KeyManager; in > classloader org.apache.geronimo.configs/jetty/1.2-beta/car > at > org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:298) > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > at > org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLServerFactory(FileKeystoreManager.java:310) > ... 53 more > An easy way to disable SSL entirely would fix this for me ;) > I'll attach relevant logs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3174) Can't start server with eclipse plugin
[ https://issues.apache.org/jira/browse/GERONIMO-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497017 ] Hernan Cunico commented on GERONIMO-3174: - Although not with eclipse, I was jut getting pretty much the same error on M5. Doesn't make any sense to me but it got fixed by placing the server.jar at the very beginning of the classpath while still using org.apache.geronimo.cli.daemon.DaemonCLI to start the server. > Can't start server with eclipse plugin > -- > > Key: GERONIMO-3174 > URL: https://issues.apache.org/jira/browse/GERONIMO-3174 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: eclipse-plugin >Affects Versions: 2.0-M6 >Reporter: Ted Kirby >Priority: Critical > Fix For: 2.0-M6 > > > I am using rev 539255. When I start the server, I get: > Exception in thread "main" java.lang.IllegalArgumentException: Argument type > is [class [Ljava.lang.String;]; expected [class > org.apache.geronimo.cli.daemon.DaemonCLParser] > at > org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:56) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) > at > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:33) > It looks like this code-path was missed in recent CLI refactoring, which > occurred after last eclipse plugin update. > I tried having the eclise plugin start org.apache.geronimo.system.main.Daemon > instead of org.apache.geronimo.kernel.util.MainConfigurationBootstrapper, but > the server never seemed to come up. > My next attempt will be to fix MainConfigurationBootstrapper.main(String[] > args) like Daemon.main(String[] args), tho I am not sure that have > geronimo-kernel depend on geronimo-system will work or is proper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3174) Can't start server with eclipse plugin
Can't start server with eclipse plugin -- Key: GERONIMO-3174 URL: https://issues.apache.org/jira/browse/GERONIMO-3174 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: eclipse-plugin Affects Versions: 2.0-M6 Reporter: Ted Kirby Priority: Critical Fix For: 2.0-M6 I am using rev 539255. When I start the server, I get: Exception in thread "main" java.lang.IllegalArgumentException: Argument type is [class [Ljava.lang.String;]; expected [class org.apache.geronimo.cli.daemon.DaemonCLParser] at org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:56) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:33) It looks like this code-path was missed in recent CLI refactoring, which occurred after last eclipse plugin update. I tried having the eclise plugin start org.apache.geronimo.system.main.Daemon instead of org.apache.geronimo.kernel.util.MainConfigurationBootstrapper, but the server never seemed to come up. My next attempt will be to fix MainConfigurationBootstrapper.main(String[] args) like Daemon.main(String[] args), tho I am not sure that have geronimo-kernel depend on geronimo-system will work or is proper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
turn on/off restriction of WARs programmatically
I'm going to code a Geronimo system module which is a realization of SAML Service Provide(for POJO web-services). I need manage processing requests to user-WARs.In other words sys admin must have a possibility to turn on/off restriction of WARs. When admin to turn on restriction of WARs I must process queries to a server. I can't set global request handler, because my SAML CAR must be deploy and undeploy from console without manual changes in config files. To process queries to a server I intend to use servlet filters. When admin turn on/off restriction of WARs my ConsoleGBean will add a servlet filter programmatically. Could you please advise on how can I programmatically add a servlet filter using Geronimo WebModule GBean?
[jira] Updated: (GERONIMO-348) Invalid module path or references in plan should result in failed deployment or warning
[ https://issues.apache.org/jira/browse/GERONIMO-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-348: -- Assignee: Rakesh Midha (was: Donald Woods) Changed throw() to just be a log.warn(), due to problems discovered during TCK. Committed revision 539548 in trunk. Rakesh, please reopen this issue if you develop a new patch that doesn't break any TCK tests. > Invalid module path or references in plan should result in failed deployment > or warning > --- > > Key: GERONIMO-348 > URL: https://issues.apache.org/jira/browse/GERONIMO-348 > Project: Geronimo > Issue Type: Bug > Components: deployment >Affects Versions: 1.x, 2.0-M6 >Reporter: Jeremy Boynes > Assigned To: Rakesh Midha >Priority: Critical > Fix For: 2.0-M6 > > Attachments: G348.patch, noref348.patch > > > If an EAR deployment plan contains a entry for a module but the path does not > match that of a module in the application.xml then an error or warning should > be issued at deployment time. > A likely reason for this is that a developer copied the plan from another but > forgot to change the uri entry for the submodule; or it could just be a > simple typo. In either way, the plan won't match the intended module from the > application.xml resulting in erroroneous behaviour. > (added) > In addition, elements in a plan that do not correspond to elements in the > deployment descriptor should result in a warning or error. Examples would be > an ejb listed in the openejb plan that does not correspond to an ejb in the > ejb-jar.xml, or a resource-ref in the ejb that does not correspond to a > resource-ref in the ejb-jar.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GERONIMO-348 patch and issues with ejb deployments
Thanks for catching this. Done in revision 539548. -Donald Jarek Gawor wrote: In my case that would be SwitchingServiceRefBuilder.java. But I think the same problem could happen in other builders too. I'm +1 for log.warn() change. Jarek On 5/18/07, Donald Woods <[EMAIL PROTECTED]> wrote: Which changed file is throwing the exception? ResourceRefBuilder.java? We can turn the throw() into a log.warn() for now, until this EJB case is fixed -Donald Jarek Gawor wrote: > Recently the GERONIMO-348 patch was committed. That is causing > problems with EJB deployments. Here's an example. > > ejb-xml.jar has 2 ejbs, and one of the ejbs has a service-ref entry: > > > > > > > > > > The G plan has corresponding entries for the beans and one service-ref > overwrite. > > Now, during deployment and in case of ejbs the > moduleBuilder.buildNaming() function is called once per each bean. The > specDD parameter will point only the given bean's xml data but the > planDD parameter will always point to the entire G plan. That means > when buildNaming() is called for the second bean and even though it > has no service-refs, one service-ref overwrite will be discovered in > the G plan. And with the GERONIMO-348 patch the deployment will fail. > > So it seems like the ejb deployment processing needs to change to pass > only the relevant parts of the particular ejb as the planDD. I'm just > not sure if there is any code that relies on having the entire G plan > around... > > Jarek > > smime.p7s Description: S/MIME Cryptographic Signature
Re: GERONIMO-348 patch and issues with ejb deployments
On May 18, 2007, at 10:42 AM, Jarek Gawor wrote: In my case that would be SwitchingServiceRefBuilder.java. But I think the same problem could happen in other builders too. I'm +1 for log.warn() change. I'm good with that... Donald, Can you make this happen? --kevan
[jira] Commented: (GERONIMO-2966) [Code donation] Web2 Plugins
[ https://issues.apache.org/jira/browse/GERONIMO-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496905 ] Paul McMahan commented on GERONIMO-2966: I agree that these plugins could use some rework. Viet posted on dev about these plugins, I suggest that he extract the contents of the original webapps from the plugins and redeploy them into geronimo to create new plugins. Also at some point it would be good to switch the build process for these plugins to maven2 and use the car-maven-plugin as Donald suggested. The servlet-examples and ldap-demo plugins are good examples in server/trunk are good examples of how this can be done. > [Code donation] Web2 Plugins > > > Key: GERONIMO-2966 > URL: https://issues.apache.org/jira/browse/GERONIMO-2966 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) >Affects Versions: 1.1.x > Environment: MS Windows XP SP2 (although Java based should work on > any OS supporting Java) >Reporter: Jeffrey Faelnar >Priority: Minor > Fix For: 1.1.x > > Attachments: IBM-Web20Plugins-CCLA.pdf, web2-plugins-0.1.1.zip > > > IBM has developed a set of Web2.0 plugins for Apache Geronimo. The first > two, the DOJO plug-in and the JSON-RPC-Java plug-in, will supply Geronimo > with client and server side support of AJAX technology. Developers will > create Web applications where the client side is implemented with the help of > a DOJO library and makes JSON-RPC calls to the server side business logic > exposed as a coarse-grained façade JavaBean. To add DOJO library support > developers need to make their applications dependent on the DOJO plug-in and > similarly to handle JSON-RPC calls using JSON-RPC-Java library developers > need to make the applications dependent on the JSON-RPC plug-in. > The remaining Feeds plug-in will allow developers to easily create RSS 1.0, > RSS 2.0 and ATOM 1.0 syndication feeds. The plug-in will be used in one of > two ways. Developers will implement feeds so that they are accessed through > the Feeds plug-in acting as an already deployed Web module. In addition, > developers can implement feeds as separately deployed Web applications that > use some functionality of the Feeds plug-in. > Attached are the plugins and IBM's CCLA. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GERONIMO-348 patch and issues with ejb deployments
In my case that would be SwitchingServiceRefBuilder.java. But I think the same problem could happen in other builders too. I'm +1 for log.warn() change. Jarek On 5/18/07, Donald Woods <[EMAIL PROTECTED]> wrote: Which changed file is throwing the exception? ResourceRefBuilder.java? We can turn the throw() into a log.warn() for now, until this EJB case is fixed -Donald Jarek Gawor wrote: > Recently the GERONIMO-348 patch was committed. That is causing > problems with EJB deployments. Here's an example. > > ejb-xml.jar has 2 ejbs, and one of the ejbs has a service-ref entry: > > > > > > > > > > The G plan has corresponding entries for the beans and one service-ref > overwrite. > > Now, during deployment and in case of ejbs the > moduleBuilder.buildNaming() function is called once per each bean. The > specDD parameter will point only the given bean's xml data but the > planDD parameter will always point to the entire G plan. That means > when buildNaming() is called for the second bean and even though it > has no service-refs, one service-ref overwrite will be discovered in > the G plan. And with the GERONIMO-348 patch the deployment will fail. > > So it seems like the ejb deployment processing needs to change to pass > only the relevant parts of the particular ejb as the planDD. I'm just > not sure if there is any code that relies on having the entire G plan > around... > > Jarek > >
Re: [VOTE] Release ServiceMix 3.1.1
Umm... the sources jars still don't have the LICENSE/DISCLAIMER/NOTICE files in them. The sigs look OK though. They validated fine. Dan On Friday 18 May 2007 10:13, Guillaume Nodet wrote: > I have uploaded a new release that should solve the last two problems. > I agree we will have to address the first one before next release. > I think due to this new upload, the vote period should be extended by > 24 hours. > > On 5/17/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > On Tuesday 15 May 2007 10:28, Guillaume Nodet wrote: > > > [ X ] -1 Do not release ServiceMix 3.1.1 > > > > > > I will upload a rat report asap. > > > > I figure I'll -1 this before it gets to [EMAIL PROTECTED] > > > > Issues: > > 1) Procedural: you published these into the release repository. > > Thus, they are already released. They should be staged into a > > staging area, voted on there, then if the vote passes, moved into > > the release repository. As it stands right now, it's technically > > already released without a vote. > > > > 2) The sources jars and javadoc jars don't have the disclaimer, > > notice, or license files in them. Thus, they are not releasable. > > (look into the remote-resources plugin, the cxf/trunk/parent pom is > > an example.) > > > > 3) Nothing has been gpg signed. All release artifacts must be gpg > > signed. A "release" profile with the gpg plugin would solve this. > > (you can use the cxf/trunk pom as an example) > > > > Anyway, IMO, it's not ready to go.If you have problems with the > > maven stuff, feel free to ping me. I'd be glad to help out. > > > > -- > > J. Daniel Kulp > > Principal Engineer > > IONA > > P: 781-902-8727C: 508-380-7194 > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
[jira] Created: (SM-953) Add meaningful exception when trying to send message exchange before endpoint activation
Add meaningful exception when trying to send message exchange before endpoint
activation
Key: SM-953
URL: https://issues.apache.org/activemq/browse/SM-953
Project: ServiceMix
Issue Type: Improvement
Components: servicemix-common
Reporter: Ben Pachol
Priority: Trivial
A message exchange in PollingEndpoint.java's Poll method cannot be sent because
the endpoint has yet to have been activated at that point. A meaningful
exception would help.
This example code is an endpoint class derived from PollingEndpoint that gives
a null pointer exception which isn't very meaningful.
public void poll() throws Exception
{
invokeIdentityService();
}
private boolean invokeIdentityService() throws MessagingException {
ComponentContext ctx =
getServiceUnit().getComponent().getComponentContext();
QName identityService = new
QName("http://servicemix.apache.org/servicemanagerassembly";,
"httpService");
InOut identityExchange = exchangeFactory.createInOutExchange();
configureTarget("Identity Service", identityExchange, ctx,
null, identityService, "soap", "");
NormalizedMessage in = identityExchange.createMessage();
in.setContent(new StringSource("Testing"));
identityExchange.setInMessage(in);
sendSync(identityExchange);
NormalizedMessage out = identityExchange.getOutMessage();
boolean login = false;
if (out != null) {
//login = support.parseIdentityOutMessage(out.getContent());
} else {
// TODO: how should we handle faults
}
done(identityExchange);
return login;
}
public void configureTarget(String serviceDesc, MessageExchange
exchange, ComponentContext context, QName _interface, QName service,
String endpoint, String uri) throws MessagingException {
if (_interface == null && service == null && uri == null) {
throw new MessagingException(serviceDesc + ": interface,
service or uri should be specified");
}
/*if (uri != null) {
URIResolver.configureExchange(exchange, context, uri);
}*/
if (_interface != null) {
exchange.setInterfaceName(_interface);
}
if (service != null) {
exchange.setService(service);
if (endpoint != null) {
ServiceEndpoint se = context.getEndpoint(service, endpoint);
exchange.setEndpoint(se);
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3171) java 1.6 compile fix for geronimo-naming mock DataSource class
[ https://issues.apache.org/jira/browse/GERONIMO-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496889 ] toby cabot commented on GERONIMO-3171: -- Donald, thanks for the lightning-fast response to this! At the moment I can build geronimo using 1.6 but haven't investigated running it. I see bug 3142 on this topic and I'll report anything else I find. > java 1.6 compile fix for geronimo-naming mock DataSource class > -- > > Key: GERONIMO-3171 > URL: https://issues.apache.org/jira/browse/GERONIMO-3171 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: naming >Affects Versions: 2.0-M6 > Environment: Java(TM) SE Runtime Environment (build 1.6.0_01-b06) > Fedora Core 4 >Reporter: toby cabot > Assigned To: Donald Woods >Priority: Trivial > Fix For: 2.0-M6 > > Attachments: j6-patch.txt > > > I was curious to see if Geronimo could build and/or run using java 1.6 so I > tried to build. There's a compile-time problem in one of the mock classes in > geronimo-naming caused by a change in 1.6's interfaces. > 1.5: http://java.sun.com/j2se/1.5.0/docs/api/javax/sql/DataSource.html > 1.6: http://java.sun.com/javase/6/docs/api/javax/sql/DataSource.html > I'll include a patch that adds the new required methods to the mock > DataSource. They seem to work fine in 1.5 also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2966) [Code donation] Web2 Plugins
[ https://issues.apache.org/jira/browse/GERONIMO-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496887 ] Donald Woods commented on GERONIMO-2966: This code doesn't look like a true Geronimo Plugin, given the org.apache.geronimo.plugins.car-maven-plugin is not used during the build, the filenames of *.car.zip and the fact that they are being individually deployed, whereas a real plugin would usually only have one CAR file to deploy and it would automatically pull in the prereqs it needs I think this contribution needs major rework for Geronimo 2.0 to: 1) make it a true Geronimo Plugin which is built with the car-maven-plugin 2) use the existing dojo CAR in the Tomcat and Jetty JEE5 assemblies > [Code donation] Web2 Plugins > > > Key: GERONIMO-2966 > URL: https://issues.apache.org/jira/browse/GERONIMO-2966 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) >Affects Versions: 1.1.x > Environment: MS Windows XP SP2 (although Java based should work on > any OS supporting Java) >Reporter: Jeffrey Faelnar >Priority: Minor > Fix For: 1.1.x > > Attachments: IBM-Web20Plugins-CCLA.pdf, web2-plugins-0.1.1.zip > > > IBM has developed a set of Web2.0 plugins for Apache Geronimo. The first > two, the DOJO plug-in and the JSON-RPC-Java plug-in, will supply Geronimo > with client and server side support of AJAX technology. Developers will > create Web applications where the client side is implemented with the help of > a DOJO library and makes JSON-RPC calls to the server side business logic > exposed as a coarse-grained façade JavaBean. To add DOJO library support > developers need to make their applications dependent on the DOJO plug-in and > similarly to handle JSON-RPC calls using JSON-RPC-Java library developers > need to make the applications dependent on the JSON-RPC plug-in. > The remaining Feeds plug-in will allow developers to easily create RSS 1.0, > RSS 2.0 and ATOM 1.0 syndication feeds. The plug-in will be used in one of > two ways. Developers will implement feeds so that they are accessed through > the Feeds plug-in acting as an already deployed Web module. In addition, > developers can implement feeds as separately deployed Web applications that > use some functionality of the Feeds plug-in. > Attached are the plugins and IBM's CCLA. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: web2 plugins for G v2.0 using tomcat
They are supplied and discovered at build time by the org.apache.geronimo.plugins.car-maven-plugin, which I can't find where its used in this contribution. In fact, this code doesn't look like a true Geronimo Plugin, given the filenames of *.car.zip and the fact that they are being individually deployed, whereas a real plugin would usually only have one CAR file to deploy and it would automatically pull in the prereqs it needs I think this contribution needs major rework for Geronimo 2.0 to make it a true Plugin and to use the existing dojo-tomcat CAR... -Donald Viet Hung Nguyen wrote: Donald, Where are the configuration names specified in the plugins? I cannot find them. -Viet - - >Donald wrote: > >The plugins need to be updated and rebuilt for Geronimo 2.0, as the >configuration names have changed. For example, the Tomcat config is currently >called - >org.apache.geronimo.configs/tomcat6/2.0-SNAPSHOT/car > >-Donald >>Viet Hung Nguyen wrote: >> I am working on the following JIRA. >> https://issues.apache.org/jira/browse/GERONIMO-2966 >> >> >> When I try to install the plugins with: >> >> ./install.sh /cygdrive/c/g/geronimo-tomcat6-jee5-2.00-SNAPSHOT >> >> I get the following error: >> Installation FAILED: Required configuration 'geronimo/tomcat//' is not installed. >> >> Using GERONIMO_BASE: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_HOME: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_TMPDIR: c:\.m2\web2-plugins-0.1.1\bin\var\temp >> Using JRE_HOME:c:\Program Files\Java\jdk1.5.0_11\jre >> Checking for status every 1000ms: >> Installation FAILED: Cannot install plugin org.apache.geronimo.plugins/ajax-dojo/0.1/car on Geronimo 2.0-SNAPSHOT >> >> Using GERONIMO_BASE: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_HOME: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_TMPDIR: c:\.m2\web2-plugins-0.1.1\bin\var\temp >> Using JRE_HOME:c:\Program Files\Java\jdk1.5.0_11\jre >> Checking for status every 1000ms: >> Installation FAILED: Cannot install plugin org.apache.geronimo.plugins/ajax-jsonrpc/0.1/car on Geronimo 2.0-SNAPSHOT >> >> Using GERONIMO_BASE: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_HOME: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_TMPDIR: c:\.m2\web2-plugins-0.1.1\bin\var\temp >> Using JRE_HOME:c:\Program Files\Java\jdk1.5.0_11\jre >> Error: Unable to distribute ajax-testapp-0.1.war: Unable to create >> configuration for deployment >> >> load of org.apache.geronimo.plugins/ajax-testapp/0.1/war failed >> >> Error starting configuration gbean >> org.apache.geronimo.plugins/ajax-testapp/0.1/war >> >> Unable to resolve dependency >> org.apache.geronimo.plugins/ajax-dojo/0.1/car >> >> Has anyone come across this problem? or have any suggestions? >> >> -Viet Nguyen smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] Release ServiceMix 3.1.1
I have uploaded a new release that should solve the last two problems. I agree we will have to address the first one before next release. I think due to this new upload, the vote period should be extended by 24 hours. On 5/17/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: On Tuesday 15 May 2007 10:28, Guillaume Nodet wrote: > [ X ] -1 Do not release ServiceMix 3.1.1 > > I will upload a rat report asap. I figure I'll -1 this before it gets to [EMAIL PROTECTED] Issues: 1) Procedural: you published these into the release repository. Thus, they are already released. They should be staged into a staging area, voted on there, then if the vote passes, moved into the release repository. As it stands right now, it's technically already released without a vote. 2) The sources jars and javadoc jars don't have the disclaimer, notice, or license files in them. Thus, they are not releasable. (look into the remote-resources plugin, the cxf/trunk/parent pom is an example.) 3) Nothing has been gpg signed. All release artifacts must be gpg signed. A "release" profile with the gpg plugin would solve this. (you can use the cxf/trunk pom as an example) Anyway, IMO, it's not ready to go.If you have problems with the maven stuff, feel free to ping me. I'd be glad to help out. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
Re: GERONIMO-348 patch and issues with ejb deployments
Which changed file is throwing the exception? ResourceRefBuilder.java? We can turn the throw() into a log.warn() for now, until this EJB case is fixed -Donald Jarek Gawor wrote: Recently the GERONIMO-348 patch was committed. That is causing problems with EJB deployments. Here's an example. ejb-xml.jar has 2 ejbs, and one of the ejbs has a service-ref entry: The G plan has corresponding entries for the beans and one service-ref overwrite. Now, during deployment and in case of ejbs the moduleBuilder.buildNaming() function is called once per each bean. The specDD parameter will point only the given bean's xml data but the planDD parameter will always point to the entire G plan. That means when buildNaming() is called for the second bean and even though it has no service-refs, one service-ref overwrite will be discovered in the G plan. And with the GERONIMO-348 patch the deployment will fail. So it seems like the ejb deployment processing needs to change to pass only the relevant parts of the particular ejb as the planDD. I'm just not sure if there is any code that relies on having the entire G plan around... Jarek smime.p7s Description: S/MIME Cryptographic Signature
Re: Re: web2 plugins for G v2.0 using tomcat
Donald, Where are the configuration names specified in the plugins? I cannot find them. -Viet - - >Donald wrote: > >The plugins need to be updated and rebuilt for Geronimo 2.0, as the >configuration names have changed. For example, the Tomcat config is currently >called - >org.apache.geronimo.configs/tomcat6/2.0-SNAPSHOT/car > >-Donald >>Viet Hung Nguyen wrote: >> I am working on the following JIRA. >> https://issues.apache.org/jira/browse/GERONIMO-2966 >> >> >> When I try to install the plugins with: >> >> ./install.sh /cygdrive/c/g/geronimo-tomcat6-jee5-2.00-SNAPSHOT >> >> I get the following error: >> Installation FAILED: Required configuration 'geronimo/tomcat//' is not installed. >> >> Using GERONIMO_BASE: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_HOME: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_TMPDIR: c:\.m2\web2-plugins-0.1.1\bin\var\temp >> Using JRE_HOME:c:\Program Files\Java\jdk1.5.0_11\jre >> Checking for status every 1000ms: >> Installation FAILED: Cannot install plugin org.apache.geronimo.plugins/ajax-dojo/0.1/car on Geronimo 2.0-SNAPSHOT >> >> Using GERONIMO_BASE: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_HOME: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_TMPDIR: c:\.m2\web2-plugins-0.1.1\bin\var\temp >> Using JRE_HOME:c:\Program Files\Java\jdk1.5.0_11\jre >> Checking for status every 1000ms: >> Installation FAILED: Cannot install plugin org.apache.geronimo.plugins/ajax-jsonrpc/0.1/car on Geronimo 2.0-SNAPSHOT >> >> Using GERONIMO_BASE: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_HOME: c:\g\geronimo-tomcat6-jee5-2.0-SNAPSHOT >> Using GERONIMO_TMPDIR: c:\.m2\web2-plugins-0.1.1\bin\var\temp >> Using JRE_HOME:c:\Program Files\Java\jdk1.5.0_11\jre >> Error: Unable to distribute ajax-testapp-0.1.war: Unable to create >> configuration for deployment >> >> load of org.apache.geronimo.plugins/ajax-testapp/0.1/war failed >> >> Error starting configuration gbean >> org.apache.geronimo.plugins/ajax-testapp/0.1/war >> >> Unable to resolve dependency >> org.apache.geronimo.plugins/ajax-dojo/0.1/car >> >> Has anyone come across this problem? or have any suggestions? >> >> -Viet Nguyen
