Re: TCK updates

[Jeff Genender]

Wrong list...please have this go to TCK list and not dev.

Jeff

Jarek Gawor wrote:
> Jeff,
> 
> Can you get the latest TCKs for us? Latest Java EE 5 TCK (or with
> signature files for JAX-WS 2.1), JAXB-2.1, and latest JAX-WS 2.1
> (jaxwstck-2.1_03-Apr-2008.zip).
> 
> Also, I created some TCK challenges for JAX-WS 2.1 but want to test it
> first with the latest TCK to be sure.
> 
> Thanks a lot,
> Jarek

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Actually I already made a Mina 2.x version that is in the G sandbox ;-)

Jeff

Kevan Miller wrote:


On Jan 29, 2008, at 7:28 PM, Mike Heath wrote:


Alex Karasulu wrote:

Hi,

Please excuse the cross post but it's quite necessary. Furthermore 
people
should not feel like they cannot cross post responses so please feel 
free.


It looks like the two versions of the http client based on MINA are 
starting

to diverge.  I've noticed the other day that some of the fixes for bugs
already solved by one group are being re-implement all over again 
over again
by another.  It's a shame to have that happen so perhaps we can take 
some

concrete steps to prevent this divergence from progressing.

As a first step I've cleaned up and restructured the Asyncweb code 
base and

posted this email here on the new directory structure in Subversion:

 *http://tinyurl.com/ypmbd3

*So I'm sending out this cross post in the hopes of bringing the two 
groups

together as one unified community which apparently has the same goal in
mind: a fast low-resource consuming asynchronous http client.  What 
ever it
takes, I'm sure the MINA PMC is more than willing to accommodate.  If 
you
have trusted committers already working on this in the Geronimo 
community
there is no reason why we cannot trust them to continue working on it 
here

at MINA's Asyncweb project.  Let's open up discussions on this.


I totally agree with Alex on this.  It looks there are fixes in the G
branch that haven't made it to the MINA branch.  How can bridge the gap
in communication as well as the gap in bug fixing?

My opinion is that we need to stop all work on the G sandbox branch and
move all work over to MINA.  Is there anything impeding that? ...besides
a lot of work merging the changes...


Thanks Alex and Mike.

So, as we discussed the last time, the community members that have been 
active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. 
You already know Jeff. Have you reached out to Sangjin and Rick? I'd 
urge them both to become involved in the Mina community, as their time 
and interest permit.


Personally, I'm certainly in favor of seeing a united effort in creating 
an async http client. Mina would seem to be a natural home for this 
support (since Mina 2.x is moving up the stack and implementing 
protocols). I think our community would be quite happy to receive this 
capability by consumng Mina technology. Given the current state of our 
two projects, I think it's somewhat doubtful that the Geronimo project 
will end up releasing the AsyncHTTPClient code in our sandbox.


I can understand, however, if Rick and Sangjin see value in the current 
codebase -- being based on a released version of Mina (1.1.2)  and 
perhaps at a different point in terms of stability and function. I 
suspect that this might be part of the reason why they haven't become 
involved in the 2.x development work occurring at Mina.


So, one possible solution that occurs to me is to transfer the current 
1.1.x code in Geronimo sandbox to the Mina project. This might allow 
Rick and Sangjin to complete their work on the current codebase and also 
ease their transition towards merging code and fixes into the Mina 2.x 
codebase. Alternatively, we can leave the code in Geronimo sandbox while 
Sangjin and Rick transition their focus to the Mina 2.x support.


Will leave it to the Mina project, Rick, and Sangjin to say what makes 
the most sense.


--kevan

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

[Jeff Genender]

Anita Kulshreshtha wrote:
>  I see Monitoring Console as a tool, a standard J2EE Application,
> that has been packaged for a convenient installation in Geronimo. It
> talks to a geronimo specific agent to discover and monitor a geronimo
> instance running elsewhere. I do not see it as an integral part of G,
> and hence prefer /plugins. Its location in svn does not affect the
> convenience of using it. It will always be installed from 'plugins'
> portlet and will be visible as an available plugin.

IMHO, it should definitely be a plugin (as should everything we ship),
but I think it should be a plugin that is installed by default.  As
pointed out in another email, monitoring is typically shipped and active
in some form for most other application servers.  If most of the users
find it helpful to have automatically enabled, then its probably good
that we do so.  I would probably suggest as we get closer to a release
date that we get more input from users on this subject so we can make a
proper and informed decision.

Jeff

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

[Jeff Genender]

Matt Hogstrom wrote:
> I think the correct decision would be what do
> the users want in terms of it being an integral part of what they do
> they would prefer to not go and install it but have it as part of the
> base install.  I'd be ok with either approach.  Most AppServers that I
> know of do ship their project with some minimal level of monitoring. 
> Perhaps that is the JMXViewer.  Although, I'd personally prefer the GUI
> of the console over the viewer but that is personal preferece.

+1...these are my sentiments as well.

[jira] Commented: (GERONIMO-3686) AsyncHttpClient does not reuse connection even if connections are persistent

[Jeff Genender (JIRA)]

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

Jeff Genender commented on GERONIMO-3686:
-

Cool stuff.  Yep...FIFO would be the way I would do the queues.  A 
ConcurrentLinkedQueue is perfect for this.  For the container that holds these 
queues, a ConcurrentHashmap would be great.

Instead of the sendRequest() checking the connection validation, why not make 
this a facet of the checking out.  In fact this whole thing could be part of a 
connection manager/connection cache that will return one if it exists (an is 
valid) or creates it if one doesn't.

The ideas look very sound and looks good to me.

> AsyncHttpClient does not reuse connection even if connections are persistent
> 
>
> Key: GERONIMO-3686
> URL: https://issues.apache.org/jira/browse/GERONIMO-3686
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: AsyncHttpClient
>Affects Versions: 1.x
>Reporter: Sangjin Lee
>
> Each time AsyncHttpClient.sendRequest() is called, a new TCP connection is 
> opened, even though connections may be kept alive per HTTP spec.  If 
> connections are kept open, they should be reused for more requests.

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

[jira] Closed: (GERONIMO-3616) AsyncHttpClient should support a batch invocation method

[Jeff Genender (JIRA)]

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

Jeff Genender closed GERONIMO-3616.
---

Resolution: Fixed

Patch applied from GERONIMO-3615.

> AsyncHttpClient should support a batch invocation method
> 
>
> Key: GERONIMO-3616
> URL: https://issues.apache.org/jira/browse/GERONIMO-3616
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: AsyncHttpClient
>Affects Versions: 1.x
>Reporter: Sangjin Lee
> Attachments: patch.zip
>
>
> It is desirable to have a method on AsyncHttpClient that submits multiple 
> URLs at once.  For example,
> public void sendRequests(HttpRequestMessage[] requests);
> One would expect it to initiate all HTTP requests as soon as possible in a 
> non-blocking manner and return.
> Furthermore, it would be even more powerful if it returned a list of futures 
> or a completion queue of results.  One idea would be to return something like 
> a completion queue (blocking) so that results or futures are added as they 
> are completed.  In other words,
> public BlockingQueue sendRequests(HttpRequestMessage[] 
> requests);

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

[jira] Closed: (GERONIMO-3615) AsyncHttpClient.sendRequest() should return a future

[Jeff Genender (JIRA)]

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

Jeff Genender closed GERONIMO-3615.
---

Resolution: Fixed

Never mind the last comment, I manually applied this patch, but the next one, 
if you could do a svn diff from the top directory, it will create the patch.  
For adding java or new files, just do an svn add and teh diff will pick those 
up.  Thanks for the excellent patch!

> AsyncHttpClient.sendRequest() should return a future
> 
>
> Key: GERONIMO-3615
> URL: https://issues.apache.org/jira/browse/GERONIMO-3615
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: AsyncHttpClient
>Affects Versions: 1.x
>Reporter: Sangjin Lee
> Attachments: patch.zip
>
>
> Currently the caller gets notified when the I/O is completed via 
> AsyncHttpClientCallback.  While this works for many use cases, there may be 
> situations where sendRequest() returning a future would lead to a much more 
> straightforward programming model.  This will become much more powerful 
> especially if one initiates requests to multiple URLs at once.
> I would request that sendRequest() return a future object on which one can 
> query the status of the operation, and also obtain the result or an error 
> case (exception or timeout) by calling methods on the future.  It is 
> desirable to have the return type implement java.util.concurrent.Future.
> Furthermore, the implementation class of the Future could retain the 
> reference to the callback.  Then one can have a consolidated and coherent 
> mechanism of completion (callbacks firing as a result of future completion).
> In other words, the suggestion is to change the return type of sendRequest() 
> from void to java.util.concurrent.Future.

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

[jira] Commented: (GERONIMO-3615) AsyncHttpClient.sendRequest() should return a future

[Jeff Genender (JIRA)]

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

Jeff Genender commented on GERONIMO-3615:
-

Sangjin...thanks for the patch...

Could you do a svn diff from the root of the source code and upload that, since 
those are easier to view and work with.  Thanks!

> AsyncHttpClient.sendRequest() should return a future
> 
>
> Key: GERONIMO-3615
> URL: https://issues.apache.org/jira/browse/GERONIMO-3615
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: AsyncHttpClient
>Affects Versions: 1.x
>Reporter: Sangjin Lee
> Attachments: patch.zip
>
>
> Currently the caller gets notified when the I/O is completed via 
> AsyncHttpClientCallback.  While this works for many use cases, there may be 
> situations where sendRequest() returning a future would lead to a much more 
> straightforward programming model.  This will become much more powerful 
> especially if one initiates requests to multiple URLs at once.
> I would request that sendRequest() return a future object on which one can 
> query the status of the operation, and also obtain the result or an error 
> case (exception or timeout) by calling methods on the future.  It is 
> desirable to have the return type implement java.util.concurrent.Future.
> Furthermore, the implementation class of the Future could retain the 
> reference to the callback.  Then one can have a consolidated and coherent 
> mechanism of completion (callbacks firing as a result of future completion).
> In other words, the suggestion is to change the return type of sendRequest() 
> from void to java.util.concurrent.Future.

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

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

[Jeff Genender]

I certainly believe it deserves a spot in trunk...this is an enhancement
to what we don't have before.  That's progress...and its pretty darn
cool too ;-)

I definitely don't want my ideas to hold up its movement...just food for
thought for down the road.

Jeff

Viet Nguyen wrote:
>> Whats your thought on an adapter interface that provides for full JSR-77
>> compatibility, thus requiring EJB, or a switch that allows for pure JMX
>> remoting?  This would allow for compliance or be able to leverage the
>> management without EJB if so desired.
>>
>> Thoughts?
> 
> There are goods and bads to both sides to this. If we strictly follow
> JSR 77, which means we will use MEJB and are forced to have OpenEJB as
> a pre-req, we won't have to worry if our architecture is good or not
> (I hope this is right), because we're following a standard for
> monitoring and management. On the flip side, if we use JMX to get a
> hold of the statistics, we will be able to monitor any type of server.
> Doesn't necessarily have to be a Geronimo server either, as long as we
> can connect to it via JMX, which I think is a huge plus.
> 
> With that said, I think if we decide to take the alternative JMX path,
> it can be changed later (even though this was originally how we
> implemented it). I think the important thing now, is to determine
> whether or not the monitoring plugin merits a place in trunk.

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

[Jeff Genender]

So I think we are kind of caught in a catch 22 here...

The issue is, the server is pluggable for the most part.  People may/may
not want EJB, but definitely want the management capabilities.

Whats your thought on an adapter interface that provides for full JSR-77
compatibility, thus requiring EJB, or a switch that allows for pure JMX
remoting?  This would allow for compliance or be able to leverage the
management without EJB if so desired.

Thoughts?

Viet Nguyen wrote:
> Yes, with the current implementation we have, OpenEJB is a
> prerequisite. JMX is a good solution too, but I wanted to follow the
> JSR 77 spec, which tells us to communicate with the server through the
> usage of MEJB, which is why OpenEJB is needed in this case.
> 
> --Viet

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

[Jeff Genender]

Never mind...yes looks like MEJB is a requirement.

Jeff

Jeff Genender wrote:
> Isn't the JSR 77 spec JMX based?
> 
> Jeff
> 
> Viet Nguyen wrote:
>> Yes, with the current implementation we have, OpenEJB is a
>> prerequisite. JMX is a good solution too, but I wanted to follow the
>> JSR 77 spec, which tells us to communicate with the server through the
>> usage of MEJB, which is why OpenEJB is needed in this case.
>>
>> --Viet

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

[Jeff Genender]

Isn't the JSR 77 spec JMX based?

Jeff

Viet Nguyen wrote:
> Yes, with the current implementation we have, OpenEJB is a
> prerequisite. JMX is a good solution too, but I wanted to follow the
> JSR 77 spec, which tells us to communicate with the server through the
> usage of MEJB, which is why OpenEJB is needed in this case.
> 
> --Viet

Re: [VOTE] Make Yoko core orb a Yoko subproject.

[Jeff Genender]

+1

Rick McGuire wrote:
> The discussion thread has been out there long enough for comment, and
> those who have responded appear positive about the prospect.  I think
> it's time to put this to a vote.  The full proposal from Matt Hogstrom
> is attached at the end, but the basic proposal we're voting on
> implementing in Geronimo is:
> 
> 1)  Accept the Yoko core modules (corba spec, corba core implemenation,
> rmi spec and rmi implementation) as a subproject of Geronimo.
> 2)  The Yoko subproject will be maintained as a stand-alone component so
> it can be used by Harmony as well as Geronimo.
> 3)  Lars Kuhn, Alexey Petrenko, and Darren Middleman be invited to join
> the Geronimo project as commiters so that they may continue contributing
> to the Yoko ORB.
> 
> This is a single vote on the entire proposal (accepting the code and
> inviting the commiters).
> 
> [ ] +1 Implement the Yoko ORB subproject in Geronimo as proposed above.
> [ ] 0 No opinion
> [ ] -1 Do not implement the Yoko subproject as proposed.
> Only PMC member's votes are binding, but we invite anybody in the
> community to speak up and vote on this.
> 
> Since the vote runs over the weekend, I'll conclude it at 10::00 Eastern
> time on Monday.
> 
> Rick
> 
> Matt's full proposal presented to the Yoko project:
> 
> The members of project yoko have been considering the future of Yoko as
> a project.  There have been several milestones delivered and the project
> is used by other ASF projects.   The project is not as active as other
> ASF projects and it makes sense to move the code from Yoko to other
> projects.  The Yoko team has the following proposal for your consideration.
> 
> Proposed Code Donation from Project Yoko to Apache CXF and Apache Geronimo
> 
> The Yoko community has been successful in delivering several milestones
> of the ORB implementation while in the Apache Incubator.  These
> milestones are used by other Apache projects (namely Geronimo and
> Harmony) to support their releases.  The WebServices bindings are
> dependent on CXF.  The Yoko community has decided that the Yoko project
> does not have quite the momentum to carry itself as an independent
> project but has sufficient value for other projects for them to consider
> receiving the code and committers for that code-base as sub-projects. 
> Since the code under consideration is used by Apache Geronimo, Apache
> CXF and Apache Harmony the movement of the code should continue to allow
> for independent releases so the code can be easily shared with other
> dependent projects.
> 
> The proposed division is:
> 
> yoko-spec-corba - this is the org.omg interface classes.
> rmi-spec - this is the javax.rmi spec implementation
> core - This is the actual ORB implementation.
> rmi-impl - This is the implementation of the RMIIIOP support.
> 
> These modules are also used by Harmony.
> 
> In addition to the code we propose that the following committers in
> Apache Yoko be accepted as committers in Apache Geronimo given their
> demonstration of delivering code, creating releases and functioning as a
> community.  Those noted with asterisks are already Geronimo committers.
> 
> Continued involvement with the core:
> 
> Rick McGuire *
> David Jencks *
> Alan Cabrera  *
> Lars Kuhne
> Alexey Petrenko
> Darren Middleman
> 
> The remainder of the modules in Yoko are part of the webservices support
> and are independent of the underlying ORB implementation.
> 
> api -- interface classes used for the web services support.
> bindings -- code to implement the CORBA-Web services bindings.
> tools -- tools for generation WSDL and IDL for the bindings
> maven-plugin -- some maven plugins that can use the tools for generating
> binding-related build artifacts.  None of the maven-plugin code is used
> by the ORB.
> 
> There is also a distribution directory with some sample applications. 
> One set of samples demonstrates using the core ORB, the other set is for
> WebServices.  We recommend that the distribution directory should move
> to Apache CXF as the webservices examples use the orb samples to bind
> them as web services.  Since Apache Geronimo's only use of CORBA is for
> exporting EJBs, these samples are not particularly valuable for Geronimo.
> 
> The Yoko community did not have any committers that expressed an
> interest in continuing work on these bindings.  As such, only the code
> would be moving to apache CXF.

Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk

[Jeff Genender]

David Jencks wrote:
> 
> On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
> 
>> Viet,
>>Thanks for working on the monitoring console. A lot still remains to
>> be done. There are architectural issues which need to be addressed:
>> Currently the agent (aka mrc-server) needs to reside in same jvm as
>> the server being monitored. It consumes significant DB resources.
> 
> While this might not be ideal (I don't know one way or another) does
> this make it useless?   I'd be in favor of getting something out with
> some useful functionality now, and improving it as it gets used.
> 

I was going to say the same but you beat me to it.

+1 with your comment...new functionality is the way to go on this.  This
is a huge step in the right direction and gives the user more power than
they had before.  It may not be perfect but it certainly is wickedly
cool ;-)

Anita, can you please technically show why this is not ready or should
not be released?  Can you explain/show where the graphs are wrong?  This
may help move things along.

Jeff

