RE: Eve integration with Geronimo
Alan D. Cabrera wrote: Alex Karasulu is working on it. I suspect that it will be completed soon. Alex? Small matter of something called a hurricane has Alex off-line at the moment. --- Noel
Converting to Subversion
We are finally going to do the long talked about conversion to Subversion. I expect this conversion to take place tomorrow or the next day. When the conversion happens the Apache infrastructure team will lock down (convert to read-only) our cvs repository and create the new Subversion repository. The existing incubator-geronimo repository will always be available, but all new development will happen in the Subversion repository. The Subversion website can be found here: http://subversion.tigris.org There are several downloads available from the Subversion website, including RPMs for Linux and executables for Windows. Back when we first discussed this, I among others raised concerns about Subversion on Mac OS X. This is no longer a problem. There are binaries available via Fink for OS X and I have been using it for a few days now. Finally, the Subversion project has a superb *free* book available Version Control with Subversion online (http://svnbook.red-bean.com/). This book is published by O'Reilly Media and is available in paperback from most book stores. If you have any problems using Subversion, you can post to this list, but we recommend that you join the [EMAIL PROTECTED] mailing list, and read the Subversion Book and FAQ (http://subversion.tigris.org/project_faq.html). You can also ask questions about Subversion on IRC at irc.freenode.net, channel #svn. Cheers, -dain -- Dain Sundstrom Chief Architect Gluecode Software 310.536.8355, ext. 26
[status] build: SUCCESSFUL, test: SUCCESSFUL | Linux 2.4.26, 2004-09-10
NIGHTLY BUILD/TEST Date: Fri Sep 10 05:46:57 EDT 2004 Kernel: Linux 2.4.26 Host: beaver.codehaus.org Java: 1.4.2_04-b05, mixed mode Maven: 1.0 CHECKOUT: incubator-geronimo BUILDING: incubator-geronimo BUILD SUCCESSFUL Total time: 20 minutes 15 seconds Finished at: Fri Sep 10 06:09:27 EDT 2004
Re: What's missing for Tomcat integration?
Shapira, Yoav wrote: Hi, After a bit of talking with Geir regarding the 1.0 M2 release still not supporting Tomcat, I thought I'd jump in and ask: what's missing for Tomcat integration, and how can I help? I sometimes see people who complain on Jetty integration in Geronimo, so I think there're a lot of obstacles you'll need to go thru until you reach the end. No need to worry though! I'm working on enabling a functionality in Geronimo, that Dain said, may be easy to implement, thus it may be me who sees toubles where they aren't ;) Anyway, I was also wondering what is to be done to have Tomcat working in Geronimo. My basic understanding of Geronimo architecture allows me to say it's a matter of creating GBean with some dependencies/references and voila it ought to be working well. I've gone over the archives, but there's nothing significant on this matter since I raised this issue last March (thread titled Does Geronimo use tomcat? in the archives). Incidentally, in that thread N. Alex Rupp also said he was working on articles in this area (http://marc.theaimsgroup.com/?l=geronimo-devm=108015237832228w=2). I've yet to see them: have they been published somewhere? I've read his articles/blogs on the MVC pattern, the servlet antipattern, and how Tomcat is similar to the Irish Elk, but I haven't seen anything addressing what the problems were in integrating Tomcat into Geronimo. I also haven't ever seen any takers of the subject. How come it was overlooked? It might've been waiting for the brave soul like you :) Anyways, since then I see Geronimo has evolved, getting closer to a release. So has Tomcat, including the (presumably) relevant area of JMX and JSR77 compliance. So I'd like an updated list of what's missing, what needs to be done, in order for Geronimo to accept Tomcat as easily/natively as it does Jetty. That should be a good start, and it's a pretty good time as far as Tomcat is concerned to make some tweaks, with the 5.5 branch still in very active development. By the way, this is no slight of offense to Jetty or any of its developers. It's a good product and I have no problems with it. I'm looking to improve both Tomcat and Geronimo with this effort. And a good weekend to all ;) Definitelly! However, it's the best time to finally sit down and program stuff for Geronimo (like TomcatGBean). It'd be fun. Hmmm, gotta think about it ;) Yoav Shapira Jacek
[jira] Created: (GERONIMO-291) Broken links on geronimo.apache.org
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-291 Here is an overview of the issue: - Key: GERONIMO-291 Summary: Broken links on geronimo.apache.org Type: Bug Status: Unassigned Priority: Trivial Project: Apache Geronimo Components: general Assignee: Reporter: YoavShapira Created: Fri, 10 Sep 2004 8:06 AM Updated: Fri, 10 Sep 2004 8:06 AM Environment: Any Description: The following links on geronimo.apache.org are broken: - All the links in the Specifications section - The Module links for Axis and Mail The following links are interesting ;) - Changelog has a lot of whitespace (about half a screen on my current PC -- compare with the commit log which looks nice) - Dependencies says Geronimo has no dependencies - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: RE: Eve integration with Geronimo
Hey guys, As a Hurricane refugee (sounds weird saying that) I have no dependable internet connectivity so I appologize for getting to these emails so late. And thank you Noel for letting people know. Now for Geronimo integration Alan and I had discussed making some components into GBeans. We were debating whether or not to make the entire server into one GBean or to make all services in the server into a GBean. To show how that is done Alan whiped together a few wrappers for all the services here: http://svn.apache.org/viewcvs.cgi/incubator/directory/eve/trunk/frontend/geronimo/?root=Apache-SVN But after he did this we began thinking the single GBean approach for all of Eve may be better. So with Alan's examples I think one of us can pick up the torch and write a single wrapper pretty easily for plugging into Geronimo. There are however some considerations. We have begun to decouple the backend code from Avalon and will have pure pojos with Avalon wrappers. This must happen before the backend can be integrated as well as the frontend code. Also we have begun to separate out frontend plumbing from LDAP specific code in Eve's frontend. This code is a TCP specific SEDA framework. We're going to make this into a subproject on its own so we can reuse it for a Eve integrated Kerberos server without tight coupling (it can also be standalone). Trustin Lee (guy who did Netty) will be looking into adding UDP support to this in project. So what does this all mean for integration? Well we want to write wrappers for this SEDA framework where Eve just plugs in as another simple protocol to be able to benefit from those wrappers. By writing a geronimo wrapper for SEDA rather than an Eve specific frontend we now allow any protocol to be fired up within geronimo without having to specifically integrate that protocols frontend. WDYT? So we really want to write a SEDA framework wrapper intead of one specifically for Eve. This also makes me think if its worth writting wrappers for the backend of Eve and this raises several questions I still don't have answers to but these I'll leave for other emails. Hope that helps, Alex From: Noel J. Bergman [EMAIL PROTECTED] Date: 2004/09/10 Fri AM 12:26:39 EDT To: [EMAIL PROTECTED] CC: Apache Directory Developers List [EMAIL PROTECTED] Subject: RE: Eve integration with Geronimo Alan D. Cabrera wrote: Alex Karasulu is working on it. I suspect that it will be completed soon. Alex? Small matter of something called a hurricane has Alex off-line at the moment. --- Noel
[jira] Closed: week of 09-10-2004
Project: Apache Geronimo Status: Resolved, Closed (24 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-278] Servlet/JSP 2.3 DTD deployment descriptor support * [GERONIMO-174] Support for security-roles in web.xml * [GERONIMO-212] EJB ejb-jar.xml resource-ref support to JMS * [GERONIMO-211] Servlet web.xml resource-ref support to JMS * [GERONIMO-206] Hot deployment of EJB, WAR, and RAR archives * [GERONIMO-205] J2EE Connector support for JMS Providers * [GERONIMO-273] Resource Environment References in ejb-jar.xml * [GERONIMO-274] Resource Environment References in web.xml * [GERONIMO-279] J2EE Application 1.4 deployment descriptor support * [GERONIMO-275] Message Destination References in ejb-jar.xml * [GERONIMO-276] Message Destination References in web.xml * [GERONIMO-277] Servlet/JSP 2.2 DTD deployment descriptor support * [GERONIMO-163] Support for ejb-refs in a web.xml ** Bug * [GERONIMO-245] OutOfMemoryError while running ConnectionManagerStressTest * [GERONIMO-235] No JSP support without tools.jar * [GERONIMO-259] maven javadoc:install fails * [GERONIMO-244] Content of war appear in car file twice * [GERONIMO-246] NullPointerException when omitting assembly-descriptor tag in ejb-jar.xml * [GERONIMO-247] Missing jsp_2_0.xsd for offline mode * [GERONIMO-283] JettyModuleBuilder can't find remote interface for ejb-refs ** Improvement * [GERONIMO-223] Upgrade Jetty5.0beta0 to Jetty5.0RC0 * [GERONIMO-147] Typo corrections * [GERONIMO-256] org.apache.xmlbeans.XmlException: error: Document root element is missing. ** Task * [GERONIMO-285] geronimo-1.0-SNAPSHOT/README.txt gives wrong URL of Geronimo Developer Notebook Preview
Re: What's missing for Tomcat integration?
Shapira, Yoav wrote: Hi, After a bit of talking with Geir regarding the 1.0 M2 release still not supporting Tomcat, I thought I'd jump in and ask: what's missing for Tomcat integration, and how can I help? Just getting it running would be a good place to start. That should be a fairly simple GBean that starts an embedded server within Geronimo. From there we can move on to closer integration. The main areas I can think off off the top of my head are: * ENC integration * Transaction context * JAAS Authentication * JACC * JSR77 * Deployment That should be a good start, and it's a pretty good time as far as Tomcat is concerned to make some tweaks, with the 5.5 branch still in very active development. AIUI TC5.5 requires JDK1.5 whereas we are targeting 1.4.2 based systems. so that would be an issue using that branch. We are also targeting a production release soon - my hunch would be that we would be better integrating with the 5.0 branch as that is currently available. I'd like to suggest we start there for a stable version and then work with the Tomcat community on the 5.5 branch for new or experimental features. By the way, this is no slight of offense to Jetty or any of its developers. It's a good product and I have no problems with it. I'm looking to improve both Tomcat and Geronimo with this effort. I would echo that - we've have always wanted to work with Tomcat bu tjust never got around to it. I'd like to welcome you to our community and look forward to getting this going. -- Jeremy
Re: What's missing for Tomcat integration?
On Sep 10, 2004, at 11:25 AM, Jeremy Boynes wrote:
Shapira, Yoav wrote:
Hi,
After a bit of talking with Geir regarding the 1.0 M2 release still
not
supporting Tomcat, I thought I'd jump in and ask: what's missing for
Tomcat integration, and how can I help?
Just getting it running would be a good place to start. That should be
a fairly simple GBean that starts an embedded server within Geronimo.
N. Alex sent me a simple version a long time ago. It simply had an
unpacked version of tomcat and started it in the same vm a geronimo. I
started to work on a closer integration because I really dislike the
idea of shipping an entire unpacked version of tomcat (since it is 12
MB), but got busy. Anyway, the code is at the end of this message (not
it is very old and may not even compile).
-dain
package org.apache.geronimo.tomcat;
import org.apache.catalina.startup.Catalina;
import org.apache.geronimo.gbean.GAttributeInfo;
import org.apache.geronimo.gbean.GBean;
import org.apache.geronimo.gbean.GBeanContext;
import org.apache.geronimo.gbean.GBeanInfo;
import org.apache.geronimo.gbean.GBeanInfoFactory;
import org.apache.geronimo.gbean.GConstructorInfo;
import org.apache.geronimo.gbean.GReferenceInfo;
import org.apache.geronimo.system.serverinfo.ServerInfo;
public class TomcatService implements GBean {
/**
* Reference to the org.apache.catalina.startup.Catalina shell
* Right now we're just wrapping up the shell, but we'll be
replacing it
* with our own GBean shell for ease of management.
*/
private Catalina shell;
/**
* Reference to the ServerInfo object. This is recieved through the
* constructor, and can be used to get information about the
Server, most
* notably including the location of the server installation
directory
* (and thus the Tomcat base dir).
*
*/
private final ServerInfo serverInfo;
private String catalinaHome;
private String catalinaBase;
/**
* Reference to the Catalina shell, to which calls are delegated.
*
* The catalina shell relies on the catalina.home and
catalina.base
* System properties. Presumably, these could be added in a simple
properties
* file, but I'm going to work under the assumption that we'll want
them as
* persistent attributes in a server configuration. This will make
them more
* easily manageable (in theory--we'll see)
*/
public TomcatService(ServerInfo serverInfo, String catalinaHome,
String catalinaBase) {
this.serverInfo = serverInfo;
this.catalinaHome = catalinaHome;
this.catalinaBase = catalinaBase;
}
public void doFail() {
doStop();
}
public void doStart() {
System.setProperty(catalina.home,
serverInfo.resolvePath(catalinaHome));
System.setProperty(catalina.base,
serverInfo.resolvePath(catalinaBase));
if (shell == null) {
shell = new Catalina();
}
shell.start();
}
public void doStop() {
if (shell != null) {
shell.stop();
shell = null;
}
}
public void setGBeanContext(GBeanContext ctx) {
}
public static final GBeanInfo GBEAN_INFO;
static {
GBeanInfoFactory infoFactory = new
GBeanInfoFactory(TomcatService.class.getName());
infoFactory.setConstructor(new String[]{ServerInfo,
CatalinaHome, CatalinaBase});
infoFactory.addReference(new GReferenceInfo(ServerInfo,
ServerInfo.class.getName()));
infoFactory.addAttribute(CatalinaHome, String.class, true);
infoFactory.addAttribute(CatalinaBase, String.class, true);
GBEAN_INFO = infoFactory.getBeanInfo();
}
public static GBeanInfo getGBeanInfo() {
return GBEAN_INFO;
}
}
README: [jira] Closed: week of 09-10-2004
Everyone, This is the first of what will be weekly reports from JIRA. Any JIRA items that are marked Closed or Resolved during the week will show up in this report. The goal of these reports is to keep everyone informed as to what is going on in the project. This includes users, contributors, and committers alike. Reading all the commit messages isn't practical with such a large codebase. This report is an example of *bad* JIRA usage--almost none of the items listed where actually completed in the last seven days. To keep our changelog and reports accurate simply follow these guidelines: - Create a JIRA item for anything you are working on if one doesn't already exist. If one exists, assign it to yourself. - When you checkin code, put the JIRA issue key in the log message. - When you complete the changes, mark the JIRA issue as closed. That's it. If you don't enter and close JIRA items for the things you work on, they will NOT show up in this report and they will NOT be included in the changelog on any releases (nightly, milestone, etc.) Long story short: treat JIRA as source code and try and keep it as accurate and up-to-date as possible. -David On Fri, Sep 10, 2004 at 01:04:44PM -0500, [EMAIL PROTECTED] wrote: Project: Apache Geronimo Status: Resolved, Closed (24 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-278] Servlet/JSP 2.3 DTD deployment descriptor support * [GERONIMO-174] Support for security-roles in web.xml * [GERONIMO-212] EJB ejb-jar.xml resource-ref support to JMS * [GERONIMO-211] Servlet web.xml resource-ref support to JMS * [GERONIMO-206] Hot deployment of EJB, WAR, and RAR archives * [GERONIMO-205] J2EE Connector support for JMS Providers * [GERONIMO-273] Resource Environment References in ejb-jar.xml * [GERONIMO-274] Resource Environment References in web.xml * [GERONIMO-279] J2EE Application 1.4 deployment descriptor support * [GERONIMO-275] Message Destination References in ejb-jar.xml * [GERONIMO-276] Message Destination References in web.xml * [GERONIMO-277] Servlet/JSP 2.2 DTD deployment descriptor support * [GERONIMO-163] Support for ejb-refs in a web.xml ** Bug * [GERONIMO-245] OutOfMemoryError while running ConnectionManagerStressTest * [GERONIMO-235] No JSP support without tools.jar * [GERONIMO-259] maven javadoc:install fails * [GERONIMO-244] Content of war appear in car file twice * [GERONIMO-246] NullPointerException when omitting assembly-descriptor tag in ejb-jar.xml * [GERONIMO-247] Missing jsp_2_0.xsd for offline mode * [GERONIMO-283] JettyModuleBuilder can't find remote interface for ejb-refs ** Improvement * [GERONIMO-223] Upgrade Jetty5.0beta0 to Jetty5.0RC0 * [GERONIMO-147] Typo corrections * [GERONIMO-256] org.apache.xmlbeans.XmlException: error: Document root element is missing. ** Task * [GERONIMO-285] geronimo-1.0-SNAPSHOT/README.txt gives wrong URL of Geronimo Developer Notebook Preview
RE: Eve integration with Geronimo
Hey Alex From: Alex Karasulu [EMAIL PROTECTED] Also we have begun to separate out frontend plumbing from LDAP specific code in Eve's frontend. This code is a TCP specific SEDA framework. We're going to make this into a subproject on its own so we can reuse it for a Eve integrated Kerberos server without tight coupling (it can also be standalone). Trustin Lee (guy who did Netty) will be looking into adding UDP support to this in project. So what does this all mean for integration? Well we want to write wrappers for this SEDA framework where Eve just plugs in as another simple protocol to be able to benefit from those wrappers. By writing a geronimo wrapper for SEDA rather than an Eve specific frontend we now allow any protocol to be fired up within geronimo without having to specifically integrate that protocols frontend. WDYT? So we really want to write a SEDA framework wrapper intead of one specifically for Eve. This also makes me think if its worth writting wrappers for the backend of Eve and this raises several questions I still don't have answers to but these I'll leave for other emails. I guess it depends what you mean by SEDA. Mostly I tend to think of the Channel abstraction in the concurrent.jar as being a pretty good abstraction for SEDA, where the channels can be local in VM or remote and you can put/take/poll objects - then the rest is just implementation details. Or some folks like to abstract away the low level SEDA like protocol of sync/async send behind a dynamic proxy to make SEDA invisible as it were. e.g. http://activemq.codehaus.org/maven/apidocs/org/codehaus/activemq/util/ AsyncProxy.html If what you mean is more of a SEDA based transport framework, well we've been working for quite some time on one of those on the ActiveMQ project :). Last benchmark we did was 22,000 messages/second sustained throughput on 2 2-way linux boxes with producer, broker, consumer all going across the network for 1-2K message sizes and reasonably low CPU usage (YMMV). Currently we've transports for * VM (in memory both sync true SEDA) * TCP / SSL * UDP multicat * NIO through g-networks and EmberIO * JGroups * JRMS * JXTA * HTTP (for tunnelling) * Jabber (experimental) * AIO4J (experimental) In addition we have discovery protocols (Zeroconf ActiveCluster) to make peer-style clusters of auto-discoverying clients servers (Zeroconf is particularly cute as it works nice with Apple's Rendezvous), together with load balancing fault tolerance transports (e.g. auto-fail over to another server in case of failure etc). Other protocols to come are SOAP-over-TCP, FTP, SMTP, SQL and file system when we get chance. Details of the code are here... http://activemq.codehaus.org/Code+Overview Basically we have a really simple TransportChannel API which can represent any kind of transport protocol. http://activemq.codehaus.org/maven/apidocs/org/codehaus/activemq/ transport/package-summary.html The minimal contract we support for application protocols is that they must decide if a method call is sync (requiring a receipt such as a commit()) or async (fire forget) and for async, whether a flush is required after the send. Consuming is pluggable based on the transport - so it decides if there is a thread, is it pull/push or how threads multiplex such as for NIO / AIO. Most of the transport channels can be reused as is with a pluggable WireFormat which dictates how command objects (we use the Packet base class) get serialized on the wire. e.g. we have a default, fast as possible, wire format for the JMS Packets, as well as Jabber XStream based ones etc. The TransportChannel abstract represents about the 8th or 9th generation of this kind of abstraction the team have used over the last 5 years or so for implementing high performance messaging SEDA transport abstractions - so if nothing else, I'd advise you to go down a similar route of abstraction; then at the very least you'll be able to reuse our transports easily we can easily plugin into your stuff - especially if you want to take advantage of our clustering, failover replication protocols.. James --- http://radio.weblogs.com/0112098/
Re: What's missing for Tomcat integration?
On Sep 10, 2004, at 9:45 AM, Shapira, Yoav wrote: Hi, After a bit of talking with Geir regarding the 1.0 M2 release still not supporting Tomcat, I thought I'd jump in and ask: what's missing for Tomcat integration, and how can I help? Yoav - thanks for coming! I've gone over the archives, but there's nothing significant on this matter since I raised this issue last March (thread titled Does Geronimo use tomcat? in the archives). Incidentally, in that thread N. Alex Rupp also said he was working on articles in this area (http://marc.theaimsgroup.com/?l=geronimo-devm=108015237832228w=2). I've yet to see them: have they been published somewhere? I've read his articles/blogs on the MVC pattern, the servlet antipattern, and how Tomcat is similar to the Irish Elk, but I haven't seen anything addressing what the problems were in integrating Tomcat into Geronimo. Anyways, since then I see Geronimo has evolved, getting closer to a release. So has Tomcat, including the (presumably) relevant area of JMX and JSR77 compliance. So I'd like an updated list of what's missing, what needs to be done, in order for Geronimo to accept Tomcat as easily/natively as it does Jetty. That should be a good start, and it's a pretty good time as far as Tomcat is concerned to make some tweaks, with the 5.5 branch still in very active development. THis is great. I think that while our goal is perfect integration, I think getting it working - not perfectly integrated, but working - is an excellent first step. It will give us feedback about what we need in Geronimo to help Tomcat integrate, and what Tomcat needs to do to become more integratable. (integrable?) geir By the way, this is no slight of offense to Jetty or any of its developers. It's a good product and I have no problems with it. I'm looking to improve both Tomcat and Geronimo with this effort. And a good weekend to all ;) Yoav Shapira Millennium Research Informatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
