[jira] [Closed] (GERONIMO-5472) Java EE 6 sample: fileupload run incorrectly on tomcat-assembly.

[Forrest Xia (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Forrest Xia closed GERONIMO-5472.
-

Resolution: Fixed

Verified the latest sample with the latest build, this sample is OK now, so 
close this jira.

> Java EE 6 sample: fileupload run incorrectly on tomcat-assembly.
> 
>
> Key: GERONIMO-5472
> URL: https://issues.apache.org/jira/browse/GERONIMO-5472
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 3.0
>Reporter: Wang Guang Zhe
>Assignee: Ivan
> Fix For: 3.0
>
>
> 1. The fileupload sample is under samples/javaee6, first checkout it from 
> samples trunk and build it.
> 2. Deploy the war package on tomcat-assembly server after it is started.
> 3. After the sample is deployed and started successfully, visit 
> http://localhost:8080/fileupload-javaee6/, you will be asked to select file 
> to upload. Select a text file which is not larger than 10kb, and click  
> submit.
> 4. The right response page will show the content of the file you submitted. 
> But on tomcat-assembly,it responses with
> 
>  HttpServletRequest.getParts() returns an empty collection!
>  HttpServletRequest.getPart(String name) returns null!
> The error stack is:
> java.lang.NullPointerException
> at 
> org.apache.geronimo.samples.javaee6.fileupload.MessageFilter.doFilter
> (MessageFilter.java:48)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
> icationFilterChain.java:242)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
> ilterChain.java:208)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
> alve.java:243)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
> alve.java:201)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
> invoke(GeronimoStandardContext.java:675)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
> nimoBeforeAfterValve.java:47)
> at 
> org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(Protecte
> dTargetValve.java:53)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> ava:146)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
> ava:108)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> ve.java:118)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
> a:402)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
> :254)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
> ss(Http11Protocol.java:267)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
> ss(Http11Protocol.java:245)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoin
> t.java:260)
> at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
> at 
> org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(Th
> readPool.java:344)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source
> )
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: less-osgi-friendly code drop

[David Jencks]

On Jul 13, 2011, at 9:46 PM, David Blevins wrote:

> 
> On Jul 11, 2011, at 12:54 AM, David Jencks wrote:
> 
>> testSpecializedBeanNotInstantiated(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationIntegrationTest)
>> testSpecializingBeanHasBindingsOfSpecializedAndSpecializingBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest)
>> testSpecializingBeanHasNameOfSpecializedBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest)
>> testSpecializingClassDirectlyExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsNothing.DirectlyExtendsNothingTest)
>> testSpecializingClassDirectlyExtendsSimpleBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsSimpleBean.DirectlyExtendsSimpleBeanTest)
>> testSpecializingClassImplementsInterfaceAndExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.implementInterfaceAndExtendsNothing.ImplementsInterfaceAndExtendsNothingTest)
>> testSpecializingAndSpecializedBeanHasName(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.sameName.SameNameTest)
> 
> Have all but 3 of these passing in the embedded container in my local copy.  
> The 3 that fail are "broken" ones.  Simply need to add validation for those.  
> My impl code is a bit hacked -- currently only works for @Stateful and not 
> exactly implemented in the right spot -- but otherwise looks like a good 
> approach.  Will clean it up and check it in tomorrow.
> 
> 

Excellent!  On the geronimo side I've changed things around so that we have one 
openejb appInfo tree for the entire application and use it to set up the owb 
context.  This _ought_ to fix the problem in g. that I was seeing that the owb 
context didn't include any of the specialized classes (since it was looking at 
only one of the modules in the ear).  However I'm still cleaning up loose ends 
so apps will deploy ok :-)

thanks
david jencks


> -David
> 

Re: less-osgi-friendly code drop

[David Blevins]

On Jul 11, 2011, at 12:54 AM, David Jencks wrote:

>  
> testSpecializedBeanNotInstantiated(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationIntegrationTest)
>  
> testSpecializingBeanHasBindingsOfSpecializedAndSpecializingBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest)
>  
> testSpecializingBeanHasNameOfSpecializedBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationTest)
>  
> testSpecializingClassDirectlyExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsNothing.DirectlyExtendsNothingTest)
>  
> testSpecializingClassDirectlyExtendsSimpleBean(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.directlyExtendsSimpleBean.DirectlyExtendsSimpleBeanTest)
>  
> testSpecializingClassImplementsInterfaceAndExtendsNothing(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.implementInterfaceAndExtendsNothing.ImplementsInterfaceAndExtendsNothingTest)
>  
> testSpecializingAndSpecializedBeanHasName(org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.broken.sameName.SameNameTest)

Have all but 3 of these passing in the embedded container in my local copy.  
The 3 that fail are "broken" ones.  Simply need to add validation for those.  
My impl code is a bit hacked -- currently only works for @Stateful and not 
exactly implemented in the right spot -- but otherwise looks like a good 
approach.  Will clean it up and check it in tomorrow.


-David

[jira] [Created] (GERONIMO-6076) Graphics cannot be displayed on monitoring porlet

[Shenghao Fang (JIRA)]

Graphics cannot be displayed on monitoring porlet
-

 Key: GERONIMO-6076
 URL: https://issues.apache.org/jira/browse/GERONIMO-6076
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: console
Affects Versions: 3.0
Reporter: Shenghao Fang


Graphics cannot be displayed on monitoring porlet.

This is a regression by GERONIMO-5674.

Monitoring portlet requires chart related dojo library which was removed by 
GERONIMO-5674.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (GERONIMODEVTOOLS-762) GEP needs a nightly builds repositary

