[jira] Issue Comment Edited: (GERONIMO-3325) Geronimo does not start in Eclipse

2007-09-09 Thread Siarhei Hushchyn (JIRA)

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

sergeger edited comment on GERONIMO-3325 at 9/9/07 7:54 PM:


Same issue with 2.0.1 on Solaris 10 x86 (same stack trace except '2.0-M6' 
replaced with '2.0.1').

On both JDK:
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)

java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)


FIXED: 
tar.gz. - seems to be have issue with unpack on Solaris
zip - unpack and run fine.

  was (Author: sergeger):
Same issue with 2.0.1 on Solaris 10 x86 (same stack trace except '2.0-M6' 
replaced with '2.0.1').

On both JDK:
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)

java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)

  
> Geronimo does not start in Eclipse
> --
>
> Key: GERONIMO-3325
> URL: https://issues.apache.org/jira/browse/GERONIMO-3325
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0-M6
> Environment: Geronimo 2.0M6, 
> g-eclipse-plugin-2.0.0-v20070703.1201-deployable.zip, WinXP, Java 1.5.0_11, 
> Eclipse 3.3 Europa
>Reporter: Jens Nicolay
>Assignee: Tim McConnell
>
> Simply unzipped, created runtime, and started server.
> 17:34:20,509 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="org.apache.geronimo.configs/j2ee-system/2.0-M6/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-M6/car"
> org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to 
> resolve dependency org.apache.geronimo.modules/geronimo-common/2.0-M6/jar
>   at 
> org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:114)
>   at 
> org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:404)
>   at 
> org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:321)
>   at 
> org.apache.geronimo.kernel.config.Configuration.(Configuration.java:266)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
>   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown 
> Source)
>   at java.lang.reflect.Constructor.newInstance(Unknown Source)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:944)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:537)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:195)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:159)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
>   at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
>   at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
> java.lang.IllegalStateException: GBean is not running: 
> org.apache.geronimo.configs/j2ee-system/2.0-M6/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-M6/car
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:197)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:159)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainC

[jira] Commented: (GERONIMO-3325) Geronimo does not start in Eclipse

2007-09-09 Thread Siarhei Hushchyn (JIRA)

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

Siarhei Hushchyn commented on GERONIMO-3325:


Same issue with 2.0.1 on Solaris 10 x86 (same stack trace except '2.0-M6' 
replaced with '2.0.1').

On both JDK:
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)

java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)


> Geronimo does not start in Eclipse
> --
>
> Key: GERONIMO-3325
> URL: https://issues.apache.org/jira/browse/GERONIMO-3325
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0-M6
> Environment: Geronimo 2.0M6, 
> g-eclipse-plugin-2.0.0-v20070703.1201-deployable.zip, WinXP, Java 1.5.0_11, 
> Eclipse 3.3 Europa
>Reporter: Jens Nicolay
>Assignee: Tim McConnell
>
> Simply unzipped, created runtime, and started server.
> 17:34:20,509 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="org.apache.geronimo.configs/j2ee-system/2.0-M6/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-M6/car"
> org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to 
> resolve dependency org.apache.geronimo.modules/geronimo-common/2.0-M6/jar
>   at 
> org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:114)
>   at 
> org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:404)
>   at 
> org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:321)
>   at 
> org.apache.geronimo.kernel.config.Configuration.(Configuration.java:266)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
>   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown 
> Source)
>   at java.lang.reflect.Constructor.newInstance(Unknown Source)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:944)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:537)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:195)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:159)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
>   at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
>   at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)
> java.lang.IllegalStateException: GBean is not running: 
> org.apache.geronimo.configs/j2ee-system/2.0-M6/car?configurationName=org.apache.geronimo.configs/j2ee-system/2.0-M6/car
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:304)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:197)
>   at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.loadBootstrapConfiguration(ConfigurationUtil.java:159)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.loadBootConfiguration(MainConfigurationBootstrapper.java:84)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:57)
>   at 
> org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38)
>   at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
>   at org.apache.geronimo.cli.daemon.DaemonCLI.main(DaemonCLI.java:30)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Ideas on a rc.d kind of directory

2007-09-09 Thread Jeff Genender
No...no reasons...move forward ;-)

Jeff

