Re: What is Jakarta?
A little backstory on the connection pooling mechanism I submitted to Struts a while back: A couple of months ago, at the company I work for we ran into problems with the connection pooling implementation within the commercial product we were using. Specifically, (a) the pool itself was buggy and (b) the pool implementation made it difficult for us to pool PreparedStatements and the parse rate of unpooled PreparedStatements within the database was becoming a bottleneck to application performance. For this reason I put together a Connection/PreparedStatement pooling implementation that met our needs. Completely independently, I noticed the Struts project on jakarta.apache.org, started to poke around a bit, and subscribed to struts-dev and struts-user. I noticed that Struts had a basic connection pooling implementation. I also noticed several requests on struts-dev and struts-user looking to expand the functionality on the Struts connection pool. Many of the features (in fact all of the features) that were being asked for were/are features of the Connection/PreparedStatement pool I put together. So, I repackaged my code as org.apache.struts.*, and submitted it to the list. This is the way open source development is supposed to work, no? I had an itch, I scratched it. I noticed others had the same itch, so I offered it up. Now, unbeknownst to me, the Turbine project over at java.apache.org also has a connection pooling library with similar functionality. Maybe it's my fault for not knowing this. Maybe it's the struts-dev folks fault (sorry guys) for failing to mention that there is a connection pooling library in Turbine over at java.apache.org. Maybe it's Apache's fault for not providing a clear picture of what is available and where. Maybe it doesn't matter anyway because I think my pool is better designed, easier to maintain, or more feature rich than the existing one, in which case I think it's up to the community to decide which implementation they'd like to use. (And before we go off on a a holy war here, I'm not saying that I do think that. I'm specifically not saying that one impl is better or worse than the other. Not having looked at the Turbine stuff in detail, I'm in no position to state that. I'm just saying that that is a valid position to take. It could be wrong (in the eyes of the community) but it's not unreasonable.) Jon's response to this, when brought up in a slightly different context, was a bit off-putting: Meanwhile, I do think there would be a lot of interest in a Jakarta connection pool. In fact, someone has offered to donate one to Struts. http://marc.theaimsgroup.com/?l=struts-devm=97967619230491 Totally friggen lame. *All* of that code (and more) is already implemented in Turbine and can be used outside of the core "Turbine" system very easily. If all of that functionality is available in Turbine, that makes it *redundant*, not lame. Moreover, having poked around a bit in the Turbine stuff (and granted, I didn't poke that hard or that long, so maybe I missed it), it seems to me that not "all of that code is already implemented in Turbine". Specifically, (a) I don't see that Turbine is doing any pooling of PreparedStatements, which if you recall was the major itch I was trying to scratch, (b) Turbine's Connection pool seems to require specific references to TurbineDB--so that legacy code has to be retrofitted to work with Turbine's pool, (c) Turbine's pool doesn't seem to support a javax.sql.DataSource interface. Could Turbine's pool be modify to support these things? Of course, but I wasn't aware of Turbine's pool when I first submitted mine. Moreover, Jon's response doesn't make me feel like my contribution is very welcome there. Frankly, there seems to be some underlying Turbine vs. Struts politics here that I don't want to get involved in. If you'd like to debate the merits of one pooling implementation versus another, or to work to see the full suite of functionality implemented in a single pooling library, or perhaps to debate whether or not more than one pool implementation is warranted, then let's do so. But I don't think a knee-jerk response like that does much more than alienate potential developers. I was going to segue this into a discussion of how a more modular utility/services/library project or set of projects is warranted, but I see that Morgan and Ted have already kicked that off in earnest, so I'll follow up in that thread. - Rod -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 4:23 PM To: '[EMAIL PROTECTED]' Subject: RE: What is Jakarta? It may not be easier, but it's certainly more fun. And it often seems easier to build to suit than to adapt something. -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 3:24 PM To: [EMAIL PROTECTED] Subject: Re:
Problems getting Apache-Tomcat on the jk-module running!
Hi everybody, could somebody please give me a hint, on how to get Apache-Tomcat on the jk-module running??? I've tried everything... Discription: --- I'm using Apache 1.3.17 and Tomcat 3.2.1 (JDK 1.3) on a Linux-Maschine. I've built Apache with the mod_jk.c of the source distribution of Tomcat: ./configure \ --prefix=/usr/local/kalle/apache \ --enable-rule=SHARED_CORE \ --add-module=/usr/local/kalle/jakarta-tomcat-3.2.1-src/src/native/apache1.3/ mod_jk.c \ --enable-module=most \ --enable-shared=max \ --disable-rule=WANTHSREGEX \ --enable-shared=jk (I also tried to build the mod_jk-adapter from the source distribution of Tomcat and adding this to Apache (shared object building enabled) manually.) I've checked the resulting structure of Apache, and it looks just fine (jk-module was added). The mod_jk.conf-auto of Tomcat is included. I've configurated Tomcat to match the work. The Problem: --- As I try to start Apache I get an error: # apachectl start Syntax error on line 238 of /usr/local/kalle/apache/conf/httpd.conf: Cannot load /usr/local/kalle/apache/libexec/mod_jk.so into server: /usr/local/kalle/apache/libexec/mod_jk.so: undefined symbol: map_name_at ./apachectl start: httpd could not be started --- What does this msg mean, and how could I prevent it?? Thanks for Your help, C.H. Liljegren Virtos GmbH http://www.virtos.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is reuse
Conor MacNeill wrote:
So now we have connection pooling code in two places.
Duplication isn't great but it happens, and sometimes
it even happens in the same project. It is a
refactoring opportunity. Now that we have recognized
that, surely we can find the best solution, find
somewhere for it to live (which may be where it
already lives) and increase our reuse going forward.
The bigger issue is to improve our communications,
cataloging, etc so reuse is easier, going forward.
To borrow a popular phrase from the 70's, "duplication happens". For those
of you who are too young, go see a great movie named Forrest Gump.
I'm not overly concerned about non-observable duplication, but when each
project requires its own separate set of database connections something is
wrong.
This seems to me to be exactly the sort of cross-project
issue the PMC is designed to handle. Perhaps the PMC
should consider whether to adopt a policy of reuse across
Jakarta projects, what that policy might be, whether the
policy should be promoted through a library subproject, etc.
Recast into corporate terms, three PMC members (Jon, Craig, and myself)
identified this issue and put out a request for a task group to be formed.
A number of people volunteered and the discussions are published for all to
see.
The original note that sparked this ("What is Avalon?") was one week old
last night. Welcome to the wonderful, and fast paced, world of open
source.
One final point, the PMC does not determine the content of the Jakarta web
site, nor will it be publishing a catalog. We leave that to volunteers.
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: What is Jakarta?
Thursday, February 08, 2001 10:29 AM GOMEZ Henri wrote: I'm +1 with Arieh Markel about . Jakarta Base Network Utilities . Jakarta Base JSP Utilities . Jakarta XML Utilities . Jakarta SMTP Utilities . Jakarta Tools How do you make the tools so that they don't tie into applications too closely, or become sub-applications - not needed to build any Jakarta project. Or can they if they are still add on tools for a Jakarta package. Theo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Long] Code Sharing Concepts
Several times, on several developer lists here within the Jakarta community and elsewhere, the question comes up -- "why aren't we sharing more code between projects and subprojects"? Lots of us have opinions and experiences about where this has worked (and not worked) for them in the past. The purpose of this thread is to discuss how we can create and/or accumulate some infrastructure within Jakarta to encourage sharing. In order to accomplish this, some discussion on a wide ranging set of concepts would be useful, so we can come to consensus on what steps we'd like to see the Jakarta community do (if anything), and how. As a starting point for these discussions, I've outlined a few issues below we might want to consider. (1) Subproject Or Community Resource? This is a fundamental organizational / process question. If a shared library codebase is to be a separate Jakarta subproject, it would need to be managed in the usual manner (sponsored by a set of initial committers, have an initial codebase, proposed to PMC, voted and accepted). Alternatively, the shared code could be a "resource" to the entire project, but that raises some interesting process and policy questions: * Who gets commit access? All committers on all subprojects? If not all, how do you choose? * Who decides whether a proposed codebase should be added to the shared library? * Who arbitrates cases of conflict over goals of a particular module or set of classes within the shared code? These issues are all normally handled by committer votes in a normal Jakarta subproject -- the absence of such processes would seem almost certain to create conflict. Therefore, IMHO, we should commission a regular subproject for this (assuming there are enough interested committers with enough code to be worthwhile). NOTE: As with Ant, there is an issue of whether code in a shared library like this fits the scope of the Jakarta Project as a whole, as defined by the Board of the Apache Software Foundation. We have sort of established a precedent that saying "libraries useful in the construction of server components" (such as the regular expression libraries) are in scope -- but would we accept a library of Swing GUI components? Even if they were going to be used to build admin consoles for server apps? (2) Functional Scope - What Is A Shareable Package? IMHO we need to identify some basic rules that define what code modules are reasonable candidates for being included in the shared library (instead of in a particular subproject). The following paragraphs identify some dimensions along which such a decision might be defined. (2a) Horizontal or Vertical Orientation Peter Donald spoke of "vertical" integration as a typical model of code sharing that goes on now -- projects that depend on each other, but semi-autonomously. It seems to me that what we are talking about here is "horizontal" integration -- identifying code that is truly useful in many domains, but without carrying along the baggage of dependency on lots of other pieces of an existing subproject. There are many code modules where its pretty obvious that the functionality provided is shareable and independent. But, IMHO, above a certain level of complexity you will tend to find dependencies -- either explicit because of shared APIs or implicit because of shared design assumptions -- on particular application use cases or design patterns. We should strive, at least initially, to collect code that is relatively simple and independent of such assumptions, to avoid concerns about vertical dependencies. Over time, we can get better at identifying the selection criteria for more complex cases. (2b) External Dependencies A fairly unambiguous criteria that can be used for admitting proposed modules to the shared library are what external dependencies that code has. The following paragraphs identify some simple cases that we should create policies for: Core Java APIs - JDK 1.1 or 1.2? - Many Jakarta subprojects still wish to (or must) remain compatible with JDK 1.1. Does that mean the entire shared codebase must be JDK 1.1-compatible? Do we support multiple versions of some functionality to support this? Optional Java Package APIs - If a shared component provides functionality around a standard Java API (such as a connection pool around the JDBC APIs), should it be required to conform to those APIs, or may it define its own? What happens when a Java API is standardized after existing implementations of an API (past example = JDBC data sources; upcoming example = JSR for a Logging API)? Should it be possible to build the shared library (without support for this particular API) if the API itself is not available on the developer's environment? External Package Wrappers - It is reasonable to visualize JavaBeans (or collections of JavaBeans) that provide insulation wrappers around complex external packages (such as an XML parser) that make use of those packages. If
Re: bugs
on 2/8/01 1:19 AM, Ceki Glc at [EMAIL PROTECTED] wrote: 1) Who should be contacted in case of problems with ABDB? I have refrained from listing Pier's address publicly. webmaster@ -- we need to get some more people behind that address to make sure that things are handled. 2) Why should a user need to file a bug report with ABDB and post to the corresponding developers mailing list? I think that filing a bug report should automatically trigger a post to the appropriate dev ML. Another possibility is to *make sure* that the concerned developers get notified through e-mail about the bug report. The requirement to have the user report bugs twice, once through ABDB and once through a ML is not optimal. Agreed. -- James Duncan Davidson http://x180.net/ !try; do(); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What is Jakarta?
Costin Manolache wrote: What's wrong with having multiple thread pools or db pools, each having special characteristics and working best in different situations ? Different, plug compatible, db pools would be great. Having each project early bind to a specific one is not. If I wanted to run JetSpeed and Coocoon today on the same web server, I would have to statically apportion my database connections between the two. Add Struts into the mix and I must further subdivide. Overall, I'm not overly concerned if we have multiple XML mappers. Arguably it would be better if we didn't, but on the other hand a little duplication sometimes removes the requirement for a lot of coordination. In other words, if this is an itch that somebody wants to scratch, I would encourage them to do so, but if not, I wouldn't want to mandate it from above. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
