Re: Supporting applications that need a database
+1 On 2/1/06, David Jencks <[EMAIL PROTECTED]> wrote: > Dain has been complaining that the default database is no more and > IIUC suggesting that we reinstate it and by default hook at least ejb > applications that don't have an explicit database configuration up to > it. Since I removed the default database I'd like to somewhat > preemptively explain my thinking. > > Based on my support experiences with another app server that did > something like this, I think this is a really bad idea. What > happened there was that no one knew how to connect their app to a non- > default database, and we got zillions of problem reports based on the > app using the default database rather than the one that was > misconfigured :-) > > I also don't think that encouraging all applications to use the same > database is a very good policy. It certainly invites collisions > between applications and reduces portability. > > We have the capabilities to build a derby database for a particular > schema, and package it , and to bundle a datasource configuration > with a j2ee app plan. This is used for the daytrader and uddi server > configurations. Rather than including a database no one should > want :-) and encouraging people to use it, I would rather see us > automate the construction of a configured database for an app, and > the construction and bundling of a datasource configuration with the > app's plan. > > thanks > david jencks > >
[jira] Created: (GERONIMO-1584) Servlet web service WSDL mangling has http://host:port//path
Servlet web service WSDL mangling has http://host:port//path Key: GERONIMO-1584 URL: http://issues.apache.org/jira/browse/GERONIMO-1584 Project: Geronimo Type: Bug Components: web, webservices Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 The URL specified in a WSDL service is totally ignored for a servlet-based web service, which is fine. Further, the WSDL is mangled so that when access at (service URL)?wsdl the correct URL to the service is provided. However, when this is done, an additional slash is inserted into the URL: http://localhost:8080//context/path-to-service"/> There should only be one slash after the port. -- 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] Created: (GERONIMO-1583) Servlet web service is created once and destroyed many times
Servlet web service is created once and destroyed many times Key: GERONIMO-1583 URL: http://issues.apache.org/jira/browse/GERONIMO-1583 Project: Geronimo Type: Bug Components: web, webservices Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 I deployed a servlet-based web service that implements ServiceLifecycle. I called another servlet that invoked the web service three times (calling one method once and a different method twice). I put printlns in the init and destroy methods and got: Web Services Servlet initialized Web Services Servlet destroyed Web Services Servlet destroyed Web Services Servlet destroyed I don't know if it was the same instance or different instances, but I assume it should not be destroyed more often than it is initialized. -- 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: Geronimo dependency issues
Thanks for the response Dain. Please see the additional details I included in my response to David. I think you may be right that the GBean deployer service is using the wrong classloader. Please let me know if the additional details my other response help narrow things down further. Joe Dain Sundstrom wrote: I think there is a code problem here. The geronimo-gbean-deployer should not need to see TranQL or the transaction manager. It should only need to see the classes required to process the xml and create the GBeanData objects. I think there are few possible problems here: 1) The geronimo-gbean-deployer is seeing too many classes - For example, if the geronimo-gbean-deployer is seeing the TranQL classes, it must also be able to see all of the dependencies of TranQL which is my you need to add JTA. I think is where you currently are and suggest you back out adding the extra dependencies to the geronimo- gbean-deployer plan. 2) The GBean deployer service is using the wrong class loader to try to load the gbean service class (the class of the declared gbean service in the xml file). This should be fairly easy to check by droping a break point in the deployer and inspecting the class loader it is using. 3) The class you are loading could have unnecessary coupling which requires to many classes to be visible to the target class loader. -dain On Feb 4, 2006, at 8:31 AM, Joe Bohn wrote: Here's an update on where I'm at with this and to see if anybody has any other ideas (thanks for the help I've already received from David Jencks and Matt). The classloader problem appears to be coming from the jetty deployment of daytrader during the configs build. By trial and error I discovered that this appears to have nothing to do with OpenEJB or OpenEJB-deployer as we once thought but rather jetty- deployer. Here's a graph of the jetty-deployer parent dependencies (I followed Matt's lead on creating text diagrams :-) ). geronimo-gbean-deployer j2ee-server A A | parent | |--| | j2ee-deployer jetty A A | parent | |--| | jetty-deployer Debug messages seem to indicate that the classloader in question is the geroniom-gbean-deployer class loader and I have had some marginal success (ie. changing the problem) by including dependencies in this config. However, I can't quite make sense of it. geronimo-gbean-deployer never had a dependency to rmi-naming to begin with. On the other hand, both the jetty config and the j2ee- server config do have a dependency to rmi-naming. So I would have thought that adding the tranql dependency here would improve things. But it had no effect at all. However, it changes the problem if I add the tranql dependency to geronimo-gbean-deployer. I then get this error: 26979 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.NoClassDefFoundError: javax/transaction/TransactionManager With Matt's help I found this class in the jta spec and added a dependency for that as well to geronimo-gbean-deployer which then resulted in this error: 14371 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.LinkageError: loader constraints violated when linking javax/transaction/UserTransaction class I'm not even sure exactly what a LinkageError is but I wonder if I'm just chasing my tail anyway. Having the dependency on tranql et. al. in geroniom-gbean-deployer might not be any better than having it in rmi-naming (still seems misplaced). Any hints/suggestions are welcome. BTW, out of about 22 questionable jars included in the minimal tomcat assembly I was able to remove 19 of them with the minimal assembly still functioning. Of course, I can only make these changes for that assembly if I can get around these side-effect problems in other configurations and assemblies. Joe Joe Bohn wrote: I'm looking to eliminate some of the unnecessary dependencies defined in our modules and configurations so that we can build smaller assemblies. While investigating what would be necessary to remove the tranql jar from the minimal assembly I removed a dependency to tranql in the rmi-naming configuration. I expected some problems, but the result I received is a bit strange. I get the NoClassDefFoundError listed below when deploying (as part of the build) the configuration for Daytrader. Is this expected based upon removing the tranql dependency from rmi-naming or is there something strange going on with the classloaders? + | configurations Daytrader using derby deployed on jetty | Memory: 52M/63M + DEPRECATED: th
Re: Roadmap, tasks and things to do?
Hi all,
I have added a page at
http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+Development+Process
Please take a moment to see if your favorite topic has
made it here. The roadmap at Geronimo site is really
old. Bruce, Do you want me to format this for xdocs?
Once the infra issues are resolved, we can start
working on linking jira issues to these topics.
Thanks
Anita
>
--- Hernan Cunico <[EMAIL PROTECTED]> wrote:
> Hi Anita,
> +1 to this great initiative.
>
> There is a new structure in confluence with the idea
> of organizing all the development processes
> together. This initial structure holds a place for
> the "roadmap". It would be great if you can
> capture here the ideas discussed in the "Roadmap,
> tasks and things to do?" thread.
>
> Here is the link to the new structure.
>
>
http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+Development+Process
>
> As usual, I would really appreciate any comments on
> the proposed structure; content donation will be
> appreciated as well ;)
>
> Cheers!
> Hernan
>
> anita kulshreshtha wrote:
> >Before all these great ideas get lost in the
> > mailing list, I would like to add them to wiki.
> There
> > is a RoadMap page, I would like to rename it to
> > Features or something similar. Add a "Roadmap and
> > things to do page. I will list all the ideas along
> > with the name of the originator(s) and hope that
> they
> > will take time to break up the ideas into
> manageable
> > work and create Jira issues.
> > Please let me know if there any objections?
> > Thanks
> > Anita
> >
> > --- Bruce Snyder <[EMAIL PROTECTED]> wrote:
> >
> >
> >>This is great input from the entire community and
> I
> >>hope the ideas
> >>keep coming! I think it would be best if these
> were
> >>all entered as
> >>JIRA issues so that they can all be categorized
> and
> >>tracked.
> >>
> >>Bruce
> >>--
> >>perl -e 'print
> >>
> >
> >
>
unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E >
> >>);'
> >>
> >>Apache Geronimo (http://geronimo.apache.org/)
> >>
> >>Castor (http://castor.org/)
> >>
> >
> >
> >
> > __
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Geronimo dependency issues
David Jencks wrote: On Feb 4, 2006, at 8:31 AM, Joe Bohn wrote: Here's an update on where I'm at with this and to see if anybody has any other ideas (thanks for the help I've already received from David Jencks and Matt). The classloader problem appears to be coming from the jetty deployment of daytrader during the configs build. By trial and error I discovered that this appears to have nothing to do with OpenEJB or OpenEJB-deployer as we once thought but rather jetty- deployer. Can you explain your reasoning? The stack trace looks like it is coming out of the openejb builder. I may be mistaken, but I was basing this assumption on the following: 1) Running the daytrader config build produced these messages that led me to believe the parent was geronimo-gbean-deployer: 681 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanInstanceState for: geronimo.maven:J2EEApplication=null,J2EEModule=geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car,J2EESe rver=geronimo,j2eeType=Deployer,name=Deployer State changed from stopped to starting 681 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - Checking if parent is running: parent=geronimo.config:name="geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car" 681 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - Parent is running: parent=geronimo.config:name="geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car" Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. Retrieving document at 'META-INF/wsdl/TradeServices.wsdl'. Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. 17856 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.NoClassDefFoundError: org/tranql/ejb/EJBProxyFactory at java.lang.ClassLoader.defineClass0(Native Method) 2) config openejb-deployer already had a geronimo.dependency on tranql. 3) Adding a tranql dep. to openejb-builder didn't change the result. 3) Adding a tranql dep. to the config openejb didn't change the result. 4) Adding a tranql dep. to geronimo-gbean-deployer did change the result. Here's a graph of the jetty-deployer parent dependencies (I followed Matt's lead on creating text diagrams :-) ). geronimo-gbean-deployer j2ee-server A A | parent | |--| | j2ee-deployer jetty A A | parent | |--| | jetty-deployer Debug messages seem to indicate that the classloader in question is the geroniom-gbean-deployer class loader and I have had some marginal success (ie. changing the problem) by including dependencies in this config. However, I can't quite make sense of it. As dain mentioned, including more in the geronimo-gbean-deployer classpath is definitely the wrong approach. I believe you need to figure out why that classloader is being used rather than the openejb config classloader which is the one that should contain the tranql classes. It is possible that we need to supply a classloader such as the openejb-builder classloader to the proxy construction code. I would start by double checking that the openejb config classloader actually has the tranql classes in it and that the openejb-builder config classloader can therefore load them. Openejb config does not contain a geronimo.dependency on tranql and adding one doesn't seem to make a difference to the initial failure in daytrader jetty config. Also, openejb-builder doesn't have a dependency on openejb config. The openejb-deployer config does have a dependency (import) on openejb. However, this doesn't seem to help us get the tranql classes in the classloader (even when I added it as a geronimo.dependency). I guess I'll have to get maven working in eclipse so that I can better inspect the classloaders and determine the cause of the failure. Thanks for the tips and please let me know if this additional information helps explain things better. Joe thanks david jencks geronimo-gbean-deployer never had a dependency to rmi-naming to begin with. On the other hand, both the jetty config and the j2ee- server config do have a dependency to rmi-naming. So I would have thought that adding the tranql dependency here would improve things. But it had no effect at all. However, it changes the problem if I add the tranql dependency to geronimo-gbean-deployer. I then get this error: 26979 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.NoClassDefFoundError: javax/transaction/TransactionManager With Matt's help I found this class in the jta spec and added a dependency for that as well to geronimo-gbean-deployer which then resulted in this error: 14371 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment fai
Re: Roadmap, tasks and things to do?
Yet another item for the list: Provide an option for Stateless Session Bean web services to auto-generate WSDL, JAX-RPC mapping file, and webservices.xml. In other words, you include the Service Endpoint Interface and list in in your ejb-jar.xml, and we do the rest. This would only work if you follow all the rules (no EJBs in method signatures, all JavaBeans have an empty constructor, you don't use any data types that are too obscure, etc., etc., etc.). But man, I just did a 3-method, 4-argument EJB interface and it chalked up over 300 lines of config between the WSDL and JAX-RPC mapping, when it was 100% boilerplate mapping. Related: provide a command-line tool to generate that junk. We can look at what Axis has to start with, but AFAICT it doesn't generate the JAX-RPC mapping file, and I'd be fine accepting some limitations on our tooling and output formats in the name of having something reasonably useful for the happy path cases (starting with only Document/Literal wrapped, for example). I can't think of a great way to automate much if you want to provide your own WSDL to work with an EJB, but maybe we could generate a servlet-based service from that. The WSDL-based approaches seem harder because there's so much variation possible in the WSDL. This also goes for the client service-ref piece, where you need to produce a couple of interfaces and a JAX-RPC mapping file from the WSDL. But we can put it on the list and maybe someone will be inspired. :) Thanks, Aaron On 1/31/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > Another thing for the list: > > Plugins for popular third-party app server add-on products like (for > security) RSA, Tivoli AM, Netegrity. Of course open source options > are great, but a lot of companies seem to have a pretty fixed > infrastructure and the better Geronimo can fit into that the more > likely it would be to be adopted. > > Thanks, > Aaron > > On 1/31/06, Dave Colasurdo <[EMAIL PROTECTED]> wrote: > > We also need to decide whether Geronimo will provide any of the following: > > > > -Incremental Update - Provide a mechanism that allows users to apply > > fixes from a "dot" release to an existing *binary* installation (e.g. > > apply 2.0.1 fixes (jars) to an existing 2.0 installation) > > > > -Migration - Provide a mechanism to migrate applications and > > configurations to a later release (e.g. user upgrade from 1.0 -> 2.0) > > > > Basically providing easy ways for users to move to later versions of code. > > > > -Dave- > > > > Dain Sundstrom wrote: > > > Ever since we shipped 1.0, I have been getting a surprising number of > > > private emails from old fiends, old Geronimo contributers, companies, > > > and just random people telling me that the are excited about Geronimo > > > and want to join in. They all inevitably ask me for advise on what to > > > work on, and I really have no idea other than "look at JIRA". So I'd > > > like to solicit the community to help me create a roadmap, tasks, things > > > to do list, what ever we call it. > > > > > > Before we get into building this, I'd like to focus the discussion, so > > > we don't end up in mailing-list fantasy land :) Lets agree to not talk > > > about the technology used to track the tasks; once we have the content > > > we can discuss using JIRA, wiki, html or creating a Gopher site. > > > Secondly, lets focus on things that are reasonable to do in the next 9 > > > months. Finally, don't worry about someone else working on something > > > you want to work on. With open communication on the mailing list, I > > > think everyone will be able to work something they find interesting > > > without stepping on toes. Oh, one final thing, please don't try to > > > "take a task" until we have this list complete. > > > > > > Without further delay, here are some things off the top of my head: > > > > > > o Conversion to Maven 2 - Very important and a huge task > > > > > > o Ant versions of the Geronimo plugins > > > > > > o XDoclet for all configurations > > > > > > o Integration tests that cover servlets, webservices and jms > > > > > > o Little-G - Geronimo with a small foot print > > > > > > o Global non-persistent JNDI implementation > > > > > > o EJB 2.x - Once I get my refractor committed, it will be obvious where > > > the 2.x implementation needs work like better caching > > > > > > o JEE 5 - There is a ton of stuff under this, but it would be good to > > > start with a list of what is required for JEE 5 > > > > > > > > > > > > I don't want to speak for the other ares of Geronimo I don't work on > > > regularly, but I am sure that there are good opportunities to help in > > > the console, jms, javamail, ejb, clustering, esb/jbi/bpm, tooling, > > > performance, build, testing, samples, documentation, so if you are more > > > familiar with one of those areas, please post. > > > > > > I think this is a "once in a project chance" to build a big vibrant > > > community of developers, and let's not let
Confluence status (was: Why Confluence cannot not be used as a wiki, and how it might be fixed)
Replying primarily for the people on [EMAIL PROTECTED] Further replies should probably just go to [EMAIL PROTECTED] Someone correct me if I'm wrong. On Feb 3, 2006, at 7:08 AM, Noel J. Bergman wrote: To quote Atlassian: "Confluence will likely die if slashdotted, so shouldn't be used as a *primary* project website if slashdotting is likely." Read "slashdotting" as heavy load, and we experience sufficient load on the Wiki to make caching mandatory. IMHO, this quote comes out opposite as it was meant. On Feb 2, 2006, at 4:29 PM, Jeff Turner wrote: On Thu, Feb 02, 2006 at 11:56:44AM -0500, Noel J. Bergman wrote: Even Atlassian has recommended against Confluence as a Wiki in our enviroment at this time. Not quite; Confluence will likely die if slashdotted, so shouldn't be used as a *primary* project website if slashdotting is likely. The distinction made is: - Confluence as a wiki, Good - Confluence as a live website, Bad There are ways to use the *content* create via Confluence in a website. A number of people have working solutions already. Most fall into one of or a mix of this: 1. Serving static pages that are generated whenever from content in Confluence 2. Smart front-end generating and caching pages from Confluence A few projects do this successfully now. The Directory guys have nice system they worked up: - Confluence Page: http://docs.safehaus.org/display/APACHEDS/ Protocol+Providers - Static page in svn: http://directory.apache.org/subprojects/ providers.html Of course the Maven guys have a maven/docs based tool that does the same: - Confluence Page: http://docs.codehaus.org/display/MAVENUSER/FAQs - Static page in svn: http://maven.apache.org/auto-faq.html I think we are in good shape sans the fact that we should have our own confluence install. There seem to be a few good options for that too. I'm not quite as crystal clear on the status of those options. Someone help me out as I will likely get this wrong: 1. Host confluence on a dedicated box provided by Atlassian in our colo. 2. Refit one of our existing boxes to host confluence. 3. Have Contegix host the confluence sponsored by Atlassian. 4. Something I missed completely. Hope this helps serve as a good "checkpoint" in the discussion. Clarifications/corrections/comments welcome. -David
Re: Building Geronimo with Maven2
2006/2/2, Alan D. Cabrera <[EMAIL PROTECTED]>: > We will never swallow m2 whole. We need to gobble little bits of it at > a time, e.g. specs. How can we stage this conversion properly? Hi, Is anyone working on the m2 transition? I'd like to step in and learn Maven2 by doing the conversion. Is there anything done that would become a starting point? Is http://issues.apache.org/jira/browse/GERONIMO-851 the place to describe the task's progress? > Alan -- Jacek Laskowski http://www.laskowski.org.pl
spec jar versioning [Re: svn commit: r374834 ]
Alan, can you document our spec jar versioning policy on the wiki somewhere. I remember us discussing this a while back, I just don't want to lose our reasoning :) Thanks, -dain On Feb 3, 2006, at 11:21 PM, [EMAIL PROTECTED] wrote: Author: adc Date: Fri Feb 3 23:21:07 2006 New Revision: 374834 URL: http://svn.apache.org/viewcvs?rev=374834&view=rev Log: Versions of individual jars should reflect their contents.
Re: Geronimo and Incubation
Hi Aaron! On Sat, Feb 04, 2006 at 03:02:23PM -0500, Aaron Mulder wrote: > If you want to involve the community outside the various PMCs, then Heh. This ain't just open source, its open "just about everything". Of course I want the wider (developer) community involved...I'd hope everyone wants that -- its one of the fundamental pillars upon which apache is built! > IMHO it might be helpful for you to list or point to a writeup of the > duties of the incubator PMC. No problem! The incubator front page at http://incubator.apache.org/ is in large part devoted to being that writeup. > I'm not at all clear on what the > incubator is supposed to do other than vet code and the somewhat > abstract "ensure healthy communities". If you want to get a clearer picture, please do spend some time reading the incubator website and the [EMAIL PROTECTED] archives at http://mail-archives.apache.org/mod_mbox/incubator-general/ A lot has been said about precisely this previously. > If the code has been vetted, Actually, the incubator is (among other things) there to ensure that new stuff entering the ASF is vetted, but less so to actually /do/ the "code vetting" - the responsibility for actually doing that is pretty much completely delegated to other PMCs, or to a PPMC (like geronimo once had). Note there is no "the" code I referred to. However, according to the status files for the subprojects under incubation on behalf of geronimo, there's a whole bunch of code that hasn't been vetted just yet. > it seems clear to me that the Geronimo community is healthy I did not intend to question the health of the Geronimo community in general in my previous email. What I talked about (and questioned) was the health of the interaction between the geronimo project and the incubation process, and more specifically the interaction between the body responsible for oversight of the geronimo project (its PMC) and the incubation process. > and (with > and without the addition of the proposed subprojects) growing, so I'm > wondering what else the incubator PMC feels responsible for. Once again, please do note my email was not on behalf of the incubator PMC but completely on personal title. However, to answer your question, http://incubator.apache.org/resolution.html spells out precisely what the incubator PMC is responsible for. > I'm also > wondering why adding code and contributors to an existing healthy > project would be a bad thing. I would too. Its usually a Good Thing(tm). I don't understand where this comment is coming from at all. I certainly did not mean to imply anything along these lines. I'm sorry if that wasn't clear. > About the only thing that seems like a > problem to me (other than certain explosive e-mails, which in the main > did not seem to be from Geronimo or incubating-project members), is > the issue of proposed committers who did not actually contribute to > the projects in question (bearing in mind that code is not the only > possible type of contribution). I explicitly didn't try to compile a list of problems. That's just a really painful process which leads to lots of discussion and friction. While that may be fruitful, I don't think it would help for me to try and be a part of that process. Please do recognize there is a lot of information from private mailing lists and off-list conversations that can lead to a perspective different from yours. There's unfortunately preciously little I can do personally about reconciling this difference since it is not appropriate for me to disclose details from private discussions. IMNSHO, most of these kinds of talks should be had on public mailing lists. So even though I can't quote from private archives, I can certainly make my own contributions "as public as possible". Let's hope others do as well. cheers, LSD
Build error
Hi, I am new to Geronimo and Maven. I tried to build from the source and get the server running. I am getting the error below after running commands (after initial fresh-checkout commands) maven m:update maven -o m:clean m:clean-repo maven new -Dmaven.test.skip=true -Dmaven.itest.skip=true Any ideas how to get past this? Thanks, Roman + | configurations System Configuration for the J2EE Server | Memory: 57M/90M + You are working offline so the build will continue, but geronimo-gbean-deployer-1.1-SNAPSHOT.car may be out of date! You are working offline so the build will continue, but geronimo-common-1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but geronimo-kernel-1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but geronimo-system-1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but geronimo-qname_1.1_spec-1.1-SNAPSHOT.jar may be out of date! car:prepare-plan: car:package: car:install: build:end: build:start: multiproject:install-callback: [echo] Running car:install for System Configuration for the J2EE Server log4j:WARN No appenders could be found for logger (org.apache.geronimo.kernel.basic.BasicKernel). log4j:WARN Please initialize the log4j system properly. java.lang.reflect.InvocationTargetException: null java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute(PackageBuilderShell.java:232) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain(Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSes
[jira] Closed: (GERONIMO-1480) Cross context include does not set jacc contextID for 2nd web app. (Tomcat only)
[ http://issues.apache.org/jira/browse/GERONIMO-1480?page=all ] Jeff Genender closed GERONIMO-1480: --- Fix Version: 1.0.1 Resolution: Fixed > Cross context include does not set jacc contextID for 2nd web app. (Tomcat > only) > > > Key: GERONIMO-1480 > URL: http://issues.apache.org/jira/browse/GERONIMO-1480 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0.1, 1.1 > Reporter: David Jencks > Assignee: Jeff Genender > Priority: Blocker > Fix For: 1.1, 1.0.1 > > If you do a cross context include from web app A to web app B, the jacc > contextID fetched from PolicyContext when you evaluate isUserInRole in web > app B is the contextID for A, not B. > Presumably the cross context dispatch does not go through the > PolicyContextValve for B. Here's a thread trace that demonstrates this, with > a couple annotations. > [EMAIL PROTECTED] daemon prio=5, in group "main", status: RUNNING > implies():80, GeronimoPolicy.java > implies():46, JaasPolicyCoordinator.java > implies():189, ProtectionDomain.java > checkPermission():254, AccessControlContext.java > hasRole():248, TomcatGeronimoRealm.java > isUserInRole():2128, Request.java > isUserInRole():761, RequestFacade.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():265, PortletRequestImpl.java > _jspService():46, roles.jsp > service():97, HttpJspBase.java > service():688, HttpServlet.java > service():322, JspServletWrapper.java > serviceJspFile():314, JspServlet.java > service():264, JspServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > include():72, JetspeedRequestDispatcher.java > doView():363, GenericServletPortlet.java > doDispatch():250, GenericPortlet.java > render():178, GenericPortlet.java > render():102, JetspeedPortletInstance.java > THIS IS WEB APP B > doGet():230, JetspeedContainerServlet.java > service():595, HttpServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > THIS IS A INCLUDING B > invoke():213, ServletPortletInvoker.java > render():125, ServletPortletInvoker.java > renderPortlet():119, PortletContainerImpl.java > renderPortlet():120, JetspeedPortletContainerWrapper.java > execute():120, RenderingJobImpl.java > renderNow():110, PortletRendererImpl.java > aggregateAndRender():199, PageAggregatorImpl.java > aggregateAndRender():182, PageAggregatorImpl.java > build():106, PageAggregatorImpl.java > invoke():48, AggregatorValve.java > invokeNext():166, JetspeedPipeline.java > invoke():132, ActionValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():76, ContainerValve.java > invokeNext():166, JetspeedPipeline.java > invoke():100, DecorationValve.java > invokeNext():166, JetspeedPipeline.java > invoke():179, ProfilerValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():143, LoginValidationValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():148, PasswordCredentialValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():168, LocalizationValveImpl.java > invokeNext():166, JetspeedPipeline.java > run():117, AbstractSecurityValve.java > doPrivileged():-1, AccessController.java > doAsPrivileged():437, Subject.java > invoke():111, AbstractSecurityValve.java > invokeNext():166, JetspeedPipeline.java > invoke():55, PortalURLValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():128, CapabilityValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():145, JetspeedPipeline.java > service():231, JetspeedEngine.java > THIS IS WEB APP A: > doGet():226, JetspeedServlet.java > service():595, HttpServlet.java > service():688, HttpServlet.java > internal
[jira] Reopened: (GERONIMO-1480) Cross context include does not set jacc contextID for 2nd web app. (Tomcat only)
[ http://issues.apache.org/jira/browse/GERONIMO-1480?page=all ] Jeff Genender reopened GERONIMO-1480: - Change fix version > Cross context include does not set jacc contextID for 2nd web app. (Tomcat > only) > > > Key: GERONIMO-1480 > URL: http://issues.apache.org/jira/browse/GERONIMO-1480 > Project: Geronimo > Type: Bug > Components: Tomcat > Versions: 1.0.1, 1.1 > Reporter: David Jencks > Assignee: Jeff Genender > Priority: Blocker > Fix For: 1.1, 1.0.1 > > If you do a cross context include from web app A to web app B, the jacc > contextID fetched from PolicyContext when you evaluate isUserInRole in web > app B is the contextID for A, not B. > Presumably the cross context dispatch does not go through the > PolicyContextValve for B. Here's a thread trace that demonstrates this, with > a couple annotations. > [EMAIL PROTECTED] daemon prio=5, in group "main", status: RUNNING > implies():80, GeronimoPolicy.java > implies():46, JaasPolicyCoordinator.java > implies():189, ProtectionDomain.java > checkPermission():254, AccessControlContext.java > hasRole():248, TomcatGeronimoRealm.java > isUserInRole():2128, Request.java > isUserInRole():761, RequestFacade.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():163, HttpServletRequestWrapper.java > isUserInRole():265, PortletRequestImpl.java > _jspService():46, roles.jsp > service():97, HttpJspBase.java > service():688, HttpServlet.java > service():322, JspServletWrapper.java > serviceJspFile():314, JspServlet.java > service():264, JspServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > include():72, JetspeedRequestDispatcher.java > doView():363, GenericServletPortlet.java > doDispatch():250, GenericPortlet.java > render():178, GenericPortlet.java > render():102, JetspeedPortletInstance.java > THIS IS WEB APP B > doGet():230, JetspeedContainerServlet.java > service():595, HttpServlet.java > service():688, HttpServlet.java > internalDoFilter():252, ApplicationFilterChain.java > doFilter():173, ApplicationFilterChain.java > invoke():672, ApplicationDispatcher.java > doInclude():574, ApplicationDispatcher.java > include():499, ApplicationDispatcher.java > THIS IS A INCLUDING B > invoke():213, ServletPortletInvoker.java > render():125, ServletPortletInvoker.java > renderPortlet():119, PortletContainerImpl.java > renderPortlet():120, JetspeedPortletContainerWrapper.java > execute():120, RenderingJobImpl.java > renderNow():110, PortletRendererImpl.java > aggregateAndRender():199, PageAggregatorImpl.java > aggregateAndRender():182, PageAggregatorImpl.java > build():106, PageAggregatorImpl.java > invoke():48, AggregatorValve.java > invokeNext():166, JetspeedPipeline.java > invoke():132, ActionValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():76, ContainerValve.java > invokeNext():166, JetspeedPipeline.java > invoke():100, DecorationValve.java > invokeNext():166, JetspeedPipeline.java > invoke():179, ProfilerValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():143, LoginValidationValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():148, PasswordCredentialValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():168, LocalizationValveImpl.java > invokeNext():166, JetspeedPipeline.java > run():117, AbstractSecurityValve.java > doPrivileged():-1, AccessController.java > doAsPrivileged():437, Subject.java > invoke():111, AbstractSecurityValve.java > invokeNext():166, JetspeedPipeline.java > invoke():55, PortalURLValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():128, CapabilityValveImpl.java > invokeNext():166, JetspeedPipeline.java > invoke():145, JetspeedPipeline.java > service():231, JetspeedEngine.java > THIS IS WEB APP A: > doGet():226, JetspeedServlet.java > service():595, HttpServlet.java > service():688, HttpServlet.java > internalDoFilter():252, Applic
Re: Geronimo dependency issues
On Feb 4, 2006, at 8:31 AM, Joe Bohn wrote: Here's an update on where I'm at with this and to see if anybody has any other ideas (thanks for the help I've already received from David Jencks and Matt). The classloader problem appears to be coming from the jetty deployment of daytrader during the configs build. By trial and error I discovered that this appears to have nothing to do with OpenEJB or OpenEJB-deployer as we once thought but rather jetty- deployer. Can you explain your reasoning? The stack trace looks like it is coming out of the openejb builder. Here's a graph of the jetty-deployer parent dependencies (I followed Matt's lead on creating text diagrams :-) ). geronimo-gbean-deployer j2ee-server A A | parent | |--| | j2ee-deployer jetty A A | parent | |--| | jetty-deployer Debug messages seem to indicate that the classloader in question is the geroniom-gbean-deployer class loader and I have had some marginal success (ie. changing the problem) by including dependencies in this config. However, I can't quite make sense of it. As dain mentioned, including more in the geronimo-gbean-deployer classpath is definitely the wrong approach. I believe you need to figure out why that classloader is being used rather than the openejb config classloader which is the one that should contain the tranql classes. It is possible that we need to supply a classloader such as the openejb-builder classloader to the proxy construction code. I would start by double checking that the openejb config classloader actually has the tranql classes in it and that the openejb-builder config classloader can therefore load them. thanks david jencks geronimo-gbean-deployer never had a dependency to rmi-naming to begin with. On the other hand, both the jetty config and the j2ee- server config do have a dependency to rmi-naming. So I would have thought that adding the tranql dependency here would improve things. But it had no effect at all. However, it changes the problem if I add the tranql dependency to geronimo-gbean-deployer. I then get this error: 26979 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.NoClassDefFoundError: javax/transaction/TransactionManager With Matt's help I found this class in the jta spec and added a dependency for that as well to geronimo-gbean-deployer which then resulted in this error: 14371 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.LinkageError: loader constraints violated when linking javax/transaction/UserTransaction class I'm not even sure exactly what a LinkageError is but I wonder if I'm just chasing my tail anyway. Having the dependency on tranql et. al. in geroniom-gbean-deployer might not be any better than having it in rmi-naming (still seems misplaced). Any hints/suggestions are welcome. BTW, out of about 22 questionable jars included in the minimal tomcat assembly I was able to remove 19 of them with the minimal assembly still functioning. Of course, I can only make these changes for that assembly if I can get around these side-effect problems in other configurations and assemblies. Joe Joe Bohn wrote: I'm looking to eliminate some of the unnecessary dependencies defined in our modules and configurations so that we can build smaller assemblies. While investigating what would be necessary to remove the tranql jar from the minimal assembly I removed a dependency to tranql in the rmi-naming configuration. I expected some problems, but the result I received is a bit strange. I get the NoClassDefFoundError listed below when deploying (as part of the build) the configuration for Daytrader. Is this expected based upon removing the tranql dependency from rmi-naming or is there something strange going on with the classloaders? + | configurations Daytrader using derby deployed on jetty | Memory: 52M/63M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo- daytrader-derby-db-1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but daytrader- ear-1.1-SNAPSHOT.ear may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for Daytrader using derby deployed on jetty Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. Retrieving document at 'META-INF/wsdl/TradeServices.wsdl'. R
Re: Geronimo dependency issues
I think there is a code problem here. The geronimo-gbean-deployer should not need to see TranQL or the transaction manager. It should only need to see the classes required to process the xml and create the GBeanData objects. I think there are few possible problems here: 1) The geronimo-gbean-deployer is seeing too many classes - For example, if the geronimo-gbean-deployer is seeing the TranQL classes, it must also be able to see all of the dependencies of TranQL which is my you need to add JTA. I think is where you currently are and suggest you back out adding the extra dependencies to the geronimo- gbean-deployer plan. 2) The GBean deployer service is using the wrong class loader to try to load the gbean service class (the class of the declared gbean service in the xml file). This should be fairly easy to check by droping a break point in the deployer and inspecting the class loader it is using. 3) The class you are loading could have unnecessary coupling which requires to many classes to be visible to the target class loader. -dain On Feb 4, 2006, at 8:31 AM, Joe Bohn wrote: Here's an update on where I'm at with this and to see if anybody has any other ideas (thanks for the help I've already received from David Jencks and Matt). The classloader problem appears to be coming from the jetty deployment of daytrader during the configs build. By trial and error I discovered that this appears to have nothing to do with OpenEJB or OpenEJB-deployer as we once thought but rather jetty- deployer. Here's a graph of the jetty-deployer parent dependencies (I followed Matt's lead on creating text diagrams :-) ). geronimo-gbean-deployer j2ee-server A A | parent | |--| | j2ee-deployer jetty A A | parent | |--| | jetty-deployer Debug messages seem to indicate that the classloader in question is the geroniom-gbean-deployer class loader and I have had some marginal success (ie. changing the problem) by including dependencies in this config. However, I can't quite make sense of it. geronimo-gbean-deployer never had a dependency to rmi-naming to begin with. On the other hand, both the jetty config and the j2ee- server config do have a dependency to rmi-naming. So I would have thought that adding the tranql dependency here would improve things. But it had no effect at all. However, it changes the problem if I add the tranql dependency to geronimo-gbean-deployer. I then get this error: 26979 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.NoClassDefFoundError: javax/transaction/TransactionManager With Matt's help I found this class in the jta spec and added a dependency for that as well to geronimo-gbean-deployer which then resulted in this error: 14371 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.LinkageError: loader constraints violated when linking javax/transaction/UserTransaction class I'm not even sure exactly what a LinkageError is but I wonder if I'm just chasing my tail anyway. Having the dependency on tranql et. al. in geroniom-gbean-deployer might not be any better than having it in rmi-naming (still seems misplaced). Any hints/suggestions are welcome. BTW, out of about 22 questionable jars included in the minimal tomcat assembly I was able to remove 19 of them with the minimal assembly still functioning. Of course, I can only make these changes for that assembly if I can get around these side-effect problems in other configurations and assemblies. Joe Joe Bohn wrote: I'm looking to eliminate some of the unnecessary dependencies defined in our modules and configurations so that we can build smaller assemblies. While investigating what would be necessary to remove the tranql jar from the minimal assembly I removed a dependency to tranql in the rmi-naming configuration. I expected some problems, but the result I received is a bit strange. I get the NoClassDefFoundError listed below when deploying (as part of the build) the configuration for Daytrader. Is this expected based upon removing the tranql dependency from rmi-naming or is there something strange going on with the classloaders? + | configurations Daytrader using derby deployed on jetty | Memory: 52M/63M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo- daytrader-derby-db-1.1-SNAPSHOT.jar may be out o
Re: Geronimo and Incubation
If you want to involve the community outside the various PMCs, then
IMHO it might be helpful for you to list or point to a writeup of the
duties of the incubator PMC. I'm not at all clear on what the
incubator is supposed to do other than vet code and the somewhat
abstract "ensure healthy communities". If the code has been vetted,
it seems clear to me that the Geronimo community is healthy and (with
and without the addition of the proposed subprojects) growing, so I'm
wondering what else the incubator PMC feels responsible for. I'm also
wondering why adding code and contributors to an existing healthy
project would be a bad thing. About the only thing that seems like a
problem to me (other than certain explosive e-mails, which in the main
did not seem to be from Geronimo or incubating-project members), is
the issue of proposed committers who did not actually contribute to
the projects in question (bearing in mind that code is not the only
possible type of contribution).
Thanks,
Aaron
On 2/4/06, Leo Simons <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm afraid I don't have time for a drawn-out discussion about any of this,
> especially
> not a heated one, but a few people asked me to write this down anyway. This
> message is
> directed primarily at the Geronimo PMC.
>
> I've just reviewed the traffic to [EMAIL PROTECTED] and [EMAIL PROTECTED] on
> all the
> different subprojects under incubation for geronimo and some of the proposed
> stuff
> and some of the it-might-be-proposed stuff and its all very unclear to me
> exactly
> what is going on.
>
> This has been the case for a while now.
>
> Just some of the things that have me scratching my head:
>
> * A variety of status files seems to not be up-to-date
> * A bunch of reminders from the incubator PMC chair for incubation status
> reports
>went unanswered
> * it seems a code grant was acked after a release vote was started
> (finished??)
>which indicates the incubation mentors / pmc are not doing their primary
> job
>(oversight) properly
> * there's a whole bunch of heated emails about a lot of this stuff where
> people
>rapidly change opinions without a lot of explanation
> * some people were proposed as committers to a subproject without them ever
>contributing a line of code to that project but that was not clear from the
>proposals
>
> and so on and so forth. I'm not going to bother to compile an extensive list;
> it should
> be obvious to most that some things are going wrong.
>
> I took a brief look at the [EMAIL PROTECTED] and [EMAIL PROTECTED] mailing
> list archives to try
> and figure out what is going on, but it seems there is a whole bunch of
> emails about
> all this stuff there that would take me most of the weekend to read. I'm not
> going to
> do that, I have more fun stuff to do with my free time! :-)
>
> That's fine, eg there's no particular need for me to read all those emails and
> understand precisely what is going on. I'm not a part of the geronimo PMC or
> its
> community and I'm not actively helping with any of the gazillion stuff under
> incubation under direction of the geronimo PMC.
>
> But, and this is important, its becoming very hard to be able to perform even
> my
> oversight duties as part of the Incubator PMC. I suspect the same is true for
> more
> than a few incubator PMC members.
>
> IMHO, the primary responsibility for making my job as incubator PMC member a
> little
> easier lies with the geronimo PMC and the mentors for the geronimo
> subprojects under
> incubation. It saddens me I even have to write this email after spending a
> whole
> lot of my hackathon weekend explaining all this stuff to a bunch of the
> people I see
> most active within Geronimo at the moment, and also discussing it at a
> stretch with
> the former and current geronimo PMC chair over the course of a few months.
>
> I feel you are more often than not doing your job as PMC properly, you're not
> listening to the many gentle pointers I've given over the years to try and
> help
> change that, and all this is making my job as an Incubator PMC member a lot
> harder,
> more involved, and also a lot less fun. I feel its not just the energy that
> I've
> invested that is totally being wasted, it is the energy of a whole bunch of
> people.
>
> Now, I realize the above is a bit abstract. So with all that in mind, a
> little more
> concretely, I have some suggestions. These are just my personal suggestions.
> In terms
> of carrots and sticks, there's only a very abstract carrot ("healthy
> community") and
> only a very big stick ("pulling the plug") that's not mine to wield, so I'm
> not waving
> any of them around; the only thing I'm trying to do is help make some sense
> out of it
> all.
>
> Anyhow, I suggest that (the "you" in the below means the Geronimo PMC as a
> collective):
>
> * you guys work to update all the incubation status files and flesh them out
> with
>much more detail
Re: Integrating Geronimo and Celtix
2006/2/4, Guillaume Nodet <[EMAIL PROTECTED]>: > I 've already answered the same question two days ago. > See http://marc.theaimsgroup.com/?l=geronimo-dev&m=113892077709751&w=2 Hi Guillaume, Yes, I had read it, but somehow forgot about it. Sorry to bother you and ask questions that had already been answered. > So the gbeans and plan exist. They only need to be re-integrated in the > geronimo build. I would be of a great value when a description on how to deploy the gbeans and what they provide. I'd also wish to read about the benefits of deploying ServiceMix onto Geronimo - something like "why would I want it". I think it's worth another thread, isn't it and possibly being sent to servicemix list. > Guillaume Nodet -- Jacek Laskowski http://www.laskowski.org.pl
Geronimo and Incubation
Hi all,
I'm afraid I don't have time for a drawn-out discussion about any of this,
especially
not a heated one, but a few people asked me to write this down anyway. This
message is
directed primarily at the Geronimo PMC.
I've just reviewed the traffic to [EMAIL PROTECTED] and [EMAIL PROTECTED] on
all the
different subprojects under incubation for geronimo and some of the proposed
stuff
and some of the it-might-be-proposed stuff and its all very unclear to me
exactly
what is going on.
This has been the case for a while now.
Just some of the things that have me scratching my head:
* A variety of status files seems to not be up-to-date
* A bunch of reminders from the incubator PMC chair for incubation status
reports
went unanswered
* it seems a code grant was acked after a release vote was started (finished??)
which indicates the incubation mentors / pmc are not doing their primary job
(oversight) properly
* there's a whole bunch of heated emails about a lot of this stuff where people
rapidly change opinions without a lot of explanation
* some people were proposed as committers to a subproject without them ever
contributing a line of code to that project but that was not clear from the
proposals
and so on and so forth. I'm not going to bother to compile an extensive list;
it should
be obvious to most that some things are going wrong.
I took a brief look at the [EMAIL PROTECTED] and [EMAIL PROTECTED] mailing list
archives to try
and figure out what is going on, but it seems there is a whole bunch of emails
about
all this stuff there that would take me most of the weekend to read. I'm not
going to
do that, I have more fun stuff to do with my free time! :-)
That's fine, eg there's no particular need for me to read all those emails and
understand precisely what is going on. I'm not a part of the geronimo PMC or its
community and I'm not actively helping with any of the gazillion stuff under
incubation under direction of the geronimo PMC.
But, and this is important, its becoming very hard to be able to perform even my
oversight duties as part of the Incubator PMC. I suspect the same is true for
more
than a few incubator PMC members.
IMHO, the primary responsibility for making my job as incubator PMC member a
little
easier lies with the geronimo PMC and the mentors for the geronimo subprojects
under
incubation. It saddens me I even have to write this email after spending a whole
lot of my hackathon weekend explaining all this stuff to a bunch of the people
I see
most active within Geronimo at the moment, and also discussing it at a stretch
with
the former and current geronimo PMC chair over the course of a few months.
I feel you are more often than not doing your job as PMC properly, you're not
listening to the many gentle pointers I've given over the years to try and help
change that, and all this is making my job as an Incubator PMC member a lot
harder,
more involved, and also a lot less fun. I feel its not just the energy that I've
invested that is totally being wasted, it is the energy of a whole bunch of
people.
Now, I realize the above is a bit abstract. So with all that in mind, a little
more
concretely, I have some suggestions. These are just my personal suggestions. In
terms
of carrots and sticks, there's only a very abstract carrot ("healthy
community") and
only a very big stick ("pulling the plug") that's not mine to wield, so I'm not
waving
any of them around; the only thing I'm trying to do is help make some sense out
of it
all.
Anyhow, I suggest that (the "you" in the below means the Geronimo PMC as a
collective):
* you guys work to update all the incubation status files and flesh them out
with
much more detail
* you guys write some meaningful summaries and reports of all the stuff that
went
on and is going on with regard to the stuff under incubation under the
banner of
the geronimo PMC (and I really don't care about internal disagreements within
geronimo as to what is going on, get consensus on what is going on first
please)
and send that info to [EMAIL PROTECTED]
* you guys leave about a week or so for the incubator PMC to read that and
catch
up on it all and ask questions
* in the meantime there's no talk about any kind of release of stuff under
incubation or anything like that and you practice some patience (its likely
you'll
get a -1 because the situation is currently not clear enough to be able to
perform
enough oversight)
(* you take a whole bunch of traffic off of [EMAIL PROTECTED] and ot into the
open (man.
I remember stating that repeatedly when it was still [EMAIL PROTECTED]
Sigh).)
* you don't propose any new stuff for incubation for a while so that everything
gets a chance to settle down and cool down and can proceed at a more healthy
pace
* when you do decide to bring in more stuff you take into consideration this
whole
concept of "oversight" more seriously and you ma
Re: Integrating Geronimo and Celtix
I 've already answered the same question two days ago. See http://marc.theaimsgroup.com/?l=geronimo-dev&m=113892077709751&w=2 So the gbeans and plan exist. They only need to be re-integrated in the geronimo build. ServiceMix has also a set of porlets that could be integrated in the geronimo console. Cheers, Guillaume Nodet Jacek Laskowski wrote: 2006/2/1, James Strachan <[EMAIL PROTECTED]>: Agreed. Apache ServiceMix is already integrated into Geronimo to provide these same ESB capabilities using the underlying Geronimo services like HTTP, JMS, JCA etc. Hi James, Whenever I see it said I keep asking myself how/where? Could you point me out to a module/gbeans of it. AFAIK, It *was* integrated one day, but it is no longer true, is it? I wish I were wrong, though. James -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Updated: (GERONIMO-1581) webservices.xml and values can't start with /
[ http://issues.apache.org/jira/browse/GERONIMO-1581?page=all ] Aaron Mulder updated GERONIMO-1581: --- Summary: webservices.xml and values can't start with / (was: webservices.xml value can't start with /) Description: It seems like it ought to be legal for the value to start with a / (in fact, the book I got my example from uses that). However, in Geronimo, that results in a java.lang.RuntimeException: Could not open stream to wsdl file. If we can't handle the preceding /, we should probably just strip it if it's there and then go on as normal (without the leading / everything is fine). The same appears to be true for the though it produces an NPE instead of the RuntimeException. was: It seems like it ought to be legal for the value to start with a / (in fact, the book I got my example from uses that). However, in Geronimo, that results in a java.lang.RuntimeException: Could not open stream to wsdl file. If we can't handle the preceding /, we should probably just strip it if it's there and then go on as normal. The same may be true for the though I'm currently getting a different error there. > webservices.xml and values can't start with > / > --- > > Key: GERONIMO-1581 > URL: http://issues.apache.org/jira/browse/GERONIMO-1581 > Project: Geronimo > Type: Bug > Components: OpenEJB, webservices > Versions: 1.0 > Reporter: Aaron Mulder > Fix For: 1.0.1, 1.1 > > It seems like it ought to be legal for the value to start with a > / (in fact, the book I got my example from uses that). However, in Geronimo, > that results in a java.lang.RuntimeException: Could not open stream to wsdl > file. If we can't handle the preceding /, we should probably just strip it > if it's there and then go on as normal (without the leading / everything is > fine). > The same appears to be true for the though it produces > an NPE instead of the RuntimeException. -- 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: Geronimo dependency issues
Here's an update on where I'm at with this and to see if anybody has any other ideas (thanks for the help I've already received from David Jencks and Matt). The classloader problem appears to be coming from the jetty deployment of daytrader during the configs build. By trial and error I discovered that this appears to have nothing to do with OpenEJB or OpenEJB-deployer as we once thought but rather jetty-deployer. Here's a graph of the jetty-deployer parent dependencies (I followed Matt's lead on creating text diagrams :-) ). geronimo-gbean-deployer j2ee-server A A | parent | |--| | j2ee-deployer jetty A A | parent | |--| | jetty-deployer Debug messages seem to indicate that the classloader in question is the geroniom-gbean-deployer class loader and I have had some marginal success (ie. changing the problem) by including dependencies in this config. However, I can't quite make sense of it. geronimo-gbean-deployer never had a dependency to rmi-naming to begin with. On the other hand, both the jetty config and the j2ee-server config do have a dependency to rmi-naming. So I would have thought that adding the tranql dependency here would improve things. But it had no effect at all. However, it changes the problem if I add the tranql dependency to geronimo-gbean-deployer. I then get this error: 26979 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.NoClassDefFoundError: javax/transaction/TransactionManager With Matt's help I found this class in the jta spec and added a dependency for that as well to geronimo-gbean-deployer which then resulted in this error: 14371 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.LinkageError: loader constraints violated when linking javax/transaction/UserTransaction class I'm not even sure exactly what a LinkageError is but I wonder if I'm just chasing my tail anyway. Having the dependency on tranql et. al. in geroniom-gbean-deployer might not be any better than having it in rmi-naming (still seems misplaced). Any hints/suggestions are welcome. BTW, out of about 22 questionable jars included in the minimal tomcat assembly I was able to remove 19 of them with the minimal assembly still functioning. Of course, I can only make these changes for that assembly if I can get around these side-effect problems in other configurations and assemblies. Joe Joe Bohn wrote: I'm looking to eliminate some of the unnecessary dependencies defined in our modules and configurations so that we can build smaller assemblies. While investigating what would be necessary to remove the tranql jar from the minimal assembly I removed a dependency to tranql in the rmi-naming configuration. I expected some problems, but the result I received is a bit strange. I get the NoClassDefFoundError listed below when deploying (as part of the build) the configuration for Daytrader. Is this expected based upon removing the tranql dependency from rmi-naming or is there something strange going on with the classloaders? + | configurations Daytrader using derby deployed on jetty | Memory: 52M/63M + DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo-daytrader-derby-db-1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but daytrader-ear-1.1-SNAPSHOT.ear may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for Daytrader using derby deployed on jetty Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. Retrieving document at 'META-INF/wsdl/TradeServices.wsdl'. Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. 143877 [main] ERROR org.apache.geronimo.deployment.Deployer - Deployment failed due to java.lang.NoClassDefFoundError: org/tranql/ejb/EJBProxyFactory at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at java.net.URLClassLoader.access$100(URLClassLoader.java:55) at java.net.URLClassLoader$1.run(URLClassLoader.java:194) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:187) at java.lang.ClassLoader.loadClass(C
[jira] Created: (GERONIMO-1582) NPE for EJB webservices.xml with bad
NPE for EJB webservices.xml with bad -- Key: GERONIMO-1582 URL: http://issues.apache.org/jira/browse/GERONIMO-1582 Project: Geronimo Type: Bug Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 If the points to an invalid location, a NullPointerException is produced. It should instead give a DeploymentException with a message like: webservices.xml for EJB JAR points to jaxrpc-mapping-file 'META-INF/foo.map' for service 'bar' but that file is not found. 11:47:01,051 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.deployment.util.NestedJarFile.getInputStream(NestedJarFile.java:187) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:95) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:88) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:315) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor() at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans() at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration() at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke() at net
[jira] Created: (GERONIMO-1581) webservices.xml value can't start with /
webservices.xml value can't start with / Key: GERONIMO-1581 URL: http://issues.apache.org/jira/browse/GERONIMO-1581 Project: Geronimo Type: Bug Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 It seems like it ought to be legal for the value to start with a / (in fact, the book I got my example from uses that). However, in Geronimo, that results in a java.lang.RuntimeException: Could not open stream to wsdl file. If we can't handle the preceding /, we should probably just strip it if it's there and then go on as normal. The same may be true for the though I'm currently getting a different error there. -- 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] Created: (GERONIMO-1580) Better error message for missing WSDL file for EJB web service
Better error message for missing WSDL file for EJB web service -- Key: GERONIMO-1580 URL: http://issues.apache.org/jira/browse/GERONIMO-1580 Project: Geronimo Type: Bug Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 If your webservices.xml file for a stateless session bean web service refers to a WSDL file that is not there, the error produced is java.lang.RuntimeException: Could not open stream to wsdl file It would be better if it produced a DeploymentException with a message something like: webservices.xml file for EJB JAR points to non-existant WSDL file 'META-INF/foo.wsdl' for service 'MyEJBWebService' The stack trace is 10:56:24,259 ERROR [Deployer] Deployment failed due to java.lang.RuntimeException: Could not open stream to wsdl file at org.apache.geronimo.axis.builder.SchemaInfoBuilder$JarWSDLLocator.getBaseInputSource(SchemaInfoBuilder.java:652) at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.readWsdl(SchemaInfoBuilder.java:555) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.(SchemaInfoBuilder.java:141) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.(SchemaInfoBuilder.java:125) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:312) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor() at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans() at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration() at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOp
configId issue... tooling impact
So due to the planned configId changes for 1.1, this will have a direct impact on the tooling. The primary issue here is that the 1.0 eclipse plugin is soon to be released only to be broken immediately by the release of 1.1. So rather then release a plugin that will not work with 1.1 here is my proposal... As soon as WTP 1.01 is released I had planned to go out with the 1.0.0 plugin. Instead I'll just tag it and make that binary available as a stable driver "zip only" (But won't put it on the update manager site which kinda puts a commitment that feature updates and patches on this will need to me made thereafter.) I'll then start versioning all my runtimes and servers to 1.1, wait for the configID changes, migrate the code and do a full release (update manager site included) as 1.1 which will allow you to define ONLY a 1.1 runtime and 1.1 server. In normal circumstances, every major release should be listed in the plugin (i.e create a 1.0 server, 1.1, server, 2.x, ...), however given the impact on the incompatibilities introduced, and specifically the possibility of not having any upward schema conversion magic, I think this is much more safer bet to just go ahead and replace 1.0 support with 1.1, rather then add 1.1 support as you would do normally. In the future, we need to be "tooling-aware" and for any major change going in like this to start considering the impact on tooling. For some stuff I may be impacted but not aware of it, so I'm asking each and everyone to be more conscious about this going forward. Thanks - sachin
[jira] Created: (GERONIMO-1579) NPE while deploying EJB as Web Service
NPE while deploying EJB as Web Service -- Key: GERONIMO-1579 URL: http://issues.apache.org/jira/browse/GERONIMO-1579 Project: Geronimo Type: Bug Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 Surely caused by a coding/configuration error, but it would really be preferable to produce a better error message. 10:23:37,328 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.openejb.deployment.SessionBuilder.addWSContainerGBean(SessionBuilder.java:208) at org.openejb.deployment.SessionBuilder.buildBeans(SessionBuilder.java:187) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:527) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans() at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration() at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117) at mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219) at sun.reflect.GeneratedMethodAccessor265.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSubjectInvoker.java:31) at mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjectInvoker.java:90) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:500) at mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:163) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
On 3 Feb 2006, at 16:47, Justin Erenkrantz wrote: On 2/3/06, James Strachan <[EMAIL PROTECTED]> wrote: community inside a single project with one overall aim (Geronimo for J2EE, ServiceMix for JBI, Jakarta Commons / WS Commons for utility code etc) than to have lots of smaller projects. Is ServiceMix intended to be a TLP, or will it continue to be a sub-project of Geronimo? This email leads me to believe that ServiceMix might not have a strong overlap with J2EE - which is Geronimo's mission. Hence, might a new TLP be best? -- justin Given the synergy with other Geronimo code in ServiceMix (it reuses Geronimo kernel, transaction manager, JCA container, ActiveMQ etc) and the large developer cross over in both projects, I'm personally happy for ServiceMix to be a sub project of Geronimo. The next milestone for ServiceMix is graduation from the incubator which is our main aim currently as we want to be able to make a real release so folks can use the code. I'm personally very happy with the governance of the Geronimo PMC but I wouldn't object if in the future the community decided that ServiceMix should be a TLP. James --- http://radio.weblogs.com/0112098/
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
On 4 Feb 2006, at 01:38, Sanjiva Weerawarana wrote: I'm going to remove my original -1 from this thread and vote +1 for it. My apologies for helping to create this major ruckus. This type of heated discussion does not help build communities and cross community interactions that would benefit all of us in many ways. That is especially so because this has partly become ServiceMix vs. WS .. which is terrible because that's not what the discussions should be about at all. In any case, the WS project is BIG at the moment and I'd personally -1 any proposal to add 20+ more committers to our already overloaded committer list. So, if the ServiceMix folks feel that a BPEL engine needs to be near to their heart, then I'm all for it. I realize that my knowledge of JBI isn't enough to have a strong position on the technical rationale for it but am happy to defer to folks likes James, Dan, Aron and others that obviously do. I'm not on the Geronimo PMC and so have no part of this vote formally. When this finds its way into a vote on the Incubator PMC (which I'm on) I will read the proposal and vote on it; assuming it meets the criteria of not being code thrown over the wall, etc. etc. I'll be +1. Good luck folks .. I'll keep an eye on it and look to participate where possible and appropriate. Thanks for your kind words Sanjiva. This has been an interesting debate, I think we've all learnt from it and are all agreeing far more than not. The way I see it right now we all agree that * we all want to see more cross community collaboration in this space (Geronimo, ServiceMix, Synapse, Tuscany, WS et al;). * we all want the code & Sybase to work with us * we want the BPEL code to be as reusable as possible in any Apache project (*) * at some point in the future, if there is a large and vibrant community behind it who wants it to be so, there should be a separate BPEL project The only area of disagreement seems to be how we start; Sybase & the ServiceMix community want to work on the code inside the existing ServiceMix project as there is great synergy of people, technology and scope - plus we are already in the incubator. The ServiceMix community are very open to contributions from anyone and we hope to grow the community further - our arms are wide open to contributions and we'd welcome any involvement from WS or Tuscany or any other part of Apache. (*) the BPEL engine will always be reusable by anyone inside or outside Apache with minimum dependencies. If folks wanna use it without JBI at all that's fine too; though the benefit is if you integrate with JBI once you have one integration point that will always work with the BPEL engine - together with any other BPEL engine and any other integration component for that matter too... http://incubator.apache.org/servicemix/Components i.e. you'd save yourself heaps of time by just integrating with the JBI API rather than the implementation-details APIs of this specific BPEL engine. Be that as it may - anyone at Apache (or elsewhere) can reuse any part of the code they like. James --- http://radio.weblogs.com/0112098/
Re: Integrating Geronimo and Celtix
2006/2/1, James Strachan <[EMAIL PROTECTED]>: > Agreed. Apache ServiceMix is already integrated into Geronimo to > provide these same ESB capabilities using the underlying Geronimo > services like HTTP, JMS, JCA etc. Hi James, Whenever I see it said I keep asking myself how/where? Could you point me out to a module/gbeans of it. AFAIK, It *was* integrated one day, but it is no longer true, is it? I wish I were wrong, though. > James -- Jacek Laskowski http://www.laskowski.org.pl
Re: Proposed solution for the configId dilemma
I've added a very rough first draft of a new/modified schema following the design on the wiki. Many of the element names are not very satisfactory and I would appreciate suggestions. There are probably other errors as well :-) branches/configid/modules/service-builder/src/schema/geronimo- config-1.1.xsd thanks david jencks On Feb 3, 2006, at 5:38 PM, David Jencks wrote: I talked with Dain some more and we laid out some steps to follow, I put them on the confluence wiki: http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/ configId If people would like me to summarize changes and progress on the dev list as well I will attempt to do that. I hope to have a proposal for schema changes in the next day or so. Please get ready to review and criticize it :-) thanks david jencks On Feb 2, 2006, at 6:42 PM, David Jencks wrote: After a long discussion on IRC we may have a proposal for the configId dilemma. People: Dain and I will work to implement this Timeframe: for the next week, then we will see where we are svn tags: we'll make a branch off 1.0. If we succeed, the merge of our work and 1.0 will become 1.1 and we will not release 1.0.1. Then we'll merge into trunk. Goal: make version Id optional almost everywhere: certainly in any normal user plan. xml changes: eliminate configId and parentId attributes: there is already the element to replace parentId, and introduce a new configId element to replace the configid attribute. This will have the same structure as dependencies, imports, etc. For all these tags except configId version will be optional. Introduce a new element (name up for grabs :-) that creates a dependency on the named configuration but does not add it to the set of classloader parents. This would have the dependency type with optional version. eliminate direct specification of gbean names in gbeans and in gbean reference patterns. Replace specification of e.g. groupId/artifactId/version/car with foo bar 1.0 where any of these is optional. There may be changes in the meaning of gbean name specifications, see the resolution process described later. problems with this: - configId can appear in module or application. We think that the configId resolution process described later will be able to resolve the meaning - there are a few gbeans that don't have as many object name keys, such as the jsr-77 beans for the server and jvm. I don't know how to deal with these yet. GBean name changes: Change the configuration gbean names to have separate groupId, artifactId, and version keys. We might need to separate out a version in every gbean name but think this is unlikely. File system changes: adopt a maven2 repository structure for the geronimo repo. algorithm changes: 1. resolving parents (imports) and config-dependencies. These both involve finding a configuration given only partial information. The config-store is going to need to be queriable to some extent and we will need some kind of resolution strategy in case there is more than one match. Starting from a plan, resolving the parents and config- dependencies recursively results (when combined) with a directed acyclic graph of configurations (configDAG). 2. resolving gbean references. This part is still open to considerable modification, but some parts are clear. We start with a partially specified object name: typically we will have a name key, a j2eeType key, and a partial specification of the configId. We start by resolving the configId by a depth first search of the configDAG until we find a match. Depending on whether the target configuration is for an ear or anything else, we can determine if the configId is the J2EEApplication or J2EEModule key for the name. We can then look for names matching the rest of the specification. Discussion of algorithm changes: Currently there are 2 kinds of name resolution: "link" resolution that typically starts in the current module and then if not matched looks in any module with J2EEApplication="null", and exact specification where you specify several name components and the rest are the same as the gbean with the reference. There is also specifying an entire name explicitly (possibly with wildcards). We plan to eliminate the whole-name option. We think that we can replace both the other resolution methods with the method just outlined, where the search path for resolution is not the whole server but the configDAG. For me, this requires more study to be completely confident that it will work but I am very hopeful. An unusual situation that requires a reference out of the configDAG: It is possible for a config A to have a gbean X and a config B to have a gbean Y where both X and Y reference the other gbean, so long as at least one of the references is multi-valued. In order to allow for this, it has to be possible