[Han Hong Fang (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065003#comment-13065003
 ] 

Han Hong Fang commented on GERONIMODEVTOOLS-762:


Yes, Kevan, totally agree with you. 

Nightly build material was removed from 
http://apache.org/dist/geronimo/eclipse/nightly, and it located at 
http://people.apache.org/builds/geronimo/eclipse/nightly 
(http://people.apache.org/builds is for staging the GEP releases before they go 
into production environment).

Janet

> GEP needs a nightly builds repositary
> -
>
> Key: GERONIMODEVTOOLS-762
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-762
> Project: Geronimo-Devtools
>  Issue Type: Wish
>  Components: eclipse-plugin
>Affects Versions: 3.0
>Reporter: Yi Xiao
>Assignee: Yi Xiao
>  Labels: build, gep,, nightly
> Attachments: gep_nightly_build.patch
>
>
> The GEP had a nightly build repo before(refer to: 
> http://geronimo.apache.org/development-tools.html#DevelopmentTools-NightlyBuilds),
>  but it does not work now. So, I thought we should set up a environment to 
> redo it.
> I've attached a patch to resolve the issue temporally. If you want to test it 
> in your local environment, should add below content to your maven's 
> settings.xml file:
> 
>   geronimo-devtools-nightly-repo
>   people.apache.org.username
>   people.apache.org.password
> 
> Thank Janet for helping me test to upload the devtools onto the apache site.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Only bind DataSource reference to openejb global tree ?

[Ivan]

Go ahead to commit the changes to trunk at r1146536, now we should not see
any warning while starting and stopping the server.

2011/7/13 Ivan 

> Hi, for solving the remote access to the data source reference, now all the
> references in the global scope will be bind to the openejb global tree.
> While it brought some issues, in
> https://issues.apache.org/jira/browse/GERONIMO-6074, I committed some
> changes to avoid bind the empty context. But while starting up the server,
> we still see some name already bind exception, and seems that it is caused
> some global ejb references are bind on the tree twice, one is in the
> XBeanJndiFactory, anther is on the OpenEJB itself. I am thinking to only
> bind the data source reference to the openejb tree, since this is only
> request now. Before doing the changes, I would double check with it, and
> just do not want to bring any regression issues :-)
> thanks.
>
> --
> Ivan
>



-- 
Ivan

[jira] [Commented] (GERONIMODEVTOOLS-759) Using the new APIs to manage the bundles status both in GEP and Server side

[Yi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064996#comment-13064996
 ] 

Yi Xiao commented on GERONIMODEVTOOLS-759:
--

I've reviewed the code, it's better and more concise than I did, thank you very 
much, Jarek.

When I test the new feature, I find a problem that when restart the eclipse and 
modify the bundle's symbolic name or version, then publish the bundle to the 
server, the server would not remove the previous one!

The root cause is when the eclipse restarts, the bundle Map's info is empty, so 
it could not get the cached bundle id and also the bundle's symbolic name or 
version has been changed, so it could not find the bundle id from server side 
by them, the bundle will be an isolated and never used one in server side. 

Maybe we still need persist the bundle map in GEP side, but just persist the 
bundle module id, symbolic name,version and the module's state(is removed or 
something else), the module state can be obtained by a resource changed 
listener as I patched before.
What's your option?

> Using the new APIs to manage  the bundles status both in GEP and Server side
> 
>
> Key: GERONIMODEVTOOLS-759
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-759
> Project: Geronimo-Devtools
>  Issue Type: Improvement
>  Components: eclipse-plugin
>Affects Versions: 3.0
> Environment: WinXP sp3 32bit& Win7 64bit, Oracle JDK 1.6, 
> Eclipse3.6SR1&SR2
>Reporter: Yi Xiao
>Assignee: Jarek Gawor
>  Labels: OSGI, bundle
> Fix For: 3.0
>
> Attachments: OSGIBundleDeploy.patch, 
> OSGIBundleDeploy_changeAPI.patch, OSGIBundleDeploy_changeAPI2_759.patch, 
> OSGIBundleDeploy_changePOM_759.patch
>
>
> This improvement depends on the server's modules, so, if the server side does 
> not update timely, it may cause the GEP compile failure!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [DISCUSSION] New look and feel of Geronimo 3.0 admin console?

[Yi Xiao]

The left side of basic view's UI is wonderful!

On Thu, Jul 14, 2011 at 3:51 AM, Russell E Glaue  wrote:

> On 07/10/2011 12:03 PM, Rex Wang wrote:
> > Hi devs,
> >
> > I think it's time to change.
> > Geronimo 3.0 will be a great milestone that brings a lot of new
> > features. So how about also provide our user a brand new UI design of
> > the admin console?
> >
> > I opened a Jira: https://issues.apache.org/jira/browse/GERONIMO-6059
> > And uploaded my proposal in the jira's attachment.
> >
> > Any thoughts?
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org 
>
>
> I like the difference between basic and advanced.
> The basic tab, with the big icons, really seems to make the options less
> intimidating to a new users.
> And having a comfortable visual tree in the advanced tab is good.
>
> I assume, in advanced, the side bar would scroll, even though the visual
> does
> not show the scroll bar.
>
> -RG
>



-- 
Best regards!


   John Xiao

Re: buildbot failure in ASF Buildbot on geronimo-server-trunk

[David Blevins]

Likely the snapshots are out of date.  Poking buildbot to publish new ones 
now

-David

On Jul 13, 2011, at 1:11 AM, Rex Wang wrote:

> Not me.. anyone see this?
> 
> java.lang.NoClassDefFoundError: org/apache/openejb/jee/Application
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:383)
> 
> 
>   at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:326)
> 
>   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:233)
>   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.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
> 
>   at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:879)
> 
> 
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
> 
>   at 
> org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:524)
>   at 
> org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:340)
> 
> 
>   at 
> org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:235)
> 
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> 
> 
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> 
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> 
> 
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> 
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> 
> 
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> 
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> 
> 
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> 
>   at 
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
>   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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> 
> 
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> 
>   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.openejb.jee.Application
> 
> 
>   at 
> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:772)
> 
>   at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)
>   at 
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690)
> 
> 
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> 
>   at 
> org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:634)
>   at 
> org.apache.felix.framework.resolver.WireImpl.getClass(WireImpl.java:99)
> 
> 
>   at 
> org.apache.felix.framework.ModuleImpl.searchImports(ModuleImpl.java:1345)
> 
>   at 
> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:711)
>   at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)
> 
> 
>   at 
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690)
> 
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>   ... 33 more
> 
> 
> 2011/7/13 
> The Buildbot has detected a new failure on builder geronimo-server-trunk 
> while building ASF Buildbot.
> Full details are available at:
>  http://ci.apache.org/builders/geronimo-server-trunk/builds/186
> 
> Buildbot URL: http://ci.apache.org/
> 
> Buildslave for this Build: hemera_ubuntu
> 
> Build Reason: scheduler
> Build Source Stamp: [branch geronimo/server/trunk] 1145895
> Blamelist: rwonly
> 
> BUILD FAILED: failed compile
> 
> sincerely,
>  -The Buildbot
> 
> 
> 
> 
> -- 
> Lei Wang

Re: What's the reason why not to add .sh extension to geornimo scripts ?

[Russell E Glaue]

On 07/13/2011 02:43 PM, Russell E Glaue wrote:
> 
> On 07/06/2011 10:56 PM, Kevan Miller wrote:
>>
>> On Jul 2, 2011, at 4:13 AM, Shawn Jiang wrote:
>>
>>> I noticed that there are no extensions for all sh scripts of geornimo.
>>>   Does anyone know what's the background of this ?
>>>
>>>
>>> GERONIMO_HOME\bin\client
>>> GERONIMO_HOME\bin\deploy
>>> GERONIMO_HOME\bin\geronimo
>>> GERONIMO_HOME\bin\register-service
>>> GERONIMO_HOME\bin\shutdown
>>> GERONIMO_HOME\bin\startup
>>
>> I believe it started with bin/geronimo -- which was based on the karaf 
>> command and that convention was carried over. Run 'svn log 
>> framework/configs/karaf-framework/src/main/distribution/unix-shell/bin/geronimo'
>>  for more details.
>>
>> I know some people like to have .bat and  that way 
>> invoking a command is the same on linux/windows. Personally, I think we 
>> should have maintained our existing conventions (e.g. geronimo.sh, etc). I'm 
>> somewhat used to typing 'geronimo', now. So, don't have a strong opinion. 
>> Would value input from users.
>>
>> --kevan
> 
> The file name suffix, is primarily for the benefit of windows-type machines
> which need the file extension for determining run-time interpretation.
> 
> It would probably be necessary if the *nix shell script files appeared in a
> Windows OS installation of Geronimo, only so Windows users do not try to 
> execute
> them.
> 
> Otherwise, the suffix is primarily for human visualization, so one can know 
> the
> intention of the script by looking at the name. Without the suffix, one 
> commonly
> pre-judges the script to be binary (though I will `head -1 file` it).
> 
> If the source is browsed in a Web Browser, having the suffix allows 
> user-defined
> methods for viewing the files, instead of the browser and server assuming the
> suffix-less file is binary.
> 
> 
> Most of us don't double-click on unix scripts from a GUI, so it is not 
> necessary
> to have the suffix extensions for the GUI's identification.
> 
> I would say a common documentation on how to execute the bat/sh scripts 
> (without
> deviation for OS differences) is more important than GUI recognition of the 
> file
> type. Most new users do not care how the script is interpreted. Most old users
> already know.
> 
> Besides, having a ".sh" extension does not tell you if the script is bash, 
> csh,
> ksh, etc... So if you want to know the interpreter of a ".sh" file, you still
> have to look.
> 
> -RG
> 

Looking at what would be the likely Windows user download for the distribution
of Geronimo (the zip file), I see that Windows batch and Unix shell scripts are
intermingled in the bin directory, and that the shell scripts have no extension.

I would say that for alleviating any possible confusion among new Windows users,
we should put the ".sh" extensions back onto the shell script file names.

Either that, or we have the build process create two distributions, one for each
OS, which I think makes our release process unnecessarily more confusing. Adding
the suffix is much easier. IMO, A -3 character typing convenience is not a great
argument against the possible misidentification/confusion of new users.

Though I would prefer Documentation to be normalized for Unix environments, and
thus leaving off the .sh suffix, and having Windows environments be the
deviation, thus requiring the .bat suffix - I think most new users will be
application programmers, and they are still predominately using Windows. Our
effort should be focused on making things as less confusing as we can over
convenience.

-RG

Re: [DISCUSSION] New look and feel of Geronimo 3.0 admin console?

[Russell E Glaue]

On 07/10/2011 12:03 PM, Rex Wang wrote:
> Hi devs,
> 
> I think it's time to change.
> Geronimo 3.0 will be a great milestone that brings a lot of new
> features. So how about also provide our user a brand new UI design of
> the admin console?
> 
> I opened a Jira: https://issues.apache.org/jira/browse/GERONIMO-6059
> And uploaded my proposal in the jira's attachment.
> 
> Any thoughts?
> 
> -- 
> Lei Wang (Rex)
> rwonly AT apache.org 


I like the difference between basic and advanced.
The basic tab, with the big icons, really seems to make the options less
intimidating to a new users.
And having a comfortable visual tree in the advanced tab is good.

I assume, in advanced, the side bar would scroll, even though the visual does
not show the scroll bar.

-RG

Re: What's the reason why not to add .sh extension to geornimo scripts ?

[Russell E Glaue]

On 07/06/2011 10:56 PM, Kevan Miller wrote:
> 
> On Jul 2, 2011, at 4:13 AM, Shawn Jiang wrote:
> 
>> I noticed that there are no extensions for all sh scripts of geornimo.
>>   Does anyone know what's the background of this ?
>>
>>
>> GERONIMO_HOME\bin\client
>> GERONIMO_HOME\bin\deploy
>> GERONIMO_HOME\bin\geronimo
>> GERONIMO_HOME\bin\register-service
>> GERONIMO_HOME\bin\shutdown
>> GERONIMO_HOME\bin\startup
> 
> I believe it started with bin/geronimo -- which was based on the karaf 
> command and that convention was carried over. Run 'svn log 
> framework/configs/karaf-framework/src/main/distribution/unix-shell/bin/geronimo'
>  for more details.
> 
> I know some people like to have .bat and  that way invoking 
> a command is the same on linux/windows. Personally, I think we should have 
> maintained our existing conventions (e.g. geronimo.sh, etc). I'm somewhat 
> used to typing 'geronimo', now. So, don't have a strong opinion. Would value 
> input from users.
> 
> --kevan

The file name suffix, is primarily for the benefit of windows-type machines
which need the file extension for determining run-time interpretation.

It would probably be necessary if the *nix shell script files appeared in a
Windows OS installation of Geronimo, only so Windows users do not try to execute
them.

Otherwise, the suffix is primarily for human visualization, so one can know the
intention of the script by looking at the name. Without the suffix, one commonly
pre-judges the script to be binary (though I will `head -1 file` it).

If the source is browsed in a Web Browser, having the suffix allows user-defined
methods for viewing the files, instead of the browser and server assuming the
suffix-less file is binary.


Most of us don't double-click on unix scripts from a GUI, so it is not necessary
to have the suffix extensions for the GUI's identification.

