Re: Geronimo plugin project example?
Fredrik, thanks for the post. Actually, there are some docs about what a geronimo-plugin looks like(1) and how to create/install/update one. Here are the URLs FYR. Please let us know if you have any comments. (1) http://cwiki.apache.org/confluence/display/GMOxDOC22/Plugin+and+plugin+group (2) http://cwiki.apache.org/confluence/display/GMOxDOC22/Administering+plugins Jeff C On Tue, Jul 14, 2009 at 6:23 PM, Fredrik Jonson fred...@myrealbox.comwrote: David Jencks wrote: Fredrik Jonson wrote: I'm looking for a simple example geronimo plugin project. Building all of geronimo itself is the best way to see a lot of plugin projects. Most of them are service plugins but there are a lot of javaee applications in there too. That seems a bit daunting. I'll try it... some day... ;) On the bright side I have finally managed to build and deploy a simple plugin! The reason I failed last week was due to a combination of PEBCAK and maybe a bit of complexity and lack of documentation in the car-maven-plugin. What I did was: 1. Tried to package a plugin with a broken plan.xml. I tried to copy the activemq-broker plugin from current trunk (2.2-SNAPSHOT) and that project configuration is a bit strange, lots of parent modules and their transitive dependencies made it hard to overview what parameters, configurations and files (history?) that actually is required, and what is just specific to that module. 2. PEBCAK. I tried to install the plugin using the deploy command instead of install-plugin. Completely my own fault. Two major gothas for me was: 1. Not declaring the geronimoVersion property in the pom. 2. Not declaring extensionstrue/extensions on the plugin configuration. If anyone else is interested, my very minimal geronimo-plugin example project is included below. The dependency org.example/provider is simply a jar module that contains the ExampleGBean implementation. |-- pom.xml `-- src `-- main `-- plan `-- plan.xml --- pom.xml --- ?xml version=1.0? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdorg.example/groupId artifactIdplugin/artifactId version1.0-SNAPSHOT/version packagingcar/packaging properties geronimoVersion2.1.4/geronimoVersion /properties dependencies dependency groupIdorg.example/groupId artifactIdprovider/artifactId version${version}/version /dependency /dependencies build plugins plugin groupIdorg.apache.geronimo.buildsupport/groupId artifactIdcar-maven-plugin/artifactId version2.1.4/version extensionstrue/extensions configuration useMavenDependencies valuetrue/value includeVersiontrue/includeVersion /useMavenDependencies categoryJMS/category /configuration /plugin /plugins /build /project --- src/main/plan/plan.xml --- ?xml version=1.0 encoding=UTF-8? module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2; gbean name=ExampleGBean class=org.example.gbean.ExampleGBean /gbean /module -- Fredrik Jonson
Re: Geronimo plugin project example?
chi runhua wrote: Fredrik, thanks for the post. Actually, there are some docs about what a geronimo-plugin looks like(1) and how to create/install/update one. Here are the URLs FYR. Please let us know if you have any comments. (1) http://cwiki.apache.org/confluence/display/GMOxDOC22/Plugin+and+plugin+group (2) http://cwiki.apache.org/confluence/display/GMOxDOC22/Administering+plugins Neat, thanks! The first link is missing an 's' though, the page is named: http://cwiki.apache.org/confluence/display/GMOxDOC22/Plugin+and+plugins+group Also, that page has a subpage include that points the wrong place, under the title Plugin groups you probably want to link to: http://cwiki.apache.org/confluence/display/GMOxDOC22/Plugins+group (or rename the page. the s seems a bit out of place.) Can anyone edit the wiki? -- Fredrik Jonson
State of EJB Clustering
Hi, what is the state of Geronimo's EJB clustering? Basically I wonder if it is possible to have n Java application clients that address m servers that run stateless beans. A client should stick to a server as long it is alive and transparently go to another one if it is dead. Is this information here still current for 2.2? http://cwiki.apache.org/GMOxDEV/test-drive-geronimo-ejb-clustering.html Or would GGache be the way to go? http://cwiki.apache.org/GMOxDEV/geronimo-clustering-with-gcache.html Thanks, Juergen -- View this message in context: http://www.nabble.com/State-of-EJB-Clustering-tp24500428s134p24500428.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: State of EJB Clustering
Hi Juergen, GCache never got finished. The wadi clustering works but is for stateful beans and AFAIK it provides only the state replication between cluster members and not the client that supports failover. I hope Gianny will tell me if I'm wrong about this :-) We do have the kind of clustering you want but I'm not sure if its documented. Basically the server cluster members maintain cluster membership information using multicast hearbeats and the ejb client maintains a list of servers and can change target server based on availability. There is an example of this at sandbox/failover and it used to work, but AFAIK no one has tried running it for several months. This would be a great thing to turn into a sample and make more public and documented for 2.2. thanks david jencks On Jul 15, 2009, at 8:34 AM, Juergen Weber wrote: Hi, what is the state of Geronimo's EJB clustering? Basically I wonder if it is possible to have n Java application clients that address m servers that run stateless beans. A client should stick to a server as long it is alive and transparently go to another one if it is dead. Is this information here still current for 2.2? http://cwiki.apache.org/GMOxDEV/test-drive-geronimo-ejb- clustering.html Or would GGache be the way to go? http://cwiki.apache.org/GMOxDEV/geronimo-clustering-with-gcache.html Thanks, Juergen -- View this message in context: http://www.nabble.com/State-of-EJB-Clustering-tp24500428s134p24500428.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: EJB Web App losing Subject
djencks wrote: OK, this is weird, I've never seen a bug in this area. What kind of authentication does the web app use? Can you show the entire stack trace to the ejb security exception? If that's the case then my gut is that the bug is somewhere in the web app, but as I didn't write it and have never seen this kind of error before I'm at a bit of a loss on where to look. Time to get creative I guess. We are using Spring's authentication framework with a custom authenticator. The exception stack itself is bog-standard so I doubt it will reveal anything, but here it is: javax.ejb.EJBAccessException: Unauthorized Access by Principal Denied at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:144) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:245) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy39.getMyFavorites(Unknown Source) at ourcode.SomeStatelessBean.getMyFavorites(SomeStatelessBean.java:58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:158) at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:141) at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy35.getMyFavorites(Unknown Source) at ourcode.dao.impl.MyFavoritesDaoImpl.getFavoriteList(MyFavoritesDaoImpl.java:42) at ourcode.service.impl.MyFavoritesServiceImpl.getFavoriteList(MyFavoritesServiceImpl.java:30) at ourcode.web.controller.MyFavoritesController.getFavoriteList(MyFavoritesController.java:32) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doInvokeMethod(HandlerMethodInvoker.java:409) at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:132) at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:310) at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:297) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.security.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:378) at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109) at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
Re: EJB Web App losing Subject
On Jul 15, 2009, at 10:23 AM, Kory Markevich wrote: djencks wrote: OK, this is weird, I've never seen a bug in this area. What kind of authentication does the web app use? Can you show the entire stack trace to the ejb security exception? If that's the case then my gut is that the bug is somewhere in the web app, but as I didn't write it and have never seen this kind of error before I'm at a bit of a loss on where to look. Time to get creative I guess. We are using Spring's authentication framework with a custom authenticator. Spring security may secure spring apps but it wont relate to container managed authorization unless you do something to hook it up. You need some code that looks vaguely like this: Subject subject = getSpringAuthenticatedSubject(); ContextManager.registerSubject(subject); //if the subject is cached in a session this should only happen once when the subject is first authenticated/constructed. //the following should happen on every request ContextManager.setCallers(subject, subject); try { //process request } finally { ContextManager.clearCallers(); } WIthout code like this the mystery is why any ejb calls succeed -- it sort of points to a bug where an authenticated subject is left associated with a thread. I suspect someone has already solved this problem of hooking spring security up to geronimo security -- we should come up with a bit of code that does it and documentation. thanks david jencks The exception stack itself is bog-standard so I doubt it will reveal anything, but here it is: javax.ejb.EJBAccessException: Unauthorized Access by Principal Denied at org .apache .openejb .core.stateless.StatelessContainer.invoke(StatelessContainer.java:144) at org .apache .openejb .core .ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java: 217) at org .apache .openejb .core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org .apache .openejb .core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:245) at org .apache .openejb .util .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy39.getMyFavorites(Unknown Source) at ourcode.SomeStatelessBean.getMyFavorites(SomeStatelessBean.java: 58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.openejb.core.interceptor.ReflectionInvocationContext $Invocation.invoke(ReflectionInvocationContext.java:158) at org .apache .openejb .core .interceptor .ReflectionInvocationContext .proceed(ReflectionInvocationContext.java:141) at org .apache .openejb .core.interceptor.InterceptorStack.invoke(InterceptorStack.java:67) at org .apache .openejb .core.stateless.StatelessContainer._invoke(StatelessContainer.java: 210) at org .apache .openejb .core.stateless.StatelessContainer._invoke(StatelessContainer.java: 188) at org .apache .openejb .core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org .apache .openejb .core .ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java: 217) at org .apache .openejb .core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org .apache .openejb .core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321) at org .apache .openejb .util .proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy35.getMyFavorites(Unknown Source) at ourcode .dao.impl.MyFavoritesDaoImpl.getFavoriteList(MyFavoritesDaoImpl.java: 42) at ourcode .service .impl .MyFavoritesServiceImpl.getFavoriteList(MyFavoritesServiceImpl.java: 30) at ourcode .web .controller .MyFavoritesController.getFavoriteList(MyFavoritesController.java:32) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun .reflect .DelegatingMethodAccessorImpl .invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doInvokeMethod (HandlerMethodInvoker.java:409) at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod (HandlerMethodInvoker.java:132) at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod (AnnotationMethodHandlerAdapter.java:310) at
Re: EJB Web App losing Subject
djencks wrote: Subject subject = getSpringAuthenticatedSubject(); ContextManager.registerSubject(subject); //if the subject is cached in a session this should only happen once when the subject is first authenticated/constructed. //the following should happen on every request ContextManager.setCallers(subject, subject); try { //process request } finally { ContextManager.clearCallers(); } Our custom Spring authenticator contains calls to ContextManager.login and setCallers. If we need to call setCallers for every request, then that would explain this bug. We only call it once, and don't call clearCallers, so the subject is staying around in the original thread but subsequent threads never get initialized properly. Sounds like the proper solution is just a simple filter that does the setCallers and clearCallers. Thanks for all the help. -- View this message in context: http://www.nabble.com/EJB---Web-App-losing-Subject-tp24485373s134p24502831.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Geronimo plugin project example?
Thanks, fixed now. Jeff C On Wed, Jul 15, 2009 at 5:51 PM, Fredrik Jonson fred...@myrealbox.comwrote: chi runhua wrote: Fredrik, thanks for the post. Actually, there are some docs about what a geronimo-plugin looks like(1) and how to create/install/update one. Here are the URLs FYR. Please let us know if you have any comments. (1) http://cwiki.apache.org/confluence/display/GMOxDOC22/Plugin+and+plugin+group (2) http://cwiki.apache.org/confluence/display/GMOxDOC22/Administering+plugins Neat, thanks! The first link is missing an 's' though, the page is named: http://cwiki.apache.org/confluence/display/GMOxDOC22/Plugin+and+plugins+group Also, that page has a subpage include that points the wrong place, under the title Plugin groups you probably want to link to: http://cwiki.apache.org/confluence/display/GMOxDOC22/Plugins+group (or rename the page. the s seems a bit out of place.) Can anyone edit the wiki? -- Fredrik Jonson
How to reuse the jars in geronimo repository?
Hi, I use Eclipse 3.4 to develop a WAR application for Geronimo 2.1.4. The application needs commons-collections-3.2.jar. For shrinking my application size, I hope to reuse the same jar file in geronimo repository if there is the jar my application needs. Fortunately I did find that there is the jar in the repository. And I add the below dependencies in dep:dependencies block in my geronimo-web.xml dep:dependency dep:groupIdcommons-collections/dep:groupId dep:artifactIdcommons-collections/dep:artifactId dep:version3.2/dep:version dep:typejar/dep:type /dep:dependency However, in Eclipse, I saw the code using the class in commons-collections-3.2.jar still has red circle X on the lines where the class appears. What action do I still need to do for fixing the priblem? Thank you for your help. -- View this message in context: http://www.nabble.com/How-to-reuse-the-jars-in-geronimo-repository--tp24508861s134p24508861.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: How to reuse the jars in geronimo repository?
IIRC, the setting dep:dependency dep:groupIdcommons-collections/dep:groupId dep:artifactIdcommons-collections/dep:artifactId dep:version3.2/dep:version dep:typejar/dep:type /dep:dependency is only for server side, which means the collection.jar will be added to the webapp's classloader. 2009/7/16 Wureka wureka...@m2k.com.tw Hi, I use Eclipse 3.4 to develop a WAR application for Geronimo 2.1.4. The application needs commons-collections-3.2.jar. For shrinking my application size, I hope to reuse the same jar file in geronimo repository if there is the jar my application needs. Fortunately I did find that there is the jar in the repository. And I add the below dependencies in dep:dependencies block in my geronimo-web.xml dep:dependency dep:groupIdcommons-collections/dep:groupId dep:artifactIdcommons-collections/dep:artifactId dep:version3.2/dep:version dep:typejar/dep:type /dep:dependency However, in Eclipse, I saw the code using the class in commons-collections-3.2.jar still has red circle X on the lines where the class appears. What action do I still need to do for fixing the priblem? Thank you for your help. -- View this message in context: http://www.nabble.com/How-to-reuse-the-jars-in-geronimo-repository--tp24508861s134p24508861.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com. -- Ivan
Re: How to reuse the jars in geronimo repository?
The specified dependency is used for classloading when the war is deployed on geronimo. I think red circle X is because the compiler can't find the right classes. Add the very jar to the build path. -- Best Regards, Rodger.