> thanks
> david jencks
> 
>> The Graph builder plots CountStatistics correctly. It does not
>> provide a way (minor point) to choose/plot both the raw count and the
>> throughput, i.e. count/sec. The graphs for TimeStatistics and
>> BoundedRangeStatistics are wrong. This is a serious shortcoming. I
>> would like it to be fixed before we can talk about releasing it.
>>
>> Thanks
>> Anita
>>
>> --- Viet Nguyen <[EMAIL PROTECTED]> wrote:
>>
>>> Hi All,
>>>
>>> There has been a lot of work done on the monitoring plugin lately. I
>>> think it is now time to move it from sandbox into trunk, in time for
>>> the 2.1 release. I am unsure
>>> of the timeline for 2.1, but I feel as though the monitoring plugin
>>> should be moved to trunk around this time, so that the little kinks
>>> can be worked out before it is
>>> too late for the release. Erik and I have worked together along with
>>> the help of many others to provide a monitoring collecting agent and
>>> monitoring portlet.
>>>
>>> To briefly go over what the monitoring plugin can do:
>>> -monitor multiple servers
>>> -securely connects to remote servers that are monitored (via MEJB and
>>> encryption of the password using Geronimo's EncryptionManager)
>>> -keeps an on going history of user-chosen statistics
>>> -provides the ability to view current and past statistics
>>> -customizable graphs (e.g. I can choose which stats I want to graph,
>>> and much more)
>>> -the ability to group certain graphs together into what we call a
>>> "view." The idea is to allow an administrator to view only those
>>> graphs that he cares about...all in one place!
>>> -editable server, graphs, and views option
>>> -provides the ability to keep track of any mbean that is declared as
>>> a
>>> StatisticsProvider
>>> -administrator can custom define the elapsed time period before each
>>> snapshot is taken
>>> -everything is packaged into plugins (separate plugins and a bundled
>>> plugin with both pieces), so deploying is made easier
>>>
>>> I hope that some of you can take some time to test out the plugin
>>> which can be pulled from sandbox at
>>> http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and
>>> provide
>>> some feedback. If there are no objections, I hope that a committer
>>> can
>>> soon move the monitoring plugin into trunk. One of the new features
>>> that I would like to see listed
>>> for the 2.1 release is this monitoring plugin. I believe it will
>>> attract a lot of attention and users.
>>>
>>> Thanks,
>>> Viet
>>>
>>
>>
>>
>>  
>> 
>>
>> Looking for last minute shopping deals?
>> Find them fast with Yahoo! Search. 
>> http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: Build broken?

[Jeff Genender]

FYI for all those not in the know...

This is caused by Maven 2.0.8...so be sure you are using 2.0.7 and this
problem goes away.  I am not sure what causes it...but I thought I would
share this with all just in case it's encountered.

Jeff

Jeff Genender wrote:
> Here is the error...don't know whats up:
> 
> issing dependency: org.apache.geronimo.configs/transaction//car
> [INFO]
> 
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: load of
> org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
>   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:585)
>   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: org.apache.maven.plugin.MojoExecutionException: load of
> org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed
>   at
> org.codehaus.mojo.pluginsupport.MojoSupport.execute(MojoSupport.java:137)
>   at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
>   ... 16 more
> Caused by: org.apache.geronimo.kernel.config.LifecycleException: load of
> org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed
>   at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:300)
>   at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:281)
>   at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:256)
>   at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111)
>   at
> org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke()
>   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>   at
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>   at
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
>   at
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
>   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.ConfigurationManager$$EnhancerByCGLIB$$9b238d66.loadConfiguration()
>   at
> org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:489)
>   at
> org.apache.geronimo.mavenplugins.car.PackageMojo.doExecute(PackageMojo.java:309)
>   at
> org.codehaus.mojo.pluginsupport.MojoSupport.execute(MojoSupport.java:122)
>   ... 18 more
> Caused by:
> org.apache.geronimo.kernel.repository.MissingDependencyException:
> Missing dependency: org.apache.geronimo.configs/transaction//car
>   at
> org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:111)

Re: [ANNOUNCE] Welcome Jay McHugh as the newest member of the Geronimo PMC

[Jeff Genender]

Congrats Jay...your hard work payed off!

Kevan Miller wrote:
> All,
> Please join us in congratulating Jay McHugh as the newest member of the
> Geronimo PMC. It's been great to have Jay working with us as a committer
> on Geronimo. Even better to have him join us in providing oversight of
> the Geronimo project.
> 
> Way to go Jay!!!
> 
> The Apache Geronimo PMC
> 
> --kevan

[jira] Commented: (GERONIMO-3624) Update start-server rc.d/ handling to prevent problems with ':' on Windows

[Jeff Genender (JIRA)]

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

Jeff Genender commented on GERONIMO-3624:
-

How about getting rid of the commas an colon and come up with something a bit 
more realistic and short?

> Update start-server rc.d/ handling to prevent problems with ':' on Windows
> --
>
> Key: GERONIMO-3624
> URL: https://issues.apache.org/jira/browse/GERONIMO-3624
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: buildsystem
> Environment: Windows
>Reporter: Hernan Cunico
>Assignee: Jason Dillon
>Priority: Blocker
> Fix For: 2.1
>
>
> Issue brought up by Jarek on dev@, I'm having the same problem too. Windows 
> users cannot check out trunk from SVN because of unsupported characters (":" 
> and ",") in file names. See svn log below
> svn: In directory
> 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d'
> svn: Can't move source to dest
> svn: Can't move
> 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/tmp/prop-base/geronimo-commands:start-server,default.groovy.svn-base'
> to 
> 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/prop-base/geronimo-commands:start-server,default.groovy.svn-base':
> No such file or directory

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

[jira] Commented: (GSHELL-90) GShell code does not pick up and execute files in the etc/rc.d directory

[Jeff Genender (JIRA)]

[ 
https://issues.apache.org/jira/browse/GSHELL-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548520
 ] 

Jeff Genender commented on GSHELL-90:
-

Maybe for another JIRA, but I think the colon and comma stuff should go and we 
use something a bit more generic?  These names are a bit long IMHO.

> GShell code does not pick up and execute files in the etc/rc.d directory
> 
>
> Key: GSHELL-90
> URL: https://issues.apache.org/jira/browse/GSHELL-90
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Jeff Genender
>Assignee: Jason Dillon
>Priority: Blocker
>
> GShell is not executing the rc.d script in the etc/rc.d directory in 
> Geronimo.  Files were named
> start-server,terracotta-client.groovy
> start-server,terracotta-config.groovy
> Reneamed to what I found there to match the default file:
> geronimo-commandsCOLONstart-serverCOMMAterracotta-client.groovy
> geronimo-commandsCOLONstart-serverCOMMAterracotta-config.groovy
> And they are not being executed.

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

[jira] Commented: (GSHELL-90) GShell code does not pick up and execute files in the etc/rc.d directory

[Jeff Genender (JIRA)]

[ 
https://issues.apache.org/jira/browse/GSHELL-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548496
 ] 

Jeff Genender commented on GSHELL-90:
-

Sounds like this may be a dupe and probably belongs over in the Geronimo 
space...feel free to mark it as such ;-)

> GShell code does not pick up and execute files in the etc/rc.d directory
> 
>
> Key: GSHELL-90
> URL: https://issues.apache.org/jira/browse/GSHELL-90
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Jeff Genender
>Assignee: Jason Dillon
>Priority: Blocker
>
> GShell is not executing the rc.d script in the etc/rc.d directory in 
> Geronimo.  Files were named
> start-server,terracotta-client.groovy
> start-server,terracotta-config.groovy
> Reneamed to what I found there to match the default file:
> geronimo-commandsCOLONstart-serverCOMMAterracotta-client.groovy
> geronimo-commandsCOLONstart-serverCOMMAterracotta-config.groovy
> And they are not being executed.

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

[jira] Created: (GSHELL-90) GShell code does not pick up and execute files in the etc/rc.d directory

[Jeff Genender (JIRA)]

GShell code does not pick up and execute files in the etc/rc.d directory


 Key: GSHELL-90
 URL: https://issues.apache.org/jira/browse/GSHELL-90
 Project: GShell
  Issue Type: Bug
  Security Level: public (Regular issues)
Reporter: Jeff Genender
Assignee: Jason Dillon
Priority: Blocker


GShell is not executing the rc.d script in the etc/rc.d directory in Geronimo.  
Files were named

start-server,terracotta-client.groovy
start-server,terracotta-config.groovy

Reneamed to what I found there to match the default file:

geronimo-commandsCOLONstart-serverCOMMAterracotta-client.groovy
geronimo-commandsCOLONstart-serverCOMMAterracotta-config.groovy

And they are not being executed.

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

PLugin installation broken?

[Jeff Genender]

Hi,

On the latest trun, it seems plugin installation is broken.  When I try
to install plugins...I get this.  Any ideas?:

5:20:44,138 ERROR [PluginInstallerGBean] Unable to install plugin.
java.io.IOException: No such file or directory
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:850)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.copyFile(PluginInstallerGBean.java:1000)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.extractPluginFiles(PluginInstallerGBean.java:914)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:904)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:889)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:470)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean$2.run(PluginInstallerGBean.java:533)
at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
at
org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:613)
15:20:44,712 WARN  [DefaultRemoter] Method execution failed:
java.lang.Exception: Unable to install configuration
at
org.apache.geronimo.console.ajax.ProgressMonitor.getProgressInfo(ProgressMonitor.java:62)
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:585)
at
org.directwebremoting.impl.ExecuteAjaxFilter.doFilter(ExecuteAjaxFilter.java:34)
at
org.directwebremoting.impl.DefaultRemoter$1.doFilter(DefaultRemoter.java:428)
at
org.directwebremoting.impl.DefaultRemoter.execute(DefaultRemoter.java:431)
at
org.directwebremoting.impl.DefaultRemoter.execute(DefaultRemoter.java:283)
at
org.directwebremoting.servlet.PlainCallHandler.handle(PlainCallHandler.java:52)
at 
org.directwebremoting.servlet.UrlProcessor.handle(UrlProcessor.java:101)
at org.directwebremoting.servlet.DwrServlet.doPost(DwrServlet.java:146)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.geronimo.console.servlet.ForwardDispatchFilter.doFilter(ForwardDispatchFilter.java:59)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292)
at
org.apache.geronimo.console.servlet.ContextForwardServlet.doPost(ContextForwardServlet.java:71)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:353)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 

Re: Build broken?

[Jeff Genender]

Here is the error...don't know whats up:

issing dependency: org.apache.geronimo.configs/transaction//car
[INFO]

[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: load of
org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
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:585)
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: org.apache.maven.plugin.MojoExecutionException: load of
org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed
at
org.codehaus.mojo.pluginsupport.MojoSupport.execute(MojoSupport.java:137)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more
Caused by: org.apache.geronimo.kernel.config.LifecycleException: load of
org.apache.geronimo.configs/connector-deployer/2.1-SNAPSHOT/car failed
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:300)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:281)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:256)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
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.ConfigurationManager$$EnhancerByCGLIB$$9b238d66.loadConfiguration()
at
org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:489)
at
org.apache.geronimo.mavenplugins.car.PackageMojo.doExecute(PackageMojo.java:309)
at
org.codehaus.mojo.pluginsupport.MojoSupport.execute(MojoSupport.java:122)
... 18 more
Caused by:
org.apache.geronimo.kernel.repository.MissingDependencyException:
Missing dependency: org.apache.geronimo.configs/transaction//car
at
org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:111)
at
org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:104)
at
org.apache.geronimo.kernel.repository.DefaultArtifactResolver$$FastClassByCGLIB$$e847b746.invoke()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
at 
org.apache.

Build broken?

[Jeff Genender]

I am not able to build the latest trunk...any ideas?

[INFO]

[INFO] Building Geronimo Configs :: System Database
[INFO]task-segment: [install]
[INFO]

[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated:
/Users/jeffgenender/Projects/geronimo/plugins/system-database/system-database/target/resources/META-INF/plan.xml
[INFO] [car:prepare-metadata]
[INFO] [car:package]
[INFO] Packaging module configuration:
/Users/jeffgenender/Projects/geronimo/plugins/system-database/system-database/target/resources/META-INF/plan.xml
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] load of
org.apache.geronimo.configs/j2ee-deployer/2.1-SNAPSHOT/car failed

Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2

[Jeff Genender]

AWESOME

Gianny Damour wrote:
> Hi,
> 
> Some heads-up.
> 
> I will soon add gshell-remote-client/common/server, gshell-whisper and
> mina dependencies so that we can remote control servers. In other words,
> it will increase a little bit more.
> 
> This may still change, however here is a list of the new commands:
> * alias: to create an alias;
> * unalias: to remove an alias;
> * execute-alias: to execute an alias;
> * remote/rsh: rsh client;
> * remote-rsh-server: rsh server;
> * remote-control/server-control: to execute a control operation
> start/stop, for a remote server. This command rsh to a gshell instance
> where the server is to be started or stopped and execute the proper
> command.
> 
> Aliases will be stored in etc/aliases.xml and users will be able to
> alter that if they want via CLI option. remote-control/server-control
> uses a hierarchical tree to defined hosts along with how to remote login
> to a gshell running on this instance and commands to control servers.
> 
> Thanks,
> Gianny
> 
> 
> On 02/12/2007, at 12:29 PM, Jason Dillon wrote:
> 
>> The core muck is a little over 1m, but for the G integration we are
>> using Groovy for commands, which adds about 2.5m for the core runtime
>> and then its got a few deps too.  I can work on optimizing this a bit,
>> have not really paid much attention, aside from trying to keep the
>> GShell core size as small as possible.
>>
>> I think we can put most of its deps in the repo and just hardcode them
>> in the classworlds conf for now.  Next version will dynamically pull
>> them out of the repo in the same way that mvn plugins do.
>>
>> --jason
>>
>>
>> On Dec 1, 2007, at 5:16 PM, Jeff Genender wrote:
>>
>>> Damn gshell...WTF?
>>>
>>> :-)
>>>
>>> I couldn't resist ;-)
>>>
>>> Jeff
>>>
>>> Jason Dillon wrote:
>>>> No doubt some increase is from the gshell libs. We can probably
>>>> optimize them a little and use repository references and such...
>>>>
>>>> --jason
>>>>
>>>>
>>>> -Original Message-
>>>> From: "Bruce Snyder" <[EMAIL PROTECTED]>
>>>>
>>>> Date: Sat, 1 Dec 2007 14:52:44
>>>> To:dev@geronimo.apache.org
>>>> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
>>>>
>>>>
>>>> On Nov 30, 2007 3:59 PM, Joe Bohn <[EMAIL PROTECTED]> wrote:
>>>>> It looks like the size of our images is increasing dramatically
>>>>> (nearly 2x).
>>>>>
>>>>> For example, the geronimo-jetty6-minimal snapshots have been growing
>>>>> like this (these image sizes are from the snapshot repo):
>>>>>
>>>>> 16604006 Jul 26 18:54
>>>>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
>>>>> 17086729 Jul 26 18:53
>>>>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.zip
>>>>>
>>>>> 22310769 Nov  1 03:19
>>>>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
>>>>> 22744083 Nov  1 03:18
>>>>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.zip
>>>>>
>>>>> 30812531 Nov 30 22:45
>>>>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
>>>>> 31248864 Nov 30 22:43
>>>>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.zip
>>>>>
>>>>>
>>>>> The javaee5 images have also grown significantly.
>>>>>
>>>>> 57099671 Jul 26 18:39
>>>>> geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.tar.gz
>>>>> 58685668 Jul 26 18:36
>>>>> geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.zip
>>>>>
>>>>> 55113050 Nov  1 03:28
>>>>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
>>>>> 56827820 Nov  1 03:25
>>>>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.zip
>>>>>
>>>>> 71313050 Nov 30 22:54
>>>>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
>>>>> 73094816 Nov 30 22:50
>>>>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.zip
>>>>>
>>>>>
>>>>> I haven't looked into the cause yet ... but does anybody have some
>>>>> ideas
>>>>> on the culprit?
>>>>
>>>> FWIW, we've experienced the same thing with ServiceMix. I think it
>>>> might be a problem with Maven and how it's resolving and including
>>>> transitive dependencies.
>>>>
>>>> Bruce
>>

Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2

[Jeff Genender]

Damn gshell...WTF?

:-)

I couldn't resist ;-)

Jeff

Jason Dillon wrote:
> No doubt some increase is from the gshell libs. We can probably optimize them 
> a little and use repository references and such...
> 
> --jason
> 
> 
> -Original Message-
> From: "Bruce Snyder" <[EMAIL PROTECTED]>
> 
> Date: Sat, 1 Dec 2007 14:52:44 
> To:dev@geronimo.apache.org
> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
> 
> 
> On Nov 30, 2007 3:59 PM, Joe Bohn <[EMAIL PROTECTED]> wrote:
>> It looks like the size of our images is increasing dramatically (nearly 2x).
>>
>> For example, the geronimo-jetty6-minimal snapshots have been growing
>> like this (these image sizes are from the snapshot repo):
>>
>> 16604006 Jul 26 18:54
>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
>> 17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.zip
>>
>> 22310769 Nov  1 03:19
>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
>> 22744083 Nov  1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.zip
>>
>> 30812531 Nov 30 22:45
>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
>> 31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.zip
>>
>>
>> The javaee5 images have also grown significantly.
>>
>> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.tar.gz
>> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.zip
>>
>> 55113050 Nov  1 03:28
>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
>> 56827820 Nov  1 03:25 geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.zip
>>
>> 71313050 Nov 30 22:54
>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
>> 73094816 Nov 30 22:50 geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.zip
>>
>>
>> I haven't looked into the cause yet ... but does anybody have some ideas
>> on the culprit?
> 
> FWIW, we've experienced the same thing with ServiceMix. I think it
> might be a problem with Maven and how it's resolving and including
> transitive dependencies.
> 
> Bruce

Re: Inserting a filter into the web container

[Jeff Genender]