I would say a common documentation on how to execute the bat/sh scripts (without
deviation for OS differences) is more important than GUI recognition of the file
type. Most new users do not care how the script is interpreted. Most old users
already know.

Besides, having a ".sh" extension does not tell you if the script is bash, csh,
ksh, etc... So if you want to know the interpreter of a ".sh" file, you still
have to look.

-RG

Re: [jira] [Commented] (GERONIMO-5764) Support Bundles Deployment in deployment command line

[Jarek Gawor]

Setting startlevel + 10 doesn't seem to be working right. Can you take a look?

Thanks,
Jarek

On Wed, Jul 13, 2011 at 5:56 AM, Yi Xiao  wrote:
> I thought in the GEP side, can provide two way to resolve the second issue:
> 1 As Rex mentioned, add a section in GEP's server page to control all the
> bundles' start level, the default value is startlevel + 10 or higher
> 2 Provide a menu Item like start, stop module when right click the module in
> server view, named "change bundle start level" to control the specific
> bundle's start level. But in this scenario, need to save every bundle's
> start level in GEP side.
>
> On Wed, Jul 13, 2011 at 3:55 PM, Rex Wang (JIRA)  wrote:
>>
>>    [
>> https://issues.apache.org/jira/browse/GERONIMO-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064415#comment-13064415
>> ]
>>
>> Rex Wang commented on GERONIMO-5764:
>> 
>>
>> fix #1 at revision: 1145896, we won't start the fragment bundle when
>> launch the framework.
>>
>> For #2, I agree with you. Currently we install car's dependent bundles in
>> car's activator, which is not that osgi-friend. That is, if the recorded
>> bundle has the same start level with the car, there is no guarantee which
>> one will start first. This could cause the recorded bundle fail to resolve
>> and start. I believe setting the startlevel properly can resolve this.
>> On the other hand, GEP need find a place to record each bundle's start
>> level, or just by default use the initial bundle startlevel + 10 ?
>>
>> -Rex
>>
>> > Support Bundles Deployment in deployment command line
>> > -
>> >
>> >                 Key: GERONIMO-5764
>> >                 URL: https://issues.apache.org/jira/browse/GERONIMO-5764
>> >             Project: Geronimo
>> >          Issue Type: New Feature
>> >      Security Level: public(Regular issues)
>> >          Components: commands, console, deployment
>> >    Affects Versions: 3.0
>> >            Reporter: viola.lu
>> >            Assignee: Rex Wang
>> >            Priority: Critical
>> >             Fix For: 3.0
>> >
>> >         Attachments: GERONIMO-5764-install-bundle.patch,
>> > GERONIMO-5764-install-uninstall-bundle.patch,
>> > GERONIMO-5764-record-bundle.patch, GERONIMO-5764.patch
>> >
>> >
>> > Now we have to deploy a regular bundle via karaf shell: osgi:install
>> > file:/[bunlde_path], not deployer command line, so open this jira to track
>> > this feature enablement.
>>
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>
>
>
> --
> Best regards!
>
>                John Xiao
>

[jira] [Issue Comment Edited] (GERONIMO-6075) Support bundle installation and uninstallation via Karaf shell

