[VOTE] Release Geronimo 2.1.8 RC2

[Forrest Xia]

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

[jira] [Updated] (GERONIMO-6236) Component name doesn't displayed right for test suit : ejb-tests

[Tina Li (Updated) (JIRA)]

 [ 
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

[Tina Li (Resolved) (JIRA)]

 [ 
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

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

[jira] [Created] (GERONIMO-6240) Move to osgi 4.3 and karaf trunk

[David Jencks (Created) (JIRA)]

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

[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

Cancelled [VOTE] Release Geronimo 2.1.8

[Forrest Xia]

Cancel it.

On Tue, Dec 20, 2011 at 9:37 AM, Forrest Xia  wrote:

>
>
> On Tue, Dec 20, 2011 at 3:49 AM, Forrest Xia  wrote:
>
>>
>>
>> On Mon, Dec 19, 2011 at 10:54 PM, Forrest Xia 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
>
>


-- 
Thanks!

Regards, Forrest

Re: [VOTE] Release Geronimo 2.1.8

[Forrest Xia]

On Tue, Dec 20, 2011 at 3:49 AM, Forrest Xia  wrote:

>
>
> On Mon, Dec 19, 2011 at 10:54 PM, Forrest Xia  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

[jira] [Assigned] (GERONIMO-6236) Component name doesn't displayed right for test suit : ejb-tests

[Tina Li (Assigned) (JIRA)]

 [ 
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 Tomcat 6.0.35.1

[Shawn Jiang]

+1

On Sun, Dec 18, 2011 at 8:17 PM, Forrest Xia  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-355/
>  
>
> 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

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: [VOTE] Release Geronimo 2.1.8

[Forrest Xia]

On Mon, Dec 19, 2011 at 10:54 PM, Forrest Xia  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