[jira] Created: (GERONIMO-3570) Review SQLLoginModule
Review SQLLoginModule - Key: GERONIMO-3570 URL: https://issues.apache.org/jira/browse/GERONIMO-3570 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: security Affects Versions: 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.1 Review SQLLoginModule for potential violations and security risks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: basic security review
I think we should create JIRAs for each review activity that results in code changes and update the wiki with the JIRA number. This way we will be able to track the progress on each activity in one central place. Also, add important points from this discussion thread to the wiki too. ++Vamsi On 10/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > I agree. Our strategy to make Geronimo secure should include an > elaborate set of unit testcases, a rich set of tests in the > security-testsuite in our testsuite framework, along with peer > review of code in components that are potential security risks. > > We should aim to have imbricate or maybe even duplicate tests than have > gaps. > > Towards this end, I created a security-testsuite in our testsuite > framework. It contains one test now. I shall add some more soon. > Please contribute to this testsuite with more and more tests that you > can think of. > > Thanx > Prasad > > On 10/29/07, Jarek Gawor <[EMAIL PROTECTED]> wrote: > > 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: basic security review
Thanks Jarek and Prasad for getting the ball rolling. ++Vamsi On 10/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > I agree. Our strategy to make Geronimo secure should include an > elaborate set of unit testcases, a rich set of tests in the > security-testsuite in our testsuite framework, along with peer > review of code in components that are potential security risks. > > We should aim to have imbricate or maybe even duplicate tests than have > gaps. > > Towards this end, I created a security-testsuite in our testsuite > framework. It contains one test now. I shall add some more soon. > Please contribute to this testsuite with more and more tests that you > can think of. > > Thanx > Prasad > > On 10/29/07, Jarek Gawor <[EMAIL PROTECTED]> wrote: > > 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 > > >
Geronimo presentation at the Irish
Hi, I wanted to let everyone know I will be giving a presentation at the Irish Java Technology Conference (ijtc) in Dublin, Ireland on Nov 8th (16:45-18:00) on Geronimo 2.x. The presentation is called "Apache Geronimo: Leveraging Open Source" and is an overview of the Geronimo server and its ability to customize your own stack. If you are attending, I hope to see you there. If you aren't and you are in town, please give me a ping as I would love to hook up and have an informal "G-Talk" at a local pub. Lets just call it an informal BOF ;-) Hope to see you there, Jeff Genender Apache Geronimo http://geronimo.apache.org
Re: [PLEASE read before you commit]: Restructuring trunk in SVN !!!
The -Dstage=former is not working as desired. I was unsuccessful in fixing it tonight. I'll try again tomorrow. However, the new restructuring is building fine. It has passed testsuite tests too. (If it passes TCK too, I may not waste any more time trying to fix old build, esp when I am deleting it the day after). Does anybody really really want it to work ? Cheers Prasad On 10/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > Sorry and thanx Jarek. I have fixed the security-deployer-config > pom.xml and plan.xml. This will remove any extraneous dependencies it > has on plugin artifacts. > > Cheers > Prasad > > On 10/30/07, Jarek Gawor <[EMAIL PROTECTED]> wrote: > > I removed all org/apache/geronimo from my m2 repo and executed mvn > > install -Dstage=bootstrap. That failed with the error below in > > ./framework/configs/server-security-config. Looks like the > > dependencies are not setup right since it was also downloading > > j2ee-deployer/car and a bunch of other modules which have not been > > built yet. > > > > Jarek > > > > [INFO] > > > > [ERROR] BUILD ERROR > > [INFO] > > > > [INFO] start of > > org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed > > > > Could not find a valid constructor for GBean: > > org.apache.geronimo.j2ee.deployment.EARConfigBuilder > > ParameterTypes: [class > > org.apache.geronimo.kernel.repository.Environment, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, interface > > java.util.Collection, interface java.util.Collection, interface > > java.util.Collection, interface java.util.Collection, interface > > java.util.Collection, interface java.util.Collection, interface > > java.util.Collection, interface java.util.Collection, interface > > java.util.Collection, interface java.util.Collection, interface > > org.apache.geronimo.kernel.Kernel] > > constructor types: [class > > org.apache.geronimo.kernel.repository.Environment, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, interface > > java.util.Collection, interface java.util.Collection, interface > > java.util.Collection, interface java.util.Collection, interface > > java.util.Collection, interface java.util.Collection, interface > > java.util.Collection, interface java.util.Collection, interface > > java.util.Collection, interface org.apache.geronimo.kernel.Kernel] > > constructor types: [class > > org.apache.geronimo.kernel.repository.Environment, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, class > > org.apache.geronimo.gbean.AbstractNameQuery, interface > > java.util.Collection, interface > > org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface > > org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface > > org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface > > org.apache.geronimo.j2ee.deployment.ActivationSpecInfoLocator, > > interface org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface > > org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface > > org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface > > org.apache.geronimo.j2ee.deployment.ModuleBuilderExtension, class > > org.apache.geronimo.kernel.Naming] > > > > > > On 10/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > > GERONIMO-3565 has now checked in the new restructured trunk into svn. > > > > > > The default profile will build the new trunk pieces. > > > > > > The -Dstage=former profile will build the old trunk pieces. > > > > > > Let's closely monitor the automated builds, testsuites and TCK results. > > > > > > If everything is going smoothly, I shall remove the old trunk pieces > > > by eod, Thursday, Nov 1 2007. > > > > > > Cheers > > > Prasad > > > > > > On 10/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > > > I am restructuring the trunk in svn to reflect our flexible server. > > > > Instead of a move, it will be a two-step copy/delete process. I shall > > > > first begin by copying some directories to other directories. Server > > > > binaries will be built from the newly created directories. After they > > > > have gone thro' 2 days of automated
[BUILD] 2.1: Failed for Revision: 590524
OpenEJB trunk at 590271 Geronimo Revision: 590524 built with tests included See the full build-2100.log file at http://people.apache.org/~prasad/binaries/trunk/20071030/build-2100.log 78K downloaded [INFO] snapshot org.apache.geronimo.modules:geronimo-web-2.5-builder:2.1-SNAPSHOT: checking for updates from apache-snapshots [INFO] snapshot org.apache.geronimo.modules:geronimo-web-2.5-builder:2.1-SNAPSHOT: checking for updates from codehaus-snapshots [INFO] snapshot org.apache.geronimo.modules:geronimo-web-2.5-builder:2.1-SNAPSHOT: checking for updates from apache.snapshots Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/modules/geronimo-web-2.5-builder/2.1-SNAPSHOT/geronimo-web-2.5-builder-2.1-20070726.173455-2.jar 56K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/components/geronimo-transaction/2.1-SNAPSHOT/geronimo-transaction-2.1-20071017.034044-1.jar 50K downloaded Downloading: http://download.java.net/maven/1//org.apache.ws.scout/jars/scout-1.0rc1.jar Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/ws/scout/scout/1.0rc1/scout-1.0rc1.jar Downloading: http://repo1.maven.org/maven2/org/apache/ws/scout/scout/1.0rc1/scout-1.0rc1.jar 1042K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/configs/j2ee-deployer/2.1-SNAPSHOT/j2ee-deployer-2.1-20071024.155022-7.pom 10K downloaded Downloading: http://download.java.net/maven/1//commons-discovery/poms/commons-discovery-0.4.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//commons-discovery/commons-discovery/0.4/commons-discovery-0.4.pom Downloading: http://repo1.maven.org/maven2/commons-discovery/commons-discovery/0.4/commons-discovery-0.4.pom 5K downloaded Downloading: http://download.java.net/maven/1//org.apache.axis2/poms/axis2-kernel-1.3.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/axis2/axis2-kernel/1.3/axis2-kernel-1.3.pom Downloading: http://repo1.maven.org/maven2/org/apache/axis2/axis2-kernel/1.3/axis2-kernel-1.3.pom 8K downloaded Downloading: http://download.java.net/maven/1//org.apache.woden/poms/woden-1.0-incubating-M7b.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.pom Downloading: http://repo1.maven.org/maven2/org/apache/woden/woden/1.0-incubating-M7b/woden-1.0-incubating-M7b.pom Downloading: http://download.java.net/maven/1//org.apache.httpcomponents/poms/httpcore-4.0-alpha5.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/httpcomponents/httpcore/4.0-alpha5/httpcore-4.0-alpha5.pom Downloading: http://repo1.maven.org/maven2/org/apache/httpcomponents/httpcore/4.0-alpha5/httpcore-4.0-alpha5.pom 4K downloaded Downloading: http://download.java.net/maven/1//org.apache.httpcomponents/poms/httpcomponents-core-4.0-alpha5.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/httpcomponents/httpcomponents-core/4.0-alpha5/httpcomponents-core-4.0-alpha5.pom Downloading: http://repo1.maven.org/maven2/org/apache/httpcomponents/httpcomponents-core/4.0-alpha5/httpcomponents-core-4.0-alpha5.pom 5K downloaded Downloading: http://download.java.net/maven/1//org.apache.httpcomponents/poms/project-4.0.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/httpcomponents/project/4.0/project-4.0.pom Downloading: http://repo1.maven.org/maven2/org/apache/httpcomponents/project/4.0/project-4.0.pom 6K downloaded Downloading: http://download.java.net/maven/1//backport-util-concurrent/poms/backport-util-concurrent-2.2.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//backport-util-concurrent/backport-util-concurrent/2.2/backport-util-concurrent-2.2.pom Downloading: http://repo1.maven.org/maven2/backport-util-concurrent/backport-util-concurrent/2.2/backport-util-concurrent-2.2.pom 909b downloaded Downloading: http://download.java.net/maven/1//org.apache.ws.commons.schema/poms/XmlSchema-1.3.1.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/ws/commons/schema/XmlSchema/1.3.1/XmlSchema-1.3.1.pom Downloading: http://repo1.maven.org/maven2/org/apache/ws/commons/schema/XmlSchema/1.3.1/XmlSchema-1.3.1.pom 16K downloaded Downloading: http://download.java.net/maven/1//org.apache.httpcomponents/poms/httpcore-niossl-4.0-alpha5.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/httpcomponents/httpcore-niossl/4.0-alpha5/httpcore-niossl-4.0-alpha5.pom Downloading: http://repo1.maven.org/maven2/org/apache/httpcomponents/httpcore-niossl/4.0-alpha5/httpcore-niossl-4.0-alpha5.pom 4K downloaded Downloading: http://download.java.net/maven/1//org.apache.httpcomponents/poms/httpcore-nio-4.0-alpha5.pom Downloading: http://people.apache.org/repo/m2-incubating
Re: [PLEASE read before you commit]: Restructuring trunk in SVN !!!
Sorry and thanx Jarek. I have fixed the security-deployer-config pom.xml and plan.xml. This will remove any extraneous dependencies it has on plugin artifacts. Cheers Prasad On 10/30/07, Jarek Gawor <[EMAIL PROTECTED]> wrote: > I removed all org/apache/geronimo from my m2 repo and executed mvn > install -Dstage=bootstrap. That failed with the error below in > ./framework/configs/server-security-config. Looks like the > dependencies are not setup right since it was also downloading > j2ee-deployer/car and a bunch of other modules which have not been > built yet. > > Jarek > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] start of > org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed > > Could not find a valid constructor for GBean: > org.apache.geronimo.j2ee.deployment.EARConfigBuilder > ParameterTypes: [class > org.apache.geronimo.kernel.repository.Environment, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, interface > java.util.Collection, interface java.util.Collection, interface > java.util.Collection, interface java.util.Collection, interface > java.util.Collection, interface java.util.Collection, interface > java.util.Collection, interface java.util.Collection, interface > java.util.Collection, interface java.util.Collection, interface > org.apache.geronimo.kernel.Kernel] > constructor types: [class > org.apache.geronimo.kernel.repository.Environment, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, interface > java.util.Collection, interface java.util.Collection, interface > java.util.Collection, interface java.util.Collection, interface > java.util.Collection, interface java.util.Collection, interface > java.util.Collection, interface java.util.Collection, interface > java.util.Collection, interface org.apache.geronimo.kernel.Kernel] > constructor types: [class > org.apache.geronimo.kernel.repository.Environment, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, class > org.apache.geronimo.gbean.AbstractNameQuery, interface > java.util.Collection, interface > org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface > org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface > org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface > org.apache.geronimo.j2ee.deployment.ActivationSpecInfoLocator, > interface org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface > org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface > org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface > org.apache.geronimo.j2ee.deployment.ModuleBuilderExtension, class > org.apache.geronimo.kernel.Naming] > > > On 10/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > GERONIMO-3565 has now checked in the new restructured trunk into svn. > > > > The default profile will build the new trunk pieces. > > > > The -Dstage=former profile will build the old trunk pieces. > > > > Let's closely monitor the automated builds, testsuites and TCK results. > > > > If everything is going smoothly, I shall remove the old trunk pieces > > by eod, Thursday, Nov 1 2007. > > > > Cheers > > Prasad > > > > On 10/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > > I am restructuring the trunk in svn to reflect our flexible server. > > > Instead of a move, it will be a two-step copy/delete process. I shall > > > first begin by copying some directories to other directories. Server > > > binaries will be built from the newly created directories. After they > > > have gone thro' 2 days of automated builds, testsuites and TCK > > > smoketests, I shall remove the old directories. > > > > > > So until further notice, please commit all your changes to both > > > directories, old and new. > > > > > > Most modules and config directories have gone into their feature > > > specific directory under plugins. For eg, changes to > > > configs/myfaces-deployer should be made to that dir and also to > > > plugins/myfaces/myfaces-deployer. > > > > > > A few modules and configs have been copied into framework directory > > > (to build framework assembly). > > > > > > For a more detailed discussion about the restructuring, pl
[jira] Resolved: (GERONIMO-3566) Monitoring client needs ability to add/edit/delete servers to connect to
[ https://issues.apache.org/jira/browse/GERONIMO-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig resolved GERONIMO-3566. - Resolution: Fixed Good after commit, Thanks anita! > Monitoring client needs ability to add/edit/delete servers to connect to > > > Key: GERONIMO-3566 > URL: https://issues.apache.org/jira/browse/GERONIMO-3566 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: monitoring >Reporter: Erik B. Craig >Assignee: Erik B. Craig > Attachments: GERONIMO-3566.patch > > > The monitoring client needs UI to add, edit, and delete servers from local > database -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [PLEASE read before you commit]: Restructuring trunk in SVN !!!
I removed all org/apache/geronimo from my m2 repo and executed mvn install -Dstage=bootstrap. That failed with the error below in ./framework/configs/server-security-config. Looks like the dependencies are not setup right since it was also downloading j2ee-deployer/car and a bunch of other modules which have not been built yet. Jarek [INFO] [ERROR] BUILD ERROR [INFO] [INFO] start of org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed Could not find a valid constructor for GBean: org.apache.geronimo.j2ee.deployment.EARConfigBuilder ParameterTypes: [class org.apache.geronimo.kernel.repository.Environment, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface org.apache.geronimo.kernel.Kernel] constructor types: [class org.apache.geronimo.kernel.repository.Environment, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface java.util.Collection, interface org.apache.geronimo.kernel.Kernel] constructor types: [class org.apache.geronimo.kernel.repository.Environment, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, class org.apache.geronimo.gbean.AbstractNameQuery, interface java.util.Collection, interface org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface org.apache.geronimo.j2ee.deployment.ActivationSpecInfoLocator, interface org.apache.geronimo.j2ee.deployment.ModuleBuilder, interface org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface org.apache.geronimo.deployment.NamespaceDrivenBuilder, interface org.apache.geronimo.j2ee.deployment.ModuleBuilderExtension, class org.apache.geronimo.kernel.Naming] On 10/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > GERONIMO-3565 has now checked in the new restructured trunk into svn. > > The default profile will build the new trunk pieces. > > The -Dstage=former profile will build the old trunk pieces. > > Let's closely monitor the automated builds, testsuites and TCK results. > > If everything is going smoothly, I shall remove the old trunk pieces > by eod, Thursday, Nov 1 2007. > > Cheers > Prasad > > On 10/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > I am restructuring the trunk in svn to reflect our flexible server. > > Instead of a move, it will be a two-step copy/delete process. I shall > > first begin by copying some directories to other directories. Server > > binaries will be built from the newly created directories. After they > > have gone thro' 2 days of automated builds, testsuites and TCK > > smoketests, I shall remove the old directories. > > > > So until further notice, please commit all your changes to both > > directories, old and new. > > > > Most modules and config directories have gone into their feature > > specific directory under plugins. For eg, changes to > > configs/myfaces-deployer should be made to that dir and also to > > plugins/myfaces/myfaces-deployer. > > > > A few modules and configs have been copied into framework directory > > (to build framework assembly). > > > > For a more detailed discussion about the restructuring, please see > > this thread - > > http://www.nabble.com/forum/ViewPost.jtp?post=13469170&framed=y&skin=134 > > > > Cheers > > Prasad > > >
[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_12538956 ] Viet Hung Nguyen commented on GERONIMO-3561: by making mrc-server a plugin, it can pull openejb onto the minimal server, likewise MEJB and the derby database. Your third point is a good one. Right now, it is hardcoded in the client to connect to port 4201. Maybe we should allow this option to be configurable. I never thought about the server having more than one geronimo instance running on it. Thanks for pointing that out. > 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] Closed: (GERONIMO-3559) assembly replaces rather than extends config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3559. -- Resolution: Fixed Fixed in rev 590516. > assembly replaces rather than extends config.xml > > > Key: GERONIMO-3559 > URL: https://issues.apache.org/jira/browse/GERONIMO-3559 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: car-maven-plugin >Affects Versions: 2.1 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.1 > > > Anita noticed that the assembly process is leaving out the stuff from the > framework assembly config.xml when constructing e.g. geronimo-jetty-javaee > config.xml. It's supposed to add stuff for the added plugins, not just start > over. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3527) Monitoring client needs default viewmode when selecting servers from the list
[ https://issues.apache.org/jira/browse/GERONIMO-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538947 ] Anita Kulshreshtha commented on GERONIMO-3527: -- GERONIMO-3566 patch applied in rev 590509. > Monitoring client needs default viewmode when selecting servers from the list > - > > Key: GERONIMO-3527 > URL: https://issues.apache.org/jira/browse/GERONIMO-3527 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: monitoring >Reporter: Erik B. Craig >Assignee: Erik B. Craig > > Currently selecting a server from the list in the monitoring client portlet > links to #, must create a default view for this in the same styling of the > default view for the 'views', with additional server-related functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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_12538944 ] Anita Kulshreshtha commented on GERONIMO-3561: -- - You could use EJB timer service. - Since mrc-server is as EJB app, it can not be installed on the minimal server. - Yes, The monitoring console(client) will know how to connect to mrc-server. My question is how do you tell the mrc-server which geronimo instance (OpenEJB Port) it is supposed to monitor. - I have applied GERONIMO-3561 and GERONIMO-3564 patches in rev. 590502. > 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] Created: (GERONIMO-3569) Monitoring client statsgraph object should read/write to db when necessary
Monitoring client statsgraph object should read/write to db when necessary -- Key: GERONIMO-3569 URL: https://issues.apache.org/jira/browse/GERONIMO-3569 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Reporter: Erik B. Craig Assignee: Erik B. Craig The statsgraph object for the monitoring client should have the ability to display the most recently drawn information from database (stored javascript as string data) when the server associated with the graph is unresponsive/down, allowing displaying of views when associated servers are down -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3567) Monitoring client add/edit server pages need to be polished up
[ https://issues.apache.org/jira/browse/GERONIMO-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3567: Assignee: Erik B. Craig > Monitoring client add/edit server pages need to be polished up > -- > > Key: GERONIMO-3567 > URL: https://issues.apache.org/jira/browse/GERONIMO-3567 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: monitoring >Reporter: Erik B. Craig >Assignee: Erik B. Craig > > -The add/edit server pages in the monitoring client need a 'test these > settings' function that will verify the current information provided in the > field, with a return of whether or not the server is responsive. > -Disable snapshot query functionality needs to be added to the edit server > page, with appropriate warning > -Saving a new snapshotduration value should compare to the current, and > change if different on the edit server page > -Disable this server link should work on the edit server page, setting the > servers status to disabled in database, also disabling associated graphs and > should warn appropriatedly > -Delete server should have appropriate warning -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3567) Monitoring client add/edit server pages need to be polished up
[ https://issues.apache.org/jira/browse/GERONIMO-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3567: Description: -The add/edit server pages in the monitoring client need a 'test these settings' function that will verify the current information provided in the field, with a return of whether or not the server is responsive. -Disable snapshot query functionality needs to be added to the edit server page, with appropriate warning -Saving a new snapshotduration value should compare to the current, and change if different on the edit server page -Disable this server link should work on the edit server page, setting the servers status to disabled in database, also disabling associated graphs and should warn appropriatedly -Delete server should have appropriate warning was:The add/edit server pages in the monitoring client need a 'test these settings' function that will verify the current information provided in the field, with a return of whether or not the server is responsive. Summary: Monitoring client add/edit server pages need to be polished up (was: Monitoring client add/edit server pages need 'test these settings' function) > Monitoring client add/edit server pages need to be polished up > -- > > Key: GERONIMO-3567 > URL: https://issues.apache.org/jira/browse/GERONIMO-3567 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: monitoring >Reporter: Erik B. Craig > > -The add/edit server pages in the monitoring client need a 'test these > settings' function that will verify the current information provided in the > field, with a return of whether or not the server is responsive. > -Disable snapshot query functionality needs to be added to the edit server > page, with appropriate warning > -Saving a new snapshotduration value should compare to the current, and > change if different on the edit server page > -Disable this server link should work on the edit server page, setting the > servers status to disabled in database, also disabling associated graphs and > should warn appropriatedly > -Delete server should have appropriate warning -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3568) Monitoring client serverview should update the last_seen field in database where possible
[ https://issues.apache.org/jira/browse/GERONIMO-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3568: Component/s: monitoring > Monitoring client serverview should update the last_seen field in database > where possible > - > > Key: GERONIMO-3568 > URL: https://issues.apache.org/jira/browse/GERONIMO-3568 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: monitoring >Reporter: Erik B. Craig >Assignee: Erik B. Craig > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3568) Monitoring client serverview should update the last_seen field in database where possible
Monitoring client serverview should update the last_seen field in database where possible - Key: GERONIMO-3568 URL: https://issues.apache.org/jira/browse/GERONIMO-3568 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Components: monitoring Reporter: Erik B. Craig Assignee: Erik B. Craig -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3567) Monitoring client add/edit server pages need 'test these settings' function
Monitoring client add/edit server pages need 'test these settings' function --- Key: GERONIMO-3567 URL: https://issues.apache.org/jira/browse/GERONIMO-3567 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Reporter: Erik B. Craig The add/edit server pages in the monitoring client need a 'test these settings' function that will verify the current information provided in the field, with a return of whether or not the server is responsive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3566) Monitoring client needs ability to add/edit/delete servers to connect to
[ https://issues.apache.org/jira/browse/GERONIMO-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3566: Attachment: GERONIMO-3566.patch This patch provides this functionality, tested and is good. After patch is applied, the following must be done to add two new files svn add client/client-war/src/main/webapp/WEB-INF/view/monitoringAddServer.jsp svn add client/client-war/src/main/webapp/WEB-INF/view/monitoringEditServer.jsp Thanks =) > Monitoring client needs ability to add/edit/delete servers to connect to > > > Key: GERONIMO-3566 > URL: https://issues.apache.org/jira/browse/GERONIMO-3566 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: monitoring >Reporter: Erik B. Craig >Assignee: Erik B. Craig > Attachments: GERONIMO-3566.patch > > > The monitoring client needs UI to add, edit, and delete servers from local > database -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3566) Monitoring client needs ability to add/edit/delete servers to connect to
[ https://issues.apache.org/jira/browse/GERONIMO-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig updated GERONIMO-3566: Patch Info: [Patch Available] > Monitoring client needs ability to add/edit/delete servers to connect to > > > Key: GERONIMO-3566 > URL: https://issues.apache.org/jira/browse/GERONIMO-3566 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: monitoring >Reporter: Erik B. Craig >Assignee: Erik B. Craig > Attachments: GERONIMO-3566.patch > > > The monitoring client needs UI to add, edit, and delete servers from local > database -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3566) Monitoring client needs ability to add/edit/delete servers to connect to
Monitoring client needs ability to add/edit/delete servers to connect to Key: GERONIMO-3566 URL: https://issues.apache.org/jira/browse/GERONIMO-3566 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Reporter: Erik B. Craig Assignee: Erik B. Craig The monitoring client needs UI to add, edit, and delete servers from local database -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [PLEASE read before you commit]: Restructuring trunk in SVN !!!
GERONIMO-3565 has now checked in the new restructured trunk into svn. The default profile will build the new trunk pieces. The -Dstage=former profile will build the old trunk pieces. Let's closely monitor the automated builds, testsuites and TCK results. If everything is going smoothly, I shall remove the old trunk pieces by eod, Thursday, Nov 1 2007. Cheers Prasad On 10/30/07, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > I am restructuring the trunk in svn to reflect our flexible server. > Instead of a move, it will be a two-step copy/delete process. I shall > first begin by copying some directories to other directories. Server > binaries will be built from the newly created directories. After they > have gone thro' 2 days of automated builds, testsuites and TCK > smoketests, I shall remove the old directories. > > So until further notice, please commit all your changes to both > directories, old and new. > > Most modules and config directories have gone into their feature > specific directory under plugins. For eg, changes to > configs/myfaces-deployer should be made to that dir and also to > plugins/myfaces/myfaces-deployer. > > A few modules and configs have been copied into framework directory > (to build framework assembly). > > For a more detailed discussion about the restructuring, please see > this thread - > http://www.nabble.com/forum/ViewPost.jtp?post=13469170&framed=y&skin=134 > > Cheers > Prasad >
[jira] Created: (GERONIMO-3565) Restructure build tree to reflect flexible server
Restructure build tree to reflect flexible server - Key: GERONIMO-3565 URL: https://issues.apache.org/jira/browse/GERONIMO-3565 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: ActiveMQ, application client, buildsystem, car-maven-plugin, Clustering, common, connector, console, CORBA, core, crypto, databases, dependencies, deployment, documentation, gbuild, general, geronimo-maven-plugin, Hot Deploy Dir, installer, J2G, Jetty, JIRA, JVM-compatibility, kernel, legal, Logging, mail, management, Memory Leaks, monitoring, naming, OpenEJB, persistence, Plugins, sample apps, security, ServiceMix, specs, startup/shutdown, testsuite, Tomcat, transaction manager, web, webservices Affects Versions: 2.1 Reporter: Prasad Kashyap Fix For: 2.1 http://www.nabble.com/forum/ViewPost.jtp?post=13469170&framed=y&skin=134 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[PLEASE read before you commit]: Restructuring trunk in SVN !!!
I am restructuring the trunk in svn to reflect our flexible server. Instead of a move, it will be a two-step copy/delete process. I shall first begin by copying some directories to other directories. Server binaries will be built from the newly created directories. After they have gone thro' 2 days of automated builds, testsuites and TCK smoketests, I shall remove the old directories. So until further notice, please commit all your changes to both directories, old and new. Most modules and config directories have gone into their feature specific directory under plugins. For eg, changes to configs/myfaces-deployer should be made to that dir and also to plugins/myfaces/myfaces-deployer. A few modules and configs have been copied into framework directory (to build framework assembly). For a more detailed discussion about the restructuring, please see this thread - http://www.nabble.com/forum/ViewPost.jtp?post=13469170&framed=y&skin=134 Cheers Prasad
[jira] Updated: (SM-1121) Remove the servicemix-bpe SE from the Apache ServiceMix distribution
[ https://issues.apache.org/activemq/browse/SM-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Snyder updated SM-1121: - Attachment: SM-1121.diff.txt Patch attached > Remove the servicemix-bpe SE from the Apache ServiceMix distribution > > > Key: SM-1121 > URL: https://issues.apache.org/activemq/browse/SM-1121 > Project: ServiceMix > Issue Type: Task > Components: servicemix-bpe >Affects Versions: 3.2 >Reporter: Bruce Snyder > Fix For: 3.2 > > Attachments: SM-1121.diff.txt > > > Since we recommend using the Apache Ode SE directly from the Ode project (see > the [servicemix-bpe > page|http://incubator.apache.org/servicemix/servicemix-bpe.html]), we should > remove the servicemix-bpe from the distribution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release ServiceMix 3.2
On 10/26/07, Freeman Fang <[EMAIL PROTECTED]> 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
Why are we still distributing servicemix-bpe? Since we recommend
Apache Ode, the servicemix-bep SE should be removed from the
distribution (https://issues.apache.org/activemq/browse/SM-1121).
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: Restructuring build for flexible server
OK. This is how I restructured it. But first, the aim was to keep the groupdId and artifactId of all artifacts as is so that our assemblies and final server is not affected. So the gIds and aIds of the modules and configs pieces were left unchanged for now. | geronimo |--- framework |--- modules |--- configs |--- components |--- plugins The framework dir contains only those modules and deployers that are needed by the framework assembly. Only geronimo-j2ee module in included here because it is needed to build the car-maven-plugin. The bootstrap profile now builds framework/modules and then builds mavenplugins (including c-m-p). All other modules, builders and their corresponding configs (cars) are moved to their respective dirs under plugins. So plugins/myfaces contain only myfaces modules and configs. I put artifacts like spring, transformer-agent and upgrade under components dir. Maybe they don't belong there. Maybe they can go elsewhere. The config pieces for the applications also moved to reside along with the application wars in the application dirs. Cheers Prasad On 10/30/07, Paul McMahan <[EMAIL PROTECTED]> wrote: > On Oct 29, 2007, at 3:47 PM, Prasad Kashyap wrote: > > > 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. > > I noticed that the groupIds in the poms don't always match their > placement in the svn directory structure. Is the intention to keep > things this way? For example: > https://svn.apache.org/repos/asf/geronimo/sandbox/restructure/ > plugins/cxf/cxf/pom.xml > > Also I'm curious what qualifies a subproject as belonging under > plugins, applications, components, configs, or modules . Currently > it's arranged as: > > applications: > # ca-helper/ > # geronimo-uddi-db/ > # mejb/ > # remote-deploy/ > # sharedlib/ > # uddi-server/ > # welcome/ > > components: > # spring/ > # transformer-agent/ > # upgrade/ > > framework/configs: > # client-system/ > # geronimo-gbean-deployer/ > # geronimo-gbean-deployer-bootstrap/ > # j2ee-security/ > # j2ee-system/ > # jee-specs/ > # jsr88-cli/ > # jsr88-deploymentfactory/ > # offline-deployer/ > # online-deployer/ > # rmi-naming/ > # server-security-config/ > # shutdown/ > # upgrade-cli/ > # xmlbeans/ > > framework/modules: > # geronimo-cli/ > # geronimo-commands/ > # geronimo-common/ > # geronimo-core/ > # geronimo-deploy-config/ > # geronimo-deploy-jsr88/ > # geronimo-deploy-jsr88-bootstrapper/ > # geronimo-deploy-tool/ > # geronimo-deployment/ > # geronimo-interceptor/ > # geronimo-j2ee/ > # geronimo-jdbc/ > # geronimo-jmx-remoting/ > # geronimo-kernel/ > # geronimo-management/ > # geronimo-naming/ > # geronimo-security/ > # geronimo-service-builder/ > # geronimo-system/ > # geronimo-transformer/ > # geronimo-upgrade/ > # geronimo-util/ > > plugins: > # activemq/ > # axis/ > # axis2/ > # client/ > # clustering/ > # connector/ > # console/ > # corba/ > # cxf/ > # debugviews/ > # dojo/ > # hotdeploy/ > # j2ee/ > # jasper/ > # javamail/ > # jaxws/ > # jetty/ > # myfaces/ > # openejb/ > # openjpa/ > # plancreator/ > # pluto/ > # system-database/ > # tomcat/ > # webservices/ > > > > Best wishes, > Paul >
[jira] Created: (SM-1121) Remove the servicemix-bpe SE from the Apache ServiceMix distribution
Remove the servicemix-bpe SE from the Apache ServiceMix distribution Key: SM-1121 URL: https://issues.apache.org/activemq/browse/SM-1121 Project: ServiceMix Issue Type: Task Components: servicemix-bpe Affects Versions: 3.2 Reporter: Bruce Snyder Fix For: 3.2 Since we recommend using the Apache Ode SE directly from the Ode project (see the [servicemix-bpe page|http://incubator.apache.org/servicemix/servicemix-bpe.html]), we should remove the servicemix-bpe from the distribution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Devtools maven-plugins-1.0 RC1
Resending, as this still hasn't hit the mailing list after 2 hours... Original Message Subject: [VOTE] Release Devtools maven-plugins-1.0 RC1 Date: Tue, 30 Oct 2007 10:47:32 -0400 From: Donald Woods <[EMAIL PROTECTED]> To: dev@geronimo.apache.org The maven-plugins are build tools used by the Eclipse Plugin and J2G tools and are not included in either tool. A 72 hour vote is being called for the following: https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/branches/1.0 Revision 590072 Binaries can be downloaded from: http://people.apache.org/~dwoods/releases/ maven-plugins-1.0-RC1-bin.tar.gz - files to be published maven-plugins-repo-1.0-RC1.tar.gz - captured build repo The source code will be moved to the following location in svn after the release has been approved: https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/tags/1.0 Please record your vote by 11AM EDT Friday, Nov. 2, 2007. Thanks, Donald
Re: [DISCUSS] Release Devtools maven-plugins-1.0
Resending, as this still hasn't hit the mailing list after 2 hours... Original Message Subject: [DISCUSS] Release Devtools maven-plugins-1.0 Date: Tue, 30 Oct 2007 10:47:14 -0400 From: Donald Woods <[EMAIL PROTECTED]> To: dev@geronimo.apache.org Discussion thread for the maven-plugins-1.0 release... -Donald
Re: Restructuring build for flexible server
On Oct 29, 2007, at 3:47 PM, Prasad Kashyap wrote: 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. I noticed that the groupIds in the poms don't always match their placement in the svn directory structure. Is the intention to keep things this way? For example: https://svn.apache.org/repos/asf/geronimo/sandbox/restructure/ plugins/cxf/cxf/pom.xml Also I'm curious what qualifies a subproject as belonging under plugins, applications, components, configs, or modules . Currently it's arranged as: applications: # ca-helper/ # geronimo-uddi-db/ # mejb/ # remote-deploy/ # sharedlib/ # uddi-server/ # welcome/ components: # spring/ # transformer-agent/ # upgrade/ framework/configs: # client-system/ # geronimo-gbean-deployer/ # geronimo-gbean-deployer-bootstrap/ # j2ee-security/ # j2ee-system/ # jee-specs/ # jsr88-cli/ # jsr88-deploymentfactory/ # offline-deployer/ # online-deployer/ # rmi-naming/ # server-security-config/ # shutdown/ # upgrade-cli/ # xmlbeans/ framework/modules: # geronimo-cli/ # geronimo-commands/ # geronimo-common/ # geronimo-core/ # geronimo-deploy-config/ # geronimo-deploy-jsr88/ # geronimo-deploy-jsr88-bootstrapper/ # geronimo-deploy-tool/ # geronimo-deployment/ # geronimo-interceptor/ # geronimo-j2ee/ # geronimo-jdbc/ # geronimo-jmx-remoting/ # geronimo-kernel/ # geronimo-management/ # geronimo-naming/ # geronimo-security/ # geronimo-service-builder/ # geronimo-system/ # geronimo-transformer/ # geronimo-upgrade/ # geronimo-util/ plugins: # activemq/ # axis/ # axis2/ # client/ # clustering/ # connector/ # console/ # corba/ # cxf/ # debugviews/ # dojo/ # hotdeploy/ # j2ee/ # jasper/ # javamail/ # jaxws/ # jetty/ # myfaces/ # openejb/ # openjpa/ # plancreator/ # pluto/ # system-database/ # tomcat/ # webservices/ Best wishes, Paul
[DISCUSS] Release Devtools maven-plugins-1.0
Discussion thread for the maven-plugins-1.0 release... -Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: Restructuring build for flexible server
This looks great! I had a couple of suggestions I mentioned to Prasad on IRC: - move client-transaction to the plugins/connector - move the jetty specific clustering stuff from plugins/clustering to plugins/jetty Unfortunately the sandbox doesn't seem to have svn history. I think its essential to preserve svn history. I think we can get this into trunk, preserve svn history, and hopefully preserve Prasad's sanity by: 1. create the new directories in trunk (e.g. framework, plugins/ connector, plugins/* etc) 2. svn cp the existing modules and configs to their new locations. This is probably the hard part I guess I'd start with the output of ls modules configs and write a script. 3. copy the new and modified poms (and other files) from restructure to trunk. If we copy rather than svn cp modified files we wont break history. Also, as long as we don't modify the root pom, all work up to here can be committed without affecting the existing build. 4. after committing the modified root pom, remove modules and configs. I'm in favor of asking Prasad to do steps 1-3 immediately in trunk. I'm fine with (4) too but perhaps we should have a vote on (4) since this is a pretty large change? thanks david jencks On Oct 29, 2007, at 8:51 PM, Prasad Kashyap wrote: 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=12460948&framed=y&skin=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 tc
[VOTE] Release Devtools maven-plugins-1.0 RC1
The maven-plugins are build tools used by the Eclipse Plugin and J2G tools and are not included in either tool. A 72 hour vote is being called for the following: https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/branches/1.0 Revision 590072 Binaries can be downloaded from: http://people.apache.org/~dwoods/releases/ maven-plugins-1.0-RC1-bin.tar.gz - files to be published maven-plugins-repo-1.0-RC1.tar.gz - captured build repo The source code will be moved to the following location in svn after the release has been approved: https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/tags/1.0 Please record your vote by 11AM EDT Friday, Nov. 2, 2007. Thanks, Donald smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] Release Devtools maven-plugins-1.0
Resending from Apache account, as Yahoo Mail seems to be unable to send right now Original Message Subject: [DISCUSS] Release Devtools maven-plugins-1.0 Date: Tue, 30 Oct 2007 10:47:14 -0400 From: Donald Woods <[EMAIL PROTECTED]> To: dev@geronimo.apache.org Discussion thread for the maven-plugins-1.0 release... -Donald
Re: J2G future positioning
Looking back, I explained what I was intending very poorly in my previous reply, but Paul has worded it much better. I am in agreement with this approach 100%. +1 Jay D. McHugh wrote: +1 This is making a -lot- of sense. There is no reason that we need to build a huge monolithic Eclipse plugin to allow people to migrate applications to our modular server platform. I originally didn't even think about breaking it up into a group of specific plugins using a common core - even though that is what Geronimo is all about. Jay Prasad Kashyap wrote: I'm with Paul on this. I envision a Migrate2Geronimo Toolkit that will consist of a suite of individual plugins (for Eclipse and G), each handling the migration from a specific appserver to G. Of course, all these may depend on a base or common plugin. But the user will only deal with the plugin relevant to him. He will not have to install one big huge uber migrator if he only has jboss apps. Next week, we'll look forward to Jason adding a BEA2G plugin to this M2G Toolkit ;-) Cheers Prasad. On 10/30/07, Paul McMahan <[EMAIL PROTECTED]> wrote: I'm not in favor of generalizing the J2G Eclipse plugin into a super migrator that grows in complexity as we incorporate new types of source formats. I think that instead we should look into factoring out the parts of J2G that could be used for other types migrators into a separate Eclipse plugin. Then J2G could remain as J2G but could prereq this new Eclipse plugin, as would any other new migrators we create. Best wishes, Paul On Oct 29, 2007, at 11:32 AM, 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 ?? -- Thanks, Tim McConnell
[jira] Commented: (SM-1120) Throwable is not cought in BaseLifeCycle which can result in open transactions
[
https://issues.apache.org/activemq/browse/SM-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40530
]
Martin Landua commented on SM-1120:
---
Sorry, forgot to attach the patch.
Index:
C:/jboss/servicemix-SNAPSHOT/common/servicemix-common/src/main/java/org/apache/servicemix/common/BaseLifeCycle.java
===
---
C:/jboss/servicemix-SNAPSHOT/common/servicemix-common/src/main/java/org/apache/servicemix/common/BaseLifeCycle.java
(revision 590120)
+++
C:/jboss/servicemix-SNAPSHOT/common/servicemix-common/src/main/java/org/apache/servicemix/common/BaseLifeCycle.java
(working copy)
@@ -44,7 +44,8 @@
public void onMessageExchange(MessageExchange exchange) {
try {
processExchange(exchange);
-} catch (Exception e) {
+} catch (Throwable t) {
+ Exception e = new Exception(t);
logger.error("Error processing exchange " + exchange, e);
try {
// If we are transacted and this is a runtime exception
> Throwable is not cought in BaseLifeCycle which can result in open transactions
> --
>
> Key: SM-1120
> URL: https://issues.apache.org/activemq/browse/SM-1120
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-common
>Affects Versions: 3.1
> Environment: Everywhere
>Reporter: Martin Landua
>
> The onMessageExchange method in BaseLifeCycle only catches Exceptions. If a
> Throwable is thrown during processing of the Message Exchange, the
> transaction will not be rolled back.
> As a result, the transaction keeps associated with the thread, which is
> returned to the thread pool. Whenever this thread is being reused, it may
> lead to "Already associated to a transaction" exception in any further
> message processing (which is not related to the actual problem in any way).
> Best regards
> Martin Landua
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-1120) Throwable is not cought in BaseLifeCycle which can result in open transactions
Throwable is not cought in BaseLifeCycle which can result in open transactions -- Key: SM-1120 URL: https://issues.apache.org/activemq/browse/SM-1120 Project: ServiceMix Issue Type: Bug Components: servicemix-common Affects Versions: 3.1 Environment: Everywhere Reporter: Martin Landua The onMessageExchange method in BaseLifeCycle only catches Exceptions. If a Throwable is thrown during processing of the Message Exchange, the transaction will not be rolled back. As a result, the transaction keeps associated with the thread, which is returned to the thread pool. Whenever this thread is being reused, it may lead to "Already associated to a transaction" exception in any further message processing (which is not related to the actual problem in any way). Best regards Martin Landua -- 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
+1 This is making a -lot- of sense. There is no reason that we need to build a huge monolithic Eclipse plugin to allow people to migrate applications to our modular server platform. I originally didn't even think about breaking it up into a group of specific plugins using a common core - even though that is what Geronimo is all about. Jay Prasad Kashyap wrote: I'm with Paul on this. I envision a Migrate2Geronimo Toolkit that will consist of a suite of individual plugins (for Eclipse and G), each handling the migration from a specific appserver to G. Of course, all these may depend on a base or common plugin. But the user will only deal with the plugin relevant to him. He will not have to install one big huge uber migrator if he only has jboss apps. Next week, we'll look forward to Jason adding a BEA2G plugin to this M2G Toolkit ;-) Cheers Prasad. On 10/30/07, Paul McMahan <[EMAIL PROTECTED]> wrote: I'm not in favor of generalizing the J2G Eclipse plugin into a super migrator that grows in complexity as we incorporate new types of source formats. I think that instead we should look into factoring out the parts of J2G that could be used for other types migrators into a separate Eclipse plugin. Then J2G could remain as J2G but could prereq this new Eclipse plugin, as would any other new migrators we create. Best wishes, Paul On Oct 29, 2007, at 11:32 AM, 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 ?? -- Thanks, Tim McConnell
Re: basic security review
I agree. Our strategy to make Geronimo secure should include an elaborate set of unit testcases, a rich set of tests in the security-testsuite in our testsuite framework, along with peer review of code in components that are potential security risks. We should aim to have imbricate or maybe even duplicate tests than have gaps. Towards this end, I created a security-testsuite in our testsuite framework. It contains one test now. I shall add some more soon. Please contribute to this testsuite with more and more tests that you can think of. Thanx Prasad On 10/29/07, Jarek Gawor <[EMAIL PROTECTED]> wrote: > 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: J2G future positioning
I'm with Paul on this. I envision a Migrate2Geronimo Toolkit that will consist of a suite of individual plugins (for Eclipse and G), each handling the migration from a specific appserver to G. Of course, all these may depend on a base or common plugin. But the user will only deal with the plugin relevant to him. He will not have to install one big huge uber migrator if he only has jboss apps. Next week, we'll look forward to Jason adding a BEA2G plugin to this M2G Toolkit ;-) Cheers Prasad. On 10/30/07, Paul McMahan <[EMAIL PROTECTED]> wrote: > I'm not in favor of generalizing the J2G Eclipse plugin into a super > migrator that grows in complexity as we incorporate new types of > source formats. I think that instead we should look into factoring > out the parts of J2G that could be used for other types migrators > into a separate Eclipse plugin. Then J2G could remain as J2G but > could prereq this new Eclipse plugin, as would any other new > migrators we create. > > Best wishes, > Paul > > > On Oct 29, 2007, at 11:32 AM, 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 ?? > > > > -- > > Thanks, > > Tim McConnell > >
[BUILD] 2.1: Failed for Revision: 590054
OpenEJB trunk at 589976 Geronimo Revision: 590054 built with tests included See the full build-0900.log file at http://people.apache.org/~prasad/binaries/trunk/20071030/build-0900.log Building Geronimo trunk at Revision: 590054 Building OpenEJB trunk at 589976 [INFO] Scanning for projects... Downloading: http://download.java.net/maven/1//org.apache.geronimo.genesis.config/poms/project-config-1.2.pom Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/genesis/config/project-config/1.2/project-config-1.2.pom 21K downloaded Downloading: http://download.java.net/maven/1//org.apache.geronimo.genesis.config/poms/config-1.2.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/genesis/config/config/1.2/config-1.2.pom Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/genesis/config/config/1.2/config-1.2.pom 1K downloaded Downloading: http://download.java.net/maven/1//org.apache.geronimo.genesis/poms/genesis-1.2.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/genesis/genesis/1.2/genesis-1.2.pom Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/genesis/genesis/1.2/genesis-1.2.pom 10K downloaded Downloading: http://download.java.net/maven/1//org.apache/poms/apache-3.pom Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/apache/3/apache-3.pom Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom 3K downloaded [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file '/home/prasad/geronimo/trunk/testsupport/pom.xml'. for project unknown [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file '/home/prasad/geronimo/trunk/testsupport/pom.xml'. for project unknown at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file '/home/prasad/geronimo/trunk/testsupport/pom.xml'. for project unknown at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1383) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:477) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:553) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:527) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: java.io.FileNotFoundException: /home/prasad/geronimo/trunk/testsupport/pom.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileReader.(FileReader.java:55) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1378) ... 17 more [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Tue Oct 30 10:51:28 EDT 2007 [INFO] Final Memory: 3M/504M [INFO]
[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_12538788 ] Viet Hung Nguyen commented on GERONIMO-3561: Anita, thanks for voicing your concerns. I was unaware that EJBs specs did not allow for ejbs to manage threads. I am currently looking for alternative ways to provide the same capabilities. One of which is the JMX Timer API (namely the javax.management.timer package in J2SE). Let me know what you think or have better solutions. In response to your second concern, we are using a remote authentication procedure provided by OpenEJB. The monitoring console (client) will have to have the authentication information beforehand, so that it can authenticate itself with the monitored server. We have tested this type of connection where one machine connects to another to grab statistics. Thanks, Viet > 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-3564) monitoring pluging: db gets too big, too quickly
[ https://issues.apache.org/jira/browse/GERONIMO-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3564: --- Attachment: geronimo-3564.patch > monitoring pluging: db gets too big, too quickly > > > Key: GERONIMO-3564 > URL: https://issues.apache.org/jira/browse/GERONIMO-3564 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: monitoring >Affects Versions: 2.1 > Environment: windows >Reporter: Viet Hung Nguyen > Attachments: geronimo-3564.patch > > > The DB used to store the snapshot statistics is growing at a very rapid rate. > It is estimated to have roughly a maximum 600k rows. This is because we are > storing one statistic per row. If we follow Erik's suggestion and group these > statistics in a CSV list and store them that way, it will reduce the number > of rows by around 5-10 times. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3564) monitoring pluging: db gets too big, too quickly
monitoring pluging: db gets too big, too quickly Key: GERONIMO-3564 URL: https://issues.apache.org/jira/browse/GERONIMO-3564 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: monitoring Affects Versions: 2.1 Environment: windows Reporter: Viet Hung Nguyen The DB used to store the snapshot statistics is growing at a very rapid rate. It is estimated to have roughly a maximum 600k rows. This is because we are storing one statistic per row. If we follow Erik's suggestion and group these statistics in a CSV list and store them that way, it will reduce the number of rows by around 5-10 times. -- 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 not in favor of generalizing the J2G Eclipse plugin into a super migrator that grows in complexity as we incorporate new types of source formats. I think that instead we should look into factoring out the parts of J2G that could be used for other types migrators into a separate Eclipse plugin. Then J2G could remain as J2G but could prereq this new Eclipse plugin, as would any other new migrators we create. Best wishes, Paul On Oct 29, 2007, at 11:32 AM, 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 ?? -- Thanks, Tim McConnell
Re: Restructuring build for flexible server
Interesting points. However, I think we should tackle this and other further restructuring in our next rev. For now, just baby steps. To dos: --- 1. Consider breaking specs after a risk-benefit analysis. 2. Change groupIds and artifactIds. While most cars(plugins) are under o.a.g.configs, there are some plugins (present plugins dir) under o.a.g.plugins. But at the end of the day, they are all plugins now. 3. Break the tree into 4-5 smaller trees. 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=12460948&framed=y&skin=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 s
