RE: Where is Cloudscape?
On Sat, 7 Aug 2004, Noel J. Bergman wrote: Brian McCallister wrote: I would strongly recommend checking out Axion they promised users a 1.0 release in [the tigris] namespace Not 1.0, but Milestone 3 I hadn't heard that until recently. See [1], which was referenced both in the proposal to [EMAIL PROTECTED] [2] and in the notice to [EMAIL PROTECTED] [3]. [1] http://axion.tigris.org/servlets/ReadMsg?list=devmsgNo=698 [2] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1384102 [3] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1180601 Is that what accounts for the delay [in fully moving to the apache infrastructure] between the Incubator being informed on October 16th that DB PMC had voted to sponsor axion to the incubator and now? Among other reasons, yes. (The warm welcome axion received at the incubator is probably another reason for delay.) When Derby was first announced I thought it may make life rough on Axion, but the more I look at using Cloudscape 10 (derby initial codebase) the more I think Axion may make life difficult for Derby There is a lot of potential for both of them. I have no idea whether we'll see the two communities and codebases merge, or just the communities with two codebases that target somewhat different, but overlapping, segments, or what. That will be up to them. How do you see the overlap and interplay between them from your review, Brian? :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating the PMC bylaws
I'm not sure I follow this statement: Non-binary voting currently relies on consensus; such as voting in a new chairman. Can one veto a new chairman? Because -1 == veto seems to be the conventional meaning of consensus around here. Also, we may want to reference or crib bits of http://jakarta.apache.org/site/decisions.html, especially with respect to what you've labeled binary voting - Rod On Thu, 5 Aug 2004, Henri Yandell wrote: I'd like to go ahead and update the PMC bylaws to reflect current reality: http://www.osjava.org/~hen/jakarta/management.html (red is add, strikethrough is remove) Before I call a vote on it, I'd like to invite anyone to suggest other essential information that should be in there, or major cockups I've made with what is in there. I plan to call a vote on it on Tuesday 10th. I would like to update the site further in the future to incorporate the information in the wiki: http://wiki.apache.org/jakarta/ but that's outside the scope of this first baby step. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating the PMC bylaws
Also, do we need to limit PMC membership to committers as a matter of policy? I suggest simply Individuals are nominated for the PMC... or something like that. - Rod On Thu, 5 Aug 2004, Rodney Waldhoff wrote: I'm not sure I follow this statement: Non-binary voting currently relies on consensus; such as voting in a new chairman. Can one veto a new chairman? Because -1 == veto seems to be the conventional meaning of consensus around here. Also, we may want to reference or crib bits of http://jakarta.apache.org/site/decisions.html, especially with respect to what you've labeled binary voting - Rod On Thu, 5 Aug 2004, Henri Yandell wrote: I'd like to go ahead and update the PMC bylaws to reflect current reality: http://www.osjava.org/~hen/jakarta/management.html (red is add, strikethrough is remove) Before I call a vote on it, I'd like to invite anyone to suggest other essential information that should be in there, or major cockups I've made with what is in there. I plan to call a vote on it on Tuesday 10th. I would like to update the site further in the future to incorporate the information in the wiki: http://wiki.apache.org/jakarta/ but that's outside the scope of this first baby step. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
requesting karma to jakarta-site2
Can I get karma on jakarta-site2 in order to update the xdocs for the commons-primitives 1.0 release? Thanks, - Rod http://radio.weblogs.com/0122027/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] promoted sub-projects
On Thu, 20 Mar 2003, [iso-8859-1] Endre Stølsvik wrote: promoted sounds bad, but there should be links someplace. How about simply moved? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jakarta Commons Locale] PROPOSAL
You might want to try this again on the [EMAIL PROTECTED] list, instead of jakarta-general (see #17 at http://jakarta.apache.org/commons/charter.html) preferably with [VOTE] in the subject line as well as PROPOSAL, if your intention is to call a binding vote right now (as opposed to discussion of the proposal). (I'll note Robert used the conventional proposal format, so we can probably assume the to line was accidental.) On Sat, 8 Feb 2003, Robert Simpson wrote: Proposal for Commons Locale component This is a proposal for creating a Locale component in the Jakarta Commons subproject, superseding and encompassing the Resources component that is currently in the Jakarta Commons sandbox. An HTML version of this proposal can be found at http://iToolSet.com/locale/PROPOSAL.html 0) Rationale There are many different types of Java(TM)* objects that may be included in Java applications that support internationalization (i18n). These include resources, message strings, formatters, Calendars, Currency objects, TimeZones, Exceptions, Collators, and BreakIterators, among others. There currently is a Resources component in the Jakarta Commons sandbox. However, there should be a common architecture for internationalization of any object, not one that is limited to Resources. Therefore, a Locale component should be added to the Jakarta Commons proper. The functions provided by the Resources component currently in the sandbox could be provided in a subpackage under the package created for the new Locale component. 1) Scope of the Component The proposal defines a common framework for internationalization of various Java classes. This internationalization typically occurs by localizing instances of Java objects to a specific Locale. The proposed framework would facilitate the internationalization of all objects to a single Locale per user, in either a single-user or multi-user environment. For example, when localizing messages, both the message patterns and the inserted arguments should be localized to the same Locale. This is a good example of why internationalization should occur at a higher level than simply the resources that supply the localized message patterns. Two interfaces, Localizable (used by classes that implement both a get and set method for the Locale) and Localized (for classes that implement a get method only) would be defined. Other implementers would be encouraged to declare their classes with one of these interfaces where appropriate. Where this occurs, any Factory classes which generate localized/localizable (localized/able) versions of those objects would be included in that same package, rather than under the Locale component. This is appropriate, since it makes sense to keep the Factory and the base class or interface it creates in the same package. In contrast, for classes provided by Sun Microsystems or third parties, where the source code could not be modified, a localized/able subclass of the Sun/third party class would be created within the Locale component, typically in a subpackage structure that in some way parallels the structure in which the base class resides (in the initial code, this has already been done for most of the Java SDK classes). This would allow other Jakarta subprojects and components to locate and include such classes in a consistent manner. 1.5) Interaction With Other Subpackages and Components In the initial code, there are a number of classes that abstract various classes provided in different versions of the Java SDKs that can be used for configuration parameters (Properties, Preferences, and the Preferences SPI). These classes might be most appropriately placed in the Jakarta Commons Util component (with specific implementations in props and prefs subpackages). If this was not acceptable, those classes could be placed under the Locale component. The proposed component will probably contribute only to other components within the Jakarta Commons subproject, primarily the util (as mentioned above) and possibly lang component. On the other hand, it is expected that other components and subpackages will make use of the Locale component anywhere they need to provide for internationalization of their objects, resulting in much heavier interaction inbound rather than outbound, which should be typical of the Commons subpackage in general. 2) Initial Source of the Package The initial source of the package would be obtained from existing code (after the addition of comments to meet Apache requirements), which can be found in a .zip file that can be downloaded from http://iToolSet.com/locale/CommonsLocale.zip. This code has been revised somewhat to demonstrate how it might appear in the Apache world, and to provide a working example. The example, which simulates the use of localized resources in a multi-user (ex: servlets) environment with both local client-side (multiple
[OT] Re: wow
I don't want to be the on-topic police guy, but clearly this isn't an issue for jakarta-general. It'd be better to send this to watchdog-dev (only) IMO, and improve the signal to noise ratio around here. (Where's Jon when you need him? :) On Thu, 23 Jan 2003, Andrew C. Oliver wrote: ;-) Henri Yandell wrote: Looks terrible. The img size is wrong. Was this sarcasm? :) It's too early in the morning to notice. On Wed, 22 Jan 2003, Andrew C. Oliver wrote: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: A Jakarta wiki?
On Sat, 21 Dec 2002, Scott Eade wrote: So how about some feedback: 1. Wiki's - love 'em or hate 'em? Love 'em, and think they would provide (a) a good way to write ad hoc documentation, (b) a good way to host certain discussions. At my day job we use an internal wiki for documentation almost exclusively, and sometimes as an effective public brainstorming tool. (And we're fairly centrally located--for distributed, asynchronous discussion a wiki is even more useful.) 2. JSPWiki - good choice or bad choice? Never used it, so no real opinion, although there seem to be a number of wiki's that are much more popular (perhaps not in java though). There's a big list of wiki impls on Ward's Wiki at http://c2.com/cgi/wiki?WikiEngines, of course. (Most wiki clones, JSPWiki included, seem to be GPLed, if that matters to anyone.) 3. Scope of the wiki(s) - ((Turbine) and (Avalon)), Jakarta or Apache? I'd like to see a wiki with at least jakarta scope. One option might be to use a wiki that supports namespaces, or a federation of wikis with intra-wiki links, so that one could create a sub-wiki per project but still support global cross-linking. For example, a intra-wiki link might look like Turbine:OracleHowTo versus plain ol' OracleHowTo. Alternatively, a simple convention of prefixing the project name might be sufficient for a shared wiki namespace, but might need support from some WikiGnomes. 4. Hosting - apache.org or external Something internal would seem official. 5. Timing - now, soon, later or never Soon. If I can use this wiki (or this makes it easier to set up another wiki) for other jakarta/apache projects, I'd be more than happy to help out however I can. Please keep me posted, either via jakarta-general, by pointing out where this discussion is happening, or via a direct note. - Rod -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Configuring Security URLs (realm)
You may have better luck on a tomcat specific list like tomcat-user. The general list is meant for jakarta-wide discussion. See http://jakarta.apache.org/site/mail.html. On Wed, 11 Dec 2002 [EMAIL PROTECTED] wrote: Hi, I want to know if there is a way to manage authorization to URL + Parameters. I am using servlets and states to identify the action in my programs, so this is very important. For now I am using this XML: security-constraint web-resource-collection web-resource-nameSample Airlines/web-resource-name url-pattern/servlet/examples.reservaVoos.Servlet/url-pattern /web-resource-collection auth-constraint role-namemanager/role-name /auth-constraint /security-constraint I need something like: ... url-pattern/servlet/examples.reservaVoos.Servlet?STATE=0/url-pattern ... Is there a way to do that??? Thanks. Don't E-Mail, ZipMail! http://www.zipmail.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: IP addresses
Yes, probably, but this isn't the right list to ask this question. If your website runs on the apache webserver, you might try one of the httpd user lists (or probably a FAQ somewhere). See http://httpd.apache.org/lists.html or http://http://httpd.apache.org/docs/. If you're talking about Tomcat, you might try tomcat-user (or probably a FAQ somewhere). See http://jakarta.apache.org/site/mail.html or http://jakarta.apache.org/tomcat/. jakarta-general is for discussion of issues and topics that impact the entire Jakarta project http://jakarta.apache.org/. On Thu, 12 Dec 2002, php user wrote: I was wondering if thier is way I can deny people access to my website via an ip address? Hopevale Union Free School District: http://www.hopevale.com This mail sent through IMP: http://horde.org/imp/ Configured By Eric Benoit: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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:
