Re: War deployment problem in geronimo 1.0-208875
We are still using the eclipse compiler for jasper under jetty. david jencks On Jul 3, 2005, at 8:07 PM, Dain Sundstrom wrote: Actually we shouldn't require a JDK for JSP pages. It looks like the stack trace is coming from jasper and IIRC we have jasper configured to use eclipse compiler which doesn't need the tools.jar. Maybe the someone accidently removed the eclipse configuration, or my memory is wrong and we never set up our server to use the eclipse compiler. -dain On Jul 3, 2005, at 7:53 PM, Aaron Mulder wrote: OK, so is the answer that for now, we require a JDK and not a JRE? If so, that should get the original poster back on track. Aaron On Sun, 3 Jul 2005, Dain Sundstrom wrote: The tools jar hack will be needed until we delete the OpenORB stub/ tie compiler. I should have this change committed in the next few days, and then we can remove the hack code. -dain On Jul 3, 2005, at 6:20 PM, [EMAIL PROTECTED] wrote: After a quick look.. Geronimo's Daemon class is still calling ToolsJarHack.install(). Jasper2 (the JSP handling component) which is part of Tomcat as of version 5.5.0 bundles the eclipse JDT to allow tomcat to run on a JRE, according to http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ jasper-howto.html The Jetty doco also says Jasper2 is used by Jetty: http:// jetty.mortbay.org/jetty/readme.txt So it appears that the ToolsJarHack isn't needed, but has anyone tested both Tomcat and Jetty without tools.jar? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. Dain Sundstrom <[EMAIL PROTECTED]> wrote on 04/07/2005 06:50:39 AM: It is supposed to use the eclipse compiler so there should be no searching at all. -dain On Jul 3, 2005, at 12:49 PM, David Blevins wrote: On Sun, Jul 03, 2005 at 01:21:23PM +0200, Oliver Kiessler wrote: hi list, I just installed geronimo 1.0-208875 and deployed a simple webapplication with just a few JSP pages. The deployment via the deployer.jar went fine. But when I accessed the webapplication via the webbrowser I got the following error: HTTP ERROR: 500 Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/ lib/ ext/tools.jar RequestURI=/karma/ Powered by Jetty:// 13:10:19,660 INFO [Container] Started HttpContext[/,/] 13:10:26,860 WARN [/karma] /karma/: org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar at org.apache.jasper.compiler.TldLocationsCache.init (TldLocationsCache.java:252) at org.apache.jasper.compiler.TldLocationsCache.getLocation (TldLocationsCache.java:223) at org.apache.jasper.JspCompilationContext.getTldLocation (JspCompilationContext.java:519) [...] My system: Fedora core 4 Kernel 2.6.11-1.1369_FC4 java version "1.4.2_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode) Looks like there is an error finding the jar containing the javac compiler required for JSP support. It certainly won't find it in the jre directory. I know we have (or had) some code to deal with this. Anyone else have more info? -David
Re: Unified Tomcat/Jetty Plans
Rather than adding code to the builders to accept obsolete schema versions, I would rather provide a standalone tool to update old plans. I don't want to get into the business of supporting non-formally-released obsolete formats forever. Thoughts? thanks david jencks On Jul 3, 2005, at 11:14 PM, David Jencks wrote: On Jul 3, 2005, at 8:17 PM, Aaron Mulder wrote: Jeremy, No need to exaggerate. You can take a friendly tone and still make your point. No one's saying that altering configuration formats is a "good" thing, just that it will steadily get "worse" the more stable the server gets. And note that an "unstable" release is exactly that -- we need a well-documented Milestone 4 release to direct new users to. In the mean time, I'm trying to set up a weekly build environment here, so hopefully I'll put up a fresh "unstable" release from that tomorrow. Finally, as for the extra mile, I have no idea how to get XMLBeans to accept an XML file that could contain one of two namespaces, but is otherwise identical in content (to handle old Jetty files). Any constructive tips? I think this is fairly easy to do using an xmlcursor. I do a lot of it in SchemaConversionUtils to convert the namespace of the embedded naming and security elements to their actual namespaces. If we add this I think we should print a loud warning that the behavior will not be supported forever. I suppose for Tomcat we could implement a schema converter that would turn the Tomcat-specific elements into container-config elements, but this seems like a lot of work. If we get a lot of feedbcak from confused Tomcat users I'll be happy to look into if further. I would think that the tomcat integration is new enough so we don't have to worry about this. thanks david jencks Aaron P.S. To address Dain's comment, I think he'd agree we need to call a moratorium on config changes once we reach a certain level of pre-1.0 stability -- perhaps RC builds or whatever. On Sun, 3 Jul 2005, Jeremy Boynes wrote: So let me get this right ... * announce to the world we pass the CTS tests and put out an unstable release * just when people are looking at the project, change the deployment plans in an incompatible way * don't provide any upgrade tool, just tell users they need to edit all their existing plans * tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out And this is somehow supposed to encourage people to use this software? Aaron, I appreciate what you are trying to do. Please go the extra mile and make sure existing plans continue to work - it is not hard to do and will avoid putting off a lot of potential users. -- Jeremy Dain Sundstrom wrote: +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Questions about CORBA
Dain Sundstrom пишет: If it comes down to fixing OpenORB or writing our own ORB, I think writing our own will be faster. OpenORB is quite difficult to understand and was written before many modern concepts like IoC were introduced. The biggest problem this the current OpenORB codebase is that it doesn't properly implement IIOP so it cant talk to any other ORBs (and it is difficult to find the code to fix). Can you provide an example? We using OpenORB for our products about 5 years, it properly work with OmniORB at less. Anyway, I say we stick with the sun orb until something better comes along. -dain On Jul 1, 2005, at 12:30 PM, Aaron Mulder wrote: On Fri, 1 Jul 2005, Jacek Laskowski wrote: I thought about it, but I like Alan's idea better to fix OpenORB issues instead of reinventing the wheel. I'd believe it's the fine and straight way to incorporate yet another open source project under Geronimo umbrella or grasp the CORBA concepts patching OpenORB and forking it at some time to create a new project. I'm leaning towards the former rather than the latter. I can't say that I fancy trying to implement an ORB from scratch. I was just trying to put all the options on the table. As for OpenORB, I don't know enough about the state of that project and what would need to be done to make any recommendation myself. Also, I'm not aware of any particular info on the Wiki, but again, I haven't been much involved in CORBA so far. Other than to curse at it, of course. :) It would be great to find a winning path forward. Aaron BTW, is there a wiki page about CORBA stuff? When I asked the question I first had looked at Wiki and couldn't find anything, so either it doesn't exist yet or is not easy to find. All in all, I'm sure we could add a bit more to Wiki now. The thread gives some alternatives to think about. Aaron Jacek
Re: Unified Tomcat/Jetty Plans
On Jul 3, 2005, at 8:17 PM, Aaron Mulder wrote: Jeremy, No need to exaggerate. You can take a friendly tone and still make your point. No one's saying that altering configuration formats is a "good" thing, just that it will steadily get "worse" the more stable the server gets. And note that an "unstable" release is exactly that -- we need a well-documented Milestone 4 release to direct new users to. In the mean time, I'm trying to set up a weekly build environment here, so hopefully I'll put up a fresh "unstable" release from that tomorrow. Finally, as for the extra mile, I have no idea how to get XMLBeans to accept an XML file that could contain one of two namespaces, but is otherwise identical in content (to handle old Jetty files). Any constructive tips? I think this is fairly easy to do using an xmlcursor. I do a lot of it in SchemaConversionUtils to convert the namespace of the embedded naming and security elements to their actual namespaces. If we add this I think we should print a loud warning that the behavior will not be supported forever. I suppose for Tomcat we could implement a schema converter that would turn the Tomcat-specific elements into container-config elements, but this seems like a lot of work. If we get a lot of feedbcak from confused Tomcat users I'll be happy to look into if further. I would think that the tomcat integration is new enough so we don't have to worry about this. thanks david jencks Aaron P.S. To address Dain's comment, I think he'd agree we need to call a moratorium on config changes once we reach a certain level of pre-1.0 stability -- perhaps RC builds or whatever. On Sun, 3 Jul 2005, Jeremy Boynes wrote: So let me get this right ... * announce to the world we pass the CTS tests and put out an unstable release * just when people are looking at the project, change the deployment plans in an incompatible way * don't provide any upgrade tool, just tell users they need to edit all their existing plans * tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out And this is somehow supposed to encourage people to use this software? Aaron, I appreciate what you are trying to do. Please go the extra mile and make sure existing plans continue to work - it is not hard to do and will avoid putting off a lot of potential users. -- Jeremy Dain Sundstrom wrote: +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Publishing unstable builds (i.e. unofficial releases)
On 7/3/05, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> I have a box I can set up to run builds. It's not going to be an
> ssh host for the outside (e.g. you), but it can do nothing but pump out
> Geronimo builds.
I was going to do the same thing on one of my servers, but I didn't
see the value in it if I couldn't expose it to the public. I suppose
offering the build artifacts that are produced is what's important.
Maybe I should just take that route.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Publishing unstable builds (i.e. unofficial releases)
I have a box I can set up to run builds. It's not going to be an ssh host for the outside (e.g. you), but it can do nothing but pump out Geronimo builds. Aaron On Sun, 3 Jul 2005, Bruce Snyder wrote: > On 7/2/05, David Blevins <[EMAIL PROTECTED]> wrote: > > > So I created this script quite a while ago and just want to let the > > committers know how to run it. > > Have we found a server where this can be run successfully? I tried > this on minotaur a while back and couldn't get past the port conflicts > and had to give up because I was not aware of any other servers. > > While in San Francisco last week, Winston mentioned a four way Itanium > server that was donated by Simula and Intel. Is this server available > for only the Codehaus?
Re: Unified Tomcat/Jetty Plans
Dude, need you use the f-bomb? Is this -- "Non-technical tip: think about the f***ing users" -- honestly your idea of a professional interaction with your peers? By the way, I think you were exaggerating when you said "tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out". Do you feel that's an accurate representation of the other side of this conversation? As far as stability goes, I hate to say it, but we're not there yet. I'm going to have to make massive change to my book for the next milestone. The entire security system looks nothing like it did in M3, web services were not present in M3, MDBs did not work in M3, CMP was incomplete in M3, there was no Tomcat option at all in M3, and the list goes on. Add all that up, and removing 6 characters from a namespace is a trivial change. I don't think anyone *should* be contemplating Geronimo for anything "serious". We haven't even released a beta yet! And on the topic of coordination for builds, it's true we could do better. But you know what? Flaming me (or David, not sure who you were targeting, really) doesn't help. If you'd like to propose a build, such as M4, and ask for a feature freeze while we prepare and test it, I think that would be a great idea. It would have been nice to have done that before we announced that we pass the test, but let's go from where we are. As far as design work goes, we've historically not had the position of review-then-commit. I think we're trying to increase the amount of discussion and planning on the list, but I'm not prepared to go to a review-then-commit strategy. Are you? Short of that, yes, let's talk on the list as we have been, but we also need to be prepared to make adjustments to code that's committed as issues are identified. Which leads me back to the web plans. Some of your comments aren't clear to me. For example: "How about defining a common interface for the runtime bits that both Jetty and Tomcat runtimes can implement?" Jetty and Tomcat are operating off the same XMLBeans right now. If there's further unification that can be done -- by merging "runtime bits", let's work on it. But that doesn't have anything to do with the XML format. Honestly, the easiest path is going to be to just get XMLBeans to ignore the namespace difference, since again, the XML content is the same. So I'll ask again, do you know of a way to do that? Some flag we can send it to forget the namespace and just try loading the elements that it expects? If so, let's make that change and move on, instead of arguing ad naseum over whether that change should have been made in the past. Aaron On Sun, 3 Jul 2005, Jeremy Boynes wrote: > Aaron Mulder wrote: > > Jeremy, > > No need to exaggerate. You can take a friendly tone and still > > make your point. > > Where was I exaggerating? You can also answer without being > condescending. Anyway, enough with the personal comments. > > > No one's saying that altering configuration formats is a > > "good" thing, just that it will steadily get "worse" the more stable the > > server gets. And note that an "unstable" release is exactly that -- we > > need a well-documented Milestone 4 release to direct new users to. In the > > mean time, I'm trying to set up a weekly build environment here, so > > hopefully I'll put up a fresh "unstable" release from that tomorrow. > > > > There's "unstable" and there's "unstable" - hopefully common sense would > say that the first release after a major achievement like CTS complete > is likely to garner more attention than just another weekly and hence a > little more care would be in order. > > That your changes went in the revision after DB cut that release > indicates a massive lack of co-ordination in the project. > > > Finally, as for the extra mile, I have no idea how to get > > XMLBeans to accept an XML file that could contain one of two namespaces, > > but is otherwise identical in content (to handle old Jetty files). Any > > constructive tips? > > > > Do some design work before committing changes? If you send ideas to the > list first then we can all review them beforehand rather than having to > deal with the aftermath. Maybe it was just me, but I did not realize > from your proposal that you were intending to invalidate all existing > plans. > > How about just leaving the existing stuff there? That way existing > applications will continue to work whilst the new stuff is being fleshed > out. That should actually give you more flexiblity in the run up to 1.0 > to get the unified solution right without interfering with the > developing user base. > > How about defining a common interface for the runtime bits that both > Jetty and Tomcat runtimes can implement? That should simplify the > builder code allowing you to support the old schemas with less duplication. > > Have you
Re: Publishing unstable builds (i.e. unofficial releases)
Bruce Snyder wrote, On 7/3/2005 9:58 PM: On 7/2/05, David Blevins <[EMAIL PROTECTED]> wrote: So I created this script quite a while ago and just want to let the committers know how to run it. Have we found a server where this can be run successfully? I tried this on minotaur a while back and couldn't get past the port conflicts and had to give up because I was not aware of any other servers. While in San Francisco last week, Winston mentioned a four way Itanium server that was donated by Simula and Intel. Is this server available for only the Codehaus? It is a box only for codehaus use. What we need to do is to ply Bob with large amounts of sharp cheddar cheese. Regards, Alan
Re: CMP mapping - cmp-field-name vs field-name
Jacek Laskowski wrote: Hi, I'm wondering why the tag in the standard DD became the in Geronimo DD - openejb-jar.xml? I can imagine that at some point the file will be auto-generated but currently while copying and pasting, it's somehow user-UNfriendly. Can we change it? Given the discussion on the web changes, I'd ask please don't break existing plans. That should be possible here by defining a choice in the schema between and and having the underlying builder code accept either form. -- Jeremy
Re: Publishing unstable builds (i.e. unofficial releases)
On 7/2/05, David Blevins <[EMAIL PROTECTED]> wrote:
> So I created this script quite a while ago and just want to let the
> committers know how to run it.
Have we found a server where this can be run successfully? I tried
this on minotaur a while back and couldn't get past the port conflicts
and had to give up because I was not aware of any other servers.
While in San Francisco last week, Winston mentioned a four way Itanium
server that was donated by Simula and Intel. Is this server available
for only the Codehaus?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: Jeremy, No need to exaggerate. You can take a friendly tone and still make your point. Where was I exaggerating? You can also answer without being condescending. Anyway, enough with the personal comments. No one's saying that altering configuration formats is a "good" thing, just that it will steadily get "worse" the more stable the server gets. And note that an "unstable" release is exactly that -- we need a well-documented Milestone 4 release to direct new users to. In the mean time, I'm trying to set up a weekly build environment here, so hopefully I'll put up a fresh "unstable" release from that tomorrow. There's "unstable" and there's "unstable" - hopefully common sense would say that the first release after a major achievement like CTS complete is likely to garner more attention than just another weekly and hence a little more care would be in order. That your changes went in the revision after DB cut that release indicates a massive lack of co-ordination in the project. Finally, as for the extra mile, I have no idea how to get XMLBeans to accept an XML file that could contain one of two namespaces, but is otherwise identical in content (to handle old Jetty files). Any constructive tips? Do some design work before committing changes? If you send ideas to the list first then we can all review them beforehand rather than having to deal with the aftermath. Maybe it was just me, but I did not realize from your proposal that you were intending to invalidate all existing plans. How about just leaving the existing stuff there? That way existing applications will continue to work whilst the new stuff is being fleshed out. That should actually give you more flexiblity in the run up to 1.0 to get the unified solution right without interfering with the developing user base. How about defining a common interface for the runtime bits that both Jetty and Tomcat runtimes can implement? That should simplify the builder code allowing you to support the old schemas with less duplication. Have you looked at the schema conversion stuff DJ did for the J2CA deployment descriptors (the stuff that handles the 1.0 DTD to 1.5 schema conversion)? Non-technical tip: think about the f***ing users. That you needed to modify all the TCK plans should have been a BIG HINT that this was not a good idea. Think of the other impacts: you still need to update your own book's website with the revisions, what about all the other authors? I suppose for Tomcat we could implement a schema converter that would turn the Tomcat-specific elements into container-config elements, but this seems like a lot of work. If we get a lot of feedbcak from confused Tomcat users I'll be happy to look into if further. It would be better to avoid confused Tomcat users in the first place. We have what we have on the Tomcat side and I assume there is external doco out there on it (as there is for Jetty). Keep that working whilst we work out the final form. As an aside, I think the very presence of Tomcat-specific parameters (e.g. TomcatRealm, FirstValve) indicates that the "one plan to rule them" model has issues and that the LCD is not good enough. It would be useful to continue that discussion. Aaron P.S. To address Dain's comment, I think he'd agree we need to call a moratorium on config changes once we reach a certain level of pre-1.0 stability -- perhaps RC builds or whatever. With CTS complete there are a lot of users interested in the project. The time for this is NOW. It is not just the technical mechanics, people are watching how the project is operating; blatant disregard for compatibility is a huge red flag for anyone contemplating anything serious. -- Jeremy
Re: Scheduler addition to Geronimo...
Jeff Genender wrote: Hi, I am writing an article for DevWorks on hooking in third party apps into Geronimo. The article is basically about writing a GBean for Quartz. Its written and works pretty good. Then I got to thinking...why not just place the GBean/module into Geronimo, so Geronimo can have a powerful scheduler as part of its offering. Many app servers have a minimal daemon process at best, and I thought having a full scale scheduler as part of the Geronimo offering could be a great addition and will give it an edge. Quartz is developed by OpenSymphony and after reading their license, I do not see any GPL or LGPL attachments. Does anyone know the licensing of it? Anyone have objections or issues to adding it into the distibution? I've been thinking of this one for a while, so no, I'm happy someone else picked it up. Apart from licensing, from a technical note I would like to see how this would integrate with a central Work manager so that scheduled activities could be co-ordinated with other Work. -- Jeremy
Re: Scheduler addition to Geronimo...
On 7/3/05, Jeff Genender <[EMAIL PROTECTED]> wrote:
> Quartz is developed by OpenSymphony and after reading their license, I
> do not see any GPL or LGPL attachments. Does anyone know the licensing
> of it?
All the OpenSymphony projects utilize the OpenSymphony license, a
modified Apache License v1.1. The license can be seen here:
http://www.opensymphony.com/quartz/license.action
Just to be safe, you may want to run it by the legal@ list.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
[jira] Commented: (GERONIMO-693) Need startup scripts in bin directory
[ http://issues.apache.org/jira/browse/GERONIMO-693?page=comments#action_12314982 ] Jeff Genender commented on GERONIMO-693: Do not forget the -Djava.endorsed.dirs=lib/endorsed to the java command line in these scripts or Tomcat will not run. > Need startup scripts in bin directory > - > > Key: GERONIMO-693 > URL: http://issues.apache.org/jira/browse/GERONIMO-693 > Project: Geronimo > Type: New Feature > Environment: Windows, Linux, Mac OS X > Reporter: Erin Mulder > Assignee: John Sisson > Priority: Minor > > It would be nice to have obvious startup.sh and startup.bat scripts in the > bin directory so that the user doesn't need to look at the README file to > figure out how to start the server. (java -jar bin/server.jar isn't hard -- > it's just not quite as brainless as a script called "startup"). -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-696) Too much info-level output during startup
[ http://issues.apache.org/jira/browse/GERONIMO-696?page=all ] Aaron Mulder reassigned GERONIMO-696: - Assign To: Aaron Mulder > Too much info-level output during startup > - > > Key: GERONIMO-696 > URL: http://issues.apache.org/jira/browse/GERONIMO-696 > Project: Geronimo > Type: Improvement > Reporter: Erin Mulder > Assignee: Aaron Mulder > > During startup, too much unnecessary information is written to the console. > Ideally, it should display a "Server starting..." message, followed by some > sort of small progress indicator, followed by a "Server started > successfully!" message. Only errors, severe warnings, or truly useful > environment information should go in between. (A verbose switch could be > added to allow developers to load the server with the current chatty log4j > config.) > For example: > - > > bin/startup.sh > Environment information: > JDK_HOME: /usr/lib/java > GERONIMO_BUILD: 1.0-169186 > VERBOSE_LEVEL: quiet (use -verbose to change) > SERVER STARTING.. > Now listening on: > Port 1234: JMS > Port 8080: HTTP > Port 8081: HTTPS > Port 9876: Foo > SERVER STARTED SUCCESSFULLY! > Browse to http://localhost:8080/ for web console > - -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-695) Need better progress feedback during startup sequence
[ http://issues.apache.org/jira/browse/GERONIMO-695?page=all ] Aaron Mulder reassigned GERONIMO-695: - Assign To: Aaron Mulder > Need better progress feedback during startup sequence > - > > Key: GERONIMO-695 > URL: http://issues.apache.org/jira/browse/GERONIMO-695 > Project: Geronimo > Type: Improvement > Reporter: Erin Mulder > Assignee: Aaron Mulder > Priority: Minor > > When first launching the server, it's hard to tell when startup is > complete. There are lots of pauses, and it's not clear whether there > will eventually be a "successful startup" message. This adds a bit of > uncertainty/confusion as you sit there and wonder whether it's done, > still going or broken. (It would actually be quite cool/unique to add > some sort of ascii progress bar like sftp and scp use.) -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-698) Print port map at server startup
[ http://issues.apache.org/jira/browse/GERONIMO-698?page=all ] Aaron Mulder reassigned GERONIMO-698: - Assign To: Aaron Mulder > Print port map at server startup > > > Key: GERONIMO-698 > URL: http://issues.apache.org/jira/browse/GERONIMO-698 > Project: Geronimo > Type: New Feature > Reporter: Erin Mulder > Assignee: Aaron Mulder > Priority: Minor > > Would be nice (especially for new users) to have the server print out a list > of port assignments upon successful startup. For example: > > bin/startup.sh > Environment information: > JDK_HOME: /usr/lib/java > GERONIMO_BUILD: 1.0-169186 > VERBOSE_LEVEL: quiet (use -verbose to change) > SERVER STARTING.. > Now listening on: > Port 1234: JMS > Port 8080: HTTP > Port 8081: HTTPS > Port 9876: Foo > SERVER STARTED SUCCESSFULLY! > Browse to http://localhost:8080/ for web console -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-693) Need startup scripts in bin directory
[ http://issues.apache.org/jira/browse/GERONIMO-693?page=all ] Aaron Mulder reassigned GERONIMO-693: - Assign To: John Sisson > Need startup scripts in bin directory > - > > Key: GERONIMO-693 > URL: http://issues.apache.org/jira/browse/GERONIMO-693 > Project: Geronimo > Type: New Feature > Environment: Windows, Linux, Mac OS X > Reporter: Erin Mulder > Assignee: John Sisson > Priority: Minor > > It would be nice to have obvious startup.sh and startup.bat scripts in the > bin directory so that the user doesn't need to look at the README file to > figure out how to start the server. (java -jar bin/server.jar isn't hard -- > it's just not quite as brainless as a script called "startup"). -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Publishing unstable builds (i.e. unofficial releases)
David Blevins wrote, On 7/2/2005 10:05 PM: So I created this script quite a while ago and just want to let the committers know how to run it. It's really easy, just run: $ wget http://svn.apache.org/repos/asf/geronimo/scripts/publish_build.sh && bash publish_build.sh That downloads the script and executes it. You need: - Any system with bash 2.05b - SSH keys setup at apache.org - svn, cvs, wget, zip, tar, perl, openssl - jdk 1.4.x - Maven 1.x Here are a few examples of using it: ./publish_build.sh ./publish_build.sh somewhere.com ./publish_build.sh [EMAIL PROTECTED] ./publish_build.sh somewhere.com /some/dir Thanks, David And now on: http://wiki.apache.org/geronimo/CommitterGuidelines Regards, Alan
Scheduler addition to Geronimo...
Hi, I am writing an article for DevWorks on hooking in third party apps into Geronimo. The article is basically about writing a GBean for Quartz. Its written and works pretty good. Then I got to thinking...why not just place the GBean/module into Geronimo, so Geronimo can have a powerful scheduler as part of its offering. Many app servers have a minimal daemon process at best, and I thought having a full scale scheduler as part of the Geronimo offering could be a great addition and will give it an edge. Quartz is developed by OpenSymphony and after reading their license, I do not see any GPL or LGPL attachments. Does anyone know the licensing of it? Anyone have objections or issues to adding it into the distibution? Jeff
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: We will also eventually need to update the geronimo-web.xml format to accomodate virtual hosts for both Tomcat and Jetty. Currently it's a Tomcat-specific container-config param, and once supported by both containers I think we'll want it to be a top-level element on its own. +1...this should definately be top level when we get Jetty using the virtual hosts. Jeff
Re: Unified Tomcat/Jetty Plans
We will also eventually need to update the geronimo-web.xml format to accomodate virtual hosts for both Tomcat and Jetty. Currently it's a Tomcat-specific container-config param, and once supported by both containers I think we'll want it to be a top-level element on its own. In any case, it might be smart to make a list of any other configuration changes like this we anticipate making. I've got the changes to PK generation I'm planning to put in once I can get to TranQL (change the XML structure for defining key generators in openejb-jar.xml). I'm not aware of any others off the top of my head, but perhaps others are (anything in security, CORBA, or web services?). Aaron On Sun, 3 Jul 2005, Dain Sundstrom wrote: > +1 before we release 1.0 is the exactly when we should be > encouraging this type of drastic change. After 1.0 comes out, I > doubt we will be able to make these type of changes until 2.0. I > think we should review all of our configuration files and make > usability/consistency changes before we even consider a 1.0. > > -dain > > On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: > > > On Sun, 3 Jul 2005, Jeremy Boynes wrote: > > > >> Won't this cause a problem for users, having to modify all existing > >> plans to accomodate this change? > >> > > > > Sure. But we've already agreed on the need for a single web > > deployment format, and I don't think it makes sense to support 3 > > formats > > to try to ease transition. This is one of many configuration > > changes that > > will be necessary in moving from Milestone 3 to Milestone 4. > > Hopefully we > > can minimize this kind of thing moving forward into more stable > > releases, > > but I'm not sure we're entirely there yet. > > > > I'll make sure the Wiki docs are up to date. > > > > Aaron > > > >
Re: Unified Tomcat/Jetty Plans
Jeremy, No need to exaggerate. You can take a friendly tone and still make your point. No one's saying that altering configuration formats is a "good" thing, just that it will steadily get "worse" the more stable the server gets. And note that an "unstable" release is exactly that -- we need a well-documented Milestone 4 release to direct new users to. In the mean time, I'm trying to set up a weekly build environment here, so hopefully I'll put up a fresh "unstable" release from that tomorrow. Finally, as for the extra mile, I have no idea how to get XMLBeans to accept an XML file that could contain one of two namespaces, but is otherwise identical in content (to handle old Jetty files). Any constructive tips? I suppose for Tomcat we could implement a schema converter that would turn the Tomcat-specific elements into container-config elements, but this seems like a lot of work. If we get a lot of feedbcak from confused Tomcat users I'll be happy to look into if further. Aaron P.S. To address Dain's comment, I think he'd agree we need to call a moratorium on config changes once we reach a certain level of pre-1.0 stability -- perhaps RC builds or whatever. On Sun, 3 Jul 2005, Jeremy Boynes wrote: > So let me get this right ... > > * announce to the world we pass the CTS tests and put out an unstable >release > * just when people are looking at the project, change the deployment >plans in an incompatible way > * don't provide any upgrade tool, just tell users they need >to edit all their existing plans > * tell them this is a *good* thing because we're going to keep >changing things until 1.0 finally comes out > > And this is somehow supposed to encourage people to use this software? > > Aaron, I appreciate what you are trying to do. Please go the extra mile > and make sure existing plans continue to work - it is not hard to do and > will avoid putting off a lot of potential users. > > -- > Jeremy > > Dain Sundstrom wrote: > > +1 before we release 1.0 is the exactly when we should be > > encouraging this type of drastic change. After 1.0 comes out, I doubt > > we will be able to make these type of changes until 2.0. I think we > > should review all of our configuration files and make > > usability/consistency changes before we even consider a 1.0. > > > > -dain > > > > On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: > > > >> On Sun, 3 Jul 2005, Jeremy Boynes wrote: > >> > >>> Won't this cause a problem for users, having to modify all existing > >>> plans to accomodate this change? > >>> > >> > >> Sure. But we've already agreed on the need for a single web > >> deployment format, and I don't think it makes sense to support 3 formats > >> to try to ease transition. This is one of many configuration changes > >> that > >> will be necessary in moving from Milestone 3 to Milestone 4. > >> Hopefully we > >> can minimize this kind of thing moving forward into more stable > >> releases, > >> but I'm not sure we're entirely there yet. > >> > >> I'll make sure the Wiki docs are up to date. > >> > >> Aaron > >> > > > >
Re: War deployment problem in geronimo 1.0-208875
Actually we shouldn't require a JDK for JSP pages. It looks like the stack trace is coming from jasper and IIRC we have jasper configured to use eclipse compiler which doesn't need the tools.jar. Maybe the someone accidently removed the eclipse configuration, or my memory is wrong and we never set up our server to use the eclipse compiler. -dain On Jul 3, 2005, at 7:53 PM, Aaron Mulder wrote: OK, so is the answer that for now, we require a JDK and not a JRE? If so, that should get the original poster back on track. Aaron On Sun, 3 Jul 2005, Dain Sundstrom wrote: The tools jar hack will be needed until we delete the OpenORB stub/ tie compiler. I should have this change committed in the next few days, and then we can remove the hack code. -dain On Jul 3, 2005, at 6:20 PM, [EMAIL PROTECTED] wrote: After a quick look.. Geronimo's Daemon class is still calling ToolsJarHack.install(). Jasper2 (the JSP handling component) which is part of Tomcat as of version 5.5.0 bundles the eclipse JDT to allow tomcat to run on a JRE, according to http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ jasper-howto.html The Jetty doco also says Jasper2 is used by Jetty: http:// jetty.mortbay.org/jetty/readme.txt So it appears that the ToolsJarHack isn't needed, but has anyone tested both Tomcat and Jetty without tools.jar? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. Dain Sundstrom <[EMAIL PROTECTED]> wrote on 04/07/2005 06:50:39 AM: It is supposed to use the eclipse compiler so there should be no searching at all. -dain On Jul 3, 2005, at 12:49 PM, David Blevins wrote: On Sun, Jul 03, 2005 at 01:21:23PM +0200, Oliver Kiessler wrote: hi list, I just installed geronimo 1.0-208875 and deployed a simple webapplication with just a few JSP pages. The deployment via the deployer.jar went fine. But when I accessed the webapplication via the webbrowser I got the following error: HTTP ERROR: 500 Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/ lib/ ext/tools.jar RequestURI=/karma/ Powered by Jetty:// 13:10:19,660 INFO [Container] Started HttpContext[/,/] 13:10:26,860 WARN [/karma] /karma/: org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar at org.apache.jasper.compiler.TldLocationsCache.init (TldLocationsCache.java:252) at org.apache.jasper.compiler.TldLocationsCache.getLocation (TldLocationsCache.java:223) at org.apache.jasper.JspCompilationContext.getTldLocation (JspCompilationContext.java:519) [...] My system: Fedora core 4 Kernel 2.6.11-1.1369_FC4 java version "1.4.2_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode) Looks like there is an error finding the jar containing the javac compiler required for JSP support. It certainly won't find it in the jre directory. I know we have (or had) some code to deal with this. Anyone else have more info? -David
Re: Unified Tomcat/Jetty Plans
So let me get this right ... * announce to the world we pass the CTS tests and put out an unstable release * just when people are looking at the project, change the deployment plans in an incompatible way * don't provide any upgrade tool, just tell users they need to edit all their existing plans * tell them this is a *good* thing because we're going to keep changing things until 1.0 finally comes out And this is somehow supposed to encourage people to use this software? Aaron, I appreciate what you are trying to do. Please go the extra mile and make sure existing plans continue to work - it is not hard to do and will avoid putting off a lot of potential users. -- Jeremy Dain Sundstrom wrote: +1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: War deployment problem in geronimo 1.0-208875
OK, so is the answer that for now, we require a JDK and not a JRE? If so, that should get the original poster back on track. Aaron On Sun, 3 Jul 2005, Dain Sundstrom wrote: > The tools jar hack will be needed until we delete the OpenORB stub/ > tie compiler. I should have this change committed in the next few > days, and then we can remove the hack code. > > -dain > > On Jul 3, 2005, at 6:20 PM, [EMAIL PROTECTED] wrote: > > > > > After a quick look.. Geronimo's Daemon class is still calling > > ToolsJarHack.install(). > > > > Jasper2 (the JSP handling component) which is part of Tomcat as of > > version 5.5.0 bundles the eclipse JDT to allow tomcat to run on a > > JRE, according to http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ > > jasper-howto.html > > > > The Jetty doco also says Jasper2 is used by Jetty: http:// > > jetty.mortbay.org/jetty/readme.txt > > > > So it appears that the ToolsJarHack isn't needed, but has anyone > > tested both Tomcat and Jetty without tools.jar? > > > > John > > > > This e-mail message and any attachments may contain confidential, > > proprietary or non-public information. This information is > > intended solely for the designated recipient(s). If an addressing > > or transmission error has misdirected this e-mail, please notify > > the sender immediately and destroy this e-mail. Any review, > > dissemination, use or reliance upon this information by unintended > > recipients is prohibited. Any opinions expressed in this e-mail > > are those of the author personally. > > > > Dain Sundstrom <[EMAIL PROTECTED]> wrote on 04/07/2005 06:50:39 AM: > > > > > It is supposed to use the eclipse compiler so there should be no > > > searching at all. > > > > > > -dain > > > > > > On Jul 3, 2005, at 12:49 PM, David Blevins wrote: > > > > > > > On Sun, Jul 03, 2005 at 01:21:23PM +0200, Oliver Kiessler wrote: > > > > > > > >> hi list, > > > >> I just installed geronimo 1.0-208875 and deployed a simple > > > >> webapplication with just a few JSP pages. The deployment via the > > > >> deployer.jar went fine. But when I accessed the webapplication > > via > > > >> the > > > >> webbrowser I got the following error: > > > >> > > > >> HTTP ERROR: 500 > > > >> Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/ > > lib/ > > > >> ext/tools.jar > > > >> RequestURI=/karma/ > > > >> Powered by Jetty:// > > > >> > > > >> 13:10:19,660 INFO [Container] Started HttpContext[/,/] > > > >> 13:10:26,860 WARN [/karma] /karma/: > > > >> org.apache.jasper.JasperException: Unable to initialize > > > >> TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar > > > >> at org.apache.jasper.compiler.TldLocationsCache.init > > > >> (TldLocationsCache.java:252) > > > >> at > > org.apache.jasper.compiler.TldLocationsCache.getLocation > > > >> (TldLocationsCache.java:223) > > > >> at org.apache.jasper.JspCompilationContext.getTldLocation > > > >> (JspCompilationContext.java:519) > > > >> > > > > [...] > > > > > > > >> > > > >> My system: > > > >> Fedora core 4 Kernel 2.6.11-1.1369_FC4 > > > >> java version "1.4.2_04" > > > >> Java(TM) 2 Runtime Environment, Standard Edition (build > > 1.4.2_04-b05) > > > >> Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode) > > > >> > > > >> > > > > > > > > Looks like there is an error finding the jar containing the javac > > > > compiler required for JSP support. It certainly won't find it in > > > > the jre directory. > > > > > > > > I know we have (or had) some code to deal with this. Anyone else > > > > have more info? > > > > > > > > -David > > > > > > > > >
Re: War deployment problem in geronimo 1.0-208875
The tools jar hack will be needed until we delete the OpenORB stub/ tie compiler. I should have this change committed in the next few days, and then we can remove the hack code. -dain On Jul 3, 2005, at 6:20 PM, [EMAIL PROTECTED] wrote: After a quick look.. Geronimo's Daemon class is still calling ToolsJarHack.install(). Jasper2 (the JSP handling component) which is part of Tomcat as of version 5.5.0 bundles the eclipse JDT to allow tomcat to run on a JRE, according to http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ jasper-howto.html The Jetty doco also says Jasper2 is used by Jetty: http:// jetty.mortbay.org/jetty/readme.txt So it appears that the ToolsJarHack isn't needed, but has anyone tested both Tomcat and Jetty without tools.jar? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. Dain Sundstrom <[EMAIL PROTECTED]> wrote on 04/07/2005 06:50:39 AM: > It is supposed to use the eclipse compiler so there should be no > searching at all. > > -dain > > On Jul 3, 2005, at 12:49 PM, David Blevins wrote: > > > On Sun, Jul 03, 2005 at 01:21:23PM +0200, Oliver Kiessler wrote: > > > >> hi list, > >> I just installed geronimo 1.0-208875 and deployed a simple > >> webapplication with just a few JSP pages. The deployment via the > >> deployer.jar went fine. But when I accessed the webapplication via > >> the > >> webbrowser I got the following error: > >> > >> HTTP ERROR: 500 > >> Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/ lib/ > >> ext/tools.jar > >> RequestURI=/karma/ > >> Powered by Jetty:// > >> > >> 13:10:19,660 INFO [Container] Started HttpContext[/,/] > >> 13:10:26,860 WARN [/karma] /karma/: > >> org.apache.jasper.JasperException: Unable to initialize > >> TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar > >> at org.apache.jasper.compiler.TldLocationsCache.init > >> (TldLocationsCache.java:252) > >> at org.apache.jasper.compiler.TldLocationsCache.getLocation > >> (TldLocationsCache.java:223) > >> at org.apache.jasper.JspCompilationContext.getTldLocation > >> (JspCompilationContext.java:519) > >> > > [...] > > > >> > >> My system: > >> Fedora core 4 Kernel 2.6.11-1.1369_FC4 > >> java version "1.4.2_04" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > >> Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode) > >> > >> > > > > Looks like there is an error finding the jar containing the javac > > compiler required for JSP support. It certainly won't find it in > > the jre directory. > > > > I know we have (or had) some code to deal with this. Anyone else > > have more info? > > > > -David > > >
Re: Unified Tomcat/Jetty Plans
+1 before we release 1.0 is the exactly when we should be encouraging this type of drastic change. After 1.0 comes out, I doubt we will be able to make these type of changes until 2.0. I think we should review all of our configuration files and make usability/consistency changes before we even consider a 1.0. -dain On Jul 3, 2005, at 7:25 PM, Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Unified Tomcat/Jetty Plans
On Sun, 3 Jul 2005, Jeremy Boynes wrote: > Won't this cause a problem for users, having to modify all existing > plans to accomodate this change? Sure. But we've already agreed on the need for a single web deployment format, and I don't think it makes sense to support 3 formats to try to ease transition. This is one of many configuration changes that will be necessary in moving from Milestone 3 to Milestone 4. Hopefully we can minimize this kind of thing moving forward into more stable releases, but I'm not sure we're entirely there yet. I'll make sure the Wiki docs are up to date. Aaron
Re: Unified Tomcat/Jetty Plans
Won't this cause a problem for users, having to modify all existing plans to accomodate this change? Aaron Mulder wrote: On Sun, 3 Jul 2005, Jeremy Boynes wrote: Do existing plans still work? No If not, how about providing an upgrade mechanism? Jetty: remove the /jetty from the default web-app namespace Tomcat: remove the /tomcat from the default web-app namespace - If any of the following elements were used: tomcat-realm tomcat-valve-chain virtual-host Then convert them to container config params: TomcatRealm FirstValve www.foo.com To update the TCK, I used a script that just ran sed to strip off the /jetty and it worked fine. Aaron
Re: War deployment problem in geronimo 1.0-208875
After a quick look.. Geronimo's Daemon class is still calling ToolsJarHack.install(). Jasper2 (the JSP handling component) which is part of Tomcat as of version 5.5.0 bundles the eclipse JDT to allow tomcat to run on a JRE, according to http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html The Jetty doco also says Jasper2 is used by Jetty: http://jetty.mortbay.org/jetty/readme.txt So it appears that the ToolsJarHack isn't needed, but has anyone tested both Tomcat and Jetty without tools.jar? John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. Dain Sundstrom <[EMAIL PROTECTED]> wrote on 04/07/2005 06:50:39 AM: > It is supposed to use the eclipse compiler so there should be no > searching at all. > > -dain > > On Jul 3, 2005, at 12:49 PM, David Blevins wrote: > > > On Sun, Jul 03, 2005 at 01:21:23PM +0200, Oliver Kiessler wrote: > > > >> hi list, > >> I just installed geronimo 1.0-208875 and deployed a simple > >> webapplication with just a few JSP pages. The deployment via the > >> deployer.jar went fine. But when I accessed the webapplication via > >> the > >> webbrowser I got the following error: > >> > >> HTTP ERROR: 500 > >> Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ > >> ext/tools.jar > >> RequestURI=/karma/ > >> Powered by Jetty:// > >> > >> 13:10:19,660 INFO [Container] Started HttpContext[/,/] > >> 13:10:26,860 WARN [/karma] /karma/: > >> org.apache.jasper.JasperException: Unable to initialize > >> TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar > >> at org.apache.jasper.compiler.TldLocationsCache.init > >> (TldLocationsCache.java:252) > >> at org.apache.jasper.compiler.TldLocationsCache.getLocation > >> (TldLocationsCache.java:223) > >> at org.apache.jasper.JspCompilationContext.getTldLocation > >> (JspCompilationContext.java:519) > >> > > [...] > > > >> > >> My system: > >> Fedora core 4 Kernel 2.6.11-1.1369_FC4 > >> java version "1.4.2_04" > >> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > >> Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode) > >> > >> > > > > Looks like there is an error finding the jar containing the javac > > compiler required for JSP support. It certainly won't find it in > > the jre directory. > > > > I know we have (or had) some code to deal with this. Anyone else > > have more info? > > > > -David > > >
Re: Unified Tomcat/Jetty Plans
On Sun, 3 Jul 2005, Jeremy Boynes wrote: > Do existing plans still work? No > If not, how about providing an upgrade mechanism? Jetty: remove the /jetty from the default web-app namespace Tomcat: remove the /tomcat from the default web-app namespace - If any of the following elements were used: tomcat-realm tomcat-valve-chain virtual-host Then convert them to container config params: TomcatRealm FirstValve www.foo.com To update the TCK, I used a script that just ran sed to strip off the /jetty and it worked fine. Aaron
CMP mapping - cmp-field-name vs field-name
Hi, I'm wondering why the tag in the standard DD became the in Geronimo DD - openejb-jar.xml? I can imagine that at some point the file will be auto-generated but currently while copying and pasting, it's somehow user-UNfriendly. Can we change it? Jacek
Re: War deployment problem in geronimo 1.0-208875
Oliver Kiessler wrote: contextConfigLocation /WEB-INF/applicationContext.xml org.springframework.web.context.ContextLoaderListener It's certainly not that simple as you had mentioned earlier ;) Could you try much simpler war example with only a jsp page and nothing more? If it works, add another page and go on until you find which part of the current webapp fails. oliver Jacek
Re: War deployment problem in geronimo 1.0-208875
It is supposed to use the eclipse compiler so there should be no searching at all. -dain On Jul 3, 2005, at 12:49 PM, David Blevins wrote: On Sun, Jul 03, 2005 at 01:21:23PM +0200, Oliver Kiessler wrote: hi list, I just installed geronimo 1.0-208875 and deployed a simple webapplication with just a few JSP pages. The deployment via the deployer.jar went fine. But when I accessed the webapplication via the webbrowser I got the following error: HTTP ERROR: 500 Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ ext/tools.jar RequestURI=/karma/ Powered by Jetty:// 13:10:19,660 INFO [Container] Started HttpContext[/,/] 13:10:26,860 WARN [/karma] /karma/: org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar at org.apache.jasper.compiler.TldLocationsCache.init (TldLocationsCache.java:252) at org.apache.jasper.compiler.TldLocationsCache.getLocation (TldLocationsCache.java:223) at org.apache.jasper.JspCompilationContext.getTldLocation (JspCompilationContext.java:519) [...] My system: Fedora core 4 Kernel 2.6.11-1.1369_FC4 java version "1.4.2_04" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode) Looks like there is an error finding the jar containing the javac compiler required for JSP support. It certainly won't find it in the jre directory. I know we have (or had) some code to deal with this. Anyone else have more info? -David
Re: War deployment problem in geronimo 1.0-208875
On Sun, Jul 03, 2005 at 01:21:23PM +0200, Oliver Kiessler wrote: > hi list, > I just installed geronimo 1.0-208875 and deployed a simple > webapplication with just a few JSP pages. The deployment via the > deployer.jar went fine. But when I accessed the webapplication via the > webbrowser I got the following error: > > HTTP ERROR: 500 > Unable to initialize TldLocationsCache: > /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar > RequestURI=/karma/ > Powered by Jetty:// > > 13:10:19,660 INFO [Container] Started HttpContext[/,/] > 13:10:26,860 WARN [/karma] /karma/: > org.apache.jasper.JasperException: Unable to initialize > TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar > at > org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:252) > at > org.apache.jasper.compiler.TldLocationsCache.getLocation(TldLocationsCache.java:223) > at > org.apache.jasper.JspCompilationContext.getTldLocation(JspCompilationContext.java:519) [...] > > My system: > Fedora core 4 Kernel 2.6.11-1.1369_FC4 > java version "1.4.2_04" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) > Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode) > Looks like there is an error finding the jar containing the javac compiler required for JSP support. It certainly won't find it in the jre directory. I know we have (or had) some code to deal with this. Anyone else have more info? -David
Re: Derby posts 10.1.1.0 RC
I have run this through the TCK tests using the Derby client driver with no problems. Jeremy Boynes wrote: Derby has posted a release candidate for 10.1.1.0 including the Derby client code (rather than the IBM code that used to be needed). I will be testing this with Geronimo this week - if anyone else is able to help please let me know so we can co-ordinate efforts. -- Jeremy
Re: Unified Tomcat/Jetty Plans
On Jul 3, 2005, at 10:26 AM, Jeremy Boynes wrote: Aaron Mulder wrote: I've changed Tomcat and Jetty so they use the same deployment plan format. The expected plan file is now WEB-INF/geronimo- web.xml, and the namespace is the same as before without the / jetty or /tomcat on the end. Do existing plans still work? If not, how about providing an upgrade mechanism? Maybe a quick doc showing the things that you need to change by hand. -dain
Re: Clustering (long)
This is cool stuff and an excellent intro to your code (you should put this summary on your website :) I suggest you start chatting with OpenEJB and ActiveMQ about a shared session key sooner rather then later as it could take a wile to get it into their code bases. I can't wait to see this stuff integrated, -dain On Jun 30, 2005, at 2:31 PM, Jules Gosnell wrote: Guys, I thought that it was high time that I brought you up to date with my efforts in building a clustering layer for Geronimo. The project, wadi.codehaus.org, started as an effort to build a scalable clustered HttpSession implementation, but in doing this, I have built components that should be useful in clustering the state held in any tier of Geronimo e.g. OpenEJB SFSBs etc. WADI (Web Application Distribution Infrastructure) has two main elements - the vertical and the horizontal. Vertically, WADI comprises a stack of pluggable stores. Each store has a pluggable Evicter responsible for demoting aging Sessions downwards. Requests arriving at the container are fed into the top of the stack and progress downwards, until their corresponding Session is found and promoted to the top, where the request is correctly rendered in its presence. Typically the top-level store is in Memory. Aging Sessions are demoted downwards onto exclusively owned LocalDisc. The bottom-most store is a database shared between all nodes in the Cluster. The first node joining the Cluster promotes all Sessions from the database into exclusively-owned store - e.g. LocalDisc. The last node to leave the Cluster demotes all Sessions down back into the database. Horizontally, all nodes in a WADI Cluster are connected (p2p) via a Clustered Store component within this stack. This typically sits at the boundary between exclusive and shared Stores. As requests fall through the stack, looking for their corresponding Session they arrive at the Clustered store, where, if the Session is present anywhere in the Cluster, its location may be learnt. At this point, the Session may be migrated in, underneath the incoming request, or, if its current location is considered advantageous, the request may be proxied or redirected to its remote location. As a node leaves the Cluster, all its Sessions are evacuated to other nodes via this store, so that they may continue to be actively maintained. The space in which Session ids are allocated is divided into a fixed number of Buckets. This number should be large enough such that management of the Buckets may be divided between all nodes in the Cluster roughly evenly. As nodes leave and join the Cluster, a single node, the Coordinator, is responsible for re-Bucketing the Cluster - i.e. reorganising who manages which Buckets and ensuring the safe transfer of the minimum number of Buckets to implement the new layout. The Coordinator is elected via a Pluggable policy. If the Coordinator leaves or fails, a new one is elected. If a node leaves or joins, buckets emigrate from it or immigrate into it, under the control of the Coordinator, to/from the rest of the Cluster. A Session may be efficiently mapped to a Bucket by simply %-ing its ID's hashcode() by the number of Buckets in the Cluster. A Bucket is a map of SessionID:Location, kept up to date with the Location of every Session in the Cluster, of which the id falls into its space. i.e. as Sessions are created, destroyed or moved around the Cluster notifications are sent to the node managing the relevant Bucket, informing it of the change. In this way, if a node receives a request for a Session which it does not own locally, it may pass a message to it, in a maximum of typically two hops, by sending the message to the Bucket owner, who then does a local lookup of the Sessions actual location and forwards the message to it. If Session and Bucket can be colocated, this can reduced to a single hop. Thus, WADI provides a fixed and scalable substrate over the more fluid arrangement that Cluster membership comprises, on top of which further Clustered services may be built. The above functionality exists in WADI CVS and I am currently working on hardening it to the point that I would consider it production strength. I will then consider the addition of some form of state replication, so that, even with the catastrophic failure of a member node, no state is lost from the Cluster. I plan to begin integrating WADI with Geronimo as soon as a certified 1.0-based release starts to settle down. Certification is the most immediate goal and clustering is not really part of the spec, so I think it best to satisfy the first before starting on subsequent goals. Further down the road we need to consider the unification of session id spaces used by e.g. the web and ejb tiers and introduction of an ApplicationSession abstraction - an object which encapsulates all e.g. web and ejb sessions associated with a particular client talking to a particular application. This will allow WADI to maintain the c
Re: Unified Tomcat/Jetty Plans
Aaron Mulder wrote: I've changed Tomcat and Jetty so they use the same deployment plan format. The expected plan file is now WEB-INF/geronimo-web.xml, and the namespace is the same as before without the /jetty or /tomcat on the end. Do existing plans still work? If not, how about providing an upgrade mechanism? -- Jeremy
Re: Unified Tomcat/Jetty Plans
Never mind the virtual host question...after reviewing the code, it looks like its handled. Jeff Jeff Genender wrote: Nice! Aaron, did you leave in the virtual host...that one is important for Tomcat (and will be for Jetty once its implemented)? This is great stuff. Jeff Aaron Mulder wrote: I've changed Tomcat and Jetty so they use the same deployment plan format. The expected plan file is now WEB-INF/geronimo-web.xml, and the namespace is the same as before without the /jetty or /tomcat on the end. For the couple Tomcat-specific elements, there's a new chunk that looks like this. You could actually put in chunks like this for more than one container, if for some reason you wanted to support deploying into any (and there was more than just Tomcat that took extra params). ... TomcatRealm FirstValve ... I updated the assembly and TCK plans, and ran all the tests, itests, and TCK servlet tests, but this was a substantial change, so please let me know if you're having problems. Interestingly, this should make it pretty easy to run the TCK against Tomcat, since all the application plans will be the same and it's only the core server configuration plans would need to be changed. Thanks, Aaron
Re: Unified Tomcat/Jetty Plans
Nice! Aaron, did you leave in the virtual host...that one is important for Tomcat (and will be for Jetty once its implemented)? This is great stuff. Jeff Aaron Mulder wrote: I've changed Tomcat and Jetty so they use the same deployment plan format. The expected plan file is now WEB-INF/geronimo-web.xml, and the namespace is the same as before without the /jetty or /tomcat on the end. For the couple Tomcat-specific elements, there's a new chunk that looks like this. You could actually put in chunks like this for more than one container, if for some reason you wanted to support deploying into any (and there was more than just Tomcat that took extra params). ... TomcatRealm FirstValve ... I updated the assembly and TCK plans, and ran all the tests, itests, and TCK servlet tests, but this was a substantial change, so please let me know if you're having problems. Interestingly, this should make it pretty easy to run the TCK against Tomcat, since all the application plans will be the same and it's only the core server configuration plans would need to be changed. Thanks, Aaron
Re: War deployment problem in geronimo 1.0-208875
2005/7/3, Jacek Laskowski <[EMAIL PROTECTED]>: > Oliver Kiessler wrote: > > hi list, > > I just installed geronimo 1.0-208875 and deployed a simple > > webapplication with just a few JSP pages. The deployment via the > > deployer.jar went fine. But when I accessed the webapplication via the > > webbrowser I got the following error: > > > > HTTP ERROR: 500 > > Unable to initialize TldLocationsCache: > > /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar > > RequestURI=/karma/ > > Powered by Jetty:// > > > > 13:10:19,660 INFO [Container] Started HttpContext[/,/] > > 13:10:26,860 WARN [/karma] /karma/: > > org.apache.jasper.JasperException: Unable to initialize > > TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar > > at > > org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:252) > > Hi, > > I've never seen the error, either. How does the web.xml file look like? > > BTW: You may be better off subscribing to user@ mailing list and send > the question there. web.xml: http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";> FrameworkContainer com.inceedo.karma.common.servlet.FrameworkContainer ServletComponentImpl com.inceedo.karma.common.components.ServletComponentImpl ServletWorkflowComponentImpl com.inceedo.karma.common.components.ServletWorkflowImpl basepackage app viewspath /views actionurlpattern /do/ usecontainer com.inceedo.karma.ioc.spring.SpringBeanFactoryImpl locale en 1 FrameworkContainer /do/* contextConfigLocation /WEB-INF/applicationContext.xml org.springframework.web.context.ContextLoaderListener 30 index.jsp index.html index.htm geronimo-jetty.xml: http://geronimo.apache.org/xml/ns/web/jetty"; configId="com/inceedo/karma/webapp" parentId="org/apache/geronimo/Server" > /karma false thanks, oliver
Re: War deployment problem in geronimo 1.0-208875
Oliver Kiessler wrote: hi list, I just installed geronimo 1.0-208875 and deployed a simple webapplication with just a few JSP pages. The deployment via the deployer.jar went fine. But when I accessed the webapplication via the webbrowser I got the following error: HTTP ERROR: 500 Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar RequestURI=/karma/ Powered by Jetty:// 13:10:19,660 INFO [Container] Started HttpContext[/,/] 13:10:26,860 WARN [/karma] /karma/: org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar at org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:252) Hi, I've never seen the error, either. How does the web.xml file look like? BTW: You may be better off subscribing to user@ mailing list and send the question there. oliver Jacek
Pre-fetching Feature - Now available
All, I would like to announce the availability of some CMP tuning features, which allow for the pre-fetching of a group of CMPs when: * a CMP method (CMP and CMR getters or setters included) is executed and the CMP is not already in the transactional cache; * a CMP field is accessed and its value is not already in the transactional cache; * a CMR field is accessed and its value is not already in the transactional cache; * a finder is executed; or * a select returning an EntityBean is executed. Let me try to describe the current implementation. For each CMP, a set of pre-fetching groups can be defined. These groups can be mapped to the defining CMP, its CMP fields, CMR fields, finders or selects methods. These mappings identify a group of CMPs to be pre-fetched upon transactional cache miss or execution of finders or selects. There are two types of transactional cache misses: * the CMP being invoked is not in the transactional cache; and * a CMP or CMR field being accessed is not in the transactional cache. Note that in this specific case, the CMP is in the transactional cache, yet the accessed field is not loaded. For the first type of transactional cache miss, the implementation fetches the primary key fields along with the pre-fetching group mapped to the CMP. For the second type, the implementation fetches the field value along with the pre-fetching group mapped to the CMP or CMR field. There are a couple of integration tests using the "standard" order, billing address, shipping address, line item and product CMP model there (OpenEJB itests module): * PrefetchFacadeBean.testFinderPrefetch: pre-fetching upon execution of a finder. When OrderLocalHome.findPrefetchAll is executed, billing address, shipping address, line items and products are fetched at the same time. The underlying SQL query looks like this: SELECT o.id, o.reference, // order CMP fields T0.id, T0.street, T0.city, // shipping address CMP fields T1.id, T1.street, T1.city, // billing addres CMP fields T2.id, T2.quantity, // line item CMP fields T3.id, T3.name, T3.product_type // product CMP fields FROM order_table o LEFT JOIN address T0 ON (T0.id = o.fk_shipping_address) LEFT JOIN address T1 ON (T1.id = o.fk_billing_address) LEFT JOIN line_item T2 ON (o.id = T2.fk_order) LEFT JOIN product T3 ON (T3.id = T2.fk_product) WHERE (o.id = ?) * PrefetchFacadeBean.testEJBPrefetch: pre-fething upon CMP transactional cache miss: When LineItemLocalHome.getQuantity() is executed, the related product is fetched at the same time; and * PrefetchFacadeBean.testCMPPrefetch and PrefetchFacadeBean.testCMRPrefetch: pre-fetching upon CMP or CMR field transactional cache miss. When order.getReference() and order.getBillingAddress() are respectively executed, billing address, shipping address, line items and products are fetched at the same time. I am still working on some related tunings; yet, I think that the pre-fetching feature is now available. Thanks, Gianny
War deployment problem in geronimo 1.0-208875
hi list, I just installed geronimo 1.0-208875 and deployed a simple webapplication with just a few JSP pages. The deployment via the deployer.jar went fine. But when I accessed the webapplication via the webbrowser I got the following error: HTTP ERROR: 500 Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar RequestURI=/karma/ Powered by Jetty:// 13:10:19,660 INFO [Container] Started HttpContext[/,/] 13:10:26,860 WARN [/karma] /karma/: org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar at org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:252) at org.apache.jasper.compiler.TldLocationsCache.getLocation(TldLocationsCache.java:223) at org.apache.jasper.JspCompilationContext.getTldLocation(JspCompilationContext.java:519) at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:417) at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:483) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1543) at org.apache.jasper.compiler.Parser.parse(Parser.java:126) at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:211) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:100) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:146) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:286) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:267) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:255) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:556) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:293) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:92) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:832) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:823) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:473) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:272) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:169) at org.mortbay.jetty.servlet.Default.handleGet(Default.java:312) at org.mortbay.jetty.servlet.Default.service(Default.java:232) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:92) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:832) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:823) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:473) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:623) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:814) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) 13:10:26,862 WARN [ServletHandler] /karma/: org.apache.jasper.JasperException: Unable to initialize TldLocationsCache: /usr/j2sdk1.4.2_04/jre/lib/ext/tools.jar at org.apache.jasper.compiler.TldLocationsCache.init(TldLocationsCache.java:252) at org.apache.jasper.compiler.TldLocationsCache.getLocation(TldLocationsCache.java:223) at org.apache.jasper.JspCompilationContext.getTldLocation(JspCompilationContext.java:519) at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser
Re: Webservices and jaxrpc done! -- public repost
On Jul 2, 2005, at 4:21 PM, Manfred Geiler wrote: Congratulations. BTW, a question: This is the J2EE 1.4 TCK, right? Can you please check if JavaServer Faces is also part of this TCK now? We from the MyFaces project are waiting for the TCK since weeks! And there where endless discussions at Sun. One of them: if JSF TCK will be shipped on it's own or as part of J2EE. So if you (i.e. the ASF) have already access to it, this would make things much easier for us, of course. Manfred, No, the JavaServer Faces TCK is not part of the J2EE TCK. Yes, this one is taking a long time for some reason, and I'm following up. I didn't forget. geir Thanks, Manfred Geiler (MyFaces PMC) 2005/7/2, David Blevins <[EMAIL PROTECTED]>: I posted this to our private tck list a few days ago. Now that we've passed all tck tests, I can legally share it and invite everyone to stand up and applaud some people who have worked very hard on the web services side of our great Geronimo. Some content ommitted for legal reasons. Let's show these guys some love! -David - Forwarded message from David Blevins <[EMAIL PROTECTED]> - I just ran the entire jaxrpc and webservices sections of the tck and hours and passing tests later I'm proud to annouce, we are done! We have it all locked up, nailed shut, and ready to go. Just in case anyone gets the funny idea that I did all or most of this work by myself, I really want to take a moment and thank the guys that made it happen. Even in another year I could never have done what these guys did. David J., this man keeps my butt in line. If you slow down even a bit he will code you over! Before you're even done checking your email in the morning, David will have you buried under a pile of code so big it will take you all day to read and a whole week to rewrite. I swear the guy got smart years ago and wrote a code generator generator and has been cashing in on it ever since. How else could anyone write so much code?!? Gianny. I think Gianny is a sick in the head. Seriously, you can barely finish saying the word "mapping" and Gianny will be right there halfway finished with a "patch". Patch being an extremely understated way of saying complete implementation of everything you missed or didn't get around to. I say he's sick cause I think he actually enjoys this stuff. CMP mapping, Java to XML Schema/WSDL mapping, I don't know what planet he's from, but if the mother ship could send a few more guys over that would be great! Hiram. Talk about good sport. I jerked him back and forth between the same two tasks like fifty million times. It was like pong. I can't count how many times he implemented wsdl rewriting for swapping out address locations. When not being distracted by me, he managed to close out nearly all of the jaxrpc-api section of test in like a week and a half. Don't let the laid back latino attitude fool you; this man means business! Dims and the whole Axis team for being super sports and johnny on the spot with applying patches and pushing out new snapshot jars. You guys are raising the bar on the rest of us poor projects, knock it off :) Big round of applause and standing ovation for these guys! We're damn lucky to have them. Best regards and thanks, David Blevins - End forwarded message - -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: svn commit: r208876 - in /geronimo/trunk/modules/web-builder: ./ src/ src/java/ src/java/org/ src/java/org/apache/ src/java/org/apache/geronimo/ src/java/org/apache/geronimo/web/ src/java/org/apache/geronimo/web/deployment/ src/schema/ src/test-resourc...
[EMAIL PROTECTED] wrote: Author: ammulder Date: Sat Jul 2 19:21:55 2005 New Revision: 208876 +Copyright 2004 The Apache Software Foundation + * Copyright 2003-2004 The Apache Software Foundation Didn't we agree upon changing the copyright to include 2005 at commit? Jacek
I'm working on...PetStore deployment
Hi, Following the recent (Aaron's) style, to report what to be working on before really delve into it, I'd like to 'announce' my work on 'PetStore deployment' (http://issues.apache.org/jira/browse/GERONIMO-271) issue. I remember someone saying that plans, DDs, etc. are somewhere available, but haven't seen any progress on it recently, so here I am - working on it without waiting any longer ;) Speak up if you want to help porting. I'd be glad to hand it over to anyone who's looking for ways to contribute to Geronimo. Jacek