Jason Dillon wrote:
> Hey, have you played with the rc.d bits in the
> assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I
> whipped up will work for you?
> 
> Any more comments or suggestions on how that stuff should work?
> 
> I think this is done, quite powerful and flexible... though to really
> know for sure we'd need to have a few plugins actually using it to
> augment the Server's bootstrap configuration a?
> 
> So... are there any reasons (significant or not) for not moving forward
> with this?
> 
> --jason
> 
> 
> On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote:
> 
>>
>>
>> Jason Dillon wrote:
>>> I still think that G could do with a tiny bootstrap JVM to handle all of
>>> the required flags and properties that are needed now for the server to
>>> opperate properly (and in a platform neutral manner).  This could also
>>> be used to spawn clones or cluster nodes.  As well as handling remote
>>> restarts and recovery from JVM crashes.
>>
>> Ok...cool...wanna help? ;-)
>>
>> If we can have a GShell, etc set an env property like JAVA_OPTS, please
>> how an example and I am all game ;-)
>>
>> Jeff
>>
>>>
>>> IMO this is critical for uber massive enterprise deployments as well as
>>> smaller scale cluster management.
>>>
>>> I also think that GShell would be ideal for the base platform for such a
>>> bootstrap JVM.
>>>
>>> I think it should be realativly easy to setup a POC if folks are
>>> interested.
>>>
>>> --jason
>>>
>>> P.S. Typed on my iPhone.  Still not quite as fast as my blackberry...
>>> But I dropped in beer at the Giants/Doggers game.  Ooops ;-)
>>>
>>>
>>> On Jul 14, 2007, at 6:41 AM, Jeff Genender <[EMAIL PROTECTED]> wrote:
>>>


 Donald Woods wrote:
> Is this a scenario that would be better handled by the gshell code in
> sandbox or some daemon code that also handles the multiple server
> instance support?
> Thought here, would be gshell could read a standard Java properties
> file
> for JVM args and then launch the server with them.
>

 As long as one JVM launches, the other (ie. gshell or groovy can start
 another instance of a JVM) then this is doable.  Otherwise, this won't
 work...with my Terracotta example being a reason.

> In my eyes, scripts are a no-go, unless you can make them platform
> neutral and not require users to install a third-party solution like
> Perl (on Windows) to make it work.

 We already ship sh and bat code...why would this be a no-go?  If
 this is
 the case, then we shouldn't be shipping startup scripts in bat and sh
 format.

>
>
> -Donald
>
>
> Jeff Genender wrote:
>> Hi,
>>
>> As we move forward and we integrate with more and more 3rd party
>> products, we will need the ability to be able to change an
>> environment
>> variable through a plugin, or add a commandline JAVA_OPTS, etc.
>>
>> Currently our startup scripts call the setjavaenv.sh to set
>> environment
>> properties.  It would really be nice to have the ability to have a
>> "scripts" directory, where all of the scripts get executed before
>> Geronimo is launched.  Why do we want this?
>>
>> As we grow in our plugins, they will need to set environment or java
>> options set before running G.  They may also have a need to start or
>> run
>> other outside processes  that are not a part of G.
>>
>> It would be great to allow plugins to install an rc script that gets
>> executed to do activities before and perhaps after G is run?
>>
>> I would propose we create a scripts directory under bin or under var
>> that could be similar to init.d, and have it called with start/stop,
>> etc.  This way plugins can install specific scripts in these
>> directories
>> for execution.
>>
>> Thoughts?
>>
>> Jeff
>>
>>


Re: New GShell-based Geronimo Server launcher now in server/trunk

2007-09-09 Thread Jeff Genender
Yeah...I need Tomcat for this plugin I am working on..thanks.

Jeff