Aaron Mulder wrote:
> To me, AOP seems like it would be better if the application were doing
> it, rather than trying to do it at the server configuration level.

Yeah..but looking at the response by DJ, looks like the app server is
gonna have to do it anyways ;-)

My answer was similar to DJs in that an AOP adapter could pick something
up from a JAR that it recognizes...just a different take on the same
problem ;-)

Jeff

> 
> Thanks,
>   Aaron
> 
> On Nov 29, 2007 1:48 PM, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Have you considered AOP?
>>
>> Jeff
>>
>>
>> Aaron Mulder wrote:
>>> Is there some good way to insert a filter/interceptor into the web
>>> container request processing chain that would work for both Tomcat and
>>> Jetty?  For example, let's say you wanted to apply some particular
>>> request validation/auditing functionality to every application,
>>> without changing the application configuration (e.g. without updating
>>> web.xml).  It would be easy to write a little request filter or
>>> interceptor to do it -- I'm just not sure what the best way is to hook
>>> that in so it gets executed, and whether we have common
>>> filters/interceptors for Tomcat and Jetty or whether you'd have to do
>>> something different for each.
>>>
>>> Thanks,
>>>Aaron
>>

Re: Inserting a filter into the web container

[Jeff Genender]

Have you considered AOP?

Jeff

Aaron Mulder wrote:
> Is there some good way to insert a filter/interceptor into the web
> container request processing chain that would work for both Tomcat and
> Jetty?  For example, let's say you wanted to apply some particular
> request validation/auditing functionality to every application,
> without changing the application configuration (e.g. without updating
> web.xml).  It would be easy to write a little request filter or
> interceptor to do it -- I'm just not sure what the best way is to hook
> that in so it gets executed, and whether we have common
> filters/interceptors for Tomcat and Jetty or whether you'd have to do
> something different for each.
> 
> Thanks,
>Aaron

Re: Greetings from Japan Apache Geronimo User Group

[Jeff Genender]

Thank you for introducing yourselves!  Welcome and we look forward to
any contributions.

Jeff

石田　剛 wrote:
> Hello, everyone.
> 
> This is the Greetings from Japan Apache Geronimo User Group.
> http://geronimo-jp.sourceforge.jp/
> 
> We, Japan Apache Geronimo User Group , are virtual community of the
> Geronimo-lovers. We have more than 50 members as of today, and the
> communiy is managed on a volunteer basis. We really appreciate and thank
> you for your great work, and efforts.
> 
> Just to let you know, some of the members in our group would like to
> start translating the Geronimo Tech Docs into Japanese. We're in a
> preparation phase, and it may take some time, but our goal is publishing
> the translated docs to Geronimo Wiki. ( Another goal is , of cource,
> having fun ! as we're all volunteers and having fun in the community )
> 
> You can reach us at
> [EMAIL PROTECTED](to all members)
> or
> [EMAIL PROTECTED]   (to translation members)
> 
> I just wanted to say hello and thank you , and make a formal greetings.
> Lastly, please keep on the good works like it has been !
> 
> Regards.
>  
> 
> 
> New Design Yahoo! JAPAN 2008/01/01 

[jira] Closed: (GERONIMO-3613) setConnectionTimeout() does not change the connect timeout on the connector

[Jeff Genender (JIRA)]

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

Jeff Genender closed GERONIMO-3613.
---

Resolution: Fixed

Patch applied...thanks!

> setConnectionTimeout() does not change the connect timeout on the connector
> ---
>
> Key: GERONIMO-3613
> URL: https://issues.apache.org/jira/browse/GERONIMO-3613
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: AsyncHttpClient
>Affects Versions: 1.x
>Reporter: Sangjin Lee
> Attachments: AsyncHttpClient.patch
>
>
> AsyncHttpClient.setConnectionTimeout() does not change the connect timeout on 
> the connector.  The SocketConnector object is instantiated in the 
> AsyncHttpClient constructor, and the connectTimeout instance variable is 
> applied to the configuration in the AsyncHttpClient constructor, and is never 
> used subsequently.
> setConnectionTimeout() has no effect, and getConnectionTimeout() returns a 
> misleading value as a result.

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

[jira] Closed: (GERONIMO-3618) when redirected via status code 30x, the original query is incorrectly appended to the location

[Jeff Genender (JIRA)]

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

Jeff Genender closed GERONIMO-3618.
---

Resolution: Fixed

Patch applied...thanks!

> when redirected via status code 30x, the original query is incorrectly 
> appended to the location
> ---
>
> Key: GERONIMO-3618
> URL: https://issues.apache.org/jira/browse/GERONIMO-3618
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: AsyncHttpClient
>Affects Versions: 1.x
>Reporter: Sangjin Lee
> Attachments: HttpIoHandler.patch
>
>
> If you're redirected via status code 30x (302, 301, ...), the code that 
> handles following redirects (HttpIoHandler.messageRecieved()) tries to append 
> the original query from the first request to the URL obtained from the 
> Location header of the response.  This is incorrect per HTTP specification.  
> The spec says the value of the Location header is an absoluteURI which is a 
> full URL that includes the proper query if any: 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30.  The query 
> from the original request should not be part of the second URL.

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

[jira] Closed: (GERONIMO-3614) the executor in AsyncHttpClient is static, and may not be shut down properly

[Jeff Genender (JIRA)]

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

Jeff Genender closed GERONIMO-3614.
---

Resolution: Fixed

Applied patch...thanks!

> the executor in AsyncHttpClient is static, and may not be shut down properly
> 
>
> Key: GERONIMO-3614
> URL: https://issues.apache.org/jira/browse/GERONIMO-3614
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: AsyncHttpClient
>Affects Versions: 1.x
>Reporter: Sangjin Lee
> Attachments: AsyncHttpClient.patch
>
>
> The threadPool variable in AsyncHttpClient (that gets passed to Mina for I/O) 
> is declared as static, and I believe it is a bug.  If you instantiate more 
> than one AsyncHttpClient objects, subsequent instantiations overwrite the 
> value of threadPool.
> It appears it is the responsibility of AsyncHttpClient, not the caller of 
> AsyncHttpClient, to shut down the thread pool.  It means then, if you 
> instantiated multiple AsyncHttpClient objects, and call destroyAll() on all 
> of them, only the thread pool that is associated with the last 
> AsyncHttpClient object will be properly shut down.  All previous thread pools 
> will linger.
> The fix should be to turn it into an instance variable.

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

Re: Distribution and start/stop of clustered deployments

[Jeff Genender]

Gianny Damour wrote:
> Nous parlons enfin la meme langue :).
> 

Nous avons toujours compris les uns les autres ;-)

I'll bet you didn't know I am in Paris right now...did ya? ;-)

Jeff

> Agreed: this would be a nice enhancement.
> 
>> Jeff

Re: Distribution and start/stop of clustered deployments

[Jeff Genender]

Gianny Damour wrote:
> I hope we are not talking about the same thing. I am talking about a
> "deployment time" constraint and not a "runtime" constraint mandating
> that all the servers are reachable when an application is *deployed*.
> FWIW, such a constraint was also defined by WebLogic 7.0; from WebLogic
> 8.x+, this constraint was subsequently relaxed in order to allow the
> deployment to a sub-set of the cluster members - however, users can
> still enforce it if they want and partial deployments is not
> recommended. As previously said, it is trivial to implement a GBean to
> distribute a backed configuration to a server, which was not reachable
> upon deployment.

Yes I mean deployment time...

I don't see a difference.  Yes...I think a switch for "allor nothing" or
"deploy to those who can" would be a good feature to have.

Jeff

Re: Distribution and start/stop of clustered deployments

[Jeff Genender]

Gianny Damour wrote:
> You can successfully "distribute" when all the configured cluster
> members are running. If one of them is down, then the installation
> fails. This seems to be a typical scenario - at least based on the
> clustered deployments I have been working with. 

Hmmm...I have found this to be different...

I have found that if 1 node in the cluster is bad, it is removed from
the general cluster array (i.e. look at heartbeats and the
joining/leaving of a general cluster).

This is a valid use case.  The 1 server could have a problem with
it...such as network, hardware, etc.  Not clustering due to a bad server
would defeat the purpose of providing for fail over.

> Hence this is the
> simplest implementation possible for this initial stab of clustered
> deployment. Furthermore, as I explained in my email, there is a carbon
> copy of the already backed configuration within the master-repository
> and it is trivial to: either improve the GBean in charge of the remote
> control of configurations; or to add new GBeans in order to
> automatically upload this carbon copy to cluster members which were not
> running upon installation.
> 
> Also, you still need to honor my request for heads-up :). If you are
> working on clustering, then could you please provide some headlines?
> 

I am working on the EJB clustering and hope that we can both communicate
on the list when we are committing in this area.

Jeff

Re: Distribution and start/stop of clustered deployments

[Jeff Genender]

Gianny Damour wrote:
> 2. The clustered store uploads the backed configuration to the
> registered cluster members, which subsequently locally install them. If
> the "remote" installation fails for one of the members, then the
> clustered store removes the configuration from all the members having
> successfully installed it so far.

So if one server fails, the clustering is fully disabled?  Can you
please explain if I got this right?  If so, this seems a bit heavy
handed.  I would more expect that particular server to be removed from
the cluster as opposed to shut down everything.

Jeff

Re: [DISCUSS] 2.1 Release

[Jeff Genender]

Gianny,

Since there are multiple clustering implementations going on at the same
time, could you please keep us aprised of what you are doing so we don't
clash?

Thanks,

Jeff

Gianny Damour wrote:
> Hi,
> 
> I resumed this week-end some work on clustered deployment. I think this
> will be completed in about 2-3 weeks. This will allow distribute,
> uninstall, start, stop, et cetera of configurations to a cluster as a
> single logic operation. I am keen to get this change in for 2.1, if it
> does not delay 2.1.
> 
> Thanks,
> Gianny
> 
> On 02/11/2007, at 4:00 AM, Kevan Miller wrote:
> 
>> I think it's time to start discussing the particulars of a 2.1 release.
>>
>> There's been a lot of advancements made in our plugin infrastructure.
>> There's also been the pluggable console enhancements. It would be good
>> to get a release out, with these capabilities. They provide a more
>> solid platform for future enhancements, I think.
>>
>> There's also GShell and new monitoring capabilities. I'm probably
>> missing a few other new functions.
>>
>> Finally, IIUC, 2.1 would be able to support a Terracotta plugin. I'd
>> also be very interested to hear what WADI capabilities that could be
>> exposed.
>>
>> I'm willing to bang the release manager drum. I see that Joe has
>> already started tugging on the TCK chain
>>
>> What do others think? How close are we to a 2.1 release? What
>> additional capabilities and bug fixes are needed? Can we wrap up
>> development activities in the next week or two?
>>
>> --kevan

Re: Tomcat GBean names for valves

[Jeff Genender]

+1 go for it.  The first valve/second valve came from it being an
example due to the chain...I guess it just kinda stuck ;-)

Jeff

Joe Bohn wrote:
> Would anybody have a strong objection if I renamed the GBeans for the
> Tomcat valves from "FirstValve" and "SecondValve" to reflect the
> function of the valves themselves?
> 
> FirstValve --> AccessLogValve
> SecondValve --> SingleSignOnValve
> 
> 
> Joe

Re: Promoting GShell to a real subproject

[Jeff Genender]

Move it ;-)

Kevan Miller wrote:
> No, not in my opinion. I haven't heard of any dissenters. There's been
> plenty of time for someone to raise an objection. I say -- have at it...
> 
> --kevan
> 
> On 11/1/07, *Jason Dillon* <[EMAIL PROTECTED]
> > wrote:
> 
> So shall we move the project out of the sandbox?  Do we need an
> official vote for this?
> 
> --jason
> 
> 
> On Oct 26, 2007, at 6:43 AM, Guillaume Nodet wrote:
> 
> > i think the subject is explicit.  What do people think about that ?
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > 
> > Blog: http://gnodet.blogspot.com/
> 
> 
>  

Geronimo presentation at the Irish

[Jeff Genender]

Hi,

I wanted to let everyone know I will be giving a presentation at the
Irish Java Technology Conference (ijtc) in Dublin, Ireland on Nov 8th
(16:45-18:00) on Geronimo 2.x.  The presentation is called "Apache
Geronimo: Leveraging Open Source" and is an overview of the Geronimo
server and its ability to customize your own stack.

If you are attending, I hope to see you there.  If you aren't and you
are in town, please give me a ping as I would love to hook up and have
an informal "G-Talk" at a local pub.  Lets just call it an informal BOF ;-)

Hope to see you there,

Jeff Genender
Apache Geronimo
http://geronimo.apache.org

Re: GShell as main starting component for 2.1

[Jeff Genender]

Guillaume Nodet wrote:
> What about moving  GShellout of the sandbox area and make it a real 
> subproject ?
> 

Lets open a new thread on this...but Im all for it.

Jeff

> On 10/25/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Title says it all...I'd really like to see gshell as the default
>> execution for Geronimo 2.1.  Any objectsions?  Jason, is this something
>> you can get going?
>>
>> Jeff
>>
> 
> 

GShell as main starting component for 2.1

[Jeff Genender]

Title says it all...I'd really like to see gshell as the default
execution for Geronimo 2.1.  Any objectsions?  Jason, is this something
you can get going?

Jeff

Re: Effectiveness of WADI's Design and Implementation Comforted

[Jeff Genender]

Gianni,

What you have done is very cool.  I guess my only comment is that what I
am reading is that the annotations force a lock to the clustering
engine, as opposed to being somewhat transparent by swapping out the
clustering manager.

Therefore, my application code needs these annotations coded as a part
of it.  In otherwords, in order for me to leverage the fine grained
capabilities of WADI, my application needs to be coded with the WADI
annotations.  Did I read that correctly?

Regardless...its pretty cool stuff.  We should talk about the
contract/interface for openejb...I look forward to working with you ;-)

Jeff



Gianny Damour wrote:
> On 17/10/2007, at 11:53 PM, Jeff Genender wrote:
> 
>>
>>
>> Gianny Damour wrote:
>>>
>>> Excerpt of the conclusion:
>>>
>>> "
>>> The effectiveness of the design and implementation of WADI's distributed
>>> session lookup engine and replication engine is further comforted by the
>>> observed average response times and scalability characteristics.
>>> For the considered scenarios, WADI performs better than Terracotta,
>>> which is not really surprising as...
>>>
>>
>> If I may comment here...Without fine-grained clustering capabilities, I
>> have a hard time believing that WADI can outperform Terracotta.
>> Especially with large objects...WADI would push over the entire object
>> each time, where Terracotta would only ship the changed members.  If you
>> are going to publish the numbers you did, you probably should explain
>> what is getting pushed across.
> 
> Hi,
> 
> I believe you simply skimmed through what I have been writing: firstly,
> I did provide a description of the state stored in session. Secondly,
> your comment about large objects and the inadequacy of WADI's design to
> handle them is clearly and explicitly discussed in the  second paragraph
> of the conclusion. As redundancy of information is not much of a problem
> for theoretical clustering discussions, I am reiterating: WADI does
> provide a fine grained replication mechanism, which is able to track
> field updates or method executions and replay them against replicas. If
> you are interested by this kind of stuff, then please feel free to have
> a look to this WIKI page -
> http://docs.codehaus.org/display/WADI/5.+Delta+Session+Replication.
> 
> At this stage, the delta replication stuff is under performing and
> resource intensive: to give you an idea, its average response time is
> 6.10ms for the third test scenario (average response time for default
> replication mechanism is 4.77ms for WADI and 6.36ms for Terracotta).
> Once again, as a preliminary comment to Ari's response, this is a
> scenario with HTTP session stickiness on. After this week-end, the
> performance for fine-grained replication should improve significantly. I
> intend to: get ride of native reflection; index constructor, field and
> methods description for really fast packaging on wire and resolution
> when reading back from a byte stream; and re-use reflective invokers
> (CGLIB FastMethod/Constructor and ASM customed field updaters).
> 
> FWIW, I do not see support of large objects as crucial as you for Web
> solutions. Even if I spent a couple of months working on wadi-aop to
> provide this feature, it was more with the ultimate goal to leverage it
> for efficient distributed caching than HTTP session replication. I truly
> believe that large scale Web solutions requiring HA have to be designed
> with this constraint in mind; with this constraint in mind, keeping
> session size small sounds reasonable.
> 
> 
>>> "
>>>
>>> If people are interested by clustering development, then please respond
>>> as I will resume some Geronimo clustering work and could really use a
>>> hand.
>>>
>>
>> I am in the midst of getting OpenEJB clusterable.  I would be happy to
>> combine forces and get clustering finished up for G ;-)
> 
> Great! Will post back to the dev@ list as soon as I resume Geronimo
> clustering work.
> 
> Thanks,
> Gianny
> 
> 
> 
>>
>>> Thanks,
>>> Gianny

Re: Effectiveness of WADI's Design and Implementation Comforted

[Jeff Genender]

Gianny Damour wrote:
> Hi,
> 
> 
> Over the last two weeks, I have been working on various experimentations
> in order to validate and demonstrate the effectiveness of WADI's
> distributed session engine and replication engine. I wrote a WIKI page
> to capture the findings:
> http://docs.codehaus.org/pages/viewpage.action?pageId=18186271
> 

You have been busy ;-)

> Excerpt of the conclusion:
> 
> "
> The effectiveness of the design and implementation of WADI's distributed
> session lookup engine and replication engine is further comforted by the
> observed average response times and scalability characteristics.
> For the considered scenarios, WADI performs better than Terracotta,
> which is not really surprising as...
> 

If I may comment here...Without fine-grained clustering capabilities, I
have a hard time believing that WADI can outperform Terracotta.
Especially with large objects...WADI would push over the entire object
each time, where Terracotta would only ship the changed members.  If you
are going to publish the numbers you did, you probably should explain
what is getting pushed across.


