Re: Geronimo 3 and karaf 3

[Jean-Baptiste Onofré]

Hi Uli,

Thanks for the update, I'm gonna take a look also.

Regards
JB

On 02/03/2012 11:46 PM, uromahn wrote:

Gentlemen,

I updated all my local sources and was able to actually build G3.
Unfortunately, the "fix" posted by JB may not have resolved all the issues.

When I extract the jetty-jee6-web assembly and start the server using
'bin/karaf start' the server hangs somewhere very early in the bootstrap.
There is absolutely no message on the console and the log file shows about
10 entries or so but no error message or any other clue.

Trying to do the same with the tomcat-jee6-web assembly I was at least able
to see the command prompt but then I saw the exact same error message than
reported before with the missing bundle.

I have actually downloaded some sources and made some local changes to some
pom files to see if I get anywhere further and will report back.

On another note: I think I found another potential issue...
Karaf 3.0.0-SNAPSHOT is referencing pax-web-1.1.2-SNAPSHOT which internally
references Jetty7. However, G3 bundles Jetty8. This could most likely lead
to a version conflict and may explain why I am not able to even start G3
with the jetty assembly. I got the latest pax-web and noticed that it is
currently at 2.0.0-SNAPSHOT. I then went ahead and updated the pom.xml of
Karaf 3 to include pax-web-2.0.0-SNAPSHOT and see if that will get me
anywhere.

I will also keep you updated on this one.
-Uli

--
View this message in context: 
http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3714488.html
Sent from the Development mailing list archive at Nabble.com.


--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Geronimo 3 and karaf 3

[David Jencks]

Thanks for the update, I will try to find some time to take a look soon.

The jetty version conflict shouldn't be a problem because geronimo should not 
be loading pax-web at all.  If you have some evidence that it is, please show 
it

In more detail, geronimo uses the karaf startup code, a lot of the other code, 
and the feature and assembly code, but we make our own assemblies that don't 
include everything the same way karaf "full" does.

thanks!
david jencks

On Feb 3, 2012, at 2:46 PM, uromahn wrote:

> Gentlemen,
> 
> I updated all my local sources and was able to actually build G3.
> Unfortunately, the "fix" posted by JB may not have resolved all the issues.
> 
> When I extract the jetty-jee6-web assembly and start the server using
> 'bin/karaf start' the server hangs somewhere very early in the bootstrap.
> There is absolutely no message on the console and the log file shows about
> 10 entries or so but no error message or any other clue.
> 
> Trying to do the same with the tomcat-jee6-web assembly I was at least able
> to see the command prompt but then I saw the exact same error message than
> reported before with the missing bundle.
> 
> I have actually downloaded some sources and made some local changes to some
> pom files to see if I get anywhere further and will report back.
> 
> On another note: I think I found another potential issue...
> Karaf 3.0.0-SNAPSHOT is referencing pax-web-1.1.2-SNAPSHOT which internally
> references Jetty7. However, G3 bundles Jetty8. This could most likely lead
> to a version conflict and may explain why I am not able to even start G3
> with the jetty assembly. I got the latest pax-web and noticed that it is
> currently at 2.0.0-SNAPSHOT. I then went ahead and updated the pom.xml of
> Karaf 3 to include pax-web-2.0.0-SNAPSHOT and see if that will get me
> anywhere.
> 
> I will also keep you updated on this one.
> -Uli
> 
> --
> View this message in context: 
> http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3714488.html
> Sent from the Development mailing list archive at Nabble.com.

Re: Geronimo 3 and karaf 3

[uromahn]

Gentlemen,

I updated all my local sources and was able to actually build G3.
Unfortunately, the "fix" posted by JB may not have resolved all the issues.

When I extract the jetty-jee6-web assembly and start the server using
'bin/karaf start' the server hangs somewhere very early in the bootstrap.
There is absolutely no message on the console and the log file shows about
10 entries or so but no error message or any other clue.

Trying to do the same with the tomcat-jee6-web assembly I was at least able
to see the command prompt but then I saw the exact same error message than
reported before with the missing bundle.

I have actually downloaded some sources and made some local changes to some
pom files to see if I get anywhere further and will report back.

On another note: I think I found another potential issue...
Karaf 3.0.0-SNAPSHOT is referencing pax-web-1.1.2-SNAPSHOT which internally
references Jetty7. However, G3 bundles Jetty8. This could most likely lead
to a version conflict and may explain why I am not able to even start G3
with the jetty assembly. I got the latest pax-web and noticed that it is
currently at 2.0.0-SNAPSHOT. I then went ahead and updated the pom.xml of
Karaf 3 to include pax-web-2.0.0-SNAPSHOT and see if that will get me
anywhere.

I will also keep you updated on this one.
-Uli

--
View this message in context: 
http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3714488.html
Sent from the Development mailing list archive at Nabble.com.

Re: Geronimo 3 and karaf 3

[Jean-Baptiste Onofré]

edResolver
| mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
1.4.0.SNAPSHOT | Resolved (org.apache.geronimo.bundles:sxc-jaxb:jar:0.7.3_1)
as
/home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/geronimo/bundles/sxc-jaxb/0.7.3_1/sxc-jaxb-0.7.3_1.jar
2012-02-01 16:34:24,990 | INFO  | Thread-8 | AetherBasedResolver
| mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
1.4.0.SNAPSHOT | Resolved
(org.apache.geronimo.bundles:sxc-runtime:jar:0.7.3_1) as
/home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/geronimo/bundles/sxc-runtime/0.7.3_1/sxc-runtime-0.7.3_1.jar
2012-02-01 16:34:25,032 | INFO  | Thread-8 | AetherBasedResolver
| mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
1.4.0.SNAPSHOT | Resolved
(org.apache.felix:org.apache.felix.configadmin:jar:1.2.4) as
/home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/felix/org.apache.felix.configadmin/1.2.4/org.apache.felix.configadmin-1.2.4.jar
2012-02-01 16:34:37,561 | INFO  | FelixStartLevel  | ScrServiceMBeanImpl
| ent.internal.ScrServiceMBeanImpl   89 | 64 -
org.apache.karaf.scr.management - 3.0.0.SNAPSHOT | Deactivating the Apache
Karaf SCR Service MBean