[Chi Runhua (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064630#comment-13064630
 ] 

Chi Runhua edited comment on GERONIMO-6075 at 7/13/11 3:25 PM:
---

Hi Ivan, you mean refer to GERONIMO-5764 for the details. IIUC, the logic of 
those 2 commands is to persist the bundle in Geronimo repository and record its 
information in /etc/startup.properties file after installation, then remove the 
record after uninstallation. In this way, the bundle could survive a clean 
start. Rex had already implemented the feature in GERONIMO-5764.

This JIRA is to simply enable the commands for Karaf shell.

HTH.

  was (Author: chi runhua):
Hi Ivan, you mean refer to GERONIMO-5764 for the details. IIUC, the logic 
of those 2 commands is to record the bundle in Geronimo repository and record 
the information in /etc/startup.properties file after installation, then remove 
the record after uninstallation. In this way, the bundle could survive after a 
clean start. Rex had already implemented the feature in GERONIMO-5764.

This JIRA is to simply enable the commands for Karaf shell.

HTH.
  
> Support bundle installation and uninstallation via Karaf shell
> --
>
> Key: GERONIMO-6075
> URL: https://issues.apache.org/jira/browse/GERONIMO-6075
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 3.0
>Reporter: Chi Runhua
>Assignee: Chi Runhua
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 6075.patch, GERONIMO-6075-updated.patch
>
>
> deploy:install-bundle
> deploy:uninstall-bundle
> should be supported via Karaf shell in Geronimo.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (GERONIMO-6075) Support bundle installation and uninstallation via Karaf shell

[Chi Runhua (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chi Runhua resolved GERONIMO-6075.
--

Resolution: Fixed

Committed revision 1146091.

> Support bundle installation and uninstallation via Karaf shell
> --
>
> Key: GERONIMO-6075
> URL: https://issues.apache.org/jira/browse/GERONIMO-6075
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 3.0
>Reporter: Chi Runhua
>Assignee: Chi Runhua
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 6075.patch, GERONIMO-6075-updated.patch
>
>
> deploy:install-bundle
> deploy:uninstall-bundle
> should be supported via Karaf shell in Geronimo.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (GERONIMO-6075) Support bundle installation and uninstallation via Karaf shell

[Chi Runhua (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064630#comment-13064630
 ] 

Chi Runhua commented on GERONIMO-6075:
--

Hi Ivan, you mean refer to GERONIMO-5764 for the details. IIUC, the logic of 
those 2 commands is to record the bundle in Geronimo repository and record the 
information in /etc/startup.properties file after installation, then remove the 
record after uninstallation. In this way, the bundle could survive after a 
clean start. Rex had already implemented the feature in GERONIMO-5764.

This JIRA is to simply enable the commands for Karaf shell.

HTH.

> Support bundle installation and uninstallation via Karaf shell
> --
>
> Key: GERONIMO-6075
> URL: https://issues.apache.org/jira/browse/GERONIMO-6075
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 3.0
>Reporter: Chi Runhua
>Assignee: Chi Runhua
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 6075.patch, GERONIMO-6075-updated.patch
>
>
> deploy:install-bundle
> deploy:uninstall-bundle
> should be supported via Karaf shell in Geronimo.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (GERONIMO-6075) Support bundle installation and uninstallation via Karaf shell

[Ivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064627#comment-13064627
 ] 

Ivan commented on GERONIMO-6075:


OK, I guess that this commands support to persistent the bundle info, so that 
it will start after the clear cache.

> Support bundle installation and uninstallation via Karaf shell
> --
>
> Key: GERONIMO-6075
> URL: https://issues.apache.org/jira/browse/GERONIMO-6075
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 3.0
>Reporter: Chi Runhua
>Assignee: Chi Runhua
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 6075.patch, GERONIMO-6075-updated.patch
>
>
> deploy:install-bundle
> deploy:uninstall-bundle
> should be supported via Karaf shell in Geronimo.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Pull Tomcat 7.0.18 to Geronimo side

[Kevan Miller]

On Jul 13, 2011, at 10:34 AM, Ivan wrote:

> I just merged almost all the changes from Tomcat trunk to our Tomcat ext 
> 7.0.18 code base. Some detailed information could be found in the readme.txt 
> file. And Tomcat community is preparing for Tomcat 7.0.19, since that our 
> 7.0.18 almost has the same contents with 7.0.19. I am thinking that there is 
> not strong requirement to remove this branch and re-pull the codes again.
> Thoughts ? If no objection, I will prepare the release 7.0.18.1 in the next 
> two or three days.

Preferrable, IMO, to be lined up with an actual Tomcat release number. So, I'd 
prefer to see a 7.0.19 equivalent...

--kevan

[jira] [Commented] (GERONIMO-6075) Support bundle installation and uninstallation via Karaf shell

[Ivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064608#comment-13064608
 ] 

Ivan commented on GERONIMO-6075:


Hi, Jeff, I might miss some background info here, since there are commands like 
osgi:install and osgi:uninstall, why do we need another commands with the 
similar functions ?

> Support bundle installation and uninstallation via Karaf shell
> --
>
> Key: GERONIMO-6075
> URL: https://issues.apache.org/jira/browse/GERONIMO-6075
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 3.0
>Reporter: Chi Runhua
>Assignee: Chi Runhua
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 6075.patch, GERONIMO-6075-updated.patch
>
>
> deploy:install-bundle
> deploy:uninstall-bundle
> should be supported via Karaf shell in Geronimo.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Pull Tomcat 7.0.18 to Geronimo side

[Ivan]

I just merged almost all the changes from Tomcat trunk to our Tomcat ext
7.0.18 code base. Some detailed information could be found in the readme.txt
file. And Tomcat community is preparing for Tomcat 7.0.19, since that our
7.0.18 almost has the same contents with 7.0.19. I am thinking that there is
not strong requirement to remove this branch and re-pull the codes again.
Thoughts ? If no objection, I will prepare the release 7.0.18.1 in the next
two or three days.

2011/7/12 Ivan 

> They accepted the patch partly, now they use the InstanceManager to create
> the instance, but some other changes are not included, you might check the
> commit history :-)
>
> 2011/7/12 David Jencks 
>
>> DId tomcat accept the change of creating AsyncListeners using the
>> InstanceManager?  If so, then the change in geronimo's copy is all that is
>> needed.
>>
>> thanks!
>> david jencks
>>
>> On Jul 10, 2011, at 11:53 PM, Ivan wrote:
>>
>> I merged all of the changes mentioned in the thread
>> http://old.nabble.com/Preparing-for-a-7.0.19-tag-td32031213.html , now
>> the 7.0.18.0 branch from Geronimo side has the same contents with the Tomcat
>> trunk rev.1144976GERONIMO-5622
>> Also, an extra changes from Geronimo side is also added,  GERONIMO-5622. it
>> will be better that someone could also help to review those changes.
>>
>> If we would release this 7.0.18 branch, which version should be used ?
>> 7.0.18.0 or 7.0.18.1, which is mentioned in the past. The reason for
>> 7.0.18.1 is that, it indicates that some extra changes are done comparing
>> the 7.0.18 code base from Tomcat.
>> Thanks.
>>
>> 2011/7/11 Ivan 
>>
>>> Yes, I will go ahead to pull the codes of 7.0.18, and apply those fixes
>>> on our code base, it is better to know whether the TCK is fine with the new
>>> version, also it looks to me that some integration changes are required.
>>> And it depends on whether Tomcat will release 7.0.19 soon, we could pull
>>> the latest 7.0.19 or release a 7.0.18.1 version with Geronimo 3.0.
>>>
>>> 2011/7/10 Kevan Miller 
>>>

 On Jul 10, 2011, at 10:14 AM, Ivan wrote:

 > Seems that there are some issues with 7.0.18, and Tomcat community is
 preparing for 7.0.19.

 So I see... I read the tomcat list last night, not this morning ;-)

 It would be a good idea to pull in an early version and identify any
 integration or tck issues.

 Anyway, thanks for tracking this...

 --kevan
>>>
>>>
>>>
>>>
>>> --
>>> Ivan
>>>
>>
>>
>>
>> --
>> Ivan
>>
>>
>>
>
>
> --
> Ivan
>



-- 
Ivan

[jira] [Commented] (GERONIMO-6075) Support bundle installation and uninstallation via Karaf shell

[Rex Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064595#comment-13064595
 ] 

Rex Wang commented on GERONIMO-6075:


hi Jeff, thanks for the patch!
I made a updated patch based on yours. There are a little bit issues:
1. the java coding convention requires the variable name should start with a 
lower case character. 
eg: "String bundleId", not "String BundleId"
2. use 4 spaces to replace the Tab in the xml.

You could review and try commit :-)

-Rex

> Support bundle installation and uninstallation via Karaf shell
> --
>
> Key: GERONIMO-6075
> URL: https://issues.apache.org/jira/browse/GERONIMO-6075
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 3.0
>Reporter: Chi Runhua
>Assignee: Chi Runhua
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 6075.patch, GERONIMO-6075-updated.patch
>
>
> deploy:install-bundle
> deploy:uninstall-bundle
> should be supported via Karaf shell in Geronimo.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (GERONIMO-6075) Support bundle installation and uninstallation via Karaf shell

[Rex Wang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rex Wang updated GERONIMO-6075:
---

Attachment: GERONIMO-6075-updated.patch

> Support bundle installation and uninstallation via Karaf shell
> --
>
> Key: GERONIMO-6075
> URL: https://issues.apache.org/jira/browse/GERONIMO-6075
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 3.0
>Reporter: Chi Runhua
>Assignee: Chi Runhua
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 6075.patch, GERONIMO-6075-updated.patch
>
>
> deploy:install-bundle
> deploy:uninstall-bundle
> should be supported via Karaf shell in Geronimo.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Only bind DataSource reference to openejb global tree ?

[Ivan]

Hi, for solving the remote access to the data source reference, now all the
references in the global scope will be bind to the openejb global tree.
While it brought some issues, in
https://issues.apache.org/jira/browse/GERONIMO-6074, I committed some
changes to avoid bind the empty context. But while starting up the server,
we still see some name already bind exception, and seems that it is caused
some global ejb references are bind on the tree twice, one is in the
XBeanJndiFactory, anther is on the OpenEJB itself. I am thinking to only
bind the data source reference to the openejb tree, since this is only
request now. Before doing the changes, I would double check with it, and
just do not want to bring any regression issues :-)
thanks.

-- 
Ivan

Re: Class-Path in manifest file of applicationclient module.

[viola lu]

But if it's by design,  appclient calls ejbs like :

@EJB
private static TradeSLSBRemote tradeSLSBRemote;

it will not find TradeSLSBRemote class in its class finder. Currently, i
have to pakcage all ejb interface to ear lib folder, making ejb interface in
appclient classpath.



On Tue, Jul 12, 2011 at 11:29 PM, Ivan  wrote:

> From the word of 'library', I do not think that ejb module is belong to
> this scope.
>
>
> 2011/7/12 Shawn Jiang 
>
>> Components in the application client container must have access to the
>> following
>> classes and resources.
>> • The content of the application client jar file.
>> • The transitive closure of any libraries referenced by the above jar file
>> (as spec-
>> ified in Section EE.8.2, “Library Support”).
>>
>>
>>
>>
>> On Tue, Jul 12, 2011 at 11:10 PM, Ivan  wrote:
>>
>>> Hmm, I double checked the spec, so which rule should cover this request
>>> ?
>>>
>>> --->
>>> • The Java EE API classes specified in Table EE.6-1 for the containers
>>> other than
>>> the application client container.
>>> • Any installed libraries available in the application server.
>>> • Other classes or resources contained in the application package, and
>>> specified
>>> by an explicit use of an extension not defined by this specification.
>>> • Other classes and resources that are part of the implementation of the
>>> applica-
>>> tion server.
>>> <---
>>>
>>>
>>> 2011/7/12 Shawn Jiang 
>>>
 per java ee 6 spec:   EE.8.3.3 Application Client Container Class
 Loading Requirements

 Components in the application client container must not have access to
 the
 following classes and resources, *unless such classes or resources are
 covered by
 one of the rules above.*

 If the ejb jar is in the class-path of app client module,   the module
 will have the access to ejb jar.




 On Tue, Jul 12, 2011 at 10:59 PM, Ivan  wrote:

> Yes, it is by design. App client modules should not have access to web
> modules, ejb modules and other app client modules in the same ear package.
>
>
> 2011/7/12 viola lu 
>
>> Hi, Dev:
>>
>>  I met a problem when deploy an ear which packages an ejb, application
>> client, web app. And the EJB is in the class-path of app client module
>> manifest, but Appclientmodulebuilder class doesn't add this class-path of
>> manifest  to module's LinkedHashSet classpath, So it's not in the
>> class path of AppclientDeplomentContext either. Is it correct?
>> --
>> viola
>>
>> Apache Geronimo
>>
>>
>
>
> --
> Ivan
>



 --
 Shawn

>>>
>>>
>>>
>>> --
>>> Ivan
>>>
>>
>>
>>
>> --
>> Shawn
>>
>
>
>
> --
> Ivan
>



-- 
viola

Apache Geronimo

[Cancel VOTE] release YOKO 1.2 - 1st attempt.

[Forrest Xia]

Notice files need updates, so cancel this vote, and prepare a new one

Forrest

On Wed, Jul 13, 2011 at 2:51 PM, viola lu  wrote:

> +1
>
>
> On Wed, Jul 13, 2011 at 12:38 PM, Kevan Miller wrote:
>
>> Same about the year in the NOTICE file. So, would like to see that
>> updated.
>>
>> The source, signatures/checksums, LICENSE/NOTICE file looks good. I'm
>> running a build, now. Will let you know if I see any problems. I keep
>> building while a Geronimo server is running. IIRC, the server interferes
>> with the junit tests.
>>
>> Once the NOTICE file is updated, I should be +1
>>
>> --kevan
>>
>> On Jul 12, 2011, at 11:45 AM, Forrest Xia wrote:
>>
>> > [VOTE] release YOKO 1.2 - 1st attempt.
>> >
>> > This is a bug fixes release for Java EE 6 compliance:
>> >
>> > The fixes in this release are:
>> > YOKO-431 Classloader issue when initializing a corba skeleton for EJB
>> object
>> > YOKO-433 YOKO chunking logic does not set the the chunk flag to false
>> when the valuetype tag is false on the chunking bit
>> >
>> > The artifacts up for vote are:
>> > 1.
>> https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.tar.gz
>> > 2.
>> https://repository.apache.org/content/repositories/orgapachegeronimo-016/org/apache/yoko/yoko/1.2/yoko-1.2-source-release.zip
>> >
>> > The staging repository is:
>> >
>> https://repository.apache.org/content/repositories/orgapachegeronimo-016
>> >
>> > The source tag is:
>> > https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.2/
>> >
>> >  Vote will be open for 72 hours.
>> >
>> >  [ ] +1  approve
>> >  [ ] +0  no opinion
>> >  [ ] -1  disapprove (and reason why)
>> >
>> > --
>> > Shawn
>>
>>
>
>
> --
> viola
>
> Apache Geronimo
>
>

[jira] [Commented] (GERONIMODEVTOOLS-762) GEP needs a nightly builds repositary

[Kevan Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064532#comment-13064532
 ] 

Kevan Miller commented on GERONIMODEVTOOLS-762:
---

Janet,
We never should have been using http://apache.org/dist for this purpose. Please 
make sure any processes dist for nightly builds have been stopped.

dist is *only* for released artifacts voted on by the Geronimo PMC.

--kevan

> GEP needs a nightly builds repositary
> -
>
> Key: GERONIMODEVTOOLS-762
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-762
> Project: Geronimo-Devtools
>  Issue Type: Wish
>  Components: eclipse-plugin
>Affects Versions: 3.0
>Reporter: Yi Xiao
>Assignee: Yi Xiao
>  Labels: build, gep,, nightly
> Attachments: gep_nightly_build.patch
>
>
> The GEP had a nightly build repo before(refer to: 
> http://geronimo.apache.org/development-tools.html#DevelopmentTools-NightlyBuilds),
>  but it does not work now. So, I thought we should set up a environment to 
> redo it.
> I've attached a patch to resolve the issue temporally. If you want to test it 
> in your local environment, should add below content to your maven's 
> settings.xml file:
> 
>   geronimo-devtools-nightly-repo
>   people.apache.org.username
>   people.apache.org.password
> 
> Thank Janet for helping me test to upload the devtools onto the apache site.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (GERONIMO-6073) Rotation and appending of console output when Geronimo is run a windows service

[viola.lu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

viola.lu reassigned GERONIMO-6073:
--

Assignee: viola.lu

> Rotation and appending of console output when Geronimo is run a windows 
> service
> ---
>
> Key: GERONIMO-6073
> URL: https://issues.apache.org/jira/browse/GERONIMO-6073
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 2.1.7, 2.2.1
> Environment: Windows
>Reporter: Vamsavardhana Reddy
>Assignee: viola.lu
>
> GERONIMO-4394 provided for running Geronimo as windows service.  The console 
> output STDOUT is directed to geronimosrv.out and STDERR is directed to 
> geronimosrv.err.  If the server is running for long, these files can grow big 
> requiring the server to be stopped.  Also, each time the server is started as 
> service, the files from the previous run are overwritten since the output 
> does not get appended to existing file.  So, if a user is interested in the 
> console output from the previous runs, it is lost.  So, console output 
> rotation and appending to already existing files should be a good improvement 
> for the "Run Geronimo as a Windows service" feature.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Commented] (GERONIMO-5764) Support Bundles Deployment in deployment command line

[Yi Xiao]

I thought in the GEP side, can provide two way to resolve the second issue:

1 As Rex mentioned, add a section in GEP's server page to control all the
bundles' start level, the default value is startlevel + 10 or higher
2 Provide a menu Item like start, stop module when right click the module in
server view, named "change bundle start level" to control the specific
bundle's start level. But in this scenario, need to save every bundle's
start level in GEP side.

On Wed, Jul 13, 2011 at 3:55 PM, Rex Wang (JIRA)  wrote:

>
>[
> https://issues.apache.org/jira/browse/GERONIMO-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064415#comment-13064415]
>
> Rex Wang commented on GERONIMO-5764:
> 
>
> fix #1 at revision: 1145896, we won't start the fragment bundle when launch
> the framework.
>
> For #2, I agree with you. Currently we install car's dependent bundles in
> car's activator, which is not that osgi-friend. That is, if the recorded
> bundle has the same start level with the car, there is no guarantee which
> one will start first. This could cause the recorded bundle fail to resolve
> and start. I believe setting the startlevel properly can resolve this.
> On the other hand, GEP need find a place to record each bundle's start
> level, or just by default use the initial bundle startlevel + 10 ?
>
> -Rex
>
> > Support Bundles Deployment in deployment command line
> > -
> >
> > Key: GERONIMO-5764
> > URL: https://issues.apache.org/jira/browse/GERONIMO-5764
> > Project: Geronimo
> >  Issue Type: New Feature
> >  Security Level: public(Regular issues)
> >  Components: commands, console, deployment
> >Affects Versions: 3.0
> >Reporter: viola.lu
> >Assignee: Rex Wang
> >Priority: Critical
> > Fix For: 3.0
> >
> > Attachments: GERONIMO-5764-install-bundle.patch,
> GERONIMO-5764-install-uninstall-bundle.patch,
> GERONIMO-5764-record-bundle.patch, GERONIMO-5764.patch
> >
> >
> > Now we have to deploy a regular bundle via karaf shell: osgi:install
> file:/[bunlde_path], not deployer command line, so open this jira to track
> this feature enablement.
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>


-- 
Best regards!


   John Xiao

[jira] [Updated] (GERONIMO-6075) Support bundle installation and uninstallation via Karaf shell

[Chi Runhua (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chi Runhua updated GERONIMO-6075:
-

Attachment: 6075.patch

> Support bundle installation and uninstallation via Karaf shell
> --
>
> Key: GERONIMO-6075
> URL: https://issues.apache.org/jira/browse/GERONIMO-6075
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: commands
>Affects Versions: 3.0
>Reporter: Chi Runhua
>Assignee: Chi Runhua
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 6075.patch
>
>
> deploy:install-bundle
> deploy:uninstall-bundle
> should be supported via Karaf shell in Geronimo.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (GERONIMO-6075) Support bundle installation and uninstallation via Karaf shell

[Chi Runhua (JIRA)]

Support bundle installation and uninstallation via Karaf shell
--

 Key: GERONIMO-6075
 URL: https://issues.apache.org/jira/browse/GERONIMO-6075
 Project: Geronimo
  Issue Type: Sub-task
  Security Level: public (Regular issues)
  Components: commands
Affects Versions: 3.0
Reporter: Chi Runhua
Assignee: Chi Runhua
Priority: Minor


deploy:install-bundle
deploy:uninstall-bundle

should be supported via Karaf shell in Geronimo.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[BUILD] branches/2.2: Failed for Revision: 1145811

[Jarek Gawor]

Geronimo Revision: 1145811 built with tests included
 
See the full build-2000.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20110713/build-2000.log
 
Download the binaries from 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20110713
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 427 minutes 26 seconds
[INFO] Finished at: Wed Jul 13 03:21:03 EDT 2011
[INFO] Final Memory: 313M/740M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
 
Assembly: tomcat
=
See full test results and logs at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20110713/logs-2000-tomcat/
 
 
Booting Geronimo Kernel (in Java 1.5.0_22)...
Module  1/75 org.apache.geronimo.framework/j2ee-system/2.2.2-SNAPSHOT/car   
started in   .000s
Module  2/75 org.apache.geronimo.framework/jee-specs/2.2.2-SNAPSHOT/car 
started in   .001s
Module  3/75 
org.apache.geronimo.plugins.classloaders/xbean-finder/2.2.2-SNAPSHOT/car
   started in   .000s
Module  4/75 org.apache.geronimo.framework/xmlbeans/2.2.2-SNAPSHOT/car  
started in   .000s
Module  5/75 org.apache.geronimo.framework/rmi-naming/2.2.2-SNAPSHOT/car
   2011-07-13 03:26:21,226 WARN  
[RMIRegistryService] RMI Registry failed
2011-07-13 03:26:21,228 ERROR [GBeanInstanceState] Error while starting; GBean 
is now in the FAILED state: 
abstractName="org.apache.geronimo.framework/rmi-naming/2.2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.framework/rmi-naming/2.2.2-SNAPSHOT/car,j2eeType=GBean,name=RMIRegistry"
java.rmi.server.ExportException: Port already in use: 1099; nested exception 
is: 
java.net.BindException: Address already in use
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:249)
at 
sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:184)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:382)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:116)
at 
sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:180)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92)
at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:68)
at 
java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222)
at 
org.apache.geronimo.kernel.rmi.RMIRegistryService.doStart(RMIRegistryService.java:72)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:953)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:269)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:103)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:125)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:539)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:377)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:465)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:190)
at 
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:546)
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:592)
at 
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816)
at 
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at 
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at 
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at 
org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$526adec1.startConfiguration()
at 
org.apache.geronimo.system.main.EmbeddedDaemon.doStartup(EmbeddedDaemon.java:204)
at 
org.apache.geronimo.system.main.EmbeddedDaemon.execute(EmbeddedDaemon.java:87)