> "
> 
> If people are interested by clustering development, then please respond
> as I will resume some Geronimo clustering work and could really use a hand.
> 

I am in the midst of getting OpenEJB clusterable.  I would be happy to
combine forces and get clustering finished up for G ;-)

> Thanks,
> Gianny

Re: gshell broken in trunk?

[Jeff Genender]

Thanks!

Sent from my iPhone

On Oct 15, 2007, at 2:22 PM, Jason Dillon <[EMAIL PROTECTED]> wrote:


This should be fixed now.  Sorry for the delay.

--jason


On Oct 11, 2007, at 4:05 PM, David Jencks wrote:


I see this also.  I have no idea what caused it.

I was wondering if we could all agree on some manual integration  
tests before committing to gshell so that the projects that depend  
on it can continue to work while it evolves.  I think its great  
that ServiceMix is also starting to use gshell but without a stable  
released version we might need to be extra careful.


I expect for geronimo building the boilerplate and framework  
assemblies and making sure the framework assembly starts w/gshell  
would suffice.  Is there something fairly simple we could do for a  
SM smoke test?


thanks
david jencks

On Oct 11, 2007, at 3:14 PM, Jeff Genender wrote:


When I try to start the server with gshell...I am getting this:


java.lang.NullPointerException: Cannot get property: homeDir on  
null object
   at org.codehaus.groovy.runtime.Invoker.getProperty 
(Invoker.java:179)

   at
org.codehaus.groovy.runtime.InvokerHelper.getProperty 
(InvokerHelper.java:179)

   at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty 
(ScriptBytecodeAdapter.java:469)

   at
org.apache.geronimo.commands.StartServerCommand.doExecute 
(StartServerCommand.groovy:159)

   at
org.apache.geronimo.gshell.command.CommandSupport.execute 
(CommandSupport.java:103)

   at
org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute 
(PlexusCommandWrapper.java:71)

   at
org.apache.geronimo.gshell.DefaultCommandExecutor.execute 
(DefaultCommandExecutor.java:128)

   at
org.apache.geronimo.gshell.DefaultCommandExecutor.execute 
(DefaultCommandExecutor.java:97)

   at
org.apache.geronimo.gshell.DefaultShell.execute(DefaultShell.java: 
124)

   at
org.apache.geronimo.gshell.DefaultShell.run(DefaultShell.java:209)
   at org.apache.geronimo.gshell.GShell.run(GShell.java:156)
   at org.apache.geronimo.gshell.cli.Main.boot(Main.java:247)
   at org.apache.geronimo.gshell.cli.Main.main(Main.java:264)
   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:585)
   at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)

   at
org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)

   at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:408)

   at
org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:351)

   at
org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)

Re: [VOTE] Geronimo 2.0.2 (rc1)

[Jeff Genender]

+1

Prasad Kashyap wrote:
> +1
> 
> Cheers
> Prasad
> 
> On 10/12/07, Kevan Miller <[EMAIL PROTECTED]> wrote:
>> All,
>> I've prepared a 2.0.2 release candidate for review and vote.
>>
>> http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/
>> contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty)
>> binaries. Here are pointers to the zip files:
>>
>> http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/
>> geronimo-jetty6-jee5-2.0.2-bin.zip
>> http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/
>> geronimo-tomcat6-jee5-2.0.2-bin.zip
>> http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/
>> geronimo-jetty6-minimal-2.0.2-bin.zip
>> http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/
>> geronimo-tomcat6-minimal-2.0.2-bin.zip
>>
>> Source for the release is packaged here: http://people.apache.org/
>> ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip
>>
>> Note that this release is dependent upon the geronimo-txmanager
>> release that is currently being voted on. To build Geronimo 2.0.2,
>> you'll need to either build geronimo-txmanager from source or copy
>> the geronimo-txmanager artifacts into your local maven repo.
>>
>> The maven artifacts for Geronimo 2.0.2 are here -- http://
>> people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the
>> following archive -- http://people.apache.org/~kevan/release-votes/
>> geronimo-2.0.2.tar.gz.
>>
>> The rat report for the Geronimo 2.0.2 source is here -- http://
>> people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt
>>
>> The source for the release currently resides here -- https://
>> svn.apache.org/repos/asf/geronimo/server/branches/2.0.2
>>
>> Once the release is approved, I'll move this branch to https://
>> svn.apache.org/repos/asf/geronimo/server/tags/2.0.2
>>
>> [ ] +1 Release Geronimo 2.0.2
>> [ ] 0 No opinion
>> [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale)
>>
>> I'll plan on calling this vote on Tuesday morning (EDT).
>>
>> --kevan
>>
>>
>>
>>
>>
>>

gshell broken in trunk?

[Jeff Genender]

When I try to start the server with gshell...I am getting this:


java.lang.NullPointerException: Cannot get property: homeDir on null object
at org.codehaus.groovy.runtime.Invoker.getProperty(Invoker.java:179)
at
org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:179)
at
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:469)
at
org.apache.geronimo.commands.StartServerCommand.doExecute(StartServerCommand.groovy:159)
at
org.apache.geronimo.gshell.command.CommandSupport.execute(CommandSupport.java:103)
at
org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute(PlexusCommandWrapper.java:71)
at
org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:128)
at
org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:97)
at
org.apache.geronimo.gshell.DefaultShell.execute(DefaultShell.java:124)
at
org.apache.geronimo.gshell.DefaultShell.run(DefaultShell.java:209)
at org.apache.geronimo.gshell.GShell.run(GShell.java:156)
at org.apache.geronimo.gshell.cli.Main.boot(Main.java:247)
at org.apache.geronimo.gshell.cli.Main.main(Main.java:264)
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:585)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
at
org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)

Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release

[Jeff Genender]

Christopher Blythe wrote:
> Jeff... I agree with you on both counts. Perhaps I should present this
> from another vantage point. If you were an application developer, would
> you use web services in the manner they are currently used in DayTrader?
> Or would you try to adhere to most documented best practices and steer
> clear of very chatty (fine-grained) web services calls. If we would like
> to keep web services in DayTrader, I think they should be re-vamped to
> re-align with a scenario/pattern that is better suited for web services
> and reflect how they are predominantly used in the industry.
> 

Yep...you are going exactly where I was ;-)

If DT is not using WS the way it should be, then absolutely it should be
redone and developed in a best practice manner.

Jeff



> On 10/3/07, *Jeff Genender* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
> 
> 
> Christopher Blythe wrote:
> > Actually, I'm suggesting we pull the web services out of DayTrader all
> > together and write another web services sample app. If DayTrader is
> > truly meant to be a "performance benchmark", why would you leave
> > something in there that is in clear violation of performance best
> > practices. Doesn't exactly send the right message if you ask me.
> >
> 
> That really depends what you are trying measure.  Are you trying to
> measure raw-throughput (ping servlet, etc), or are you trying to measure
> how a JavaEE5 application using standard components is going to perform
> (more realistic)?
> 
> IMHO, I think Daytrader is a neat application that lets you kind of
> configure what you want to test and how you want to test it.  Its
> interesting because I haven't seen anything else out there that does
> this...it really is a good way to measure most components of a
> standardized stack.
> 
> Jeff
> 
> > On 10/2/07, *Matt Hogstrom* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
> >
> >
> > On Oct 1, 2007, at 11:23 PM, Christopher Blythe wrote:
> >
> > > Matt...
> > >
> > >
> > > In summary, I guess I really just wanted to say that I feel
> the web
> > > services modes in DayTrader should be removed at least until
> we can
> > > come up with something better. If the only reason to keep these
> > > around is to provide a "sample" and not a performance benchmark,
> > > lets come up with some other sample that demonstrates web
> services.
> > >
> >
> > You make a good point about the WebServices.  I'd suggest that we
> > document the current limitations of comparing these WebServices in
> > performance benchmarks.  That should help to set everyone's
> > expectations about the relevant usefulness of the data.
> >
> > For WebServices it sounds like your suggesting that we
> deprecate web
> > services for performance work rather than for functional purposes
> > like was done for the MDB primitives.  I'd be for adding the
> warning
> > in a readme.
> >
> >
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let... lets
> > evolve, let the chips fall where they may." - Tyler Durden
> 
> 
> 
> 
> -- 
> "I say never be complete, I say stop being perfect, I say let... lets
> evolve, let the chips fall where they may." - Tyler Durden

Re: DayTrader - porting MarketSummaryInterval changes from 2.0 to 1.2 and preparing to release

[Jeff Genender]

Christopher Blythe wrote:
> Actually, I'm suggesting we pull the web services out of DayTrader all
> together and write another web services sample app. If DayTrader is
> truly meant to be a "performance benchmark", why would you leave
> something in there that is in clear violation of performance best
> practices. Doesn't exactly send the right message if you ask me.
> 

That really depends what you are trying measure.  Are you trying to
measure raw-throughput (ping servlet, etc), or are you trying to measure
how a JavaEE5 application using standard components is going to perform
(more realistic)?

IMHO, I think Daytrader is a neat application that lets you kind of
configure what you want to test and how you want to test it.  Its
interesting because I haven't seen anything else out there that does
this...it really is a good way to measure most components of a
standardized stack.

Jeff

> On 10/2/07, *Matt Hogstrom* <[EMAIL PROTECTED]
> > wrote:
> 
> 
> On Oct 1, 2007, at 11:23 PM, Christopher Blythe wrote:
> 
> > Matt...
> >
> >
> > In summary, I guess I really just wanted to say that I feel the web
> > services modes in DayTrader should be removed at least until we can
> > come up with something better. If the only reason to keep these
> > around is to provide a "sample" and not a performance benchmark,
> > lets come up with some other sample that demonstrates web services.
> >
> 
> You make a good point about the WebServices.  I'd suggest that we
> document the current limitations of comparing these WebServices in
> performance benchmarks.  That should help to set everyone's
> expectations about the relevant usefulness of the data.
> 
> For WebServices it sounds like your suggesting that we deprecate web
> services for performance work rather than for functional purposes
> like was done for the MDB primitives.  I'd be for adding the warning
> in a readme.
> 
> 
> 
> 
> -- 
> "I say never be complete, I say stop being perfect, I say let... lets
> evolve, let the chips fall where they may." - Tyler Durden

Re: Frequent build breaks due to missing dependencies

[Jeff Genender]

WTF???  schadenfreude???

I had to look that up!!! :-)

Jeff

Prasad Kashyap wrote:
> They say, misery loves company.  Pardon my schadenfreude, but I'm
> relieved to know I've not been on some list targeted for victimization
> :-)
> 
> Cheers
> Prasad
> 
> On 10/2/07, Joe Bohn <[EMAIL PROTECTED]> wrote:
>>
>> Lin Sun wrote:
>>> Me too!  I haven't been able to build geronimo 2.0 branch since this AM,
>>> after some similar failures every time.
>> Persistence paid off for me.  I had to build like 8 times and with each
>> failure I built the individual component that was failing.  Eventually I
>> was able to get everything downloaded and built.  very painful.
>>
>> Joe
>>
>>

Plugin installer in trunk broke?

[Jeff Genender]

Is the plugin installer broke?  Duno if a java 1.4 dependency got in or
not, but I am unable to install plugins from the console:

java.lang.IllegalArgumentException: Cannot convert [1.5] of type class
java.util.ArrayList to class [Ljava.lang.String;
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:374)
at org.apache.el.parser.AstFunction.getValue(AstFunction.java:86)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:923)
at
jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspx_meth_c_005fotherwise_005f2(viewForDownload_jsp.java:488)
at
jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspx_meth_c_005fchoose_005f2(viewForDownload_jsp.java:435)
at
jsp.WEB_002dINF.view.car.viewForDownload_jsp._jspService(viewForDownload_jsp.java:136)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
at
org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:65)
at
org.apache.geronimo.console.MultiPagePortlet.doView(MultiPagePortlet.java:153)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
at
org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
at
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
at
org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
at
jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:70)

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

[Jeff Genender]

Cool stuff.  I probably should have alerted you to the 2.0 version of
Mina has bugs up the wazoo and would have advocated not to use it.  I
also back ported to 1.1.2 for the AyncHttpClient stuff, and that
stabilized everything.

Jeff

Jason Dillon wrote:
> Well... me thinks I've finally gotten over the major hump...
> 
> I had been using Mina 2.x (which is in pre-release right now)... I was
> using it because it has some synchronous request/response handling muck
> already there which I kinda needed to implement the remote shell proxy
> muck.  And well, I must have spent like a week digging through code,
> running tests, rebuilding my tree, and really... going crazy because no
> matter what I did nothing seemed to behave itself as I needed it to.
> 
> So I ported and basically re-wrote all that request/response stuff I
> wanted so I could add debug to it and understand why it was not happy...
> or try to at least.  It really seemed like there was some kind of
> threading problem or a sync problem but all of the diag I got from logs
> just made no sense and the results I get from running tests were random
> at best.
> 
> Ugh... so anyways, I wanted to use Mina 2.0 for the request/response
> stuff... which I rewrote anyways... so a little before midnight on the
> night before the 20th I decided to move Mina 1.1.2 (latest official
> release).  Updated some apis, hacked around a few other bits...  and
> about 10 or 10 minutes into the 20th I had the tcp transports all ported
> and... um working!!! for the normally async, req/resp and for the stream
> i/o all at the same time.  It was a nice birthday present... such a good
> feeling to finally get this crap working after going mad over it over
> the past few days!!! :-)
> 
> And now over the days past I've fixed up the vm:// transport and fixed
> some bugs in the req/resp handling which were causing things to puke up
> insanity in a oh so blissful random form.
> 
> Um... ya, so I think I've finally mastered... er well, beaten to
> submission, mina... which I still really like a lot btw...  And I've
> implemented some framework to make using it a little easier for me,
> probably going to invent some more as I go... but right now... um... it
> seems to work.  Tcp, ssl, vm... all working happy, happy.  Message
> passing along side of stream i/o sitting on top of a few
> request/response bits to boot.
> 
> Oh ya... and well, you can actually get a remote shell with this stuff
> now.  Its not 100% functional, but you can connect to a remote server
> (running a rsh-server command), authenticate (internally it will do some
> rsa key exchange muck too) and then well, you are running commands on
> the remote system.  And the output comes back to you, and you can 'exit'
> the remote shell and get back to your local shell.  Wee.
> 
> Its still not done though, all this batting with mina had kept me from
> finishing up the gshell rsh protocl bits and finishing up the state
> management and such... but I think I'm past that now, so I really hope
> to get these loose ends tied up soonish.  Its still a bit POC, I'm still
> learning and adapting to how best  to implement this stuff, but I expect
> the first version to be a "just make it work" and then after that a bit
> of refactor to clean things up (which really has how most of the gshell
> implementation has been going... sans the first week of insane code
> drops when I wrote most of it).
> 
>  * * *
> 
> Okay, I'll stop babbling now... my point is... the remoting crapo
> works... and I think that maybe in another week or so there should be
> something functional enough for me to integration back into Geronimo. 
> Something like a gsh rsh into a running server (over ssl with
> authentication) and then maybe a few stupid commands to show vm stats,
> shutdown or something else.  I guess since some peeps are keen for
> scripting muck I can show how you can use the script command to execute
> a script on a server too ;-)
> 
> I'm still working on the 'makecoffee --now' command...
> 
> :-P
> 
> Oh, and lastly... and then ya... I'll shut up...  If anyone is even
> remotely interested in any of this crap it would be nice to have another
> mass of grey matter pondering over some of its present and future...
> 
> Cheers,
> 
> --jason
> 
> 
> PS.  Sorry, I couldn't resist...  I think that the stuff in there now
> can probably support a telnet as well as ssh transport impl too.  Though
> I've yet to find an ASL friendly java ssh client+server library to build
> it with...
> 
> 
> 
> On Sep 18, 2007, at 3:09 PM, Jason Dillon wrote:
> 
>> Hiya folks... just a quick update on GShell muck...
>>
>> I've been madly hacking on the remote shell support for the past week
>> and well, its really close to being functional.  I initially was going
>> to implement a POC over ActiveMQ but that was pissing me off soo much
>> that I decided to peek at what Jeff had done with GShell and
>> discovered how incredibly cool Apache Mina is!!  So I've based

Re: Ideas on a rc.d kind of directory

[Jeff Genender]

Hehehe...Jason...messing with you is like going to Disneyland...all fun ;-)

Dude...you rock :-)  Keep up the awesome work!

Jefff

Jason Dillon wrote:
> I meant stop waiting for _more_ feedback :-P
> 
> So far its all been good, but its a bigish change so I wanted to wait
> for a bit before I did it.
> 
> I've also been sexying up gshell... :-P
> 
> --jason
> 
> 
> On Sep 10, 2007, at 5:54 PM, Jeff Genender wrote:
> 
>>
>>
>> Jason Dillon wrote:
>>> Aighty... I'm gonna stop waiting for feedback and implement this stuff
>>> for all assemblies.
>>
>> U...what am I...chopped liver? ;-)
>>
>>
>>>
>>> --jason
>>>
>>>
>>> On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote:
>>>
>>>> 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
>>>>>>

Re: Ideas on a rc.d kind of directory

[Jeff Genender]

Jason Dillon wrote:
> Aighty... I'm gonna stop waiting for feedback and implement this stuff
> for all assemblies.

U...what am I...chopped liver? ;-)


> 
> --jason
> 
> 
> On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote:
> 
>> 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: Ideas on a rc.d kind of directory

