[jira] Updated: (GERONIMO-4375) rebind of "auto-bound" stuff in jca: context doesn't work
[
https://issues.apache.org/jira/browse/GERONIMO-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang updated GERONIMO-4375:
--
Attachment: xbean-115_for_3.3tag.patch
This is the patch to fix xbean-115 based on xbean 3.3. tag code.
> rebind of "auto-bound" stuff in jca: context doesn't work
> -
>
> Key: GERONIMO-4375
> URL: https://issues.apache.org/jira/browse/GERONIMO-4375
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: naming
>Affects Versions: 2.1.3, 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.1.4, 2.2
>
> Attachments: G4375_revert2ASM223.patch, GERONIMO-4375_21branch.patch,
> xbean-115_for_3.3tag.patch
>
>
> This works:
> InitialContext ctx = new InitialContext(contextEnv);
> Context fooCtx = ctx.createSubcontext("jca:foo");
> fooCtx.createSubcontext("bar");
> ctx.bind("jca:foo/bar/baz", 1);
> assertEquals(ctx.lookup("jca:foo/bar/baz"), 1);
> ctx.rebind("jca:foo/bar/baz", 2);
> assertEquals(ctx.lookup("jca:foo/bar/baz"), 2);
> this doesn't, where jca:/test/test/GBean/resourceSource is an datasource
> installed by the ResourceBinding GBean
> InitialContext ctx = new InitialContext(contextEnv);
> assertTrue(ctx.lookup("jca:/test/test/GBean/resourceSource")
> instanceof DataSource);
> ctx.rebind("jca:/test/test/GBean/resourceSource", 2);
> assertEquals(2, ctx.lookup("jca:/test/test/GBean/resourceSource"));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4375) rebind of "auto-bound" stuff in jca: context doesn't work
[
https://issues.apache.org/jira/browse/GERONIMO-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang updated GERONIMO-4375:
--
Attachment: G4375_revert2ASM223.patch
Because it's the xbean-naming 3.5 that depends on ASM 3.1, keep other xbean to
3.3 does not resolve thepotential compatibility after upgrading asm.
Here is the patch to revert asm to 2.2.3 and revert xbean to 3.3, which
requires pulling the XBEAN-115 fix to xbean 3.3 tag code to make a patched
xbean 3.3 manually.
I'll upload a xbean 3.3 based patch to XBEAN-115 in case someone needs to keep
the asm to 2.2.3 in geronimo 2.1.
> rebind of "auto-bound" stuff in jca: context doesn't work
> -
>
> Key: GERONIMO-4375
> URL: https://issues.apache.org/jira/browse/GERONIMO-4375
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: naming
>Affects Versions: 2.1.3, 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.1.4, 2.2
>
> Attachments: G4375_revert2ASM223.patch, GERONIMO-4375_21branch.patch
>
>
> This works:
> InitialContext ctx = new InitialContext(contextEnv);
> Context fooCtx = ctx.createSubcontext("jca:foo");
> fooCtx.createSubcontext("bar");
> ctx.bind("jca:foo/bar/baz", 1);
> assertEquals(ctx.lookup("jca:foo/bar/baz"), 1);
> ctx.rebind("jca:foo/bar/baz", 2);
> assertEquals(ctx.lookup("jca:foo/bar/baz"), 2);
> this doesn't, where jca:/test/test/GBean/resourceSource is an datasource
> installed by the ResourceBinding GBean
> InitialContext ctx = new InitialContext(contextEnv);
> assertTrue(ctx.lookup("jca:/test/test/GBean/resourceSource")
> instanceof DataSource);
> ctx.rebind("jca:/test/test/GBean/resourceSource", 2);
> assertEquals(2, ctx.lookup("jca:/test/test/GBean/resourceSource"));
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jetty-dev] Jetty Security refactoring for JASPI
Hi David, I'm still snatching time to tiptoe further around the jaspi branch. A couple of thoughts to run by you: 1. UserIdentity and LoginService classnames. These are quasi analogous to UserPrincipal and UserRealm (although the behaviour has been refactored). I'm wondering whether it might not be a good idea to retain the old classnames, just so it might be easier for jetty users/developers to ease into understanding the new security structures? 1a. Actually thinking about this, it will probably be quite important for Jetty users to be able to make a smooth transition over to a jaspi-based implementation. Do you think we can retain a UserRealm and a UserPrincipal with all their methods intact, but just "blend in" the jaspi-ness with some extra methods and some changed implementations of the existing apis? 2. We allow a UserRealm to be explicitly set on a WebAppContext (well, strictly speaking its WebAppContext.getSecurityHandler().setUserRealm(UserRealm)). I couldn't see specific support for that, only getting a list of LoginServices from the Server instance. Should be easy enough to put in though? 3. With the JAAS stuff, which has its own set of callbacks it uses to obtain info, we used a DefaultCallbackHandler to plug in the right info, such as credentials, passwords, usernames and also extra request parameters from the login. I notice you're using an anonymous CallbackHandler instead to pass into the JAAS LoginContext. Is it possible to use the DefaultCallbackHandler instead? It supports a couple more callback types that some LoginModule implementations may depend on. 4. Minor thing - is there a lot of value in the RunAsToken marker interface as opposed to just having a String? The roles and role mappings are themselves just Strings, so I was wondering what the utility is? best regards Jan David Jencks wrote: > > On Oct 16, 2008, at 11:59 PM, Jan Bartel wrote: > >> Hi David, >> >> Firstly, let me genuflect in recognition of your extraordinary efforts >> for a) reading the spec b) being able to make heads or tails of it c) >> coming up with an implementation based on it! > > :-D >> >> >> I'm surpressing the urge to have a bit of rant at yet another jcp spec >> that is at the same time heavy on the verbiage and light on >> comprehensibility. Your email was way more informative >> than what 29 people managed to produce in the spec. >> >> Anyway, looking at the code in the jetty-7-jaspi branch, and I admit >> that so far I've only just had a cursory nosey around, where would >> we integrate the JAAS side of things? Implement a JAASLoginService? > > see org.mortbay.jetty.plus.jaas in modules/plus/jetty-plus > Not sure if it is ideal, it's pretty much a simple modification of the > former JAASUserRealm > >> >> >> I'll have a deeper look at the code and get back to you with more >> informed comments. This mail is to re-assure you that your post >> hasn't fallen into the void and that we are looking forward to >> integrating this into jetty-7 trunk! > > The main thing to remember might be that the current implementations of > built-in security (FORM, BASIC, DIGEST etc) are in jaspi "modules" only > until we agree on the jetty api at which point I was thinking to convert > them back into more jetty specific code. Of course if you decide you > really like jaspi :-) >> >> >> Jan >> PS I love this code-comment in ServletCallbackHandler: >> >> * Idiot class required by jaspi stupidity @#*($)#@&^)[EMAIL PROTECTED]&*$@ > > Several parts of the jaspi spec look to me as if they are sort of stuck > on at the end when someone realized it was incomplete, and the heavy use > of CallbackHandler for two way communication between the jaspi modules > and the container strikes me as one such point. > > thanks > david jencks > >> >> >> :) >> >> David Jencks wrote: >>> Greg and Jan were kind enough to create a branch for me to play around >>> with a JASPI (Java Authentication Service Provider Interface) >>> integration with jetty and its getting to a point where I'm willing to >>> talk about it. >>> >>> Code is at https://svn.codehaus.org/jetty/jetty/branches/jetty-7-jaspi >>> >>> JASPI attempts to provide a uniform framework for messaging systems, >>> both client and server side, to plug in message authentication. On the >>> client you can add auth info to a request and validate auth info on a >>> response. On the server you can validate auth info on a request and add >>> auth info to a response. The auth code can conduct arbitrary message >>> exchanges to negotiate what info is needed and transmit the info. I've >>> been working on the server side auth for jetty. >>> >>> The actual spec jaspi interfaces are not 100% ideal for http and don't >>> allow stuff like lazy authentication for unsecured resources so I've >>> come up with interfaces similar in spirit to the jaspi ones. >>> >>> I've also tried to rework the implementation so it i
[jira] Commented: (GERONIMO-4384) Could load xbean factory when configure ActiveMQ brokerUri
[
https://issues.apache.org/jira/browse/GERONIMO-4384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643730#action_12643730
]
viola.lu commented on GERONIMO-4384:
It's the same as http://issues.apache.org/jira/browse/GERONIMO-3148, so you
mean ActiveMQ Security Function won't work in geronimo 2.2?
> Could load xbean factory when configure ActiveMQ brokerUri
> ---
>
> Key: GERONIMO-4384
> URL: https://issues.apache.org/jira/browse/GERONIMO-4384
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: ActiveMQ
>Affects Versions: 2.1.3
> Environment: Windows XP ,JDK 1.5.0
>Reporter: viola.lu
>
> 1.Edit config.xml udner $geronimo_instal_Dir/var/config as below:
>
>
> name="brokerUri">xbean:file:/path/to/activemq.xml
> possibly-unique-broker
> false
> var/activemq
>
>
> ${ServerHostname}
> ${ActiveMQPort + PortOffset}
>
>
> ${ServerHostname}
> ${ActiveMQStompPort +
> PortOffset}
>
> 2.Startup geronimo server, but exceptions exist:
> 22:02:15,843 ERROR [GBeanInstanceState] Error while starting; GBean is now in
> the FAILED state:
> abstractName="org.apache.geronimo.configs/activemq-broker/2.1.3/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.1.3/car,j2eeType=JMSServer,name=ActiveMQ"
> java.io.IOException: Could load xbean factory:java.lang.NoClassDefFoundError:
> org/springframework/beans/BeansException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:28)
> at
> org.apache.activemq.broker.BrokerFactory.createBrokerFactoryHandler(BrokerFactory.java:43)
> at
> org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:56)
> at
> org.apache.geronimo.activemq.BrokerServiceGBeanImpl.doStart(BrokerServiceGBeanImpl.java:80)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:998)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
> at
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456)
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.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:832)
> 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$$49484ad2.startConfiguration()
> at
> org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:162)
> at
> org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
> at
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
> at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
> Caused by: java.lang.NoClassDefFoundError:
> org/springframework/beans/BeansException
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
> at java.lang.Class.getConstructor0(Class.java:2671)
> at java.lang.Class.newInsta
[BUILD] branches/2.0: Failed for Revision: 709043
Geronimo Revision: 709043 built with tests included See the full build-2000.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20081029/build-2000.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.0/20081029 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 23 minutes 47 seconds [INFO] Finished at: Wed Oct 29 20:28:11 EDT 2008 [INFO] Final Memory: 233M/943M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20081029/logs-2000-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 162.391 sec <<< FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20081029/logs-2000-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 158.864 sec <<< FAILURE!
[BUILD] branches/2.1: Failed for Revision: 708946
Geronimo Revision: 708946 built with tests included
See the full build-1400.log file at
http://people.apache.org/builds/geronimo/server/binaries/2.1/20081029/build-1400.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/2.1/20081029
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 31 minutes 49 seconds
[INFO] Finished at: Wed Oct 29 14:38:33 EDT 2008
[INFO] Final Memory: 315M/1014M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/2.1/20081029/logs-1400-tomcat/test.log
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [war:war]
[INFO] [INFO] Exploding webapp...
[INFO] [INFO] Assembling webapp corba-helloworld-war in
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT
[INFO] [INFO] Copy webapp webResources to
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT
[INFO] [INFO] Copy webapp webResources to
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT
[INFO] [INFO] Copy webapp webResources to
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT
[INFO] [INFO] Building jar:
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT/WEB-INF/lib/corba-helloworld-war-2.1.4-SNAPSHOT.jar
[INFO] [INFO] Generating war
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT.war
[INFO] [INFO] Building war:
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT.war
[INFO] [INFO] [surefire:test {execution: integration}]
[INFO] [INFO] No tests to run.
[INFO] [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] [INFO] Checking legal files in: corba-helloworld-war-2.1.4-SNAPSHOT.war
[INFO] [INFO] [install:install]
[INFO] [INFO] Installing
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT.war
to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/corba-helloworld-war/2.1.4-SNAPSHOT/corba-helloworld-war-2.1.4-SNAPSHOT.war
[INFO] [INFO] [testsuite:generate-surefire-xml {execution:
generate-surefire-xml}]
[INFO] [INFO] Updating directory:
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/target/surefire-reports
[INFO] [INFO] No surefire-reports directory here
[INFO] [INFO]
[INFO] [INFO] Building Geronimo TestSuite :: CORBA TestSuite :: Hello World
Client
[INFO] [INFO]task-segment: [install]
[INFO] [INFO]
[INFO] [INFO] [enforcer:enforce {execution: default}]
[INFO] [INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [INFO] Created dir:
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-client/target/classes/META-INF
[INFO] [INFO] Copying 2 files to
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-client/target/classes/META-INF
[INFO] [INFO] [resources:resources]
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:compile]
[INFO] [INFO] Compiling 4 source files to
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-client/target/classes
[INFO] [INFO] [resources:testResources]
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:testCompile]
[INFO] [INFO] No sources to compile
[INFO] [INFO] [surefire:test]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [surefire:test {execution: test}]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [jar:jar]
[INFO] [INFO] Building jar:
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-client/target/corba-helloworld-client-2.1.4-SNAPSHOT.jar
[INFO] [INFO] [surefire:test {execution: integration}]
[INFO] [INFO] No tests to run.
[INFO] [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] [INFO] Checking legal files in:
corba-helloworld-client-2.1.4-SNAPSHOT.jar
[INFO] [INFO] [install:install]
[INFO] [INFO] Installing
/home/geronimo
Re: Creating server instances
Ok. so there are bugs :-) Maybe even significant bugs! Maybe even bugs that make it totally useless as is!! But its a good idea... I'll look into this when I get a chance. I think maybe I'm calling the wrong method on the persistent configuration list to find out what's installed? thanks for the test drive! david jencks On Oct 29, 2008, at 11:08 AM, Joe Bohn wrote: I can create a server instance now. :-) However, I was under the impression that this would clone the existing server instance. Is there still more to be done for that or did I misunderstand? I started with the tomcat javaee5 server assembly and ran the new- instance gshell command expecting to get a second server instance that looked exactly like the javaee5 tomcat instance. I then changed the port offset for the new instance, updated the server name in GERONIMO_OPTS, and started the new server instance. The new instance is basically just a bootstrap assembly. As you can see from the messages below, it looks like just RMI Naming and JMX Remoting Connector were started. Booting Geronimo Kernel (in Java 1.5.0_16)... Starting Geronimo Application Server v2.2-SNAPSHOT [] 100% 1s Startup complete Listening on Ports: 1109 127.0.0.1 RMI Naming 10009 127.0.0.1 JMX Remoting Connector Geronimo Application Server started Joe David Jencks wrote: umm..., added, now you can find the next thing I left out :-/ david jencks On Oct 29, 2008, at 8:44 AM, Joe Bohn wrote: David, I think you must have forgotten something in the check-in. When I attempt to create a new instance I get the following error from gshell: /> deploy/new-instance -n myserver1 ERROR NotFoundException: geronimo-commands:new-server-instance Joe Joe Bohn wrote: This sounds really cool David! I'm hoping to give it a test drive soon. Joe David Jencks wrote: For a long time we've been talking about having an easy way to create lots of server instances sharing the same geronimo installation (GERONIMO-3123). After staring at the farm demo long enough I realized that we could use almost the same technique to "clone" a server instance as used to install the same plugins on all the instances sharing a geronimo install. The var directory was originally created by unpacking stuff out of all the plugins installed in the server. So we can create a new var directory for the new server instance by creating a ServerInfo set up for the new instance (i.e. knowing where the server is, i.e. the var directory), creating a PluginInstallerGBean around it, and installing all the plugins that are installed on the original server. After fixing a few bugs, this amounts to unpacking the stuff out of all these plugins into the new var directory. This seems like a pretty elegant solution to me. There's a new gshell command deploy/new-instance -n server1 See GERONIMO-4382 thanks david jencks
Re: Creating server instances
I can create a server instance now. :-) However, I was under the impression that this would clone the existing server instance. Is there still more to be done for that or did I misunderstand? I started with the tomcat javaee5 server assembly and ran the new-instance gshell command expecting to get a second server instance that looked exactly like the javaee5 tomcat instance. I then changed the port offset for the new instance, updated the server name in GERONIMO_OPTS, and started the new server instance. The new instance is basically just a bootstrap assembly. As you can see from the messages below, it looks like just RMI Naming and JMX Remoting Connector were started. Booting Geronimo Kernel (in Java 1.5.0_16)... Starting Geronimo Application Server v2.2-SNAPSHOT [] 100% 1s Startup complete Listening on Ports: 1109 127.0.0.1 RMI Naming 10009 127.0.0.1 JMX Remoting Connector Geronimo Application Server started Joe David Jencks wrote: umm..., added, now you can find the next thing I left out :-/ david jencks On Oct 29, 2008, at 8:44 AM, Joe Bohn wrote: David, I think you must have forgotten something in the check-in. When I attempt to create a new instance I get the following error from gshell: /> deploy/new-instance -n myserver1 ERROR NotFoundException: geronimo-commands:new-server-instance Joe Joe Bohn wrote: This sounds really cool David! I'm hoping to give it a test drive soon. Joe David Jencks wrote: For a long time we've been talking about having an easy way to create lots of server instances sharing the same geronimo installation (GERONIMO-3123). After staring at the farm demo long enough I realized that we could use almost the same technique to "clone" a server instance as used to install the same plugins on all the instances sharing a geronimo install. The var directory was originally created by unpacking stuff out of all the plugins installed in the server. So we can create a new var directory for the new server instance by creating a ServerInfo set up for the new instance (i.e. knowing where the server is, i.e. the var directory), creating a PluginInstallerGBean around it, and installing all the plugins that are installed on the original server. After fixing a few bugs, this amounts to unpacking the stuff out of all these plugins into the new var directory. This seems like a pretty elegant solution to me. There's a new gshell command deploy/new-instance -n server1 See GERONIMO-4382 thanks david jencks
Re: An idea for defining custom valves in config.xml
There's no need to check in what you have if you don't feel it's quite done
yet. I was just wondering where you were at. I was eager to have a
solution for the original issue find its way into the 2.2 release, and it
seems that would be the case. I think that improving the classloading
isolation would be the best approach to solve the issue you raised. I'm not
too familiar with the classloader as is, though, so I'm not sure what impact
that would have. From a purely user point of view, it seems like the
correct way to go. Let me know if you need any help testing or coding any
of this. As I said, I'm not too familiar with the classloader, but if I
flop around in the code enough I might be able to make a few small waves ;)
Thanks!
On Tue, Oct 28, 2008 at 4:53 PM, Gianny Damour <
[EMAIL PROTECTED]> wrote:
> Hi Jason,
>
> It is implemented and I will check-in over the week-end.
>
> Here is the design:
> 1. When a ConfigurationData is loaded from a ConfigurationStore, its
> dependencies can be altered based on scripts matching the pattern
> dependencies-(.*).groovy. Here is the script I have been using to perform my
> integration test:
>
> configurationDataBuilder.configure {
>addDependency(groupId: "org.springframework", artifactId: "spring-core",
> version: "2.0.5", type: "jar")
> }
>
> 2. When the GBeans of a configuration are loaded, i.e. when a Configuration
> instance is created, GBeans can be updated based on scripts matching the
> pattern gbeans-(,*).groovy. Here is my integration test script:
>
> import org.springframework.core.SpringVersion
>
> gbeanDataBuilder.configure {
>addGBean(name: 'name', gbean: SpringVersion) {
>}
> }
>
> Scripts are searched in the configuration directory, i.e. in the same
> folder of the META-INF folder of a configuration. This can be easily changed
> by implementing a ScriptLocater strategy.
>
> I had to add a groovy dependency to the j2ee-system config which is not
> ideal as all the configurations will now see the Groovy classes. Ideally, I
> would like to add another configuration where ConfigurationDataTransformers
> can be declared and the out-of-the-box GroovyTransformer can be specified.
> This is problematic as such a configuration needs to be started after
> j2ee-system and before any other configurations. I could add a dependency to
> this configuration on the innermost configuration after j2ee-system.
>
> Another approach would be to improve the isolation of configuration
> classloaders, which should also address classloading problems reported by
> users and the need to fiddle with hidden-classes declarations. Assuming that
> I stick to the current configuration approach where I declare a
> GroovyTransformer in j2ee-system, the improvement I am thinking about is:
> 1) add a new classloading declaration element, maybe hidden-for-children,
> where users can specify a pattern a la hidden-classes.
> 2) The above declarations are used to build a classloader which simply
> delegates to the configuration classloader and filter out classes matching
> the hidden-for-children declarations.
> 3) Children configurations are provided with the above classloader instead
> of the configuration classloader.
>
> With this thing in place, I will be able to add a groovy dependency to
> j2ee-system w/o having to thing about the impacts to children configurations
> as I can hide the groovy classes.
>
> If you want me to check-in "as-is" this scripting stuff and revisit the
> implementation as soon as I figure out which of the two approaches, i.e. add
> another config or improve classloading isolation, is the best, then let me
> know.
>
> Thanks,
> Gianny
>
>
>
> On 29/10/2008, at 2:21 AM, Jason Warner wrote:
>
> Hi Gianny,
>>
>> Have you made any progress with this? Are you targeting this for the 2.2
>> release (whenever that happens to be)?
>>
>> Thanks!
>>
>> On Fri, Oct 17, 2008 at 8:11 PM, Gianny Damour <
>> [EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I am proposing the following implementation to start with:
>>
>> 1. In the META-INF folder of a config, we scan for files matching the
>> patterns "dependencies-(.*).groovy" and "extentions-(.*).groovy".
>>
>> 2. We execute the scripts "dependencies-(.*).groovy" which modify
>> dependencies. For instance, such scripts may look like:
>>
>> configurationData + dependency(groupId: 'group', artifactId: 'artifact',
>> version: '1.1', type: 'jar', importType: importType) -- add the declared
>> dependency
>> configurationData - dependency(groupId: 'group', artifactId: 'artifact',
>> version: '1.0', type: 'jar') -- remove the declared dependency
>>
>> This gives us the final classloader of the config.
>>
>> 3. We execute the scripts "extentions-(.*).groovy" which update the
>> GBeans, For instance, such scripts may look like:
>>
>> gBeanBuilder.configure {
>> addGBean(BasicNodeInfo) { -- add a GBean
>> attribute(name: 'node1')
>> attribute(extendedJMXConnectorInfo: new
>> BasicExtendedJMXConnectorInfo(...))
[jira] Commented: (GERONIMO-4382) New Server Instance via plugins
[ https://issues.apache.org/jira/browse/GERONIMO-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643530#action_12643530 ] David Jencks commented on GERONIMO-4382: Missed the groovy command, added in rev 708938. Thanks jbohn! > New Server Instance via plugins > --- > > Key: GERONIMO-4382 > URL: https://issues.apache.org/jira/browse/GERONIMO-4382 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: commands, Plugins >Affects Versions: 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2 > > > After staring at the farming sample long enough I realized that it's pretty > easy to duplcate a server by the same process as used in the farm sample to > install the same plugin list on a bunch of servers running in the same > geronimo install. Basically, just fire up a new ServerInfo for the new > instance, construct a PluginInstallerGBean around it, and install all the > existing plugins into the new instance. > This might be enough of a solution to close GERONIMO-3123. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Creating server instances
umm..., added, now you can find the next thing I left out :-/ david jencks On Oct 29, 2008, at 8:44 AM, Joe Bohn wrote: David, I think you must have forgotten something in the check-in. When I attempt to create a new instance I get the following error from gshell: /> deploy/new-instance -n myserver1 ERROR NotFoundException: geronimo-commands:new-server-instance Joe Joe Bohn wrote: This sounds really cool David! I'm hoping to give it a test drive soon. Joe David Jencks wrote: For a long time we've been talking about having an easy way to create lots of server instances sharing the same geronimo installation (GERONIMO-3123). After staring at the farm demo long enough I realized that we could use almost the same technique to "clone" a server instance as used to install the same plugins on all the instances sharing a geronimo install. The var directory was originally created by unpacking stuff out of all the plugins installed in the server. So we can create a new var directory for the new server instance by creating a ServerInfo set up for the new instance (i.e. knowing where the server is, i.e. the var directory), creating a PluginInstallerGBean around it, and installing all the plugins that are installed on the original server. After fixing a few bugs, this amounts to unpacking the stuff out of all these plugins into the new var directory. This seems like a pretty elegant solution to me. There's a new gshell command deploy/new-instance -n server1 See GERONIMO-4382 thanks david jencks
Re: Creating server instances
David, I think you must have forgotten something in the check-in. When I attempt to create a new instance I get the following error from gshell: /> deploy/new-instance -n myserver1 ERROR NotFoundException: geronimo-commands:new-server-instance Joe Joe Bohn wrote: This sounds really cool David! I'm hoping to give it a test drive soon. Joe David Jencks wrote: For a long time we've been talking about having an easy way to create lots of server instances sharing the same geronimo installation (GERONIMO-3123). After staring at the farm demo long enough I realized that we could use almost the same technique to "clone" a server instance as used to install the same plugins on all the instances sharing a geronimo install. The var directory was originally created by unpacking stuff out of all the plugins installed in the server. So we can create a new var directory for the new server instance by creating a ServerInfo set up for the new instance (i.e. knowing where the server is, i.e. the var directory), creating a PluginInstallerGBean around it, and installing all the plugins that are installed on the original server. After fixing a few bugs, this amounts to unpacking the stuff out of all these plugins into the new var directory. This seems like a pretty elegant solution to me. There's a new gshell command deploy/new-instance -n server1 See GERONIMO-4382 thanks david jencks
[jira] Commented: (GERONIMO-4384) Could load xbean factory when configure ActiveMQ brokerUri
[
https://issues.apache.org/jira/browse/GERONIMO-4384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643516#action_12643516
]
Donald Woods commented on GERONIMO-4384:
Believe this is a duplicate of an older JIRA, as we do not include Spring as a
dependency to allow users to do this in Geronimo 2.0/2.1/2.2.
> Could load xbean factory when configure ActiveMQ brokerUri
> ---
>
> Key: GERONIMO-4384
> URL: https://issues.apache.org/jira/browse/GERONIMO-4384
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: ActiveMQ
>Affects Versions: 2.1.3
> Environment: Windows XP ,JDK 1.5.0
>Reporter: viola.lu
>
> 1.Edit config.xml udner $geronimo_instal_Dir/var/config as below:
>
>
> name="brokerUri">xbean:file:/path/to/activemq.xml
> possibly-unique-broker
> false
> var/activemq
>
>
> ${ServerHostname}
> ${ActiveMQPort + PortOffset}
>
>
> ${ServerHostname}
> ${ActiveMQStompPort +
> PortOffset}
>
> 2.Startup geronimo server, but exceptions exist:
> 22:02:15,843 ERROR [GBeanInstanceState] Error while starting; GBean is now in
> the FAILED state:
> abstractName="org.apache.geronimo.configs/activemq-broker/2.1.3/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.1.3/car,j2eeType=JMSServer,name=ActiveMQ"
> java.io.IOException: Could load xbean factory:java.lang.NoClassDefFoundError:
> org/springframework/beans/BeansException
> at
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:28)
> at
> org.apache.activemq.broker.BrokerFactory.createBrokerFactoryHandler(BrokerFactory.java:43)
> at
> org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:56)
> at
> org.apache.geronimo.activemq.BrokerServiceGBeanImpl.doStart(BrokerServiceGBeanImpl.java:80)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:998)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
> at
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456)
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.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:832)
> 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$$49484ad2.startConfiguration()
> at
> org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:162)
> at
> org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
> at
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
> at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
> at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
> Caused by: java.lang.NoClassDefFoundError:
> org/springframework/beans/BeansException
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
> at java.lang.Class.getConstructor0(Class.java:2671)
> at java.lang.C
[jira] Commented: (GERONIMODEVTOOLS-527) Upgrade GEP to support Eclipse 3.4 SR1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643492#action_12643492 ] Donald Woods commented on GERONIMODEVTOOLS-527: --- Is this for building or a runtime problem? > Upgrade GEP to support Eclipse 3.4 SR1 > -- > > Key: GERONIMODEVTOOLS-527 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Reporter: Tim McConnell >Assignee: Tim McConnell > Fix For: 2.1.4 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4384) Could load xbean factory when configure ActiveMQ brokerUri
Could load xbean factory when configure ActiveMQ brokerUri
---
Key: GERONIMO-4384
URL: https://issues.apache.org/jira/browse/GERONIMO-4384
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: ActiveMQ
Affects Versions: 2.1.3
Environment: Windows XP ,JDK 1.5.0
Reporter: viola.lu
1.Edit config.xml udner $geronimo_instal_Dir/var/config as below:
xbean:file:/path/to/activemq.xml
possibly-unique-broker
false
var/activemq
${ServerHostname}
${ActiveMQPort + PortOffset}
${ServerHostname}
${ActiveMQStompPort + PortOffset}
2.Startup geronimo server, but exceptions exist:
22:02:15,843 ERROR [GBeanInstanceState] Error while starting; GBean is now in
the FAILED state:
abstractName="org.apache.geronimo.configs/activemq-broker/2.1.3/car?ServiceModule=org.apache.geronimo.configs/activemq-broker/2.1.3/car,j2eeType=JMSServer,name=ActiveMQ"
java.io.IOException: Could load xbean factory:java.lang.NoClassDefFoundError:
org/springframework/beans/BeansException
at
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:28)
at
org.apache.activemq.broker.BrokerFactory.createBrokerFactoryHandler(BrokerFactory.java:43)
at
org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:56)
at
org.apache.geronimo.activemq.BrokerServiceGBeanImpl.doStart(BrokerServiceGBeanImpl.java:80)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:998)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:188)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.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:832)
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$$49484ad2.startConfiguration()
at
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:162)
at
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:79)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:45)
at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
Caused by: java.lang.NoClassDefFoundError:
org/springframework/beans/BeansException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
at java.lang.Class.getConstructor0(Class.java:2671)
at java.lang.Class.newInstance0(Class.java:321)
at java.lang.Class.newInstance(Class.java:303)
at
org.apache.activemq.util.FactoryFinder.newInstance(FactoryFinder.java:61)
at
org.apache.activemq.util.FactoryFinder.newInstance(FactoryFinder.java:47)
at
org.apache.activemq.broker.BrokerFactory.createBrokerFactoryHandler(BrokerFactory.java:41)
... 27 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4361) Resource injection of simple env. entry types
[ https://issues.apache.org/jira/browse/GERONIMO-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643491#action_12643491 ] Jarek Gawor commented on GERONIMO-4361: --- If you have @Resource annotation without the "name" attribute, the matching env-entry name in the DD for the injected resource should be something like: org.apache.geronimo.samples.slsb.calculator.Calculator/myString So you either need to change the env-entry-name to match the injected resource or add "name" attribute to the @Resource annotation. > Resource injection of simple env. entry types > - > > Key: GERONIMO-4361 > URL: https://issues.apache.org/jira/browse/GERONIMO-4361 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.1.3, 2.2 >Reporter: Jarek Gawor >Assignee: Jarek Gawor > Fix For: 2.1.4, 2.2 > > > There are a couple problems with @Resource injection of simple env. types: > 1) If @Resource.mappedName attribute is specified, it becomes the env-entry > value. For example, if we have @Resource(mappedName = "java:comp/env/bar") > String foo, the injected value of "foo" will be "java:comp/env/bar". That's > incorrect. > 2) Right now, @Resource String foo = "bar". without a corresponding env-entry > in the DD will cause a deployment (injection) exception (since there is no > entry for it in the JNDI context). However, according to the Java EE 5 spec, > section EE.5.4.1.3, "... the container must only inject a value for this > resource if the deployer has specified a value to override the default value" > and since the generated DD entry for this resource will have no > env-entry-value element, the injection should not happen (and so the > application should deploy without an error). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] branches/2.1: Failed for Revision: 708879
Geronimo Revision: 708879 built with tests included
See the full build-0800.log file at
http://people.apache.org/builds/geronimo/server/binaries/2.1/20081029/build-0800.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/2.1/20081029
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 44 minutes 16 seconds
[INFO] Finished at: Wed Oct 29 08:49:23 EDT 2008
[INFO] Final Memory: 345M/881M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/2.1/20081029/logs-0800-tomcat/test.log
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [war:war]
[INFO] [INFO] Exploding webapp...
[INFO] [INFO] Assembling webapp corba-helloworld-war in
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT
[INFO] [INFO] Copy webapp webResources to
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT
[INFO] [INFO] Copy webapp webResources to
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT
[INFO] [INFO] Copy webapp webResources to
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT
[INFO] [INFO] Building jar:
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT/WEB-INF/lib/corba-helloworld-war-2.1.4-SNAPSHOT.jar
[INFO] [INFO] Generating war
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT.war
[INFO] [INFO] Building war:
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT.war
[INFO] [INFO] [surefire:test {execution: integration}]
[INFO] [INFO] No tests to run.
[INFO] [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] [INFO] Checking legal files in: corba-helloworld-war-2.1.4-SNAPSHOT.war
[INFO] [INFO] [install:install]
[INFO] [INFO] Installing
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-war/target/corba-helloworld-war-2.1.4-SNAPSHOT.war
to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/corba-helloworld-war/2.1.4-SNAPSHOT/corba-helloworld-war-2.1.4-SNAPSHOT.war
[INFO] [INFO] [testsuite:generate-surefire-xml {execution:
generate-surefire-xml}]
[INFO] [INFO] Updating directory:
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/target/surefire-reports
[INFO] [INFO] No surefire-reports directory here
[INFO] [INFO]
[INFO] [INFO] Building Geronimo TestSuite :: CORBA TestSuite :: Hello World
Client
[INFO] [INFO]task-segment: [install]
[INFO] [INFO]
[INFO] [INFO] [enforcer:enforce {execution: default}]
[INFO] [INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [INFO] Created dir:
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-client/target/classes/META-INF
[INFO] [INFO] Copying 2 files to
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-client/target/classes/META-INF
[INFO] [INFO] [resources:resources]
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:compile]
[INFO] [INFO] Compiling 4 source files to
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-client/target/classes
[INFO] [INFO] [resources:testResources]
[INFO] [INFO] Using default encoding to copy filtered resources.
[INFO] [INFO] [compiler:testCompile]
[INFO] [INFO] No sources to compile
[INFO] [INFO] [surefire:test]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [surefire:test {execution: test}]
[INFO] [INFO] Tests are skipped.
[INFO] [INFO] [jar:jar]
[INFO] [INFO] Building jar:
/home/geronimo/geronimo/2.1/testsuite/corba-testsuite/corba-helloworld/corba-helloworld-client/target/corba-helloworld-client-2.1.4-SNAPSHOT.jar
[INFO] [INFO] [surefire:test {execution: integration}]
[INFO] [INFO] No tests to run.
[INFO] [INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] [INFO] Checking legal files in:
corba-helloworld-client-2.1.4-SNAPSHOT.jar
[INFO] [INFO] [install:install]
[INFO] [INFO] Installing
/home/geronimo
[jira] Created: (GERONIMO-4383) PortletException on file upload after console timeout
PortletException on file upload after console timeout - Key: GERONIMO-4383 URL: https://issues.apache.org/jira/browse/GERONIMO-4383 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 2.1.3 Reporter: Jürgen Weber Priority: Minor If you (re)deploy an application but the console timeout has happened, you are lead to the login page. After successfully logging in you get a PortletException. This should be handled gracefully. HTTP ERROR: 500 Expected file upload RequestURI=/console/portal//Applications/Deploy%20New/__ac0x3plugin0x2Deployment!227983155|0 Caused by: javax.portlet.PortletException: Expected file upload at org.apache.geronimo.console.configmanager.DeploymentPortlet.processAction(DeploymentPortlet.java:75) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:67) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.handle(TwistyWebAppContext.java:59) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:192) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.action(DefaultPortletInvokerService.java:85) at org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:219) at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:121) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.apache.geronimo.jetty6.InternalJettyServletHolder.handle(InternalJettyServletHolder.java:65) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.apache.geronimo.jetty6.handler.JettySecurityHandler.handle(JettySecurityHandler.java:114) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101(TwistyWebAppContext.java:40) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext$TwistyHandler.handle(TwistyWebAppContext.java:65) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle(ThreadClassloaderHandler.java:46) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle(InstanceContextHandler.java:58) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle(UserTransactionHandler.java:48) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle(ComponentContextHandler.java:47) at org.apache.geronimo.jetty6.handler.TwistyWebAppContext.handle(TwistyWebAppContext.java:59) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206) at org.mortbay.jet
[jira] Resolved: (GERONIMO-3811) EjbServer portlet
[ https://issues.apache.org/jira/browse/GERONIMO-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manu T George resolved GERONIMO-3811. - Resolution: Fixed > EjbServer portlet > - > > Key: GERONIMO-3811 > URL: https://issues.apache.org/jira/browse/GERONIMO-3811 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: OpenEJB > Environment: All >Reporter: Manu T George >Assignee: Manu T George > Fix For: 2.2 > > Attachments: g3811_r640786.patch, g3811_r678044.patch, > screenshot-1.jpg, screenshot-2.jpg > > > A portlet to show information about the OpenEJB container integrated in > Geronimo. It should also allow configuration of some parameters like pool > size etc -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4361) Resource injection of simple env. entry types
[
https://issues.apache.org/jira/browse/GERONIMO-4361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643450#action_12643450
]
Jürgen Weber commented on GERONIMO-4361:
Another Problem: attributes are not overridden.
For
@Resource
private String myString = "foo";
myString
java.lang.String
bar
at runtime myString is "foo" instead of "bar".
I understand "the container must only inject a value for this resource if the
deployer has specified a value to override the default value" means "do it if
there is a env-entry.
I took the calculator sample
http://cwiki.apache.org/GMOxDOC21/calculator-using-ejb-30-functions.html
@Stateless(name = "Calculator")
public class Calculator implements CalculatorRemote, CalculatorLocal {
@Resource
private String myString = "foo";
..
Calculator
myString
java.lang.String
bar
> Resource injection of simple env. entry types
> -
>
> Key: GERONIMO-4361
> URL: https://issues.apache.org/jira/browse/GERONIMO-4361
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: deployment
>Affects Versions: 2.1.3, 2.2
>Reporter: Jarek Gawor
>Assignee: Jarek Gawor
> Fix For: 2.1.4, 2.2
>
>
> There are a couple problems with @Resource injection of simple env. types:
> 1) If @Resource.mappedName attribute is specified, it becomes the env-entry
> value. For example, if we have @Resource(mappedName = "java:comp/env/bar")
> String foo, the injected value of "foo" will be "java:comp/env/bar". That's
> incorrect.
> 2) Right now, @Resource String foo = "bar". without a corresponding env-entry
> in the DD will cause a deployment (injection) exception (since there is no
> entry for it in the JNDI context). However, according to the Java EE 5 spec,
> section EE.5.4.1.3, "... the container must only inject a value for this
> resource if the deployer has specified a value to override the default value"
> and since the generated DD entry for this resource will have no
> env-entry-value element, the injection should not happen (and so the
> application should deploy without an error).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 708809
Geronimo Revision: 708809 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081029/build-0300.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20081029 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 39 minutes 6 seconds [INFO] Finished at: Wed Oct 29 03:43:29 EDT 2008 [INFO] Final Memory: 402M/972M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081029/logs-0300-tomcat/test.log Booting Geronimo Kernel (in Java 1.5.0_12)... Module 1/73 org.apache.geronimo.framework/gshell-framework/2.2-SNAPSHOT/car started in .000s Module 2/73 org.apache.geronimo.framework/gshell-geronimo/2.2-SNAPSHOT/car started in .000s Module 3/73 org.apache.geronimo.framework/gshell-remote/2.2-SNAPSHOT/car started in .000s Module 4/73 org.apache.geronimo.framework/j2ee-system/2.2-SNAPSHOT/car started in .000s Module 5/73 org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car started in .001s Module 6/73 org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car started in .290s Module 7/73 org.apache.geronimo.configs/sharedlib/2.2-SNAPSHOT/car started in .012s Module 8/73 org.apache.geronimo.framework/transformer-agent/2.2-SNAPSHOT/car started in .000s Module 9/73 org.apache.geronimo.plugins.classloaders/geronimo-javaee-deployment_1.1MR3_spec/2.2-SNAPSHOT/car started in .000s Module 10/73 org.apache.geronimo.framework/plugin/2.2-SNAPSHOT/car started in .754s Module 11/73 org.apache.geronimo.framework/xmlbeans/2.2-SNAPSHOT/car started in .000s Module 12/73 org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car started in .350s Module 13/73 org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car started in .286s Module 14/73 org.apache.geronimo.configs/j2ee-server/2.2-SNAPSHOT/car started in .100s Module 15/73 org.apache.geronimo.configs/transaction/2.2-SNAPSHOT/car started in .253s Module 16/73 org.apache.geronimo.framework/server-security-config/2.2-SNAPSHOT/car started in .056s Module 17/73 org.apache.geronimo.configs/jasper/2.2-SNAPSHOT/car started in .003s Module 18/73 org.apache.geronimo.plugins.classloaders/geronimo-schema-jee_5/2.2-SNAPSHOT/car started in .000s Module 19/73 org.apache.geronimo.configs/webservices-common/2.2-SNAPSHOT/car started in .000s Module 20/73 org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car started in 2.708s Module 21/73 org.apache.geronimo.configs/remote-deploy-tomcat/2.2-SNAPSHOT/car started in .538s Module 22/73 org.apache.geronimo.plugins.classloaders/xbean-finder/2.2-SNAPSHOT/car started in .000s Module 23/73 org.apache.geronimo.configs/j2ee-deployer/2.2-SNAPSHOT/car started in .392s Module 24/73 org.apache.geronimo.configs/connector-deployer/2.2-SNAPSHOT/car started in .132s Module 25/73 org.apache.geronimo.configs/tomcat6-deployer/2.2-SNAPSHOT/car started in .112s Module 26/73 org.apache.geronimo.configs/jasper-deployer/2.2-SNAPSHOT/car started in .011s Module 27/73 org.apache.geronimo.configs/hot-deployer/2.2-SNAPSHOT/car started in .311s Module 28/73 org.apache.geronimo.configs/welcome-tomcat/2.2-SNAPSHOT/car started in .093s Module 29/73 org.apache.geronimo.configs/dojo-legacy-tomcat/2.2-SNAPSHOT/car started in .064s Module 30/73 org.apache.geronimo.configs/spring/2.2-SNAPSHOT/car started in .000s Module 31/73 org.apache.geronimo.plugins/pluto-support/2.2-SNAPSHOT/car
[BUILD] branches/2.0: Failed for Revision: 708781
Geronimo Revision: 708781 built with tests included See the full build-0200.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20081029/build-0200.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.0/20081029 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 24 minutes 57 seconds [INFO] Finished at: Wed Oct 29 02:28:26 EDT 2008 [INFO] Final Memory: 228M/1001M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20081029/logs-0200-tomcat/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 161.371 sec <<< FAILURE! Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.0/20081029/logs-0200-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 12, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 156.552 sec <<< FAILURE!