and the following error message on the console:

ERROR: Bundle org.ops4j.pax.url.obr [25] Error starting
mvn:org.ops4j.pax.url/pax-url-obr/1.4-SNAPSHOT
(org.osgi.framework.BundleException: Unresolved constraint in bundle
org.ops4j.pax.url.obr [25]: Unable to resolve 25.0: missing requirement
[25.0] osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.lang)(version>=1.3.0)))
org.osgi.framework.BundleException: Unresolved constraint in bundle
org.ops4j.pax.url.obr [25]: Unable to resolve 25.0: missing requirement
[25.0] osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.lang)(version>=1.3.0))
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)

Any idea how to correct this and get a running server?
-Uli

--
View this message in context: 
http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3708594.html
Sent from the Development mailing list archive at Nabble.com.




--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Geronimo 3 and karaf 3

[Jean-Baptiste Onofré]

 | AetherBasedResolver
| mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
1.4.0.SNAPSHOT | Resolved
(org.apache.felix:org.apache.felix.bundlerepository:jar:1.6.6) as
/home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/felix/org.apache.felix.bundlerepository/1.6.6/org.apache.felix.bundlerepository-1.6.6.jar
2012-02-01 16:34:24,925 | INFO  | Thread-8 | AetherBasedResolver
| mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
1.4.0.SNAPSHOT | Resolved (org.apache.geronimo.bundles:sxc-jaxb:jar:0.7.3_1)
as
/home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/geronimo/bundles/sxc-jaxb/0.7.3_1/sxc-jaxb-0.7.3_1.jar
2012-02-01 16:34:24,990 | INFO  | Thread-8 | AetherBasedResolver
| mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
1.4.0.SNAPSHOT | Resolved
(org.apache.geronimo.bundles:sxc-runtime:jar:0.7.3_1) as
/home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/geronimo/bundles/sxc-runtime/0.7.3_1/sxc-runtime-0.7.3_1.jar
2012-02-01 16:34:25,032 | INFO  | Thread-8 | AetherBasedResolver
| mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
1.4.0.SNAPSHOT | Resolved
(org.apache.felix:org.apache.felix.configadmin:jar:1.2.4) as
/home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/felix/org.apache.felix.configadmin/1.2.4/org.apache.felix.configadmin-1.2.4.jar
2012-02-01 16:34:37,561 | INFO  | FelixStartLevel  | ScrServiceMBeanImpl
| ent.internal.ScrServiceMBeanImpl   89 | 64 -
org.apache.karaf.scr.management - 3.0.0.SNAPSHOT | Deactivating the Apache
Karaf SCR Service MBean

and the following error message on the console:

ERROR: Bundle org.ops4j.pax.url.obr [25] Error starting
mvn:org.ops4j.pax.url/pax-url-obr/1.4-SNAPSHOT
(org.osgi.framework.BundleException: Unresolved constraint in bundle
org.ops4j.pax.url.obr [25]: Unable to resolve 25.0: missing requirement
[25.0] osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.lang)(version>=1.3.0)))
org.osgi.framework.BundleException: Unresolved constraint in bundle
org.ops4j.pax.url.obr [25]: Unable to resolve 25.0: missing requirement
[25.0] osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.lang)(version>=1.3.0))
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)

Any idea how to correct this and get a running server?
-Uli

--
View this message in context: 
http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3708594.html
Sent from the Development mailing list archive at Nabble.com.




--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Geronimo 3 and karaf 3

[David Jencks]