[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

[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

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

[Jeff Genender]

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 like one woudl expect)


   someserver:9447 > list-configurations
   someserver:9447 > remove-configuration some-unwanted-config
   someserver:9447 > copy-configuration default some-new-config

So, all of these operations would happen on the node named  
"someserver" listening on 9443 (over ssl of course).  Or how about  
you want to reboot a server remotely?


   someserver:9447 > restart-server now
   Geronimo server shutting down...
   
   Geronimo server shutdown.
   Geronimo server starting...
   ...
   Geronimo server started in ...

Since GShell manages the processes its really easy to perform a full  
restart of a Server w/o needing magical platform scripting muck.   
And it will just work the same on each platform too.

Re: Classloader clashing and plugins

[Jeff Genender]

David Jencks wrote:
> - have a classloader per jar (an idea Dain suggested a long time ago,
> but it requires accurate jar-jar dependency information, better than is
> in maven poms)

This one was actually my expectation with the plugin.  I hoped that my
plugin had its own classloader...but I learned the hard way.  I would
tend to vote for this one...

Thanks,

Jeff

> thanks
> david jencks
> 
>>
>> Jeff
>>
>> David Jencks wrote:
>>> I would guess that something has included a jasper jar as a dependency
>>> (either by including it in a war lib or with a dependency on the jasper
>>> jar in the geronimo repo) rather than using a dependency on the jasper
>>> config.  If you can debug this CCE and find out what classloader the
>>> jasper class is loaded in that would be very useful.
>>>
>>> thanks
>>> david jencks
>>>
>>> On Sep 2, 2007, at 7:52 AM, Jeff Genender wrote:
>>>
>>>> Hi,
>>>>
>>>> I just finished the server plugin for Terracotta which can be found
>>>> here:
>>>>
>>>> http://svn.terracotta.org/svn/tc/geronimo-plugin/trunk/geronimo-2.0/
>>>>
>>>> When I install the plugin, everything is fine.  I can start/stop
>>>> Terracotta, and works as expected.  However when I stop Geronimo and
>>>> restart it and I go to the console, the console starts to spew errors
>>>> and we get errors in a majority of the portlets (as shown below).
>>>> Anyone know why a plugin's classes are interfering with other classes?
>>>> Do we have a classloader problem?  Any ideas on what is going on?
>>>>
>>>> Side note - Terracotta needs certain components from Jetty as artifacts
>>>> and I am running the Tomcat version of Geronimo.
>>>>
>>>> Thanks,
>>>>
>>>> Jeff
>>>>
>>>> 08:46:05,413 ERROR [normal_jsp]] Servlet.service() for servlet
>>>> jsp.WEB_002dINF.view.configmanager.normal_jsp threw exception
>>>> java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl
>>>> at
>>>> org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:920)
>>>>
>>>>
>>>> at
>>>> jsp.WEB_002dINF.view.configmanager.normal_jsp._jspx_meth_c_005fif_005f0(normal_jsp.java:133)
>>>>
>>>>
>>>> at
>>>> jsp.WEB_002dINF.view.configmanager.normal_jsp._jspService(normal_jsp.java:101)
>>>>
>>>>
>>>> at
>>>> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>>>> at
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>>>
>>>>
>>>> at
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>>>
>>>>
>>>> at
>>>> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
>>>>
>>>>
>>>> at
>>>> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
>>>>
>>>>
>>>> at
>>>> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
>>>>
>>>>
>>>> at
>>>> org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:65)
>>>>
>>>>
>>>> at
>>>> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:353)
>>>>
>>>>
>>>> at
>>>> javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>>>> at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>>>> at
>>>> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
>>>> at
>>>> org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>>>> at
>>>> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
>>>> a

Re: Classloader clashing and plugins

[Jeff Genender]

Welp...that did it ;-)  I put a dep on the jasper config and the console
works...yay!

As always, thanks!  Also...this is probably yet another plugin anomoly
we need to document at some point ;-)

Jeff

David Jencks wrote:
> I would guess that something has included a jasper jar as a dependency
> (either by including it in a war lib or with a dependency on the jasper
> jar in the geronimo repo) rather than using a dependency on the jasper
> config.  If you can debug this CCE and find out what classloader the
> jasper class is loaded in that would be very useful.
> 
> thanks
> david jencks
> 
> On Sep 2, 2007, at 7:52 AM, Jeff Genender wrote:
> 
>> Hi,
>>
>> I just finished the server plugin for Terracotta which can be found here:
>>
>> http://svn.terracotta.org/svn/tc/geronimo-plugin/trunk/geronimo-2.0/
>>
>> When I install the plugin, everything is fine.  I can start/stop
>> Terracotta, and works as expected.  However when I stop Geronimo and
>> restart it and I go to the console, the console starts to spew errors
>> and we get errors in a majority of the portlets (as shown below).
>> Anyone know why a plugin's classes are interfering with other classes?
>> Do we have a classloader problem?  Any ideas on what is going on?
>>
>> Side note - Terracotta needs certain components from Jetty as artifacts
>> and I am running the Tomcat version of Geronimo.
>>
>> Thanks,
>>
>> Jeff
>>
>> 08:46:05,413 ERROR [normal_jsp]] Servlet.service() for servlet
>> jsp.WEB_002dINF.view.configmanager.normal_jsp threw exception
>> java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl
>> at
>> org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:920)
>>
>> at
>> jsp.WEB_002dINF.view.configmanager.normal_jsp._jspx_meth_c_005fif_005f0(normal_jsp.java:133)
>>
>> at
>> jsp.WEB_002dINF.view.configmanager.normal_jsp._jspService(normal_jsp.java:101)
>>
>> at
>> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>
>> at
>> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
>>
>> at
>> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
>>
>> at
>> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
>>
>> at
>> org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:65)
>>
>> at
>> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:353)
>>
>> at
>> javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
>> at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
>> at
>> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
>> at
>> org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
>> at
>> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>
>> at
>> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
>>
>> at
>> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
>>
>> at
>> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
>>
>> at
>> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
>>
>> at
>> org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
>>
>> at
>> org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119)
>>
>> at
>> org.apache.pluto.portalImp

Classloader clashing and plugins

[Jeff Genender]

Hi,

I just finished the server plugin for Terracotta which can be found here:

http://svn.terracotta.org/svn/tc/geronimo-plugin/trunk/geronimo-2.0/

When I install the plugin, everything is fine.  I can start/stop
Terracotta, and works as expected.  However when I stop Geronimo and
restart it and I go to the console, the console starts to spew errors
and we get errors in a majority of the portlets (as shown below).
Anyone know why a plugin's classes are interfering with other classes?
Do we have a classloader problem?  Any ideas on what is going on?

Side note - Terracotta needs certain components from Jetty as artifacts
and I am running the Tomcat version of Geronimo.

Thanks,

Jeff

08:46:05,413 ERROR [normal_jsp]] Servlet.service() for servlet
jsp.WEB_002dINF.view.configmanager.normal_jsp threw exception
java.lang.ClassCastException: org.apache.jasper.runtime.ELContextImpl
at
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:920)
at
jsp.WEB_002dINF.view.configmanager.normal_jsp._jspx_meth_c_005fif_005f0(normal_jsp.java:133)
at
jsp.WEB_002dINF.view.configmanager.normal_jsp._jspService(normal_jsp.java:101)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
at
org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:65)
at
org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:353)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
at
org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
at
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
at
org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
at
jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:70)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
at
org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
at
jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:67)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp

Trouble with 2.0.1 main pom and building anything a G dependency

[Jeff Genender]

Hi,

I was building a 3rd party application with a dependency on the Geronimo
specs (jee)...and I could not get it to build because it was looking for

axis-saaj-1.3-r562247

For the life of me, I thought I had that usual maven corrupt repo issues
and I wiped out my local repo...a number of times.  I began looking
through repos and sure enough it didn't exist.  Well..I decided to look
in our pom and I found:

1.3-r562247

Further discussion with others resulted in finding that we have a
"special" repository that pulls these special versions. (Ok I forgot
about that).

This is going to be a problem for anyone who has a dependency on our
jars (ie. wanting to use the specs jars for a web applications, etc).
If I (a committer) had to go through this much trouble trying to figure
out how to get that dependency...I can't imagine what the standard user
will go through when writing a web or webservices application.

The point I am making here is if we are going to have special versions
of jars, we need to make these more readily available.

Here are some options I thought of:

A) Place the special jars in central so they are automatically available
to others. (Easiest approach for the user - but we are going to have to
convince other projects to put them out into their locations - that may
prove difficult).

B) Heavily, heavily document how to get around this problem by adding
our repo to their pom.  This should be easily Googled and placed in a
FAQ, because I would hazard to guess this will be a frequent question.
(probably the easiest approach for us, but this needs to be a short term
solution - and its still a PITA for our users).

C) Convince the other projects to get their releases in order and get
good versions of their product on central. (Should do this regardless of
any other option).

D) Rename our special versions to g-axis-saaj-1.3-r562247 and house
those under our own control (org.apache.geronimo...) in central on our
next build (2.0.2). (The easy and quick, and very temprary fix!)

Thoughts? Comments?

Thanks,

Jeff

Re: removal of spring dependencies from cxf module

[Jeff Genender]

No...that made much more sense to me ;-)

I think convenience is the way to go.  I am following you now.

Thanks,

Jeff

David Jencks wrote:
> 
> On Aug 27, 2007, at 11:26 AM, Jeff Genender wrote:
> 
>> David,
>>
>> So perhaps I am missing something and you could help clarify this.  You
>> say "It's by no means obvious to me that treating this as a problem with
>> the coding of our classloaders is appropriate."  Yet in your 1, 2, and 3
>> options, you seem to be saying its basically a problem with
>> classloading.  Is it our classloaders, or is it Spring's (or other)?
> 
> Sorry I'm not being clear.
> 1>> problem with cxf that no amount of changing our classloader code or
> configuration will fix.  The same problem would occur in tomcat if you
> tried to use a spring version incompatible with cxf.
> 
> 2>> our classloader works as long as you provide spring in the web app
> for use by the web app.  We could optionally enhance our classloader so
> a user would not need spring added to hidden-classes for the web app.
> 
> 3>> For ease in making sure the classes from our copy of spring are
> normally loaded in the same classloader no matter who is using them, we
> might consider have a spring configuration with just the spring classes
> in it.  This would be more useful if the optional enhancement suggested
> in (2) was made.
> 
> So I don't see any way the code in our classloaders is wrong.  We might
> be able to make some things more convenient, and one of those things
> would involve a new feature in our classloaders.
> 
> I know there's a good chance I'm still writing incomprehensibly, so
> don't be shy if this still doesn't make sense :-)
> 
> thanks
> david jencks
> 
>>
>> Jeff
>>
>> David Jencks wrote:
>>
>>> Cool down a minute and think about this.  What happens in tomcat if you
>>> want to use cxf + an incompatible version of spring in your app?  You
>>> bundle cxf + springA + springB into your web-app and then what happens?
>>>
>>> IMO we are talking about trying to get geronimo to generically solve a
>>> problem that tomcat forces its users to deal with on an per-app basis.
>>>
>>> It's by no means obvious to me that treating this as a problem with the
>>> coding of our classloaders is appropriate.  Here  are some possibilities
>>> I can think of off the top of my head:
>>>
>>> 1. cxf generates some code  for each web service client/service that
>>> directly use spring classes.  In this case there is AFAIK no way for an
>>> app to use a different spring version since these generated classes are
>>> going to be loaded in the application classloader and they need access
>>> to cxf's copy of spring classes.  If this is what is going on I hope
>>> it's possible for cxf to stop doing this.
>>>
>>> 2. If putting spring in the apps hidden-classes works and allows the app
>>> to use a different spring version, then evidently (1) isn't a problem.
>>> In this case if we automatically add spring to hidden-classes of every
>>> app we would be preventing all apps from using our copy of spring which
>>> seems undesirable to me.  hidden-classes currently means "don't import
>>> these classes from parents".  We could look into also having a "don't
>>> export these classes to children" filter in our classloader.
>>>
>>> 3. With just the "don't export" filter proposed in (2), people adding
>>> the spring jars to their dependency list would be getting spring loaded
>>> in a different classloader for their app and for cxf.  This might not be
>>> desirable.  We could make a spring configuration to provide a single
>>> classloader to load spring in that cxf and apps could depend on.
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>>
>>>>>
>>>>> I believe it's the latter. In which case, you're not giving me an
>>>>> apples-to-apples comparison, IMO.
>>>>>
>>>>
>>>> Well...lets agree to disagree.  The bottom line is we are castrating
>>>> other projects because we have messed up classloaders.  That, IMNSHO,
>>>> has nothing to do with apples-to-apples comparison and we are
>>>> creating a
>>>> treatment to the problem rather than a panacea.
>>>>
>>>> Do as you may, but call my issue with how we are handling this a
>>>> dissenting voice.  I am not in agreement with this action.
>>>>
>>>>> --kevan
>>>>>

Re: removal of spring dependencies from cxf module

[Jeff Genender]

David,

So perhaps I am missing something and you could help clarify this.  You
say "It's by no means obvious to me that treating this as a problem with
the coding of our classloaders is appropriate."  Yet in your 1, 2, and 3
options, you seem to be saying its basically a problem with
classloading.  Is it our classloaders, or is it Spring's (or other)?

Jeff

David Jencks wrote:

> Cool down a minute and think about this.  What happens in tomcat if you
> want to use cxf + an incompatible version of spring in your app?  You
> bundle cxf + springA + springB into your web-app and then what happens?
> 
> IMO we are talking about trying to get geronimo to generically solve a
> problem that tomcat forces its users to deal with on an per-app basis.
> 
> It's by no means obvious to me that treating this as a problem with the
> coding of our classloaders is appropriate.  Here  are some possibilities
> I can think of off the top of my head:
> 
> 1. cxf generates some code  for each web service client/service that
> directly use spring classes.  In this case there is AFAIK no way for an
> app to use a different spring version since these generated classes are
> going to be loaded in the application classloader and they need access
> to cxf's copy of spring classes.  If this is what is going on I hope
> it's possible for cxf to stop doing this.
> 
> 2. If putting spring in the apps hidden-classes works and allows the app
> to use a different spring version, then evidently (1) isn't a problem. 
> In this case if we automatically add spring to hidden-classes of every
> app we would be preventing all apps from using our copy of spring which
> seems undesirable to me.  hidden-classes currently means "don't import
> these classes from parents".  We could look into also having a "don't
> export these classes to children" filter in our classloader.
> 
> 3. With just the "don't export" filter proposed in (2), people adding
> the spring jars to their dependency list would be getting spring loaded
> in a different classloader for their app and for cxf.  This might not be
> desirable.  We could make a spring configuration to provide a single
> classloader to load spring in that cxf and apps could depend on.
> 
> thanks
> david jencks
> 
>>
>>
>>>
>>> I believe it's the latter. In which case, you're not giving me an
>>> apples-to-apples comparison, IMO.
>>>
>>
>> Well...lets agree to disagree.  The bottom line is we are castrating
>> other projects because we have messed up classloaders.  That, IMNSHO,
>> has nothing to do with apples-to-apples comparison and we are creating a
>> treatment to the problem rather than a panacea.
>>
>> Do as you may, but call my issue with how we are handling this a
>> dissenting voice.  I am not in agreement with this action.
>>
>>> --kevan
>>>

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

[Jeff Genender]

Jason Dillon wrote:
> So, is this something that I should pursue?  I've seen a few positive
> comments on this functionality, nothing negative...
> 
> Should I invest more time in making this feature complete and set it up
> as the default system for launching the server?

Yes!


> 
> --jason
> 
> 
> On Aug 21, 2007, at 3:05 PM, Jeff Genender wrote:
> 
>> Oh man this is sweet...
>>
>> I'd *really* like to see this in 2.0.2...
>>
>> Jeff
>>
>> Jason Dillon wrote:
>>> Hiya folks, I finally got around to finishing up my POC of using GShell
>>> to launch the Geronimo Server and I have committed the bits that make it
>>> work to server/trunk.  The new module which contains the GShell command
>>> implementation (and support) classes is:
>>>
>>> modules/geronimo-commands
>>>
>>> And a new assembly which has the GShell bits all in place for folks to
>>> test with is:
>>>
>>> assemblies/geronimo-jetty6-javaee5-gshell
>>>
>>> The assembly is not hooked up by default, but the code module is.  So,
>>> to test it out, you need to do something like:
>>>
>>> svn co https://svn.apache.org/repos/asf/geronimo/server/trunk server
>>> cd server
>>> mvn
>>> assemblies/geronimo-jetty6-javaee5-gshell
>>> mvn
>>>
>>> Then unzip the assembly:
>>>
>>> unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
>>>
>>> And then finally try it out.  First lets get the basic GShell
>>> command-line help:
>>>
>>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
>>>
>>> This should spit out something like:
>>>
>>> 
>>>   _  _ _
>>>   / ___/ ___|| |__   ___| | |
>>>  | |  _\___ \| '_ \ / _ \ | |
>>>  | |_| |___) | | | |  __/ | |
>>>   \|/|_| |_|\___|_|_|
>>>
>>>  GShell -- Geronimo command-line shell
>>>
>>> usage: gsh [options]  [args]
>>> -n,--non-interactiveRun in non-interactive mode
>>> -D,--define Define a system property
>>> -V,--versionDisplay GShell version
>>> -c,--commands   Read commands from string
>>> -debug,--debug  Enable DEBUG logging output
>>> -h,--help   Display this help message
>>> -i,--interactiveRun in interactive mode
>>> -quiet,--quiet  Limit logging output to ERROR
>>> -verbose,--verbose  Enable INFO logging output
>>> 
>>>
>>> Then lets run the interactive-shell:
>>>
>>> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
>>>
>>> This should leave you at a very plain prompt at the moment:
>>>
>>> 
>>>> _
>>> 
>>>
>>> At this point you can type something like this to list all of the known
>>> commands:
>>>
>>> 
>>> help commands
>>> 
>>>
>>> Which should spit back:
>>>
>>> 
>>> Available commands (and aliases):
>>>   start-server ( start )
>>>   set
>>>   exit ( quit, bye )
>>>   unset
>>>   source
>>>   help
>>> 
>>>
>>> The command that I added is called 'start-server', with an alias of
>>> 'start'.  This is basically an augmented and enhanced version of what
>>> the geronimo:start-server goal does in the geronimo-maven-plugin.  To
>>> see its options run this:
>>>
>>> 
>>> start-server --help
>>> 
>>>
>>> And it says:
>>>
>>> 
>>> start-server -- Starts a new Geronimo server instance
>>>
>>> usage: start-server [options]
>>> -A,--javaagent   Use a specific Java Agent, set to
>>> 'none' to
>>>   disable
>>> -D,--property Set a system property
>>> -H,--homeUse a specific Geronimo home directory
>>> -J,--javaopt  Set a JVM flag
>>> -b,--background   Run the server process in the
>>> background.
>>> -h,--help Display this help message
>>> -j,--jvm Use a specific Java Virtual Machine
>>> for server
>>>   process
>>> -l,--logfile  

