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