2-02-01 16:34:24,844 | INFO  | Thread-8 | AetherBasedResolver  
>
> | mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
> 1.4.0.SNAPSHOT | Resolved
> (org.apache.geronimo.bundles:jaxb-impl:jar:2.2.3-1_1) as
> /home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/geronimo/bundles/jaxb-impl/2.2.3-1_1/jaxb-impl-2.2.3-1_1.jar
> 2012-02-01 16:34:24,853 | INFO  | Thread-8 | AetherBasedResolver  
>
> | mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
> 1.4.0.SNAPSHOT | Resolved
> (org.apache.geronimo.bundles:woodstox-core-asl:jar:4.1.2_1) as
> /home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/geronimo/bundles/woodstox-core-asl/4.1.2_1/woodstox-core-asl-4.1.2_1.jar
> 2012-02-01 16:34:24,859 | INFO  | Thread-8 | AetherBasedResolver  
>
> | mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
> 1.4.0.SNAPSHOT | Resolved (org.codehaus.woodstox:stax2-api:jar:3.1.1) as
> /home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/codehaus/woodstox/stax2-api/3.1.1/stax2-api-3.1.1.jar
> 2012-02-01 16:34:24,907 | INFO  | Thread-8 | AetherBasedResolver  
>
> | mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
> 1.4.0.SNAPSHOT | Resolved
> (org.apache.felix:org.apache.felix.bundlerepository:jar:1.6.6) as
> /home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/felix/org.apache.felix.bundlerepository/1.6.6/org.apache.felix.bundlerepository-1.6.6.jar
> 2012-02-01 16:34:24,925 | INFO  | Thread-8 | AetherBasedResolver  
>
> | mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
> 1.4.0.SNAPSHOT | Resolved (org.apache.geronimo.bundles:sxc-jaxb:jar:0.7.3_1)
> as
> /home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/geronimo/bundles/sxc-jaxb/0.7.3_1/sxc-jaxb-0.7.3_1.jar
> 2012-02-01 16:34:24,990 | INFO  | Thread-8 | AetherBasedResolver  
>
> | mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
> 1.4.0.SNAPSHOT | Resolved
> (org.apache.geronimo.bundles:sxc-runtime:jar:0.7.3_1) as
> /home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/geronimo/bundles/sxc-runtime/0.7.3_1/sxc-runtime-0.7.3_1.jar
> 2012-02-01 16:34:25,032 | INFO  | Thread-8 | AetherBasedResolver  
>
> | mvn.internal.AetherBasedResolver  224 | 2 - org.ops4j.pax.url.mvn -
> 1.4.0.SNAPSHOT | Resolved
> (org.apache.felix:org.apache.felix.configadmin:jar:1.2.4) as
> /home/uromahn/programs/geronimo-jetty8-javaee6-web-3.0-SNAPSHOT/system/org/apache/felix/org.apache.felix.configadmin/1.2.4/org.apache.felix.configadmin-1.2.4.jar
> 2012-02-01 16:34:37,561 | INFO  | FelixStartLevel  | ScrServiceMBeanImpl  
>
> | ent.internal.ScrServiceMBeanImpl   89 | 64 -
> org.apache.karaf.scr.management - 3.0.0.SNAPSHOT | Deactivating the Apache
> Karaf SCR Service MBean
> 
> and the following error message on the console:
> 
> ERROR: Bundle org.ops4j.pax.url.obr [25] Error starting
> mvn:org.ops4j.pax.url/pax-url-obr/1.4-SNAPSHOT
> (org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.ops4j.pax.url.obr [25]: Unable to resolve 25.0: missing requirement
> [25.0] osgi.wiring.package;
> (&(osgi.wiring.package=org.ops4j.lang)(version>=1.3.0)))
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> org.ops4j.pax.url.obr [25]: Unable to resolve 25.0: missing requirement
> [25.0] osgi.wiring.package;
> (&(osgi.wiring.package=org.ops4j.lang)(version>=1.3.0))
>   at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
>   at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>   at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
>   at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
>   at java.lang.Thread.run(Thread.java:662)
> 
> Any idea how to correct this and get a running server?
> -Uli
> 
> --
> View this message in context: 
> http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3708594.html
> Sent from the Development mailing list archive at Nabble.com.

Re: Geronimo 3 and karaf 3

[Jean-Baptiste Onofré]

Hi Ulrich and David,

regarding Karaf 3, I'm going to create a karaf-3.0 branch to freeze the 
features included and stabilize.


I'm upgrading the dependency versions right now, I will cut off this 
branch tomorrow or Monday morning.


Regards
JB

On 01/20/2012 09:17 PM, uromahn wrote:

Hi David,

Thanks for your quick response. Based on your and your fellow
committer’s comments on this thread, I suspected you were as frustrated
as well.

To answer your immediate question: I may be best to put a short but
prominent comment here: https://cwiki.apache.org/GMOxDEV/index.html

In addition, it may be helpful to update the build instructions included
in the source and put the same warning there.

At least that way, interested developers would be aware of the current
issues.

-Ulrich

*Ulrich Romahn*

Sr. MTS, Architect

*PayPal*

The safer, easier way to pay online

2211 North First Street, San Jose, CA 95131

Direct 408 967 6808 | Cell 650 430 4499

Skype uliromahn

*From:*David Jencks [via Apache Geronimo] [mailto:[hidden email]
]
*Sent:* Friday, January 20, 2012 12:12 PM
*To:* Romahn, Ulrich
*Subject:* Re: Geronimo 3 and karaf 3

HI Ulrich,

I appreciate your frustration... I've been struggling with various forms
of the current problems for more than a year and think we may finally be
close to a working stable solution. How and if these problems show up
seems to be quite dependent on your local maven environment. For
instance I have nexus installed locally and configured to never download
any org.apache.geronimo.* artifacts and that has stabilized my builds
considerably but concealed the problems other people are having from me.

I have been trying to update the build status on the geronimo dev list,
and you seem to have found the current thread on the topic. Do you have
a suggestion on a better way?

We also have a buildbot set up but I haven't figured out when it runs or
how to trigger it. Sometimes it reports interesting errors quickly and
other times it seems to just not run.

thanks for your interest!
david jencks

On Jan 20, 2012, at 11:54 AM, uromahn wrote:


 > Gentlemen:
 >
 > I am following the development on Geronimo 3 for quite a while since
we are
 > very interested in potentially using it to support a new OSGI-based
server
 > framework that we will use here.
 >
 > Today, I have refreshed my G3 sources of trunk and was trying to
build G3.
 > After reading through this thread and doing the build step-by-step (I
had to
 > go into various sub-systems and do a mvn clean install first before I
could
 > run the top level build successfully) I finally ended up with the
completed
 > assemblies. However, when trying to start G3 using the command
"./bin/karaf"
 > I am getting a failed start because some dependencies are missing.
 >
 > Unfortunately, it appears that the current state of trunk is somewhat
 > unstable. I completely understand that this happens, but I would kindly
 > suggest to post a message somewhere "warning" people wanting to build
 > G3-trunk themselves, that the result may actually not really what
they hoped
 > for.
 >
 > With a little frustration and hope for a more stable situation soon,
 >
 > kind regards,
 > -Ulrich
 >
 > --
 > View this message in context: click here.
NAML
<http://apache-geronimo.328035.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>



----------------
View this message in context: RE: Geronimo 3 and karaf 3
<http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3676525.html>
Sent from the Development mailing list archive
<http://apache-geronimo.328035.n3.nabble.com/Development-f342155.html>
at Nabble.com.


--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