Re: removal of spring dependencies from cxf module

[Jeff Genender]

Kevan Miller wrote:
> K. Can you explain to me what functionality is being taken away? Dan
> said function would be lost, but then listed functionality and said that
> configuring them "becomes quite a bit harder". Nor do I know how this
> increased complexity would be who bears the burden for things becoming
> quite a bit harder.
>

Read Dan's comment/answer.  The functionality is the ease of
configuration, etc.  For someone who has used Spring extensively, I
think its a huge loss not to be able to leverage it.

> I want the client application to be in control of the Spring version. I
> don't want the Geronimo server environment to dictate the version of
> Spring used by the client application. At present, we are dictating the
> version of Spring. I think this needs to change. I don't think this is a
> result of our ClassLoader structure.
>

What are you talking about...this is clearly a classloader problem.  The
fact the client and the server are fighting over whose version of Spring
is the "right one" points its finger at a classloader issue.  The fact
the client has to set the hidden classes attribute on plans clearly
shows this is a classloader problem.  Am I missing or not seeing
something here?  If so, please point it out...perhaps I'm simply not
getting it.  Clashing versions is about as classloader related as it gets.


>>
>>>
>>> I have no real issue with our CXF server module requiring Spring.
>>>
>>> I'm less happy if we're requiring that Spring be accessible from a
>>> client application module to configure CXF web services client
>>> capabilities.
>>>
>>> I'm way less happy if we require the same Spring instance be accessible
>>> from the CXF server module and the client application module. This is
>>> the case, at the moment. I think this needs to be changed.
>>>
>>
>> Why should it be changed?  This seems to work with someone using
>> Tomcat...just not Geronimo.
> 
> Does Tomcat embed CXF? Does CXF distribute Tomcat binaries configured to
> provide CXF-based web services? Or does CXF distribute CXF and
> associated dependent jars which can be packaged into a WAR and
> subsequently deployed into a web container?

CXF can certainly be used in Tomcat.  Tomcat doesn't distribute it, but
it certainly can be used with that web container.  It appears the only
project who has this problem is Geronimo :-/


> 
> I believe it's the latter. In which case, you're not giving me an
> apples-to-apples comparison, IMO.
> 

Well...lets agree to disagree.  The bottom line is we are castrating
other projects because we have messed up classloaders.  That, IMNSHO,
has nothing to do with apples-to-apples comparison and we are creating a
treatment to the problem rather than a panacea.

Do as you may, but call my issue with how we are handling this a
dissenting voice.  I am not in agreement with this action.

> --kevan
> 

Re: removal of spring dependencies from cxf module

[Jeff Genender]

Kevan Miller wrote:
> 
> On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote:
> 
>>
>> From my standpoint, it would be greatly preferred if you could find a way
>> to leave spring for CXF.   There is definitely a lot of functionality
>> that would be lost if spring is not available.  In particular, if a user
>> want to configure various things like message logging or
>> WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc...,
>> without the spring config, it becomes quite a bit harder.   For very
>> basic usage, spring is optional.   But once you want some
>> customizations, you really need it.
> 
> OK. First I've heard of loss of functionality... Is there loss of
> functionality? Or things become harder without Spring? If things become
> harder, an important question is who pays the price? The embedder (i.e.
> us)? Or the user?

I have to agree with Dan on this.  This is clearly our problem.  It's
Geronimo's classloaders that are causing the issue.  We are taking away
functionality at the expense of our inability to handle Spring.

> 
> I have no real issue with our CXF server module requiring Spring.
> 
> I'm less happy if we're requiring that Spring be accessible from a
> client application module to configure CXF web services client
> capabilities.
> 
> I'm way less happy if we require the same Spring instance be accessible
> from the CXF server module and the client application module. This is
> the case, at the moment. I think this needs to be changed.
> 

Why should it be changed?  This seems to work with someone using
Tomcat...just not Geronimo.

>>
>> I suppose one option might be to document how to put spring back in if
>> someone needs it.   We could then add more advanced thing to those docs
>> like where to get the additional jars for WS-RM/WS-A/WS-Security, JMS
>> transports, etc   Kind of an "Advanced WebServices with CXF" type
>> docs.
> 
> Can you point me to documentation on how a user configures this
> functionality currently?
> 
> --kevan

Re: Now that we released...how about 2 more...

[Jeff Genender]

Kevan Miller wrote:
> So, to be clear -- I certainly didn't mean to imply that *only* you
> could certify these alternate configurations of Geronimo. If anyone with
> TCK access wants to run these tests, then that's fantastic. I don't plan
> on running them. If I see requests from Geronimo users requesting
> certification of these configurations, then I'd probably run them myself.

Well...nobody asked you to run them.  But, your statement is somewhat
offensive...I guess I don't really get the distinction between requests
from "users" and requests from your co-committers...what are the rest of
us, chopped liver?  Aren't we all users? You certainly are setting the
stage for making me want to help you out when you throw out an idea on
the lists or have an issue that needs looking into
(http://www.mail-archive.com/dev@geronimo.apache.org/msg39121.html).

I'll be sure to use that ideology the next time you need a favor...great
community spirit! ;-)

At any rate, lets let this go...its going down a slippery slope...this
already has gone off topic and contains overtones of personal issues
that are not even related to the discussion (i.e. someone's having a bad
day).

Jeff

Re: removal of spring dependencies from cxf module

[Jeff Genender]

Kevan Miller wrote:
> 
> On Aug 24, 2007, at 5:35 PM, Jeff Genender wrote:
> 
>> Kevan,
>>
>> IIU the reason you are asking, removal of the Spring dependencies from
>> CXF would appear to be a band aid and temporary fix to the real issue.
>> Is this about the Spring versioning and different versions getting
>> loaded? (If not then never mind)
> 
> I wouldn't characterize this as a band-aid. And I doubt that I would
> advocate a different approach to solving this problem in a 2.0.x release.
> 

Umm...why wouldn't you characterize this as a band aid?  The problem is
our class loaders.  You still have this problem if someone integrates
something that uses Spring...right?


> FYI, at present, cxf-based web services client code requires access to
> Spring classes from the application's ClassLoader. So, even if you
> wanted to completely isolate the application ClassLoader from system
> ClassLoaders, this must be changed. I probably could have narrowed my
> request a bit by saying can we just fix this web services client code
> dependency -- better, I think to remove the spring dependency all
> together from our cxf module.
> 

So what would happen if I integrate another 3rd party component that
uses Spring...say...Terracotta DSO? Or...ServiceMix?  What happens then?

> --kevan

Re: Now that we released...how about 2 more...

[Jeff Genender]

Kevan Miller wrote:
> 
> That would be great. Do you have a login on the test systems that have
> been used for cert? Or perhaps a better solution is to setup a shared
> (or temporary use) cts login that could be used...
> 

Sure...I would be happy to.  Would you like to help me with the clustering?

Jeff

> --kevan

Re: Now that we released...how about 2 more...

[Jeff Genender]

Kevan Miller wrote:
> 
> On Aug 24, 2007, at 10:48 AM, Jeff Genender wrote:
> 
>> Any chance we can release a Jetty/Axis and Tomcat/CXF?  2 more TCK runs?
> 
> Both are "released" -- it's just a matter of configuration. You want 2
> additional assemblies with these configured by default available for
> download? Or are you interested in certification tests being run on
> these alternate configurations?

Well..switching the configuration doesn't necessarily mean certified ;-)

I am interested in the cert tests begin run on the alternate configurations.

Thanks,

Jeff



> 
> --kevan

Re: removal of spring dependencies from cxf module

[Jeff Genender]

Kevan,

IIU the reason you are asking, removal of the Spring dependencies from
CXF would appear to be a band aid and temporary fix to the real issue.
Is this about the Spring versioning and different versions getting
loaded? (If not then never mind)

Jeff

Kevan Miller wrote:
> We've run into multiple issues caused by the dependency of our cxf
> module on Spring.
> 
> Jarek, you've mentioned that it's possible to switch from Spring-based
> configuration of CXF to, hmm, some other form of configuration
> (xml/programmatic?). How hard would this be? Could we get this done for
> a 2.0.2 release?
> 
> --kevan

Now that we released...how about 2 more...

[Jeff Genender]

Any chance we can release a Jetty/Axis and Tomcat/CXF?  2 more TCK runs?

Jeff

Now that we released...how about 2 more...

[Jeff Genender]

Any chance we can release a Jetty/Axis and Tomcat/CXF?  2 more TCK runs?

Jeff

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

[Jeff Genender]

Oh man this is sweet...

I'd *really* like to see this in 2.0.2...

Jeff

Jason Dillon wrote:
> Hiya folks, I finally got around to finishing up my POC of using GShell
> to launch the Geronimo Server and I have committed the bits that make it
> work to server/trunk.  The new module which contains the GShell command
> implementation (and support) classes is:
> 
> modules/geronimo-commands
> 
> And a new assembly which has the GShell bits all in place for folks to
> test with is:
> 
> assemblies/geronimo-jetty6-javaee5-gshell
> 
> The assembly is not hooked up by default, but the code module is.  So,
> to test it out, you need to do something like:
> 
> svn co https://svn.apache.org/repos/asf/geronimo/server/trunk server
> cd server
> mvn
> assemblies/geronimo-jetty6-javaee5-gshell
> mvn
> 
> Then unzip the assembly:
> 
> unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
> 
> And then finally try it out.  First lets get the basic GShell
> command-line help:
> 
> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
> 
> This should spit out something like:
> 
> 
>   _  _ _
>   / ___/ ___|| |__   ___| | |
>  | |  _\___ \| '_ \ / _ \ | |
>  | |_| |___) | | | |  __/ | |
>   \|/|_| |_|\___|_|_|
> 
>  GShell -- Geronimo command-line shell
> 
> usage: gsh [options]  [args]
> -n,--non-interactiveRun in non-interactive mode
> -D,--define Define a system property
> -V,--versionDisplay GShell version
> -c,--commands   Read commands from string
> -debug,--debug  Enable DEBUG logging output
> -h,--help   Display this help message
> -i,--interactiveRun in interactive mode
> -quiet,--quiet  Limit logging output to ERROR
> -verbose,--verbose  Enable INFO logging output
> 
> 
> Then lets run the interactive-shell:
> 
> ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
> 
> This should leave you at a very plain prompt at the moment:
> 
> 
>> _
> 
> 
> At this point you can type something like this to list all of the known
> commands:
> 
> 
> help commands
> 
> 
> Which should spit back:
> 
> 
> Available commands (and aliases):
>   start-server ( start )
>   set
>   exit ( quit, bye )
>   unset
>   source
>   help
> 
> 
> The command that I added is called 'start-server', with an alias of
> 'start'.  This is basically an augmented and enhanced version of what
> the geronimo:start-server goal does in the geronimo-maven-plugin.  To
> see its options run this:
> 
> 
> start-server --help
> 
> 
> And it says:
> 
> 
> start-server -- Starts a new Geronimo server instance
> 
> usage: start-server [options]
> -A,--javaagent   Use a specific Java Agent, set to
> 'none' to
>   disable
> -D,--property Set a system property
> -H,--homeUse a specific Geronimo home directory
> -J,--javaopt  Set a JVM flag
> -b,--background   Run the server process in the background.
> -h,--help Display this help message
> -j,--jvm Use a specific Java Virtual Machine
> for server
>   process
> -l,--logfileCapture console output to file
> -m,--module Start up a specific module by name.
> -q,--quietSuppress informative and warning messages
> -t,--timeout Specify the timeout for the server
> process in
>   seconds
> -v,--verbose  Enable verbose output; specify
> multipule times
>   to increase verbosity.
> 
> 
> NOTE: Use -vv for --veryverbose ;-)
> 
> And then give it a whirl and try to start the server up from the shell:
> 
> 
> start-server
> 
> 
> or if you prefer more output:
> 
> 
> start-server -v
> 
> 
> And so on...
> 
> This will actually create a newly forked JVM to run the server in, and
> will eventually have a robust node manager thingy, but I've not done
> that yet ;-)
> 
> The platform scripts are now super simple!!!  All of the logic is now in
> the command implementation.  And eventually we can probably have the
> geronimo-maven-plugin just invoke the command so that *everything* uses
> the exact same method for launching the server process.
> 
>  * * *
> 
> As requested by Jeff, I added support to read in some scripts to augment
> the launching of the server... so that plugins can add properties and
> such easily.  Right now this is the directory which is inspected for
> scripts:
> 
> etc/rc.d
> 
> And currently the scripts need to be named like this:
> 
>,.groovy
> 
> I've created a default one for you to look at:
> 
> etc/rc.d/start-server,default.groovy
> 
> Which simply sets the max heap size to 512m:
> 
> 
> command.javaFlags << '-Xmx512m'
> 
> 
> When running the start-server comman

Re: Updating the Sun WebSite

[Jeff Genender]

Joe Bohn wrote:
> 
> 
> Matt Hogstrom wrote:
>> Jeff / Joe,
>>
>> Can we get the Sun WebSite updated with Geronimo 2.0.1 being certified
>> rather than 2.0-M6-rc1?
> 
> Jeff has the Sun contacts.  Also, we certified 2.0.1 with a different OS
> and with a newer patch/exclude list.  I'll put the updated information
> to document our certification on the TCK list for you Jeff.

Sounds good...thats what I need.

Jeff

> 
> Joe

Re: Removing 1.0 and 1.1 from the download site...any objections?

[Jeff Genender]

+1

Matt Hogstrom wrote:
> All,
> 
> Since 1.1.1 is the stable version of Geronimo I'd like to propose that
> we remove the older versions from the download site.  If there are no
> objections I'll do this tomorrow when we announce the 2.0.1 release.

Re: project involvement

[Jeff Genender]

Congrats on the marriage!

Sachin Patel wrote:
> Hello community members...
> 
> I'd thought I'd shoot of a note to explain my limited involvement in the
> project as of recent.  As some have you may have known, I've taken a new
> job thats taken has taken away from the Java enterprise space.  As we
> all know what starting a new job is like, I've had very limited time
> with following the progress of Geronimo 2.0 and keeping up with the
> Geronimo Eclipse Plugin.  I ask that the community see to it that they
> continue their involvement in providing Geronimo best Java EE tooling
> and once things aren't so hectic with my life (a new job & getting
> married in 3 weeks!) I'll continue to be involved as I can.
> 
> - sachin

Re: [VOTE] Geronimo 2.0.1 (rc1)

[Jeff Genender]

My +1.

On Aug 17, 2007, at 9:00 AM, Matt Hogstrom wrote:


Sent my vote to the user list by accident.

Here is my official +1

On Aug 15, 2007, at 4:39 PM, Matt Hogstrom wrote:

The updated binaries are available for review.  I have  
incorporated the security changes provided by David Jencks, Kevan  
and Vamsi.  Thanks gents !


I also incorporated a few additional fixes.  Please note the  
change log for the changes to the release notes for more information.


The binaries and source are available at:  http:// 
people.apache.org/~hogstrom/geronimo-2.0.1-rc1


I have placed the uber repo jar in the main directory with sub  
directories of src and assemblies respectively for the other  
components.


Please don't comment in this thread but rather use the DISCUSS  
thread for issues / discussion items.


[ ] +1 Release these binaries
[ ] 0 No opinion
[ ] -1 Do not release (please provide rationale)

This vote will conclude on Saturday August 18th at 1700.

[jira] Commented: (GERONIMO-3389) console: java.lang.UnsatisfiedLinkError is thrown when create a Tomcat APR HTTP Connector

[Jeff Genender (JIRA)]

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

Jeff Genender commented on GERONIMO-3389:
-

This is not a bug. This is normal and expected without the native libraries 
present.

See this link for more info:

http://tomcat.apache.org/tomcat-6.0-doc/apr.html

IMHO this should be closed and an enhancement JIRA be opened if there is a need 
for the console app to decide whether or not to even show the APR connector 
based on the existence of the APR libs.

