Re: How to convert from Tomcat to Geronimo
I'd like to suggest you take a look at the Apache OpenEJB plugin for Tomcat (http://openejb.apache.org/tomcat.html). Basically, you drop the openejb.war into Tomcat and you get a JEE compatible Tomcat. OpenEJB also has support for Collapsed EAR deployment (http://openejb.apache.org/collapsed-ear.html ) which vastly simplifies the development and deployment of EJBs, persistence units and web-services (this will be most likely make it into the next EJB spec). If you decide take a look and run into any problems, hit us up on the OpenEJB mailing list (http://openejb.apache.org/mailing-lists.html). -dain On Jun 18, 2008, at 4:20 PM, Tim Harsch wrote: Hi all, I’m fairly new to J2EE in general, so please forgive my naïve question. I would like to take a simple hello world type JSP and Servlet project running via WTP 2.0.2 on Europa. Running on Apache Tomcat Server it runs fine. But then, after stopping Tomcat, when I try to right-click on project and “Run as…”, “Run on Server” and choose Geronimo 2.1 then no browser window will open and no page is showed. I can however manually start the Geronimo server in the Servers pane, and navigate to localhost:8080 and see that the server is running. I noticed this fairly recent post, which seems very similar to my problem. http://www.eclipse.org/newsportal/article.php?id=16603group=eclipse.webtools#16603 Thanks, Tim
Re: EJB-QL Compiler Factory
Starting with Geronimo 2.0 those properties are ignored. The new versions of Geronimo use OpenEJB 3.0 which has a brand new CMP implementation based on OpenJPA. OpenJPA is a lot smarter then our old CMP engine and one of its many tricks is the ability to automatically discover the database type and adjust the SQL dialect accordingly. -dain On Sep 10, 2007, at 8:26 PM, Efren Gonzalez wrote: Hello On the openejb-jar documentation, it says that the ejb-ql-compiler- factory and db-syntax-factory are to specify classes that know about a certain RDBMS, and that the default is for Derby. I have used CMP EJBs with MySQL without specifying those two parameters (it uses the Derby defaults I suppose) and haven't noticed any particular issue, but I was wondering if there are specific classes for MySQL. Does anyone know if there are such classes? Maybe using the Derby defaults work OK with MySQL, but performance could be improved by using specific MySQL ones? I have been looking in other threads and on the TranQL site with no luck, hope someone can provide any clue on this. Thanks!! Efrén gonzale.vcf
Re: AW: AW: Using JacORB not possible within Geronimo?
That is a result of how Geronimo did the integration with OpenEJB not the OpenEJB project itself, which has no Yoko dependencies. -dain On Jul 24, 2007, at 12:39 AM, Andersch, Jens (DWBI) wrote: Unfortunately openejb has a dependency on Yoko. Have a look at .../repository/org/apache/geronimo/configs/openejb/ 2.0-M6/ openejb-2.0-M6.car/META-INF/config.ser. How can I get rid of this dependency and tell openejb to use jacorb? thanks Jens -Ursprüngliche Nachricht- Von: Dain Sundstrom [mailto:[EMAIL PROTECTED] Gesendet: Montag, 23. Juli 2007 19:33 An: user@geronimo.apache.org Betreff: Re: AW: Using JacORB not possible within Geronimo? The actual code we use to create the orb bound to java:comp/ORB is simply ORB orb = ORB.init(); so it should what with what ever you have configured as the default ORB in your VM. OpenEJB doesn't even have a dependency on Yoko. -dain On Jul 20, 2007, at 8:09 AM, David Jencks wrote: The yoko stuff is in the connector-deployer defaultEnvironment so we can construct working jndi references so you can look up java:comp/ORB and IIRC it's in the ejb stuff for a similar reason. So if you don't need an automatic resource-ref to java:comp/ORB or anything similar I think you can override the defaultEnvironments in config.xml for these two builders. I think that in geronimo 1.2 we were able to more easily run without an orb but with the annotation stuff and various automatic jndi references to orbs it has become more difficult. I doubt we'll get to it by 2.0 but you might file a JIRA tracking the problems you've run into here. thanks david jencks On Jul 20, 2007, at 1:42 AM, Andersch, Jens (DWBI) wrote: Thank you for your help, That seems to work. I only replaced the yoko jars within the endorsed dir by the jacorb jars and made the following changes within config.xml: module name=org.apache.geronimo.configs/j2ee-corba-yoko/2.0-M6/ car gbean load=false name=NameServer ... /gbean gbean load=false name=Server ... /gbean gbean load=false name=UnprotectedServer ... /gbean /module I am not really happy with this solution because I am not sure if I will get any side effects in the future. What should I do with the connector-deployer module which also depends on yoko classes ? If I delete yoko from the repository subdir I get a lot of exceptions because of the dependencies in the connector-deployer module. Moreover the openejb classes throw exceptions if they can't find the yoko jars in the repository. So I have to keep them. module name=org.apache.geronimo.configs/connector-deployer/2.0- M6/car gbean name=ResourceRefBuilder attribute name=eeNamespaceshttp://java.sun.com/xml/ ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute attribute name=defaultEnvironment environment xmlns=http://geronimo.apache.org/xml/ ns/deployment-1.2 dependencies dependency groupIdorg.apache.geronimo.configs/ groupId artifactIdj2ee-corba-yoko/ artifactId typecar/ type /dependency / dependencies /environment /attribute /gbean gbean name=AdminObjectRefBuilder attribute name=eeNamespaceshttp://java.sun.com/xml/ ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute /gbean gbean name=ClientResourceRefBuilder attribute name=eeNamespaceshttp://java.sun.com/xml/ ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute attribute name=defaultEnvironment environment xmlns=http://geronimo.apache.org/xml/ ns/deployment-1.2 dependencies dependency groupIdorg.apache.geronimo.configs/ groupId artifactIdclient-corba- yoko/artifactId typecar/ type /dependency / dependencies /environment /attribute /gbean /module Jens Von: David Jencks [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 18. Juli 2007 20:36 An: user@geronimo.apache.org Betreff: Re: Using JacORB not possible within Geronimo? We havent' tried this, and you probably won't be able to use the corba ejb transport I would start by moving to the almost released geronimo 1.2 or also close to release 2.0 since they are set up to use a non-jdk orb, namely yoko. I think it will be easier to switch which non- jdk orb you use than switch from jdk orb to non-jdk orb. You should then remove the yoko corba spec jars from lib/endorsed and the yoko jars from the geronimo repository and comment out stuff in config.xml until geronimo starts :-) Now put the jacORB spec jar(s) in lib/endorsed and try your app. Hope this helps david jencks On Jul 17, 2007, at 11:46 PM, Andersch, Jens (DWBI) wrote: Hi All, does anyone know
Re: AW: Using JacORB not possible within Geronimo?
The actual code we use to create the orb bound to java:comp/ORB is simply ORB orb = ORB.init(); so it should what with what ever you have configured as the default ORB in your VM. OpenEJB doesn't even have a dependency on Yoko. -dain On Jul 20, 2007, at 8:09 AM, David Jencks wrote: The yoko stuff is in the connector-deployer defaultEnvironment so we can construct working jndi references so you can look up java:comp/ORB and IIRC it's in the ejb stuff for a similar reason. So if you don't need an automatic resource-ref to java:comp/ORB or anything similar I think you can override the defaultEnvironments in config.xml for these two builders. I think that in geronimo 1.2 we were able to more easily run without an orb but with the annotation stuff and various automatic jndi references to orbs it has become more difficult. I doubt we'll get to it by 2.0 but you might file a JIRA tracking the problems you've run into here. thanks david jencks On Jul 20, 2007, at 1:42 AM, Andersch, Jens (DWBI) wrote: Thank you for your help, That seems to work. I only replaced the yoko jars within the endorsed dir by the jacorb jars and made the following changes within config.xml: module name=org.apache.geronimo.configs/j2ee-corba-yoko/2.0-M6/ car gbean load=false name=NameServer … /gbean gbean load=false name=Server … /gbean gbean load=false name=UnprotectedServer … /gbean /module I am not really happy with this solution because I am not sure if I will get any side effects in the future. What should I do with the connector-deployer module which also depends on yoko classes ? If I delete yoko from the repository subdir I get a lot of exceptions because of the dependencies in the connector-deployer module. Moreover the openejb classes throw exceptions if they can’t find the yoko jars in the repository. So I have to keep them. module name=org.apache.geronimo.configs/connector-deployer/2.0- M6/car gbean name=ResourceRefBuilder attribute name=eeNamespaceshttp://java.sun.com/xml/ ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute attribute name=defaultEnvironment environment xmlns=http://geronimo.apache.org/xml/ ns/deployment-1.2 dependencies dependency groupIdorg.apache.geronimo.configs/ groupId artifactIdj2ee-corba-yoko/ artifactId typecar/ type /dependency / dependencies /environment /attribute /gbean gbean name=AdminObjectRefBuilder attribute name=eeNamespaceshttp://java.sun.com/xml/ ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute /gbean gbean name=ClientResourceRefBuilder attribute name=eeNamespaceshttp://java.sun.com/xml/ ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute attribute name=defaultEnvironment environment xmlns=http://geronimo.apache.org/xml/ ns/deployment-1.2 dependencies dependency groupIdorg.apache.geronimo.configs/ groupId artifactIdclient-corba- yoko/artifactId typecar/ type /dependency / dependencies /environment /attribute /gbean /module Jens Von: David Jencks [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 18. Juli 2007 20:36 An: user@geronimo.apache.org Betreff: Re: Using JacORB not possible within Geronimo? We havent' tried this, and you probably won't be able to use the corba ejb transport I would start by moving to the almost released geronimo 1.2 or also close to release 2.0 since they are set up to use a non-jdk orb, namely yoko. I think it will be easier to switch which non- jdk orb you use than switch from jdk orb to non-jdk orb. You should then remove the yoko corba spec jars from lib/endorsed and the yoko jars from the geronimo repository and comment out stuff in config.xml until geronimo starts :-) Now put the jacORB spec jar(s) in lib/endorsed and try your app. Hope this helps david jencks On Jul 17, 2007, at 11:46 PM, Andersch, Jens (DWBI) wrote: Hi All, does anyone know, if it is possible to deploy an own ear which contains a connector rar that uses JacORB instead of the ORB Implementation used by Geronimo 1.1.1 itself. I have the problem that the class loader loads the org.omg classes from …/repository/geronimo-spec/geronimo-spec-corba/1.0/geronimo- spec-corba-1.0.jar and my jacorb classes from the jar included in the rar. Unfortunately some org.omg classes do not have the same versions as
Re: Still remaining problems using openJPA
On Jul 23, 2007, at 9:40 AM, Ueberbach, Michael wrote: Hello, meanwhile I got along a bit further in deploying and using an EJB 3.0 application on g2 (M6). But there still remain some open questions: 1. I did openJPA enhancing on build time (via ant script) to compare the results with enhancing on deploy time. In both cases I didn't manage to use the property acces mode for an entity bean. In all cases I tried the openJPA parser says that there was the attempt to use both field and property access. Only one access method is permitted. So at last I changed my code to field access mode. I think your going to have to hit up the OpenJPA mailing list ([EMAIL PROTECTED]) for this one. 2. When using a certain dynamic query I got the following exception An error occurred while parsing the query filter 'SELECT person FROM Person AS person WHERE person.name LIKE ?1 ESCAPE '|''. Error message: 1.0.0-SNAPSHOT-SNAPSHOT nonfatal user error org.apache.openjpa.kernel.jpql.ParseException: Encountered ESCAPE at character 63, but expected: [AND, GROUP, HAVING, OR, ORDER, EOF]. While the JPQL Language Reference says: 2.5.9 The syntax for the use of the comparison operator [ NOT ] LIKE in a conditional expression is as follows: string_expression [NOT] LIKE pattern_value [ESCAPE escape_character] I know old versions of mysql did not support the SQL standard LIKE EXCAPE clause, but I don't know if mysql ever got around to implementing this. Looking at the openjpa docs, it is not listed as a limitation of the mysql integration (http://openjpa.apache.org/docs/ latest/manual/manual.html#dbsupport_mysql_issues) I suggest you read that over anyway, so you don't have any surprises with mysql. Anyway, I suggest you first look at the mysql SQL documentation to see if it implements ESCAPE. If it does, you most likely need to upgrade. If not, I don't think there is anything you can do other then remove the ESCAPE clause. 3. The most important and irritating problem is the following: After starting the database and then geronimo the first access to persistent data by an ejb method results in the following exception: ERROR [OpenEJB] The bean instances business method encountered a system exception: Access denied for user 'geronimo'@'localhost' to database 'GERONIMO_DB' 1.0.0-SNAPSHOT-SNAPSHOT nonfatal general error org.apache.openjpa.persistence.PersistenceException: Access denied for user 'geronimo'@'localhost' to database 'GERONIMO_DB' The access is denied because the name of the database is geronimo_db (lower cases) and MySQL on linux works case-sensitive. But the correct writing of the name has been used when deploying the database pool. What is most astonishing is the following!!! After stopping the database the attempt to get access to data results in [MCFConnectionInterceptor] Error occurred creating ManagedConnection for [EMAIL PROTECTED] javax.resource.spi.ResourceAllocationException: Unable to obtain physical connection to jdbc:mysql://localhost:3306/geronimo_db at org.tranql.connector.jdbc.JDBCDriverMCF.getPhysicalConnection (JDBCDriverMCF.java:98) This is clear and expectable. But ... after starting the database again: Everything works! I can reproduce the whole thing. Conclusion at the moment is: To get a working connection to the database I have to force the above error situation first. Very strange! May someone has an idea about this behaviour? This is something we should be able to help you with. Unfortunately, I this isn't my area, but hopefully David Jencks will respond quickly :) -dain
Re: AW: Using JacORB not possible within Geronimo?
On Jul 23, 2007, at 10:51 AM, Rick McGuire wrote: Dain Sundstrom wrote: The actual code we use to create the orb bound to java:comp/ORB is simply ORB orb = ORB.init(); so it should what with what ever you have configured as the default ORB in your VM. OpenEJB doesn't even have a dependency on Yoko. I would hope this is not true. ORB.init() returns the singleton ORB instance, which is only guaranteed to be functional for creating Any and TypeCode instances. It is true, and that is all the default orb bound into jndi is good for per spec. Any thing beyond that is a vendor specific feature. -dain
Re: EJB 2.1 CMR Bi-Directional with Compound Key
I also suggest you skip CMP and move directly to JPA. Knowing CMP isn't going to help you lean JPA at all. -dain On May 30, 2007, at 1:17 PM, Jay D. McHugh wrote: Mark, I thought about suggesting that you use JPA, but I wasn't sure if there was a reason 'bigger than you' that was requiring you to use EJB2. I tried to learn how to use EJB2 entity beans and I was defeated. I am _very_ glad that OpenJPA is integrated into Geronimo now - It is making my life much easier. If you have any questions once you start working with it I'd be happy to answer any questions you have (if I can). (BTW: Thanks to any and every one who had a part in getting JPA working in Geronimo!) Jay Mark Aufdencamp wrote: Thanks for the response Gianny. I've wacked out a small demo that I'm working on right now with a session facade, the three beans, and the database tables. I'll let you all know how it goes:) I'm planning on hittting EJB 3.0 hard once I understand this. I want to comprehend the legacy way first! Original Message Subject: Re: EJB 2.1 CMR Bi-Directional with Compound Key From: Gianny Damour [EMAIL PROTECTED] Date: Wed, May 30, 2007 7:07 am To: user@geronimo.apache.org Hi Mark, I had a look to the openejb-jar DD and I think you need to drop the foreign-key-column-on-source/ element from the Committee- CommitteeMembers relation. This optional element means that the foreign key columns declared in the following cmr-field-mapping elements are defined by the CMP declared by relationship-role-source. So, this should work: ejb-relation ejb-relation-nameCommittee-CommitteeMembers/ejb-relation- name ejb-relationship-role ejb-relationship-role-nameCommittee-has-many- CommitteeMembers/ ejb-relationship-role-name relationship-role-source ejb-nameCommitteeEntity/ejb-name /relationship-role-source cmr-field cmr-field-namecommitteeMembers/cmr-field-name /cmr-field role-mapping cmr-field-mapping key-columnCommitteeId/key-column foreign-key-columnCommitteeId/foreign-key-column /cmr-field-mapping /role-mapping /ejb-relationship-role /ejb-relation Also, you do not need to declare both sides of a relationship: the above is enough to declare the CMR mapping for the Committee- CommitteeMembers relation. BTW, I strongly recommend you to upgrade to OpenEJB3: this should be a seamless migration from a CMP perspective as the OpenEJB guys have done a fantastic work at writing an OpenEJB2 schema converter. Thanks, Gianny On 30/05/2007, at 1:07 AM, Mark Aufdencamp wrote: I could really use some help on this! I have a two Entity beans with a bi-directional relationship, committees and committee_members. Committees has a single field primary key of committeeId. Committee_members has a compound primary key of CommitteeId+UserId. A Foreign Key constraint has been defined for the committee_members table based on the committeeId. I can't seem to get this to deploy and believe it's my openejb-jar.xml deployment descriptor in the relationship section. I've looked at examples from JBoss and Sun, so I'm fairly certain my ejb- jar.xml is correct. Does anyone have a working example of a bi-directional relatioship where the many table has a compound key that I can take a look at? Where can I find documentation on how OpenEJB and TranQL interact to create the O/R map? This knowledge are really seems to be lacking documentation in Geronimo. I'd really like to draw some pretty pictures of tables and beans with the seven different relationship types defined for EJB 2.1. This would be good preliminary work for documenting EJB 3.0 examples. Please help me learn, so I can contribute:) TIA, Mark Aufdencamp [EMAIL PROTECTED] http://email.secureserver.net/ pcompose.php? aEmlPart=0type=replyfolder=INBOX.Apache.Geronimo.Usersuid=108#Comp ose
Re: Openejb: This principle is not authorized
I'm not sure exactly what you are doing, so I'll explain how an
OpenEJB JNDI based login works.
On the client side when you create a JNDIContext with the principal
and credentials set the OpenEJB JNDI code will open a connection to
the server and perform a remote login. The server redirects the
login request to the OpenEJB SecurityService.login(String user,
String pass) method. The SecurityService authenticates the user and
returns a security token (java.lang.Object). The client stashes off
the token and send it on ever request.
To start with, your login module configuration will need to be on the
server side. In OpenEJB standalone, you can modify the $
{OPENEJB_HOME}/conf/login.conf file. I don't know what the
equivalent configuration is for Geronimo. Secondly, the current
security service code has the name of the login module hard coded.
In OpenEJB standalone it is hard coded to PropertiesLogin and in the
Geronimo integration it is hard coded to OpenEJB.
If you get stuck and want to debug the server, all of the security
magic for ejb clients happens in GeronimoSecurityService or
SecurityServiceImpl for OpenEJB standalone.
-dain
On Apr 13, 2007, at 7:07 AM, Bert_nor wrote:
Standalone application
login.config:
dw_realm {
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator
required
host=localhost
port=4242
realm=dw_realm;
};
LoginContext context = new LoginContext(dw_realm,...);
context.login();
Properties props = new Properties();
props.put(java.naming.factory.initial,
org.apache.openejb.client.RemoteInitialContextFactory);
props.put(java.naming.factory.host, 127.0.0.1);
props.put(java.naming.factory.port, 4201);
props.put(java.naming.security.principal, ...);
props.put(java.naming.security.credentials, ...);
Context remoteContext = remoteContext = new InitialContext(props);
javax.naming.AuthenticationException: This principle is not
authorized.
at org.apache.openejb.client.JNDIContext.authenticate
(JNDIContext.java:144)
at
org.apache.openejb.client.JNDIContext.getInitialContext
(JNDIContext.java:116)
at javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:247)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.init(InitialContext.java:197)
It's exception thrown from
org.apache.geronimo.openejb.GeronimoSecurityService.login(String user,
String pass) {
LoginContext context = new LoginContext(OpenEJB, new
UsernamePasswordCallbackHandler(user,
pass));--javax.security.auth.login.LoginException: No LoginModules
configured for OpenEJB
Can be use realm for the current user?
--
View this message in context: http://www.nabble.com/Openejb%3A-This-
principle-is-not-authorized-tf3571824s134.html#a9979641
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.
Re: JPA in geronimo
On Feb 24, 2007, at 2:52 PM, Dario Andrade wrote: How do I assemble a project in order to use geronimo's jpa support? Does anyone recommend toplink jar lib or openjpa to be added to my class path? I highly recommend OpenJPA over toplink. I find toplink much more picky and hard to understand then OpenJPA. Also, I find it easier to get help and fixes from OpenJPA. -dain
Re: JPA in geronimo
On Feb 25, 2007, at 2:11 AM, David Jencks wrote: On Feb 24, 2007, at 8:47 PM, Lasantha Ranaweera wrote: Hi David, I have been going on this same jpa sample given on testsuite and having a problem too (may be I am missing some basic thing in JSR). Anyway thought to give a try on this same thread it looks iron is hot here and it will give some insight on G to our users too. ;) In my debugging enviroment shows that above sample application creates 3 PersistenceUnitGBeans. The one I dont understand it named 'cmp'. Where does it comes from ? Either 'persistence.xml' or 'openejb-jar.xml' doesn't have that information know. Do you have any idea what is I am missing here? That one is created by some magic code dain wrote to map cmp 2.1 entity beans to jpa. Apparently it shows up even if you have no entity beans. It should only be created if your application has CMP entities. If notice this code creating a persistence unit for applications without CMP entities, it is a bug. -dain
Re: Is there a vendor independent way of accessing EJBs from a standalone client?
I suggest you put an interface in that abstracts the lookups. This will let your code easily switch between vendors. -dain On Feb 22, 2007, at 3:13 PM, Ryan wrote: You're right, I didn't quite explain things 100%. I would like to have a .ear file that contains EJBs and a Swing client. I would like to be able to deploy that .ear and have it work on Glassfish or Geronimo, but don't want to change naming lookups, etc. I really just want to have the option of switching vendors at a later date. I will always use a matching app server and client container (ie: Geronimos AS with Geronimo ACC, or Glassfish AS with Glassfish ACC). Ryan Jencks wrote: I'm unclear on whether you plan to run the app client on the same vendors product as the ejb itself. If you plan to use 2 vendors you have to use corba. If you plan to use the app client container and the ejb container from geronimo, what you are trying should work. However for geronimo you would have to have deployed the ejb application first (assuming it is not packaged in an ear with the app client) and the ejb app would have to be a parent of the client app. Under these circumstances the deployers should be able to find your ejb at deploy time and figure out how to hook up to it when you run the app client. thanks david jencks On Feb 22, 2007, at 1:46 AM, Ryan wrote: Hi, I'm working at setting up an application client and am having some difficulty accessing EJBs on the server. I'm running my client using an application client container and am trying it out on a few different application servers. However, I'm having difficulty finding a way to lookup EJBs in a vendor independent manner. Specifically, almost every doc I can find has some variation of: Context initialContext = new InitialContext(); Object ref = initialContext.lookup(some vendor specific name here); If I replace some vendor specific name here with the proper vendor specific name for each app server and re-deploy everything works. At first I thought I could use application-client.xml to name each EJB and have the container(s) take care of the mapping, but I haven't had any luck with this approach. I tried something like this (relevant parts only): ejb-ref ejb-ref-nameejb/test1234/ConnectionTester/ejb-ref-name ejb-ref-typeSession/ejb-ref-type remotedomain.ejb.interfaces.ConnectionTesterRemote/remote /ejb-ref When I deploy to Glassfish using the above I end up with a JNDI name of ejb/test1234/ConnectionTester and can look it up using java:comp/env/ejb/test1234/ConnectionTester. However, when I try to deploy to Geronimo, I get the following error (while deploying): org.apache.openejb.OpenEJBException: Cannot find bean ejb/test1234/ConnectionTester referenced by bean GeronimoEnc. Obviously I'm missing something because Glassfish appears to use 'ejb-ref-name' as a type of alias for the EJB name while Geronimo thinks it contains the name of an existing EJB. Maybe I'm just not thinking clearly tonight, but isn't there some kind of simple, standard way of looking up an EJB from a standalone client? Is vendor independence even a realistic goal (that's what the spec is for right)? Thanks in advance for any help, Ryan P.S. Sorry for the formatting :-(
Re: Gbean within a signed jar
Alternatively, just change the code that complains about the signature. We could add a flag to the Geronimo class loader to hide all signing data. -dain On Feb 6, 2007, at 11:54 AM, Spotts, Joel (ISS Atlanta) wrote: I have a gbean packaged within a signed jar that is placed in my EAR. Trouble is it seems that geronimo uses proxy classes on the gbean class files, which results in the dreaded: java.lang.SecurityException: class ...'s signer information does not match signer information of other classes in the same package when geronimo attempts to start the gbean. Anyone have a solution to this problem other than not signing the jar? Thanks, Yoel Spotts
Re: AW: other appserver/ejb2.1 to geronimo 2.0 migration strategy?
On Jan 25, 2007, at 1:47 AM, Hans J. Prueller wrote: David, thank you for your thoughts. You provided good entry points for me. I mentioned hibernate specifically because we already are using hibernate and CMP in parallel within our project (as CMP2.x sometimes does not fulfill all needs). targeting JPA instead of hibernate specifically is essential –thank you for that. If you can use hibernate in jpa mode, we will be able to support that. I also would like to do a one-by-one migration because I am afraid if we would migrate the whole project at once, everything could collapse. Doing smaller steps provides more control I think. That is exactly why I wrote the OpenEjb 3 cmp engine on JPA, so beans can be migrated one at at time. Migrating a whole app all at once is just to risky. However this would mean that you would need to start by generating the cmp2 mapping info. so this is what should to be contained in the Geronimo deployment plan right? are deployment plans required also in Geronimo2 ? (I think there shouldn’t be any more “vendor” specific DDs in Java EE 5). But for compatibility reasons They won't be required, but vendor-DD less deployment is fully implemented yet. You can deploy an ejb module without any plans in 2.0-M2, but I don't you can deploy any other module types without a plan. with my EJB2.1 CMP beans I think I won’t come around to provide a mapping file at all ;-) For OpenEJB3 we use a standard JPA entity-mapping.xml file for the mappings. I asked about XDoclet support for Geronimo some months ago, at that point in time there was no usable version around. As Java 2 EE 1.4 requires Java 1.4 I cannot work with annotations unless the whole app is migrated, so XDoclet would be of great help…? J2ee 1.4 requires java 1.4+. You can run in Java5 if you want. -dain
Weekly: Geronimo 1.2-r483346
Geronimo 1.2-r483346 - Dec 6, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r483346/ geronimo-1.2-r483346-src.tar.gz geronimo-1.2-r483346-src.zip geronimo-framework-1.2-r483346.tar.gz geronimo-framework-1.2-r483346.zip geronimo-jetty-j2ee-1.2-r483346.tar.gz geronimo-jetty-j2ee-1.2-r483346.zip geronimo-jetty-minimal-1.2-r483346.tar.gz geronimo-jetty-minimal-1.2-r483346.zip geronimo-tomcat-j2ee-1.2-r483346.tar.gz geronimo-tomcat-j2ee-1.2-r483346.zip geronimo-tomcat-minimal-1.2-r483346.tar.gz geronimo-tomcat-minimal-1.2-r483346.zip Changelog: http://people.apache.org/dist/geronimo/unstable/1.2-r483346/CHANGELOG.txt NOTE: This build is not an official release, nor tested, and should be considered unstable.
Weekly: Geronimo 1.2-r480769
Geronimo 1.2-r480769 - Nov 29, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r480769/ geronimo-1.2-r480769-src.tar.gz geronimo-1.2-r480769-src.zip geronimo-framework-1.2-r480769.tar.gz geronimo-framework-1.2-r480769.zip geronimo-jetty-j2ee-1.2-r480769.tar.gz geronimo-jetty-j2ee-1.2-r480769.zip geronimo-jetty-minimal-1.2-r480769.tar.gz geronimo-jetty-minimal-1.2-r480769.zip geronimo-tomcat-j2ee-1.2-r480769.tar.gz geronimo-tomcat-j2ee-1.2-r480769.zip geronimo-tomcat-minimal-1.2-r480769.tar.gz geronimo-tomcat-minimal-1.2-r480769.zip Changelog: http://people.apache.org/dist/geronimo/unstable/1.2-r480769/CHANGELOG.txt NOTE: This build is not an official release, nor tested, and should be considered unstable.
Weekly: Geronimo 1.2-r475585
Geronimo 1.2-r475585 - Nov 1, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r475585/ geronimo-1.2-r475585-src.tar.gz geronimo-1.2-r475585-src.zip geronimo-framework-1.2-r475585.tar.gz geronimo-framework-1.2-r475585.zip geronimo-jetty-j2ee-1.2-r475585.tar.gz geronimo-jetty-j2ee-1.2-r475585.zip geronimo-jetty-minimal-1.2-r475585.tar.gz geronimo-jetty-minimal-1.2-r475585.zip geronimo-tomcat-j2ee-1.2-r475585.tar.gz geronimo-tomcat-j2ee-1.2-r475585.zip geronimo-tomcat-minimal-1.2-r475585.tar.gz geronimo-tomcat-minimal-1.2-r475585.zip Changelog: http://people.apache.org/dist/geronimo/unstable/1.2-r475585/CHANGELOG.txt NOTE: This build is not an official release, nor tested, and should be considered unstable.
Weekly: Geronimo now with JPA (tm)
With this week's snapshot of Geronimo we have OpenJPA integration. This currently only works with the geronimo-jetty-j2ee server. Here is a sample openejb-jar.xml file: http://svn.apache.org/viewvc/geronimo/sandbox/javaee5/itests-jee5/jpa/ejb/src/main/resources/META-INF/openejb-jar.xml?revision=HEADview=markup Let us know if you have any problems, -dain Geronimo 1.2-r472744 - Nov 8, 2006 -- http://people.apache.org/dist/geronimo/unstable/1.2-r472744/ geronimo-1.2-r472744-src.tar.gz geronimo-1.2-r472744-src.zip geronimo-framework-1.2-r472744.tar.gz geronimo-framework-1.2-r472744.zip geronimo-jetty-j2ee-1.2-r472744.tar.gz geronimo-jetty-j2ee-1.2-r472744.zip geronimo-jetty-minimal-1.2-r472744.tar.gz geronimo-jetty-minimal-1.2-r472744.zip geronimo-tomcat-j2ee-1.2-r472744.tar.gz geronimo-tomcat-j2ee-1.2-r472744.zip geronimo-tomcat-minimal-1.2-r472744.tar.gz geronimo-tomcat-minimal-1.2-r472744.zip Changelog: http://people.apache.org/dist/geronimo/unstable/1.2-r472744/CHANGELOG.txt NOTE: This build is not an official release, nor tested, and should be considered unstable. Geronimo 1.2-r472744 - Nov 1, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r472744/ geronimo-1.2-r472744-src.tar.gz geronimo-1.2-r472744-src.zip geronimo-framework-1.2-r472744.tar.gz geronimo-framework-1.2-r472744.zip geronimo-jetty-j2ee-1.2-r472744.tar.gz geronimo-jetty-j2ee-1.2-r472744.zip geronimo-jetty-minimal-1.2-r472744.tar.gz geronimo-jetty-minimal-1.2-r472744.zip geronimo-tomcat-j2ee-1.2-r472744.tar.gz geronimo-tomcat-j2ee-1.2-r472744.zip geronimo-tomcat-minimal-1.2-r472744.tar.gz geronimo-tomcat-minimal-1.2-r472744.zip Changelog: http://people.apache.org/dist/geronimo/unstable/1.2-r472744/CHANGELOG.txt NOTE: This build is not an official release, nor tested, and should be considered unstable.
Weekly: Geronimo 1.2-r470164
Geronimo 1.2-r470164 - Nov 1, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r470164/ geronimo-1.2-r470164-src.tar.gz geronimo-1.2-r470164-src.zip geronimo-framework-1.2-r470164.tar.gz geronimo-framework-1.2-r470164.zip geronimo-jetty-j2ee-1.2-r470164.tar.gz geronimo-jetty-j2ee-1.2-r470164.zip geronimo-jetty-minimal-1.2-r470164.tar.gz geronimo-jetty-minimal-1.2-r470164.zip geronimo-tomcat-j2ee-1.2-r470164.tar.gz geronimo-tomcat-j2ee-1.2-r470164.zip geronimo-tomcat-minimal-1.2-r470164.tar.gz geronimo-tomcat-minimal-1.2-r470164.zip Changelog: http://people.apache.org/dist/geronimo/unstable/1.2-r470164/CHANGELOG.txt NOTE: This build is not an official release, nor tested, and should be considered unstable.
Re: Weekly: Geronimo 1.2-r465304
On Oct 18, 2006, at 6:59 PM, Kevan Miller wrote: On Oct 18, 2006, at 5:19 PM, Dain Sundstrom wrote: Geronimo 1.2-r465304 - Oct 18, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r465304/ ... NOTE: This build is not an official release, nor tested, and should be considered unstable. Dain, The jetty-j2ee server does not start for me. Does it work for you? I test started all of the binaries before uploading, but I'll download geronimo-jetty-j2ee-1.2-r465304.tar.gz and try to start it. -dain
Re: Weekly: Geronimo 1.2-r465304
On Oct 19, 2006, at 9:22 AM, Dain Sundstrom wrote: On Oct 18, 2006, at 6:59 PM, Kevan Miller wrote: On Oct 18, 2006, at 5:19 PM, Dain Sundstrom wrote: Geronimo 1.2-r465304 - Oct 18, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r465304/ ... NOTE: This build is not an official release, nor tested, and should be considered unstable. Dain, The jetty-j2ee server does not start for me. Does it work for you? I test started all of the binaries before uploading, but I'll download geronimo-jetty-j2ee-1.2-r465304.tar.gz and try to start it. It works for me on my mac: $ wget http://people.apache.org/dist/geronimo/unstable/1.2-r465304/ geronimo-jetty-j2ee-1.2-r465304.tar.gz 09:22:36 (528.97 KB/s) - `geronimo-jetty-j2ee-1.2-r465304.tar.gz' saved [49455963/49455963] $ tar -zxf geronimo-jetty-j2ee-1.2-r465304.tar.gz tar: A lone zero block at 122798 $ java -jar geronimo-jetty-j2ee-1.2-r465304/bin/server.jar [] 100% 42s Startup complete Geronimo Application Server started -dain
Re: Weekly: Geronimo 1.2-r465304
On Oct 19, 2006, at 11:27 AM, Aaron Mulder wrote: In 1.1.1, the majority of the startup delay is in the console module. Dain suggested it's because we precompile the JSPs, so each one becomes a servlet, so each one becomes a GBean, and starting GBeans is what's slow. I found it hard to believe they're *that* slow, but I don't have any factual basis for disputing the claim... :) In any case, it would be great to investigate and optimize the startup time, or maybe introduce an option for a module that would kick it's startup into a background task or something. I've timed it before. Starting each gbean takes a very very long time. I'd also guess that as you add more gbeans it gets slower. If I had to bet, I'd blame AbstractName and AbstractNameQuery. When we used object names we indexed the names so queries were faster, and now we do a liner compare for each life-cycle event fired. -dain
Re: Weekly: Geronimo 1.2-r465304
On Oct 19, 2006, at 12:22 PM, Kevan Miller wrote: On Oct 19, 2006, at 2:01 PM, Dain Sundstrom wrote: I'm using Java 1.4.2_09. Me too. :-) 'java -jar server.jar' on 1.4.2 works for me. './geronimo.sh run' on 1.4.2 does not work for me './geronimo.sh run' on 1.5 works for me. geronimo.sh run works for me in Java 1.4 $ geronimo-jetty-j2ee-1.2-r465304/bin/geronimo.sh run Using GERONIMO_BASE: /Users/dain/t/geronimo-jetty-j2ee-1.2-r465304 Using GERONIMO_HOME: /Users/dain/t/geronimo-jetty-j2ee-1.2-r465304 Using GERONIMO_TMPDIR: /Users/dain/t/geronimo-jetty-j2ee-1.2-r465304/ var/temp Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/ Versions/CurrentJDK/Home Booting Geronimo Kernel (in Java 1.4.2_09)... Starting Geronimo Application Server v1.2-r465304 [] 100% 39s Startup complete -dain
Re: Weekly: Geronimo 1.2-r465304
On Oct 19, 2006, at 12:26 PM, Kevan Miller wrote: On Oct 19, 2006, at 2:27 PM, Aaron Mulder wrote: In 1.1.1, the majority of the startup delay is in the console module. Dain suggested it's because we precompile the JSPs, so each one becomes a servlet, so each one becomes a GBean, and starting GBeans is what's slow. I found it hard to believe they're *that* slow, but I don't have any factual basis for disputing the claim... :) In any case, it would be great to investigate and optimize the startup time, or maybe introduce an option for a module that would kick it's startup into a background task or something. Agreed that some optimization would be nice. However, this isn't really a case of optimization, I think. Something has changed quite drastically between 1.1.1 and 1.2-SNAPSHOT. We've more than doubled our startup time... My guess is we have doubled the number of jsp pages and thus the number of GBeans. -dain Here are the numbers from 1.2 jetty: Module 1/22 org.apache.geronimo.configs/rmi-naming/1.2-r465304/ car started in .274s Module 2/22 org.apache.geronimo.configs/j2ee-server/1.2-r465304/ car started in .143s Module 3/22 org.apache.geronimo.configs/transaction/1.2-r465304/ car started in .243s Module 4/22 org.apache.geronimo.configs/j2ee-security/1.2-r465304/ car started in .333s Module 5/22 org.apache.geronimo.configs/axis/1.2-r465304/ carstarted in .044s Module 6/22 org.apache.geronimo.configs/openejb/1.2-r465304/ car started in 1.785s Module 7/22 org.apache.geronimo.configs/system-database/1.2-r465304/ car started in .000s Module 9/22 org.apache.geronimo.configs/activemq/1.2-r465304/ carstarted in .239s Module 10/22 org.apache.geronimo.configs/jetty/1.2-r465304/ car started in .533s Module 11/22 org.apache.geronimo.configs/geronimo-gbean-deployer/1.2- r465304/car started in .183s Module 12/22 org.apache.geronimo.configs/j2ee-deployer/1.2-r465304/ car started in .203s Module 13/22 org.apache.geronimo.configs/connector-deployer/1.2- r465304/car started in .128s Module 14/22 org.apache.geronimo.configs/openejb-deployer/1.2-r465304/ carstarted in .302s Module 15/22 org.apache.geronimo.configs/client-deployer/1.2-r465304/ car started in .067s Module 16/22 org.apache.geronimo.configs/axis-deployer/1.2-r465304/ car started in .585s Module 17/22 org.apache.geronimo.configs/sharedlib/1.2-r465304/ car started in .007s Module 18/22 org.apache.geronimo.configs/jetty-deployer/1.2-r465304/ car started in .259s Module 19/22 org.apache.geronimo.configs/welcome-jetty/1.2-r465304/ car started in .452s Module 20/22 org.apache.geronimo.configs/webconsole-jetty/1.2-r465304/ carstarted in 27.210s Module 21/22 org.apache.geronimo.configs/remote-deploy-jetty/1.2- r465304/car started in .190s Module 22/22 org.apache.geronimo.configs/hot-deployer/1.2-r465304/ carstarted in .278s And from 1.1 jetty; Booting Geronimo Kernel (in Java 1.4.2_09)... Module 1/20 geronimo/rmi-naming/1.1.1/car started in . 206s Module 2/20 geronimo/j2ee-server/1.1.1/car started in . 350s Module 3/20 geronimo/j2ee-security/1.1.1/car started in . 339s Module 4/20 geronimo/axis/1.1.1/carstarted in . 049s Module 5/20 geronimo/openejb/1.1.1/car started in . 232s Module 6/20 geronimo/system-database/1.1.1/car started in 1.521s Module 7/20 geronimo/activemq-broker/1.1.1/car started in . 810s Module 8/20 geronimo/activemq/1.1.1/carstarted in . 218s Module 9/20 geronimo/jetty/1.1.1/car started in . 445s Module 10/20 geronimo/geronimo-gbean-deployer/1.1.1/car started in . 180s Module 11/20 geronimo/j2ee-deployer/1.1.1/car started in . 163s Module 12/20 geronimo/openejb-deployer/1.1.1/carstarted in . 187s Module 13/20 geronimo/client-deployer/1.1.1/car started in . 036s Module 14/20 geronimo/axis-deployer/1.1.1/car started in . 050s Module 15/20 geronimo/sharedlib/1.1.1/car started in . 005s Module 16/20 geronimo/jetty-deployer/1.1.1/car started in . 181s Module 17/20 geronimo/welcome-jetty/1.1.1/car started in . 441s Module 18/20 geronimo/webconsole-jetty/1.1.1/carstarted in 7.797s Module 19/20 geronimo/remote-deploy-jetty/1.1.1/car started in . 165s Module 20/20 geronimo/hot-deployer/1.1.1/carstarted in . 220s And tomcat 1.2 Module 1/22 org.apache.geronimo.configs/rmi-naming/1.2-r465304/ car started in .282s Module 2/22 org.apache.geronimo.configs/j2ee-server/1.2-r465304/ car started in .142s Module 3/22
Weekly: Geronimo 1.2-r465304
Geronimo 1.2-r465304 - Oct 18, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r465304/ geronimo-1.2-r465304-src.tar.gz geronimo-1.2-r465304-src.zip geronimo-framework-1.2-r465304.tar.gz geronimo-framework-1.2-r465304.zip geronimo-jetty-j2ee-1.2-r465304.tar.gz geronimo-jetty-j2ee-1.2-r465304.zip geronimo-jetty-minimal-1.2-r465304.tar.gz geronimo-jetty-minimal-1.2-r465304.zip geronimo-tomcat-j2ee-1.2-r465304.tar.gz geronimo-tomcat-j2ee-1.2-r465304.zip geronimo-tomcat-minimal-1.2-r465304.tar.gz geronimo-tomcat-minimal-1.2-r465304.zip Changelog: http://people.apache.org/dist/geronimo/unstable/1.2-r465304/CHANGELOG.txt NOTE: This build is not an official release, nor tested, and should be considered unstable.
Weekly: Geronimo 1.2-r463140
Geronimo 1.2-r463140 - Oct 4, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-r463140/ geronimo-1.2-r463140-src.tar.gz geronimo-1.2-r463140-src.zip geronimo-framework-1.2-r463140.tar.gz geronimo-framework-1.2-r463140.zip geronimo-jetty-j2ee-1.2-r463140.tar.gz geronimo-jetty-j2ee-1.2-r463140.zip geronimo-jetty-minimal-1.2-r463140.tar.gz geronimo-jetty-minimal-1.2-r463140.zip geronimo-tomcat-j2ee-1.2-r463140.tar.gz geronimo-tomcat-j2ee-1.2-r463140.zip geronimo-tomcat-minimal-1.2-r463140.tar.gz geronimo-tomcat-minimal-1.2-r463140.zip Changelog: http://people.apache.org/dist/geronimo/unstable/1.2-r463140/CHANGELOG.txt NOTE: This build is not an official release, nor tested, and should be considered unstable.
Weekly: Geronimo 1.2-450299
Geronimo 1.2-450299 - Sept 27, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-450299/ geronimo-framework-1.2-450299.tar.gz geronimo-framework-1.2-450299.zip geronimo-jetty-j2ee-1.2-450299.tar.gz geronimo-jetty-j2ee-1.2-450299.zip geronimo-jetty-minimal-1.2-450299.tar.gz geronimo-jetty-minimal-1.2-450299.zip geronimo-tomcat-j2ee-1.2-450299.tar.gz geronimo-tomcat-j2ee-1.2-450299.zip geronimo-tomcat-minimal-1.2-450299.tar.gz geronimo-tomcat-minimal-1.2-450299.zip Changelog: http://people.apache.org/dist/geronimo/unstable/1.2-450299/CHANGELOG.txt NOTE: This build is not an official release, nor tested, and should be considered unstable.
Weekly: Geronimo 1.2-447908
We have our first of hopefully a long line of weekly builds published to the Geronimo unstable directory. This is still a fairly manual process, but I'm about half way through updating David Blevins' publish script. So now for the guilt trip... I've done my part and spent all day working on getting the binaries published and now it is your turn. Let's all pretend that this is a real release and spend a few minutes reviewing the binaries. Thanks, -dain Geronimo 1.2-447908 - Sept 20, 2006 http://people.apache.org/dist/geronimo/unstable/1.2-447908/ geronimo-jetty-j2ee-1.2-447908.tar.gz geronimo-jetty-j2ee-1.2-447908.zip geronimo-jetty-minimal-1.2-447908.tar.gz geronimo-jetty-minimal-1.2-447908.zip geronimo-tomcat-j2ee-1.2-447908.tar.gz geronimo-tomcat-j2ee-1.2-447908.zip geronimo-tomcat-minimal-1.2-447908.tar.gz geronimo-tomcat-minimal-1.2-447908.zip Changelog: http://people.apache.org/dist/geronimo/unstable/1.2-447908/CHANGELOG.txt NOTE: This build is not an official release, nor tested, and should be considered unstable.
Re: Entity bean can not remove itself
It has been a long time since I looked at this stuff, but I'm not
sure an entity can remove itself. The one thing I know for certain,
is that calling the ejbRemove remove method has not effect on the
entity state. The ejbRemove method is a callback invoked by the
entity container when the entity container has decided to remove the
entity. If you call this method directly, the entity container does
not see this.
After reviewing the 2.1 spec, I can't see any where that specifies
that entity can remove itself. Every remove example, has another
bean removing the target bean. At the very least, I'd start by
marking the entity as reentrant since a remove is conceivably
reentrancy. Then I'd try, entityContext.getEJB[Local]Object().remove()
-dain
On Jul 10, 2006, at 10:56 PM, D. Strauss wrote:
Hello, Markus
try this:
Way a (the Collection way):
java.util.CollectionEjbLocal c=ejbHome.findAll();
EjbLocal delBean=null;
for(EjbLocal l : c){
//find the bean you want to remove: for now, find the last one
delBean=l;
}
c.remove(delBean);
Way b (the usual way):
EjbLocal delBean=ejbHome.findByPrimaryKey(12);
delBean.remove();
Best regards
Dirk
mahu2425 schrieb:
Hello Dirk,
I'm not sure what you mean by collection version of ejbRemove().
Could you please explain it a little bit more?
Thank in advance,
Markus
Hello, Markus
now I get it ^^ (at least I think so)
So, to summarize it: you work with a CMP bean that is used by
various
other beans (JMS in particular). After all things have been done
I want
to remove the bean?
Using ejbRemove() is OK but you may want to use the Collection
version
of ejbRemove. I think (if I remember correctly) that ejbRemove()
always
crashed the EJB container. So I used the collection method. It is a
little bit difficult but it worked.
Give it a try and tell us if it works.
Best regards
Dirk
Schnell und einfach ohne Anschlusswechsel zur Lycos DSL Flatrate
wechseln und 3 Monate kostenlos ab effektiven 5,21 EUR pro Monat
im ersten Jahr surfen.
http://www.lycos.de/startseite/online/dsl/index.html?
prod=DSLtrackingID=email_footertxt
Re: Loading a dll file in the geronimo
Geronimo doesn't do anything special to help you load native libraries, nor does it do anything special to prevent you from loading a native library. To load a native library in Java use the System.load(String filename) or System.loadLibrary(String libname) methods. Native libraries can be very difficult to work with, so I suggest you read a tutorial or book on the Java Native Interface, and write a simple standalone test case before attempting to integrate a native library into Geronimo. -dain On Jul 6, 2006, at 1:06 AM, Santosh Koti wrote: Hi All, Is there a way to load a dll file in to the server JVM, has that to be done by wrapping it as a jar file adding a dependency for it..? I am yet to test on this..? Has some 1 done this earlier..? Thanks, Santosh. Don't talk about yourself; it will be done when you leave. CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
Re: geronimo 1.1 and activemq 4.0
I believe that you can use AMQ 4 as a plain old JCA managed resource, by deploying the AMQ 4 rar. Geronimo will treat this as just another resource adapter and will have console support. I suggest you ask for more help on the active mq mailing list. -dain On Jun 7, 2006, at 3:11 AM, Christoph Sturm wrote: Hey guys! the 1.1 candidates seem to run with activemq 3.x still. When will there be a version that runs with activemq 4.0? Is it possible to use activemq 4.0 now with geronimo 1.1 anyway? thanks chris
[announce] Apache Geronimo welcomes Guillaume Nodet as our newest committer
The Apache Geronimo PMC is proud to announce Guillaume Nodet as our newest Apache Geronimo committer, and look forward to his continued great work on XBean and the Geronimo integration with Service Mix. His work shows initiative, concern to get user feedback, empathy for problems faced by other committers and willingness to work on fixing these problems. Guillaume has consistently brought unique and very difficult use cases to the XBean project (along with patches), and it is these diverse requirements that will ultimately make XBean a success. We believe he will be an excellent addition to the project and will help foster these values in others. Please join us in congratulating Guillaume, The Apache Geronimo PMC
Re: commons logging issue
Our long term goal is to isolate web applications from the system classes. This means that by default a web application will only see the spec jars required by the servlet spec. Then if an application needs more jars, they can either add them to the WEB-INF/lib or the geronimo repository and add a dependency. I would have liked to get this into 1.1, but I think 1.1 will ship before I can get to it. -dain On Apr 13, 2006, at 7:18 AM, Guilherme Rios wrote: Thanks Pablo, Should this be addressed? The practical impact is sometimes an application will deploy fine in Geronimo/Tomcat but not Geronimo/ Jetty (because it will use jars unavailable in the former) or the other way around (because app jars will conflict with Geronimo's, as already discussed in other thread). Is there any reason why the repositories differ for both versions? Cheers, Guilherme Pablo wrote: Guilherme Rios wrote: Paul McMahan wrote: I'm not sure why deployment didn't fail in jetty, perhaps you would have seen a failure later on when you tried to access your servlets(?). Hi, I recall noticing a few days ago some jars missing from Geronimo/Jetty /repository when compared to Geronimo/Tomcat. Commons Logging was one, there was also one or two others missing. Can anyone pls confirm that? (I do not have access to my installation at this very moment) This could be the reason why it works on Geronimo/Jetty but not Geronimo/Tomcat. Regards, Guilherme Hi I'm sending lists of jars for both jetty and tomcat. There are a few differences... Cheers Pablo Send instant messages to your online friends http:// uk.messenger.yahoo.com
Re: User Feedback Request -- this means you!
On Mar 28, 2006, at 12:50 PM, [EMAIL PROTECTED] wrote: 2) Implementation of J2EE 1.5 (or JEE 5 or whatever we're calling it these days) JEE 5 is a huge cacophony of specifications. Can you be more specific about which specs you would like to see finished first? -dain
Re: User Feedback Request -- this means you!
For everyone that listed more documentation, can you be more specific? It will help us prioritize the effort to hit the most important stuff first. Thanks, -dain On Mar 28, 2006, at 10:31 PM, mikael-aronsson wrote: Same as below for me - Original Message - From: Christian Stolz [EMAIL PROTECTED] To: user@geronimo.apache.org Sent: Wednesday, March 29, 2006 7:36 AM Subject: Re: User Feedback Request -- this means you! Hi there, here is my Top 5: 1. Support for JDK1.5 2. JAX-WS support 3. More documentation 4. NetBeans support 5. More frequent releases Thanks Christian
Re: tying together various components w/ gbeans and spring?
On Feb 24, 2006, at 8:35 AM, David Jencks wrote: I've never been able to figure out a reasonable way for this to work, maybe someone else has better thinking on the subject. Here's the problem I see: Two configurations , A and B, B is a child of A. We start with both A and B started. Stop A, this should stop B first. Now I want to stop B, so when I restart A, B does not restart. Anyone see how to make this work? Um isn't this what startRecusive does? We have A - B with both running. Stop(A) will stop B then A. StartRecursive(A) will start A and then start B. -dain
Re: tying together various components w/ gbeans and spring?
On Feb 17, 2006, at 11:49 AM, David Jencks wrote: On Feb 17, 2006, at 10:50 AM, Tim Kettering wrote: lets say foo-webapp has a spring context that is started up when the webapp starts up. ideally i'd like this spring context to be able to obtain the various gbeans that are set in the server and make them available as beans in the context. has anyone done this, or could anyone offer some ideas/suggestions on how that might be done? Dain has some ideas on how to do this generically. Right now it is not very convenient. An example of something you can do is in trunk in the Spring module where there's a spring bean that more or less wraps our TransactionContextManager gbean. In the xbean code we have spring bean factories that expose Geronimo services to Spring, but I don't expect that code to be integrated into Geronimo for several months (assuming that community wants it at all). Note that depending on the circumstances you might be able to use JNDI. (not that I recommend JNDI for much of anything :-).The stuff specified in a web app's jndi specification will be accessible in any thread that goes through that web app. Therefore if you don't need to access geronimo services (gbeans) during the spring startup but only when in use from a web app, you can look up stuff like datasources. I'd like to be able to expose generic geronimo service via the J2EE enc, but never got around to adding the configuration code necessary to make it happen :( i will continue to work this angle - and share any answers i might by miracle discover, considering my very amateur understanding of this geronimo thing here. :) This is definitely an area we are interested in making easier :-) +1 -dain
Re: fail to build with
On Dec 23, 2005, at 3:27 PM, Nicholas Irving wrote: am I not using the correct repo? http://ibiblio.org/maven/axis/jars/ axis-1.4-356167.jar does not seem to exist. It is here http://cvs.apache.org/repository/axis/jars/ axis-1.4-356167.jar You may have tried to build during a server outage; I'd just try building again. -dain
Re: javamail issue
I'm not sure what you are asking. JavaMail is a specification
published by the Java Community Process. We provide a clean room
implementation of this specification with the Geronimo server
starting with version 1.0. If you would like to use the
implementation published by Sun Microsystems, that is also possible,
but you will have to acquire that implementation from Sun (it is
free) since licensing restrictions prevent us from shipping it with
our server.
-dain
On Dec 15, 2005, at 12:11 AM, Arun Venugopal wrote:
Hi Aaaron,
Does that mean that I cannot use the plain javamail implementation
in Geronimo and that I have to use the APIs provided by Geronimo
Thanks and regards
Arun
On Wed, 2005-12-14 at 14:27 -0500, Aaron Mulder wrote:
If you're planning to use Geronimo's JavaMail features, you should
be on a very current version (built from source or the 1.0 release
candidate). Then you want to add a line like this to your Geronimo
deployment plan: importgeronimo/javamail/1.0/car/import That
way, you should be sure to get our JavaMail code on the classpath
of your application. The JavaMail configuration is not started by
default, though it should be started when you deploy an
application that depends on it. If you want to start it by hand,
you can always use java -jar bin/deployer.jar start geronimo/
javamail/1.0/car Thanks, Aaron On 12/14/05, Arun Venugopal
[EMAIL PROTECTED] wrote: Hi, I have this piece
of code that uses javamail . This code works fine when i try it as
a standalone java application (ie when i put it in java file,
compile it and run it). But when i put this code in an war (and
call it from a servlet) and then deploy the war in geronimo, it
does not work. I am pretty sure that this code is being called as
any System.out.println that i give in between the code gets
displayed in the console. Also i tried out the same code in JBoss
and it seems to work there also. I have seen many discussions
in the dev list regarding the JavaMail implementation. But i think
all that is with regards to creating a new API for geronimo in the
lines of the mail API's present in JBoss. And that since i am
using plain java mail it should work irrespective of the
application server. Can any one give me any pointers on why i
am having this issue in geronimo and if i can solve it ...
-
-- //
substitute your mail address here String from = [EMAIL PROTECTED];
String to = [EMAIL PROTECTED]; //substitute the host name or ip of your
smtp server here String host = 1.2.3.4; Properties props =
new Properties(); props.put(mail.smtp.host, host); props.put
(mail.debug, true); Session session = Session.getInstance
(props); try { Message msg = new MimeMessage(session);
msg.setFrom(new InternetAddress(from)); InternetAddress[]
address = {new InternetAddress(to)}; msg.setRecipients
(Message.RecipientType.TO, address); msg.setSubject(Test E-Mail
through Java); msg.setContent(msg, text/plain);
msg.setSentDate(new Date()); msg.setText(Test Message);
Transport.send(msg);
-
Thanks in advance Regards ArunThis e-mail and any
files transmitted with it are for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the
original message. Any unauthorized review, use, disclosure,
dissemination, forwarding, printing or copying of this email or
any action taken in reliance on this e-mail is strictly
prohibited and may be unlawful. Visit us at http://
www.cognizant.com
This e-mail and any files transmitted with it are for the sole use
of the intended recipient(s) and may contain confidential and
privileged information.
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message.
Any unauthorized review, use, disclosure, dissemination,
forwarding, printing or copying of this email or any action taken
in reliance on this e-mail is strictly
prohibited and may be unlawful.
Visit us at http://www.cognizant.com
Re: Load Balancing in Geronimo
On Oct 25, 2005, at 4:44 PM, Michael Malgeri wrote: I'm working with a University that wants to implement an application on Geronimo that supports 10,000 concurrent users. There are a number of use cases but here's one that captures the primary issue Will this scenario work in the absence of clustering: 1. Load balancer in front of many linux servers each running Geronimo 2. Each instance or Geronimo connected to the same database server 3. Application only composed of JSPs, Servlets and Javabeans (no EJBs) 4. Users will be accessing shared data such as registering for a class In this case, if the following is true: 1. Load balancer handles session stickiness 2. Database server handles transactional access to shared data 3. Users can live without session failover Will this work? What are the unforeseen problems? What are the unforeseen restrictions? It should work. If they are only using the one database connection, I'd suggest that they use a one-phase (normal non-two-phase) JDBC connection. JDBC drivers tend to be more reliable in one-phase mode. -dain
Re: Geronimo disk footprint growth at startup
ActiveMQ doesn't use HOWL. Hiram wrote a transaction log customized and tuned for the access patterns of JMS. Hiram, we have been having a discussion about how the Geronimo disk footprint grows by 40MB when started up. Can you give Dave, Bruce and myself some insight on why the logs are the size they are, how much they can grow, and what attributes are available to configure this? Thanks, -dain On Aug 18, 2005, at 8:21 AM, Bruce Snyder wrote: On 8/18/05, Dave Colasurdo [EMAIL PROTECTED] wrote: Hmmm.. The only entries in j2ee-server-plan.xml that seems relevant is the HOWLTransactionLog gbean and it specifies the file var/txlog/howl*.log. Changing/distributing the changed properties associated with this gBean either have no effect on the var/activemq/journal/log*.dat or cause the server startup to fail... However, in the plan system-activemq-plan.xml.. I found the following gbean for the journal that seems to define the journal directory though have found no properties to control the size of the log-000*.dat file. gbean name=ActiveMQ.journal class=org.activemq.store.journal.JournalPersistenceAdapterGBean !--TODO change to ServerInfo -- reference name=serverInfomoduleorg/apache/geronimo/System/ moduletypeGBean/typenameServerInfo/name/reference attribute name=directoryvar/activemq/journal/attribute attribute name=journalTypedefault/attribute reference name=longTermPersistencegbean- namegeronimo.server:j2eeType=JMSPersistence,name=ActiveMQ.jdbc,*/ gbean-name/reference /gbean Thoughts? That's to configure ActiveMQ's use of HOWL. Are you referring to log files in the modules/assembly/target/geronimo-1.0-SNAPSHOT/var/ activemq/journal/log-000.dat directory named log-00*.dat? If so, then we'll need to consult Hiram or James about how ActiveMQ uses HOWL and why the journal's are of this size. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/
Re: Geronimo disk footprint growth at startup
On Aug 17, 2005, at 10:11 AM, Dave Colasurdo wrote: Thanks Bruce.. A few followup questions.. Is there any bound on how large these files can grow or a way to configure a smaller value for the recovery log? I don't believe the files grow at all. IIRC the logger preallocates the files so it is fast. Why does a simple server startup require 41M of recovery data? No user applications have been installed on this server yet. Most likely, but what kind of user machine doesn't have 40M of free disk space? Just wondering if there is a way to limit the default disk footprint requirement for geronimo... You can change these settings in the Server plan. Look for howl. -dain
Re: Geronimo disk footprint growth at startup
On Aug 17, 2005, at 12:24 PM, Dave Colasurdo wrote: Dain Sundstrom wrote: On Aug 17, 2005, at 10:11 AM, Dave Colasurdo wrote: Thanks Bruce.. A few followup questions.. Is there any bound on how large these files can grow or a way to configure a smaller value for the recovery log? I don't believe the files grow at all. IIRC the logger preallocates the files so it is fast. Why does a simple server startup require 41M of recovery data? No user applications have been installed on this server yet. Most likely, but what kind of user machine doesn't have 40M of free disk space? Was thinking of the case where geronimo is an embedded technology.. ISVs generally like embedded technologies to be as small and fast as possible. Just seems strange that starting the server nearly doubles the disk footprint when no user applications are installed. Any chance of shrinking the default size for the recovery log. Is 40M really needed? It seems a bit excessive.. Sure. In an embedded scenario, the ISV would tweak the howl configuration to reduce the foot print. Now exact what you change is something David Jencks will have to tell us. -dain
Re: GBeans threading best practices
On Aug 3, 2005, at 9:34 AM, Dain Sundstrom wrote: On Aug 3, 2005, at 8:13 AM, Miguel A Paraz wrote: Hi, I'm planning on writing my own GBeans to implement services. Is it OK to start new Threads - using new Thread() directly, or indirectly by using util.concurrent facilities which I see in the code? You can start threads directly, but it is preferrable to use a EDU.oswego.cs.dl.util.concurrent.Executor. The best practice is to have the Executor inject via constructor injection or setter injection. This allows a user of your service to have complete control the properties of the thread pool. Let me be a bit more clear. I suggest you write your code to use the concurrent executor since it is common reusable api with many implementations. When it comes to deploying your service in Geronimo, the Geronimo ThreadPool class implements the Executor so you can just use that service with a Geronimo GBean reference. -dain
Re: build problem
We now use a single global repository list which is way easier to maintain. In maven 1.0 and 1.0.1 there was a bug that caused a module to not inherit the repo list from the parent project. -dain On Jun 23, 2005, at 10:28 AM, Jeremy Boynes wrote: David Jencks wrote: Are you using maven 1.0.2? Basically all other versions don't work, either older or newer. Dumb question, but what changed in the build that stopped maven 1.0 from working and can we work around it? -- Jeremy
Re: Command Line Geronimo Remote deployment
On Jun 14, 2005, at 12:15 AM, NATARAJAN Sasi Kumar wrote: The following command is possible to deploy local. But I am expecting remote deployment how can I do. Where can I mention the Hostname and what is the argument. Option. Anyone has idea please advice to me deployer.jar -user system -password manager deploy sample.war Remote deployment is not implemented yet, so you have to be on the same computer as the Geronimo server to deploy. This will be implemented before version 1.0 ships. -dain
Re: RSS Syndication and Aggregation
On Jun 5, 2005, at 5:25 PM, Scott Anderson wrote: I would be interested in a standard RSS Syndication/Aggregation Service getting included with a future Geronimo distribution. In my mind this service would make it easy for developers and content providers to... 1) serve up dynamically generated RSS feeds 2) subscribe to remote feeds with support for filtering and/or combining feeds and then republishing them (XSLT?) 3) manage subscriptions 4) provide statistics on feed usage I suspect that the Geronimo dev team's response to this request will be something like...great, why don't you get started on that. Hopefully, others have been thinking along these same lines though. I will be attempting find some time to work on a ROME GBean (https://rome.dev.java.net/) in the short to medium term. I'll be happy to share that code with any interested parties once I have something. No guarantees on when that'll be. If anyone has suggestions on how to structure this service, how to integrate with it, or what features you think are important, I'd be happy to hear from you here. Interesting idea. I'm not too familiar with rss other then rss feeds from blogs and new sites. What sort of information do you see Geronimo serving via RSS? I mean I'm sure we could serve general information like blogs, but I'm curious if we could use this for management of some kind or something totally different. Again cool idea, -dain
Re: HTTP Server jetty
David is assuming you are asking about the Apache Java based http server (and servlet/jsp engine) Tomcat. If you really meant the Apache HTTPd server, the reason we don't ship with it is HTTPd is written in C and must be compiled to each platform where our distributions will run on a generic Java VM. -dain -- Dain Sundstrom Chief Architect Gluecode Software On Apr 14, 2005, at 8:49 AM, David Jencks wrote: The reasons are primarily historical: the main Jetty developers were some of the geronimo founding members and most of us have a lot more experience with Jetty than Tomcat. There is a Tomcat integration and several people are working on it, however it is not yet completely integrated and functional. I think the Tomcat work is somewhat sidelined at the moment in our effort to finish j2ee certification. We would certainly welcome help in finishing the Tomcat integration. Many thanks, david jencks On Apr 14, 2005, at 8:31 AM, Yves Caloz wrote: Hi, Somebody surely already put the question, but I did not find an answer, then I ask it nevertheless: Why is Geronimo default with Jetty and not HTTP Apache Server integrated ? Is it a licence problem ? Thanks
Re: Mail Archives and EJB3
On Feb 15, 2005, at 4:36 AM, David J. Green wrote: Hello all! I'm new here so hang with me.First, I tried to find some information in the mail list archives, and received a Velocity Servlet error when I tried to view the messages by subject, and also when I tried by thread. Someone might want to look at that, although I know you're all busy. Its been broken for a while. :( I think someone on the Apache infrastructure team is working on it now. Second, I assume Geronimo's EJB code is written for the 2.1 spec, but was curious about the plan once the 3.0 spec is release. Will that be a feature for the future, or will you try to get it up as quickly as you can.I'm looking forward to dumping my current server program. Keep up the good work. Geronimo uses the EJB implementation from OpenEJB (openejb.org), and it is written to the EJB 2.1 specification. As for EJB 3.0, it is not even at the public draft stage of the JCP process. (http://www.jcp.org/en/procedures/jcp2), so I personally don't expect to see a final spec for another year or two. Given the extreme political nature of the EJB 3.0 specification and the huge amount change in the EJB 3.0 from the 2.1, I expect to see the EJB 3.0 specification to change a lot as the vendors attempt to implement it. We saw this to a lesser degree when CMP 2.0 was first introduced, and when the vendors attempted to implement the public draft, found that the dependent objects part of the specification simply did not work. Anyway, I personally don't plan on starting on EJB 3.0 until the spec stabilizes. I plan on working on features that will make the user experience better, such as providing better error messages to users. This is an opensource project, so if you or anyone else is interested in working on EJB 3.0, please contribute. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
Re: Updating the web-site
On Feb 11, 2005, at 11:25 AM, Alan D. Cabrera wrote: Doesn't Apache have a free license to use Confluence? Getting a license for software is normally not an issue. Normally the issue is getting infrastructure to agree to run the software. -dain
Re: Geronimo on Fedora
Looks like the public repos are out of sync. Geronimo is the integration of 5 projects, and a lot of changes propagate several projects. What happens is the jars for the projects are all published at different times, so there is a period where things don't build independently. I suggest you use our maven goals that checkout and does a transitive build of geronimo and the sister projects. Simply run, maven m:co maven m:build later you can use maven m:update maven m:rebuild -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 On Dec 1, 2004, at 2:37 PM, Hari Kodungallur wrote: Hello, I am trying to build Geronimo on Fedora Core 1. I downloaded the source tar.gz file -- did not checkout the source from the subversion. And I did $ maven The result is that it stops, with an exception, at Building server.jar. The exception is shown below at the end of this email. I will try to debug this. But, I am wondering whether someone has encountered this error before or knows what the problem is? I did see that Fedora is not listed in the Known Supported Platforms. Thanks much! -Hari Here is the exception: [echo] Building server.jar [java] Error: Unable to start local kernel [java] [java] org.apache.geronimo.kernel.config.InvalidConfigException: Invalid GBean configuration for geronimo.config:name=org/apache/geronimo/J2EEDeployer [java] at org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:379) [java] at org.apache.geronimo.system.main.CommandLine.startKernel(CommandLine.jav a:120) [java] at org.apache.geronimo.deployment.cli.ServerConnection$KernelWrapper.start (ServerConnection.java:239) [java] at org.apache.geronimo.deployment.cli.ServerConnection.initializeKernel(Se rverConnection.java:128) [java] at org.apache.geronimo.deployment.cli.ServerConnection.init(ServerConnec tion.java:119) [java] at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java: 109) [java] at org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:252) [java] Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Invalid GBean configuration for geronimo.deployer:role=ModuleBuilder,type=EJB,config=org/apache/ geronimo/J2EEDeployer [java] at org.apache.geronimo.kernel.Kernel.loadGBean(Kernel.java:359) [java] at org.apache.geronimo.kernel.config.Configuration.doStart(Configuration.j ava:207) [java] at org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:616) [java] at org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(Ab stractManagedObject.java:511) [java] at org.apache.geronimo.gbean.jmx.AbstractManagedObject.start(AbstractManag edObject.java:305) [java] at org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(Abst ractManagedObject.java:329) [java] at org.apache.geronimo.gbean.jmx.GBeanMBean$11.invoke(GBeanMBean.java: 1036) [java] at org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOper ation.java:142) [java] at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:844) [java] at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBe anServerInterceptor.java:218) [java] at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBe anServerInterceptor.java:121) [java] at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityM BeanServerInterceptor.java:86) [java] at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBe anServerInterceptor.java:121) [java] at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBe anServerInterceptor.java:121) [java] at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke (ContextClassLoaderMBeanServerInterceptor.java:205) [java] at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079) [java] at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:288) [java] at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:283) [java] at org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:375) [java] ... 6 more [java] Caused by: net.sf.cglib.core.CodeGenerationException: java.lang.IllegalStateException--Proxy is stopped [java] at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:270) [java] at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:255) [java] at net.sf.cglib.proxy.Enhancer.createUsingReflection(Enhancer.java:386) [java] at net.sf.cglib.proxy.Enhancer.nextInstance(Enhancer.java:366) [java] at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator. java:200) [java] at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:330) [java
Re: Anyone have a sample EAR?
Geronimo builds one at applications/magicGball/target/magicGball-ejb.jar, but that requires building from source. -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26 On Nov 24, 2004, at 3:18 PM, David Jencks wrote: I think the activemq itest involves deploying an ear. david jencks On Nov 24, 2004, at 1:55 PM, Lajos wrote: I'm trying to debug my own .ear, which won't deploy in Geronimo. Does anyone have a super-simple .ear application that runs on M3? I would be very grateful if you could post it or email it to me. I'm hoping it is just a matter of some descriptor that I have wrong ... Thanks! Lajos -- Lajos Moczar Open Source Support, Consulting and Training Tomcat Unleashed (www.amazon.com/exec/obidos/tg/detail/-/0672326361) Cocoon Developer's Handbook (www.amazon.com/exec/obidos/tg/detail/-/0672322579) _ _ / \ / /___\ / / \ / http://www.galatea.com -- powered by AzSSL
