Re: [VOTE] Release ServiceMix 3.2
+1 : everything looks ok and examples can be deployed/run P.S. Currently, the CXF-BC interferes with the HTTP BC if you use the same HTTP port number. Wouldn't it be better to change the port number on the CXF WSDL first example for now to avoid this problem -- e.g. when installing the bridge example as well as the CXF WSDL first example? Freeman Fang wrote: Hi All, I have uploaded a version of ServiceMix 3.2 for you to review. See http://cwiki.apache.org/confluence/display/SM/ServiceMix+3.2 for all the links and release notes. [ ] +1 Release ServiceMix 3.2 [ ] ± 0 [ ] -1 Do not release ServiceMix 3.2 Cheers Freeman
Re: [VOTE] Release ServiceMix 3.2
Change the port used in cxf-wsdl-first sample from 8192 to 8092, only affected module samples/cxf-wsdl-first/ and distribution is re-uploaded. Best Regards Freeman Freeman Fang wrote: Hi Gert, Right, I can change to another port. Best Regards Freeman Gert Vanthienen wrote: +1 : everything looks ok and examples can be deployed/run P.S. Currently, the CXF-BC interferes with the HTTP BC if you use the same HTTP port number. Wouldn't it be better to change the port number on the CXF WSDL first example for now to avoid this problem -- e.g. when installing the bridge example as well as the CXF WSDL first example? Freeman Fang wrote: Hi All, I have uploaded a version of ServiceMix 3.2 for you to review. See http://cwiki.apache.org/confluence/display/SM/ServiceMix+3.2 for all the links and release notes. [ ] +1 Release ServiceMix 3.2 [ ] ± 0 [ ] -1 Do not release ServiceMix 3.2 Cheers Freeman
[jira] Updated: (GERONIMO-2880) TransportDisposedIOException occurs when trying to close ActiveMQ queue
[ https://issues.apache.org/jira/browse/GERONIMO-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-2880: -- Affects Version/s: 2.1 Assignee: Vamsavardhana Reddy TransportDisposedIOException occurs when trying to close ActiveMQ queue --- Key: GERONIMO-2880 URL: https://issues.apache.org/jira/browse/GERONIMO-2880 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.0.x, 2.1 Environment: Windows XP SP2 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Critical Fix For: 2.0.x, 2.1 Attachments: AMQ_NoTxDatasource.patch I have discovered some problems with queues while running unittest in our own J2EE app. After sending a message on a queue, when we try to call the close() method on the queue, we get the following exception: org.apache.activemq.transport.TransportDisposedIOException: Peer (vm://localhost#69) disposed. where the number after localhost is different every time. We do not experience this problem with topics. We are using ActiveMQ as part of an embedded configuration with Geronimo. I've done some debugging and the problem occurs at this line in the ActiveMQMessageProducer.close() method: this.session.asyncSendPacket(info.createRemoveCommand()); The queue itself is disposed properly in the dispose() method that is called in the line before, but this sending of the asynchronous packet fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2880) TransportDisposedIOException occurs when trying to close ActiveMQ queue
[ https://issues.apache.org/jira/browse/GERONIMO-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538426 ] Vamsavardhana Reddy commented on GERONIMO-2880: --- Completed: At revision: 589532 o Thanks to Anish for providing the patch o Use a non XA datasource for activemq persistence **: This commit can use a review. TransportDisposedIOException occurs when trying to close ActiveMQ queue --- Key: GERONIMO-2880 URL: https://issues.apache.org/jira/browse/GERONIMO-2880 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.0.x, 2.1 Environment: Windows XP SP2 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Critical Fix For: 2.0.x, 2.1 Attachments: AMQ_NoTxDatasource.patch I have discovered some problems with queues while running unittest in our own J2EE app. After sending a message on a queue, when we try to call the close() method on the queue, we get the following exception: org.apache.activemq.transport.TransportDisposedIOException: Peer (vm://localhost#69) disposed. where the number after localhost is different every time. We do not experience this problem with topics. We are using ActiveMQ as part of an embedded configuration with Geronimo. I've done some debugging and the problem occurs at this line in the ActiveMQMessageProducer.close() method: this.session.asyncSendPacket(info.createRemoveCommand()); The queue itself is disposed properly in the dispose() method that is called in the line before, but this sending of the asynchronous packet fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Promoting GShell to a real subproject
Thanx Kevan. +1. Cheers Prasad On 10/26/07, Kevan Miller [EMAIL PROTECTED] wrote: On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
On Oct 28, 2007, at 3:22 PM, Donald Woods wrote: Any thoughts on setting up automated builds of Samples at least once a week? That would be helpful. Now that we have catalog support in car-maven- plugin we could also automatically update the online plugins catalog as well. This would require some coordination around building server/ trunk and samples/trunk.Basically: 1.) build server/trunk 2.) build samples/trunk 3.) run a script on ~/.m2/repository/geronimo-plugins.xml to remove references to the local repo 4.) svn commit site/trunk/docs/plugins/geronimo-x.x/geronimo- plugins.xml I can help with a perl script for #3 if someone more savvy with build automation wants to look further into this. One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Best wishes, Paul
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
On 10/28/07, Donald Woods [EMAIL PROTECTED] wrote: Also, maybe a samples project under the server testsuite dir that verifies each sample can be installed and functions? +1 to tests but I would rather put them somewhere with the samples. Jarek
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Yes, definitely. That was the goal for 2.0 samples at least. The wiki documentation should be up to date (expect the artifact version) and all the code in wiki should be in the samples svn. If anything, I would like to remove the attached sample .zip files from the wiki and instead direct the users to checkout the sample code from svn. Also, I think we should release samples at the same time (or close to) when we release Geronimo. Jarek
Restructuring build for flexible server
I spend most of the weekend trying to restructure trunk to reflect the new flexible server and I should tell you, it has been one shitty job much akin to untangling the knots of Medusa's hair. To begin with I wanted to build just the modules and configs (along with the necessary buildsupport and maven-plugins artifacts) that go into a framework assembly.I believe that if we effectively want to restructure the build tree to reflect the flexible server, then we should be able to build just the framework artifacts ONLY. The framework artifacts should not have a dependency on plugins artifacts because they are optionally choosen to build an assembly of choice. Also, if our strategic vision is to break down the tree into smaller projects for framework, plugins etc, this we should break this cyclical dependency too. See Jason's response here - http://www.nabble.com/forum/ViewPost.jtp?post=12460948framed=yskin=134 First hitch - Our framework assembly contains jee-specs car. This car has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is in a incorrect dependency which we don't need at this point or it might be truly needed here so that it gets in the classpath for later use. I commented this dependency out and proceeded to build jee-specs car. I strongly tend to believe that this myfaces dep is wrongly placed here. If it is really req'd then we have a bigger problem of fixing our classloader scheme. Second hitch - Trying to build framework assembly's server-security-config car requires you to build j2ee-deployer. If you wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars which in turn has a dependency on webservices. Slowly we are building more and more plugins which are optional artifacts. If we really have to build a lot of plugins just to build the framework artifacts, then there is little point in restructuring the build tree now or breaking the tree later. I have checked in the restructured code under sandbox/restructure. I have been able to do a bootstrap build thus far. To build this on your machine, take the following steps 1) begin with a good local repository for your trunk build 2) delete applications, assemblies, modules, geronimo, configs, plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your local repo. 3) svn co https://svn.apache.org/repos/asf/geronimo/sandbox/restructure 4) mvn -o -Dstage=bootstrap 5) mvn -o -Dstage=assembly You should fail here Cheers Prasad
[jira] Created: (GERONIMO-3561) monitoring plugin: mrc-server needs to be a plugin in order to pull in a database
monitoring plugin: mrc-server needs to be a plugin in order to pull in a database -- Key: GERONIMO-3561 URL: https://issues.apache.org/jira/browse/GERONIMO-3561 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Attachments: geronimo-3561.patch the mrc-server should be packaged in a CAR so that it can install on a minimal assembly. Also, as suggested by Paul Mcmahan and David Jencks, the datasources used should be a plugin itself so that we are not bound to just use the default derby DB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3561) monitoring plugin: mrc-server needs to be a plugin in order to pull in a database
[ https://issues.apache.org/jira/browse/GERONIMO-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3561: --- Attachment: geronimo-3561.patch monitoring plugin: mrc-server needs to be a plugin in order to pull in a database -- Key: GERONIMO-3561 URL: https://issues.apache.org/jira/browse/GERONIMO-3561 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Attachments: geronimo-3561.patch the mrc-server should be packaged in a CAR so that it can install on a minimal assembly. Also, as suggested by Paul Mcmahan and David Jencks, the datasources used should be a plugin itself so that we are not bound to just use the default derby DB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
J2G future positioning
Hi, Does anyone have any thoughts as to how we'll position the J2G plugin in the future ?? I understand now that in its initial iteration that it is narrowly scoped to work for JBoss specific migrations only (thus the JBoss in the name). However, it seems if we want to eventually enhance it as a more generic tool for migrating multiple applications to Geronimo (which I would hope we would), it might be a good time now to reconsider a more generic and/or appropriate name. Any thoughts ?? -- Thanks, Tim McConnell
[jira] Created: (SM-1119) Encoding problem in text returned by HTTP-SU
Encoding problem in text returned by HTTP-SU Key: SM-1119 URL: https://issues.apache.org/activemq/browse/SM-1119 Project: ServiceMix Issue Type: Bug Components: servicemix-core, servicemix-http, servicemix-jsr181 Affects Versions: 3.1.2, 3.1.1, 3.1 Environment: This issue can be reproduced on Windows XP Pro and Red Hat Linux. Reporter: Philip Webster Attachments: multimatch-search.zip It looks as though there is an encoding problem at the point after the results are returned from the JSR181 service unit. The issue can be reproduced on 3.1, 3.1.1, 3.1.2 and the October 25th snapshot of 3.2 As discussed on this thread: http://www.nabble.com/Encoding-problem-in-text-returned-by-HTTP-SU-tf4676140s12049r3.html The attached service usints and service assembly can be used to reproduce the issue. Use the following input against http://localhost:8492/MultiMatchSearch/ soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:sear=http://eir.multimatch.org/search; soapenv:Header/ soapenv:Body sear:doSearchRequest query searchTriples searchTermsCharles Perrault/searchTerms searchFieldsTitle/searchFields searchOperators~/searchOperators /searchTriples queryLanguageSPANISH/queryLanguage resultLanguagesENGLISH/resultLanguages metadataSchemanonCached/metadataSchema fieldsmetadata/fields contentTypesRequested contentTypeTEXT/contentType startResults0/startResults numberOfResults1/numberOfResults /contentTypesRequested /query returnFullObjectsfalse/returnFullObjects /sear:doSearchRequest /soapenv:Body /soapenv:Envelope The result is: soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Body ns2:doSearchResponse xmlns:ns2=http://eir.multimatch.org/search; results textResults identifierurn://org.multimatch/search/result/1193668323010/identifier TitleMeñiquÃn Charles Perrault ; traducción de Teodoro Baró/Title sourceUrlhttp://www.google.com//sourceUrl /textResults /results /ns2:doSearchResponse /soapenv:Body /soapenv:Envelope The result should be: soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Body ns2:doSearchResponse xmlns:ns2=http://eir.multimatch.org/search; results textResults identifierurn://org.multimatch/search/result/1193668323010/identifier TitleMeñiquín Charles Perrault ; traducción de Teodoro Baró/Title sourceUrlhttp://www.google.com//sourceUrl /textResults /results /ns2:doSearchResponse /soapenv:Body /soapenv:Envelope -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: J2G future positioning
I worry that giving it a more generic name before the tool can actually be applied in a generic way might confuse some users. Although, since it's being moved at the moment, it is the most convenient time to make such a change. I think adding some extra emphasis in the documentation that it's really only meant to be used on JBoss apps until further functionality is added might be sufficient to stem user confusion. What about a simple Geronimo Migration Tool name? ~Jason Warner On 10/29/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi, Does anyone have any thoughts as to how we'll position the J2G plugin in the future ?? I understand now that in its initial iteration that it is narrowly scoped to work for JBoss specific migrations only (thus the JBoss in the name). However, it seems if we want to eventually enhance it as a more generic tool for migrating multiple applications to Geronimo (which I would hope we would), it might be a good time now to reconsider a more generic and/or appropriate name. Any thoughts ?? -- Thanks, Tim McConnell
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
While a part of me seems to agree with you that we should remove the zip file from the samples' wiki pages, a greater part of me feels that we may be forcing some our users to now get SVN. A user who just downloads and installs from a binary server will have no need for svn. But just to get to the samples, he now has to get SVN. Then he has to get maven to play with the samples. So we are making him jump thro' many hoops just to see our prized samples. Hmm.. Cheers Prasad On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote: On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Yes, definitely. That was the goal for 2.0 samples at least. The wiki documentation should be up to date (expect the artifact version) and all the code in wiki should be in the samples svn. If anything, I would like to remove the attached sample .zip files from the wiki and instead direct the users to checkout the sample code from svn. Also, I think we should release samples at the same time (or close to) when we release Geronimo. Jarek
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
Paul, I can help you do this. Cheers Prasad On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: On Oct 28, 2007, at 3:22 PM, Donald Woods wrote: Any thoughts on setting up automated builds of Samples at least once a week? That would be helpful. Now that we have catalog support in car-maven- plugin we could also automatically update the online plugins catalog as well. This would require some coordination around building server/ trunk and samples/trunk.Basically: 1.) build server/trunk 2.) build samples/trunk 3.) run a script on ~/.m2/repository/geronimo-plugins.xml to remove references to the local repo 4.) svn commit site/trunk/docs/plugins/geronimo-x.x/geronimo- plugins.xml I can help with a perl script for #3 if someone more savvy with build automation wants to look further into this. One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Best wishes, Paul
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
Prasad, I have put some thought into this myself and agree with you. It would be too much of a hassle for users, I think, if they have to download subversion and maven along with the sample app, and THEN compile it before attempting to deploy it. Probably the best thing would be to have 'releases' or snapshots of the sample apps up on the wiki, along with the source being in the subversion repo. -Erik Prasad Kashyap wrote: While a part of me seems to agree with you that we should remove the zip file from the samples' wiki pages, a greater part of me feels that we may be forcing some our users to now get SVN. A user who just downloads and installs from a binary server will have no need for svn. But just to get to the samples, he now has to get SVN. Then he has to get maven to play with the samples. So we are making him jump thro' many hoops just to see our prized samples. Hmm.. Cheers Prasad On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote: On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Yes, definitely. That was the goal for 2.0 samples at least. The wiki documentation should be up to date (expect the artifact version) and all the code in wiki should be in the samples svn. If anything, I would like to remove the attached sample .zip files from the wiki and instead direct the users to checkout the sample code from svn. Also, I think we should release samples at the same time (or close to) when we release Geronimo. Jarek
Re: Restructuring build for flexible server
Good work!! A couple comments inline. On Oct 29, 2007, at 7:48 AM, Prasad Kashyap wrote: I spend most of the weekend trying to restructure trunk to reflect the new flexible server and I should tell you, it has been one shitty job much akin to untangling the knots of Medusa's hair. To begin with I wanted to build just the modules and configs (along with the necessary buildsupport and maven-plugins artifacts) that go into a framework assembly.I believe that if we effectively want to restructure the build tree to reflect the flexible server, then we should be able to build just the framework artifacts ONLY. The framework artifacts should not have a dependency on plugins artifacts because they are optionally choosen to build an assembly of choice. Also, if our strategic vision is to break down the tree into smaller projects for framework, plugins etc, this we should break this cyclical dependency too. See Jason's response here - http://www.nabble.com/forum/ViewPost.jtp? post=12460948framed=yskin=134 First hitch - Our framework assembly contains jee-specs car. This car has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is in a incorrect dependency which we don't need at this point or it might be truly needed here so that it gets in the classpath for later use. I commented this dependency out and proceeded to build jee-specs car. I strongly tend to believe that this myfaces dep is wrongly placed here. If it is really req'd then we have a bigger problem of fixing our classloader scheme. I don't understand the problem here and what you want to do. We have several other specs (from axis and jstl) that we don't build that are included in jee-specs. Is the jsf api different from these in some way? Do you want to remove the jsf spec from jee-specs or the jee- specs from the framework assembly? I remember having a lot of classloader problems trying to get stuff to run and pass the tck before we came up with the jee-specs module, but it might be possible to split it up and put the jars with the implementations that use them. I think this will be difficult so I'd like to postpone that. Second hitch - Trying to build framework assembly's server-security-config car requires you to build j2ee-deployer. If you wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars which in turn has a dependency on webservices. Slowly we are building more and more plugins which are optional artifacts. This is definitely a problem. I think we can solve it with a security-deployer config that has the security related gbeans from j2ee-deployer in it. What do you think? If we really have to build a lot of plugins just to build the framework artifacts, then there is little point in restructuring the build tree now or breaking the tree later. I have checked in the restructured code under sandbox/restructure. I have been able to do a bootstrap build thus far. To build this on your machine, take the following steps 1) begin with a good local repository for your trunk build 2) delete applications, assemblies, modules, geronimo, configs, plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your local repo. 3) svn co https://svn.apache.org/repos/asf/geronimo/sandbox/ restructure 4) mvn -o -Dstage=bootstrap 5) mvn -o -Dstage=assembly You should fail here Thanks! david jencks Cheers Prasad
[jira] Created: (GSHELL-37) New Command: Clear
New Command: Clear -- Key: GSHELL-37 URL: https://issues.apache.org/jira/browse/GSHELL-37 Project: GShell Issue Type: New Feature Security Level: public (Regular issues) Components: Commands Reporter: Jason Warner Assignee: Jason Warner Implement the ability to use the clear command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
basic security review
A few security problems were discovered in Geronimo in the last few months and weeks. Most of them were Geronimo-specific except one. Therefore, I think we should spend a little bit of our time to review our code and check for potential security problems. As the first step, I think we should identify components that make security decisions (e.g. LoginModules) or enable access to server management and control (e.g. MEJB) or any other components that might be important for sever security. Once we have a few components identified we can start the review. Besides finding and fixing the potential security problems during the review we must also ensure that we have decent tests for these components that cover a range of inputs. For each problem that we do discover, we must write a test case to make sure it never happens again. Basically, a problem is not fully addressed until we have a test for it. For now, I created the following page where we can keep track of the components and the review: http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review Feel free to update it in any way. Opinions? Ideas? Thoughts? Jarek
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
On Oct 27, 2007, at 11:32 AM, David Jencks wrote: The admin console needs to be lightweight and portable so it is based on Pluto. The Jetspeed MBE (as currently designed) would interfere with the deployment of admin console extensions. Adding something to the Geronimo plan to activate the Jetspeed MBE instead of just looking for a WEB-INF/portlet.xml sounds like a reasonable solution. Let's pursue that approach. +1 as I see many situations where the Pluto Admin Console will still be used even when Jetspeed or Liferay are installed. I haven't looked into exactly how the admin console plugins get added to the admin console but if they are geronimo plugins they have already gone through the deployment process and there is no chance for the jetspeed MBE to see them as the deployment machinery is not activated at all when a plugin is installed. I see your point. Limiting portal apps to installation via plugin would offer an advantage that developers can pick the appropriate MBEs at build time, giving them us (the MBE provider) fine grained control over every step in the deployment process. While using MBEs has proven to be a very successful approach for deploying services and enterprise apps in Geronimo I am concerned that the lack of any standardization or a specification for deploying portal apps could make this difficult and fragile in the case of portlets. My observation has been that deployment into most portals (Liferay, Pluto, uPortal, and even Jetspeed itself) is based on the concept that the developer creates a standard WAR and uses the Portal's runtime or build-time utility for preprocessing it. Then the portal deploys the preprocessed WAR using the app server's standard deployment mechanism, or relies on the end user to do this. Can/should deployment of portlet into Geronimo be an extension of that process? I have been inclined to follow that approach so far but there may be disadvantages I haven't thought of. BTW, I have started using the term console extension instead of console plugin because adding portlets to the admin console doesn't currently require them to be packaged as plugins.A console extension can be installed as a plugin or it could be deployed like any other ordinary WAR. I hope most developers will offer their console extensions as plugins because they are easier for end users to browse and install. But I think the latter option (deploying console extensions as a WAR) will be important to developers that don't want to create plugins for reasons such as the reliance on maven to build them, the sensitivity of plugins to Geronimo server versions, etc. Best wishes, Paul
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
Binary files in wiki and source in svn? That works for me. Jarek On 10/29/07, Erik B. Craig [EMAIL PROTECTED] wrote: Prasad, I have put some thought into this myself and agree with you. It would be too much of a hassle for users, I think, if they have to download subversion and maven along with the sample app, and THEN compile it before attempting to deploy it. Probably the best thing would be to have 'releases' or snapshots of the sample apps up on the wiki, along with the source being in the subversion repo. -Erik Prasad Kashyap wrote: While a part of me seems to agree with you that we should remove the zip file from the samples' wiki pages, a greater part of me feels that we may be forcing some our users to now get SVN. A user who just downloads and installs from a binary server will have no need for svn. But just to get to the samples, he now has to get SVN. Then he has to get maven to play with the samples. So we are making him jump thro' many hoops just to see our prized samples. Hmm.. Cheers Prasad On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote: On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Yes, definitely. That was the goal for 2.0 samples at least. The wiki documentation should be up to date (expect the artifact version) and all the code in wiki should be in the samples svn. If anything, I would like to remove the attached sample .zip files from the wiki and instead direct the users to checkout the sample code from svn. Also, I think we should release samples at the same time (or close to) when we release Geronimo. Jarek
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
When I mentioned parity between svn and the wiki I really meant to stress the same stuff showing both locations, which I think Jarek's suggestion would help achieve.Another idea would be to build and deploy the samples using maven. Then we could point the wiki page at the maven repo for both the compiled binary and for the source.zip (which is automatically created by maven). Best wishes, Paul On Oct 29, 2007, at 2:12 PM, Jarek Gawor wrote: Binary files in wiki and source in svn? That works for me. Jarek On 10/29/07, Erik B. Craig [EMAIL PROTECTED] wrote: Prasad, I have put some thought into this myself and agree with you. It would be too much of a hassle for users, I think, if they have to download subversion and maven along with the sample app, and THEN compile it before attempting to deploy it. Probably the best thing would be to have 'releases' or snapshots of the sample apps up on the wiki, along with the source being in the subversion repo. -Erik Prasad Kashyap wrote: While a part of me seems to agree with you that we should remove the zip file from the samples' wiki pages, a greater part of me feels that we may be forcing some our users to now get SVN. A user who just downloads and installs from a binary server will have no need for svn. But just to get to the samples, he now has to get SVN. Then he has to get maven to play with the samples. So we are making him jump thro' many hoops just to see our prized samples. Hmm.. Cheers Prasad On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote: On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Yes, definitely. That was the goal for 2.0 samples at least. The wiki documentation should be up to date (expect the artifact version) and all the code in wiki should be in the samples svn. If anything, I would like to remove the attached sample .zip files from the wiki and instead direct the users to checkout the sample code from svn. Also, I think we should release samples at the same time (or close to) when we release Geronimo. Jarek
Re: Icons in web console disappeared
Icon support in the new admin console is not implemented yet. The early thoughts on this were to bundle the icons for the base console and the various extensions in their respective WAR files and pass the location of the icons to the portal driver thru the AdminConsoleExtensionGBean. I created https://issues.apache.org/jira/browse/GERONIMO-3562 Best wishes, Paul On Oct 27, 2007, at 1:38 PM, Jacek Laskowski wrote: Hi, What happened to the nice-looking icons next to administration menus in webconsole of 2.1-SNAPSHOT? They're in 2.0.2. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Commented: (GERONIMO-3534) allowHosts attribute unavailable in geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMO-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538560 ] Jarek Gawor commented on GERONIMO-3534: --- The allowHosts option is not really supported by OpenEJB right now. I opened https://issues.apache.org/jira/browse/OPENEJB-711. Once that bug is fixed, we should be able to provide a corresponding fix in Geronimo. allowHosts attribute unavailable in geronimo 2.0.1 -- Key: GERONIMO-3534 URL: https://issues.apache.org/jira/browse/GERONIMO-3534 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.0.1 Environment: Windows XP, geronimo-tomcat6-jee5-2.0.1 Reporter: Ashish Jain I am using a standalone client running on remote machine to access EJB deployed on the server. By using the allowHosts attribute with AG 1.2 for example gbean name=EJBNetworkService attribute name=host0.0.0.0/attribute attribute name=port4201/attribute attribute name=allowHosts192.168.1.2/attribute /gbean. I am able to restrict access to EJB to specific IP addresses. In AG 2.0.1 only host, port and threads attribute are allowed with EJBNetworkService gbean and allowHosts attribute is missing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3562) customizable navigator icons for admin console extensions
customizable navigator icons for admin console extensions
-
Key: GERONIMO-3562
URL: https://issues.apache.org/jira/browse/GERONIMO-3562
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: console
Affects Versions: 2.1
Reporter: Paul McMahan
The extensible admin console console should support customizable icons for the
navigator items. One way to implement this would be to enhance the gbean
definition like:
{code:xml}
gbean name=MyConsoleExtension
class=org.apache.geronimo.pluto.AdminConsoleExtensionGBean
attribute name=pageTitleApplications/My Console
Extension/attribute
attribute name=portletContext/my-console-extension/attribute
attribute name=portletList[MyPortlet]/attribute
attribute name=iconimages/myicon.png/attribute!--- new
attribute for icon --
/gbean
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Restructuring build for flexible server
Thanx David. With the latest commit to sandbox, I have all the artifacts building successfully. We have good assemblies too. Tthe groupId and artifactId of all the artifacts have essentially remained the same. The final server should now pass TCK smoketests and our testsuite. More comments inline - On 10/29/07, David Jencks [EMAIL PROTECTED] wrote: Good work!! A couple comments inline. On Oct 29, 2007, at 7:48 AM, Prasad Kashyap wrote: I spend most of the weekend trying to restructure trunk to reflect the new flexible server and I should tell you, it has been one shitty job much akin to untangling the knots of Medusa's hair. To begin with I wanted to build just the modules and configs (along with the necessary buildsupport and maven-plugins artifacts) that go into a framework assembly.I believe that if we effectively want to restructure the build tree to reflect the flexible server, then we should be able to build just the framework artifacts ONLY. The framework artifacts should not have a dependency on plugins artifacts because they are optionally choosen to build an assembly of choice. Also, if our strategic vision is to break down the tree into smaller projects for framework, plugins etc, this we should break this cyclical dependency too. See Jason's response here - http://www.nabble.com/forum/ViewPost.jtp? post=12460948framed=yskin=134 First hitch - Our framework assembly contains jee-specs car. This car has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is in a incorrect dependency which we don't need at this point or it might be truly needed here so that it gets in the classpath for later use. I commented this dependency out and proceeded to build jee-specs car. I strongly tend to believe that this myfaces dep is wrongly placed here. If it is really req'd then we have a bigger problem of fixing our classloader scheme. I don't understand the problem here and what you want to do. We have several other specs (from axis and jstl) that we don't build that are included in jee-specs. Is the jsf api different from these in some way? Do you want to remove the jsf spec from jee-specs or the jee- specs from the framework assembly? I remember having a lot of classloader problems trying to get stuff to run and pass the tck before we came up with the jee-specs module, but it might be possible to split it up and put the jars with the implementations that use them. I think this will be difficult so I'd like to postpone that. I'm sorry. I had misrepresented the problem. The j2ee-specs and it's dependencies are fine. The problem is with myfaces artifacts showing up as missing even though they are in very much present in the local repo. I learnt that this is a problem even with the current build. It seemed to be caused by an incorrect publish of the myfaces artifacts. We are fine here as long as we do a online build. Second hitch - Trying to build framework assembly's server-security-config car requires you to build j2ee-deployer. If you wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars which in turn has a dependency on webservices. Slowly we are building more and more plugins which are optional artifacts. This is definitely a problem. I think we can solve it with a security-deployer config that has the security related gbeans from j2ee-deployer in it. What do you think? The CredentialStore gbean in security-deployer config needed the j2eeDeployer during c-m-p. The gbean was all but commented out as it is. So I reduced it to a standard empty gbean and removed the j2eeDeployer in the deploymentConfig of the c-m-p. This has solved the problem. If we really have to build a lot of plugins just to build the framework artifacts, then there is little point in restructuring the build tree now or breaking the tree later. I have checked in the restructured code under sandbox/restructure. I have been able to do a bootstrap build thus far. To build this on your machine, take the following steps 1) begin with a good local repository for your trunk build 2) delete applications, assemblies, modules, geronimo, configs, plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your local repo. 3) svn co https://svn.apache.org/repos/asf/geronimo/sandbox/ restructure 4) mvn -o -Dstage=bootstrap 5) mvn -o -Dstage=assemble You should fail here I have had to add deps in the console-tomcat and console-jetty poms on a few deployers to impose build order. But for that, we now have a restructured tree. Thanks! david jencks Cheers Prasad
[jira] Resolved: (GERONIMO-3556) Monitoring client serverview should show statistics attribute names when an mbean name is clicked
[ https://issues.apache.org/jira/browse/GERONIMO-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig resolved GERONIMO-3556. - Resolution: Fixed This issue was resolved through GERONIMO-3553 and GERONIMO-3551. Monitoring client serverview should show statistics attribute names when an mbean name is clicked - Key: GERONIMO-3556 URL: https://issues.apache.org/jira/browse/GERONIMO-3556 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: monitoring Reporter: Erik B. Craig Assignee: Erik B. Craig Monitoring client serverview should show statistics attribute names when an mbean name is clicked on the right side panel -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: J2G future positioning
On 10/29/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi, Does anyone have any thoughts as to how we'll position the J2G plugin in the future ?? I understand now that in its initial iteration that it is narrowly scoped to work for JBoss specific migrations only (thus the JBoss in the name). However, it seems if we want to eventually enhance it as a more generic tool for migrating multiple applications to Geronimo (which I would hope we would), it might be a good time now to reconsider a more generic and/or appropriate name. Any thoughts ?? I think it's a good idea to call it a migration tool. We definitely should not be using the name JBoss. j2g would be ok (though i'd be in favor of a generic name). --kevan
[jira] Closed: (GERONIMODEVTOOLS-248) GEP should more elegantly catch and handle IllegalArgumentException when a Geronimo deployment plan is opened without a Geronimo server defined
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-248. -- Resolution: Fixed The IllegalArgumentException exception is now being caught and a new message created such that the user will now know that a Targeted Runtime should be specified for the web project. GEP should more elegantly catch and handle IllegalArgumentException when a Geronimo deployment plan is opened without a Geronimo server defined - Key: GERONIMODEVTOOLS-248 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-248 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 2.0.0 Reporter: Tim McConnell Assignee: Tim McConnell Priority: Minor Fix For: 2.0.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: J2G future positioning
I was trying to come up with something like that myself. I like the idea of keeping the 2. Somehow, Migrate 2 Geronimo was too obscure for me to grasp. Thanks for ending my mental struggle, Joe. ~Jason Warner On 10/29/07, Joe Bohn [EMAIL PROTECTED] wrote: Kevan Miller wrote: On 10/29/07, *Tim McConnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Does anyone have any thoughts as to how we'll position the J2G plugin in the future ?? I understand now that in its initial iteration that it is narrowly scoped to work for JBoss specific migrations only (thus the JBoss in the name). However, it seems if we want to eventually enhance it as a more generic tool for migrating multiple applications to Geronimo (which I would hope we would), it might be a good time now to reconsider a more generic and/or appropriate name. Any thoughts ?? I think it's a good idea to call it a migration tool. We definitely should not be using the name JBoss. j2g would be ok (though i'd be in favor of a generic name). I agree. What's not to like about a generic migration tool to get people on Geronimo even if the first version only works when you migrate from JBoss? :-) Personally, I'd still like to see the 2 in the name. How about M2G (Migrate to Geronimo)? The problem with something like Geronimo Migration tool or even just migration tool is that the direction isn't clear and we definitely want it to be known that we're helping you migrate to Geronimo. Joe
Re: J2G future positioning
Kevan Miller wrote: On 10/29/07, *Tim McConnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Does anyone have any thoughts as to how we'll position the J2G plugin in the future ?? I understand now that in its initial iteration that it is narrowly scoped to work for JBoss specific migrations only (thus the JBoss in the name). However, it seems if we want to eventually enhance it as a more generic tool for migrating multiple applications to Geronimo (which I would hope we would), it might be a good time now to reconsider a more generic and/or appropriate name. Any thoughts ?? I think it's a good idea to call it a migration tool. We definitely should not be using the name JBoss. j2g would be ok (though i'd be in favor of a generic name). I agree. What's not to like about a generic migration tool to get people on Geronimo even if the first version only works when you migrate from JBoss? :-) Personally, I'd still like to see the 2 in the name. How about M2G (Migrate to Geronimo)? The problem with something like Geronimo Migration tool or even just migration tool is that the direction isn't clear and we definitely want it to be known that we're helping you migrate to Geronimo. Joe
Re: J2G future positioning
I think it would be great if it can handle more than jboss to geronimo. We can have a pluggable migration framework that does most of the migration work that is needed from server A to geronimo, and allow a user to build additional plugins to plugin their server specific stuff in. For instance, a jboss plugin to have all the unique stuff that is needed for jboss to geronimo migration. Lin Jason Warner wrote: I worry that giving it a more generic name before the tool can actually be applied in a generic way might confuse some users. Although, since it's being moved at the moment, it is the most convenient time to make such a change. I think adding some extra emphasis in the documentation that it's really only meant to be used on JBoss apps until further functionality is added might be sufficient to stem user confusion. What about a simple Geronimo Migration Tool name? ~Jason Warner On 10/29/07, *Tim McConnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Does anyone have any thoughts as to how we'll position the J2G plugin in the future ?? I understand now that in its initial iteration that it is narrowly scoped to work for JBoss specific migrations only (thus the JBoss in the name). However, it seems if we want to eventually enhance it as a more generic tool for migrating multiple applications to Geronimo (which I would hope we would), it might be a good time now to reconsider a more generic and/or appropriate name. Any thoughts ?? -- Thanks, Tim McConnell
[jira] Closed: (GERONIMO-2880) TransportDisposedIOException occurs when trying to close ActiveMQ queue
[ https://issues.apache.org/jira/browse/GERONIMO-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2880. -- Resolution: Fixed This fix looks completely correct to me and I'm only embarrassed that I didn't use the right datasource in the first place. TransportDisposedIOException occurs when trying to close ActiveMQ queue --- Key: GERONIMO-2880 URL: https://issues.apache.org/jira/browse/GERONIMO-2880 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.0.x, 2.1 Environment: Windows XP SP2 Reporter: Aman Nanner Assignee: Vamsavardhana Reddy Priority: Critical Fix For: 2.0.x, 2.1 Attachments: AMQ_NoTxDatasource.patch I have discovered some problems with queues while running unittest in our own J2EE app. After sending a message on a queue, when we try to call the close() method on the queue, we get the following exception: org.apache.activemq.transport.TransportDisposedIOException: Peer (vm://localhost#69) disposed. where the number after localhost is different every time. We do not experience this problem with topics. We are using ActiveMQ as part of an embedded configuration with Geronimo. I've done some debugging and the problem occurs at this line in the ActiveMQMessageProducer.close() method: this.session.asyncSendPacket(info.createRemoveCommand()); The queue itself is disposed properly in the dispose() method that is called in the line before, but this sending of the asynchronous packet fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3563) Remove duplicate plan.xml files under configs
Remove duplicate plan.xml files under configs - Key: GERONIMO-3563 URL: https://issues.apache.org/jira/browse/GERONIMO-3563 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem, car-maven-plugin Affects Versions: 2.1 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 2.1 Under some configs, there is a plan.xml under src/plan directory and another in src/main/plan directory. The file under src/main/plan is redundant and should be removed to avoid confusion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Restructuring build for flexible server
I think we really need to find some way to break the specs into smaller pieces. Having to install all of the JEE specs just for the simple minimal web container assembly is ugly and wastes disk space. -Donald David Jencks wrote: Good work!! A couple comments inline. On Oct 29, 2007, at 7:48 AM, Prasad Kashyap wrote: I spend most of the weekend trying to restructure trunk to reflect the new flexible server and I should tell you, it has been one shitty job much akin to untangling the knots of Medusa's hair. To begin with I wanted to build just the modules and configs (along with the necessary buildsupport and maven-plugins artifacts) that go into a framework assembly.I believe that if we effectively want to restructure the build tree to reflect the flexible server, then we should be able to build just the framework artifacts ONLY. The framework artifacts should not have a dependency on plugins artifacts because they are optionally choosen to build an assembly of choice. Also, if our strategic vision is to break down the tree into smaller projects for framework, plugins etc, this we should break this cyclical dependency too. See Jason's response here - http://www.nabble.com/forum/ViewPost.jtp?post=12460948framed=yskin=134 First hitch - Our framework assembly contains jee-specs car. This car has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is in a incorrect dependency which we don't need at this point or it might be truly needed here so that it gets in the classpath for later use. I commented this dependency out and proceeded to build jee-specs car. I strongly tend to believe that this myfaces dep is wrongly placed here. If it is really req'd then we have a bigger problem of fixing our classloader scheme. I don't understand the problem here and what you want to do. We have several other specs (from axis and jstl) that we don't build that are included in jee-specs. Is the jsf api different from these in some way? Do you want to remove the jsf spec from jee-specs or the jee-specs from the framework assembly? I remember having a lot of classloader problems trying to get stuff to run and pass the tck before we came up with the jee-specs module, but it might be possible to split it up and put the jars with the implementations that use them. I think this will be difficult so I'd like to postpone that. Second hitch - Trying to build framework assembly's server-security-config car requires you to build j2ee-deployer. If you wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars which in turn has a dependency on webservices. Slowly we are building more and more plugins which are optional artifacts. This is definitely a problem. I think we can solve it with a security-deployer config that has the security related gbeans from j2ee-deployer in it. What do you think? If we really have to build a lot of plugins just to build the framework artifacts, then there is little point in restructuring the build tree now or breaking the tree later. I have checked in the restructured code under sandbox/restructure. I have been able to do a bootstrap build thus far. To build this on your machine, take the following steps 1) begin with a good local repository for your trunk build 2) delete applications, assemblies, modules, geronimo, configs, plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your local repo. 3) svn co https://svn.apache.org/repos/asf/geronimo/sandbox/restructure 4) mvn -o -Dstage=bootstrap 5) mvn -o -Dstage=assembly You should fail here Thanks! david jencks Cheers Prasad smime.p7s Description: S/MIME Cryptographic Signature
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
Then why not make this a real release, with a bin and src zip/tar like we do for the server? -Donald Prasad Kashyap wrote: While a part of me seems to agree with you that we should remove the zip file from the samples' wiki pages, a greater part of me feels that we may be forcing some our users to now get SVN. A user who just downloads and installs from a binary server will have no need for svn. But just to get to the samples, he now has to get SVN. Then he has to get maven to play with the samples. So we are making him jump thro' many hoops just to see our prized samples. Hmm.. Cheers Prasad On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote: On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Yes, definitely. That was the goal for 2.0 samples at least. The wiki documentation should be up to date (expect the artifact version) and all the code in wiki should be in the samples svn. If anything, I would like to remove the attached sample .zip files from the wiki and instead direct the users to checkout the sample code from svn. Also, I think we should release samples at the same time (or close to) when we release Geronimo. Jarek smime.p7s Description: S/MIME Cryptographic Signature
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
+1 to that. If we released it, then we could point it to the published binaries. Cheers Prasad On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: When I mentioned parity between svn and the wiki I really meant to stress the same stuff showing both locations, which I think Jarek's suggestion would help achieve.Another idea would be to build and deploy the samples using maven. Then we could point the wiki page at the maven repo for both the compiled binary and for the source.zip (which is automatically created by maven). Best wishes, Paul On Oct 29, 2007, at 2:12 PM, Jarek Gawor wrote: Binary files in wiki and source in svn? That works for me. Jarek On 10/29/07, Erik B. Craig [EMAIL PROTECTED] wrote: Prasad, I have put some thought into this myself and agree with you. It would be too much of a hassle for users, I think, if they have to download subversion and maven along with the sample app, and THEN compile it before attempting to deploy it. Probably the best thing would be to have 'releases' or snapshots of the sample apps up on the wiki, along with the source being in the subversion repo. -Erik Prasad Kashyap wrote: While a part of me seems to agree with you that we should remove the zip file from the samples' wiki pages, a greater part of me feels that we may be forcing some our users to now get SVN. A user who just downloads and installs from a binary server will have no need for svn. But just to get to the samples, he now has to get SVN. Then he has to get maven to play with the samples. So we are making him jump thro' many hoops just to see our prized samples. Hmm.. Cheers Prasad On 10/29/07, Jarek Gawor [EMAIL PROTECTED] wrote: On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Yes, definitely. That was the goal for 2.0 samples at least. The wiki documentation should be up to date (expect the artifact version) and all the code in wiki should be in the samples svn. If anything, I would like to remove the attached sample .zip files from the wiki and instead direct the users to checkout the sample code from svn. Also, I think we should release samples at the same time (or close to) when we release Geronimo. Jarek
Re: J2G future positioning
I like a generic Migrator package name under devtools, so it leaves open the possibility for other app servers to Geronimo and to upgrade/migrate from previous Geronimo releases if we make major changes. -Donald Kevan Miller wrote: On 10/29/07, *Tim McConnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Does anyone have any thoughts as to how we'll position the J2G plugin in the future ?? I understand now that in its initial iteration that it is narrowly scoped to work for JBoss specific migrations only (thus the JBoss in the name). However, it seems if we want to eventually enhance it as a more generic tool for migrating multiple applications to Geronimo (which I would hope we would), it might be a good time now to reconsider a more generic and/or appropriate name. Any thoughts ?? I think it's a good idea to call it a migration tool. We definitely should not be using the name JBoss. j2g would be ok (though i'd be in favor of a generic name). --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: deploying snapshots of the samples to a new location in m2-snapshot-repo
+1 to removing all zips from the Wiki and releasing the samples with (or very quickly) after the server. -Donald Jarek Gawor wrote: On 10/29/07, Paul McMahan [EMAIL PROTECTED] wrote: One other question -- should we try to have parity between what's in samples/trunk and what's in the samples section of the wiki? Are there barriers, technical or otherwise, that make this difficult? http://cwiki.apache.org/GMOxSAMPLES/index.html http://svn.apache.org/repos/asf/geronimo/samples/trunk/ Yes, definitely. That was the goal for 2.0 samples at least. The wiki documentation should be up to date (expect the artifact version) and all the code in wiki should be in the samples svn. If anything, I would like to remove the attached sample .zip files from the wiki and instead direct the users to checkout the sample code from svn. Also, I think we should release samples at the same time (or close to) when we release Geronimo. Jarek smime.p7s Description: S/MIME Cryptographic Signature
[jira] Commented: (GERONIMO-3561) monitoring plugin: mrc-server needs to be a plugin in order to pull in a database
[ https://issues.apache.org/jira/browse/GERONIMO-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538642 ] Anita Kulshreshtha commented on GERONIMO-3561: -- Viet and Erik, Thanks for submitting numerous patches. I played around with the version of the plugin in the sandbox and peeked at the code. Here are my biggest concerns: 1. The EJBs (MasterRemoteControl) should not be managing any threads. The specs do not allow this. 2. In a realistic environment the plugin (mrc-server) will NEVER be loaded in the same jvm as the server being monitored. It can reside on the same machine and act as a helper for the monitoring console (aka client in the sandbox). Could you please clarify where these components will be loaded and how they will authenticate and work together? monitoring plugin: mrc-server needs to be a plugin in order to pull in a database -- Key: GERONIMO-3561 URL: https://issues.apache.org/jira/browse/GERONIMO-3561 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen Attachments: geronimo-3561.patch the mrc-server should be packaged in a CAR so that it can install on a minimal assembly. Also, as suggested by Paul Mcmahan and David Jencks, the datasources used should be a plugin itself so that we are not bound to just use the default derby DB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3563) Remove duplicate plan.xml files under configs
[ https://issues.apache.org/jira/browse/GERONIMO-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538643 ] Vamsavardhana Reddy commented on GERONIMO-3563: --- Rev 589918: o Removed the trivial ones where the plan.xml under src/plan is not significantly different from the one under src/main/plan except for some formatting etc. Rev 589923: o Somehow mejb config has only one plan.xml file and it is under src/main/plan. This plan file deleted accidentally in rev 589918 has been restored in rev 589923. Remove duplicate plan.xml files under configs - Key: GERONIMO-3563 URL: https://issues.apache.org/jira/browse/GERONIMO-3563 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem, car-maven-plugin Affects Versions: 2.1 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 2.1 Under some configs, there is a plan.xml under src/plan directory and another in src/main/plan directory. The file under src/main/plan is redundant and should be removed to avoid confusion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: J2G future positioning
I'm going more along with Jason's original reply here... I like the idea of calling it Geronimo Migration Toolkit, keeping the name slightly ambiguous with the toolkit at the end would allow for us to potentially 'grow into' it in the future. -Erik Tim McConnell wrote: Hi, Does anyone have any thoughts as to how we'll position the J2G plugin in the future ?? I understand now that in its initial iteration that it is narrowly scoped to work for JBoss specific migrations only (thus the JBoss in the name). However, it seems if we want to eventually enhance it as a more generic tool for migrating multiple applications to Geronimo (which I would hope we would), it might be a good time now to reconsider a more generic and/or appropriate name. Any thoughts ??
Re: Restructuring build for flexible server
Donald Woods wrote: I think we really need to find some way to break the specs into smaller pieces. Having to install all of the JEE specs just for the simple minimal web container assembly is ugly and wastes disk space. Well, we could have a config per spec ... but that might be a bit too much. I'm not sure what smaller organizations would look like. We thought about breaking jee-specs up when we created the minimal assemblies but at the time it didn't seem worthy of the effort. Now that we are getting closer to making the flexible server a reality perhaps it is time. But I'm still not convinced that it would be worth the complexities it would bring and it doesn't consume a huge amount of space. Joe David Jencks wrote: Good work!! A couple comments inline. On Oct 29, 2007, at 7:48 AM, Prasad Kashyap wrote: I spend most of the weekend trying to restructure trunk to reflect the new flexible server and I should tell you, it has been one shitty job much akin to untangling the knots of Medusa's hair. To begin with I wanted to build just the modules and configs (along with the necessary buildsupport and maven-plugins artifacts) that go into a framework assembly.I believe that if we effectively want to restructure the build tree to reflect the flexible server, then we should be able to build just the framework artifacts ONLY. The framework artifacts should not have a dependency on plugins artifacts because they are optionally choosen to build an assembly of choice. Also, if our strategic vision is to break down the tree into smaller projects for framework, plugins etc, this we should break this cyclical dependency too. See Jason's response here - http://www.nabble.com/forum/ViewPost.jtp?post=12460948framed=yskin=134 First hitch - Our framework assembly contains jee-specs car. This car has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is in a incorrect dependency which we don't need at this point or it might be truly needed here so that it gets in the classpath for later use. I commented this dependency out and proceeded to build jee-specs car. I strongly tend to believe that this myfaces dep is wrongly placed here. If it is really req'd then we have a bigger problem of fixing our classloader scheme. I don't understand the problem here and what you want to do. We have several other specs (from axis and jstl) that we don't build that are included in jee-specs. Is the jsf api different from these in some way? Do you want to remove the jsf spec from jee-specs or the jee-specs from the framework assembly? I remember having a lot of classloader problems trying to get stuff to run and pass the tck before we came up with the jee-specs module, but it might be possible to split it up and put the jars with the implementations that use them. I think this will be difficult so I'd like to postpone that. Second hitch - Trying to build framework assembly's server-security-config car requires you to build j2ee-deployer. If you wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars which in turn has a dependency on webservices. Slowly we are building more and more plugins which are optional artifacts. This is definitely a problem. I think we can solve it with a security-deployer config that has the security related gbeans from j2ee-deployer in it. What do you think? If we really have to build a lot of plugins just to build the framework artifacts, then there is little point in restructuring the build tree now or breaking the tree later. I have checked in the restructured code under sandbox/restructure. I have been able to do a bootstrap build thus far. To build this on your machine, take the following steps 1) begin with a good local repository for your trunk build 2) delete applications, assemblies, modules, geronimo, configs, plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your local repo. 3) svn co https://svn.apache.org/repos/asf/geronimo/sandbox/restructure 4) mvn -o -Dstage=bootstrap 5) mvn -o -Dstage=assembly You should fail here Thanks! david jencks Cheers Prasad
Re: svn commit: r589918 - in /geronimo/server/trunk/configs: activemq-broker/src/main/ activemq-ra/src/main/ axis-deployer/src/main/ axis/src/main/ axis2-deployer/src/main/ axis2-ejb-deployer/src/main
Vamsi, you have removed the wrong plan. This is THE actual plan. The plan to be removed is the one under src/plan http://www.nabble.com/forum/ViewPost.jtp?post=13435934framed=yskin=134 Cheers Prasad On 10/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: vamsic007 Date: Mon Oct 29 17:36:56 2007 New Revision: 589918 URL: http://svn.apache.org/viewvc?rev=589918view=rev Log: GERONIMO-3563 Remove duplicate plan.xml files under configs o Removed the trivial ones where the plan.xml under src/plan is not significantly different from the one under src/main/plan except for some formatting etc. Removed: geronimo/server/trunk/configs/activemq-broker/src/main/ geronimo/server/trunk/configs/activemq-ra/src/main/ geronimo/server/trunk/configs/axis-deployer/src/main/ geronimo/server/trunk/configs/axis/src/main/ geronimo/server/trunk/configs/axis2-deployer/src/main/ geronimo/server/trunk/configs/axis2-ejb-deployer/src/main/ geronimo/server/trunk/configs/axis2-ejb/src/main/ geronimo/server/trunk/configs/axis2/src/main/ geronimo/server/trunk/configs/ca-helper-jetty/src/main/ geronimo/server/trunk/configs/ca-helper-tomcat/src/main/ geronimo/server/trunk/configs/client-corba-yoko/src/main/ geronimo/server/trunk/configs/client-deployer/src/main/ geronimo/server/trunk/configs/client-security/src/main/ geronimo/server/trunk/configs/client-system/src/main/plan/ geronimo/server/trunk/configs/client-transaction/src/main/ geronimo/server/trunk/configs/client/src/main/ geronimo/server/trunk/configs/clustering/src/main/ geronimo/server/trunk/configs/connector-deployer/src/main/ geronimo/server/trunk/configs/cxf-deployer/src/main/ geronimo/server/trunk/configs/cxf-ejb-deployer/src/main/ geronimo/server/trunk/configs/cxf-ejb/src/main/ geronimo/server/trunk/configs/cxf/src/main/ geronimo/server/trunk/configs/dojo-jetty6/src/main/ geronimo/server/trunk/configs/dojo-tomcat/src/main/ geronimo/server/trunk/configs/hot-deployer/src/main/ geronimo/server/trunk/configs/j2ee-corba-yoko/src/main/ geronimo/server/trunk/configs/j2ee-deployer/src/main/ geronimo/server/trunk/configs/j2ee-security/src/main/ geronimo/server/trunk/configs/j2ee-server/src/main/ geronimo/server/trunk/configs/j2ee-system/src/main/plan/ geronimo/server/trunk/configs/jasper-deployer/src/main/ geronimo/server/trunk/configs/jasper/src/main/ geronimo/server/trunk/configs/jaxws-deployer/src/main/plan/ geronimo/server/trunk/configs/jaxws-ejb-deployer/src/main/ geronimo/server/trunk/configs/jee-specs/src/main/ geronimo/server/trunk/configs/jetty6-clustering-builder-wadi/src/main/ geronimo/server/trunk/configs/jetty6-clustering-wadi/src/main/ geronimo/server/trunk/configs/jetty6/src/main/ geronimo/server/trunk/configs/jsr88-cli/src/main/ geronimo/server/trunk/configs/jsr88-deploymentfactory/src/main/plan/ geronimo/server/trunk/configs/mejb/src/main/ geronimo/server/trunk/configs/myfaces-deployer/src/main/ geronimo/server/trunk/configs/myfaces/src/main/ geronimo/server/trunk/configs/online-deployer/src/main/plan/ geronimo/server/trunk/configs/openejb-corba-deployer/src/main/ geronimo/server/trunk/configs/openejb/src/main/ geronimo/server/trunk/configs/persistence-jpa10-deployer/src/main/ geronimo/server/trunk/configs/remote-deploy-jetty/src/main/ geronimo/server/trunk/configs/remote-deploy-tomcat/src/main/ geronimo/server/trunk/configs/rmi-naming/src/main/ geronimo/server/trunk/configs/server-security-config/src/main/ geronimo/server/trunk/configs/sharedlib/src/main/ geronimo/server/trunk/configs/shutdown/src/main/plan/ geronimo/server/trunk/configs/spring/src/main/ geronimo/server/trunk/configs/tomcat6-deployer/src/main/ geronimo/server/trunk/configs/tomcat6/src/main/ geronimo/server/trunk/configs/transaction/src/main/ geronimo/server/trunk/configs/transformer-agent/src/main/plan/ geronimo/server/trunk/configs/wadi-clustering/src/main/ geronimo/server/trunk/configs/webservices-common/src/main/ geronimo/server/trunk/configs/welcome-jetty/src/main/ geronimo/server/trunk/configs/welcome-tomcat/src/main/ geronimo/server/trunk/configs/xmlbeans/src/main/
[BUILD] 2.1: Failed for Revision: 589922
OpenEJB trunk at 589804
Geronimo Revision: 589922 built with tests included
See the full build-2100.log file at
http://people.apache.org/~prasad/binaries/trunk/20071029/build-2100.log
[INFO] Copy webapp webResources to
/home/prasad/geronimo/trunk/applications/geronimo-uddi-server/target/geronimo-uddi-server-2.1-SNAPSHOT
[INFO] Building jar:
/home/prasad/geronimo/trunk/applications/geronimo-uddi-server/target/geronimo-uddi-server-2.1-SNAPSHOT/WEB-INF/lib/geronimo-uddi-server-2.1-SNAPSHOT.jar
[INFO] Generating war
/home/prasad/geronimo/trunk/applications/geronimo-uddi-server/target/geronimo-uddi-server-2.1-SNAPSHOT.war
[INFO] Building war:
/home/prasad/geronimo/trunk/applications/geronimo-uddi-server/target/geronimo-uddi-server-2.1-SNAPSHOT.war
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-uddi-server-2.1-SNAPSHOT.war
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/applications/geronimo-uddi-server/target/geronimo-uddi-server-2.1-SNAPSHOT.war
to
/home/prasad/.m2/repository/org/apache/geronimo/applications/geronimo-uddi-server/2.1-SNAPSHOT/geronimo-uddi-server-2.1-SNAPSHOT.war
[INFO]
[INFO] Building Geronimo Applications :: CA Helper Application
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 3 source files to
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/classes
[INFO] [jspc:compile {execution: default}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/jsp-source
[INFO] Compiling JSP source files to
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/jsp-source
[INFO] Compiled completed in 0:00:00.806
[INFO] Copying 9 files to
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [war:war]
[INFO] Exploding webapp...
[INFO] Assembling webapp geronimo-ca-helper in
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/geronimo-ca-helper-2.1-SNAPSHOT
[INFO] Copy webapp webResources to
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/geronimo-ca-helper-2.1-SNAPSHOT
[INFO] Copy webapp webResources to
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/geronimo-ca-helper-2.1-SNAPSHOT
[INFO] Building jar:
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/geronimo-ca-helper-2.1-SNAPSHOT/WEB-INF/lib/geronimo-ca-helper-2.1-SNAPSHOT.jar
[INFO] Generating war
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/geronimo-ca-helper-2.1-SNAPSHOT.war
[INFO] Building war:
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/geronimo-ca-helper-2.1-SNAPSHOT.war
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-ca-helper-2.1-SNAPSHOT.war
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/applications/geronimo-ca-helper/target/geronimo-ca-helper-2.1-SNAPSHOT.war
to
/home/prasad/.m2/repository/org/apache/geronimo/applications/geronimo-ca-helper/2.1-SNAPSHOT/geronimo-ca-helper-2.1-SNAPSHOT.war
[INFO]
[INFO] Building Geronimo Configs
[INFO]task-segment: [install]
[INFO]
[INFO] Reloading plugin container for:
org.apache.geronimo.plugins:car-maven-plugin. The plugin artifact has changed.
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [site:attach-descriptor]
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] [install:install]
[INFO] Installing /home/prasad/geronimo/trunk/configs/pom.xml to
/home/prasad/.m2/repository/org/apache/geronimo/configs/configs/2.1-SNAPSHOT/configs-2.1-SNAPSHOT.pom
[INFO]
[INFO] Building Geronimo Configs :: GBean Deployer Boostrap version
[INFO]task-segment: [install]
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy
Re: Restructuring build for flexible server
I ran the tck smoketest (both Jetty Tomcat) on the restructured build and the results were consistent with the ones from the current trunk build. What are the next steps ? If we plan to use this tree for 2.1 trunk, then we should merge ASAP before the trees get too much out of synch. I'd appreciate if folks checked out the restructure dir from sandbox and built the new tree. The steps are listed here again 1) begin with a good local repository for your trunk build. 2) delete applications, assemblies, modules, geronimo, configs, plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your local repo. 3) svn co https://svn.apache.org/repos/asf/geronimo/sandbox/restructure 4) mvn -o -Dstage=bootstrap 5) mvn -o -Dstage=assemble P.S: If jee-specs and myfaces modules fail to build due to missing o.a.myfaces.core/myfaces-* dependencies, just build those in the online mode. Cheers Prasad On 10/29/07, Joe Bohn [EMAIL PROTECTED] wrote: Donald Woods wrote: I think we really need to find some way to break the specs into smaller pieces. Having to install all of the JEE specs just for the simple minimal web container assembly is ugly and wastes disk space. Well, we could have a config per spec ... but that might be a bit too much. I'm not sure what smaller organizations would look like. We thought about breaking jee-specs up when we created the minimal assemblies but at the time it didn't seem worthy of the effort. Now that we are getting closer to making the flexible server a reality perhaps it is time. But I'm still not convinced that it would be worth the complexities it would bring and it doesn't consume a huge amount of space. Joe David Jencks wrote: Good work!! A couple comments inline. On Oct 29, 2007, at 7:48 AM, Prasad Kashyap wrote: I spend most of the weekend trying to restructure trunk to reflect the new flexible server and I should tell you, it has been one shitty job much akin to untangling the knots of Medusa's hair. To begin with I wanted to build just the modules and configs (along with the necessary buildsupport and maven-plugins artifacts) that go into a framework assembly.I believe that if we effectively want to restructure the build tree to reflect the flexible server, then we should be able to build just the framework artifacts ONLY. The framework artifacts should not have a dependency on plugins artifacts because they are optionally choosen to build an assembly of choice. Also, if our strategic vision is to break down the tree into smaller projects for framework, plugins etc, this we should break this cyclical dependency too. See Jason's response here - http://www.nabble.com/forum/ViewPost.jtp?post=12460948framed=yskin=134 First hitch - Our framework assembly contains jee-specs car. This car has a dependency on o.a.myfaces.core/myfaces-api jar. Either this is in a incorrect dependency which we don't need at this point or it might be truly needed here so that it gets in the classpath for later use. I commented this dependency out and proceeded to build jee-specs car. I strongly tend to believe that this myfaces dep is wrongly placed here. If it is really req'd then we have a bigger problem of fixing our classloader scheme. I don't understand the problem here and what you want to do. We have several other specs (from axis and jstl) that we don't build that are included in jee-specs. Is the jsf api different from these in some way? Do you want to remove the jsf spec from jee-specs or the jee-specs from the framework assembly? I remember having a lot of classloader problems trying to get stuff to run and pass the tck before we came up with the jee-specs module, but it might be possible to split it up and put the jars with the implementations that use them. I think this will be difficult so I'd like to postpone that. Second hitch - Trying to build framework assembly's server-security-config car requires you to build j2ee-deployer. If you wish to build j2ee-deployer, it pulls in other j2ee-* modules and cars which in turn has a dependency on webservices. Slowly we are building more and more plugins which are optional artifacts. This is definitely a problem. I think we can solve it with a security-deployer config that has the security related gbeans from j2ee-deployer in it. What do you think? If we really have to build a lot of plugins just to build the framework artifacts, then there is little point in restructuring the build tree now or breaking the tree later. I have checked in the restructured code under sandbox/restructure. I have been able to do a bootstrap build thus far. To build this on your machine, take the following steps 1) begin with a good local repository for your trunk build 2) delete applications, assemblies, modules, geronimo, configs, plugins and mavenplugin dirs under .m2/org/apache/geronimo dir of your
Re: Question about a sample Application
#1. The example asks you to create a DB named InventoryDB and then run some sql commands to create tables. #2. Your web.xml has a resource ref to jdbc/InventoryDS. This is a part of the jndi name of the datasource (not database). #3. The geronimo-web.xml links your jdbc/InventoryDS with the datasource's name called InventoryPool. #4. Then the InventoryPool.xml which is the alt-DD for the RA links the InventoryPool datasource with the InventoryDB you created in #1. http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/inventory/inventory-ear/src/main/resources/InventoryPool.xml?view=markup For further reading, check out this link http://localhost:8080/console/portal//Services/Database%20Pools/__pm0x3system-database0x2DBWizard!1134683811%7C0_view/__rp0x3system-database0x2DBWizard!1134683811%7C0_name/InventoryPool/__rp0x3system-database0x2DBWizard!1134683811%7C0_mode/usage/__rp0x3system-database0x2DBWizard!1134683811%7C0_abstractName/org0x2apache0x2geronimo0x2samples0x3inventory-ear0x320x20-SNAPSHOT0x3ear0xaJ2EEApplication=org0x2apache0x2geronimo0x2samples0x3inventory-ear0x320x20-SNAPSHOT0x3ear,JCAConnectionFactory=InventoryPool,JCAResource=tranql-connector-ra-10x230x2rar,ResourceAdapter=tranql-connector-ra-10x230x2rar,ResourceAdapterModule=tranql-connector-ra-10x230x2rar,j2eeType=JCAManagedConnectionFactory,name=InventoryPool This is the usage link for the InventoryPool under Database Pools navigational link. If you have deployed the Inventory app, you will see this link too. Hope this helps Cheers Prasad On 10/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi , we are working on the geronimo one project. We were looking at a sample application that connects to the database in geronimo . Upone studying it we stumbled upon a syntax that has a little confused In your DBManager.java for the inventory application we found this line of code. DataSource ds = (DataSource)context.lookup(java:comp/env/jdbc/InventoryDS); We know what the function does . We just don't know what the parameter represents. Which part of the parameter represents the database we are connecting to? We need to know the nature of the parameter so that we can use it in our own application.
[jira] Commented: (GERONIMO-3563) Remove duplicate plan.xml files under configs
[ https://issues.apache.org/jira/browse/GERONIMO-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538650 ] Vamsavardhana Reddy commented on GERONIMO-3563: --- Rev: 589946 o Reverting all changed made in rev 589918 as it resulted in build break. o The use of plan.xml file is not consistent across all configs. Some use src/plan/plan.xml and some others use src/main/plan/plan.xml Remove duplicate plan.xml files under configs - Key: GERONIMO-3563 URL: https://issues.apache.org/jira/browse/GERONIMO-3563 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem, car-maven-plugin Affects Versions: 2.1 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 2.1 Under some configs, there is a plan.xml under src/plan directory and another in src/main/plan directory. The file under src/main/plan is redundant and should be removed to avoid confusion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Question about a sample Application
Hi , we are working on the geronimo one project. We were looking at a sample application that connects to the database in geronimo . Upone studying it we stumbled upon a syntax that has a little confused In your DBManager.java for the inventory application we found this line of code. DataSource ds = (DataSource)context.lookup(java:comp/env/jdbc/InventoryDS); We know what the function does . We just don't know what the parameter represents. Which part of the parameter represents the database we are connecting to? We need to know the nature of the parameter so that we can use it in our own application.
Re: @Resource.mappedName processing
On Oct 23, 2007, at 9:50 PM, Jarek Gawor wrote: Some questions on @Resource.mappedName processing. When an ejb is deployed that has some @Resource annotated fields, OpenEJB will process them and create the appropriate resource-ref entires in the DD and pass it to Geronimo. But before the DD is passed into Geronimo the mappedName attributes of the entires are cleared (see EjbModuleBuilder.unmapReferences()). Why is that cleared? IIRC, when the original integration was going on (back in 2.0 m2) there were issues in the xmlbeans tree in Geronimo such that it didn't contain the mappedName element. As a workaround we had to clear the mappedName data out so things wouldn't blow up. We can probably delete the code in EjbModuleBuilder that clears them out. -David
Re: Question about a sample Application
On 10/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi , we are working on the geronimo one project. We were looking at a sample application that connects to the database in geronimo . Upone studying it we stumbled upon a syntax that has a little confused In your DBManager.java for the inventory application we found this line of code. DataSource ds = (DataSource)context.lookup(java:comp/env/jdbc/InventoryDS); The parameter represents the JNDI name of a datasource. Once you deploy the application, go to the Administration Console, then click on JNDI Viewer on the left panel. It will show you a tree of the JNDI names. We know what the function does . We just don't know what the parameter represents. Which part of the parameter represents the database we are connecting to? We need to know the nature of the parameter so that we can use it in our own application. The parameter does not specify which DB you are connecting to. What it does, is specify which DataSource you wish to use. The DataSource will specify which DB to connect to. So it's YourApp -- DataSource -- Database The DataSource is defined by 'InventoryPool.xml.' Hope this helps, Viet