> console: java.lang.UnsatisfiedLinkError is thrown when create a Tomcat APR 
> HTTP Connector
> -
>
> Key: GERONIMO-3389
> URL: https://issues.apache.org/jira/browse/GERONIMO-3389
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: documentation, Tomcat
>Affects Versions: 2.0, 2.0.x, 2.1
> Environment: Windows xp sp2, IE, Firefox
>Reporter: Song
> Fix For: 2.0.x
>
>
>   Click on "Save" button after entering all necessary parameters for creating 
> a new Tomcat APR HTTP Connector "test_APR_HTTP", it returned to the Network 
> Listeners list page. However,the Protocol for test_APR_HTTP is empty, State 
> is failed. And java.lang.UnsatisfiedLinkError is thrown from the server 
> started console and server.log.
>   Same error to creating Tomcat APR HTTPS Connetor.
>   
> Detailed error as below:
> --
> 13:33:46,515 WARN  [ConnectorGBean] test_APR_HTTP connector failed
> 13:33:46,515 ERROR [Connector] Coyote connector has not been started
> 13:33:46,515 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="org.apache.geronimo.configs/tomcat6/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0-SNAPSHOT/car,j2eeType=GBean,name=test_APR_HTTP"
> java.lang.UnsatisfiedLinkError: org/apache/tomcat/jni/Pool.create(J)J
>   at org.apache.tomcat.util.net.AprEndpoint.init(AprEndpoint.java:579)
>   at 
> org.apache.coyote.http11.Http11AprProtocol.init(Http11AprProtocol.java:121)
>   at 
> org.apache.catalina.connector.Connector.initialize(Connector.java:1059)
>   at 
> org.apache.catalina.core.StandardService.addConnector(StandardService.java:267)
>   at org.apache.catalina.startup.Embedded.addConnector(Embedded.java:327)
>   at 
> org.apache.geronimo.tomcat.TomcatContainer.addConnector(TomcatContainer.java:383)
>   at 
> org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke()
>   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
>   at 
> org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830)
>   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.tomcat.TomcatContainer$$EnhancerByCGLIB$$fa3733e1.addConnector()
>   at 
> org.apache.geronimo.tomcat.connector.ConnectorGBean.doStart(ConnectorGBean.java:95)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996)
>   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.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553)
>   at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
>   at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365)
>   at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>   at 
> org.apache.geronimo.tomcat.connector.Http11APRProtocol$$EnhancerByCGLIB$$abc46ac2.startRecursive()
>   at 
> org.apache.geronimo.console.webmanager.C

Now that 2.0 is released...

[Jeff Genender]

How about releasing the other 2 configurations?  i.e. Tomcat/CXF and
Jetty/Axis2.  Any objections to running the TCK on these and releasing
those as well?

Jeff

Re: DRAFT Press Release (taking this forward to the PRC on Monday unless there are significant changes ... keep 'em coming)

[Jeff Genender]

+1...looks good.

Matt Hogstrom wrote:
> This works for me.   Anyone else ?
> 
> On Aug 11, 2007, at 7:37 PM, Jarek Gawor wrote:
> 
>> Matt,
>>
>> A few comments:
>>
>> 1) I We should say Apache Axis2 instead of just Apache Axis.
>>
>> 2) I liked the original first paragraph because it announced Geronimo
>> as Java EE 5 server which is really the most important bit of this
>> release. Therefore, I think the press release should start with that
>> and not with the web services bits.
>>
>> Here's the text I propose:
>>
>> =
>>
>> date/time/location—The Apache Software Foundation (ASF) announced
>> today the release of Apache Geronimo Version 2.0
>> (http://geronimo.apache.org). This release represents the latest open
>> source Java Enterprise Edition 5.0 application server from the Apache
>> Geronimo project, and continues the evolution of the Apache Geronimo
>> server by adding new features and capabilities to a fully compliant
>> and certified Java Enterprise Edition container suitable for
>> everything from a development environment to enterprise-level
>> deployments.
>>
>> The newly released Apache Geronimo 2.0 breaks new ground as the first
>> Open Source Application Server to provide two certified JAX-WS Web
>> Services implementations: Apache Axis2 and Apache CXF. It also
>> introduces other new features such as simplified development, improved
>> diagnostics and flexible assemblies. Simplified deployment is
>> achieved (insert rest of the text)
>>
> 
> 
> 

Re: DRAFT Press Release (final draft for review)

[Jeff Genender]

I would change the "certified Java Enterprise Edition" in the first
paragraph to "certified Java Enterprise Edition 5.0"...i.e. add the 5.0.

Jeff

Matt Hogstrom wrote:
> I think I addressed many of the concerns.  Special thanks to Amy
> Hocraffer for some great ideas to better organize and spiff up the
> announcement.
> 
> Please take a few minutes and comments and review. Also, please make
> sure our claims are accurate :)
> 
> = DRAFT =
> 
> 
> Apache Geronimo Version 2.0 released by Apache Software Foundation
> 
> 
> date/time/location—The Apache Software Foundation (ASF) announced today
> the release of Apache Geronimo Version 2.0. This release represents the
> latest open source Java Enterprise Edition 5.0 application server from
> the Apache Geronimo project, and continues the evolution of the Apache
> Geronimo server by adding new features and capabilities to a fully
> compliant and certified Java Enterprise Edition container suitable for
> everything from a development environment to enterprise-level deployments.
> 
> Apache Geronimo Version 2.0 introduces several new features like
> simplified development, improved diagnostics and flexible assemblies.
> Simplified deployment is achieved through the use of standards based
> programming model enhancements found in Java Enterprise Edition 5.0.  
> Some of the new features include:
> Streamlined development options provided with Java Enterprise Edition 5.0
> EJB 3.0 persistence
> A programming model that uses annotations to express developer defaults
> in the source code
> 
> Improved diagnostic capabilities include enhanced logging, class loader
> viewer as well as JMX browser all available from the included console. 
> Change logging levels on the fly as well as view existing logs with a
> set of filters.  Looking for a class and wondering where it came from? 
> The class loader viewer let’s you find them.  Want to see or change the
> attributes for MBeans in the server?  The JMX browser allows you to
> navigate the MBeans in the server in a simple tree format without having
> to hook up external consoles or third party products.
> 
> Flexible assemblies are realized through the project’s continued
> promotion of the ”Little G” Version 2.0—a lightweight container offering
> for projects that don’t need the full feature set of Java Enterprise
> Edition 5.0.  Perfect for web-service and SOA deployments, "Little G"
> brings the modularity, manageability and extensibility of Apache
> Geronimo to a lightweight assembly that is small in footprint but full
> of capability.
> 
> This flexible, user-friendly, and easy-to-configure application server
> is built from best-of-breed open source components and is fully licensed
> under the Apache Software License, offering multiple benefits to
> organizations and their development teams. They can use Apache Geronimo
> as-is or, if they so choose, create their own custom offerings without
> the restrictions imposed by other Open Source licenses. 
> 
> Finally, Apache Geronimo 2.0 is breaks new ground with as the first Open
> Source Application Server to provide its users with two certified Web
> Services implementations.  Users can choose between Apache Axis and
> Apache CXF for their JAX-WS Web Services provider.  Flexibility and
> choice, you have both with Apache Geronimo.
> 
> The software can be downloaded for free from the Apache Geronimo web
> site ( http://geronimo.apache.org/).
> 
> 
> About the Apache Software Foundation
> 
> The Apache Software Foundation provides organizational, legal and
> financial support for a broad range of open source software projects.
> The Foundation provides an established framework for intellectual
> property and financial contributions, while simultaneously limiting
> contributors' potential legal exposure. Through a collaborative and
> meritocratic development process, Apache projects deliver
> enterprise-grade, freely available software products that attract large
> communities of users. The pragmatic Apache License makes it easy for all
> users--commercial and individual--to deploy Apache products. For more
> information on The Apache Software Foundation, please visit
> http://www.apache.org/.
> 
> 
> Java, J2EE and Java Enterprise Edition are trademarks or registered
> trademarks of Sun Microsystems, Inc. in the United States and other
> countries. All other trademarks or registered trademarks herein are
> property of their respective owners.
> 
> = DRAFT =
> 
> 

Re: Tomcat connectors

[Jeff Genender]

David Jencks wrote:
> Well, I expect we actually want to ship with the NIO connectors used by
> default anyway, like we do for jetty.
> 

+1...excellent idea.

Jeff

Re: Tomcat connectors

[Jeff Genender]

Yeah...I would like to see us fix this at some point.  I think if we
delete a GBean, it should rebuild the car that it references or
something along those lines.  A deletion is a deletion and I think a
load="false" is not really a deletion.

Jeff

Paul McMahan wrote:
> On Aug 9, 2007, at 4:56 PM, threepointsomething wrote:
> 
>> I had removed the entire element > name="TomcatWebConnector">... from config.xml. That
>> is when
>> it was showing 2 8080 connectors.
>>
>> If I use load="false" it seems fine and only 1 8080 connector is shown.
> 
> I think you are seeing this because when you remove that section of XML
> from config.xml you are not actually removing the connector, just the
> configuration overrides for it.  The connector is actually defined in
> tomcat's deployment plan.   Setting load="false" in config.xml prevents
> the connector (which was defined elsewhere) from starting.
> 
> 
> Best wishes,
> Paul

Re: Tomcat connectors

[Jeff Genender]

You should not have 2 8080 connectors.  Did you do a load="false" for
the TomcatWebConnector?

Jeff

threepointsomething wrote:
> Great!
> 
> I followed your suggestions and am now able to configure the connector via
> config.xml. Here are the steps:
> 
> 1. Ensure the server is not running.
> 2. Disable the BIO connector by making the following change in
> var\config\config.xml:
> 
> Remove the element  or change it to
> 
> 
> 3. Add the NIO connector by adding the following to var\config\config.xml:
> 
>    gbeanInfo="org.apache.geronimo.tomcat.connector.Http11NIOConnectorGBean"
> name="org.apache.geronimo.configs/tomcat6/2.0.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatNIOConnector">
> ${HTTPPortPrimary +
> PortOffset}
> ${HTTPSPortPrimary +
> PortOffset}
> 150
>  name="connectionTimeout">6
>  name="name">TomcatNIOConnector
> ${ServerHostname}
> 
> 
>
> org.apache.geronimo.configs
> tomcat6
> 2.0.1-SNAPSHOT
> car
> TomcatWebContainer
> 
> 
> 
> 
>
> org.apache.geronimo.configs
> j2ee-system
> 2.0.1-SNAPSHOT
> car
> ServerInfo
> 
> 
> 
> 
> 4. Start Geronimo. You should see the following:
> 
>   Listening on Ports:
> 1050 127.0.0.1 CORBA Naming Service
> 1099 0.0.0.0   RMI Naming
> 1527 0.0.0.0   Derby Connector
> 2001 127.0.0.1 OpenEJB ORB Adapter
> 4201 0.0.0.0   OpenEJB Daemon
> 6882 127.0.0.1 OpenEJB ORB Adapter
> 8009 0.0.0.0   Tomcat Connector AJP AJP
> 8080 0.0.0.0   Tomcat Connector HTTP NIO TomcatNIOConnector
> 8080 0.0.0.0   Tomcat Connector HTTP BIO HTTP
> 8443 0.0.0.0   Tomcat Connector HTTPS BIO HTTPS
>  0.0.0.0   JMX Remoting Connector
>61613 0.0.0.0   ActiveMQ Transport Connector
>61616 0.0.0.0   ActiveMQ Transport Connector
> 
> (It seems to show 8080 with a BIO connector as well. Is this a bug?)
> 
> Gautham.
> 
> 
> djencks wrote:
>>
>> On Aug 9, 2007, at 11:18 AM, threepointsomething wrote:
>>
>>> I am quite new to Geronimo, so I am not sure if the steps I  
>>> followed are
>>> right. Here goes:
>>>
>>> I had to ensure that the NIO connector is picked up in place of the  
>>> basic
>>> HTTP connector, so I made the following change in
>>> configs\tomcat6\src\plan\plan.xml:
>>>
>>> >> class="org.apache.geronimo.tomcat.connector.Http11NIOConnectorGBean"&g 
>>> t;
>>>
>>> I then rebuilt config\tomcat6\. When I started Geronimo, it picked  
>>> up the
>>> NIO connector as expected.
>>>
>>>   Listening on Ports:
>>> 1050 127.0.0.1 CORBA Naming Service
>>> 1099 0.0.0.0   RMI Naming
>>> 1527 0.0.0.0   Derby Connector
>>> 2001 127.0.0.1 OpenEJB ORB Adapter
>>> 4201 0.0.0.0   OpenEJB Daemon
>>> 6882 127.0.0.1 OpenEJB ORB Adapter
>>> 8009 0.0.0.0   Tomcat Connector AJP AJP
>>> 8080 0.0.0.0   Tomcat Connector HTTP NIO HTTP
>>> 8443 0.0.0.0   Tomcat Connector HTTPS BIO HTTPS
>>>  0.0.0.0   JMX Remoting Connector
>>>61613 0.0.0.0   ActiveMQ Transport Connector
>>>61616 0.0.0.0   ActiveMQ Transport Connector
>>>
>>> I then ran a sample comet application (WAR) that was executing  
>>> properly in
>>> Tomcat and tried it in this instance of Geronimo. Seemed to work fine.
>>>
>>> I was wondering if there is a simpler way of configuring NIO  
>>> without having
>>> to rebuild config\tomcat6. If so can you please suggest how I can  
>>> do that?
>> Well, I expect we actually want to ship with the NIO connectors used  
>> by default anyway, like we do for jetty.
>>
>> However until we get there you can either turn off the BIO connector  
>> and add a NIO connector in var/config/config.xml or turn off the BIO  
>> connector in config.xml and add the appropriate connector to the  
>> geronimo plan for your app.  You can add the NIO connector using the  
>> admin console, but I think you need to turn off the BIO connector by  
>> editing config.xml when geronimo is not running.  add the attribute  
>> load="false" to the gb

Re: [VOTE] Geronimo 2.0 (RC1) and txmanager 2.0.1

[Jeff Genender]

+1


On Aug 8, 2007, at 12:38 PM, David Jencks <[EMAIL PROTECTED]>  
wrote:



+1 provided we don't run into any last minute tck problems

thanks
david jencks

On Aug 8, 2007, at 3:56 AM, Matt Hogstrom wrote:

I have put together the release and its been a long journey to get  
here.


If you have comments please put them on the corresponding [DISCUSS]  
thread.


[ ] +1 Release Geronimo 2.0
[ ] 0   No opinion
[ ] -1  Do not release Geronimo 2.0

Vote will conclude on 0700 ET on Saturday August 11th.

Binaries and source artifacts are at 
http://people.apache.org/~hogstrom/geronimo-2.0-rc1


Files are being uploaded as of the time of this writing.

Re: DRAFT Press Release

[Jeff Genender]

Jarek Gawor wrote:
> Maybe we also want to mention JAX-WS and especially that Geronimo
> supports two JAX-WS engines (since AFAIK that's pretty unqiue to
> Geronimo at this point).

Well...and JBoss 5 who support 3 JAX-WS engines...

> 
> Jarek
> 
> On 8/7/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
>> Please include your updates and comments on this press release.
>> After Thursday I'll forward to the PRC for their review with our
>> comments.  I'm cross-posting here to give the PRC a heads up.
>>
>>  DRAFT 
>>
>> Apache Software Foundation Announces Release Of Apache Geronimo
>> Version 2.0
>>
>>
>> date/time/pre-amble   -- The Apache Software Foundation is pleased to
>> announce the release of Apache Geronimo Version 2.0, an open source
>> Java Enterprise Edition 5.0 application server from the Apache
>> Geronimo project. This release continues the evolution of the Apache
>> Geronimo server, adding new features and capabilities to a fully
>> compliant Java Enterprise Edition container suitable for everything
>> from development to enterprise deployments.
>>
>>
>> Along with many new features, Apache Geronimo Version 2.0 introduces
>> several options for clustering and simplified deployment.  Developers
>> can quickly take advantage of the streamlined development options
>> provided with Java Enterprise Edition 5.0.  These include EJB 3.0
>> persistence as well as new programming model changes that use
>> annotations to express developer defaults right in the source code.
>> The configuration and management console has also been upgraded with
>> several usability improvements such as a JNDI viewer and JMX browser.
>>
>>
>> The project continues to make available its assembly called "Little
>> G" Version 2.0, a lightweight application server for applications
>> that don't need the full feature set of Java Enterprise Edition 5.0.
>> Perfect for web-service and SOA deployments, "Little G" brings the
>> modularity, manageability and extensibility of Apache Geronimo to a
>> lightweight, non-Java Enterprise Edition footprint.
>>
>>
>> This flexible, easy-to-use, and easy-to-configure application server
>> is built from best-of-breed open source components and is fully
>> licensed under the Apache Software License, offering multiple
>> benefits to organizations and their development teams. The software
>> is available now for free download from the Apache Geronimo web site
>> (http://geronimo.apache.org/).
>>
>>
>> About The Apache Software Foundation
>>
>> The Apache Software Foundation provides organizational, legal and
>> financial support for a broad range of open source software projects.
>> The Foundation provides an established framework for intellectual
>> property and financial contributions that simultaneously limits
>> contributors' potential legal exposure. Through a collaborative and
>> meritocratic development process, Apache projects deliver enterprise-
>> grade, freely available software products that attract large
>> communities of users. The pragmatic Apache License makes it easy for
>> all users, commercial and individual, to deploy Apache products. For
>> more information on The Apache Software Foundation, please visit
>> http://www.apache.org/ .
>>
>>
>> Java, J2EE and Java Enterprise Edition are trademarks or registered
>> trademarks of Sun Microsystems, Inc. in the United States and other
>> countries. All other trademarks or registered trademarks herein are
>> property of their respective owners.
>>
>>  DRAFT 
>>

Re: DRAFT Press Release

[Jeff Genender]

You might want to mention its "Certified Java Enterprise Edition 5.0".

Jeff

Matt Hogstrom wrote:
> Please include your updates and comments on this press release.  After
> Thursday I'll forward to the PRC for their review with our comments. 
> I'm cross-posting here to give the PRC a heads up.
> 
>  DRAFT 
> 
> Apache Software Foundation Announces Release Of Apache Geronimo Version 2.0
> 
> 
> date/time/pre-amble   -- The Apache Software Foundation is pleased to
> announce the release of Apache Geronimo Version 2.0, an open source Java
> Enterprise Edition 5.0 application server from the Apache Geronimo
> project. This release continues the evolution of the Apache Geronimo
> server, adding new features and capabilities to a fully compliant Java
> Enterprise Edition container suitable for everything from development to
> enterprise deployments.
> 
> 
> Along with many new features, Apache Geronimo Version 2.0 introduces
> several options for clustering and simplified deployment.  Developers
> can quickly take advantage of the streamlined development options
> provided with Java Enterprise Edition 5.0.  These include EJB 3.0
> persistence as well as new programming model changes that use
> annotations to express developer defaults right in the source code.  The
> configuration and management console has also been upgraded with several
> usability improvements such as a JNDI viewer and JMX browser.
> 
> 
> The project continues to make available its assembly called "Little G"
> Version 2.0, a lightweight application server for applications that
> don't need the full feature set of Java Enterprise Edition 5.0. Perfect
> for web-service and SOA deployments, "Little G" brings the modularity,
> manageability and extensibility of Apache Geronimo to a lightweight,
> non-Java Enterprise Edition footprint.
> 
> 
> This flexible, easy-to-use, and easy-to-configure application server is
> built from best-of-breed open source components and is fully licensed
> under the Apache Software License, offering multiple benefits to
> organizations and their development teams. The software is available now
> for free download from the Apache Geronimo web site
> (http://geronimo.apache.org/).
> 
> 
> About The Apache Software Foundation
> 
> The Apache Software Foundation provides organizational, legal and
> financial support for a broad range of open source software projects.
> The Foundation provides an established framework for intellectual
> property and financial contributions that simultaneously limits
> contributors' potential legal exposure. Through a collaborative and
> meritocratic development process, Apache projects deliver
> enterprise-grade, freely available software products that attract large
> communities of users. The pragmatic Apache License makes it easy for all
> users, commercial and individual, to deploy Apache products. For more
> information on The Apache Software Foundation, please visit
> http://www.apache.org/ .
> 
> 
> Java, J2EE and Java Enterprise Edition are trademarks or registered
> trademarks of Sun Microsystems, Inc. in the United States and other
> countries. All other trademarks or registered trademarks herein are
> property of their respective owners.
> 
>  DRAFT 

Re: Changes to server started messages

[Jeff Genender]

Donald Woods wrote:
> So, if we are using virtual hosts, we'll have no way of knowing which
> host(s) an app maps to?  If we have /welcome installed on multiple
> virtual hosts, will we now see it listed multiple times as just /welcome ?

Nope.  The web app is deployed as just that...a web app.  The web app
has a single context...and that is what is reported.  The URL is not
fair because Tomcat can have valves that can turn on/off IP
addresses/ports/etc.

If we want to get into introspection of which connectors its listening
on, which schemes, which ports, which virtual hosts, etc, I highly
recommend we start talking about MBean exposure and JMX to do this
properly and effectively.

Jeff


> 
> 
> -Donald
> 
> Jeff Genender wrote:
>> Yup...
>>
>> The old messages made no sense at all...because Web application !=
>> connector and therefore its not fair to determine that the web
>> applications actually listen on http.  In long discussions with David
>> Jencks, we agreed the slapping of http in from of the URL was purely a
>> hack and was not correct for complex cases...i.e. the applications you
>> listed also are running on https *and* ajp.  In otherwords, the web
>> application is independent of the scheme (http) and it shouldn't know
>> its own scheme.
>>
>> It *is* correct for the web application to know it's identified by the
>> context, and thats why you see them listed.
>>
>> I hope this made sense.
>>
>> Jeff
>>
>>
>> Kevan Miller wrote:
>>> I noticed that the server started messages have changed. The started Web
>>> Applications are now of the following form:
>>>
>>>   Web Applications:
>>> /
>>> /console
>>> /console-standard
>>> /dojo
>>> /remote-deploy
>>>
>>> Geronimo Application Server started
>>>
>>> Where they used to be:
>>>
>>>   Web Applications:
>>> http://coltrane:8080/
>>> http://coltrane:8080/console
>>> http://coltrane:8080/console-standard
>>> http://coltrane:8080/dojo
>>> http://coltrane:8080/remote-deploy
>>>
>>> Geronimo Application Server started
>>>
>>> I'm assuming that this is associated with the recent Connector
>>> changes... I preferred the old messages, but I doubt I'll lose very much
>>> sleep... Apologies if I missed discussion about this. Even more
>>> apologies if the network config on my machine has gone bonkers... ;-)
>>>
>>> --kevan
>>
>>

Re: [VOTE] Release TxManager 2.0

[Jeff Genender]

+1

Matt Hogstrom wrote:
> All,
> 
> 
> Please take a peek at the jar files for the txManagr components that
> David Jencks had busted out earlier.  A tar ball can be found at
> http://people.apache.org/~hogstrom/txmanager-2.0-rc1/
> 
> [ ] +1 Release these binaries
> [ ] 0  No opinion
> [ ] -1  Do not release these binaries (please provide reason.
> 
> Vote will conclude on Sunday August 5th at  1300 Eastern.

Re: Changes to server started messages

[Jeff Genender]

Yup...

The old messages made no sense at all...because Web application !=
connector and therefore its not fair to determine that the web
applications actually listen on http.  In long discussions with David
Jencks, we agreed the slapping of http in from of the URL was purely a
hack and was not correct for complex cases...i.e. the applications you
listed also are running on https *and* ajp.  In otherwords, the web
application is independent of the scheme (http) and it shouldn't know
its own scheme.

It *is* correct for the web application to know it's identified by the
context, and thats why you see them listed.

I hope this made sense.

Jeff


Kevan Miller wrote:
> I noticed that the server started messages have changed. The started Web
> Applications are now of the following form:
> 
>   Web Applications:
> /
> /console
> /console-standard
> /dojo
> /remote-deploy
> 
> Geronimo Application Server started
> 
> Where they used to be:
> 
>   Web Applications:
> http://coltrane:8080/
> http://coltrane:8080/console
> http://coltrane:8080/console-standard
> http://coltrane:8080/dojo
> http://coltrane:8080/remote-deploy
> 
> Geronimo Application Server started
> 
> I'm assuming that this is associated with the recent Connector
> changes... I preferred the old messages, but I doubt I'll lose very much
> sleep... Apologies if I missed discussion about this. Even more
> apologies if the network config on my machine has gone bonkers... ;-)
> 
> --kevan

Re: Tomcat connectors

[Jeff Genender]

Ok..I added APR connectors...

Jeff


Filip Hanik - Dev Lists wrote:
> Jeff Genender wrote:
>> Ok I added a whole bunch of new connectors in the o.a.g.t.connectors
>> package.
>>
>> I am still working on APR - more notes to follow on this as its a little
>> squirly since the Tomcat Connector somewhat "chooses" this automatically
>> based on the existence of a native libraries.  For the console we may
>> wish to do a check on whether the native libs exist, and if so, present
>> the APR connector.  More on this in another email.
>>   
> not really, it works the same as the NIO connector selection, in
> server.xml if
> protocol="HTTP/1.1" and the java.library.path contains the TC native
> library (tcnative.dll or libtcnative.so)
> then APR is selected.
> however, the protocol attribute also takes a complete class name, like
> 
> protocol="org.apache.coyote.http11.Http11Protocol" <-- java blocking
> connector
> protocol="org.apache.coyote.http11.Http11NioProtocol" <-- java non
> blocking connector
> protocol="org.apache.coyote.http11.Http11AprProtocol" <-- APR connector
> 
> so there is no need to dabble with the auto select, personally I don't
> think its very usable feature, since the APR SSL connector has different
> attributes than the Java SSL connector and the auto select wouldn't work
> in that scenario anyway.
> 
> Filip
> 
>> Here are the connectors we care about at the moment...
>>
>> AJP13ConnectorGBean - Implements AJP
>> Http11ConnectorGBean - Implements blocking Http connector
>> Https11ConnectorGBean  - Implements blocking Https connector
>> Http11NIOConnectorGBean - Implements non-blocking Http connector
>> Https11NIOConnectorGBean - Implements non-blocking Https connector
>>
>> I have not wired them into the container and other GBeans yet...I want
>> to clena them up and get any feedback before making the switch since
>> this obviously will impact the console upon wiring them in.
>>
>> As a side note...I am not using any references to the WebManager or
>> other interfaces we used that hooked into the console.  We can re-add
>> those if those are deemed necessary.
>>
>> Jeff
>>
>> Paul McMahan wrote:
>>  
>>> I agree NIO support would be great to have in 2.0, especially since its
>>> required for comet.
>>>
>>> Best wishes,
>>> Paul
>>>
>>> On Jul 23, 2007, at 2:42 PM, Jeff Genender wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> I was going through some JIRAs and the Geronimo2.0 source and
>>>> noticed it
>>>> will be difficult at best to get the NIO connector and setting
>>>> attributes on the APR connector for Tomcat due to its current
>>>> implementation.  I really think the ability to use these 2
>>>> connectors is
>>>> very important for the 2.0 release and I would like to put these
>>>> in.  If
>>>> there are no objections, I would like this to be a part of the 2.0
>>>> release.
>>>>
>>>> Jeff
>>>>   
>>
>>
>>   

Re: Tomcat connectors

[Jeff Genender]

Filip Hanik - Dev Lists wrote:

> so there is no need to dabble with the auto select, personally I don't
> think its very usable feature, since the APR SSL connector has different
> attributes than the Java SSL connector and the auto select wouldn't work
> in that scenario anyway.

Great to hear...Ill add that connector in then ;-)


Jeff

Re: Change in WebModule interface

[Jeff Genender]

My +1 on this...this made things *much* easier and in more complex
configurations, its much more accurate.

Jeff

David Jencks wrote:
> I've been talking with jgenender on IRC a bit about the former getURLFor
> method in web modules.  This used to be used in the console to provide a
> link to deployed web apps and in the startup to display where web apps
> are and I think in cl deployer to show where you app ended up.  Also for
> remote deploy upload servlet.
> 
> We decided that this really makes no sense in any but the simplest
> configurations and in more complicated situations (2 connectors) its apt
> to be wrong and misleading.  So I took out the method.
> 
> The console links to apps still work if everything is running on the
> same connector.  The startup shows you the context path, and I think the
> cl deployer will also.  This isn't much less convenient.
> 
> You now configure where the remote deploy upload servlet is with a
> Deployer attribute remoteDeployAddress.  By default it's localhost:8080
> which provides the additional security of not allowing remote deploy
> unless you change it.
> 
> Any comments?  Getting the method back will require you to implement it
> sensibly for all the tomcat connectors, something neither jeff nor I
> know how to do :-)
> 
> thanks
> david jencks