RE: Geronimo 3 and karaf 3

[uromahn]

Hi David,

Thanks for your quick response. Based on your and your fellow committer's 
comments on this thread, I suspected you were as frustrated as well.

To answer your immediate question: I may be best to put a short but prominent 
comment here: https://cwiki.apache.org/GMOxDEV/index.html
In addition, it may be helpful to update the build instructions included in the 
source and put the same warning there.

At least that way, interested developers would be aware of the current issues.

-Ulrich

Ulrich Romahn
Sr. MTS, Architect

PayPal
The safer, easier way to pay online

2211 North First Street, San Jose, CA 95131
Direct  408 967 6808  |  Cell  650 430 4499
Skype  uliromahn

From: David Jencks [via Apache Geronimo] 
[mailto:ml-node+s328035n3676516...@n3.nabble.com]
Sent: Friday, January 20, 2012 12:12 PM
To: Romahn, Ulrich
Subject: Re: Geronimo 3 and karaf 3

HI Ulrich,

I appreciate your frustration... I've been struggling with various forms of the 
current problems for more than a year and think we may finally be close to a 
working stable solution.  How and if these problems show up seems to be quite 
dependent on your local maven environment.  For instance I have nexus installed 
locally and configured to never download any org.apache.geronimo.* artifacts 
and that has stabilized my builds considerably but concealed the problems other 
people are having from me.

I have been trying to update the build status on the geronimo dev list, and you 
seem to have found the current thread on the topic.  Do you have a suggestion 
on a better way?

We also have a buildbot set up but I haven't figured out when it runs or how to 
trigger it.  Sometimes it reports interesting errors quickly and other times it 
seems to just not run.

thanks for your interest!
david jencks

On Jan 20, 2012, at 11:54 AM, uromahn wrote:

> Gentlemen:
>
> I am following the development on Geronimo 3 for quite a while since we are
> very interested in potentially using it to support a new OSGI-based server
> framework that we will use here.
>
> Today, I have refreshed my G3 sources of trunk and was trying to build G3.
> After reading through this thread and doing the build step-by-step (I had to
> go into various sub-systems and do a mvn clean install first before I could
> run the top level build successfully) I finally ended up with the completed
> assemblies. However, when trying to start G3 using the command "./bin/karaf"
> I am getting a failed start because some dependencies are missing.
>
> Unfortunately, it appears that the current state of trunk is somewhat
> unstable. I completely understand that this happens, but I would kindly
> suggest to post a message somewhere "warning" people wanting to build
> G3-trunk themselves, that the result may actually not really what they hoped
> for.
>
> With a little frustration and hope for a more stable situation soon,
>
> kind regards,
> -Ulrich
>
> --
> View this message in context: 
> http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3676480.html
> Sent from the Development mailing list archive at Nabble.com.



If you reply to this email, your message will be added to the discussion below:
http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3676516.html
To unsubscribe from Geronimo 3 and karaf 3, click 
here<http://apache-geronimo.328035.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3600027&code=dXJvbWFobkBwYXlwYWwuY29tfDM2MDAwMjd8LTEyMzk5MjQ3OTg=>.
NAML<http://apache-geronimo.328035.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


--
View this message in context: 
http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3676525.html
Sent from the Development mailing list archive at Nabble.com.

Re: Geronimo 3 and karaf 3

[David Jencks]

HI Ulrich,

I appreciate your frustration... I've been struggling with various forms of the 
current problems for more than a year and think we may finally be close to a 
working stable solution.  How and if these problems show up seems to be quite 
dependent on your local maven environment.  For instance I have nexus installed 
locally and configured to never download any org.apache.geronimo.* artifacts 
and that has stabilized my builds considerably but concealed the problems other 
people are having from me.

I have been trying to update the build status on the geronimo dev list, and you 
seem to have found the current thread on the topic.  Do you have a suggestion 
on a better way?

We also have a buildbot set up but I haven't figured out when it runs or how to 
trigger it.  Sometimes it reports interesting errors quickly and other times it 
seems to just not run.

thanks for your interest!
david jencks

On Jan 20, 2012, at 11:54 AM, uromahn wrote:

> Gentlemen:
> 
> I am following the development on Geronimo 3 for quite a while since we are
> very interested in potentially using it to support a new OSGI-based server
> framework that we will use here.
> 
> Today, I have refreshed my G3 sources of trunk and was trying to build G3.
> After reading through this thread and doing the build step-by-step (I had to
> go into various sub-systems and do a mvn clean install first before I could
> run the top level build successfully) I finally ended up with the completed
> assemblies. However, when trying to start G3 using the command "./bin/karaf"
> I am getting a failed start because some dependencies are missing.
> 
> Unfortunately, it appears that the current state of trunk is somewhat
> unstable. I completely understand that this happens, but I would kindly
> suggest to post a message somewhere "warning" people wanting to build
> G3-trunk themselves, that the result may actually not really what they hoped
> for.
> 
> With a little frustration and hope for a more stable situation soon,
> 
> kind regards,
> -Ulrich
> 
> --
> View this message in context: 
> http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3676480.html
> Sent from the Development mailing list archive at Nabble.com.

Re: Geronimo 3 and karaf 3

[uromahn]

Gentlemen:

I am following the development on Geronimo 3 for quite a while since we are
very interested in potentially using it to support a new OSGI-based server
framework that we will use here.

Today, I have refreshed my G3 sources of trunk and was trying to build G3.
After reading through this thread and doing the build step-by-step (I had to
go into various sub-systems and do a mvn clean install first before I could
run the top level build successfully) I finally ended up with the completed
assemblies. However, when trying to start G3 using the command "./bin/karaf"
I am getting a failed start because some dependencies are missing.

