Re: [VOTE] Release Geronimo 2.1.8
On Mon, Dec 19, 2011 at 10:54 PM, Forrest Xia forres...@gmail.com wrote: Hi folks, A release candidate for Geronimo 2.1.8 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.8/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-367/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-367/org/apache/geronimo/geronimo/2.1.8/geronimo-2.1.8-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-367/org/apache/geronimo/geronimo/2.1.8/geronimo-2.1.8-source-release.zip A tck execution against 2.1.8 tag is ongoing, and will be finished around 16 hours later. I will update the status here. Java ee 5 tck passed for both Tomcat and Jetty assembly. Now only one jaxb tck failure, if we switch the jaxb api back to RI's, then no failure. Please comment if we should hold on the release until we fixed the jaxb tck failure. My point is to go ahead to have 2.1.8 out of the door, then look for the reason of the jaxb tck failure. any thoughts? Based on the awareness of the jaxb tck failure and the fact of all java ee 5 CTS passed, my vote +1 The vote will be open for 72 hours. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) -- Thanks! Regards, Forrest -- Thanks! Regards, Forrest
Re: Geronimo 3 and karaf 3
Great job David, It looks good to me (non-binding ;)). Regards JB On 12/20/2011 02:08 AM, David Jencks wrote: I've been spending a lot of time working to rebase geronimo on karaf 3 so we can have a maintainable future and get stuff like osgi 4.3, up to date aries components, and the experimental region support now in karaf. After a lot of work I have everything except clustering building and after turning off a couple problematic modules the tomcat-javaee6 server starts and the web admin console appears to work at least a little bit. I'd like a little vacation this year and would like to commit this work first so that others can help with the loose ends if they like. I'll probably be around to answer questions in any case. The modules that don't start are: activemq-broker-blueprint. The ${X + Y} stuff is not getting evaluated at all. I don't know if this is an xbean-blueprint problem or an aries blueprint problem or a side effect of running in geronimo. As a result activemq-ra and tomcat-console-activemq can't be started. client-deployer. I think this is a pretty simple gbean name problem but I haven't looked into it. Here are some of the changes: -- assemble the server using a combination of karaf assembly from features and kars and geronimo assembly from geronimo plugins. We now use the same base karaf assembly stuff as the normal default full karaf assembly (except I might have left out the spring feature repository). -- basic geronimo components such as the kernel, configuration manager, dependency manager, deployer, and service config builder are set up as osgi declarative services so they start without any geronimo configuration. They are generally configured through config admin as appropriate. Most of these also have gbean wrappers so they can be accessed through gbean references. -- geronimo is started from a DS component, EmbeddedDaemon. -- I think I'm using the karaf remote jmx security rather than ours. The capabilities are similar but not identical. Some other things that are not working yet: -- The (gogo) geronimo console commands that work through remote gbean proxies don't work AFAIK. Probably one way to fix this would be to expose some more of the DS components using gbean wrappers, but I haven't looked into this yet. -- the app client (as well as the client-deployer) is not working yet at all. We may be able to use command line args to tell the EmbeddedDaemon it's an app client, or possibly not. We may be able to use a karaf instance to supply different ConfigAdmin settings to e.g. the local attribute manager to convince it it's an app client. Similarly the separate console-like things presumably won't work either. -- the EditableConfigurationManager needs to be replaced by a separate component that edits the configuration it gets from the normal configuration manager. I think this affects some part of the admin console. I'f there's no strong opposition I'd like to commit this tomorrow. Many thanks david jencks -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Geronimo 3 and karaf 3
Hi, David: There is a jira about activemq-broker-blueprint. The ${X + Y} stuff is not getting evaluated at all., It's already fixed by Rex, may be helpful to you. https://issues.apache.org/jira/browse/GERONIMO-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#issue-tabs which is dependent on https://issues.apache.org/jira/browse/ARIES-727 On Tue, Dec 20, 2011 at 4:51 PM, Jean-Baptiste Onofré j...@nanthrax.netwrote: Great job David, It looks good to me (non-binding ;)). Regards JB On 12/20/2011 02:08 AM, David Jencks wrote: I've been spending a lot of time working to rebase geronimo on karaf 3 so we can have a maintainable future and get stuff like osgi 4.3, up to date aries components, and the experimental region support now in karaf. After a lot of work I have everything except clustering building and after turning off a couple problematic modules the tomcat-javaee6 server starts and the web admin console appears to work at least a little bit. I'd like a little vacation this year and would like to commit this work first so that others can help with the loose ends if they like. I'll probably be around to answer questions in any case. The modules that don't start are: activemq-broker-blueprint. The ${X + Y} stuff is not getting evaluated at all. I don't know if this is an xbean-blueprint problem or an aries blueprint problem or a side effect of running in geronimo. As a result activemq-ra and tomcat-console-activemq can't be started. client-deployer. I think this is a pretty simple gbean name problem but I haven't looked into it. Here are some of the changes: -- assemble the server using a combination of karaf assembly from features and kars and geronimo assembly from geronimo plugins. We now use the same base karaf assembly stuff as the normal default full karaf assembly (except I might have left out the spring feature repository). -- basic geronimo components such as the kernel, configuration manager, dependency manager, deployer, and service config builder are set up as osgi declarative services so they start without any geronimo configuration. They are generally configured through config admin as appropriate. Most of these also have gbean wrappers so they can be accessed through gbean references. -- geronimo is started from a DS component, EmbeddedDaemon. -- I think I'm using the karaf remote jmx security rather than ours. The capabilities are similar but not identical. Some other things that are not working yet: -- The (gogo) geronimo console commands that work through remote gbean proxies don't work AFAIK. Probably one way to fix this would be to expose some more of the DS components using gbean wrappers, but I haven't looked into this yet. -- the app client (as well as the client-deployer) is not working yet at all. We may be able to use command line args to tell the EmbeddedDaemon it's an app client, or possibly not. We may be able to use a karaf instance to supply different ConfigAdmin settings to e.g. the local attribute manager to convince it it's an app client. Similarly the separate console-like things presumably won't work either. -- the EditableConfigurationManager needs to be replaced by a separate component that edits the configuration it gets from the normal configuration manager. I think this affects some part of the admin console. I'f there's no strong opposition I'd like to commit this tomorrow. Many thanks david jencks -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- viola Apache Geronimo
Re: Geronimo 3 and karaf 3
David, thanks a lot! You deserve a good rest. Please feel free to commit your change into trunk, it's open for your great changes :) Wish you have a happy and great X'mas holiday! On Tue, Dec 20, 2011 at 1:10 PM, David Jencks david_jen...@yahoo.comwrote: more not-yet-working inline On Dec 19, 2011, at 5:08 PM, David Jencks wrote: I've been spending a lot of time working to rebase geronimo on karaf 3 so we can have a maintainable future and get stuff like osgi 4.3, up to date aries components, and the experimental region support now in karaf. After a lot of work I have everything except clustering building and after turning off a couple problematic modules the tomcat-javaee6 server starts and the web admin console appears to work at least a little bit. I'd like a little vacation this year and would like to commit this work first so that others can help with the loose ends if they like. I'll probably be around to answer questions in any case. The modules that don't start are: activemq-broker-blueprint. The ${X + Y} stuff is not getting evaluated at all. I don't know if this is an xbean-blueprint problem or an aries blueprint problem or a side effect of running in geronimo. As a result activemq-ra and tomcat-console-activemq can't be started. client-deployer. I think this is a pretty simple gbean name problem but I haven't looked into it. Here are some of the changes: -- assemble the server using a combination of karaf assembly from features and kars and geronimo assembly from geronimo plugins. We now use the same base karaf assembly stuff as the normal default full karaf assembly (except I might have left out the spring feature repository). -- basic geronimo components such as the kernel, configuration manager, dependency manager, deployer, and service config builder are set up as osgi declarative services so they start without any geronimo configuration. They are generally configured through config admin as appropriate. Most of these also have gbean wrappers so they can be accessed through gbean references. -- geronimo is started from a DS component, EmbeddedDaemon. -- I think I'm using the karaf remote jmx security rather than ours. The capabilities are similar but not identical. Some other things that are not working yet: -- The (gogo) geronimo console commands that work through remote gbean proxies don't work AFAIK. Probably one way to fix this would be to expose some more of the DS components using gbean wrappers, but I haven't looked into this yet. -- the app client (as well as the client-deployer) is not working yet at all. We may be able to use command line args to tell the EmbeddedDaemon it's an app client, or possibly not. We may be able to use a karaf instance to supply different ConfigAdmin settings to e.g. the local attribute manager to convince it it's an app client. Similarly the separate console-like things presumably won't work either. -- the EditableConfigurationManager needs to be replaced by a separate component that edits the configuration it gets from the normal configuration manager. I think this affects some part of the admin console. --I couldn't get the xml stream 1.2 and jaxb 2.2 to work with the spec jars as bundles.According to http://servicemix.396122.n5.nabble.com/DISCUSS-Enhance-specs-to-work-better-with-JRE-td5001108.htmleven if you do get them to work (as we seem to have up to now by not exposing the packages from the framework) that breaks other stuff. I think we need to investigate the karaf-activator stuff guillaume wrote and adapt our specs to use it. At the moment I have the framework lying and claiming later versions for the xmlstream and jaxb packages. I haven't found any documentation for karaf-activator yet. -- the build uses a lot more memory. I typically run out of permgen twice during the build with MAVEN_OPTS = -XX:MaxPermSize=512m -Xms1024m -Xmx2048m -- startup AFAIK only works as ./bin/karaf -l rather than our geronimo scripts. Again, I have to increase memory settings for the server to fully start. I'f there's no strong opposition I'd like to commit this tomorrow. Many thanks david jencks david jencks -- Thanks! Regards, Forrest
Re: [VOTE] Release Geronimo Tomcat 6.0.35.1
+1 On Sun, Dec 18, 2011 at 8:17 PM, Forrest Xia forres...@gmail.com wrote: Please vote for the Geronimo Tomcat 6.0.35.1 release, which is based on Tomcat 6.0.35 tag, and will be used in Geronimo 2.1.8 release. The components up for vote are: https://repository.apache.org/content/repositories/orgapachegeronimo-355/org/apache/geronimo/ext/tomcat/tomcat-parent-6.0.35/6.0.35.1/tomcat-parent-6.0.35-6.0.35.1-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-355/org/apache/geronimo/ext/tomcat/tomcat-parent-6.0.35/6.0.35.1/tomcat-parent-6.0.35-6.0.35.1-source-release.zip Staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-014 https://repository.apache.org/content/repositories/orgapachegeronimo-355/ https://repository.apache.org/content/repositories/orgapachegeronimo-014 tag is here: https://svn.apache.org/repos/asf/geronimo/external/tags/tomcat-parent-6.0.35.1/ Vote open 72 hours [ ] +1 release this [ ] 0 don't care [ ] -1 don't release this (please explain) -- Thanks! Regards, Forrest -- Shawn
[jira] [Assigned] (GERONIMO-6236) Component name doesn't displayed right for test suit : ejb-tests
[ https://issues.apache.org/jira/browse/GERONIMO-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tina Li reassigned GERONIMO-6236: - Assignee: Tina Li Component name doesn't displayed right for test suit : ejb-tests Key: GERONIMO-6236 URL: https://issues.apache.org/jira/browse/GERONIMO-6236 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: testsuite Affects Versions: 3.0-beta-1 Environment: JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr9-20110624_85526 (JIT enabled, AOT enabled) Reporter: Tina Li Assignee: Tina Li Priority: Trivial Attachments: ejb-ejb-3.0-beta-1.jar 1.Download geronimo server: http://mirror.bjtu.edu.cn/apache//geronimo/3.0-beta-1/geronimo-tomcat7-javaee6-3.0-beta-1-bin.tar.gz 2.Unzip and started server successfully 3.Deploy ejb-test application of test suite: testsuite-enterpris-testsuite-ejb-tests-ejb-ejb successfully 4.Check component name under EJB-JARs of User Assets porlet, then found displayed name is: ${pom.groupId}/${pom.artifactId}/${version}/jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Geronimo 2.1.8
On Tue, Dec 20, 2011 at 3:49 AM, Forrest Xia forres...@gmail.com wrote: On Mon, Dec 19, 2011 at 10:54 PM, Forrest Xia forres...@gmail.com wrote: Hi folks, A release candidate for Geronimo 2.1.8 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.8/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-367/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-367/org/apache/geronimo/geronimo/2.1.8/geronimo-2.1.8-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-367/org/apache/geronimo/geronimo/2.1.8/geronimo-2.1.8-source-release.zip A tck execution against 2.1.8 tag is ongoing, and will be finished around 16 hours later. I will update the status here. Java ee 5 tck passed for both Tomcat and Jetty assembly. Now only one jaxb tck failure, if we switch the jaxb api back to RI's, then no failure. Since this jaxb tck failure, we have to revert back to use jaxb-api, not our geronimo jaxb spec api, so cancel this vote. Please comment if we should hold on the release until we fixed the jaxb tck failure. My point is to go ahead to have 2.1.8 out of the door, then look for the reason of the jaxb tck failure. any thoughts? Based on the awareness of the jaxb tck failure and the fact of all java ee 5 CTS passed, my vote +1 The vote will be open for 72 hours. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) -- Thanks! Regards, Forrest -- Thanks! Regards, Forrest -- Thanks! Regards, Forrest
Cancelled [VOTE] Release Geronimo 2.1.8
Cancel it. On Tue, Dec 20, 2011 at 9:37 AM, Forrest Xia forres...@gmail.com wrote: On Tue, Dec 20, 2011 at 3:49 AM, Forrest Xia forres...@gmail.com wrote: On Mon, Dec 19, 2011 at 10:54 PM, Forrest Xia forres...@gmail.comwrote: Hi folks, A release candidate for Geronimo 2.1.8 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.8/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-367/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-367/org/apache/geronimo/geronimo/2.1.8/geronimo-2.1.8-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-367/org/apache/geronimo/geronimo/2.1.8/geronimo-2.1.8-source-release.zip A tck execution against 2.1.8 tag is ongoing, and will be finished around 16 hours later. I will update the status here. Java ee 5 tck passed for both Tomcat and Jetty assembly. Now only one jaxb tck failure, if we switch the jaxb api back to RI's, then no failure. Since this jaxb tck failure, we have to revert back to use jaxb-api, not our geronimo jaxb spec api, so cancel this vote. Please comment if we should hold on the release until we fixed the jaxb tck failure. My point is to go ahead to have 2.1.8 out of the door, then look for the reason of the jaxb tck failure. any thoughts? Based on the awareness of the jaxb tck failure and the fact of all java ee 5 CTS passed, my vote +1 The vote will be open for 72 hours. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) -- Thanks! Regards, Forrest -- Thanks! Regards, Forrest -- Thanks! Regards, Forrest -- Thanks! Regards, Forrest
Re: Geronimo 3 and karaf 3
2011/12/20 David Jencks david_jen...@yahoo.com I've been spending a lot of time working to rebase geronimo on karaf 3 so we can have a maintainable future and get stuff like osgi 4.3, up to date aries components, and the experimental region support now in karaf. After a lot of work I have everything except clustering building and after turning off a couple problematic modules the tomcat-javaee6 server starts and the web admin console appears to work at least a little bit. I'd like a little vacation this year and would like to commit this work first so that others can help with the loose ends if they like. I'll probably be around to answer questions in any case. The modules that don't start are: activemq-broker-blueprint. The ${X + Y} stuff is not getting evaluated at all. I don't know if this is an xbean-blueprint problem or an aries blueprint problem or a side effect of running in geronimo. As a result activemq-ra and tomcat-console-activemq can't be started. Hi David, neither xbean-blueprint nor aries-blueprint can correctly do such evaluation. So for 3.0-beta-1 release, I provided an interim fix of Aries-727 and release our aries-blueprint in external folder: http://svn.apache.org/repos/asf/geronimo/external/tags/blueprint-0.3.0.1/ However, we should not use this approach for trunk. I had refactored the codes in Aries-727 based on the discussion in Aries mailing list. The new approach has been applied to Aries trunk. The current approach is as following: 1, depends on following org.apache.aries.blueprint.core-0.4.1-SNAPSHOT org.apache.aries.blueprint.jexl.evaluator-0.1.1-SNAPSHOT ( http://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-jexl-evaluator/ ) 2. use the new namespace blueprint-ext 1.2.0 xmlns:ext=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.2.0; 3. use the ext:property-placeholder with the new attribute *evaluator=jexl * to do evaluation ext:property-placeholder placeholder-prefix=$[ placeholder-suffix=] ignore-missing-locations=true system-properties=override *evaluator=jexl* ext:default-properties ext:property name=name value=value / ext:property name=a value=Hello / ext:property name=b value=FooBar / /ext:default-properties ext:locationfile:///url/ext:location /ext:property-placeholder bean id=bar class=org.apache.aries.blueprint.sample.Bar property name=value value=$[a+b] ... basically, this will make the blueprint bundle reference a PropertyEvaluator service with the property org.apache.aries.blueprint.ext.evaluator.name=jexl to do the evaluate. Hope this helps, and I can help fix this issue after your commit. Merry Christmas and happy new year! -Rex client-deployer. I think this is a pretty simple gbean name problem but I haven't looked into it. Here are some of the changes: -- assemble the server using a combination of karaf assembly from features and kars and geronimo assembly from geronimo plugins. We now use the same base karaf assembly stuff as the normal default full karaf assembly (except I might have left out the spring feature repository). -- basic geronimo components such as the kernel, configuration manager, dependency manager, deployer, and service config builder are set up as osgi declarative services so they start without any geronimo configuration. They are generally configured through config admin as appropriate. Most of these also have gbean wrappers so they can be accessed through gbean references. -- geronimo is started from a DS component, EmbeddedDaemon. -- I think I'm using the karaf remote jmx security rather than ours. The capabilities are similar but not identical. Some other things that are not working yet: -- The (gogo) geronimo console commands that work through remote gbean proxies don't work AFAIK. Probably one way to fix this would be to expose some more of the DS components using gbean wrappers, but I haven't looked into this yet. -- the app client (as well as the client-deployer) is not working yet at all. We may be able to use command line args to tell the EmbeddedDaemon it's an app client, or possibly not. We may be able to use a karaf instance to supply different ConfigAdmin settings to e.g. the local attribute manager to convince it it's an app client. Similarly the separate console-like things presumably won't work either. -- the EditableConfigurationManager needs to be replaced by a separate component that edits the configuration it gets from the normal configuration manager. I think this affects some part of the admin console. I'f there's no strong opposition I'd like to commit this tomorrow. Many thanks david jencks -- Lei Wang (Rex) rwonly AT apache.org
[jira] [Created] (GERONIMO-6240) Move to osgi 4.3 and karaf trunk
Move to osgi 4.3 and karaf trunk Key: GERONIMO-6240 URL: https://issues.apache.org/jira/browse/GERONIMO-6240 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: core Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Move to osgi R 4.3. Base geronimo more directly on karaf and in particular karaf trunk (3.0-SNAPSHOT) Use karaf assembly tools as much as possible, and don't copy and modify karaf code Start geronimo (in karaf) from a DS component (command line args are now visible from karaf) Make the basic server components (kernel, configurationManager, service config builder, deployer) DS components that don't need a geronimo plan but start automatically when their bundles are started. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo 3 and karaf 3
OK, I just committed this stuff, with reference to GERONIMO-6240. Some more hints I can build all the way through with MAVEN_OPTS=-XX:MaxPermSize=2048m -Xms2048m -Xmx4096m I can start karaf after setting export JAVA_MAX_MEM=2048m export JAVA_MAX_PERM_MEM=512m The car packaging is set up to stop and wait if it gets stuck. In an earlier version of this you'd get the karaf console and you could use karaf commands to investigate what was going on. For some reason this isn't working now. If you get into this situation, you need to kill the maven java process some way. Usually setting a breakpoint at DependencyManager line 571 will show you a bundle that has a resolution problem that you can then fix. The problem with the console deploy-type commands I think relates to using the karaf RMIRegistry. I'm going to modify it so it includes the port as a service property, then we can look for the osgi service and get its port instead of the port gbean attribute. thanks david jencks On Dec 19, 2011, at 9:10 PM, David Jencks wrote: more not-yet-working inline On Dec 19, 2011, at 5:08 PM, David Jencks wrote: I've been spending a lot of time working to rebase geronimo on karaf 3 so we can have a maintainable future and get stuff like osgi 4.3, up to date aries components, and the experimental region support now in karaf. After a lot of work I have everything except clustering building and after turning off a couple problematic modules the tomcat-javaee6 server starts and the web admin console appears to work at least a little bit. I'd like a little vacation this year and would like to commit this work first so that others can help with the loose ends if they like. I'll probably be around to answer questions in any case. The modules that don't start are: activemq-broker-blueprint. The ${X + Y} stuff is not getting evaluated at all. I don't know if this is an xbean-blueprint problem or an aries blueprint problem or a side effect of running in geronimo. As a result activemq-ra and tomcat-console-activemq can't be started. client-deployer. I think this is a pretty simple gbean name problem but I haven't looked into it. Here are some of the changes: -- assemble the server using a combination of karaf assembly from features and kars and geronimo assembly from geronimo plugins. We now use the same base karaf assembly stuff as the normal default full karaf assembly (except I might have left out the spring feature repository). -- basic geronimo components such as the kernel, configuration manager, dependency manager, deployer, and service config builder are set up as osgi declarative services so they start without any geronimo configuration. They are generally configured through config admin as appropriate. Most of these also have gbean wrappers so they can be accessed through gbean references. -- geronimo is started from a DS component, EmbeddedDaemon. -- I think I'm using the karaf remote jmx security rather than ours. The capabilities are similar but not identical. Some other things that are not working yet: -- The (gogo) geronimo console commands that work through remote gbean proxies don't work AFAIK. Probably one way to fix this would be to expose some more of the DS components using gbean wrappers, but I haven't looked into this yet. -- the app client (as well as the client-deployer) is not working yet at all. We may be able to use command line args to tell the EmbeddedDaemon it's an app client, or possibly not. We may be able to use a karaf instance to supply different ConfigAdmin settings to e.g. the local attribute manager to convince it it's an app client. Similarly the separate console-like things presumably won't work either. -- the EditableConfigurationManager needs to be replaced by a separate component that edits the configuration it gets from the normal configuration manager. I think this affects some part of the admin console. --I couldn't get the xml stream 1.2 and jaxb 2.2 to work with the spec jars as bundles.According to http://servicemix.396122.n5.nabble.com/DISCUSS-Enhance-specs-to-work-better-with-JRE-td5001108.html even if you do get them to work (as we seem to have up to now by not exposing the packages from the framework) that breaks other stuff. I think we need to investigate the karaf-activator stuff guillaume wrote and adapt our specs to use it. At the moment I have the framework lying and claiming later versions for the xmlstream and jaxb packages. I haven't found any documentation for karaf-activator yet. -- the build uses a lot more memory. I typically run out of permgen twice during the build with MAVEN_OPTS = -XX:MaxPermSize=512m -Xms1024m -Xmx2048m -- startup AFAIK only works as ./bin/karaf -l rather than our geronimo scripts. Again, I have to increase memory settings for the server to fully start. I'f
Re: Geronimo 3 and karaf 3
BTW, to get the regions/isolation stuff working I think we are going to need to replace our use of BundleListener/SynchronousBundleListener with the (updated-for-4.3) aries RecursiveBundleTracker. I think we'll need also change from ConfigurationActivator to an extender pattern. I'd guess the ConfigurationActivator functionality could be moved to DependencyManager rather than having an additional tracker. thanks david jencks On Dec 20, 2011, at 10:13 AM, David Jencks wrote: OK, I just committed this stuff, with reference to GERONIMO-6240. Some more hints I can build all the way through with MAVEN_OPTS=-XX:MaxPermSize=2048m -Xms2048m -Xmx4096m I can start karaf after setting export JAVA_MAX_MEM=2048m export JAVA_MAX_PERM_MEM=512m The car packaging is set up to stop and wait if it gets stuck. In an earlier version of this you'd get the karaf console and you could use karaf commands to investigate what was going on. For some reason this isn't working now. If you get into this situation, you need to kill the maven java process some way. Usually setting a breakpoint at DependencyManager line 571 will show you a bundle that has a resolution problem that you can then fix. The problem with the console deploy-type commands I think relates to using the karaf RMIRegistry. I'm going to modify it so it includes the port as a service property, then we can look for the osgi service and get its port instead of the port gbean attribute. thanks david jencks On Dec 19, 2011, at 9:10 PM, David Jencks wrote: more not-yet-working inline On Dec 19, 2011, at 5:08 PM, David Jencks wrote: I've been spending a lot of time working to rebase geronimo on karaf 3 so we can have a maintainable future and get stuff like osgi 4.3, up to date aries components, and the experimental region support now in karaf. After a lot of work I have everything except clustering building and after turning off a couple problematic modules the tomcat-javaee6 server starts and the web admin console appears to work at least a little bit. I'd like a little vacation this year and would like to commit this work first so that others can help with the loose ends if they like. I'll probably be around to answer questions in any case. The modules that don't start are: activemq-broker-blueprint. The ${X + Y} stuff is not getting evaluated at all. I don't know if this is an xbean-blueprint problem or an aries blueprint problem or a side effect of running in geronimo. As a result activemq-ra and tomcat-console-activemq can't be started. client-deployer. I think this is a pretty simple gbean name problem but I haven't looked into it. Here are some of the changes: -- assemble the server using a combination of karaf assembly from features and kars and geronimo assembly from geronimo plugins. We now use the same base karaf assembly stuff as the normal default full karaf assembly (except I might have left out the spring feature repository). -- basic geronimo components such as the kernel, configuration manager, dependency manager, deployer, and service config builder are set up as osgi declarative services so they start without any geronimo configuration. They are generally configured through config admin as appropriate. Most of these also have gbean wrappers so they can be accessed through gbean references. -- geronimo is started from a DS component, EmbeddedDaemon. -- I think I'm using the karaf remote jmx security rather than ours. The capabilities are similar but not identical. Some other things that are not working yet: -- The (gogo) geronimo console commands that work through remote gbean proxies don't work AFAIK. Probably one way to fix this would be to expose some more of the DS components using gbean wrappers, but I haven't looked into this yet. -- the app client (as well as the client-deployer) is not working yet at all. We may be able to use command line args to tell the EmbeddedDaemon it's an app client, or possibly not. We may be able to use a karaf instance to supply different ConfigAdmin settings to e.g. the local attribute manager to convince it it's an app client. Similarly the separate console-like things presumably won't work either. -- the EditableConfigurationManager needs to be replaced by a separate component that edits the configuration it gets from the normal configuration manager. I think this affects some part of the admin console. --I couldn't get the xml stream 1.2 and jaxb 2.2 to work with the spec jars as bundles.According to http://servicemix.396122.n5.nabble.com/DISCUSS-Enhance-specs-to-work-better-with-JRE-td5001108.html even if you do get them to work (as we seem to have up to now by not exposing the packages from the framework) that breaks other stuff. I think we need to investigate the karaf-activator stuff guillaume wrote and adapt
[jira] [Updated] (GERONIMO-6236) Component name doesn't displayed right for test suit : ejb-tests
[ https://issues.apache.org/jira/browse/GERONIMO-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tina Li updated GERONIMO-6236: -- Attachment: GERONIMO-6236.patch Problem fixed,patch attached. Component name doesn't displayed right for test suit : ejb-tests Key: GERONIMO-6236 URL: https://issues.apache.org/jira/browse/GERONIMO-6236 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: testsuite Affects Versions: 3.0-beta-1 Environment: JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr9-20110624_85526 (JIT enabled, AOT enabled) Reporter: Tina Li Assignee: Tina Li Priority: Trivial Fix For: 3.0-beta-1 Attachments: GERONIMO-6236.patch, ejb-ejb-3.0-beta-1.jar 1.Download geronimo server: http://mirror.bjtu.edu.cn/apache//geronimo/3.0-beta-1/geronimo-tomcat7-javaee6-3.0-beta-1-bin.tar.gz 2.Unzip and started server successfully 3.Deploy ejb-test application of test suite: testsuite-enterpris-testsuite-ejb-tests-ejb-ejb successfully 4.Check component name under EJB-JARs of User Assets porlet, then found displayed name is: ${pom.groupId}/${pom.artifactId}/${version}/jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (GERONIMO-6236) Component name doesn't displayed right for test suit : ejb-tests
[ https://issues.apache.org/jira/browse/GERONIMO-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tina Li resolved GERONIMO-6236. --- Resolution: Fixed Fix Version/s: 3.0-beta-1 Component name doesn't displayed right for test suit : ejb-tests Key: GERONIMO-6236 URL: https://issues.apache.org/jira/browse/GERONIMO-6236 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: testsuite Affects Versions: 3.0-beta-1 Environment: JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr9-20110624_85526 (JIT enabled, AOT enabled) Reporter: Tina Li Assignee: Tina Li Priority: Trivial Fix For: 3.0-beta-1 Attachments: GERONIMO-6236.patch, ejb-ejb-3.0-beta-1.jar 1.Download geronimo server: http://mirror.bjtu.edu.cn/apache//geronimo/3.0-beta-1/geronimo-tomcat7-javaee6-3.0-beta-1-bin.tar.gz 2.Unzip and started server successfully 3.Deploy ejb-test application of test suite: testsuite-enterpris-testsuite-ejb-tests-ejb-ejb successfully 4.Check component name under EJB-JARs of User Assets porlet, then found displayed name is: ${pom.groupId}/${pom.artifactId}/${version}/jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[VOTE] Release Geronimo 2.1.8 RC2
Hi folks, A release candidate for Geronimo 2.1.8 has been created and staged. The tag has been created here: https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.8/ The staging repo is here: https://repository.apache.org/content/repositories/orgapachegeronimo-377/ The main artifacts up for vote are the source release archives: https://repository.apache.org/content/repositories/orgapachegeronimo-377/org/apache/geronimo/geronimo/2.1.8/geronimo-2.1.8-source-release.tar.gz https://repository.apache.org/content/repositories/orgapachegeronimo-377/org/apache/geronimo/geronimo/2.1.8/geronimo-2.1.8-source-release.zip A tck execution against 2.1.8 tag is ongoing, and will be finished around 16 hours later. I will update the status here. The vote will be open for 72 hours. [ ] +1 about time to push this out the door [ ] 0 no opinion [ ] -1 not this one (please explain why) -- Thanks! Regards, Forrest