[jira] [Resolved] (GERONIMO-6074) Do not bind/unbind the empty global/env context on the openejb root context

[Ivan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan resolved GERONIMO-6074.


Resolution: Fixed

> Do not bind/unbind the empty global/env context on the openejb root context
> ---
>
> Key: GERONIMO-6074
> URL: https://issues.apache.org/jira/browse/GERONIMO-6074
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 3.0
>Reporter: Ivan
>Assignee: Ivan
> Fix For: 3.0
>
>
> Now Geronimo monitor all the global bindings and bind them on the root 
> context of openejb. But it is no need to bind/unbind the empty global/env 
> context. Or once a module is stopped, it will try to unbind the whole 
> global/env context.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (GERONIMO-6074) Do not bind/unbind the empty global/env context on the openejb root context

[Ivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064421#comment-13064421
 ] 

Ivan commented on GERONIMO-6074:


Commit changes to trunk at r1145900. With the current ApplicationJndi 
implementation, it will be fine. While I am thinking that whether we need a 
'merge' function for the context instance.

> Do not bind/unbind the empty global/env context on the openejb root context
> ---
>
> Key: GERONIMO-6074
> URL: https://issues.apache.org/jira/browse/GERONIMO-6074
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 3.0
>Reporter: Ivan
>Assignee: Ivan
> Fix For: 3.0
>
>
> Now Geronimo monitor all the global bindings and bind them on the root 
> context of openejb. But it is no need to bind/unbind the empty global/env 
> context. Or once a module is stopped, it will try to unbind the whole 
> global/env context.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: buildbot failure in ASF Buildbot on geronimo-server-trunk

[Rex Wang]

Not me.. anyone see this?

java.lang.NoClassDefFoundError: org/apache/openejb/jee/Application
at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:383)

