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.