Unfortunately, it appears that the current state of trunk is somewhat
unstable. I completely understand that this happens, but I would kindly
suggest to post a message somewhere "warning" people wanting to build
G3-trunk themselves, that the result may actually not really what they hoped
for.

With a little frustration and hope for a more stable situation soon,

kind regards,
-Ulrich

--
View this message in context: 
http://apache-geronimo.328035.n3.nabble.com/Geronimo-3-and-karaf-3-tp3600027p3676480.html
Sent from the Development mailing list archive at Nabble.com.

Re: Geronimo 3 and karaf 3

[Jean-Baptiste Onofré]

Hi David,

FYI, pax-url-aether used aether 1.11, and part of my fix consists to 
upgrade to aether 1.13.1.


I will commit a fix soon on pax-url and karaf.

Regards
JB

On 01/18/2012 06:37 PM, David Jencks wrote:

I did a build on another machine with nexus turned off and reproduced
this problem.

We (karaf people) think that it's due to aether expecting maven metadata
in the karaf system repository and ignoring any artifacts there not
represented by metadata, and downloading a remote older version of the
snapshot. I did not see this because I have my local nexus configured to
not download any geronimo artifacts. It's still not entirely clear why
aether would prefer an older copy from apache-snapshots to a newer copy
in the ~/.m2/repository repo. This might be due to a bug in the old
version of aether embedded in pax-url-aether.

thanks
david jencks

On Jan 12, 2012, at 4:43 AM, Forrest Xia wrote:




On Thu, Jan 12, 2012 at 3:29 PM, David Jencks mailto:david_jen...@yahoo.com>> wrote:

I have seen problems like this sometimes. I wonder if the pax-url
and karaf snapshots are up to date?

I locally built karaf, but no pax-url, will retry.

That might result in old artifacts (not from the build you just
did) getting downloaded and installed in the framework rather than
the ones in the server /system repo. You might also be able to use
the console to investigate why geronimo-system won't start. The
log (now at data/log/karaf.log) might show something also.

I'll see if I can find some time tomorrow to run a build on
another machine and see what happens.

thanks
david jencks



On Jan 11, 2012, at 9:58 PM, Forrest Xia wrote:


Made a build bypassing the test, but failed to start server with
this exception:

Module 1/62
org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car Server
Startup failed

org.apache.geronimo.kernel.config.LifecycleException: load of
org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car failed
at

org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:389)
at

org.apache.geronimo.system.main.EmbeddedDaemon$1.run(EmbeddedDaemon.java:261)
Caused by: org.osgi.framework.BundleException: Unresolved
constraint in bundle org.apache.geronimo.framework.j2ee-system
[129]: Unable to resolve 129.0: missing requirement [129.0]
osgi.wiring.package;
(osgi.wiring.package=org.apache.geronimo.system.osgi)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at

org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:380)
... 1 more


On Tue, Jan 10, 2012 at 11:13 PM, Kevan Miller
mailto:kevan.mil...@gmail.com>> wrote:


Looks like there's a new build issue --

http://ci.apache.org/builders/geronimo-server-trunk/builds/506/steps/compile/logs/stdio

--kevan




--
Thanks!

Regards, Forrest






--
Thanks!

Regards, Forrest





--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Geronimo 3 and karaf 3

[David Jencks]

I did a build on another machine with nexus turned off and reproduced this 
problem.

We (karaf people) think that it's due to aether expecting maven metadata in the 
karaf system repository and ignoring any artifacts there not represented by 
metadata, and downloading a remote older version of the snapshot.  I did not 
see this because I have my local nexus configured to not download any geronimo 
artifacts.  It's still not entirely clear why aether would prefer an older copy 
from apache-snapshots to a newer copy in the ~/.m2/repository repo.  This might 
be due to a bug in the old version of aether embedded in pax-url-aether.

thanks
david jencks

On Jan 12, 2012, at 4:43 AM, Forrest Xia wrote:

> 
> 
> On Thu, Jan 12, 2012 at 3:29 PM, David Jencks  wrote:
> I have seen problems like this sometimes.  I wonder if the pax-url and karaf 
> snapshots are up to date?
> I locally built karaf, but no pax-url, will retry. 
>  That might result in old artifacts (not from the build you just did) getting 
> downloaded and installed in the framework rather than the ones in the server 
> /system repo.  You might also be able to use the console to investigate why 
> geronimo-system won't start.  The log (now at data/log/karaf.log) might show 
> something also.
> 
> I'll see if I can find some time tomorrow to run a build on another machine 
> and see what happens.
> 
> thanks
> david jencks
> 
> 
> 
> On Jan 11, 2012, at 9:58 PM, Forrest Xia wrote:
> 
>> Made a build bypassing the test, but failed to start server with this 
>> exception:
>> 
>> Module  1/62 org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car  
>>Server Startup failed
>> 
>> org.apache.geronimo.kernel.config.LifecycleException: load of 
>> org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car failed
>> at 
>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:389)
>> at 
>> org.apache.geronimo.system.main.EmbeddedDaemon$1.run(EmbeddedDaemon.java:261)
>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in 
>> bundle org.apache.geronimo.framework.j2ee-system [129]: Unable to resolve 
>> 129.0: missing requirement [129.0] osgi.wiring.package; 
>> (osgi.wiring.package=org.apache.geronimo.system.osgi)
>> at 
>> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>> at 
>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:380)
>> ... 1 more
>> 
>> 
>> On Tue, Jan 10, 2012 at 11:13 PM, Kevan Miller  
>> wrote:
>> 
>> Looks like there's a new build issue -- 
>> http://ci.apache.org/builders/geronimo-server-trunk/builds/506/steps/compile/logs/stdio
>> 
>> --kevan
>> 
>> 
>> 
>> -- 
>> Thanks!
>> 
>> Regards, Forrest
>> 
> 
> 
> 
> 
> -- 
> Thanks!
> 
> Regards, Forrest
> 