at 
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:326)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:233)
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.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:131)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:879)

at 
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:245)
at 
org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:524)
at 
org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:340)

at 
org.apache.geronimo.mavenplugins.car.PackageMojo.execute(PackageMojo.java:235)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at 
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.lang.ClassNotFoundException: org.apache.openejb.jee.Application

at 
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:772)
at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)
at 
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690)

at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at 
org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:634)
at 
org.apache.felix.framework.resolver.WireImpl.getClass(WireImpl.java:99)

at 
org.apache.felix.framework.ModuleImpl.searchImports(ModuleImpl.java:1345)
at 
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:711)
at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)

at 
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 33 more



2011/7/13 

> The Buildbot has detected a new failure on builder geronimo-server-trunk
> while building ASF Buildbot.
> Full details are available at:
>  http://ci.apache.org/builders/geronimo-server-trunk/builds/186
>
> Buildbot URL: http://ci.apache.org/
>
> Buildslave for this Build: hemera_ubuntu
>
> Build Reason: scheduler
> Build Source Stamp: [branch geronimo/server/trunk] 1145895
> Blamelist: rwonly
>
> BUILD FAILED: failed compile
>
> sincerely,
>  -The Buildbot
>
>


-- 
Lei Wang (Rex)
rwonly AT apache.org