Jason Dillon wrote:
> Ya, should be simple enough... though I don't want to keep maintaining
> these extra assemblies, I'd like to just convert all of the assemblies
> to use this stuff...
> 
> But if it helps ya out, I can make a geronimo-tomcat6-javaee5-gshell...
> 
> --jason
> 
> 
> On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote:
> 
>> Is this working for the Tomcat assembly?  If not...can it soon?
>>
>> Thanks,
>>
>> Jeff
>> Sent from my iPhone
>>
>> On Sep 8, 2007, at 1:40 PM, Jason Dillon <[EMAIL PROTECTED]> wrote:
>>
>>> A little bit more insight into what I'm thinking of doing... since
>>> some of you can't read minds to well :-P
>>>
>>> I'd like to convert all of the assemblies to basically look like what
>>> the assemblies/geronimo-jetty6-javaee5-gshell produces.
>>>
>>> And then I'd like to start converting the other cli bits to gshell
>>> command impls, like: deployer, client and shutdown.
>>>
>>> And then (maybe around the same time or before the above), I'd like
>>> to adapt the gshell of target jvm bits to load jars from the
>>> repository, instead of using the lib/* bits.
>>>
>>> A little background for those who haven't looked at
>>> assemblies/geronimo-jetty6-javaee5-gshell and what it produces from a
>>> lib/* perspective.  Right now I've set up the assembly to produce:
>>>
>>>geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib
>>>geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot
>>>geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
>>>geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell
>>>
>>> Where the bits in lib/* and lib/endorsed/* are the same as they were
>>> before.  The bits in lib/boot/* and lib/gshell/* are specific to
>>> gshell.  And normally a gshell installation would have everything I
>>> put into lib/gshell/* into lib/*, but I moved them to a sub dir for
>>> now... since the bin/*.jar's load jars from the ../lib/* dirs.
>>>
>>> The lib/boot/* stuff is the very minimal gshell bootstrap classes,
>>> which setup up the other happiness... and let you do things like:
>>>
>>>java -jar
>>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/gshell-bootstrap.jar
>>>
>>>
>>> And that will give you a nice shell... or
>>>
>>>java -jar
>>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/gshell-bootstrap.jar
>>> start-server
>>>
>>> That will launch the G server process using all of the right
>>> -Djava.ext.dirs and whatever properties that we currently have hacked
>>> into platform scripts.
>>>
>>> Anyways, so the idea is to move all of the bits which are current in
>>> the lib/* into the repository, and then configure the gshell command
>>> impl to load put the correct dependency artifacts onto the classpath
>>> of the target jvm that is booted up.  This will augment the existing
>>> kernel bootstrap from repo stuff, putting evertying except what is
>>> needed from gshell into the repository...
>>>
>>> And really, what I'd like to eventually get to is having the
>>> bootstrap from the repository... so that everything except for what
>>> is now it lib/boot/* and lib/endorsed/* can live in the repository
>>> like happy little communistic jars should be :-P
>>>
>>> * * *
>>>
>>> And then there are longer term things for GShell...
>>>
>>> Remote administration (via, telnet, ssh, or custom ssl protocol...
>>> last is most likely to actually happen soonish)
>>>
>>> Process management, which is great for clusters, or staging ->
>>> production management.  A full suite of command-line tools which can
>>> manage the configuration of a server... easily.  So, for example,
>>> lets say you've got a configuration that is working really well for
>>> you... but you want to play with something new...
>>>
>>> So you might:
>>>
>>>./bin/gsh backup-configuration before-mucking
>>>./bin/gsh start-server
>>>
>>> And then go and change a whole bunch of stuff...  and it doesn't
>>> work... yikes... so rollback...
>>>
>>>./bin/gsh backup-configuration hosed-server
>>>./bin/gsh restore-configuration before-mucking
>>>./bin/gsh start-server
>>>
>>> And then maybe you want to play with the "hosed-server" configuration
>>> again...
>>>
>>>./bin/gsh start-server --configuration hosed-server
>>>
>>> Of course, all of these could have been run from a single ./bin/gsh,
>>> but just for clarity, you can run them one off too.
>>>
>>> Maybe list or mange the configurations
>>>
>>>./bin/gsh list-configurations
>>>./bin/gsh remove-configuration some-unwanted-config
>>>./bin/gsh copy-configuration default some-new-config
>>>
>>> The sky is the limit really... for what kind of management we can do...
>>>
>>> Lets say you wanted to do the above on a remote node?
>>>
>>>./bin/gsh remote-shell someserver:9443
>>>Connecting to someserver:9447...
>>>Connected
>>>
>>>username: system
>>>password:  (remember this is all jline, so we can mask
>>> passwords l

Logging out from a web app when using BASIC authentication

2007-09-09 Thread Vamsavardhana Reddy
Is it not possible to logout from a web application while using BASIC
authentication?  I see that logout works as expected when I use FORM
authentication and I am able to login as a different user without closing
the browser.  When BASIC authentication is configured, I have to close the
browser window to be able login as a different user :(

Vamsi


[jira] Updated: (GERONIMODEVTOOLS-197) Mechanism required to LICENSE/NOTICE files management

2007-09-09 Thread Jacek Laskowski (JIRA)

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

Jacek Laskowski updated GERONIMODEVTOOLS-197:
-

Summary: Mechanism required to LICENSE/NOTICE files management  (was: 
Mechanism required to )

> Mechanism required to LICENSE/NOTICE files management
> -
>
> Key: GERONIMODEVTOOLS-197
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-197
> Project: Geronimo-Devtools
>  Issue Type: Bug
>  Components: eclipse-plugin
>Affects Versions: 2.0
>Reporter: Tim McConnell
>Assignee: Tim McConnell
> Fix For: 2.0
>
>
> Per suggestions from David Jencks there seems to be a couple alternatives to 
> consider (maven-rat-plugin or the maven-remote-resources-plugin)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (GSHELL-5) MOTD-like support

2007-09-09 Thread Jason Dillon (JIRA)

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

Jason Dillon closed GSHELL-5.
-

Resolution: Fixed

Use shared profile script to implement this as desired

> MOTD-like support
> -
>
> Key: GSHELL-5
> URL: https://issues.apache.org/jira/browse/GSHELL-5
> Project: GShell
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 0.0.1
>Reporter: Jason Dillon
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-1
>
>
> Execute a "welcome.gsh" or something?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (GSHELL-26) Add custom security manager to disable dangerous things like System.exit()

2007-09-09 Thread Jason Dillon (JIRA)

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

Jason Dillon closed GSHELL-26.
--

Resolution: Fixed

> Add custom security manager to disable dangerous things like System.exit()
> --
>
> Key: GSHELL-26
> URL: https://issues.apache.org/jira/browse/GSHELL-26
> Project: GShell
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 0.0.1
>Reporter: Jason Dillon
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-1
>
>
> Take a peek at org.apache.tools.ant.util.optional.NoExitSecurityManager for 
> an example.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.