Re: Geronimo 3 and karaf 3

[Forrest Xia]

On Thu, Jan 12, 2012 at 3:29 PM, David Jencks wrote:

> I have seen problems like this sometimes.  I wonder if the pax-url and
> karaf snapshots are up to date?
>
I locally built karaf, but no pax-url, will retry.

>  That might result in old artifacts (not from the build you just did)
> getting downloaded and installed in the framework rather than the ones in
> the server /system repo.  You might also be able to use the console to
> investigate why geronimo-system won't start.  The log (now at
> data/log/karaf.log) might show something also.
>
> I'll see if I can find some time tomorrow to run a build on another
> machine and see what happens.
>
> thanks
> david jencks
>
>
>
> On Jan 11, 2012, at 9:58 PM, Forrest Xia wrote:
>
> Made a build bypassing the test, but failed to start server with this
> exception:
>
> Module  1/62
> org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car
> Server Startup failed
>
> org.apache.geronimo.kernel.config.LifecycleException: load of
> org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car failed
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:389)
> at
> org.apache.geronimo.system.main.EmbeddedDaemon$1.run(EmbeddedDaemon.java:261)
> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
> bundle org.apache.geronimo.framework.j2ee-system [129]: Unable to resolve
> 129.0: missing requirement [129.0] osgi.wiring.package;
> (osgi.wiring.package=org.apache.geronimo.system.osgi)
> at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:380)
> ... 1 more
>
>
> On Tue, Jan 10, 2012 at 11:13 PM, Kevan Miller wrote:
>
>>
>> Looks like there's a new build issue --
>> http://ci.apache.org/builders/geronimo-server-trunk/builds/506/steps/compile/logs/stdio
>>
>> --kevan
>
>
>
>
> --
> Thanks!
>
> Regards, Forrest
>
>
>


-- 
Thanks!

Regards, Forrest

Re: Geronimo 3 and karaf 3

[David Jencks]

I have seen problems like this sometimes.  I wonder if the pax-url and karaf 
snapshots are up to date?  That might result in old artifacts (not from the 
build you just did) getting downloaded and installed in the framework rather 
than the ones in the server /system repo.  You might also be able to use the 
console to investigate why geronimo-system won't start.  The log (now at 
data/log/karaf.log) might show something also.

I'll see if I can find some time tomorrow to run a build on another machine and 
see what happens.

thanks
david jencks


On Jan 11, 2012, at 9:58 PM, Forrest Xia wrote:

> Made a build bypassing the test, but failed to start server with this 
> exception:
> 
> Module  1/62 org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car   
>   Server Startup failed
> 
> org.apache.geronimo.kernel.config.LifecycleException: load of 
> org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car failed
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:389)
> at 
> org.apache.geronimo.system.main.EmbeddedDaemon$1.run(EmbeddedDaemon.java:261)
> Caused by: org.osgi.framework.BundleException: Unresolved constraint in 
> bundle org.apache.geronimo.framework.j2ee-system [129]: Unable to resolve 
> 129.0: missing requirement [129.0] osgi.wiring.package; 
> (osgi.wiring.package=org.apache.geronimo.system.osgi)
> at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:380)
> ... 1 more
> 
> 
> On Tue, Jan 10, 2012 at 11:13 PM, Kevan Miller  wrote:
> 
> Looks like there's a new build issue -- 
> http://ci.apache.org/builders/geronimo-server-trunk/builds/506/steps/compile/logs/stdio
> 
> --kevan
> 
> 
> 
> -- 
> Thanks!
> 
> Regards, Forrest
> 

Re: Geronimo 3 and karaf 3

[Forrest Xia]

Made a build bypassing the test, but failed to start server with this
exception:

Module  1/62
org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car
Server Startup failed

org.apache.geronimo.kernel.config.LifecycleException: load of
org.apache.geronimo.framework/j2ee-system/3.0-SNAPSHOT/car failed
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:389)
at
org.apache.geronimo.system.main.EmbeddedDaemon$1.run(EmbeddedDaemon.java:261)
Caused by: org.osgi.framework.BundleException: Unresolved constraint in
bundle org.apache.geronimo.framework.j2ee-system [129]: Unable to resolve
129.0: missing requirement [129.0] osgi.wiring.package;
(osgi.wiring.package=org.apache.geronimo.system.osgi)
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:380)
... 1 more


On Tue, Jan 10, 2012 at 11:13 PM, Kevan Miller wrote:

>
> Looks like there's a new build issue --
> http://ci.apache.org/builders/geronimo-server-trunk/builds/506/steps/compile/logs/stdio
>
> --kevan




-- 
Thanks!

Regards, Forrest

Re: Geronimo 3 and karaf 3

[Kevan Miller]

Looks like there's a new build issue -- 
http://ci.apache.org/builders/geronimo-server-trunk/builds/506/steps/compile/logs/stdio

--kevan

Re: Geronimo 3 and karaf 3

[Kevan Miller]

On Jan 6, 2012, at 11:04 AM, David Jencks wrote:

> A different problem...
> 
> [WARNING] The POM for 
> org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT is 
> invalid, transitive dependencies (if any) will not be available, enable debug 
> logging for more details
> 
> I don't know how to find out what the problem is since I don't have it 
> locally.  Can we run with -X?

Buildbot is seeing the same test failure that I am…

http://ci.apache.org/builders/geronimo-server-trunk/builds/502/steps/compile/logs/stdio

--kevan

Re: Geronimo 3 and karaf 3

[Kevan Miller]

I've added -X to buildbot, since I can't hit the same problem, locally.

--kevan
On Jan 6, 2012, at 11:04 AM, David Jencks wrote:

> A different problem...
> 
> [WARNING] The POM for 
> org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT is 
> invalid, transitive dependencies (if any) will not be available, enable debug 
> logging for more details
> 
> I don't know how to find out what the problem is since I don't have it 
> locally.  Can we run with -X?
> 
> david jencks
> 
> On Jan 6, 2012, at 7:43 AM, Kevan Miller wrote:
> 
>> 
>> On Jan 5, 2012, at 9:40 PM, David Jencks wrote:
>> 
>>> yup, karaf just copied those classes into itself to avoid some java  7 
>>> problem just committed a fix along with some other work.
>> 
>> Still seems to be problems… 
>> http://ci.apache.org/builders/geronimo-server-trunk/builds/501
>> 
>> --kevan
>> 
> 

Re: Geronimo 3 and karaf 3

[Kevan Miller]

On Jan 6, 2012, at 11:04 AM, David Jencks wrote:

> A different problem...
> 
> [WARNING] The POM for 
> org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT is 
> invalid, transitive dependencies (if any) will not be available, enable debug 
> logging for more details
> 
> I don't know how to find out what the problem is since I don't have it 
> locally.  Can we run with -X?

By the way, here are the test errors:

---
Test set: org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest
---
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.075 sec <<< 
FAILURE!
testEmptyPlanProcessing(org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest)
  Time elapsed: 0.052 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/codehaus/plexus/classworlds/realm/ClassRealm
at 
org.codehaus.plexus.DefaultContainerConfiguration.(DefaultContainerConfiguration.java:197)
at 
org.codehaus.plexus.PlexusTestCase.setupContainer(PlexusTestCase.java:82)
at 
org.codehaus.plexus.PlexusTestCase.getContainer(PlexusTestCase.java:139)
at org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:191)
at 
org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest.setUp(PlanProcessorMojoTest.java:59)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:79)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
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:597)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: java.lang.ClassNotFoundException: 
org.codehaus.plexus.classworlds.realm.ClassRealm
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 23 more

testNoEnvironmentPlanProcessing(org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest)
  Time elapsed: 0.001 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/codehaus/plexus/classworlds/realm/ClassRealm
at 
org.codehaus.plexus.DefaultContainerConfiguration.(DefaultContainerConfiguration.java:197)
at 
org.codehaus.plexus.PlexusTestCase.setupContainer(PlexusTestCase.java:82)
at 
org.codehaus.plexus.PlexusTestCase.getContainer(PlexusTestCase.java:139)
at org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:191)
at 
org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest.setUp(PlanProcessorMojoTest.java:59)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:79)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java

Re: Geronimo 3 and karaf 3

[Kevan Miller]

On Jan 6, 2012, at 11:04 AM, David Jencks wrote:

> A different problem...
> 
> [WARNING] The POM for 
> org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT is 
> invalid, transitive dependencies (if any) will not be available, enable debug 
> logging for more details
> 
> I don't know how to find out what the problem is since I don't have it 
> locally.  Can we run with -X?

So far, I'm getting the following, if I run with tests:

---
 T E S T S
---
Running org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.096 sec <<< 
FAILURE!
Running org.apache.geronimo.mavenplugins.car.DependencyTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running org.apache.geronimo.mavenplugins.car.PluginMetadataTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.281 sec

Results :

Tests in error: 
  
testEmptyPlanProcessing(org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest)
  
testNoEnvironmentPlanProcessing(org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest)

Tests run: 7, Failures: 0, Errors: 2, Skipped: 0


And the following, if I run without tests:

[INFO] 
[INFO] Building Geronimo Framework, Feature :: DS and Metatype 3.0-SNAPSHOT
[INFO] 
[WARNING] The POM for 
org.apache.karaf.tooling:karaf-maven-plugin:jar:3.0.0-20111221.171238-221 is 
invalid, transitive dependencies (if any) will not be available, enable debug 
logging for more details
Downloading: 
http://repository.apache.org/snapshots/org/apache/felix/org.apache.felix.scr/1.6.1-SNAPSHOT/maven-metadata.xml
Downloading: 
http://snapshots.repository.codehaus.org/org/apache/felix/org.apache.felix.scr/1.6.1-SNAPSHOT/maven-metadata.xml
Downloading: 
http://oss.sonatype.org/content/groups/jetty-with-staging/org/apache/felix/org.apache.felix.scr/1.6.1-SNAPSHOT/maven-metadata.xml
Downloading: 
http://nexus.openqa.org/content/repositories/snapshots/org/apache/felix/org.apache.felix.scr/1.6.1-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://repository.apache.org/snapshots/org/apache/felix/org.apache.felix.scr/1.6.1-SNAPSHOT/maven-metadata.xml
 (786 B at 1.1 KB/sec)
[INFO] 
[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ declarative-services 
---
[INFO] Deleting file set: 
/Users/kevan/geronimo/server/trunk/framework/features/declarative-services/target
 (included: [**], excluded: [])
[INFO] 
[INFO] --- genesis-maven-plugin:2.0:validate-configuration (default) @ 
declarative-services ---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (default) @ 
declarative-services ---
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.0:process (default) @ 
declarative-services ---
[INFO] 
[INFO] --- karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor 
(default-features-generate-descriptor) @ declarative-services ---
[WARNING] The POM for 
org.apache.karaf.tooling:karaf-maven-plugin:jar:3.0.0-20111221.171238-221 is 
invalid, transitive dependencies (if any) will not be available, enable debug 
logging for more details
Jan 6, 2012 11:58:58 AM org.sonatype.guice.bean.reflect.LoadedClass
WARNING: Error injecting: 
org.apache.karaf.tooling.features.GenerateDescriptorMojo
java.lang.NoClassDefFoundError: 
org/apache/maven/shared/filtering/MavenFilteringException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getDeclaredConstructors(Class.java:1836)
at 
com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:243)
at 
com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:96)
at 
com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:628)
at 
com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:835)
at 
com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:769)
at 
com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:254)
at 
com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:205)
at 
com.google.inject.internal.InjectorImpl.getInternalFactory(InjectorImpl.java:843)
at 
com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:957)
at 
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:990)
at 
com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:951)
at 
com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1003)
at 
org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDefer

Re: Geronimo 3 and karaf 3

[Kevan Miller]

On Jan 6, 2012, at 11:04 AM, David Jencks wrote:

> A different problem...
> 
> [WARNING] The POM for 
> org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT is 
> invalid, transitive dependencies (if any) will not be available, enable debug 
> logging for more details
> 
> I don't know how to find out what the problem is since I don't have it 
> locally.  Can we run with -X?

The build bot configuration is here 
https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/geronimo.conf

And yes, we could add a -X. However, I'll see if I can recreate locally. Will 
be simpler…

--kevan

Re: Geronimo 3 and karaf 3

[David Jencks]

A different problem...

[WARNING] The POM for 
org.apache.geronimo.testsupport:testsupport-common:jar:3.0-SNAPSHOT is invalid, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details

I don't know how to find out what the problem is since I don't have it locally. 
 Can we run with -X?

david jencks

On Jan 6, 2012, at 7:43 AM, Kevan Miller wrote:

> 
> On Jan 5, 2012, at 9:40 PM, David Jencks wrote:
> 
>> yup, karaf just copied those classes into itself to avoid some java  7 
>> problem just committed a fix along with some other work.
> 
> Still seems to be problems… 
> http://ci.apache.org/builders/geronimo-server-trunk/builds/501
> 
> --kevan
> 

Re: Geronimo 3 and karaf 3

[Kevan Miller]

On Jan 5, 2012, at 9:40 PM, David Jencks wrote:

> yup, karaf just copied those classes into itself to avoid some java  7 
> problem just committed a fix along with some other work.

Still seems to be problems… 
http://ci.apache.org/builders/geronimo-server-trunk/builds/501

--kevan

Re: Geronimo 3 and karaf 3

[David Jencks]

yup, karaf just copied those classes into itself to avoid some java  7 
problem just committed a fix along with some other work.

david jencks

On Jan 5, 2012, at 6:16 PM, Kevan Miller wrote:

> 
> I'm seeing this same failure, locally -- 
> http://ci.apache.org/builders/geronimo-server-trunk/builds/498/steps/compile/logs/stdio
> 
> Anyone else?
> 
> --kevan

Re: Geronimo 3 and karaf 3

[Kevan Miller]

I'm seeing this same failure, locally -- 
http://ci.apache.org/builders/geronimo-server-trunk/builds/498/steps/compile/logs/stdio

Anyone else?

--kevan

Re: Geronimo 3 and karaf 3

[David Jencks]

I think that changing the namespace and adding the new evaluator attribute fix 
this!

thanks
david jencks

On Dec 20, 2011, at 8:18 AM, Rex Wang wrote:

> 
> 
> 2011/12/20 David Jencks 
> 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
>   placeholder-suffix="]" ignore-missing-locations="true"
> system-properties="override" evaluator="jexl">
>  
>  
> 
> 
>  
>  file:///url
> 
> 
> 
> 
> ...
> 
> 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

Re: Geronimo 3 and karaf 3

[David Jencks]

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  wrote:
> 
> 
> On Wed, Jan 4, 2012 at 5:32 PM, Forrest Xia  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.(GBeanAttribute.java:252)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.buildAttributes(GBeanInstance.java:396)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.(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.(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  wrote:
> 
> 
> On Thu, Dec 22, 2011 at 2:27 AM, David Jencks  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  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 
>

Re: Geronimo 3 and karaf 3

[Forrest Xia]

On Wed, Jan 4, 2012 at 5:39 PM, Forrest Xia  wrote:

>
>
> On Wed, Jan 4, 2012 at 5:32 PM, Forrest Xia  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.(GBeanAttribute.java:252)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.buildAttributes(GBeanInstance.java:396)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.(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.(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  wrote:
>>
>>>
>>>
>>> On Thu, Dec 22, 2011 at 2:27 AM, David Jencks 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 
 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_M

Re: Geronimo 3 and karaf 3

[Forrest Xia]

On Wed, Jan 4, 2012 at 5:32 PM, Forrest Xia  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  wrote:
>
>>
>>
>> On Thu, Dec 22, 2011 at 2:27 AM, David Jencks 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 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 loo

Re: Geronimo 3 and karaf 3

[Forrest Xia]

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  wrote:

>
>
> On Thu, Dec 22, 2011 at 2:27 AM, David Jencks 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 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 kara

Re: Geronimo 3 and karaf 3

[Forrest Xia]

On Thu, Dec 22, 2011 at 2:27 AM, David Jencks 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 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 gbe

Re: Geronimo 3 and karaf 3

[David Jencks]

I pushed a karaf snapshot maybe that will help?  I don't see this problem 
locally.

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  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 cl

Re: Geronimo 3 and karaf 3

[Forrest Xia]

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 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
> separa

Re: Geronimo 3 and karaf 3

[David Jencks]

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
>>  

Re: Geronimo 3 and karaf 3

[David Jencks]

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

Re: Geronimo 3 and karaf 3

[Rex Wang]

2011/12/20 David Jencks 

> 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

 
 


 
 file:///url




...

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

Re: Geronimo 3 and karaf 3

[Forrest Xia]

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 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

Re: Geronimo 3 and karaf 3

[viola lu]

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é wrote:

> 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

[Jean-Baptiste Onofré]

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

[David Jencks]

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

Geronimo 3 and karaf 3

[David Jencks]

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