[jira] Assigned: (GERONIMO-3334) Need a way to select the Tomcat NIO connector in order to enable comet support

[Jeff Genender (JIRA)]

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

Jeff Genender reassigned GERONIMO-3334:
---

Assignee: Jeff Genender

> Need a way to select the Tomcat NIO connector in order to enable comet support
> --
>
> Key: GERONIMO-3334
> URL: https://issues.apache.org/jira/browse/GERONIMO-3334
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0-M5
> Environment: Windows XP, geronimo-tomcat6-jee5-2.0-M5
>Reporter: Gautham Pai
>Assignee: Jeff Genender
>
> Tomcat provides a way to configure either a simple HTTP connector or an APR 
> or NIO connector by providing the appropriate value for the protocol 
> attribute in TOMCAT_HOME/conf/server.xml.
> The following connectors can be configured:
> org.apache.coyote.http11.Http11Protocol
> org.apache.coyote.http11.Http11NioProtocol
> org.apache.coyote.http11.Http11AprProtocol
> However this provision is not available in Geronimo. This makes it difficult 
> to select either the NIO or the APR connector, without which the comet 
> implementation of Tomcat cannot be enabled.
> We should be able to configure this protocol via 
> GERONIMO_HOME/var/config/config.xml. Also the NIO connector attributes should 
> be configurable.
> For more information on the HTTP connector settings please refer to the 
> Tomcat documentation here:
> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html

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

Re: Tomcat connectors

[Jeff Genender]

Ok I added a whole bunch of new connectors in the o.a.g.t.connectors
package.

I am still working on APR - more notes to follow on this as its a little
squirly since the Tomcat Connector somewhat "chooses" this automatically
based on the existence of a native libraries.  For the console we may
wish to do a check on whether the native libs exist, and if so, present
the APR connector.  More on this in another email.

Here are the connectors we care about at the moment...

AJP13ConnectorGBean - Implements AJP
Http11ConnectorGBean - Implements blocking Http connector
Https11ConnectorGBean  - Implements blocking Https connector
Http11NIOConnectorGBean - Implements non-blocking Http connector
Https11NIOConnectorGBean - Implements non-blocking Https connector

I have not wired them into the container and other GBeans yet...I want
to clena them up and get any feedback before making the switch since
this obviously will impact the console upon wiring them in.

As a side note...I am not using any references to the WebManager or
other interfaces we used that hooked into the console.  We can re-add
those if those are deemed necessary.

Jeff

Paul McMahan wrote:
> I agree NIO support would be great to have in 2.0, especially since its
> required for comet.
> 
> Best wishes,
> Paul
> 
> On Jul 23, 2007, at 2:42 PM, Jeff Genender wrote:
> 
>> Hi,
>>
>> I was going through some JIRAs and the Geronimo2.0 source and noticed it
>> will be difficult at best to get the NIO connector and setting
>> attributes on the APR connector for Tomcat due to its current
>> implementation.  I really think the ability to use these 2 connectors is
>> very important for the 2.0 release and I would like to put these in.  If
>> there are no objections, I would like this to be a part of the 2.0
>> release.
>>
>> Jeff

Tomcat connectors

[Jeff Genender]

Hi,

I was going through some JIRAs and the Geronimo2.0 source and noticed it
will be difficult at best to get the NIO connector and setting
attributes on the APR connector for Tomcat due to its current
implementation.  I really think the ability to use these 2 connectors is
very important for the 2.0 release and I would like to put these in.  If
there are no objections, I would like this to be a part of the 2.0 release.

Jeff

[jira] Commented: (GERONIMO-3334) Need a way to select the Tomcat NIO connector in order to enable comet support

[Jeff Genender (JIRA)]

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

Jeff Genender commented on GERONIMO-3334:
-

Yeah I see the issue.  I can make a few changes and enable this.

> Need a way to select the Tomcat NIO connector in order to enable comet support
> --
>
> Key: GERONIMO-3334
> URL: https://issues.apache.org/jira/browse/GERONIMO-3334
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0-M5
> Environment: Windows XP, geronimo-tomcat6-jee5-2.0-M5
>Reporter: Gautham Pai
>
> Tomcat provides a way to configure either a simple HTTP connector or an APR 
> or NIO connector by providing the appropriate value for the protocol 
> attribute in TOMCAT_HOME/conf/server.xml.
> The following connectors can be configured:
> org.apache.coyote.http11.Http11Protocol
> org.apache.coyote.http11.Http11NioProtocol
> org.apache.coyote.http11.Http11AprProtocol
> However this provision is not available in Geronimo. This makes it difficult 
> to select either the NIO or the APR connector, without which the comet 
> implementation of Tomcat cannot be enabled.
> We should be able to configure this protocol via 
> GERONIMO_HOME/var/config/config.xml. Also the NIO connector attributes should 
> be configurable.
> For more information on the HTTP connector settings please refer to the 
> Tomcat documentation here:
> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html

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

[jira] Commented: (GERONIMO-3334) Need a way to select the Tomcat NIO connector in order to enable comet support

[Jeff Genender (JIRA)]

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

Jeff Genender commented on GERONIMO-3334:
-

These connectors can be added via the config.xml...can you please expand on 
what you are not able to do?

> Need a way to select the Tomcat NIO connector in order to enable comet support
> --
>
> Key: GERONIMO-3334
> URL: https://issues.apache.org/jira/browse/GERONIMO-3334
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0-M5
> Environment: Windows XP, geronimo-tomcat6-jee5-2.0-M5
>Reporter: Gautham Pai
>
> Tomcat provides a way to configure either a simple HTTP connector or an APR 
> or NIO connector by providing the appropriate value for the protocol 
> attribute in TOMCAT_HOME/conf/server.xml.
> The following connectors can be configured:
> org.apache.coyote.http11.Http11Protocol
> org.apache.coyote.http11.Http11NioProtocol
> org.apache.coyote.http11.Http11AprProtocol
> However this provision is not available in Geronimo. This makes it difficult 
> to select either the NIO or the APR connector, without which the comet 
> implementation of Tomcat cannot be enabled.
> We should be able to configure this protocol via 
> GERONIMO_HOME/var/config/config.xml. Also the NIO connector attributes should 
> be configurable.
> For more information on the HTTP connector settings please refer to the 
> Tomcat documentation here:
> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html

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

[Jeff Genender]

Lets let Jason chime in here as I think he volunteered to stitch a lot
of this together.

Jeff

Donald Woods wrote:
> Could we use Jakarta commons-launcher, which uses a subset of ANT?
> We'd probably have to make a few changes, so it would use the existing
> manifest settings in the server/client.jar and to handle our multiple
> server instance directory structure.
> 
> 
> -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: Ideas on a rc.d kind of directory

[Jeff Genender]

Jason Dillon wrote:
> How does the script know to pick it up.  Got a cli example of how the
> invoke would look?

Pseudo code for geronimo.sh:

scripts = read(bin/scripts);
for each script in scripts do
   call script
endfor

Jeff

> 
> --jason
> 
> 
> On Jul 16, 2007, at 9:45 PM, Jeff Genender wrote:
> 
>> Use case needed now:
>>
>> Terracotta is developing a plugin.  It needs to pass a setting to the
>> JVM (i.e. -xbootclasspath=).  So when the Geronimo script is run, it
>> needs to pick up this "setting" from a script that is installed by the
>> plugin.  The script would normally set a JAVA_OPTS and the geronimo.sh
>> script would then pick this up.
>>
>> These scripts would be installed by plugins (or created by someone), but
>> the great part is, when the plugin is uninstalled, the script goes away,
>> and the options are not set.
>>
>> Did this make sense?
>>
>> Jeff
>>
>>
>>
>> Jason Dillon wrote:
>>> Can you provide a wee bit detail on hat the use cases are you have in
>>> mind?  I'm still a bit fuzzy what you are going for.
>>>
>>> --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
>>>>>>>>
>>>>>>>>