Re: Geronimo and Grails
On May 13, 2008, at 9:55 PM, michaelg wrote: I am writing an article for IBM developerWorks on using Grails and Geronimo together. However, I am unable to deploy a Grails WAR to Geronimo. I first tried it with Geronimo 2.1.1 with Jetty. The error I got was a NoClassDefFound for org.apache.commons.fileupload.FileItemFactory. This class is the Geronimo repository, and is also included with the Grails war. It's the same version for both. Next I tried it with Geronimo 2.1.1 with Tomcat. This time I got a dom4j InvalidXPathException. Next I tried the Little G distribution. It worked perfectly. I had also tried standalone Tomcat with success as well, so I guess this should not have been too surprising. Obviously I have to point a finger at Grails or Geronimo, and since it works fine on Tomcat or Little G, I am pointing the finger at Geronimo. The Geronimo/Jetty error sure smelled like a class loader problem, but I have no clue on the Geronimo/Tomcat. Note, in all cases I included a Geronimo deployment plan inside the WAR (/WEB-INF/geronimo-web.xml) It doesn't matter whether the plan is included in the app or supplied externally. Any ideas/advice is greatly appreciated. I'm surprised you are seeing different results on "big" and "little" geronimo. You should be getting the same classloader for your app in either server. Would it be possible to share your app so we can take a look at what is going on? If I was writing an article on geronimo I would structure the project so it consisted of one or more geronimo plugins and would show how to construct a specialized server including those plugins. This is by far easier if you are using maven, which I realize might not fit with the requirements you are working under. There are some instructions on how to do something similar here: http://cwiki.apache.org/confluence/display/GMOxDOC21/Constructing+a+special-purpose+server+using+maven thanks david jencks -- View this message in context: http://www.nabble.com/Geronimo-and-Grails-tp17223357s134p17223357.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: DeploymentException: Module was not an EJB: EntitiesES.jar
Hello, and thanks for answering. I solved the problem: I had the entity beans
in "EntitiesES.jar" and the session beans in "EJBModelES.jar". When I did put
them together inside the same jar the problem dissapeared.
I don't know why this procedure solved the problem, so if someone knows about
this, the information is welcome.
--- El mié, 14/5/08, Kevan Miller <[EMAIL PROTECTED]> escribió:
> De: Kevan Miller <[EMAIL PROTECTED]>
> Asunto: Re: DeploymentException: Module was not an EJB: EntitiesES.jar
> Para: user@geronimo.apache.org
> Fecha: miércoles, 14 mayo, 2008 12:07
> On May 9, 2008, at 12:18 PM, ismael GranPollÿf3n wrote:
>
> >
> > Hello. I am trying to migrate from JBoss to Geronimo,
> and I am
> > having difficulties with my EJB jars. I am using
> Geronimo 2.1.1 and
> > Geronimo 2.0.2, both of them with Tomcat. I get the
> following error:
> >
> > Unable to deploy:
> org.apache.geronimo.common.DeploymentException:
> > Module was not an EJB: EntitiesES.jar
> >
> > I am trying to migrate an Ear application, I followed
> the EJB
> > example from the wiki, but I cannot make my
> application to run. I
> > hope someone can help, please ask me any doubt about
> the problem
> > The directories of my Ear are as follows:
> >
> > EJBAplicationES.ear
> > + META-INF
> > + EJBModelES.jar
> > + EJBAplicationES.war
> > + EntitiesES.jar
> > + database.xml
> >
> >
> >
> > The "EntitiesES.jar" contains this:
> > + es
> > + META-INF
> >
> > "es" folder have my ejbs, META-INF holds the
> "openejb-jar.xml" and
> > "persistence.xml" archives. The contents of
> these are:
> >
> > OPENEJB-JAR.XML:
> >
> > encoding="UTF-8"?>
> >
> > xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1";>
> > xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2
>
> > ">
> >
> >
> >
> >
> EntitiesES
> >
> >jar
> >
> >
> >
> >
> >
> org.apache.geronimo.configs
> >
> openjpa
> >car
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > PERSISTENCE.XML:
> >
> > encoding="UTF-8"?>
> > xmlns="http://java.sun.com/xml/ns/persistence";
> >
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> > version="1.0"
> >
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
>
> >
> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";>
> >
> > name="EJBAplicationES">
> >
> >Entity Beans for
> EJBAplicationES
> >
> >
> >
> >
> org.apache.openjpa.persistence.PersistenceProviderImpl
> > provider>
> >
> >
> es.model.document.entity.Document
> >
> es.model.user.entity.Language
> >
> es.model.user.entity.User
> >
> es.model.util.parameter.entity.Parameter
> >
> >
> > name="openjpa.jdbc.SynchronizeMappings"
> > value="false" />
> >
> >
> >
> database
> >
> database
> >
> >
> >
> >
> >
> >
> >
> > In the last one I declare the "database"
> datasource, I have that
> > files but I think that there are too much code in this
> e-mail; feel
> > free to ask me for this or other configuration files.
> Thank you for
> > reading!
>
>
> Hi,
> I don't see anything obviously wrong. Are you certain
> about the layout
> of your EntitiesES.jar?
>
> You are welcom to create a Jira issue
> (https://issues.apache.org/jira/browse/GERONIMO
> ) and attach your ear file there ("Attach File").
>
> --kevan
__
Enviado desde Correo Yahoo! La bandeja de entrada más inteligente.
Re: Geronimo and Grails
Hello, I have been running Grails 0.5+ applications on Geronimo 2.x and this works w/o problem as long as you hide specific packages. Your geronimo-web.xml should look like the following one: http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.2";> yourGroupId yourArtifactId yourVersion war org.springframework org.apache.cxf org.apache.commons /yourContextPath Thanks, Gianny On 14/05/2008, at 2:55 PM, michaelg wrote: I am writing an article for IBM developerWorks on using Grails and Geronimo together. However, I am unable to deploy a Grails WAR to Geronimo. I first tried it with Geronimo 2.1.1 with Jetty. The error I got was a NoClassDefFound for org.apache.commons.fileupload.FileItemFactory. This class is the Geronimo repository, and is also included with the Grails war. It's the same version for both. Next I tried it with Geronimo 2.1.1 with Tomcat. This time I got a dom4j InvalidXPathException. Next I tried the Little G distribution. It worked perfectly. I had also tried standalone Tomcat with success as well, so I guess this should not have been too surprising. Obviously I have to point a finger at Grails or Geronimo, and since it works fine on Tomcat or Little G, I am pointing the finger at Geronimo. The Geronimo/Jetty error sure smelled like a class loader problem, but I have no clue on the Geronimo/Tomcat. Note, in all cases I included a Geronimo deployment plan inside the WAR (/WEB-INF/geronimo-web.xml) Any ideas/advice is greatly appreciated. -- View this message in context: http://www.nabble.com/Geronimo-and- Grails-tp17223357s134p17223357.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Geronimo and Grails
David Jencks wrote: On May 13, 2008, at 9:55 PM, michaelg wrote: I am writing an article for IBM developerWorks on using Grails and Geronimo together. However, I am unable to deploy a Grails WAR to Geronimo. I first tried it with Geronimo 2.1.1 with Jetty. The error I got was a NoClassDefFound for org.apache.commons.fileupload.FileItemFactory. This class is the Geronimo repository, and is also included with the Grails war. It's the same version for both. Next I tried it with Geronimo 2.1.1 with Tomcat. This time I got a dom4j InvalidXPathException. Next I tried the Little G distribution. It worked perfectly. I had also tried standalone Tomcat with success as well, so I guess this should not have been too surprising. Obviously I have to point a finger at Grails or Geronimo, and since it works fine on Tomcat or Little G, I am pointing the finger at Geronimo. The Geronimo/Jetty error sure smelled like a class loader problem, but I have no clue on the Geronimo/Tomcat. Note, in all cases I included a Geronimo deployment plan inside the WAR (/WEB-INF/geronimo-web.xml) It doesn't matter whether the plan is included in the app or supplied externally. Any ideas/advice is greatly appreciated. I'm surprised you are seeing different results on "big" and "little" geronimo. You should be getting the same classloader for your app in either server. Would it have worked in little G because little G does not include commons-fileupload and so there is no chance of loading a class from one classloader and using it in another? Would it be possible to share your app so we can take a look at what is going on? If I was writing an article on geronimo I would structure the project so it consisted of one or more geronimo plugins and would show how to construct a specialized server including those plugins. This is by far easier if you are using maven, which I realize might not fit with the requirements you are working under. There are some instructions on how to do something similar here: http://cwiki.apache.org/confluence/display/GMOxDOC21/Constructing+a+special-purpose+server+using+maven thanks david jencks -- View this message in context: http://www.nabble.com/Geronimo-and-Grails-tp17223357s134p17223357.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Question on letting several EJB3 SLSB timer beans share the same interface
Hello all, I have about 25 (currently - will probably increase over time) timer beans that really only need to expose the method to schedule them. But I haven't been able to figure out how to share one interface class and still be able to inject the correct, particular timer out of the 25 different timer classes. Is this possible/has anyone done anything like this? Thanks, Jay
Re: Geronimo and Grails
The hidden classes works great for Jetty. I will make sure this is included in the IBM article so that other folks don't have this problem. Thanks for the help! On Wed, May 14, 2008 at 4:11 AM, Gianny Damour < [EMAIL PROTECTED]> wrote: > Hello, > > I have been running Grails 0.5+ applications on Geronimo 2.x and this works > w/o problem as long as you hide specific packages. Your geronimo-web.xml > should look like the following one: > > > http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.2";> > > > >yourGroupId >yourArtifactId >yourVersion >war > > > > org.springframework > org.apache.cxf > org.apache.commons > > > > >/yourContextPath > > > > > Thanks, > Gianny > > > On 14/05/2008, at 2:55 PM, michaelg wrote: > > >> I am writing an article for IBM developerWorks on using Grails and >> Geronimo >> together. However, I am unable to deploy a Grails WAR to Geronimo. >> >> I first tried it with Geronimo 2.1.1 with Jetty. The error I got was a >> NoClassDefFound for org.apache.commons.fileupload.FileItemFactory. This >> class is the Geronimo repository, and is also included with the Grails >> war. >> It's the same version for both. >> >> Next I tried it with Geronimo 2.1.1 with Tomcat. This time I got a dom4j >> InvalidXPathException. >> >> Next I tried the Little G distribution. It worked perfectly. I had also >> tried standalone Tomcat with success as well, so I guess this should not >> have been too surprising. >> >> Obviously I have to point a finger at Grails or Geronimo, and since it >> works >> fine on Tomcat or Little G, I am pointing the finger at Geronimo. The >> Geronimo/Jetty error sure smelled like a class loader problem, but I have >> no >> clue on the Geronimo/Tomcat. Note, in all cases I included a Geronimo >> deployment plan inside the WAR (/WEB-INF/geronimo-web.xml) >> >> Any ideas/advice is greatly appreciated. >> -- >> View this message in context: http://www.nabble.com/Geronimo-and- >> Grails-tp17223357s134p17223357.html >> Sent from the Apache Geronimo - Users mailing list archive at Nabble.com. >> >> >
Question on letting several EJB3 SLSB timer beans share one interface class
(This will probably end up appearing twice eventually - sorry) Hello all, I have about 25 (currently - will probably increase over time) timer beans that really only need to expose the method to schedule them. But I haven't been able to figure out how to share one interface class and still be able to inject the correct, particular timer out of the 25 different timer classes. Is this possible/has anyone done anything like this? Thanks, Jay
Re: POJO caching in geronimo
Hello, Gianny Damour and team. I want to list my questions and proposals to
the possible architecture and features of the Geronimo POJO cache that WADI
is going to implement soon.
Assume that we are exposing a POJO cache using GBean, so POJOCache is
available through JNDI (new
InitialContext().lookup("java:comp/env/cache"))if gbean-ref and
dependencies is included into Geronimo specific deployment
plan. The following questions are interesting for me.
1) I wonder what interfaces need to be exposed to access this POJO
Cache. We need to list these interfaces in "implements …" block when
declaring GBEAN and in gbean-ref / ref-type section. And developers will use
the pojo cache using these (this) interface as well.
I suspect that we need at least the following interfaces: JSR-107 JCache
related interfaces, plain java.util.Map, and the specific implementation
(ehcache, jcs) if someone needs to use that implementation directly.
First of all I want to consider JCache. JCache standard is far from being a
final and it is changing till now. Here is the list of limitation of the
current JSR standard
http://ehcache.sourceforge.net/documentation/jsr107.html (see section
"Problem and limitation"), so these limitations need to be worked around or
just emphasized for the developer if we decided to expose JCache as the
primary interface over geronimo pojo cache gbean.
The next question is on plain java.util.Map interface. In theory JCache
(JCache.CacheMap) implements Map, so one may do the cast "(Map) jcache" if
(s)he prefers plain Map over instantiating JCache or just uses Map in code
already. However http://shevek.livejournal.com/84313.html complains on a
slight incompatibility with the expected usage of Map, so our pojo gbean
might play as wrapper to resolve this incompatibility as well.
The last issue on getting underline implementation can probably be easily
solved with gettingBackingCache() method from JCache, although it quite
interesting to figure out (from configuration or JMX) which implementation
is tired with now.
2) The next question is on the number of GBean, that related to the
maintenance of pojo caching. Is the PojoCache gbean needs to be the only
gbean related to the cache, or (in distributed case) it may act as wrapper
to the actual ehcache/tabgosol/terracotta/wadi/jboss-cache-wrapper gbeans.
In the later case we just need to raise up the target gbean and provide all
configuration to it, and later just wired the actual GBEAN with the remote
(external) one. This may probably help to monitor and configure these caches
in more subtle way and allow to remain everything in the target application
the same (even a Geronimo-deployment descriptors), while just plug-in
(hot-replace) any remote / distributed / multilayered caching solution even
in runtime. Example, you just set up the application (war/ear) that have the
only dependency o local POJO cache gbean, that is used fast JCS back end
while no other authentificated plug-in discovering request occurs, but when
this happens your caching solution becomes multi tired (hierarchical) with
very light 1level local cache with specific expiration policy and 2level
distributed (memcache-d aware) cache.
3) The third question is on Statistic. We have some pretty tab on the
JMX section in Geronimo that seems to be used as viewer some graphics on
historical data. Really I don't know how to exposed some data from the Gbean
to there, but it seems to be nice to have exposed such a parameters as
number of hits per second, or the pluggable one statistic like "how many
request in percent to the total are done to the specific part of our cached
data" or "how many data are stored in the disk sue to short overflow of
overall memory restriction for the given local cache" (when storing is
switch on). The result of such a statistic is useful for capacity planning
and tuning the system.
It's interesting not only to plug such a statistic and get this from regular
Geronimo JMX tabs, but do this easily with no binding to the specific
underline implementation. I suppose that this may be done if we just wrap
any put / get methods of POJO GBean implements JCache with some JAMON (*).
Concrete interceptors (what collect in very specific cases) may be tired up
with GBean using AOP (**). Probably we need to integrate native JMX support
for such a project as well (***)
So we have three questions here: how to expose such a data to JMX statistic
tab, how to add user defined interceptors, and how to configure (switch off
such a tools on production when deploy or in runtime by JMX value)
4) The next question is where to locate specific configuration files
like ehcache.xml. The more precise question is where it is possible and
appropriate to locate such a files. I suppose that local cache parameters
(1level local cache gbean) may be located in war/ear, and the parameters for
regular distributed cache (2level distributed cache gbean) needs to be
located in config.
Re: Question on letting several EJB3 SLSB timer beans share one interface class
Hello again. Just in case someone else needs to do this. And, I must say that it is probably almost always a bad thing to do. In most cases, the need to have the exact same interface exposed on a range of classes that perform completely different functions should be rare. I just happen to have a block of Here is how you would have several session bean classes that utilize the same interface class: 1) Create the one interface class. 2) Create the multiple bean classes implementing the interface class. Here is where it gets interesting (not particularly interesting though) 3) Inject an instance of your bean using the following syntax: @EJB(beanName="SpecificBeanImplementationClass") private GenericInterface specificBeanInstance; That should have all been on one line, but it was too long so it auto-wrapped. And of course the pretend names should be replaced with your particular class, interface, and instance names. Maybe this might help someone else, Jay Jay McHugh wrote: (This will probably end up appearing twice eventually - sorry) Hello all, I have about 25 (currently - will probably increase over time) timer beans that really only need to expose the method to schedule them. But I haven't been able to figure out how to share one interface class and still be able to inject the correct, particular timer out of the 25 different timer classes. Is this possible/has anyone done anything like this? Thanks, Jay
Re: Question on letting several EJB3 SLSB timer beans share one interface class
Hello again. (This is a resend because I left out part of my first paragraph by accident) Just in case someone else needs to do this. And, I must say that it is probably almost always a bad thing to do. In most cases, the need to have the exact same interface exposed on a range of classes that perform completely different functions should be rare. I just happen to have a block of utility classes that do data cleanup for me. They are too processor/disk intensive to be run all at the same time so I implemented them as a series of timer beans that chain together. Since I may need to add or remove new processes at a later date - I wanted to have a generic interface to work with so that I could add/delete/swap the processes without having to worry about the exact action that the timer would be performing. Here is how you would have several session bean classes that utilize the same interface class: 1) Create the one interface class. 2) Create the multiple bean classes implementing the interface class. Here is where it gets interesting (not particularly interesting though) 3) Inject an instance of your bean using the following syntax: @EJB(beanName="SpecificBeanImplementationClass") private GenericInterface specificBeanInstance; That should have all been on one line, but it was too long so it auto-wrapped. And of course the pretend names should be replaced with your particular class, interface, and instance names. Maybe this might help someone else, Jay Jay McHugh wrote: (This will probably end up appearing twice eventually - sorry) Hello all, I have about 25 (currently - will probably increase over time) timer beans that really only need to expose the method to schedule them. But I haven't been able to figure out how to share one interface class and still be able to inject the correct, particular timer out of the 25 different timer classes. Is this possible/has anyone done anything like this? Thanks, Jay