[jira] [Created] (GERONIMO-6074) Do not bind/unbind the empty global/env context on the openejb root context

[Ivan (JIRA)]

Do not bind/unbind the empty global/env context on the openejb root context
---

 Key: GERONIMO-6074
 URL: https://issues.apache.org/jira/browse/GERONIMO-6074
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: OpenEJB
Affects Versions: 3.0
Reporter: Ivan
Assignee: Ivan
 Fix For: 3.0


Now Geronimo monitor all the global bindings and bind them on the root context 
of openejb. But it is no need to bind/unbind the empty global/env context. Or 
once a module is stopped, it will try to unbind the whole global/env context.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (GERONIMO-5764) Support Bundles Deployment in deployment command line

[Rex Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064415#comment-13064415
 ] 

Rex Wang commented on GERONIMO-5764:


fix #1 at revision: 1145896, we won't start the fragment bundle when launch the 
framework.

For #2, I agree with you. Currently we install car's dependent bundles in car's 
activator, which is not that osgi-friend. That is, if the recorded bundle has 
the same start level with the car, there is no guarantee which one will start 
first. This could cause the recorded bundle fail to resolve and start. I 
believe setting the startlevel properly can resolve this.
On the other hand, GEP need find a place to record each bundle's start level, 
or just by default use the initial bundle startlevel + 10 ?

-Rex

> Support Bundles Deployment in deployment command line
> -
>
> Key: GERONIMO-5764
> URL: https://issues.apache.org/jira/browse/GERONIMO-5764
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: commands, console, deployment
>Affects Versions: 3.0
>Reporter: viola.lu
>Assignee: Rex Wang
>Priority: Critical
> Fix For: 3.0
>
> Attachments: GERONIMO-5764-install-bundle.patch, 
> GERONIMO-5764-install-uninstall-bundle.patch, 
> GERONIMO-5764-record-bundle.patch, GERONIMO-5764.patch
>
>
> Now we have to deploy a regular bundle via karaf shell: osgi:install 
> file:/[bunlde_path], not deployer command line, so open this jira to track 
> this feature enablement.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira