Transaction Manager and Connection Manager usage outside Geronimo
Hi all, my name is Jacopo Cappellato, I'm one of the developers of the OFBiz project (www.ofbiz.org), that will soon start the incubation process. We are evaluating the possibility to integrate into OFBiz two of the Geronimo's components: the Transaction Manager and the TX-aware Connection Pooling (right now we are using JOTM and Minerva). Can these components be used separately from the whole Geronimo thing? Any hints on dependencies (etc.) we should take care will be highly appreciated. Thanks, Jacopo
Re: Transaction Manager and Connection Manager usage outside Geronimo
Jacopo forwarded this message to me and I thought it would probably be easiest if I just joined in here... My name is David Jones and I'm one of the OFBiz developers and have worked quite a bit on this part of the project. Hi all, my name is Jacopo Cappellato, I'm one of the developers of the OFBiz project (www.ofbiz.org), that will soon start the incubation process. We are evaluating the possibility to integrate into OFBiz two of the Geronimo's components: the Transaction Manager and the TX- aware Connection Pooling (right now we are using JOTM and Minerva). Can these components be used separately from the whole Geronimo thing? Any hints on dependencies (etc.) we should take care will be highly appreciated. You are not the first to want to do this :-). The purpose of the Jencks project is to run these components in Spring. It should also be pretty easy to set up the components you need in code. Does OFBiz use a component framework? Does it run in a web server? If run in a j2ee app server, what happens to its own tm and connection pooling? We have various ways of doing this, and it is configurable through the database setup XML file. The Entity Engine is the part of OFBiz that handles all of this, so if it means anything to anyone this is setup in the entityengine.xml file. Our preference is to just have the JTA interface (UserTransaction and TransactionManager) implementations in JNDI and use them from there. We prefer the same for the connection pool (data source), ie to have the XADataSource object available in JNDI. As an alternative to these we support (and have done this various times in the past) just writing code that uses the objects directly to get what we need. For the TX manager side we have done custom code for both JOTM and Tyrex (a _long_ time ago). Right now we are putting the JOTM JTA interface impls in JNDI on startup and then using them from there. The issue with JOTM comes up because we are using Carol for the underlying stuff and that is LGPL licensed... When running in an app server we just refer to the JNDI locations that the app server uses. Our default running mode, however, is to run with embedded J2EE components, including the Servlet container (embedded Tomcat is the default, we also support Jetty embedded), transaction manager, and so on. The nice thing about doing it this way is that we have a container feature to load things on startup, and a component feature that allows us to drop in component directories that have an OFBiz- specific description to load various general (classpath, webapps) and OFBiz-specific (entity, service, etc) resources to make it easy to drop in applications and such and have then deployed. For deploying OFBiz in an external (as opposed to embedded) app server we have a tool to turn templates into config files with the classpath and webapp settings from all of the OFBiz component descriptors. This is an extra step for deployment, but helps a lot when you have hundreds of classpath entries, and over a dozen webapps. The last time I looked the Jencks project was not setting up the transaction log so recovery of in-doubt transactions would not be possible. I don't know why it wasn't set up, it is pretty easy to do. It's desirable for all calls into a web app or ejb to go through an interceptor connected to the connection management framework. This is needed to support some required but bad-practice j2ee requirements, but also has the very good effect of preventing connection leaks if you use appropriate j2ca jdbc wrappers such as the tranql connectors. If you run in Geronimo these interceptors are installed for you, but it is also possible to install them in standalone jetty and (I think) tomcat and IIUC the Jencks project has installed them in Spring. Is there any sort of demo code you could recommend to see how to either initialize the JTA and JDBC DataSource objects to put into JNDI, or alternatively how to initialize and use the objects from TX operations and JDBC Connection factory types of things? I guess the Jencks project you mentioned is a good place to look, but it sounds like with a couple of exceptions where it could be improved... I am extremely geronimo-centric :-) but I will push one of our capabilities anyway, feel free to ignore it. If you are interested in running OFBiz in geronimo, you can predeploy it into a geronimo component, and then build a server that includes a web server, the tm, connection management, and OFBiz and pretty much nothing else, and produce an unzip and run server. This has always been one of our goals and we are ironing out some details of the pretty much nothing else part right now. Deployment is an interesting issue with OFBiz... We have a few requirements that are difficult with some app servers. Well, we prefer to deploy using embedded
Re: Confluence status
[i'm not on [EMAIL PROTECTED], so the moderator there will have to push this thru] David Blevins [EMAIL PROTECTED] writes: 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 IIRC the technical requirements come from experience with the existing moin-moin wiki, so that's probably the context best suited for Noel's remarks. 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 My concern is that people will be far less creative in how they manage their content if there's an asf-endorsed wiki they can just point users at. IOW, are people doing similarly creative things with the moin-moin wiki, or do they normally just refer folks directly to the content on the apache wiki? I think we are in good shape sans the fact that we should have our own confluence install. We'd be in better shape if we could just get confluence to perform as well as moin-moin, so policing people's usage would be less of a concern. When it comes to options, the issue of failure recovery is important. What happens if the box dies; does the content die with it? What will happen to the projects dependent on an asf confluence if the technical support for it (which is a perpetual committment) diminishes over time? -- Joe Schaefer
[jira] Created: (GERONIMO-1585) Web app security on /* causes deployment exception
Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: http://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Type: Bug Components: web Versions: 1.0 Environment: Geronimo 1.0 with Jetty Reporter: Aaron Mulder Priority: Critical Fix For: 1.0.1, 1.1 Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- 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] Reopened: (GERONIMODEVTOOLS-40) Cannot start server programmatically
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-40?page=all ] Sachin Patel reopened GERONIMODEVTOOLS-40: -- Cannot start server programmatically Key: GERONIMODEVTOOLS-40 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-40 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Environment: Windows XP Reporter: Kathy Chan Assignee: Sachin Patel Priority: Critical I was using the following drivers on Windows XP: - WTP 1.0 - Geronimo 1.0 server - Geronimo 20060109 plugin With a new workspace, do the following: - install Geronimo 1.0 server runtime - create Geronimo server using server tooling - start server - create Web project a1 with EAR - In the Web project, create a simple Echo.java with a hello method that takes a String and returns it. Here are the procedure to create a bottom-up Web service: - right-click on Echo.java, select Web Services - Create Web service - select test Web service and overwrite file on the 1st page of Web service wizard - click Finish - when the Web Services Explorer comes up, you should be able to invoke the hello method Now, if you remove the Web project a1 from the server and ensure that the server is still in started state, then you can repeat the above steps to create a bottom-up Web service. However, if you do not remove the Web project from the server first, then you'll run into the problem reported in bug http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-39. If you remove the Web project from the server first but stop the server before creating the bottom-up Web service, when the Web service wizard tried to start the server programmatically, you'll notice that the server console indicates that Geronimo startup complete but server tooling still thinks that the server is started. The server start will eventually times out. Now, even if I use server tooling to start the server, server start would not complete. This problem persist even if I delete the server and recreate another one. The only way I could recover is to use a new workspace. -- 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: [jira] Created: (GERONIMO-1585) Web app security on /* causes deployment exception
Hmmm... , debug tool (G-1448) required a similar modification. Is it time to recite the specs...? Thanks Anita --- Aaron Mulder (JIRA) dev@geronimo.apache.org wrote: Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: http://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Type: Bug Components: web Versions: 1.0 Environment: Geronimo 1.0 with Jetty Reporter: Aaron Mulder Priority: Critical Fix For: 1.0.1, 1.1 Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (GERONIMO-1586) In naming schema, make uri optional in portType
In naming schema, make uri optional in portType --- Key: GERONIMO-1586 URL: http://issues.apache.org/jira/browse/GERONIMO-1586 Project: Geronimo Type: Improvement Components: naming, webservices Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 Currently the portType requires uri. If you only want to add security settings to the web service, and are happy to default to the URI in the WSDL, you should not need to repeat the URI here. So technically, you should need either the uri or credentials-name or both, but I think it's easier to model in the schema as making them both optional, and if you add a port with nothing but a name, well then, nothing will change from the original J2EE DD service-ref and WSDL. -- 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: spec jar versioning [Re: svn commit: r374834 ]
GERONIMO-1587 Document versioning process Regards, Alan On 2/4/2006 2:08 PM, Dain Sundstrom wrote: 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=374834view=rev Log: Versions of individual jars should reflect their contents.
[jira] Created: (GERONIMO-1587) Document versioning process
Document versioning process --- Key: GERONIMO-1587 URL: http://issues.apache.org/jira/browse/GERONIMO-1587 Project: Geronimo Type: Task Components: specs Reporter: Alan Cabrera Assigned to: Alan Cabrera Document versioning process. Start w/ Specs -- 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: [VOTE] accept donation of a business process engine into the ServiceMix project
James Strachan wrote: We have received the generous donation of a complete and working BPE engine to the ServiceMix project... http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/[EMAIL PROTECTED] the contributor has offered to donate to Apache complete the necessary software grants IP clearance and to work with us on integrating it into ServiceMix. I assume we'd all get to see the code under an Apache License before deciding to accept. How else could we vote it in? [SNIP] I'll go out on a limb here : [X] -1 I object because: ... ... I think that a BPEL engine is something that spans many of the WS and SOA oriented projects at the ASF, such as ServiceMix, Tuscany, Synapse, Agila, etc... However, that's not my main reason, because honestly, if I was the only one that cared about that, I wouldn't ever attempt to stand in the way of people wanting to do cool things. However, this proposal has sent up far too many red flags, has alienated too many people, and is causing too much of a bad feeling in people, for ServiceMix, for Geronimo and for the ASF in general. I'd suggest you make a big effort to cool things down and get a broad conversation going, over at [EMAIL PROTECTED], drive to consensus, and then regroup and try again. geir
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
The way this 'debate' has continued has been very embarrassing - It just makes me wonder why anyone would consider donating code to Apache in the future ... On 5 Feb 2006, at 21:03, Geir Magnusson Jr wrote: James Strachan wrote: We have received the generous donation of a complete and working BPE engine to the ServiceMix project... http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/ 200602.mbox/% [EMAIL PROTECTED] the contributor has offered to donate to Apache complete the necessary software grants IP clearance and to work with us on integrating it into ServiceMix. I assume we'd all get to see the code under an Apache License before deciding to accept. How else could we vote it in? [SNIP] I'll go out on a limb here : [X] -1 I object because: ... ... I think that a BPEL engine is something that spans many of the WS and SOA oriented projects at the ASF, such as ServiceMix, Tuscany, Synapse, Agila, etc... However, that's not my main reason, because honestly, if I was the only one that cared about that, I wouldn't ever attempt to stand in the way of people wanting to do cool things. However, this proposal has sent up far too many red flags, has alienated too many people, and is causing too much of a bad feeling in people, for ServiceMix, for Geronimo and for the ASF in general. I'd suggest you make a big effort to cool things down and get a broad conversation going, over at [EMAIL PROTECTED], drive to consensus, and then regroup and try again. geir
Re: [jira] Created: (GERONIMO-1585) Web app security on /* causes deployment exception
This appears to be related to the issue raised around M4 with Jetty. I hadn't tried tomcat at the time. http://issues.apache.org/jira/browse/GERONIMO-603 John anita kulshreshtha wrote: Hmmm... , debug tool (G-1448) required a similar modification. Is it time to recite the specs...? Thanks Anita --- Aaron Mulder (JIRA) dev@geronimo.apache.org wrote: Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: http://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Type: Bug Components: web Versions: 1.0 Environment: Geronimo 1.0 with Jetty Reporter: Aaron Mulder Priority: Critical Fix For: 1.0.1, 1.1 Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Roadmap, tasks and things to do?
Way to go!!! Great job Anita. Thanks for putting the roadmap together. Cheers! Hernan anita kulshreshtha wrote: 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-N61ED\!G;6%I;\YC;VT* );' 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: [VOTE] accept donation of a business process engine into the ServiceMix project
On Feb 5, 2006, at 1:29 PM, Rob Davies wrote: The way this 'debate' has continued has been very embarrassing - It just makes me wonder why anyone would consider donating code to Apache in the future ... Because we care enough to have the debate. If anyone wants silence, they are free to go to sourceforge. Silence is death. Roy
Re: Confluence status
On Sun, Feb 05, 2006 at 04:50:13AM -0500, Joe Schaefer wrote: ... IIRC the technical requirements come from experience with the existing moin-moin wiki, so that's probably the context best suited for Noel's remarks. Yes, and I think it's a fair approach to take. Here's how I see things going forward.. 1) Towards Confluence as a direct MoinMoin alternative Infrastructure@ want some decent benchmarks demonstrating that Confluence can survive sustained heavy load (ala MoinMoin) and/or spikes (slashdot). Noel rightly says caching is essential. Briefly experimenting with 'ab -c 100 -n 1000' suggests that Confluence's internal caching may be enough. I'll ask the Confluence team if they can produce some benchmarks. 2) Confluence as doc staging/development environment There are various ways to suck content from Confluence to a live site: - Maven has Doxia in development. - Codehaus have a Perl script (Confluenza) which sucks down content via XML-RPC to build their website. - Pier is working on a Confluence plugin that saves static HTML. - Anyone can rig up a script using Confluence's XML-RPC/SOAP API. Confluence does not have to be running on ASF hardware for its use as a doc staging environment. Some projects might use the Codehaus Confluence, some use http://opensource2.atlassian.com/confluence/oss/. It would be nice if the ASF had an internal Confluence installation for doc staging, and that's what I proposed Atlassian would sponsor a box (partly) for. --Jeff -- Joe Schaefer
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Roy - I agree - it's one of Apache's strengths. My disappointment is that not all the the comments have been helpful or constructive. BTW - I in no way mean Geir's comments - I just got a bit lazy and hit the replyTo on his email :) On 5 Feb 2006, at 22:03, Roy T. Fielding wrote: On Feb 5, 2006, at 1:29 PM, Rob Davies wrote: The way this 'debate' has continued has been very embarrassing - It just makes me wonder why anyone would consider donating code to Apache in the future ... Because we care enough to have the debate. If anyone wants silence, they are free to go to sourceforge. Silence is death. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (GERONIMO-1462) Finish implementing inverseClassloading attribute in plan schemas
[ http://issues.apache.org/jira/browse/GERONIMO-1462?page=all ] David Jencks reassigned GERONIMO-1462: -- Assign To: David Jencks Finish implementing inverseClassloading attribute in plan schemas - Key: GERONIMO-1462 URL: http://issues.apache.org/jira/browse/GERONIMO-1462 Project: Geronimo Type: Bug Versions: 1.0 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 1.x, 1.1 The inverseClassloading attribute is declared in geronimo-config-1.0.xsd. It appears to be used in: - geronimo-application-1.0 - geronimo-connector-1.0 - geronimo-jetty-1.0 - openejb-jar-2.0 It should be added to: - geronimo-web-1.0 - geronimo-tomcat-1.0 - geronimo-application-client-1.0 (not totally sure about this one) However, we need to decide whether to rev the version numbers of those schemas when we make the change. I would be inclined to not change the namespace or version in the file name, but to add an internal version history in the header comment of the schemas. Mainly because that's how Sun does it with the J2EE schemas, and I think it would be a huge pain to try to get people to update their namespaces every time we have a tiny change. -- 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
I could not reproduce this problem. I tried moving openejb, tranql, and activemq dependencies to more appropriate places and after some fiddling it seems to work, so I committed my changes (geronimo r375137, openejb r2428 ). In the future including diffs of your changes might help figure out exactly where you are stuck. thanks david jencks On Feb 4, 2006, at 7:34 PM, Joe Bohn wrote: 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
[jira] Created: (GERONIMO-1588) ActiveMQ directory as peer to geronimo-1.0 directory
ActiveMQ directory as peer to geronimo-1.0 directory Key: GERONIMO-1588 URL: http://issues.apache.org/jira/browse/GERONIMO-1588 Project: Geronimo Type: Improvement Components: ActiveMQ Versions: 1.0 Reporter: Jason Dillon Priority: Minor An ActiveMQ directory gets created as a peer to the top-level geronimo-1.0 directory. Looks like this directory contains message state, and I'd expect to see it under geronimo-1.0/var/activemq. -- 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
tranql needed for full build?
Are the tranql sources needed for a full build? I noticed that new0 and new00 are both for tranql/* but m:checkout has the tranql co commented out. --jason
Re: tranql needed for full build?
tranql and tranql-connector don't change all that often but if you have them checked out you can build them as part of the project. Similarly if you don't check out openejb you can use downloaded jars. Anytime you do this your risk of mismatched jars increases. So, it depends what you mean by full build thanks david jencks On Feb 5, 2006, at 4:11 PM, Jason Dillon wrote: Are the tranql sources needed for a full build? I noticed that new0 and new00 are both for tranql/* but m:checkout has the tranql co commented out. --jason
Re: tranql needed for full build?
We haven't considered TranQL source necessary for quite a while. The only source that should be regularly checked out is OpenEJB, and we're considering moving away even from that. Thanks, Aaron On 2/5/06, Jason Dillon [EMAIL PROTECTED] wrote: By full build I mean, the build that should just always work... latest stable development... if we had to release it, the same build that would be used for that. On a related note, why don't we use vendor branches for sources that are external to our SVN, but are critical for the build? --jason On Feb 5, 2006, at 5:01 PM, David Jencks wrote: tranql and tranql-connector don't change all that often but if you have them checked out you can build them as part of the project. Similarly if you don't check out openejb you can use downloaded jars. Anytime you do this your risk of mismatched jars increases. So, it depends what you mean by full build thanks david jencks On Feb 5, 2006, at 4:11 PM, Jason Dillon wrote: Are the tranql sources needed for a full build? I noticed that new0 and new00 are both for tranql/* but m:checkout has the tranql co commented out. --jason
[jira] Created: (GERONIMO-1589) Deploy CORBA EJB with TSS; config with CORBA Server is not started but no error message
Deploy CORBA EJB with TSS; config with CORBA Server is not started but no error message --- Key: GERONIMO-1589 URL: http://issues.apache.org/jira/browse/GERONIMO-1589 Project: Geronimo Type: Bug Components: OpenEJB, CORBA, kernel Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1 The j2ee-corba configuration defines the CORBA Server. I added a TSS to an EJB JAR, and the TSS has a reference to the Server running in the j2ee-corba configuration. The deployment completed successfully, yet the j2ee-corba configuration was still not running. What happened here? From the log, it looks like the TSSBean failed to start waiting on the Server, and the SessionBean failed to start waiting on the TSSBean. This should have resulted in some kind of message during dpeloyment, if not outright failing the deployment. Or better yet, it should have just started the j2ee-corba configuration. This would be cured by setting j2ee-corba as a parent or import for the EJB JAR, but I forgot, and it still should have produced a warning or error message as is! -- 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] Commented: (GERONIMO-1589) Deploy CORBA EJB with TSS; config with CORBA Server is not started but no error message
[ http://issues.apache.org/jira/browse/GERONIMO-1589?page=comments#action_12365239 ] Aaron Mulder commented on GERONIMO-1589: To add insult to injury, errors are produced when the application is shut down: GBeanInstance should already be stopped before die() is called:... I got about 8 of these indicating that various servlets and things failed to start (presumably on account of the session bean not starting), so the application was in fact totally crippled. Deploy CORBA EJB with TSS; config with CORBA Server is not started but no error message --- Key: GERONIMO-1589 URL: http://issues.apache.org/jira/browse/GERONIMO-1589 Project: Geronimo Type: Bug Components: OpenEJB, CORBA, kernel Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1 The j2ee-corba configuration defines the CORBA Server. I added a TSS to an EJB JAR, and the TSS has a reference to the Server running in the j2ee-corba configuration. The deployment completed successfully, yet the j2ee-corba configuration was still not running. What happened here? From the log, it looks like the TSSBean failed to start waiting on the Server, and the SessionBean failed to start waiting on the TSSBean. This should have resulted in some kind of message during dpeloyment, if not outright failing the deployment. Or better yet, it should have just started the j2ee-corba configuration. This would be cured by setting j2ee-corba as a parent or import for the EJB JAR, but I forgot, and it still should have produced a warning or error message as is! -- 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: Oracle XA RAR for G1.0?
Any clue on the required config to get the rar deployed? I'm trying to convert this URL to the params for the RAR: jdbc:oracle:thin:@mydbhost:1621:devdb Unfortunately the Oracle XA RAR does not take a URL, but wants granular configuration. Some obvious stuff I get (like the port number), but what to use for protocol and type, etc have me scratching my head. I also looked for the Javadocs for oracle.jdbc.xa.client.OracleXADataSource with no luck to see what properties it exposed. The only docs I can find are to expose the XAResource, but there must be more since the TranQL RAR is calling some of them. Any ideas? --jason On Feb 3, 2006, at 5:44 AM, Matt Hogstrom wrote: I think David means that it has not been extensively tested and so there are no gurantees that you'll simply be able to drop it in. I'm currently working on a DB2 XA RAR and am still working out some kinks. It should work well, we're just not sure its been testd enough to know that it does. I looked on CodeHaus and it appears that Jeremy had not previous released a SNAPSHOT. I compiled the connector this morning against the Oracle 10.1.4.0 classes12.jar. I've published it and it is called tranql/rars/tranql-connector- oracle-xa-1.0-SNAPSHOT.rar If someone can try this out then that would be excellent. I have only compiled it and not tested it so caveat emptor. lichtner wrote: On Fri, 3 Feb 2006, David Jencks wrote: It is likely to work if you build it. However I don't know that it has been used in the last year or more, so I won't make any promises. Matt might have tried it, I don't know. We have been a bit reluctant to publish it without more evidence that it works well. Why would it not work well? When I was in my last job I remember getting that rar to work with mysql xa, so it probably also works with Oracle xa.
[jira] Created: (GERONIMO-1590) CORBA for EJB with Local interface only causes NPE
CORBA for EJB with Local interface only causes NPE -- Key: GERONIMO-1590 URL: http://issues.apache.org/jira/browse/GERONIMO-1590 Project: Geronimo Type: Bug Components: CORBA, OpenEJB Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 I have an EJB with a local interface and I tried applying CORBA settings. It blows up during deployment. My guess is that it wants a remote interface to be there, but somehow, the checks in StandardServant:126 are not working and the interface just comes up as null. Caused by: java.lang.NullPointerException at org.openejb.corba.util.Util.getAllInterfaces(Util.java:593) at org.openejb.corba.util.Util.getAllMethods(Util.java:815) at org.openejb.corba.util.Util.iiopMap(Util.java:608) at org.openejb.corba.util.Util.mapOperationToMethod(Util.java:604) at org.openejb.corba.StandardServant.init(StandardServant.java:135) at org.openejb.corba.StandardServant.init(StandardServant.java:116) at org.openejb.corba.Adapter.init(Adapter.java:100) ... 67 more -- 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] Commented: (GERONIMO-1590) CORBA for EJB with Local interface only causes NPE
[
http://issues.apache.org/jira/browse/GERONIMO-1590?page=comments#action_12365240
]
Aaron Mulder commented on GERONIMO-1590:
Proposed fix (no diff b/c I don't have the SVN checkout yet and CVS seems to be
history)...
Add this to SessionBuilder:328
if(tssBeanObjectName != null (!sessionBean.isSetRemote() ||
!sessionBean.isSetHome())) {
throw new DeploymentException(A session bean without a remote
interface cannot be exposed via CORBA);
}
And add to EntityBuilder:139
if(tssBeanObjectName != null (!entityBean.isSetRemote() ||
!entityBean.isSetHome())) {
throw new DeploymentException(An entity bean without a remote
interface cannot be exposed via CORBA);
}
And change CMPEntityBuilder:188 to:
ObjectName tssBean = getTssBeanObjectName(openejbEntityBean,
earContext);
if(tssBean != null (!entityBean.isSetRemote() ||
!entityBean.isSetHome())) {
throw new DeploymentException(An entity bean without a remote
interface cannot be exposed via CORBA);
}
GBeanData gbean = builder.createConfiguration(containerObjectName,
earContext.getTransactionContextManagerObjectName(),
earContext.getConnectionTrackerObjectName(), tssBean);
CORBA for EJB with Local interface only causes NPE
--
Key: GERONIMO-1590
URL: http://issues.apache.org/jira/browse/GERONIMO-1590
Project: Geronimo
Type: Bug
Components: CORBA, OpenEJB
Versions: 1.0
Reporter: Aaron Mulder
Fix For: 1.0.1, 1.1
I have an EJB with a local interface and I tried applying CORBA settings. It
blows up during deployment. My guess is that it wants a remote interface to
be there, but somehow, the checks in StandardServant:126 are not working and
the interface just comes up as null.
Caused by: java.lang.NullPointerException
at org.openejb.corba.util.Util.getAllInterfaces(Util.java:593)
at org.openejb.corba.util.Util.getAllMethods(Util.java:815)
at org.openejb.corba.util.Util.iiopMap(Util.java:608)
at org.openejb.corba.util.Util.mapOperationToMethod(Util.java:604)
at org.openejb.corba.StandardServant.init(StandardServant.java:135)
at org.openejb.corba.StandardServant.init(StandardServant.java:116)
at org.openejb.corba.Adapter.init(Adapter.java:100)
... 67 more
--
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-1591) Redeploy CORBA EJB JAR w/TSS; Blows up and server must be restarted
Redeploy CORBA EJB JAR w/TSS; Blows up and server must be restarted --- Key: GERONIMO-1591 URL: http://issues.apache.org/jira/browse/GERONIMO-1591 Project: Geronimo Type: Bug Components: CORBA, OpenEJB Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.0.1, 1.1 When you configure a session bean with CORBA (including a TSS GBean in the EJB plan) and deploy it the first time, it works, If you make no changes and redeploy it, it dies with the following error. The only way to get it to deploy successfully is to restart the server. It appears that the POA named for my TSS is not removed when the EJB is undeployed, so the second attempt to deploy it fails. 00:38:05,177 WARN [TSSBean] Failed CORBA Target Security Service in POA TSS-SSL 00:38:05,179 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=CORBATest,J2EEModule=ejb-1.0-SNAPSHOT.jar,J2EEServer=geronimo,j2eeType=CORBATSS,name=TSS-SSL org.omg.PortableServer.POAPackage.AdapterAlreadyExists: IDL:omg.org/PortableServer/POA/AdapterAlreadyExists:1.0 at com.sun.corba.se.internal.POA.POAImpl.adapterAlreadyExists(POAImpl.java:1263) at com.sun.corba.se.internal.POA.POAImpl.create_POA(POAImpl.java:211) at com.sun.corba.se.internal.POA.POAImpl.create_POA(POAImpl.java:522) at org.openejb.corba.TSSBean.doStart(TSSBean.java:147) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) at org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) at org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke(generated) 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.basic.BasicKernel.invoke(BasicKernel.java:173) at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142) at org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke(generated) 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(generated) 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.GeneratedMethodAccessor107.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
Re: Oracle XA RAR for G1.0?
I think the properties were ConnectionURL, UserName and Password, but don't spend a lot of time on these because I could be wrong .. On Sun, 5 Feb 2006, Jason Dillon wrote: Any clue on the required config to get the rar deployed? I'm trying to convert this URL to the params for the RAR: jdbc:oracle:thin:@mydbhost:1621:devdb Unfortunately the Oracle XA RAR does not take a URL, but wants granular configuration. Some obvious stuff I get (like the port number), but what to use for protocol and type, etc have me scratching my head. I also looked for the Javadocs for oracle.jdbc.xa.client.OracleXADataSource with no luck to see what properties it exposed. The only docs I can find are to expose the XAResource, but there must be more since the TranQL RAR is calling some of them. Any ideas? --jason On Feb 3, 2006, at 5:44 AM, Matt Hogstrom wrote: I think David means that it has not been extensively tested and so there are no gurantees that you'll simply be able to drop it in. I'm currently working on a DB2 XA RAR and am still working out some kinks. It should work well, we're just not sure its been testd enough to know that it does. I looked on CodeHaus and it appears that Jeremy had not previous released a SNAPSHOT. I compiled the connector this morning against the Oracle 10.1.4.0 classes12.jar. I've published it and it is called tranql/rars/tranql-connector- oracle-xa-1.0-SNAPSHOT.rar If someone can try this out then that would be excellent. I have only compiled it and not tested it so caveat emptor. lichtner wrote: On Fri, 3 Feb 2006, David Jencks wrote: It is likely to work if you build it. However I don't know that it has been used in the last year or more, so I won't make any promises. Matt might have tried it, I don't know. We have been a bit reluctant to publish it without more evidence that it works well. Why would it not work well? When I was in my last job I remember getting that rar to work with mysql xa, so it probably also works with Oracle xa.
[jira] Created: (GERONIMO-1592) Add NamedUPCredentialLoginModule to Console Realm Wizard
Add NamedUPCredentialLoginModule to Console Realm Wizard Key: GERONIMO-1592 URL: http://issues.apache.org/jira/browse/GERONIMO-1592 Project: Geronimo Type: Improvement Components: console, security, webservices Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.0.1, 1.1 The console currently has a checkbox to store credentials (using the GeronimoPasswordCredentialLoginModule). It should likewise have a checkbox and text field to store credentials using the NamedUPCredentialLoginModule (where the text field specifies the name to save under). -- 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] Updated: (GERONIMO-1566) Binary distributions (both zip and tgz) contain a META-INF/manifest.mf file under the geronimo-1.0 directory.
[ http://issues.apache.org/jira/browse/GERONIMO-1566?page=all ] John Sisson updated GERONIMO-1566: -- Description: The binary distributions (both zip and tgz) contain a META-INF/manifest.mf file under the geronimo-1.0 directory. Fixed. The assembly-plugin has been enhanced to look at a geronimo.assemble.unpack.exclude.manifest property (true/false value) when unpacking the jar file containing the scripts. was: The binary distributions (both zip and tgz) also contain a META-INF/manifest.mf file. It's not at the root level of the archive like in the src dist, but is it necessary? This is a minor issue, but if we end up touching the packaging scripts for this JIRA anyway then we could consider removing those files from the binary dists as well. (This issue has been split out from GERONIMO-1456). Binary distributions (both zip and tgz) contain a META-INF/manifest.mf file under the geronimo-1.0 directory. - Key: GERONIMO-1566 URL: http://issues.apache.org/jira/browse/GERONIMO-1566 Project: Geronimo Type: Bug Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Fix For: 1.0.1, 1.1 The binary distributions (both zip and tgz) contain a META-INF/manifest.mf file under the geronimo-1.0 directory. Fixed. The assembly-plugin has been enhanced to look at a geronimo.assemble.unpack.exclude.manifest property (true/false value) when unpacking the jar file containing the scripts. -- 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] Closed: (GERONIMO-1566) Binary distributions (both zip and tgz) contain a META-INF/manifest.mf file under the geronimo-1.0 directory.
[ http://issues.apache.org/jira/browse/GERONIMO-1566?page=all ] John Sisson closed GERONIMO-1566: - Resolution: Fixed Binary distributions (both zip and tgz) contain a META-INF/manifest.mf file under the geronimo-1.0 directory. - Key: GERONIMO-1566 URL: http://issues.apache.org/jira/browse/GERONIMO-1566 Project: Geronimo Type: Bug Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Fix For: 1.0.1, 1.1 The binary distributions (both zip and tgz) contain a META-INF/manifest.mf file under the geronimo-1.0 directory. Fixed. The assembly-plugin has been enhanced to look at a geronimo.assemble.unpack.exclude.manifest property (true/false value) when unpacking the jar file containing the scripts. -- 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
German Shizer stills coming....
If someone doesnt remove me from this fucking distribution list the porno will be flying fast and furious soon. Fix your fucking unsubscribe script!!! (For the 100th time)
