You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Forrest Xia <fo...@gmail.com> on 2012/01/04 10:32:51 UTC
Re: Geronimo 3 and karaf 3
I got some time to try the trunk change locally after G 2.1.8 release
stuffs are basically done :-)
Several findings about the trunk changes:
1. The server trunk can only be compiled with Maven 3, that's the reason it
failed to compile in the TCK environment(the maven version used in TCK env
is 2.2.1). I will update the TCK env in the coming days.
2. The testsuite cannot be executed since geronimo-maven-plugin cannot
launch the server now. This issue will also block TCK execution.
3. The command line interfaces has big changes, I cannot find
startup/shutdown/geronimo scripts now. I do not look into the changes
further, so I even don't know how to launch the server now.
So generally, I think we need a introduction about how to use the trunk
build now.
On Thu, Dec 22, 2011 at 5:14 PM, Forrest Xia <fo...@gmail.com> wrote:
>
>
> On Thu, Dec 22, 2011 at 2:27 AM, David Jencks <da...@yahoo.com>wrote:
>
>> I pushed a karaf snapshot.... maybe that will help? I don't see this
>> problem locally.
>>
> No help for server build in AHP, I will try it locally. thanks!
>
>
>>
>> thanks
>> david jencks
>>
>> On Dec 21, 2011, at 8:18 AM, Forrest Xia wrote:
>>
>> Trunk build failed with this error when building a new module *Geronimo
>> Framework, Feature :: DS and Metatype*
>>
>> [INFO] Internal error in the plugin manager executing goal
>> 'org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor':
>> Unable to find the mojo 'features-generate-descriptor' (or one of its
>> required components) in the plugin
>> 'org.apache.karaf.tooling:karaf-maven-plugin'
>> Component descriptor cannot be found in the component repository:
>> org.sonatype.aether.RepositorySystem.
>>
>>
>> On Tue, Dec 20, 2011 at 2:06 PM, David Jencks <da...@yahoo.com>wrote:
>>
>>> 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<https://issues.apache.org/jira/browse/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.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
>>
>>
>>
>
>
> --
> Thanks!
>
> Regards, Forrest
>
>
--
Thanks!
Regards, Forrest
Re: Geronimo 3 and karaf 3
Posted by David Jencks <da...@yahoo.com>.
Hi Forrest,
I've seen some problems like this and don't know exactly what causes them. Some old artifacts have gotten into the build: LocalAttributeManager is no longer a gbean and j2ee-system doesn't try to set it up as a gbean. It might be related to KARAF-910. For me this issue seems to sometimes cause aether to download an old remote copy of some artifact rather than using the one in the karaf/geronimo system repo. Could you look in your geronimo instance and see what the j2ee-system bundle is in the system repo and in the data cache? The log might also provide a clue.
thanks
david jencks
On Jan 4, 2012, at 1:42 AM, Forrest Xia wrote:
>
>
> On Wed, Jan 4, 2012 at 5:39 PM, Forrest Xia <fo...@gmail.com> wrote:
>
>
> On Wed, Jan 4, 2012 at 5:32 PM, Forrest Xia <fo...@gmail.com> wrote:
> I got some time to try the trunk change locally after G 2.1.8 release stuffs are basically done :-)
>
> Several findings about the trunk changes:
> 1. The server trunk can only be compiled with Maven 3, that's the reason it failed to compile in the TCK environment(the maven version used in TCK env is 2.2.1). I will update the TCK env in the coming days.
> 2. The testsuite cannot be executed since geronimo-maven-plugin cannot launch the server now. This issue will also block TCK execution.
> 3. The command line interfaces has big changes, I cannot find startup/shutdown/geronimo scripts now. I do not look into the changes further, so I even don't know how to launch the server now.
> Sorry, I reread the mail thread and got known that how to start the server now: bin/karaf -l
> Hit this exception when I tried on my ubuntu box:
>
> geronimo> Booting Geronimo Kernel (in Java 1.6.0_29)...
> Module 1/62 org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car Server Startup failed
>
> org.apache.geronimo.kernel.config.LifecycleException: start of org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car failed
> at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:803)
> at org.apache.geronimo.system.main.EmbeddedDaemon$1.run(EmbeddedDaemon.java:265)
> Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Unknown start exception
> at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:527)
> at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:286)
> at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:787)
> ... 1 more
> Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: Getter method not found Attribute Name: GBeanInfo, Type: class org.apache.geronimo.gbean.GBeanInfo, GBeanInstance: org.apache.geronimo.system.configuration.LocalAttributeManager
> at org.apache.geronimo.gbean.runtime.GBeanAttribute.<init>(GBeanAttribute.java:252)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.buildAttributes(GBeanInstance.java:396)
> at org.apache.geronimo.gbean.runtime.GBeanInstance.<init>(GBeanInstance.java:266)
> at org.apache.geronimo.kernel.basic.BasicKernel.loadGBean(BasicKernel.java:431)
> at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:452)
> ... 3 more
> Caused by: java.lang.NoSuchMethodException: org.apache.geronimo.system.configuration.LocalAttributeManager.getGBeanInfo()
> at java.lang.Class.getMethod(Class.java:1605)
> at org.apache.geronimo.gbean.runtime.GBeanAttribute.<init>(GBeanAttribute.java:237)
> ... 7 more
>
>
> So generally, I think we need a introduction about how to use the trunk build now.
>
>
> On Thu, Dec 22, 2011 at 5:14 PM, Forrest Xia <fo...@gmail.com> wrote:
>
>
> On Thu, Dec 22, 2011 at 2:27 AM, David Jencks <da...@yahoo.com> wrote:
> I pushed a karaf snapshot.... maybe that will help? I don't see this problem locally.
> No help for server build in AHP, I will try it locally. thanks!
>
>
> thanks
> david jencks
>
> On Dec 21, 2011, at 8:18 AM, Forrest Xia wrote:
>
>> Trunk build failed with this error when building a new module Geronimo Framework, Feature :: DS and Metatype
>>
>> [INFO] Internal error in the plugin manager executing goal 'org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor': Unable to find the mojo 'features-generate-descriptor' (or one of its required components) in the plugin 'org.apache.karaf.tooling:karaf-maven-plugin'
>> Component descriptor cannot be found in the component repository: org.sonatype.aether.RepositorySystem.
>>
>>
>> On Tue, Dec 20, 2011 at 2:06 PM, David Jencks <da...@yahoo.com> wrote:
>> 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 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
>>
>
>
>
>
> --
> Thanks!
>
> Regards, Forrest
>
>
>
>
> --
> Thanks!
>
> Regards, Forrest
>
>
>
>
> --
> Thanks!
>
> Regards, Forrest
>
>
>
>
> --
> Thanks!
>
> Regards, Forrest
>
Re: Geronimo 3 and karaf 3
Posted by Forrest Xia <fo...@gmail.com>.
On Wed, Jan 4, 2012 at 5:39 PM, Forrest Xia <fo...@gmail.com> wrote:
>
>
> On Wed, Jan 4, 2012 at 5:32 PM, Forrest Xia <fo...@gmail.com> wrote:
>
>> I got some time to try the trunk change locally after G 2.1.8 release
>> stuffs are basically done :-)
>>
>> Several findings about the trunk changes:
>> 1. The server trunk can only be compiled with Maven 3, that's the reason
>> it failed to compile in the TCK environment(the maven version used in TCK
>> env is 2.2.1). I will update the TCK env in the coming days.
>> 2. The testsuite cannot be executed since geronimo-maven-plugin cannot
>> launch the server now. This issue will also block TCK execution.
>> 3. The command line interfaces has big changes, I cannot find
>> startup/shutdown/geronimo scripts now. I do not look into the changes
>> further, so I even don't know how to launch the server now.
>>
> Sorry, I reread the mail thread and got known that how to start the server
> now: bin/karaf -l
>
Hit this exception when I tried on my ubuntu box:
geronimo> Booting Geronimo Kernel (in Java 1.6.0_29)...
Module 1/62
org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car
Server Startup failed
org.apache.geronimo.kernel.config.LifecycleException: start of
org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car failed
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:803)
at
org.apache.geronimo.system.main.EmbeddedDaemon$1.run(EmbeddedDaemon.java:265)
Caused by: org.apache.geronimo.kernel.config.InvalidConfigException:
Unknown start exception
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:527)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:286)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:787)
... 1 more
Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: Getter
method not found Attribute Name: GBeanInfo, Type: class
org.apache.geronimo.gbean.GBeanInfo, GBeanInstance:
org.apache.geronimo.system.configuration.LocalAttributeManager
at
org.apache.geronimo.gbean.runtime.GBeanAttribute.<init>(GBeanAttribute.java:252)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.buildAttributes(GBeanInstance.java:396)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.<init>(GBeanInstance.java:266)
at
org.apache.geronimo.kernel.basic.BasicKernel.loadGBean(BasicKernel.java:431)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:452)
... 3 more
Caused by: java.lang.NoSuchMethodException:
org.apache.geronimo.system.configuration.LocalAttributeManager.getGBeanInfo()
at java.lang.Class.getMethod(Class.java:1605)
at
org.apache.geronimo.gbean.runtime.GBeanAttribute.<init>(GBeanAttribute.java:237)
... 7 more
>
>> So generally, I think we need a introduction about how to use the trunk
>> build now.
>>
>>
>> On Thu, Dec 22, 2011 at 5:14 PM, Forrest Xia <fo...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Dec 22, 2011 at 2:27 AM, David Jencks <da...@yahoo.com>wrote:
>>>
>>>> I pushed a karaf snapshot.... maybe that will help? I don't see this
>>>> problem locally.
>>>>
>>> No help for server build in AHP, I will try it locally. thanks!
>>>
>>>
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Dec 21, 2011, at 8:18 AM, Forrest Xia wrote:
>>>>
>>>> Trunk build failed with this error when building a new module *Geronimo
>>>> Framework, Feature :: DS and Metatype*
>>>>
>>>> [INFO] Internal error in the plugin manager executing goal
>>>> 'org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor':
>>>> Unable to find the mojo 'features-generate-descriptor' (or one of its
>>>> required components) in the plugin
>>>> 'org.apache.karaf.tooling:karaf-maven-plugin'
>>>> Component descriptor cannot be found in the component repository:
>>>> org.sonatype.aether.RepositorySystem.
>>>>
>>>>
>>>> On Tue, Dec 20, 2011 at 2:06 PM, David Jencks <da...@yahoo.com>wrote:
>>>>
>>>>> 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<https://issues.apache.org/jira/browse/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.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
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks!
>>>
>>> Regards, Forrest
>>>
>>>
>>
>>
>> --
>> Thanks!
>>
>> Regards, Forrest
>>
>>
>
>
> --
> Thanks!
>
> Regards, Forrest
>
>
--
Thanks!
Regards, Forrest
Re: Geronimo 3 and karaf 3
Posted by Forrest Xia <fo...@gmail.com>.
On Wed, Jan 4, 2012 at 5:32 PM, Forrest Xia <fo...@gmail.com> wrote:
> I got some time to try the trunk change locally after G 2.1.8 release
> stuffs are basically done :-)
>
> Several findings about the trunk changes:
> 1. The server trunk can only be compiled with Maven 3, that's the reason
> it failed to compile in the TCK environment(the maven version used in TCK
> env is 2.2.1). I will update the TCK env in the coming days.
> 2. The testsuite cannot be executed since geronimo-maven-plugin cannot
> launch the server now. This issue will also block TCK execution.
> 3. The command line interfaces has big changes, I cannot find
> startup/shutdown/geronimo scripts now. I do not look into the changes
> further, so I even don't know how to launch the server now.
>
Sorry, I reread the mail thread and got known that how to start the server
now: bin/karaf -l
>
> So generally, I think we need a introduction about how to use the trunk
> build now.
>
>
> On Thu, Dec 22, 2011 at 5:14 PM, Forrest Xia <fo...@gmail.com> wrote:
>
>>
>>
>> On Thu, Dec 22, 2011 at 2:27 AM, David Jencks <da...@yahoo.com>wrote:
>>
>>> I pushed a karaf snapshot.... maybe that will help? I don't see this
>>> problem locally.
>>>
>> No help for server build in AHP, I will try it locally. thanks!
>>
>>
>>>
>>> thanks
>>> david jencks
>>>
>>> On Dec 21, 2011, at 8:18 AM, Forrest Xia wrote:
>>>
>>> Trunk build failed with this error when building a new module *Geronimo
>>> Framework, Feature :: DS and Metatype*
>>>
>>> [INFO] Internal error in the plugin manager executing goal
>>> 'org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor':
>>> Unable to find the mojo 'features-generate-descriptor' (or one of its
>>> required components) in the plugin
>>> 'org.apache.karaf.tooling:karaf-maven-plugin'
>>> Component descriptor cannot be found in the component repository:
>>> org.sonatype.aether.RepositorySystem.
>>>
>>>
>>> On Tue, Dec 20, 2011 at 2:06 PM, David Jencks <da...@yahoo.com>wrote:
>>>
>>>> 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<https://issues.apache.org/jira/browse/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.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
>>>
>>>
>>>
>>
>>
>> --
>> Thanks!
>>
>> Regards, Forrest
>>
>>
>
>
> --
> Thanks!
>
> Regards, Forrest
>
>
--
Thanks!
Regards, Forrest