Re: in-out to in-only adapting - solution
L.S., Seems like a good addition for servicemix-eip at first glance. If you want to contribute it to ServiceMix, the easiest way to ensure follow-up on this would be by raising a JIRA issue. Thank you, Gert ale wrote: i finally managed to find a solution to the synchronizing issue i requested help for 1 days ago. I built a component implementing a pattern which could be thought as the opposite of a pipeline. It accepts an in-out mep and holds it associated to a correlation key and then sends the in message asynchronously to a target service. When an in-only mep comes in it tries to correlate the message with one of the stored exchanges and eventually answers back with the corresponding in-out mep. That's what it does : / -IN-ONLY / -- IN-OUT -- \ \--IN-ONLY Its ina very early version but if anybody finds it interesting i could provide the full sources on this forum or as a jira issue. Let me know, bye.
[jira] Created: (GERONIMO-3242) Version not considered during dependency resolution for plugins
Version not considered during dependency resolution for plugins --- Key: GERONIMO-3242 URL: https://issues.apache.org/jira/browse/GERONIMO-3242 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.0-M6 Environment: All Reporter: Manu T George Fix For: 2.0-M7 When installing a plugin during the dependency resolution the version no of the provided dependency is not taken into account. This causes problems when we want to download a particular version of the dependency for the plugin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3242) Version not considered during dependency resolution for plugins
[ https://issues.apache.org/jira/browse/GERONIMO-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manu T George updated GERONIMO-3242: Attachment: plugin-dependency-resolution.patch Added a check if the version specified is there in the available versions then download that Version not considered during dependency resolution for plugins --- Key: GERONIMO-3242 URL: https://issues.apache.org/jira/browse/GERONIMO-3242 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0-M6 Environment: All Reporter: Manu T George Fix For: 2.0-M7 Attachments: plugin-dependency-resolution.patch When installing a plugin during the dependency resolution the version no of the provided dependency is not taken into account. This causes problems when we want to download a particular version of the dependency for the plugin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Integrating OpenEJB as a SE in servicemix.
Not sure if we are thinking about the same thing. I was thinking about embedding the EJB engine within a SE so that you can deploy annotated POJOs (EJB3) and leverage the EJB3 features (transactions, security, CMP, injection, etc...). For these POJOs to be invoked from the JBI bus, you need to marshall / unmarshall the xml messages to POJOs invocations and the reverse. This is what is actually done in jsr181 SE (or the CXF SE), but these do not leverage EJB features, so I was just thinking about embedding OpenEJB inside CXF and write the same kind of integration you would have inside a JEE5 app server for EJB3 / web services. One should be able to combine WS and EJB3 annotations to create a stateless EJB that could be exposed as a service on the JBI bus, and from this POJO, you could also use the CMP stuff to provide database access. If you do not put any annotations, it should behave the same way as before in jsr181 or CXF-SE. So in my mind, OpenEJB is only used when the component is acting as a provider. Using CXF seeems a good idea for the marshalling / ws stuff for the following reasons: * this is the next version of xfire (there is no more development in xfire) * the OpenEJB / CXF integration has already been done in Geronimo 2.0somehow (no idea how reusable it is) Makes sense ? On 6/13/07, Eric Dofonsou [EMAIL PROTECTED] wrote: Hello Guillaume I've looked at the OpenEJB and CXF module. TO my understanding this would be used to provide a ejb-consumer ONLY endpoint (I see no need for a provider). -OpenEJB would be used to handle the transaction and would provide an interface to marshall/unmarshall the message so they can be transported on the ESB. So my question is do you want to use CXF for this purpose ? - Original Message From: Guillaume Nodet [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 5, 2007 10:17:00 AM Subject: Re: Integrating OpenEJB as a SE in servicemix. I was really thinking that it could be done inside the new SE based on CXF. CXF would do the marshalling based on JAXWS while OpenEJB would provide transactions and access to EJB CMP from the main service POJO (stateless) ... On 6/5/07, Eric Dofonsou [EMAIL PROTECTED] wrote: Hi guys, I was looking at a way to integrate open EJB as a service engine in servicemix. My main question is how do I go about exposing my EJBs in servicemix I wanted to do this with XML (something like WSDL). But the convertion from EJB to XML does not seem trivial. Do you guys here have any hint on how this can be done ? -- View this message in context: http://www.nabble.com/Integrating-OpenEJB-as-a-SE-in-servicemix.-tf3871967s12049.html#a10970148 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
[jira] Assigned: (GERONIMO-3242) Version not considered during dependency resolution for plugins
[ https://issues.apache.org/jira/browse/GERONIMO-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy reassigned GERONIMO-3242: - Assignee: Vamsavardhana Reddy Version not considered during dependency resolution for plugins --- Key: GERONIMO-3242 URL: https://issues.apache.org/jira/browse/GERONIMO-3242 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0-M6 Environment: All Reporter: Manu T George Assignee: Vamsavardhana Reddy Fix For: 2.0-M7 Attachments: plugin-dependency-resolution.patch When installing a plugin during the dependency resolution the version no of the provided dependency is not taken into account. This causes problems when we want to download a particular version of the dependency for the plugin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3242) Version not considered during dependency resolution for plugins
[ https://issues.apache.org/jira/browse/GERONIMO-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy closed GERONIMO-3242. - Resolution: Fixed Completed: At revision: 546793 in trunk. Version not considered during dependency resolution for plugins --- Key: GERONIMO-3242 URL: https://issues.apache.org/jira/browse/GERONIMO-3242 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0-M6 Environment: All Reporter: Manu T George Assignee: Vamsavardhana Reddy Fix For: 2.0-M7 Attachments: plugin-dependency-resolution.patch When installing a plugin during the dependency resolution the version no of the provided dependency is not taken into account. This causes problems when we want to download a particular version of the dependency for the plugin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo/Tuscany integration
Hi, Myself and Manu have been working on the integration thing. As a first step, we have created a plugin for Geronimo that will let the user to deploy standalone tuscany modules into Geronimo and use the deployed services by looking up in JNDI. I have put the code in Geronimo Sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/. Going forward, we have the following in mind: A) Write a deploymentwatcher so that Tuscany modules can be bundled as part of J2EE artifacts. B) Extend the current deployer to enable Tuscany Modules deployed in Geronimo to access resources like datasources from Geronimo Some of the questions we have are: 1. Should we use this plugin approach or intergrate Tuscany to be bundled as part of the Geronimo distribution? 2. Should we have support for bundling Tuscany composites in WAR, EJB-JAR and EAR? Or should we provide for adding a separate Tuscany module in EAR? 3. Where should we maintain the integration code? Your comments and suggestions will be very helpful. Thanks and best regards, Vamsi On 5/10/07, Manu George [EMAIL PROTECTED] wrote: Hi Raymond/Jay, I would like to join this effort. I would like to discuss what is expected of the deep integration. I will just list down my understanding of both the current and proposed integrations Understanding of the Current Integration 1) TuscanyContextListener creates an SCA domain when the servlet is created and then destroys it when the servlet is destroyed. 2) During SCA domain creation it looks up the composites and deploys them in the domain Creates a webapp module activator for registering servlet hosts. 3) Finally we have a servlet that forwards requests to the servlet registered with the Tuscany Servlet Host. 4) An SCADomain is created for each application and we can lookup the services from the SCADomain. 5) During SCADomain creation a runtime is also created for the DefaultSCADomain. 7) All tuscany classes are loaded repeatedly for each application in separate classloaders. 8) A runtime is created per application Understanding/Doubts about the proposed Integration. 1) Each SCA application will have an SCA module which will be a jar with an SCDL in META-INF. This jar can also be part of an EAR. . There will be a Tuscany deployer that will take care of deploying the SCA modules. Should WAR files be also able to contain SCA jars? 2) Each App will have an SCA Domain which will be instantiated when the application starts. Is this assumption correct or can there be multiple SCADomains per app? 3) The Tuscany classes are loaded only once and then shared between the different SCA applications. 4) There will be multiple domains instantiated from different applications and there should be a server wide domain registry where applications can look up and invoke different composites from domains different from their own. (Can this be Global JNDI/Gbean refs or is there something specific in tuscany). 5) There should be only a single Tuscany Runtime for the entire geronimo instance. 6) How can we lookup the services running in one geronimo instance from an app in another geronimo instance. Is this supported in Tuscany These are just the initial set of points/questions that hit me when I thought about the integration. Jay /Raymond I guess you guys will be aware of many other points as well. Can you reply with your analysis so that we can flesh out the requirements completely in the mailing list. That way both the communities can contribute their thoughts. If you have already started can you just point me to where I can catch up on what has happened? Thanks Manu On 4/26/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Geronimo community. As you may know, Tuscany is an Apache project under incubation to provide an open source SOA infrastructure. For more information, you can visit http://cwiki.apache.org/TUSCANY/. Tuscany implements the SCA specification (http://www.osoa.org) and allows you to develop and run SCA components in various hosting environments. We currently integrate with Tomcat and Jetty and would like to try to integrate with Geronimo as well. I would like to start some discussions here to figure out the best way to do that. After some preliminary investigations of Geronimo, I feel that there are two options on the table so far. 1) Shallow integration: Package SCA applications together with the Tuscany runtime as WARs and deploy them Geronimo as Web applications. It's basically the integration with a Web container. We register a TuscanyContextListner (which implements javax.servlet.ServletContextListener) in web.xml to start/stop the Tuscany runtime when the web application is started/stopped. This will allow us to support the following use cases: * A Web application hosted by Geronimo with business logic written as SCA components * Expose one or more SCA components as Web services over HTTP as supported by the Web container. 2) Deep integration: We
Re: pluto portal for geronimo 2.0
Paul, I've been an advocate of this approach as well so thanks for taking the initiative on this. I'll take a look at what you've done later today. There are probably a few issues we'll need to consider if we take this plugin approach - splitting the console components from the underlying portal infrastructure: - Uniformity between various portal implementations for how to define portlet page content, theme/skin definition, and any portal extensions that we may use. - Plugin dependencies based upon type - ie. the admin console plugin would have a pre-req on a portal plugin but not necessarily a particular portal plugin if we can pull manage to pull off this separation. Perhaps I'm taking this a bit farther than you intended at the moment. We could certainly just split these components for now and have the admin console tightly dependent upon a Pluto component. That does provide some benefits such as in allowing a user to choose the portal without the admin console and allowing the user to integrate their own portlets with Geronimo admin functions. That's a good step forward. Greater flexibility would be in allowing the user to choose the portal they wish to use but I think this would require more portal standards that do not yet exist. Thanks for taking the first step here! Joe Paul McMahan wrote: We have talked about upgrading the admin console to use a more recent version of pluto. Now that geronimo 2.0 has taken shape I took a look at pluto 1.2 and found that it has a lot of new features that we should take advantage of, including the ability to make our admin console more dynamic and customizable. It is not backwards compatible with the version that we currently use so we can't just swap in the jars. But that's OK since I think our goal to make the admin console more dynamic probably warrants a bit of redesign anyway. I just committed some stuff to sandbox that demonstrates one technique for integrating pluto into geronimo, and I think it can serve as the basis for a more dynamic admin console as well. You can try it out by following these steps: svn co https://svn.apache.org/repos/asf/geronimo/sandbox/portals cd portals mvn geronimo/bin/deploy.sh install-plugin pluto-container/target/pluto-container-1.0-SNAPSHOT.car geronimo/bin/deploy.sh deploy pluto-portal/target/pluto-portal-1.0-SNAPSHOT.war geronimo/bin/deploy.sh deploy pluto-testsuite/target/pluto-testsuite.war point your browser at http://localhost:8080/pluto/portal This works in the minimal or jee5 assemblies, but right now it only supports tomcat because the cross-context setting is required in geronimo-web.xml. I was hoping to avoid a separate jetty module just for that setting, but maybe that's unavoidable. The maven related stuff could probably use some tuning as well. While working on this it occurred to me that we could consider providing a native general purpose portal in geronimo, and the admin console as we know it today could just be a collection of portlets deployed into it that are only visible to users with sufficient admin privileges. The stuff in sandbox could also help us move things in that direction if we like that idea. Thoughts? Best wishes, Paul
[jira] Resolved: (GERONIMO-3241) The J2G Sources tool should have the ability to easily add compatibility classes
[ https://issues.apache.org/jira/browse/GERONIMO-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-3241. Resolution: Fixed Completed: At revision: 546862 The J2G Sources tool should have the ability to easily add compatibility classes Key: GERONIMO-3241 URL: https://issues.apache.org/jira/browse/GERONIMO-3241 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Reporter: Jason Warner Assignee: Jason Warner Attachments: Geronimo-3241.patch The J2G sources tool has some already built in classes used for compatibility between JBoss and Geronimo. These classes are wrapped inside of jars, though, and make it difficult to add more without having to rebuild the tool. There should be a top-level folder where these classes can be dropped for use with the tool after it's already been built. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release specs for Activation, JACC, Deployment, Servlet and StAX
I am going to release Deployment as it passed with all +1's The other specs either had issues or were dependent on specs that had issues so I'll spin up a new vote for them. Thanks for your critical eyes. On Jun 8, 2007, at 5:43 PM, Matt Hogstrom wrote: Please review the specifications located at http:// people.apache.org/~hogstrom/specs-rc1/ We are voting these in a block. Failures will be removed from the block and others will proceed forward. Voting concludes on Monday, June 11th at 1800 ET. Thanks
[jira] Assigned: (GERONIMO-3160) align J2G tool with Geronimo 's core eclipse plugins
[ https://issues.apache.org/jira/browse/GERONIMO-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner reassigned GERONIMO-3160: -- Assignee: (was: Jason Warner) align J2G tool with Geronimo 's core eclipse plugins Key: GERONIMO-3160 URL: https://issues.apache.org/jira/browse/GERONIMO-3160 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Reporter: Paul McMahan Priority: Minor The J2G tool is implemented as a collection eclipse plugins. It should be aligned with Geronimo's core eclipse plugins in terms of how it is built and used, and should also be offered through the same distribution mechanism (eclipse plugin manager). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3239) Jasper JSPCompiler used in J2G breaks on pathnames in some applications
[ https://issues.apache.org/jira/browse/GERONIMO-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan reassigned GERONIMO-3239: -- Assignee: Paul McMahan (was: Erik B. Craig) Jasper JSPCompiler used in J2G breaks on pathnames in some applications --- Key: GERONIMO-3239 URL: https://issues.apache.org/jira/browse/GERONIMO-3239 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: J2G Environment: Windows XP/Sun JDK 1.5_12 Reporter: Erik B. Craig Assignee: Paul McMahan Attachments: geronimo-3239.patch The relative path names being used in the JSPCompiler portion of J2G resulted in some invalid paths in only some apps being converted on windows. A check must be put in place to correct this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3239) Jasper JSPCompiler used in J2G breaks on pathnames in some applications
[ https://issues.apache.org/jira/browse/GERONIMO-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-3239. -- Resolution: Fixed patch committed. thanks Erik! Jasper JSPCompiler used in J2G breaks on pathnames in some applications --- Key: GERONIMO-3239 URL: https://issues.apache.org/jira/browse/GERONIMO-3239 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: J2G Environment: Windows XP/Sun JDK 1.5_12 Reporter: Erik B. Craig Assignee: Paul McMahan Attachments: geronimo-3239.patch The relative path names being used in the JSPCompiler portion of J2G resulted in some invalid paths in only some apps being converted on windows. A check must be put in place to correct this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3234) JIRA to add another testset to the CORBA testsuite
[ https://issues.apache.org/jira/browse/GERONIMO-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504275 ] Donald Woods commented on GERONIMO-3234: Applied GERONIMO-3234-2.patch as revision 546900. Please review and close if this work item is completed. JIRA to add another testset to the CORBA testsuite -- Key: GERONIMO-3234 URL: https://issues.apache.org/jira/browse/GERONIMO-3234 Project: Geronimo Issue Type: Test Security Level: public(Regular issues) Components: CORBA Affects Versions: 2.0-M7 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.0-M7 Attachments: GERONIMO-3234-2.patch, GERONIMO-3234.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3060) Add a separate tree branch for persistence units into the JMX viewer
[ https://issues.apache.org/jira/browse/GERONIMO-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-3060. Resolution: Fixed Fix Version/s: 2.0-M7 Assignee: Jay D. McHugh (was: Matt Hogstrom) Applied Jay's patch as revision 546902. Please close this issue if everything looks okay. Add a separate tree branch for persistence units into the JMX viewer Key: GERONIMO-3060 URL: https://issues.apache.org/jira/browse/GERONIMO-3060 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: console, persistence Affects Versions: 2.0-M5 Reporter: Jay D. McHugh Assignee: Jay D. McHugh Priority: Minor Fix For: 2.0-M7 Attachments: geronimo-3060.patch Added a branch under J2EE Managed Objects that show the persistence unit gbeans. Note: persistence unit gbeans still appear under All MBeans/geronimo. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release of javamail 1.4 specs and javamail 1.4 providers
+1 -Donald Rick McGuire wrote: Please review the javamail specifications located at http://people.apache.org/~prasad/specs_rc1/ The files in question are geronimo-javamail_1.4_spec-1.0.tar.gz http://people.apache.org/%7Eprasad/specs_rc1/geronimo-javamail_1.4_spec-1.0.tar.gz, which is the api spec jar and geronimo-javamail_1.4-1.1.tar.gz http://people.apache.org/%7Eprasad/specs_rc1/geronimo-javamail_1.4-1.1.tar.gz, which is the javamail provider implementations and the merged mail jar. The provider jar has a dependency on the javamail spec jar. The merged mail jar is used by Geronimo 2.0 for the javamail implementation. Voting concludes on Friday, June 15th at 1100 ET Rick smime.p7s Description: S/MIME Cryptographic Signature
[jira] Updated: (GERONIMO-2892) Undeploy locks files on Windows
[ https://issues.apache.org/jira/browse/GERONIMO-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2892: --- Fix Version/s: Verification Required Undeploy locks files on Windows --- Key: GERONIMO-2892 URL: https://issues.apache.org/jira/browse/GERONIMO-2892 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M3, 2.0-M5 Environment: Windows XP. Reporter: Prasad Kashyap Priority: Blocker Fix For: Verification Required Attachments: simplewebapp0.war Upon undeploying an app, its entry in the config.xml is removed. However its files in the G repo are not cleaned up. When the same app is deployed again, it fails with the a Config already exists Exception. Trying to undelete the app's files from the G repo fails with a windows message that files are in use by an another process. http://www.nabble.com/Can-somebody-please-verify-that-undeploy-works-%28on-Windows%29---tf3269734.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Updated Specs for Servlet and JACC - Please be aware
I have made changes to the Servlet specification by replacing the web- app_2_5.xsd as well as the web-app_2_2.dtd files with clean room implementations. This is a heads up. Let's allow these to bake for a few days and then we'll release these and be done with any IP issues.
Re: pluto portal for geronimo 2.0
On Jun 12, 2007, at 8:23 PM, David Jencks wrote: Sure, but if you are planning to use this for the admin console you'll probably need separate modules for jetty and tomcat anyway, so 2 plans is more or less required even if they are identical. Not sure I follow you on this. Do you mean that we might create two separate collections of portlets based on which web container is in use? Today the admin console the same collection of portlets built from a single codebase for both containers -- the webconatiner administration jsps just render differently when running in tomcat vs. jetty. The only thing I know of that's really different between the tomcat and jetty admin console modules is their deployment plans, and I think those could be consolidated. Or are there other reasons why you think separate modules might be required, perhaps the security configuration? Whether or not separate modules are needed for the admin console, if we want the portal to be extensible by geronimo applications then it would be best if they can provide a single extension module that works in both containers. Hopefully the container-config technique that Jeff pointed out will allow them to accomplish that (it worked for me). Is pluto 1.2 actually functional as a real portal, or is it just way easier to deploy portlets to than 1.0 was? My impression was that it was not really intended to be a jetspeed or liferay replacement. No it does not provide equivalent functionality to jetspeed or liferay. In fact their FAQ says: Is Pluto an Enterprise Portal? No, the Pluto project aims to provide a Java Specification compliant Portlet Container. In order to support the container, the Pluto project provides a simple portal, however, this does not provides optional services such as single sign on. If you are looking for an Open Source enterprise Portal implementation, there are several available. Apache Jetspeed is an enterprise portal hosted by the Apache Software Foundation. Sakai and uPortal are both educational portals which utilize Pluto as their container. There are many other open source portals. http://portals.apache.org/pluto/faq.html So for an enterprise class portal Geronimo users should be encouraged to look into one of those solutions. For simple a portal application like the admin console, and for portlet development and testing purposes I think pluto's portal driver provides an ideal lightweight solution. And technically speaking there's nothing that prevents a geronimo user from installing multiple portal solutions alongside pluto. I've been hoping that now that jetspeed has m2-ized their build we might be able to pursue jetspeed integration again. As mentioned above pluto doesn't claim to provide an enterprise class solution. It's very lightweight and really intended for simple portal apps and for portlet development / testing. As long as the portlets are written against the JSR 168 api they should be portable across the portal containers. So by all means let's continue to pursue integration with jetspeed, liferay, etc. We can put all these goodies into sandbox/portals for now and then later decide if we want to migrate the useful parts into server/trunk or create a new subproject. Best wishes, Paul
Re: [VOTE] 2.0-M6 (rc3)
+1 for all 4 assemblies. Joe Jay D. McHugh wrote: Full test (server start, database pool creations, app deploy, and app use) +1 tomcat-jee5 +0 jetty-jee5 (app use fails - testing further to determine reason) Basic test (server start and stop) +1 tomcat-minimal +1 jetty-minimal Jay Matt Hogstrom wrote: I think I've narrowed the problem on the rebuild. When building from the top-level it seems we pick up more cars than we want. If I build local in the assemblies dir then things seem to be scoped correctly. Something odd with Maven and / or how were using it. The binaries are uploading now so please take a peek. http://people.apache.org/~hogstrom/2.0-M6-rc3 Vote concludes on Thursday June 14th at 2300 hours. [ ] +1 release [ ] 0 abstain [ ] -1 Don't ship...provide reason
[jira] Updated: (GERONIMO-1917) repository doesn't deal well with case insensitive file systems
[ https://issues.apache.org/jira/browse/GERONIMO-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-1917: --- Fix Version/s: (was: 2.0-M5) (was: 1.1.2) repository doesn't deal well with case insensitive file systems --- Key: GERONIMO-1917 URL: https://issues.apache.org/jira/browse/GERONIMO-1917 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1, 1.1.1, 1.1.2, 1.1.x Reporter: David Jencks If you've installed a configuration A/B/1/car and then look for a/b/1/car, the repository will claim it's there on a case insensitive file system, but then further logic in the config store/ manager blows up because those are different artifacts. Solution appears to be to check when locating an artifact that the case from the file system matches the case you are asking for. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2480) Plugin installer status sticks on Searching for X at Y while downloading
[ https://issues.apache.org/jira/browse/GERONIMO-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2480: --- Fix Version/s: (was: 2.0-M5) (was: 1.1.2) (was: 1.x) Plugin installer status sticks on Searching for X at Y while downloading -- Key: GERONIMO-2480 URL: https://issues.apache.org/jira/browse/GERONIMO-2480 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.1.1 Reporter: Aaron Mulder The plugin installer should show status Downloading X from Y during a download, but it seems to get stuck on the previous Searching for... message while showing the download percentage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2322) remove resources and unit-test specifications from project.xml
[ https://issues.apache.org/jira/browse/GERONIMO-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2322: --- Fix Version/s: (was: 1.1.2) remove resources and unit-test specifications from project.xml -- Key: GERONIMO-2322 URL: https://issues.apache.org/jira/browse/GERONIMO-2322 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.1.2 Reporter: Kevan Miller Some module project.xml files contain resources and unit-test specifications. As these override the settings in etc/project.xml, there can be unexpected results. Updates to etc/project.xml may not be reflected in these modules. Better to fold all behavior into etc/project.xml, if possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1747) HTTP-methods checks
[ https://issues.apache.org/jira/browse/GERONIMO-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-1747: --- Fix Version/s: (was: 1.1.2) HTTP-methods checks --- Key: GERONIMO-1747 URL: https://issues.apache.org/jira/browse/GERONIMO-1747 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.0 Environment: Windows 2003, java 1.4 Reporter: Ilya Platonov Attachments: slide.war, web.xml I'm tring to run jakarta-slide web-application on geronimo application server. Slide provides WebDAV support. When security constrain is not set, everything works fine exept some minor issues but when I put some security constraints for servlets I got following error in server.log. 15:43:58,132 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Invalid HTTPMethodSpec at javax.security.jacc.HTTPMethodSpec.init(HTTPMethodSpec.java:114) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:84) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasUserDataPermission(TomcatGeronimoRealm.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:428) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:262) at org.apache.geronimo.tomcat.valve.PolicyContextValve.invoke(PolicyContextValve.java:50) at org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) at org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) at org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) When I looked through Geronimo source code I found that GET, POST, PUT, DELETE, HEAD, OPTIONS and TRACE http-methods hardcoded into HTTPMethodSpec class and if you tring to use another method it throws this exception. Problem is that WebDAV specification extends standard HTTP-methods, for example it uses MKCOL and LOCK methods so jakarta-slide just not working. Is there any workaround for this bug or geronimo is just not able to handle any HTTP protocol extensions??? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2561) Uber geronimo-j2ee_1.4_spec was not updated and republished for 1.1.1 to include updated geronimo-j2ee-jacc_1.0_spec-1.1.1
[ https://issues.apache.org/jira/browse/GERONIMO-2561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2561: --- Fix Version/s: (was: 1.1.x) (was: 1.1.2) Uber geronimo-j2ee_1.4_spec was not updated and republished for 1.1.1 to include updated geronimo-j2ee-jacc_1.0_spec-1.1.1 -- Key: GERONIMO-2561 URL: https://issues.apache.org/jira/browse/GERONIMO-2561 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1.1, 1.1.2, 1.2 Reporter: Donald Woods Assignee: Matt Hogstrom Priority: Critical geronimo-j2ee-jacc_1.0_spec was updated to version 1.1.1 for the Geronimo 1.1.1 release, but the uber geronimo-j2ee_1.4_spec was not rebuilt and republished to include the JACC updates. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1053) Session Bean, Finder, Method Permissions
[
https://issues.apache.org/jira/browse/GERONIMO-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods updated GERONIMO-1053:
---
Fix Version/s: (was: 1.1.2)
Session Bean, Finder, Method Permissions
--
Key: GERONIMO-1053
URL: https://issues.apache.org/jira/browse/GERONIMO-1053
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: OpenEJB, security
Affects Versions: 1.0-M5
Reporter: Aaron Mulder
Priority: Blocker
I have an EAR with a Web App, Session Bean, and CMP Entity Bean, using the M5
release.
The user brings up a secure page on the web app and logs in.
The web code invoked after the login calls the session bean.
The session bean calls a finder on the entity bean, and gets this (in the
session bean method code, where it calls the finder):
{noformat}
Caused by: javax.ejb.TransactionRolledbackLocalException
at
org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:123)
at
org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80)
at
org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82)
at
org.openejb.GenericEJBContainer$DefaultSubjectInterceptor.invoke(GenericEJBContainer.java:545)
at
org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238)
at
org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:129)
at
org.openejb.proxy.EntityEJBLocalHome$$EnhancerByCGLIB$$afb1a239.findAll(generated)
at
org.loadmagus.ejb.TestManagerBean.getAllApplications(TestManagerBean.java:70)
... 48 more
Caused by: javax.ejb.AccessLocalException: access denied
(javax.security.jacc.EJBMethodPermission EntityBean findAll,LocalHome,)
at
org.openejb.security.EJBSecurityInterceptor.invoke(EJBSecurityInterceptor.java:107)
at
org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56)
at
org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81)
at
org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136)
at
org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:84)
at
org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119)
... 55 more
{noformat}
The ejb-jar.xml for the EJBs in question has:
{noformat}
security-role
role-nameDeveloper/role-name
/security-role
method-permission
role-nameDeveloper/role-name
method
ejb-nameSessionBean/ejb-name
method-name*/method-name
/method
/method-permission
method-permission
role-nameDeveloper/role-name
method
ejb-nameEntityBean/ejb-name
method-name*/method-name
/method
/method-permission
{noformat}
So it's a little odd that the session bean sees a transaction rolled back
exception rather than the real security exception, but whatever.
The real problem is that both the session bean and the entity bean are
covered by identical all-inclusive method permission blocks, so if the user
got into the session bean, there should be no reason they can't get into the
entity bean. The syntax above is specifically supported in the
ejb-jar-2_1.xsd Schema (#1; This style is used to refer to all the methods
of the specified enterprise bean's home, component, and/or web service
endpoint interfaces.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: pluto portal for geronimo 2.0
On Jun 13, 2007, at 8:20 AM, Paul McMahan wrote: On Jun 12, 2007, at 8:23 PM, David Jencks wrote: Sure, but if you are planning to use this for the admin console you'll probably need separate modules for jetty and tomcat anyway, so 2 plans is more or less required even if they are identical. Not sure I follow you on this. Do you mean that we might create two separate collections of portlets based on which web container is in use? Today the admin console the same collection of portlets built from a single codebase for both containers -- the webconatiner administration jsps just render differently when running in tomcat vs. jetty. The only thing I know of that's really different between the tomcat and jetty admin console modules is their deployment plans, and I think those could be consolidated. Or are there other reasons why you think separate modules might be required, perhaps the security configuration? Whether or not separate modules are needed for the admin console, if we want the portal to be extensible by geronimo applications then it would be best if they can provide a single extension module that works in both containers. Hopefully the container-config technique that Jeff pointed out will allow them to accomplish that (it worked for me). module == car file (or plugin), i.e. pre-deployed application for javaee apps, and you certainly can't run the same web module in both the jetty and tomcat integrations. So, unless you are proposing a really big redesign of what is in a module for a web app, you're going to need separate modules for pluto on jetty and tomcat, the base console on jetty and tomcat, each bit of additional console on jetty and tomcat It's quite possible for the plans for the jetty and tomcat versions to be identical (as long as the environment element is added by the car plugin), but you still get 2 modules. thanks david jencks Is pluto 1.2 actually functional as a real portal, or is it just way easier to deploy portlets to than 1.0 was? My impression was that it was not really intended to be a jetspeed or liferay replacement. No it does not provide equivalent functionality to jetspeed or liferay. In fact their FAQ says: Is Pluto an Enterprise Portal? No, the Pluto project aims to provide a Java Specification compliant Portlet Container. In order to support the container, the Pluto project provides a simple portal, however, this does not provides optional services such as single sign on. If you are looking for an Open Source enterprise Portal implementation, there are several available. Apache Jetspeed is an enterprise portal hosted by the Apache Software Foundation. Sakai and uPortal are both educational portals which utilize Pluto as their container. There are many other open source portals. http://portals.apache.org/pluto/faq.html So for an enterprise class portal Geronimo users should be encouraged to look into one of those solutions. For simple a portal application like the admin console, and for portlet development and testing purposes I think pluto's portal driver provides an ideal lightweight solution. And technically speaking there's nothing that prevents a geronimo user from installing multiple portal solutions alongside pluto. I've been hoping that now that jetspeed has m2-ized their build we might be able to pursue jetspeed integration again. As mentioned above pluto doesn't claim to provide an enterprise class solution. It's very lightweight and really intended for simple portal apps and for portlet development / testing. As long as the portlets are written against the JSR 168 api they should be portable across the portal containers. So by all means let's continue to pursue integration with jetspeed, liferay, etc. We can put all these goodies into sandbox/portals for now and then later decide if we want to migrate the useful parts into server/trunk or create a new subproject. Best wishes, Paul
[jira] Updated: (GERONIMO-2288) Abstract/Maven repositories install modules incorrectly
[ https://issues.apache.org/jira/browse/GERONIMO-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2288: --- Affects Version/s: 2.0-M6 1.2 1.1.1 Fix Version/s: (was: 1.2) Abstract/Maven repositories install modules incorrectly --- Key: GERONIMO-2288 URL: https://issues.apache.org/jira/browse/GERONIMO-2288 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel, Plugins Affects Versions: 1.1, 1.1.1, 1.2, 2.0-M6 Reporter: Aaron Mulder Assignee: Aaron Mulder The repository unpacks a JAR when it installs it only if the Artifact type is car. That is incorrect -- it should unpack any module with META-INF/config.ser (which is the logic that we use in other places, such as RepositoryConfigurationStore). This breaks plugins that don't have the type car (such as copying a database pool from server to server). The currently handling attempts to be generic by associating a behavior with each file type, though in practice this is only used for type=car. In the 1.1 branch, I am going to put in a workaround to look up the car handler any time we find a META-INF/config.ser (a pretty minimal workaround). In trunk, I think we should remove the behavior/type association and instead have a boolean for whether configurations should be unpacked, or an ArtifactTypeHandler property specifically for configurations and another one for non-configurations. I don't see any reason to distinguish based on module type. Input would be appreciated for the 1.2 resolution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: pluto portal for geronimo 2.0
On Jun 13, 2007, at 9:08 AM, Joe Bohn wrote: I've been an advocate of this approach as well so thanks for taking the initiative on this. I'll take a look at what you've done later today. a significant part of this approach is based on the work you did on little G, as well as the opinions you have been sharing with us about the need for a more dynamic admin console. so I'm definitely looking forward to more feedback and participation from you! There are probably a few issues we'll need to consider if we take this plugin approach - splitting the console components from the underlying portal infrastructure: - Uniformity between various portal implementations for how to define portlet page content, theme/skin definition, and any portal extensions that we may use. - Plugin dependencies based upon type - ie. the admin console plugin would have a pre-req on a portal plugin but not necessarily a particular portal plugin if we can pull manage to pull off this separation. Perhaps I'm taking this a bit farther than you intended at the moment. We could certainly just split these components for now and have the admin console tightly dependent upon a Pluto component. That does provide some benefits such as in allowing a user to choose the portal without the admin console and allowing the user to integrate their own portlets with Geronimo admin functions. That's a good step forward. Greater flexibility would be in allowing the user to choose the portal they wish to use but I think this would require more portal standards that do not yet exist. I wasn't thinking out that far yet. Like you said more standards are probably needed before we could think about making the portal container interchangeable without affecting the portlets that have already been deployed. I agree that providing a native portal container that geronimo users can deploy standard JSR 168 portlets into is a good step forward, and maybe we can make some improvements to the administration console in the process. Later on the portal or J2EE community may provide more standardization in this area, so please help us stay on the right track. Best wishes, Paul
Re: pluto portal for geronimo 2.0
On Jun 13, 2007, at 12:36 PM, David Jencks wrote: module == car file (or plugin), i.e. pre-deployed application for javaee apps, and you certainly can't run the same web module in both the jetty and tomcat integrations. So, unless you are proposing a really big redesign of what is in a module for a web app, you're going to need separate modules for pluto on jetty and tomcat, the base console on jetty and tomcat, each bit of additional console on jetty and tomcat It's quite possible for the plans for the jetty and tomcat versions to be identical (as long as the environment element is added by the car plugin), but you still get 2 modules. Sorry my terminology is a bit rusty. Now I understand what you mean and agree that for pre-deployed versions of the pluto driver and admin console web apps there would be separate plugins for tomcat and jetty. Right now the only piece that's implemented as a plugin is the pluto container which only prereqs the jee-specs config and some pluto jars, so it can be used in either tomcat or jetty. Best wishes, Paul
[jira] Created: (GERONIMO-3243) ActiveMQ violates System Properties
ActiveMQ violates System Properties
---
Key: GERONIMO-3243
URL: https://issues.apache.org/jira/browse/GERONIMO-3243
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: ActiveMQ
Affects Versions: 2.0-M3, 1.2, 2.0-M4
Reporter: solprovider
The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
Geronimo development please add all affected versions?)
ActiveMQ adds a HashMap as a global Property named
org.apache.activeio.journal.active.lockMap.
Properties must use Strings for keys and values per
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
This causes any code reading all the Properties and expecting Strings to error.
The error can be produced with Cocoon's SitemapVariableHolder for XMAP
constants:
map:component-configurationsglobal-variables
myConstantHello World/myConstant
/global-variables/map:component-configurations
{global:myConstant} errors
The permanent fix is for Geronimo to update to a better version of ActiveMQ,
either downgrading to before the bug was programmed or wait for the ActiveMQ
team to follow the standards. That is unlikely to be tested and released
quickly.
The quick fix is to disable the offensive code. For Geronimo 1.2 on Windows,
add this line at the beginning of STARTUP.BAT:
SET GERONIMO_OPTS=-Dorg.apache.activeio.journal.active.DisableLocking=true
%GERONIMO_OPTS%
David Jencks suggested that Geronimo can set the
org.apache.activeio.journal.active.DisableLocking property in a Geronimo
SystemProperties gbean, there's one called ServerSystemProperties in
j2ee-server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] 2.0-M6 (rc3)
+1 Matt Hogstrom wrote: I think I've narrowed the problem on the rebuild. When building from the top-level it seems we pick up more cars than we want. If I build local in the assemblies dir then things seem to be scoped correctly. Something odd with Maven and / or how were using it. The binaries are uploading now so please take a peek. http://people.apache.org/~hogstrom/2.0-M6-rc3 Vote concludes on Thursday June 14th at 2300 hours. [ ] +1 release [ ] 0 abstain [ ] -1 Don't ship...provide reason
[jira] Updated: (GERONIMO-3243) ActiveMQ violates System Properties
[
https://issues.apache.org/jira/browse/GERONIMO-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
solprovider updated GERONIMO-3243:
--
Description:
The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
Geronimo development please add all affected versions?)
ActiveMQ adds a HashMap as a global Property named
org.apache.activeio.journal.active.lockMap.
Properties must use Strings for keys and values per
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
This causes any code reading all the Properties and expecting Strings to error.
Here is a test:
boolean test(){ //true = passes, false = failed.
boolean test = true;
java.util.Properties properties = System.getProperties();
java.util.Enumeration enumeration = properties.elements();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
enumeration = properties.keys();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
return test;
}
The permanent fix is for Geronimo to update to a better version of ActiveMQ,
either downgrading to before the bug was programmed or wait for the ActiveMQ
team to follow the standards. That is unlikely to be tested and released
quickly.
The quick fix is to disable the offensive code. For Geronimo 1.2 on Windows,
add this line at the beginning of STARTUP.BAT:
SET GERONIMO_OPTS=-Dorg.apache.activeio.journal.active.DisableLocking=true
%GERONIMO_OPTS%
David Jencks suggested that Geronimo can set the
org.apache.activeio.journal.active.DisableLocking property in a Geronimo
SystemProperties gbean, there's one called ServerSystemProperties in
j2ee-server.
was:
The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
Geronimo development please add all affected versions?)
ActiveMQ adds a HashMap as a global Property named
org.apache.activeio.journal.active.lockMap.
Properties must use Strings for keys and values per
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
This causes any code reading all the Properties and expecting Strings to error.
The error can be produced with Cocoon's SitemapVariableHolder for XMAP
constants:
map:component-configurationsglobal-variables
myConstantHello World/myConstant
/global-variables/map:component-configurations
{global:myConstant} errors
The permanent fix is for Geronimo to update to a better version of ActiveMQ,
either downgrading to before the bug was programmed or wait for the ActiveMQ
team to follow the standards. That is unlikely to be tested and released
quickly.
The quick fix is to disable the offensive code. For Geronimo 1.2 on Windows,
add this line at the beginning of STARTUP.BAT:
SET GERONIMO_OPTS=-Dorg.apache.activeio.journal.active.DisableLocking=true
%GERONIMO_OPTS%
David Jencks suggested that Geronimo can set the
org.apache.activeio.journal.active.DisableLocking property in a Geronimo
SystemProperties gbean, there's one called ServerSystemProperties in
j2ee-server.
ActiveMQ violates System Properties
---
Key: GERONIMO-3243
URL: https://issues.apache.org/jira/browse/GERONIMO-3243
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 1.2, 2.0-M3, 2.0-M4
Reporter: solprovider
The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
Geronimo development please add all affected versions?)
ActiveMQ adds a HashMap as a global Property named
org.apache.activeio.journal.active.lockMap.
Properties must use Strings for keys and values per
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
This causes any code reading all the Properties and expecting Strings to
error.
Here is a test:
boolean test(){ //true = passes, false = failed.
boolean test = true;
java.util.Properties properties = System.getProperties();
java.util.Enumeration enumeration = properties.elements();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
enumeration = properties.keys();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
return test;
}
The permanent fix is for Geronimo to update to a better version of ActiveMQ,
either downgrading to before the bug was programmed or wait for the ActiveMQ
team to follow the standards. That is unlikely to be tested and released
quickly.
The quick fix is to disable the offensive code. For Geronimo 1.2 on
Windows, add this line at the beginning of STARTUP.BAT:
SET GERONIMO_OPTS=-Dorg.apache.activeio.journal.active.DisableLocking=true
[jira] Updated: (GERONIMO-3243) ActiveMQ violates System Properties
[
https://issues.apache.org/jira/browse/GERONIMO-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
solprovider updated GERONIMO-3243:
--
Description:
The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
Geronimo development please add all affected versions?)
ActiveMQ adds a HashMap as a global Property named
org.apache.activeio.journal.active.lockMap.
Properties must use Strings for keys and values per
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
This causes any code reading all the Properties and expecting Strings to error.
{code:title=Test Code|borderStyle=solid}
boolean test(){ //true = passes, false = failed.
boolean test = true;
java.util.Properties properties = System.getProperties();
java.util.Enumeration enumeration = properties.elements();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
enumeration = properties.keys();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
return test;
}
{code}
The permanent fix is for Geronimo to update to a better version of ActiveMQ,
either downgrading to before the bug was programmed or wait for the ActiveMQ
team to follow the standards. That is unlikely to be tested and released
quickly.
The quick fix is to disable the offensive code. For Geronimo 1.2 on Windows,
add this line at the beginning of STARTUP.BAT:
SET GERONIMO_OPTS=-Dorg.apache.activeio.journal.active.DisableLocking=true
%GERONIMO_OPTS%
David Jencks suggested that Geronimo can set the
org.apache.activeio.journal.active.DisableLocking property in a Geronimo
SystemProperties gbean, there's one called ServerSystemProperties in
j2ee-server.
was:
The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
Geronimo development please add all affected versions?)
ActiveMQ adds a HashMap as a global Property named
org.apache.activeio.journal.active.lockMap.
Properties must use Strings for keys and values per
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
This causes any code reading all the Properties and expecting Strings to error.
Here is a test:
boolean test(){ //true = passes, false = failed.
boolean test = true;
java.util.Properties properties = System.getProperties();
java.util.Enumeration enumeration = properties.elements();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
enumeration = properties.keys();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
return test;
}
The permanent fix is for Geronimo to update to a better version of ActiveMQ,
either downgrading to before the bug was programmed or wait for the ActiveMQ
team to follow the standards. That is unlikely to be tested and released
quickly.
The quick fix is to disable the offensive code. For Geronimo 1.2 on Windows,
add this line at the beginning of STARTUP.BAT:
SET GERONIMO_OPTS=-Dorg.apache.activeio.journal.active.DisableLocking=true
%GERONIMO_OPTS%
David Jencks suggested that Geronimo can set the
org.apache.activeio.journal.active.DisableLocking property in a Geronimo
SystemProperties gbean, there's one called ServerSystemProperties in
j2ee-server.
ActiveMQ violates System Properties
---
Key: GERONIMO-3243
URL: https://issues.apache.org/jira/browse/GERONIMO-3243
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 1.2, 2.0-M3, 2.0-M4
Reporter: solprovider
The latest Geronimo 1.2 and 2.0 use ActiveMQ. (Would someone familiar with
Geronimo development please add all affected versions?)
ActiveMQ adds a HashMap as a global Property named
org.apache.activeio.journal.active.lockMap.
Properties must use Strings for keys and values per
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html
This causes any code reading all the Properties and expecting Strings to
error.
{code:title=Test Code|borderStyle=solid}
boolean test(){ //true = passes, false = failed.
boolean test = true;
java.util.Properties properties = System.getProperties();
java.util.Enumeration enumeration = properties.elements();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
enumeration = properties.keys();
while(test enumeration.hasMoreElements()) test=
String.class.equals(enumeration.nextElement().getClass());
return test;
}
{code}
The permanent fix is for Geronimo to update to a better version of ActiveMQ,
either downgrading to before
Re: [VOTE] 2.0-M6 (rc3)
+1 Cheers! Hernan Matt Hogstrom wrote: I think I've narrowed the problem on the rebuild. When building from the top-level it seems we pick up more cars than we want. If I build local in the assemblies dir then things seem to be scoped correctly. Something odd with Maven and / or how were using it. The binaries are uploading now so please take a peek. http://people.apache.org/~hogstrom/2.0-M6-rc3 Vote concludes on Thursday June 14th at 2300 hours. [ ] +1 release [ ] 0 abstain [ ] -1 Don't ship...provide reason
[jira] Updated: (GERONIMO-3159) J2G documentation
[ https://issues.apache.org/jira/browse/GERONIMO-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3159: Attachment: geronimo-3159.patch Removed the old word document from the structure, created a new readme.txt that is included in deployable package, as well as modified the existing readme.txt with build instructions. J2G documentation - Key: GERONIMO-3159 URL: https://issues.apache.org/jira/browse/GERONIMO-3159 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Reporter: Paul McMahan Assignee: Erik B. Craig Priority: Minor Attachments: geronimo-3159.patch The J2G donation (GERONIMO-2743) contained some documentation. But that documentation had IBM Confidential footer. Need to secure new documentation from the contributor that does not contain the footer or get permission to remove the footer. Once the documentation has been secured it should be added to the J2G package and maybe also added to the wiki. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3159) J2G documentation
[ https://issues.apache.org/jira/browse/GERONIMO-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3159: Patch Info: [Patch Available] J2G documentation - Key: GERONIMO-3159 URL: https://issues.apache.org/jira/browse/GERONIMO-3159 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Reporter: Paul McMahan Assignee: Erik B. Craig Priority: Minor Attachments: geronimo-3159.patch The J2G donation (GERONIMO-2743) contained some documentation. But that documentation had IBM Confidential footer. Need to secure new documentation from the contributor that does not contain the footer or get permission to remove the footer. Once the documentation has been secured it should be added to the J2G package and maybe also added to the wiki. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Release specs for El, J2EE Management, WS-Metadata - rc2
Please review the specifications located at http://people.apache.org/~prasad/specs_rc2 The only changes that were made to the binaries that passed a vote over the past weekend was to add the scm section to the pom.xml. I have dropped jsp specs from the vote now. ws-metadata will have a 3 digit version number (1.1.1) because 1.1.0 was already released some 6 weeks ago. This is a minor update to the released version. Voting concludes on Saturday, June 16th at 1700 ET. Cheers Prasad
Re: [VOTE] 2.0-M6 (rc3)
+1 Cheers Prasad On 6/11/07, Matt Hogstrom [EMAIL PROTECTED] wrote: I think I've narrowed the problem on the rebuild. When building from the top-level it seems we pick up more cars than we want. If I build local in the assemblies dir then things seem to be scoped correctly. Something odd with Maven and / or how were using it. The binaries are uploading now so please take a peek. http://people.apache.org/~hogstrom/2.0-M6-rc3 Vote concludes on Thursday June 14th at 2300 hours. [ ] +1 release [ ] 0 abstain [ ] -1 Don't ship...provide reason
Re: [VOTE] Release specs for El, J2EE Management, WS-Metadata - rc2
do none of the spec releases get md5 sums nor pgp signatures? Filip Prasad Kashyap wrote: Please review the specifications located at http://people.apache.org/~prasad/specs_rc2 The only changes that were made to the binaries that passed a vote over the past weekend was to add the scm section to the pom.xml. I have dropped jsp specs from the vote now. ws-metadata will have a 3 digit version number (1.1.1) because 1.1.0 was already released some 6 weeks ago. This is a minor update to the released version. Voting concludes on Saturday, June 16th at 1700 ET. Cheers Prasad
Re: [VOTE] Release specs for El, J2EE Management, WS-Metadata - rc2
Hi Filip, Like Ragu, its in there. Looks like Prasad provided the tar ball of the artifacts as they'd reside in the Maven Repo: geronimo-j2ee-management_1.1_spec-1.0/ geronimo-j2ee-management_1.1_spec-1.0/org/ geronimo-j2ee-management_1.1_spec-1.0/org/apache/ geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/ geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/ geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/ geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0-javadoc.jar geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0-javadoc.jar.asc geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0-javadoc.jar.md5 geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0-javadoc.jar.sha1 geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0-sources.jar geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0-sources.jar.asc geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0-sources.jar.md5 geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0-sources.jar.sha1 geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0.jar geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0.jar.asc geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0.jar.md5 geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0.jar.sha1 geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0.pom geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0.pom.asc geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0.pom.md5 geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/1.0/geronimo-j2ee- management_1.1_spec-1.0.pom.sha1 geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/maven-metadata.xml geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/maven-metadata.xml.md5 geronimo-j2ee-management_1.1_spec-1.0/org/apache/geronimo/specs/ geronimo-j2ee-management_1.1_spec/maven-metadata.xml.sha1 If you download the tar ball and unpack it this is what you'll see. I even verified the .asc files and it really is Prasad :) On Jun 13, 2007, at 6:28 PM, Filip Hanik - Dev Lists wrote: do none of the spec releases get md5 sums nor pgp signatures? Filip Prasad Kashyap wrote: Please review the specifications located at http://people.apache.org/~prasad/specs_rc2 The only changes that were made to the binaries that passed a vote over the past weekend was to add the scm section to the pom.xml. I have dropped jsp specs from the vote now. ws-metadata will have a 3 digit version number (1.1.1) because 1.1.0 was already released some 6 weeks ago. This is a minor update to the released version. Voting concludes on Saturday, June 16th at 1700 ET. Cheers Prasad
[STATUS] (geronimo) Wed Jun 13 23:48:53 2007
APACHE GERONIMO STATUS: -*-text-*- Last modified at [$Date: 2007-05-31 12:21:22 -0400 (Thu, 31 May 2007) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/geronimo/server/trunk/STATUS Upcoming Releases: Geronimo 2.0 -- geronimo/server/trunk/ Release Manager: Matt Hogstrom Estimated Date: Q2 2007 Geronimo 1.2 -- geronimo/server/branches/1.2 Release Manager: Dain Sundstrom and Alan Cabrera Estimated Date: June 2007 Status: The codebase is ready to ship, but there is one bug the community has determined to be a blocker that must be fixed before shipping. RELEASE HISTORY: 2007-03-04 Geronimo 2.0-M3 2007-01-30 Geronimo 2.0-M2 2006-12-22 Geronimo 2.0-M1 2006-12-16 Geronimo 1.2-beta 2006-09-18 Geronimo 1.1.1 2006-06-26 Geronimo 1.1 2006-01-05 Geronimo 1.0 2005-10-04 Geronimo 1.0 milestone 5 2005-08-10 Geronimo 1.0 milestone 4 2004-11-11 Geronimo 1.0 milestone 3 2004-09-09 Geronimo 1.0 milestone 2 2004-04-29 Geronimo 1.0 milestone 1 If you're a contributor looking for something to do: * Review the documentation and suggest improvements * Review the bug list and suggest fixes or report reproducibility * Report bugs yourself
Deploying maven2 module as maven1 module
Hi, Does anybody here have experience with deploying a maven2 module as a maven1 module? For example, I would like to deploy the geronimo-annotation_1.0_spec module as a maven1 module. This is for Axis2 project to get them to use our annotation definitions instead of their partial definitions. Axis2 can be built with maven1 or maven2 but I think maven1 is preferred right now. Thanks, Jarek
Re: Deploying maven2 module as maven1 module
Use the maven-one-plugin: http://maven.apache.org/plugins/maven-one-plugin/ --jason On Jun 13, 2007, at 9:58 PM, Jarek Gawor wrote: Hi, Does anybody here have experience with deploying a maven2 module as a maven1 module? For example, I would like to deploy the geronimo-annotation_1.0_spec module as a maven1 module. This is for Axis2 project to get them to use our annotation definitions instead of their partial definitions. Axis2 can be built with maven1 or maven2 but I think maven1 is preferred right now. Thanks, Jarek
