date:20060118


This state is transactional, I take it?

On Wed, 18 Jan 2006 [EMAIL PROTECTED] wrote:

>
> On 18 Jan 2006, at 18:10, lichtner wrote:
> > It looks like a map-like interface. When you say this could manage
> > state
> > for OpenEJB, what kind of state do you have in mind?
>
> For a given client in EJB / JBI / Lingo / SCA there tends to be
> chunks of state for each client.  e.g. in EJB a single EJB client can
> create N stateful session beans each of which can be updated
> independently; but the entire state might be managed as a whole. So
> each chunk of state inside the Session represents the state of a
> single session bean for a given EJB client.
>
> James
> ---
> http://radio.weblogs.com/0112098/
>
>

Re: JACC plugability etc

2006-01-18 Thread Jian Liao

Some questions, pls see below.On 1/19/06, David Jencks <[EMAIL PROTECTED]> wrote:
First of all, someone pointed me recently to https://openjacc.projects.dev2dev.bea.com/ which looks like it shares somegoals with us.  I can't tell how its license affects our ability to
use it, and would appreciate some informed opinions.I would like our JACC implementation to be plugable and extensible topermissions not specifically mentioned in the jacc spec such as thejetspeed 2 portal permissions.  I've been thinking on and off about
this and it might even be possible.  Here are some aspects to thisproblem:- spec defined permissions, from the spec deployment descriptors.This can probably be used for any jacc implementation, so should
remain in "core geronimo".- Putting the permissions from the spec into the jaccPolicyConfiguration.  We use theApplicationPolicyConfigurationManager gbean for this now, but thatincludes also code specific to our geronimo jacc implementation.
Perhaps this can be split into 2 gbeans or a base gbean with the spec-required behavior can be written.1. User can write an J2PortalPolicyConfigurationManager to config  J2 specific perssioms. Do I have to extend from the base one?
2. J2PortalPolicyConfigurationManager just add J2 specific permissions to the corresponding policyConfiguration instance?3. Will J2PortalPolicyConfigurationManager be used to support dynamic policyConfiguration update? like remove, add or change a permission in runtime?
- Our plans include xml for a role >> principal mapping which isspecific to our jacc implementation.  This info is added to the
ApplicationPolicyConfigurationManager as well.  The use of our schemais hardcoded in our j2ee plans, but this could be turned into anamespace-driven choice of security builders.So, what I'm thinking of is something like:
- define a SecurityBuilder interface primarily for the non-spec partsof the security setup.  The various j2ee builders can call into it atappropriate times.- selection of a SecurityBuilder relates to configuration of the
server, since it reflects the Policy installed.  I don't see how tohave several JACC implementations running at once.  EachSecurityBuilder would presumably have its own namespace. Perhaps wecan select the SecurityBuilder based on namespace, but this would
push the discovery of incompatibility in JACC implementation toruntime.  This might or might not be acceptable or the best idea, I'mnot sure.- the SecurityBuilder would be responsible for adding the
ApplicationPolicyConfigurationManager-like gbean to thedeploymentContext and building up its configuration.- as now, when the app starts, theApplicationPolicyConfigurationManager gbean will configure the JACC
PolicyConfiguration appropriately for its jacc implementation.Presumably it will need to object if it finds the wrong jaccimplementation installed.Comments? Objections? Questions?thanksdavid jencks

Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany

2006-01-18 Thread jastrachan



On 18 Jan 2006, at 18:10, lichtner wrote:
It looks like a map-like interface. When you say this could manage  
state

for OpenEJB, what kind of state do you have in mind?


For a given client in EJB / JBI / Lingo / SCA there tends to be  
chunks of state for each client.  e.g. in EJB a single EJB client can  
create N stateful session beans each of which can be updated  
independently; but the entire state might be managed as a whole. So  
each chunk of state inside the Session represents the state of a  
single session bean for a given EJB client.


James
---
http://radio.weblogs.com/0112098/

Re: CORBA incubation proposal


That would be great.


Regards,
Alan

Matt Hogstrom wrote, On 1/18/2006 6:29 PM:
Are there any people on the Harmony project that might (are) interested 
in an ORB?  Seems like prime territory for them.


Otherwise it looks good.

Alan D. Cabrera wrote:


Here is the incubation proposal

http://wiki.apache.org/incubator/CorbaProposal

Does anyone have any comments before we vote on it?

Should this also get sent to the incubator list or do we wait until 
after the vote?


Alex Karasulu and I were talking about it and we both think that it 
might be a good idea to shoot for making this a TLP.  Thoughts?




Regards,
Alan

Re: CORBA incubation proposal


That would be great.


Regards,
Alan

Matt Hogstrom wrote, On 1/18/2006 6:29 PM:
Are there any people on the Harmony project that might (are) interested 
in an ORB?  Seems like prime territory for them.


Otherwise it looks good.

Alan D. Cabrera wrote:


Here is the incubation proposal

http://wiki.apache.org/incubator/CorbaProposal

Does anyone have any comments before we vote on it?

Should this also get sent to the incubator list or do we wait until 
after the vote?


Alex Karasulu and I were talking about it and we both think that it 
might be a good idea to shoot for making this a TLP.  Thoughts?




Regards,
Alan

Re: [VOTE} ActiveMQ 4.0 M4 Release candidate

2006-01-18 Thread Bruce Snyder

On 1/16/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> Hi Guys,
>
> I've done a release candidate build of ActiveMQ 4.0 M4 and have
> posted it here:
> http://people.apache.org/~chirino/incubator-activemq-4.0-M4/
> I've tagged the source for that build as:
> https://svn.apache.org/repos/asf/incubator/activemq/tags/
> ACTIVEMQ_4_0_M_4/activemq
>
> Lets kick it around and verify that it passes any apache release
> requirements.
>
> [ ] +1 Release the binary as our milestone 4
> [ ] -1 Veto the milestone release (provide specific comments)
>
> If this vote passes, I think we still need to get incubator PMC buy
> off and we need to put together release notes.

+1

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)

Castor (http://castor.org/)

[jira] Commented: (GERONIMO-1495) Installer build failure when using Maven 1.0.2

[ 
http://issues.apache.org/jira/browse/GERONIMO-1495?page=comments#action_12363201
 ] 

erik daughtrey commented on GERONIMO-1495:
--

The patch has been tested against trunk and branches/1.0.

It should be applied to both.


> Installer build failure when using Maven 1.0.2
> --
>
>  Key: GERONIMO-1495
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1495
>  Project: Geronimo
> Type: Bug
>   Components: installer
> Versions: 1.0
>  Environment: any
> Reporter: erik daughtrey
>  Attachments: installer-trunk-maven102-fix.patch
>
> Maven 1.0.2 embeds an older version of Jelly which doesn't understand  append="true">
> Maven 1.1 beta 2 does not have this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1495) Installer build failure when using Maven 1.0.2

[ 
http://issues.apache.org/jira/browse/GERONIMO-1495?page=comments#action_12363200
 ] 

erik daughtrey commented on GERONIMO-1495:
--

This patch should be applied to both trunk and branches/1.0.
it's been tested on both.


> Installer build failure when using Maven 1.0.2
> --
>
>  Key: GERONIMO-1495
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1495
>  Project: Geronimo
> Type: Bug
>   Components: installer
> Versions: 1.0
>  Environment: any
> Reporter: erik daughtrey
>  Attachments: installer-trunk-maven102-fix.patch
>
> Maven 1.0.2 embeds an older version of Jelly which doesn't understand  append="true">
> Maven 1.1 beta 2 does not have this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: CORBA incubation proposal

2006-01-18 Thread Matt Hogstrom

Are there any people on the Harmony project that might (are) interested in an 
ORB?  Seems like prime territory for them.


Otherwise it looks good.

Alan D. Cabrera wrote:

Here is the incubation proposal

http://wiki.apache.org/incubator/CorbaProposal

Does anyone have any comments before we vote on it?

Should this also get sent to the incubator list or do we wait until 
after the vote?


Alex Karasulu and I were talking about it and we both think that it 
might be a good idea to shoot for making this a TLP.  Thoughts?




Regards,
Alan

Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany


It looks like a map-like interface. When you say this could manage state
for OpenEJB, what kind of state do you have in mind?

On Wed, 18 Jan 2006, James Strachan wrote:

> I got chance to have a mini-hackathon with some geronimo committers
> over the weekend to hack up a real simple client API to some kind of
> state store, which could be clustered, that the OpenEJB, ServiceMix,
> Lingo and Tuscany guys could use.
>
> Rather than focussing on the possible technical implementations and
> techniques (like group communication, election strategies,
> distributed locking, totem protocol, distributed hash maps etc) we
> tried to put in place a simple client API for the person who has to
> integrate some kind of client session state into the client/server
> side of OpenEJB or ServiceMix etc .
>
> Its a very simple API and should be trivial to implement in a
> gazillion of different ways (a HashMap, totem, WADI, just a database
> or file system, a combination of database for being the controller &
> using point to point non-reliable messaging with the other members to
> group election strategies etc). Without further ado here's where it
> lives...
>
> http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/
>
> There's some javadoc that tries to explain the use cases, the design
> goals behind the client API and a variety of possible implementations
> we could do - the idea is based on your requirements and performance
> targets you may use a real simple implementation or a wacky complex
> one.  We tried to assume a possibly low QoS (e.g. 1 box with a
> HashMap) while allowing any implementation to plug in based on its
> requirements.
>
> Here's more docs in HTML which explains it much better
> http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/
> java/org/apache/geronimo/session/package.html
>
> Thoughts?
>
> To the WADI folks - do you think it'd be easy to put WADI underneath
> this API?
>
> James
> ---
> http://radio.weblogs.com/0112098/
>
>
>
>
> James
> ---
> http://radio.weblogs.com/0112098/
>
>

Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany

Ok...besides my "great stuff"...I really mean that.

I took a look at the API and its a pretty good start to make a generic
pluggable layer for state clustering management.

I like this.

Jeff

James Strachan wrote:
> I got chance to have a mini-hackathon with some geronimo committers over
> the weekend to hack up a real simple client API to some kind of state
> store, which could be clustered, that the OpenEJB, ServiceMix, Lingo and
> Tuscany guys could use.
> 
> Rather than focussing on the possible technical implementations and
> techniques (like group communication, election strategies, distributed
> locking, totem protocol, distributed hash maps etc) we tried to put in
> place a simple client API for the person who has to integrate some kind
> of client session state into the client/server side of OpenEJB or
> ServiceMix etc .
> 
> Its a very simple API and should be trivial to implement in a gazillion
> of different ways (a HashMap, totem, WADI, just a database or file
> system, a combination of database for being the controller & using point
> to point non-reliable messaging with the other members to group election
> strategies etc). Without further ado here's where it lives...
> 
> http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/
> 
> There's some javadoc that tries to explain the use cases, the design
> goals behind the client API and a variety of possible implementations we
> could do - the idea is based on your requirements and performance
> targets you may use a real simple implementation or a wacky complex
> one.  We tried to assume a possibly low QoS (e.g. 1 box with a HashMap)
> while allowing any implementation to plug in based on its requirements.
> 
> Here's more docs in HTML which explains it much better
> http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/java/org/apache/geronimo/session/package.html
> 
> 
> Thoughts?
> 
> To the WADI folks - do you think it'd be easy to put WADI underneath
> this API?
> 
> James
> ---
> http://radio.weblogs.com/0112098/
> 
> 
> 
> 
> James
> ---
> http://radio.weblogs.com/0112098/

Re: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany

Really cool stuff!

James Strachan wrote:
> I got chance to have a mini-hackathon with some geronimo committers over
> the weekend to hack up a real simple client API to some kind of state
> store, which could be clustered, that the OpenEJB, ServiceMix, Lingo and
> Tuscany guys could use.
> 
> Rather than focussing on the possible technical implementations and
> techniques (like group communication, election strategies, distributed
> locking, totem protocol, distributed hash maps etc) we tried to put in
> place a simple client API for the person who has to integrate some kind
> of client session state into the client/server side of OpenEJB or
> ServiceMix etc .
> 
> Its a very simple API and should be trivial to implement in a gazillion
> of different ways (a HashMap, totem, WADI, just a database or file
> system, a combination of database for being the controller & using point
> to point non-reliable messaging with the other members to group election
> strategies etc). Without further ado here's where it lives...
> 
> http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/
> 
> There's some javadoc that tries to explain the use cases, the design
> goals behind the client API and a variety of possible implementations we
> could do - the idea is based on your requirements and performance
> targets you may use a real simple implementation or a wacky complex
> one.  We tried to assume a possibly low QoS (e.g. 1 box with a HashMap)
> while allowing any implementation to plug in based on its requirements.
> 
> Here's more docs in HTML which explains it much better
> http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/java/org/apache/geronimo/session/package.html
> 
> 
> Thoughts?
> 
> To the WADI folks - do you think it'd be easy to put WADI underneath
> this API?
> 
> James
> ---
> http://radio.weblogs.com/0112098/
> 
> 
> 
> 
> James
> ---
> http://radio.weblogs.com/0112098/

heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany

2006-01-18 Thread James Strachan

I got chance to have a mini-hackathon with some geronimo committers  
over the weekend to hack up a real simple client API to some kind of  
state store, which could be clustered, that the OpenEJB, ServiceMix,  
Lingo and Tuscany guys could use.


Rather than focussing on the possible technical implementations and  
techniques (like group communication, election strategies,  
distributed locking, totem protocol, distributed hash maps etc) we  
tried to put in place a simple client API for the person who has to  
integrate some kind of client session state into the client/server  
side of OpenEJB or ServiceMix etc .


Its a very simple API and should be trivial to implement in a  
gazillion of different ways (a HashMap, totem, WADI, just a database  
or file system, a combination of database for being the controller &  
using point to point non-reliable messaging with the other members to  
group election strategies etc). Without further ado here's where it  
lives...


http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/

There's some javadoc that tries to explain the use cases, the design  
goals behind the client API and a variety of possible implementations  
we could do - the idea is based on your requirements and performance  
targets you may use a real simple implementation or a wacky complex  
one.  We tried to assume a possibly low QoS (e.g. 1 box with a  
HashMap) while allowing any implementation to plug in based on its  
requirements.


Here's more docs in HTML which explains it much better
http://svn.apache.org/repos/asf/geronimo/trunk/modules/session/src/ 
java/org/apache/geronimo/session/package.html


Thoughts?

To the WADI folks - do you think it'd be easy to put WADI underneath  
this API?


James
---
http://radio.weblogs.com/0112098/




James
---
http://radio.weblogs.com/0112098/

[jira] Resolved: (GERONIMO-1482) Add CORBA spec version 3.0

2006-01-18 Thread Alan Cabrera (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1482?page=all ]
 
Alan Cabrera resolved GERONIMO-1482:


Fix Version: 1.x
 Resolution: Fixed

Thanks!

> Add CORBA spec version 3.0
> --
>
>  Key: GERONIMO-1482
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1482
>  Project: Geronimo
> Type: Task
>   Components: CORBA
> Reporter: Anders Hessellund Jensen
> Assignee: Alan Cabrera
>  Fix For: 1.x
>  Attachments: geronimo-spec-corba-3.0.zip
>
> I have created a 3.0 version of the CORBA spec. It is java / IDL files from 
> OMG with some modifications. 
> Consider where to put it. I suppose the sandbox would be most appropriate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1495) Installer build failure when using Maven 1.0.2

 [ http://issues.apache.org/jira/browse/GERONIMO-1495?page=all ]

erik daughtrey updated GERONIMO-1495:
-

Attachment: installer-trunk-maven102-fix.patch

This patch fixes the build and works with both Maven 1.0.2 and 1.1 beta 2.


> Installer build failure when using Maven 1.0.2
> --
>
>  Key: GERONIMO-1495
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1495
>  Project: Geronimo
> Type: Bug
>   Components: installer
> Versions: 1.0
>  Environment: any
> Reporter: erik daughtrey
>  Attachments: installer-trunk-maven102-fix.patch
>
> Maven 1.0.2 embeds an older version of Jelly which doesn't understand  append="true">
> Maven 1.1 beta 2 does not have this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1495) Installer build failure when using Maven 1.0.2

Installer build failure when using Maven 1.0.2
--

 Key: GERONIMO-1495
 URL: http://issues.apache.org/jira/browse/GERONIMO-1495
 Project: Geronimo
Type: Bug
  Components: installer  
Versions: 1.0
 Environment: any
Reporter: erik daughtrey


Maven 1.0.2 embeds an older version of Jelly which doesn't understand 
Maven 1.1 beta 2 does not have this problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: EJB3 plans ?

My sense is that we'll be looking at EJB3 for Geronimo 2.0, to be
delivered in the 6+ month time frame.  I think OpenEJB would be a
logical place to raise this issue -- I know David Blevins has a lot of
thoughts on what should go into OpenEJB 3.

Aaron

On 1/18/06, Bobby Abraham <[EMAIL PROTECTED]> wrote:
> I have been scanning the geronimo lists and haven't seen any discussion
> of moves toward ejb3 or jsr220 support.
>
> Has any of this development stated yet ?
> Should I be looking on openejb lists for this discussion ?
>
> I am interested to know if the plan is to extend openejb or to add
> another a persistence container like glassfish or hibernate3 for this
> support.
>
> I understand the licensing issue regarding hibernate (LGPL) but the
> glassfish license may be compatible with the apache licence, no ?
>
>
> --
> Bobby Abraham <[EMAIL PROTECTED]>
> Subtle Guru
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQBDzt/k5qQlbWjPJNsRAgaJAKCZFzJNIX0mBD6FJfFYXVZ3YSXMxgCfU3p4
> qC1odSo36PLCLXUj12thUQ4=
> =ospI
> -END PGP SIGNATURE-
>
>
>

EJB3 plans ?

2006-01-18 Thread Bobby Abraham

I have been scanning the geronimo lists and haven't seen any discussion
of moves toward ejb3 or jsr220 support.

Has any of this development stated yet ?
Should I be looking on openejb lists for this discussion ?

I am interested to know if the plan is to extend openejb or to add
another a persistence container like glassfish or hibernate3 for this
support.  

I understand the licensing issue regarding hibernate (LGPL) but the
glassfish license may be compatible with the apache licence, no ?


-- 
Bobby Abraham <[EMAIL PROTECTED]>
Subtle Guru


signature.asc
Description: This is a digitally signed message part

Re: WADI clustering

2006-01-18 Thread Rajith Attapattu

Ok, I am not fixed on multiple-active-sessions. 
But my concern is high availability with single-active-session model under high load conditions.

As u pointed out,
>In the web world, clients commonly throw multiple concurrent requests at>clusters, however, if we could assure total affinity, these would always>arrive at the same copy, avoiding the chance of a collision

However if we use 100% session affinity then the chance of one server getting too many hits is possible (due to that being the primary and the LB indiscrimantely maintaining session affinity without due consideration for load).

Thus a compromise of service quality is inevitable. The service will have to drop requests or degrade the service (provide only some of the services which are not expensive).

So sometimes the cost of maintaining multiple-active-sessions may be less compared to the exceptional cost that has to be paid with a server crash thus increasing the load within the remaining nodes of the cluster.

The cost in terms of money value of loosing revenue due to service un-availability could be higher than providing more memory, high-speed network infra which could handle the cost of serialization/desirialization of replicas and the overhead of a distributed locking mechanism without compromising performance.

Thats why I said that we should provide both stratergies and the end-user can make an informed decesion based on there business requirments and load conditions within there cluster.

We should avoid making those decesions before hand.

Also allowing the idea of configurable active replicas will allow the end-user the flexibility of trying out both multiple-active-session and single-active-session models and see what works best for them.

I would strongly advocate the idea of a Replication mgt abstraction API especially with some of the ideas Gianny provided on the thread.

What do u think about that?? Have I made a case??

Regards,

Rajith.

On 1/18/06, Jules Gosnell <[EMAIL PROTECTED]> wrote: 
Jules Gosnell wrote:> Oh Rajith - you've got me thinking :-(>> I'm not happy with the last answer - lets try again
>> lets agree some points :>> 1) since changes made to sessions are made in app-space, apps are not> written with the expectation that a change collision may occur and the> container would not be able to avoid such a collision, it must never
> happen.>> 2) in order for a change-collision to occur multiple concurrent> requests/invocations must hit multiple copies of the session>> In the web world, clients commonly throw multiple concurrent requests
> at clusters, however, if we could assure total affinity, these would> always arrive at the same copy, avoiding the chance of a collision.> There are various situations within the web tier that may cause the
> breakdown of affinity. Different loadbalancers handle these situations> with varying degrees of correctness. I have decided that it is safer> to assume that, whilst affinity is a substantial optimisation, it
> cannot be relied on 100%.>> So, in the web tier, it is possible for concurrent requests for the> same session to arrive at different session copies. So we need a> pessimistic distributed locking strategy to ensure that collisions do
> not occur.>> In the EJB world, we have more control over the load-balancer, because> it is effectively built into the proxy  that we supplied, and we could> enforce the serial nature of invocations at this point. So it might be
> possible to move forward on the assumption that we don't need> pessimistic locking (provided that no-one ever passes a session handle> to another client).>> I'm going to give this a little more thought...
>> I think the outcome will be that I can avoid some locking in the EJB> world, but need to send the same messages anyway... but we'll see.>> Thanks for getting me to revisit this,>
BTW - if we do assume that we can rely on affinity 100% in the EJB tierthen I am still not sure that I see any real advantage in holdingmultiple active copies of a session. I guess you will have to explain to
me exactly why you would want to do this.Finally, the locking system that WADI currently uses will only incurextra work, taking distributed locks, if affinity breaks down, so thecost of applying it to the SFSBs where, we hope for 100% affinity,
should be 0.Jules>> Jules Jules Gosnell wrote:>>> Rajith Attapattu wrote:> More question if you don't mind.>>>
>>> > 2.) Assuming sombody wants to do session replication (All>>> > Active) instead of (one Active and "n" backups) is there provision>>> > within the WADI api to plug in this stratergy?
>> >I'm giving this some thought in terms of SFSB support, I'm not>>> aware of>>> >similar constraints in the EJB world...>> >I guess we could relax this constraint in the web world, but I am not
>>> >sure that I think that this is a good idea. Can you see a way to do>>> this>>> >and maintain spec compliance and performance ?>>> Is WADI designed primarily fo

Re: Clustering - initial overview doc... - where should we keep it ?


Hi Rajith,
the following link is the *Notation Guide* for confluence that provides 
available formats.

http://opensource2.atlassian.com/confluence/oss/renderer/notationhelp.action?section=all

Here are just a few tips for writing documentation that I have found useful.
- read other articles published in confluence to have a feel of the structure and organization of 
other articles for consistency.

- keep it simple; don't use too many different fonts and styles.
- create a hierarchical structure first, work on titles and sections first then 
focus on the content.
- keep it simple[2], don't use "fancy" words to explain simple things.
- make sure the article has a flow and it is easy to follow.
- keep it simple[3], if the topic being addressed in complex, separate the article in multiple 
sections/pages.

- if samples are included, make sure the instructions to get it working are 
clear.

Again, these are just a few tips I try to follow myself. Comments are welcome.

HTH

Cheers!
Hernan


Rajith Attapattu wrote:

Hey Hernan,
 
If u can publish a few tips on basic formatting with confluence that 
will help.
 
Maybe an email or a doc itself within confluence will do.
 
Regards,
 
Rajith.
 
On 1/18/06, *lichtner* <[EMAIL PROTECTED] > 
wrote:



So where is this document now? I am not very familiar with the web site
there seems to be more than one place.

On Wed, 18 Jan 2006, Hernan Cunico wrote:

 > Hi Jules,
 > many of the articles (if not all) started the same way and many
of them are still a work in progress.
 >
 > It would be great if you can publish your doc there, I can give
you a hand with the confluence
 > formatting if you want to.
 >
 > Cheers!
 > Hernan
 >
 > Jules Gosnell wrote:
 > > Hernan Cunico wrote:
 > >
 > >> Hi Jules,
 > >> can you put your docs in confluence!?
 > >>
 > >> There is already a section for performance in the TOC, it would be
 > >> great if you put the clustering documentation there.
 > >
 > >
 > >
 > > OK - can do, if everyone is happy with this...
 > >
 > > It is a pretty rough doc though... the rest of the stuff in
there looks
 > > pretty polished... - this really is a work in progress... - is
that OK ?
 > >
 > > Jules
 > >
 > >>
 > >> Here is the link to the TOC, to edit confluence you will have to
 > >> register first.
 > >>
 > >>

http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692
 > >>
 > >>
 > >> Let me know if you need any help with confluence.
 > >>
 > >> Cheers!
 > >> Hernan
 > >>
 > >> Jules Gosnell wrote:
 > >>
 > >>> Guys,
 > >>>
 > >>> I have the beginnings of this doc...
 > >>>
 > >>> Where would be the best place to keep it ? Ideally it should
be r/w
 > >>> by everyone, with history - SVN, WIKI or where ? What is best
practice ?
 > >>>
 > >>> Also, if in SVN, what format - text, html, ... etc...
 > >>>
 > >>>
 > >>> Jules
 > >>>
 > >
 > >
 >

[jira] Updated: (GERONIMO-1494) Potential infinite loop in ActiveMQ shutdown processing

 [ http://issues.apache.org/jira/browse/GERONIMO-1494?page=all ]

John Sisson updated GERONIMO-1494:
--

Summary: Potential infinite loop in ActiveMQ shutdown processing  (was: 
Potential)

> Potential infinite loop in ActiveMQ shutdown processing
> ---
>
>  Key: GERONIMO-1494
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1494
>  Project: Geronimo
> Type: Bug
>   Components: ActiveMQ
> Versions: 1.0
> Reporter: Kevan Miller
> Priority: Minor
>  Fix For: 1.1

>
> The geronimo.log posted to http://issues.apache.org/jira/browse/GERONIMO-1372 
> shows evidence of infinite loop in ActiveMQ shutdown processing. 
> The log entry from the 1372 log is excerpted below: 
> 17:30:34,325 WARN [TransportChannelSupport] Caught exception dispatching 
> message and no ExceptionListener registered: javax.jms.JMSException: 
> asyncSend failed: java.io.EOFException: Cannot write to the stream any more 
> it has already been closed 
> javax.jms.JMSException: asyncSend failed: java.io.EOFException: Cannot write 
> to the stream any more it has already been closed 
> at 
> org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49)
>  
> at 
> org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:483)
>  
> at 
> org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160)
>  
> at 
> org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145)
>  
> at 
> org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) 
> at 
> org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617)
>  
> at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) 
> at 
> org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78)
>  
> at 
> org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164)
>  
> at 
> org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:176)
>  
> at 
> org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40)
>  
> at 
> org.activemq.ra.ActiveMQAsfEndpointWorker$1$1.onException(ActiveMQAsfEndpointWorker.java:83)
>  
> at 
> org.activemq.transport.TransportChannelSupport.onAsyncException(TransportChannelSupport.java:445)
>  
> at 
> org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:484)
>  
> at 
> org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160)
>  
> at 
> org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145)
>  
> at 
> org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) 
> at 
> org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617)
>  
> at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) 
> at 
> org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78)
>  
> at 
> org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164)
>  
> at 
> org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:176)
>  
> at 
> org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40)
>  
> at 
> org.activemq.ra.ActiveMQAsfEndpointWorker$1$1.onException(ActiveMQAsfEndpointWorker.java:83)
>  
> at 
> org.activemq.transport.TransportChannelSupport.onAsyncException(TransportChannelSupport.java:445)
>  
> at 
> org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:484)
>  
> at 
> org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160)
>  
> at 
> org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145)
>  
> at 
> org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) 
> at 
> org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617)
>  
> at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) 
> ... (you get the picture) 
> at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) 
> at 
> org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78)
>  
> at 
> org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164)
>  
> at 
> org.activemq.ra.ActiveMQAsfEndpointWorker.stop(ActiveMQAsfEndpointWorker.java:139)
>  
> at 
> org.activemq.ra.ActiveMQResourceAdapter.endpointDeactivation(ActiveMQResourceAdapter.java:261)
>  
> at 
> org.apache.geronimo.connector.ResourceAdapterWrapper.endpointDeactivation(ResourceAdapterWrapper.java:92)
>  
> at 
> org.apache.geronimo.connector.ResourceAdapterWrapper$$FastClassByCGLIB$$4ab28e73.invoke()
>  
> at net.sf.cgli

Re: CORBA incubation proposal

2006-01-18 Thread John Sisson


Dain Sundstrom wrote:

On Jan 18, 2006, at 2:39 PM, Alan D. Cabrera wrote:


Here is the incubation proposal

http://wiki.apache.org/incubator/CorbaProposal

Does anyone have any comments before we vote on it?


Looks fine to me.

Should this also get sent to the incubator list or do we wait until 
after the vote?


Alex Karasulu and I were talking about it and we both think that it 
might be a good idea to shoot for making this a TLP.  Thoughts?


That is not a decision that needs to be made today.  I think we should 
focus on creating a sub project (which is a lot of work as it stands) 
and reevaluate in a month or two.


-dain


I Agree.  I think we should keep focused on getting an ORB for Geronimo 
out the door so Geronimo can use Corba on JDK 5, then look at moving it 
to a top level project.


John

Re: CORBA incubation proposal



On Jan 18, 2006, at 3:48 PM, Dain Sundstrom wrote:


On Jan 18, 2006, at 2:39 PM, Alan D. Cabrera wrote:


Here is the incubation proposal

http://wiki.apache.org/incubator/CorbaProposal

Does anyone have any comments before we vote on it?


Looks fine to me.


agreed.


Should this also get sent to the incubator list or do we wait  
until after the vote?


Alex Karasulu and I were talking about it and we both think that  
it might be a good idea to shoot for making this a TLP.  Thoughts?


That is not a decision that needs to be made today.  I think we  
should focus on creating a sub project (which is a lot of work as  
it stands) and reevaluate in a month or two.



agreed.

thanks
david jencks


-dain

Re: CORBA incubation proposal

2006-01-18 Thread Dain Sundstrom


On Jan 18, 2006, at 2:39 PM, Alan D. Cabrera wrote:


Here is the incubation proposal

http://wiki.apache.org/incubator/CorbaProposal

Does anyone have any comments before we vote on it?


Looks fine to me.

Should this also get sent to the incubator list or do we wait until  
after the vote?


Alex Karasulu and I were talking about it and we both think that it  
might be a good idea to shoot for making this a TLP.  Thoughts?


That is not a decision that needs to be made today.  I think we  
should focus on creating a sub project (which is a lot of work as it  
stands) and reevaluate in a month or two.


-dain

[jira] Created: (GERONIMO-1494) Potential

Potential 
--

 Key: GERONIMO-1494
 URL: http://issues.apache.org/jira/browse/GERONIMO-1494
 Project: Geronimo
Type: Bug
  Components: ActiveMQ  
Versions: 1.0
Reporter: Kevan Miller
Priority: Minor
 Fix For: 1.1


The geronimo.log posted to http://issues.apache.org/jira/browse/GERONIMO-1372 
shows evidence of infinite loop in ActiveMQ shutdown processing. 

The log entry from the 1372 log is excerpted below: 

17:30:34,325 WARN [TransportChannelSupport] Caught exception dispatching 
message and no ExceptionListener registered: javax.jms.JMSException: asyncSend 
failed: java.io.EOFException: Cannot write to the stream any more it has 
already been closed 
javax.jms.JMSException: asyncSend failed: java.io.EOFException: Cannot write to 
the stream any more it has already been closed 
at 
org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49)
 
at 
org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:483)
 
at 
org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160)
 
at 
org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145)
 
at org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) 
at 
org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617)
 
at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) 
at 
org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78)
 
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164)
 
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:176)
 
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40)
 
at 
org.activemq.ra.ActiveMQAsfEndpointWorker$1$1.onException(ActiveMQAsfEndpointWorker.java:83)
 
at 
org.activemq.transport.TransportChannelSupport.onAsyncException(TransportChannelSupport.java:445)
 
at 
org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:484)
 
at 
org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160)
 
at 
org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145)
 
at org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) 
at 
org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617)
 
at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) 
at 
org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78)
 
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164)
 
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:176)
 
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40)
 
at 
org.activemq.ra.ActiveMQAsfEndpointWorker$1$1.onException(ActiveMQAsfEndpointWorker.java:83)
 
at 
org.activemq.transport.TransportChannelSupport.onAsyncException(TransportChannelSupport.java:445)
 
at 
org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:484)
 
at 
org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160)
 
at 
org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145)
 
at org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) 
at 
org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617)
 
at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) 
... (you get the picture) 
at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) 
at 
org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78)
 
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164)
 
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.stop(ActiveMQAsfEndpointWorker.java:139)
 
at 
org.activemq.ra.ActiveMQResourceAdapter.endpointDeactivation(ActiveMQResourceAdapter.java:261)
 
at 
org.apache.geronimo.connector.ResourceAdapterWrapper.endpointDeactivation(ResourceAdapterWrapper.java:92)
 
at 
org.apache.geronimo.connector.ResourceAdapterWrapper$$FastClassByCGLIB$$4ab28e73.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:118)
 
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) 
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) 
at 
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
 
at 
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInt

Re: Clustering - initial overview doc... - where should we keep it ?

Jules has the documentation for clustering and I am suggesting him to get that documentation
published in confluence.

Currently, there is just an empty entry in the Table of Contents pointing to *Clustering* in the
*Performance and high availability* section.

You can see the TOC here
http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692

Cheers!
Hernan

lichtner wrote:

So where is this document now? I am not very familiar with the web site
there seems to be more than one place.

On Wed, 18 Jan 2006, Hernan Cunico wrote:

Hi Jules,
many of the articles (if not all) started the same way and many of them are
still a work in progress.

It would be great if you can publish your doc there, I can give you a hand with
the confluence
formatting if you want to.

Cheers!
Hernan

Jules Gosnell wrote:

Hernan Cunico wrote:

Hi Jules,
can you put your docs in confluence!?

There is already a section for performance in the TOC, it would be
great if you put the clustering documentation there.

OK - can do, if everyone is happy with this...

It is a pretty rough doc though... the rest of the stuff in there looks
pretty polished... - this really is a work in progress... - is that OK ?

Jules

Here is the link to the TOC, to edit confluence you will have to
register first.

http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692

Let me know if you need any help with confluence.

Cheers!
Hernan

Jules Gosnell wrote:

Guys,

I have the beginnings of this doc...

Where would be the best place to keep it ? Ideally it should be r/w
by everyone, with history - SVN, WIKI or where ? What is best practice ?

Also, if in SVN, what format - text, html, ... etc...

Jules

[jira] Created: (GERONIMO-1493) Deadlock in ActiveMQ close processing

Deadlock in ActiveMQ close processing
-

 Key: GERONIMO-1493
 URL: http://issues.apache.org/jira/browse/GERONIMO-1493
 Project: Geronimo
Type: Bug
  Components: ActiveMQ  
Versions: 1.0
 Environment: Geronimo 1.0
Reporter: Kevan Miller
 Fix For: 1.1


Poor use of synchronization in ActiveMQAsfEndpointWorker can prevent Geronimo 
from shutting down. The problem showed up in Jira 1422 
(http://issues.apache.org/jira/browse/GERONIMO-1422). And is contained in the 
attached file 
(http://issues.apache.org/jira/secure/attachment/12321750/geronimo_shutdown_stdout.txt).

The following thread is attempting to reconnect to the broker:

"Thread-91" prio=7 tid=0x08358d50 nid=0x91 waiting on condition 
[c082f000..c082fd98]
at java.lang.Thread.sleep(Native Method)
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:177)
- locked <0xc7c80470> (a org.activemq.ra.ActiveMQAsfEndpointWorker)
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40)
at 
org.activemq.ra.ActiveMQAsfEndpointWorker$1.run(ActiveMQAsfEndpointWorker.java:105)
- locked <0xc7c7d138> (a org.activemq.ra.ActiveMQAsfEndpointWorker$1)
at 
org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown 
Source)
at java.lang.Thread.run(Thread.java:534)

While the following thread is attempting to close the EndpointWorker:

"Geronimo shutdown thread" prio=5 tid=0x08ed3030 nid=0x7f waiting for monitor 
entry [c07ed000..c07edd98]
at 
org.activemq.ra.ActiveMQAsfEndpointWorker.stop(ActiveMQAsfEndpointWorker.java:135)
- waiting to lock <0xc7c80470> (a 
org.activemq.ra.ActiveMQAsfEndpointWorker)
at 
org.activemq.ra.ActiveMQResourceAdapter.endpointDeactivation(ActiveMQResourceAdapter.java:261)
at 
org.apache.geronimo.connector.ResourceAdapterWrapper.endpointDeactivation(ResourceAdapterWrapper.java:92)
at 
org.apache.geronimo.connector.ResourceAdapterWrapper$$FastClassByCGLIB$$4ab28e73.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:118)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
at 
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at 
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
at 
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at 
org.apache.geronimo.connector.ResourceAdapterWrapper$$EnhancerByCGLIB$$168e117d.endpointDeactivation()
at 
org.apache.geronimo.connector.ActivationSpecWrapper.deactivate(ActivationSpecWrapper.java:109)
at 
org.apache.geronimo.connector.ActivationSpecWrapper$$FastClassByCGLIB$$aaa078c1.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:118)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
at 
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at 
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
at 
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at 
org.apache.geronimo.connector.ActivationSpecWrapper$$EnhancerByCGLIB$$17d592bb.deactivate()
at org.openejb.mdb.MDBContainer.doStop(MDBContainer.java:223)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1079)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:395)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:200)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:545)
at 
org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:213)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:192)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:545)
at 
org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:213)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:192)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:545)
at 
org.apache.geronimo.kernel.basic

[jira] Resolved: (GERONIMO-1458) Use JacORB IDL Compiler instead of Sun's idlj

2006-01-18 Thread Alan Cabrera (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1458?page=all ]
 
Alan Cabrera resolved GERONIMO-1458:


Resolution: Fixed

> Use JacORB IDL Compiler instead of Sun's idlj
> -
>
>  Key: GERONIMO-1458
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1458
>  Project: Geronimo
> Type: Task
>   Components: CORBA
> Versions: 1.1
> Reporter: Anders Hessellund Jensen
> Assignee: Alan Cabrera
>  Fix For: 1.1
>  Attachments: generated-sources.zip, geronimo-orb-GERONIMO-1458.patch, 
> geronimo-spec-corba-GERONIMO-1458.patch, maven-idlj-plugin-GERONIMO-1458.patch
>
> We should use the JacORB IDL Compiler instead of Sun's idlj. Depending on 
> idlj for compilation of IDL files makes the build processs depend on Suns JDK 
> implementation.
> This involves the following:
> Upload the JacORB IDL compiler to the maven repos
> Modify the maven-idlj-plugin to support JacORB
> Update the geronimo-spec-corba POM
> Update the geronimo-orb POM 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (GERONIMO-1458) Use JacORB IDL Compiler instead of Sun's idlj

2006-01-18 Thread Alan Cabrera (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1458?page=all ]

Alan Cabrera reassigned GERONIMO-1458:
--

Assign To: Alan Cabrera  (was: Anders Hessellund Jensen)

> Use JacORB IDL Compiler instead of Sun's idlj
> -
>
>  Key: GERONIMO-1458
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1458
>  Project: Geronimo
> Type: Task
>   Components: CORBA
> Versions: 1.1
> Reporter: Anders Hessellund Jensen
> Assignee: Alan Cabrera
>  Fix For: 1.1
>  Attachments: generated-sources.zip, geronimo-orb-GERONIMO-1458.patch, 
> geronimo-spec-corba-GERONIMO-1458.patch, maven-idlj-plugin-GERONIMO-1458.patch
>
> We should use the JacORB IDL Compiler instead of Sun's idlj. Depending on 
> idlj for compilation of IDL files makes the build processs depend on Suns JDK 
> implementation.
> This involves the following:
> Upload the JacORB IDL compiler to the maven repos
> Modify the maven-idlj-plugin to support JacORB
> Update the geronimo-spec-corba POM
> Update the geronimo-orb POM 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

CORBA incubation proposal


Here is the incubation proposal

http://wiki.apache.org/incubator/CorbaProposal

Does anyone have any comments before we vote on it?

Should this also get sent to the incubator list or do we wait until 
after the vote?


Alex Karasulu and I were talking about it and we both think that it 
might be a good idea to shoot for making this a TLP.  Thoughts?




Regards,
Alan

Re: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

2006-01-18 Thread Prasad Kashyap

I have also noticed that using struts tag to write out a string  will take care of the problem.

Cheers
PrasadOn 1/18/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
Jeff, to answer your question about containers on other servers
handling XSS, I can say that WebSphere too leaves it to the apps to
protect themselves. Would it be too paranoid for a container to handle
this ?

Joe, the scripts can be entered on the request just like any other parameter using the input field. 

Eg. You have a login page with a field for loginid. The user enters a
script in the field. Now assume that security is turned off and just
about any userid is allowed inside. After logging in, the consolde
displays a "Welcome " somewhere there. Had the user
entered a script, it would have been executed soon after the Welcome
rendered.

Another example. Say you have a search url.
http://localhost:8080/console/search.jsp?pattern="alert('hi')"

When the search servlet can't find that pattern, if it is designed to
render a page that says, " not found", then the script
will be executed at that stage.

Cheers
PrasadOn 1/18/06, Dave Colasurdo <
[EMAIL PROTECTED]> wrote:
Snippets from another offline conversation with the Tomact folks.. >> Has Tomcat (the container) considered checking input URIs for scripting >> tags and rendering them innocuous by substitution (
e.g.

Re: Clustering - initial overview doc... - where should we keep it ?

2006-01-18 Thread Rajith Attapattu

Hey Hernan,
 
If u can publish a few tips on basic formatting with confluence that will help. 
Maybe an email or a doc itself within confluence will do.
 
Regards,
 
Rajith. 
On 1/18/06, lichtner <[EMAIL PROTECTED]> wrote:
So where is this document now? I am not very familiar with the web sitethere seems to be more than one place.
On Wed, 18 Jan 2006, Hernan Cunico wrote:> Hi Jules,> many of the articles (if not all) started the same way and many of them are still a work in progress.>> It would be great if you can publish your doc there, I can give you a hand with the confluence
> formatting if you want to.>> Cheers!> Hernan>> Jules Gosnell wrote:> > Hernan Cunico wrote:> >> >> Hi Jules,> >> can you put your docs in confluence!?
> >>> >> There is already a section for performance in the TOC, it would be> >> great if you put the clustering documentation there.> >> >> >> > OK - can do, if everyone is happy with this...
> >> > It is a pretty rough doc though... the rest of the stuff in there looks> > pretty polished... - this really is a work in progress... - is that OK ?> >> > Jules> >
> >>> >> Here is the link to the TOC, to edit confluence you will have to> >> register first.> >>> >> 
http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692> >>> >>> >> Let me know if you need any help with confluence.> >>> >> Cheers!
> >> Hernan> >>> >> Jules Gosnell wrote:> >>> >>> Guys,>  >>> I have the beginnings of this doc...> >>>
> >>> Where would be the best place to keep it ? Ideally it should be r/w> >>> by everyone, with history - SVN, WIKI or where ? What is best practice ?>  >>> Also, if in SVN, what format - text, html, ... etc...
>   >>> Jules>  >> >>

Re: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

2006-01-18 Thread Prasad Kashyap

Jeff, to answer your question about containers on other servers
handling XSS, I can say that WebSphere too leaves it to the apps to
protect themselves. Would it be too paranoid for a container to handle
this ?

Joe, the scripts can be entered on the request just like any other parameter using the input field. 

Eg. You have a login page with a field for loginid. The user enters a
script in the field. Now assume that security is turned off and just
about any userid is allowed inside. After logging in, the consolde
displays a "Welcome " somewhere there. Had the user
entered a script, it would have been executed soon after the Welcome
rendered.

Another example. Say you have a search url.
http://localhost:8080/console/search.jsp?pattern="alert('hi')"
When the search servlet can't find that pattern, if it is designed to
render a page that says, " not found", then the script
will be executed at that stage.

Cheers
PrasadOn 1/18/06, Dave Colasurdo <[EMAIL PROTECTED]> wrote:
Snippets from another offline conversation with the Tomact folks.. >> Has Tomcat (the container) considered checking input URIs for scripting >> tags and rendering them innocuous by substitution (
e.g.

Re: Clustering - initial overview doc... - where should we keep it ?


So where is this document now? I am not very familiar with the web site
there seems to be more than one place.

On Wed, 18 Jan 2006, Hernan Cunico wrote:

> Hi Jules,
> many of the articles (if not all) started the same way and many of them are 
> still a work in progress.
>
> It would be great if you can publish your doc there, I can give you a hand 
> with the confluence
> formatting if you want to.
>
> Cheers!
> Hernan
>
> Jules Gosnell wrote:
> > Hernan Cunico wrote:
> >
> >> Hi Jules,
> >> can you put your docs in confluence!?
> >>
> >> There is already a section for performance in the TOC, it would be
> >> great if you put the clustering documentation there.
> >
> >
> >
> > OK - can do, if everyone is happy with this...
> >
> > It is a pretty rough doc though... the rest of the stuff in there looks
> > pretty polished... - this really is a work in progress... - is that OK ?
> >
> > Jules
> >
> >>
> >> Here is the link to the TOC, to edit confluence you will have to
> >> register first.
> >>
> >> http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692
> >>
> >>
> >> Let me know if you need any help with confluence.
> >>
> >> Cheers!
> >> Hernan
> >>
> >> Jules Gosnell wrote:
> >>
> >>> Guys,
> >>>
> >>> I have the beginnings of this doc...
> >>>
> >>> Where would be the best place to keep it ? Ideally it should be r/w
> >>> by everyone, with history - SVN, WIKI or where ? What is best practice ?
> >>>
> >>> Also, if in SVN, what format - text, html, ... etc...
> >>>
> >>>
> >>> Jules
> >>>
> >
> >
>

[jira] Commented: (GERONIMO-1448) debug-tool does not work on Tomcat

[ 
http://issues.apache.org/jira/browse/GERONIMO-1448?page=comments#action_12363171
 ] 

Kevan Miller commented on GERONIMO-1448:


Hmmm. I was a bit curious as to why this fix would work. I just tested on trunk 
and it's not working for me. After starting the debug tool app, debug tool 
still serves up bad links. I also restarted the server for good measure...

I've noticed that if you load the following url, the page works fine:

   http://localhost:8080/debug-tool/

However, if you load the following url (the resource listed during server 
startup), the MBean links are missing the context-root...

   http://localhost:8080/debug-tool

Any explanations as to why the difference? BTW, I'm assuming that we'll soon be 
replacing debug tool on trunk... We should get this resolved on 1.0.1, 
however...


> debug-tool does not work on Tomcat
> --
>
>  Key: GERONIMO-1448
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1448
>  Project: Geronimo
> Type: Bug
>   Components: Tomcat
> Versions: 1.0
>  Environment: Geronimo-1.0
> Reporter: Kevan Miller
> Assignee: Donald Woods
>  Fix For: 1.0.1, 1.1
>  Attachments: Geronimo-1448.patch
>
> The debug console doesn't work when running Tomcat. The base page loads 
> successfully. However, when you click on a GBean, you get a 404:
> HTTP Status 404 - /index.vm
> type Status report
> message /index.vm
> description The requested resource (/index.vm) is not available.
> Apache Tomcat/5.5.9

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Clustering - initial overview doc... - where should we keep it ?


Hi Jules,
many of the articles (if not all) started the same way and many of them are 
still a work in progress.

It would be great if you can publish your doc there, I can give you a hand with the confluence 
formatting if you want to.


Cheers!
Hernan

Jules Gosnell wrote:

Hernan Cunico wrote:


Hi Jules,
can you put your docs in confluence!?

There is already a section for performance in the TOC, it would be 
great if you put the clustering documentation there.




OK - can do, if everyone is happy with this...

It is a pretty rough doc though... the rest of the stuff in there looks 
pretty polished... - this really is a work in progress... - is that OK ?


Jules



Here is the link to the TOC, to edit confluence you will have to 
register first.


http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692 



Let me know if you need any help with confluence.

Cheers!
Hernan

Jules Gosnell wrote:


Guys,

I have the beginnings of this doc...

Where would be the best place to keep it ? Ideally it should be r/w 
by everyone, with history - SVN, WIKI or where ? What is best practice ?


Also, if in SVN, what format - text, html, ... etc...


Jules

[jira] Resolved: (GERONIMODEVTOOLS-49) Add resource reference GUI created unnecessary target-name elements

2006-01-18 Thread Sachin Patel (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-49?page=all ]
 
Sachin Patel resolved GERONIMODEVTOOLS-49:
--

Resolution: Fixed
 Assign To: Sachin Patel

> Add resource reference GUI created unnecessary target-name elements
> ---
>
>  Key: GERONIMODEVTOOLS-49
>  URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-49
>  Project: Geronimo-Devtools
> Type: Bug
>   Components: eclipse-plugin
>  Environment: WinXP, JDK 1.4.2, Geronimo 1.0, Eclipse 3.1.1
> Reporter: Lin Sun
> Assignee: Sachin Patel
> Priority: Minor

>
> If you specify a resource reference via the naming page in geronimo-web.xml, 
> the naming:target-name elements will be created unnecessarily, and it will 
> cause deploy error when the module is deployed.  For example:
>   
> test
> test
> 
>   
> The workaround is to remove the "" 
> at the source tab and save the change.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1336) Setting the Max PoolSize on a DataBase pool with invalid information does not yield an error message and silently fails

 [ http://issues.apache.org/jira/browse/GERONIMO-1336?page=all ]

Donald Woods updated GERONIMO-1336:
---

Fix Version: 1.1
   Priority: Minor  (was: Major)

Validated patch against latest 1.0 branch.

> Setting the Max PoolSize on a DataBase pool with invalid information does not 
> yield an error message and silently fails
> ---
>
>  Key: GERONIMO-1336
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1336
>  Project: Geronimo
> Type: Bug
>   Components: console
> Versions: 1.0-M5
> Reporter: Matt Hogstrom
> Assignee: Matt Hogstrom
> Priority: Minor
>  Fix For: 1.0.1, 1.1
>  Attachments: DBPoolValidate.patch
>
> When attempting a set of the SystemDatabase pool to a negative value the save 
> command executes and gives the appearance that the change was made.  At least 
> there is no information that indicates it failed.  The following error is 
> logged in the geronimo.log.  The Console should detect this error and inform 
> the user that an invalid value was specified.
> 13:38:37,813 ERROR [DatabasePoolPortlet] Unable to save connection pool
> java.lang.IllegalArgumentException: Max size must be positive, not -1
> at 
> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.setPartitionMaxSize(AbstractSinglePoolConnectionInterceptor.java:149)
> at 
> org.apache.geronimo.connector.outbound.connectionmanagerconfig.SinglePool.setPartitionMaxSize(SinglePool.java:143)
> at 
> org.apache.geronimo.connector.outbound.AbstractConnectionManager.setPartitionMaxSize(AbstractConnectionManager.java:104)
> at 
> org.apache.geronimo.connector.outbound.AbstractConnectionManager$$FastClassByCGLIB$$80012030.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.GBeanAttribute.setValue(GBeanAttribute.java:403)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:698)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.setAttribute(GBeanInstance.java:683)
> at 
> org.apache.geronimo.gbean.runtime.RawInvoker.setAttribute(RawInvoker.java:53)
> at 
> org.apache.geronimo.kernel.basic.RawSetAttributeInvoker.invoke(RawSetAttributeInvoker.java:36)
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at 
> org.apache.geronimo.connector.outbound.ConnectionManagerContainer$$EnhancerByCGLIB$$813b4258.setPartitionMaxSize()
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:940)
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:337)
> at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
> at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMODEVTOOLS-50) resource reference specified in geronimo-web.xml is not shown up in the naming tab of the geronimo web deployment plan editor

2006-01-18 Thread Lin Sun (JIRA)

resource reference specified in geronimo-web.xml is not shown up in the naming 
tab of the geronimo web deployment plan editor
-

 Key: GERONIMODEVTOOLS-50
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-50
 Project: Geronimo-Devtools
Type: Bug
  Components: eclipse-plugin  
 Environment: Eclipse 3.1.1, Geronimo 1.0, winxp, JDK 1.4.2
Reporter: Lin Sun
Priority: Minor


Imported a simple war file that contains a geronimo-web.xml.  The 
geronimo-web.xml also contains a resource reference elements.  
1) I can open the geronimo-web.xml file via the geronimo web deployment plan 
editor, but I don't see the resource reference I specified in the 
geronimo-web.xml file under the naming tab.  
2) I tried to add a resource reference at the naming tab, and save the file.   
Reopen the geronimo-web.xml, the previous defined resource reference is 
replaced with the newly added one.   

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMODEVTOOLS-49) Add resource reference GUI created unnecessary target-name elements

2006-01-18 Thread Lin Sun (JIRA)

Add resource reference GUI created unnecessary target-name elements
---

 Key: GERONIMODEVTOOLS-49
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-49
 Project: Geronimo-Devtools
Type: Bug
  Components: eclipse-plugin  
 Environment: WinXP, JDK 1.4.2, Geronimo 1.0, Eclipse 3.1.1
Reporter: Lin Sun
Priority: Minor


If you specify a resource reference via the naming page in geronimo-web.xml, 
the naming:target-name elements will be created unnecessarily, and it will 
cause deploy error when the module is deployed.  For example:

  
test
test

  

The workaround is to remove the "" at 
the source tab and save the change.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMODEVTOOLS-34) cannot create a resource reference via plugin GUI

2006-01-18 Thread Lin Sun (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-34?page=all ]
 
Lin Sun closed GERONIMODEVTOOLS-34:
---


This issue can be closed now.  The only thing is that if you don't specify a 
target-name, the target-name element will still appear in the source, like:

  
test
test

  

The workaround is to remove the "".  
Will open a seperate bug for this.

> cannot create a resource reference via plugin GUI
> -
>
>  Key: GERONIMODEVTOOLS-34
>  URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-34
>  Project: Geronimo-Devtools
> Type: Bug
>   Components: eclipse-plugin
>  Environment: WinXP, Eclipse 3.1.1, WTP 1.0RC5, JDK 1.4.2
> Reporter: Lin Sun
> Assignee: Sachin Patel

>
> Tried to add a resource reference from the geronimo-web.xml in the simple 
> hello program (in the naming tab page, click on Add.  At resource reference 
> detail page, type resource name and resource link and click Finish.  Got an 
> error in a sec asking me to check error log.  (It would be nice to indicate 
> to the user where the error log is).
> I went to .metadata\.log file, and saw the following exception:
> !ENTRY org.eclipse.jface 4 2 2006-01-09 15:50:16.161
> !MESSAGE Problems occurred when invoking code from plug-in: 
> "org.eclipse.jface".
> !STACK 0
> java.util.MissingResourceException: The image resource 
> 'full/obj16/ResourceRefType' could not be located
>   at 
> org.eclipse.emf.common.EMFPlugin.delegatedGetImage(EMFPlugin.java:319)
>   at org.eclipse.emf.common.EMFPlugin.getImage(EMFPlugin.java:273)
>   at 
> org.apache.geronimo.xml.ns.naming.provider.ResourceRefTypeItemProvider.getColumnImage(ResourceRefTypeItemProvider.java:376)
>   at 
> org.eclipse.emf.edit.ui.provider.AdapterFactoryLabelProvider.getColumnImage(AdapterFactoryLabelProvider.java:229)
>   at 
> org.eclipse.jface.viewers.TableViewer.doUpdateItem(TableViewer.java:473)
>   at 
> org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:434)
>   at 
> org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java(Inlined
>  Compiled Code))
>   at org.eclipse.core.runtime.Platform.run(Platform.java(Inlined Compiled 
> Code))
>   at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java(Inlined 
> Compiled Code))
>   at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java(Compiled 
> Code))
>   at 
> org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:1763)
>   at 
> org.eclipse.jface.viewers.StructuredViewer.internalUpdate(StructuredViewer.java:1746)
>   at 
> org.eclipse.jface.viewers.StructuredViewer.update(StructuredViewer.java:1697)
>   at 
> org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvider$ViewerRefresh.run(AdapterFactoryContentProvider.java:309)
>   at 
> org.eclipse.emf.edit.ui.provider.AdapterFactoryContentProvider.notifyChanged(AdapterFactoryContentProvider.java:257)
>   at 
> org.eclipse.emf.edit.provider.ChangeNotifier.fireNotifyChanged(ChangeNotifier.java:45)
>   at 
> org.eclipse.emf.edit.provider.ComposedAdapterFactory.fireNotifyChanged(ComposedAdapterFactory.java:451)
>   at 
> org.apache.geronimo.xml.ns.naming.provider.NamingItemProviderAdapterFactory.fireNotifyChanged(NamingItemProviderAdapterFactory.java:530)
>   at 
> org.eclipse.emf.edit.provider.ItemProviderAdapter.fireNotifyChanged(ItemProviderAdapter.java:217)
>   at 
> org.apache.geronimo.xml.ns.naming.provider.ResourceRefTypeItemProvider.notifyChanged(ResourceRefTypeItemProvider.java:319)
>   at 
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.eNotify(BasicNotifierImpl.java(Compiled
>  Code))
>   at 
> org.apache.geronimo.xml.ns.naming.impl.ResourceRefTypeImpl.setResourceLink(ResourceRefTypeImpl.java:461)
>   at 
> org.apache.geronimo.xml.ns.naming.impl.ResourceRefTypeImpl.eSet(ResourceRefTypeImpl.java:574)
>   at 
> org.apache.geronimo.ui.wizards.DynamicAddEditWizard.processEAttributes(DynamicAddEditWizard.java:119)
>   at 
> org.apache.geronimo.ui.wizards.DynamicAddEditWizard.performFinish(DynamicAddEditWizard.java:92)
>   at 
> org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:676)
>   at 
> org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:349)
>   at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:556)
>   at 
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java(Compiled 
> Code))
>   at 
> org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java(Compiled Code))
>   at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java(Inlined 
> Compiled Code))
>   at 
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java(Compiled Code))
>   at 
> org.eclipse.swt.widgets.Display.readAndDispatch(Display.java(Compiled Code))
>   at

[jira] Assigned: (GERONIMO-1449) Cannot build from Geronimo 1.0 src zip - issues with missing dependencies

 [ http://issues.apache.org/jira/browse/GERONIMO-1449?page=all ]

Donald Woods reassigned GERONIMO-1449:
--

Assign To: Matt Hogstrom  (was: Donald Woods)

Matt, can you apply this patch to the 1.0 branch and trunk?

> Cannot build from Geronimo 1.0 src zip - issues with missing dependencies
> -
>
>  Key: GERONIMO-1449
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1449
>  Project: Geronimo
> Type: Bug
>   Components: buildsystem
> Versions: 1.0
> Reporter: John Sisson
> Assignee: Matt Hogstrom
> Priority: Blocker
>  Fix For: 1.0.1, 1.1
>  Attachments: Geronimo-1449.patch
>
> There are a some issues building Geronimo 1.0 from the src zip distribution 
> with a clean maven repo:
> 1. The OpenEJB 2.0 jars have not been published, so downloads of the OpenEJB 
> dependencies fail.
> 2. If you copy the OpenEJB 2.0 jars from the binary release to your local 
> maven repo (e.g. C:\Documents and 
> Settings\sissonj\.maven\repository\openejb\jars) you then run into another 
> issue:
> +
> | configurations Server Configuration for the J2EE Server
> | Memory: 26M/42M
> +
> 
> multiproject:install-callback:
> [echo] Running car:install for Server Configuration for the J2EE Server
> 21110 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder  - 
> org.apache.geronimo.common.DeploymentException: org.apache
> .geronimo.kernel.repository.MissingDependencyException: uri 
> org.apache.geronimo.specs/geronimo-corba_2.3_spec/1.0/jar not found in r
> epository
> Where is the above dependency coming from and why isn't it in the repo?
> The geronimo-service.xml file in the openejb-core-2.0 jar file has the 
> dependency:
>   
> geronimo-spec
> geronimo-spec-corba
> 2.3-rc4
>   
> Note that the above dependency is using the old group id of "geronimo-spec" 
> instead of "org.apache.geronimo.specs" (needs to be fixed) and is also using 
> a release candidate jar.
> My maven local repository doesn't contain the "geronimo-spec" group id, but 
> it does contain the "org.apache.geronimo.specs" groupid, but the 
> geronimo-corba_2.3_spec-1.0.jar wasn't in there (wasn't downloaded).
> Any ideas what is happening here and whether we can provide a workaround for 
> those users who have downloaded the src zip to allow them to build?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1449) Cannot build from Geronimo 1.0 src zip - issues with missing dependencies

 [ http://issues.apache.org/jira/browse/GERONIMO-1449?page=all ]

Donald Woods updated GERONIMO-1449:
---

Attachment: Geronimo-1449.patch

Attaching patch for Part 2 of the reported problem.

> Cannot build from Geronimo 1.0 src zip - issues with missing dependencies
> -
>
>  Key: GERONIMO-1449
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1449
>  Project: Geronimo
> Type: Bug
>   Components: buildsystem
> Versions: 1.0
> Reporter: John Sisson
> Assignee: Donald Woods
> Priority: Blocker
>  Fix For: 1.0.1, 1.1
>  Attachments: Geronimo-1449.patch
>
> There are a some issues building Geronimo 1.0 from the src zip distribution 
> with a clean maven repo:
> 1. The OpenEJB 2.0 jars have not been published, so downloads of the OpenEJB 
> dependencies fail.
> 2. If you copy the OpenEJB 2.0 jars from the binary release to your local 
> maven repo (e.g. C:\Documents and 
> Settings\sissonj\.maven\repository\openejb\jars) you then run into another 
> issue:
> +
> | configurations Server Configuration for the J2EE Server
> | Memory: 26M/42M
> +
> 
> multiproject:install-callback:
> [echo] Running car:install for Server Configuration for the J2EE Server
> 21110 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder  - 
> org.apache.geronimo.common.DeploymentException: org.apache
> .geronimo.kernel.repository.MissingDependencyException: uri 
> org.apache.geronimo.specs/geronimo-corba_2.3_spec/1.0/jar not found in r
> epository
> Where is the above dependency coming from and why isn't it in the repo?
> The geronimo-service.xml file in the openejb-core-2.0 jar file has the 
> dependency:
>   
> geronimo-spec
> geronimo-spec-corba
> 2.3-rc4
>   
> Note that the above dependency is using the old group id of "geronimo-spec" 
> instead of "org.apache.geronimo.specs" (needs to be fixed) and is also using 
> a release candidate jar.
> My maven local repository doesn't contain the "geronimo-spec" group id, but 
> it does contain the "org.apache.geronimo.specs" groupid, but the 
> geronimo-corba_2.3_spec-1.0.jar wasn't in there (wasn't downloaded).
> Any ideas what is happening here and whether we can provide a workaround for 
> those users who have downloaded the src zip to allow them to build?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1449) Cannot build from Geronimo 1.0 src zip - issues with missing dependencies

 [ http://issues.apache.org/jira/browse/GERONIMO-1449?page=all ]

Donald Woods updated GERONIMO-1449:
---

Geronimo Info: [Patch Available]
  Fix Version: 1.1
Assign To: Donald Woods

Looks like part 1 was fixed yesterday.
Part 2 - Turns out that configs/j2ee-server/project.xml needs 
geronimo-corba_2.3_spec and geronimo-spec-corba when OpenEJB is not built with 
Geronimo.

> Cannot build from Geronimo 1.0 src zip - issues with missing dependencies
> -
>
>  Key: GERONIMO-1449
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1449
>  Project: Geronimo
> Type: Bug
>   Components: buildsystem
> Versions: 1.0
> Reporter: John Sisson
> Assignee: Donald Woods
> Priority: Blocker
>  Fix For: 1.0.1, 1.1
>  Attachments: Geronimo-1449.patch
>
> There are a some issues building Geronimo 1.0 from the src zip distribution 
> with a clean maven repo:
> 1. The OpenEJB 2.0 jars have not been published, so downloads of the OpenEJB 
> dependencies fail.
> 2. If you copy the OpenEJB 2.0 jars from the binary release to your local 
> maven repo (e.g. C:\Documents and 
> Settings\sissonj\.maven\repository\openejb\jars) you then run into another 
> issue:
> +
> | configurations Server Configuration for the J2EE Server
> | Memory: 26M/42M
> +
> 
> multiproject:install-callback:
> [echo] Running car:install for Server Configuration for the J2EE Server
> 21110 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder  - 
> org.apache.geronimo.common.DeploymentException: org.apache
> .geronimo.kernel.repository.MissingDependencyException: uri 
> org.apache.geronimo.specs/geronimo-corba_2.3_spec/1.0/jar not found in r
> epository
> Where is the above dependency coming from and why isn't it in the repo?
> The geronimo-service.xml file in the openejb-core-2.0 jar file has the 
> dependency:
>   
> geronimo-spec
> geronimo-spec-corba
> 2.3-rc4
>   
> Note that the above dependency is using the old group id of "geronimo-spec" 
> instead of "org.apache.geronimo.specs" (needs to be fixed) and is also using 
> a release candidate jar.
> My maven local repository doesn't contain the "geronimo-spec" group id, but 
> it does contain the "org.apache.geronimo.specs" groupid, but the 
> geronimo-corba_2.3_spec-1.0.jar wasn't in there (wasn't downloaded).
> Any ideas what is happening here and whether we can provide a workaround for 
> those users who have downloaded the src zip to allow them to build?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

2006-01-18 Thread Dave Colasurdo



Snippets from another offline conversation with the Tomact folks..

>> Has Tomcat (the container) considered checking input URIs for scripting
>> tags and rendering them innocuous by substitution (e.g.

Re: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

Ok...so would there be any interest in a Geronimo valve that we can
include with the container, and developers can choose to add it in at
the Engine (full container), Host, or context levels?  This way if they
want such filtering...just add in the valve.

Comments?

Joe Bohn wrote:
> 
> I agree that the application should code defensively for these types of
> attacks. However, I'm still wondering if this type of attack isn't
> something that the containers could assist with as well.
> 
> IIUC the attack is basically accomplished by appending some script to a
> valid URL.  If this URL is processed without challenge and returned in
> the response then attack is successful.
> 
> So my question (perhaps dumb question) is - "Is this a typical pattern
> used by an application?"  I can see where script is added to the URL on
> a response but it isn't obvious to me how script might be used on a
> request URL.  Could a container provide some additional protection
> (without breaking apps) by striping any script from incoming requests?
> 
> Joe
> 
> 
> Paul McMahan wrote:
>> Jeff, I believe it is the responsibility of the application to secure
>> itself against XSS attacks, and not the web container's. As you know,
>> the web container really has no way to differentiate between
>> legitimate and "tainted" content in the output stream.  The container
>> could do paranoid things such as replacing suspicous characters when
>> it logs request URIs.  But, as you say, that type of approach could be
>> seen as too heavy handed.
>>
>> Best wishes,
>> Paul
>>
>> On 1/18/06, *Jeff Genender* <[EMAIL PROTECTED]
>> > wrote:
>>
>> Where I am going at with this...is this a vulnerability caused by
>> coding
>> the apps, or the containers themselves?
>>
>> i.e., Will I have this problem with a perl app running on httpd? or
>> ASP/C# on IIS?  Is this type of vulnerability a facet of
>> responsibility
>> that lies on the container, or the developer?
>>
>> I am just trying to assess this as a true vulnerability from a web
>> container perspective.  I am assuming, that yes, the container could
>> change the < and > to lt&; and gt&;.  But, I am wondering where we
>> draw
>> the line and wonder if that is too heavy handed.
>>
>> If the other web servers provide protection from this, then I
>> guess its
>> safe to assume we should follow the pack. OTOH, I surely would not
>> want
>> to take away too much responsibility of the developer to ensure they
>> are
>> properly securing their own apps, while maintaining a bit of
>> flexibility
>> for them.
>>
>> Jeff
>>
>> Kevan Miller wrote:
>>  >
>>  > On Jan 18, 2006, at 11:24 AM, Jeff Genender wrote:
>>  >
>>  >> So assuming this appears to be somewhat "examples" related, is
>> this
>>  >> truly a container problem, or just the jsp examples
>> implementation?
>>  >
>>  > IANASE, but it seems that any vulnerabilities must be fixed in
>> the apps
>>  > themselves -- certainly seems like the only course of action for G
>>  > 1.0.1. I'm currently aware of problems with samples and the admin
>> console.
>>  >
>>  > Apps must insure they return appropriate content to clients. I
>> don't see
>>  > how a container could provide general XSS protection... I'm sure
>> there
>>  > are people who know much more than I on the topic...
>>  >
>>  > --kevan
>>
>>
>

Re: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

2006-01-18 Thread Joe Bohn

I agree that the application should code defensively for these types of 
attacks. However, I'm still wondering if this type of attack isn't 
something that the containers could assist with as well.

IIUC the attack is basically accomplished by appending some script to a 
valid URL.  If this URL is processed without challenge and returned in 
the response then attack is successful.

So my question (perhaps dumb question) is - "Is this a typical pattern 
used by an application?"  I can see where script is added to the URL on 
a response but it isn't obvious to me how script might be used on a 
request URL.  Could a container provide some additional protection 
(without breaking apps) by striping any script from incoming requests?

Joe

Paul McMahan wrote:
Jeff, I believe it is the responsibility of the application to secure 
itself against XSS attacks, and not the web container's. As you know, 
the web container really has no way to differentiate between legitimate 
and "tainted" content in the output stream.  The container could do 
paranoid things such as replacing suspicous characters when it logs 
request URIs.  But, as you say, that type of approach could be seen as 
too heavy handed.

Best wishes,
Paul

On 1/18/06, *Jeff Genender* <[EMAIL PROTECTED] 
> wrote:

Where I am going at with this...is this a vulnerability caused by coding
the apps, or the containers themselves?

i.e., Will I have this problem with a perl app running on httpd? or
ASP/C# on IIS?  Is this type of vulnerability a facet of responsibility
that lies on the container, or the developer?

I am just trying to assess this as a true vulnerability from a web
container perspective.  I am assuming, that yes, the container could
change the < and > to lt&; and gt&;.  But, I am wondering where we draw
the line and wonder if that is too heavy handed.

If the other web servers provide protection from this, then I guess its
safe to assume we should follow the pack. OTOH, I surely would not want
to take away too much responsibility of the developer to ensure they
are
properly securing their own apps, while maintaining a bit of flexibility
for them.

Jeff

Kevan Miller wrote:
 >
 > On Jan 18, 2006, at 11:24 AM, Jeff Genender wrote:
 >
 >> So assuming this appears to be somewhat "examples" related, is this
 >> truly a container problem, or just the jsp examples implementation?
 >
 > IANASE, but it seems that any vulnerabilities must be fixed in
the apps
 > themselves -- certainly seems like the only course of action for G
 > 1.0.1. I'm currently aware of problems with samples and the admin
console.
 >
 > Apps must insure they return appropriate content to clients. I
don't see
 > how a container could provide general XSS protection... I'm sure
there
 > are people who know much more than I on the topic...
 >
 > --kevan

--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Re: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

2006-01-18 Thread Paul McMahan

Jeff, I believe it is the responsibility of the application to secure
itself against XSS attacks, and not the web container's. As you know,
the web container really has no way to differentiate between
legitimate and "tainted" content in the output stream. 
The container could do paranoid things such as replacing suspicous
characters when it logs request URIs.  But, as you say, that type
of approach could be seen as too heavy handed.

Best wishes,
PaulOn 1/18/06, Jeff Genender <[EMAIL PROTECTED]
> wrote:
Where I am going at with this...is this a vulnerability caused by codingthe apps, or the containers themselves?i.e., Will I have this problem with a perl app running on httpd? orASP/C# on IIS?  Is this type of vulnerability a facet of responsibility
that lies on the container, or the developer?I am just trying to assess this as a true vulnerability from a webcontainer perspective.  I am assuming, that yes, the container couldchange the < and > to lt&; and gt&;.  But, I am wondering where we draw
the line and wonder if that is too heavy handed.If the other web servers provide protection from this, then I guess itssafe to assume we should follow the pack. OTOH, I surely would not wantto take away too much responsibility of the developer to ensure they are
properly securing their own apps, while maintaining a bit of flexibilityfor them.JeffKevan Miller wrote:>> On Jan 18, 2006, at 11:24 AM, Jeff Genender wrote:>>> So assuming this appears to be somewhat "examples" related, is this
>> truly a container problem, or just the jsp examples implementation?>> IANASE, but it seems that any vulnerabilities must be fixed in the apps> themselves -- certainly seems like the only course of action for G
> 1.0.1. I'm currently aware of problems with samples and the admin console.>> Apps must insure they return appropriate content to clients. I don't see> how a container could provide general XSS protection... I'm sure there
> are people who know much more than I on the topic...>> --kevan

Work


I am actually looking for another job/contract right now (in the San Diego
area, or I can telecommute), so I thought I would mention it in case
anybody knows of any openings.

Guglielmo

[jira] Commented: (GERONIMO-1474) Cross site scripting vulnerabilites

2006-01-18 Thread Paul McMahan (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-1474?page=comments#action_12363140
 ] 

Paul McMahan commented on GERONIMO-1474:


Please note that the patch for the admin portlets does *not* address any XSS 
vulnerabilities in the sample applications.   Based on recent discussion on the 
dev list my understanding is that the tomcat dev team will address any 
vulnerabilities in the samples they provide.

> Cross site scripting vulnerabilites
> ---
>
>  Key: GERONIMO-1474
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1474
>  Project: Geronimo
> Type: Bug
>   Components: console, security
> Versions: 1.0
> Reporter: Greg Wilkins
>  Fix For: 1.0.1, 1.1
>  Attachments: GERONIMO-1474.patch
>
> Reported by oliver karow:
> The Web-Access-Log viewer does no filtering for html-/script-tags, and
> therefore allows attacks against the user of the admin-console:
> http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> Also reported:
> The first one is a classical cross-site scripting in the jsp-examples:
> http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1474) Cross site scripting vulnerabilites

2006-01-18 Thread Paul McMahan (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1474?page=all ]

Paul McMahan updated GERONIMO-1474:
---

Geronimo Info: [Patch Available]

> Cross site scripting vulnerabilites
> ---
>
>  Key: GERONIMO-1474
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1474
>  Project: Geronimo
> Type: Bug
>   Components: console, security
> Versions: 1.0
> Reporter: Greg Wilkins
>  Fix For: 1.0.1, 1.1
>  Attachments: GERONIMO-1474.patch
>
> Reported by oliver karow:
> The Web-Access-Log viewer does no filtering for html-/script-tags, and
> therefore allows attacks against the user of the admin-console:
> http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> Also reported:
> The first one is a classical cross-site scripting in the jsp-examples:
> http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1474) Cross site scripting vulnerabilites

2006-01-18 Thread Paul McMahan (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1474?page=all ]

Paul McMahan updated GERONIMO-1474:
---

Attachment: GERONIMO-1474.patch

Attaching a patch that will escape any special html chars read from the web, 
derby, and system logs before displaying them in the log viewer portlets. The 
 jstl tag is used for this purpose, setting the escapeXml attribute to 
true.  The JSTL 1.0 specification for this tag says:

"If escapeXml is true, the following character conversions are applied:

CharacterCharacter Entity Code
<<
>>
&   &
' '
''"


> Cross site scripting vulnerabilites
> ---
>
>  Key: GERONIMO-1474
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1474
>  Project: Geronimo
> Type: Bug
>   Components: console, security
> Versions: 1.0
> Reporter: Greg Wilkins
>  Fix For: 1.0.1, 1.1
>  Attachments: GERONIMO-1474.patch
>
> Reported by oliver karow:
> The Web-Access-Log viewer does no filtering for html-/script-tags, and
> therefore allows attacks against the user of the admin-console:
> http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time="/>alert(document.cookie)
> Also reported:
> The first one is a classical cross-site scripting in the jsp-examples:
> http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds

[ 
http://issues.apache.org/jira/browse/GERONIMO-1422?page=comments#action_12363134
 ] 

Kevan Miller commented on GERONIMO-1422:


Oops, I forgot...

branches/1.0:
Sendingconfigs/activemq-broker/src/plan/plan.xml
Transmitting file data .
Committed revision 370205.

trunk:
Sendingconfigs/activemq-broker/src/plan/plan.xml
Transmitting file data .
Committed revision 370204.


> Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect 
> endpoints to broker every 30 seconds
> 
>
>  Key: GERONIMO-1422
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1422
>  Project: Geronimo
> Type: Bug
>   Components: ActiveMQ
> Versions: 1.0
>  Environment: Solaris 10 x86 under VMWare player 1.01
> Java 1.4.2_10
> tomcat build of geronimo
> Reporter: John Sisson
> Assignee: Kevan Miller
>  Fix For: 1.0.1
>  Attachments: geronimo_shutdown_stdout.txt, shutdown.txt, shutdown_rhel3.txt
>
> Can anyone reproduce this problem on other platforms?
> If I start the tomcat build of the release candidate and then shut it down 
> once the startup has completed it shuts down almost cleanly:
> Server shutdown begun  
> 11:25:47,951 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
> http-0.0.0.0-8443
> 11:25:48,986 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
> http-0.0.0.0-8080
> 11:25:49,001 INFO  [StandardContext] Container 
> org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not 
> been started
> Server shutdown completed
> I have shutdown issues If I do the following:
> * start the tomcat build of release candidate using geronimo.sh run --long
> * connect to the daytrader web app
> *  populate the daytrader database via the daytrader configuration page
> * log into daytrader and view account, portfolio etc.
> * press ctrl-C in the window that geronimo was started in to shut it down.  
> * You will see ActiveMQAsfEndpointWorker messages every 30 seconds.  
> 10:46:56,356 WARN  [BrokerContainerImpl] Got duplicate deregisterConnection 
> for client: ID:unknown-34799-1136504488185-10:0
> 10:46:56,358 WARN  [TransportChannelSupport] Caught exception dispatching 
> message and no ExceptionListener registered: javax.jms.JMSException: Error 
> reading socket: java.io.EOFException
> javax.jms.JMSException: Error reading socket: java.io.EOFException
> at 
> org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49)
> at 
> org.activemq.transport.tcp.TcpTransportChannel.doClose(TcpTransportChannel.java:509)
> at 
> org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:330)
> at java.lang.Thread.run(Thread.java:534)
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:333)
> at 
> org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:230)
> at 
> org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313)
> ... 1 more
> 10:47:27,401 INFO  [ActiveMQAsfEndpointWorker] Endpoint connection to JMS 
> broker failed: Initialization of TcpTransportChannel failed. URI was: 
> tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused
> 10:47:27,402 INFO  [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect 
> to the JMS broker in 30 seconds
> 10:47:27,403 INFO  [ActiveMQAsfEndpointWorker] Endpoint connection to JMS 
> broker failed: Initialization of TcpTransportChannel failed. URI was: 
> tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused
> 10:47:27,403 INFO  [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect 
> to the JMS broker in 30 seconds
> I will have attached a capture of stdout also including a thread dump to this 
> issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds

 [ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ]
 
Kevan Miller closed GERONIMO-1422:
--

Resolution: Fixed

As Jules suggested, ActiveMQ's shutdown handler was being invoked. This meant 
that the broker was stopping before Geronimo could stop any internal clients. 
Log entries and exposure of several ActiveMQ bugs resulted. I've set the 
activemq.broker.disable-clean-shutdown property to true using the 
SystemProperties GBean in the ActiveMQ broker config. Shutdown looks much 
cleaner.

ActiveMQ warnings are still possible during shutdown, but should be greatly 
reduced. The ActiveMQ shutdown bugs are not fixed by this change. I'll create 
new jira's to describe them. The bugs I've seen are:
1) infinite recursion in RA reconnect processing
2) deadlock in Connection close processing



> Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect 
> endpoints to broker every 30 seconds
> 
>
>  Key: GERONIMO-1422
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1422
>  Project: Geronimo
> Type: Bug
>   Components: ActiveMQ
> Versions: 1.0
>  Environment: Solaris 10 x86 under VMWare player 1.01
> Java 1.4.2_10
> tomcat build of geronimo
> Reporter: John Sisson
> Assignee: Kevan Miller
>  Fix For: 1.0.1
>  Attachments: geronimo_shutdown_stdout.txt, shutdown.txt, shutdown_rhel3.txt
>
> Can anyone reproduce this problem on other platforms?
> If I start the tomcat build of the release candidate and then shut it down 
> once the startup has completed it shuts down almost cleanly:
> Server shutdown begun  
> 11:25:47,951 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
> http-0.0.0.0-8443
> 11:25:48,986 INFO  [Http11Protocol] Stopping Coyote HTTP/1.1 on 
> http-0.0.0.0-8080
> 11:25:49,001 INFO  [StandardContext] Container 
> org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not 
> been started
> Server shutdown completed
> I have shutdown issues If I do the following:
> * start the tomcat build of release candidate using geronimo.sh run --long
> * connect to the daytrader web app
> *  populate the daytrader database via the daytrader configuration page
> * log into daytrader and view account, portfolio etc.
> * press ctrl-C in the window that geronimo was started in to shut it down.  
> * You will see ActiveMQAsfEndpointWorker messages every 30 seconds.  
> 10:46:56,356 WARN  [BrokerContainerImpl] Got duplicate deregisterConnection 
> for client: ID:unknown-34799-1136504488185-10:0
> 10:46:56,358 WARN  [TransportChannelSupport] Caught exception dispatching 
> message and no ExceptionListener registered: javax.jms.JMSException: Error 
> reading socket: java.io.EOFException
> javax.jms.JMSException: Error reading socket: java.io.EOFException
> at 
> org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49)
> at 
> org.activemq.transport.tcp.TcpTransportChannel.doClose(TcpTransportChannel.java:509)
> at 
> org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:330)
> at java.lang.Thread.run(Thread.java:534)
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:333)
> at 
> org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:230)
> at 
> org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313)
> ... 1 more
> 10:47:27,401 INFO  [ActiveMQAsfEndpointWorker] Endpoint connection to JMS 
> broker failed: Initialization of TcpTransportChannel failed. URI was: 
> tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused
> 10:47:27,402 INFO  [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect 
> to the JMS broker in 30 seconds
> 10:47:27,403 INFO  [ActiveMQAsfEndpointWorker] Endpoint connection to JMS 
> broker failed: Initialization of TcpTransportChannel failed. URI was: 
> tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused
> 10:47:27,403 INFO  [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect 
> to the JMS broker in 30 seconds
> I will have attached a capture of stdout also including a thread dump to this 
> issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

Where I am going at with this...is this a vulnerability caused by coding
the apps, or the containers themselves?

i.e., Will I have this problem with a perl app running on httpd? or
ASP/C# on IIS?  Is this type of vulnerability a facet of responsibility
that lies on the container, or the developer?

I am just trying to assess this as a true vulnerability from a web
container perspective.  I am assuming, that yes, the container could
change the < and > to lt&; and gt&;.  But, I am wondering where we draw
the line and wonder if that is too heavy handed.

If the other web servers provide protection from this, then I guess its
safe to assume we should follow the pack. OTOH, I surely would not want
to take away too much responsibility of the developer to ensure they are
properly securing their own apps, while maintaining a bit of flexibility
for them.

Jeff

Kevan Miller wrote:
> 
> On Jan 18, 2006, at 11:24 AM, Jeff Genender wrote:
> 
>> So assuming this appears to be somewhat "examples" related, is this
>> truly a container problem, or just the jsp examples implementation?
> 
> IANASE, but it seems that any vulnerabilities must be fixed in the apps
> themselves -- certainly seems like the only course of action for G
> 1.0.1. I'm currently aware of problems with samples and the admin console.
> 
> Apps must insure they return appropriate content to clients. I don't see
> how a container could provide general XSS protection... I'm sure there
> are people who know much more than I on the topic...
> 
> --kevan

JACC plugability etc

First of all, someone pointed me recently to https:// 
openjacc.projects.dev2dev.bea.com/ which looks like it shares some  
goals with us.  I can't tell how its license affects our ability to  
use it, and would appreciate some informed opinions.


I would like our JACC implementation to be plugable and extensible to  
permissions not specifically mentioned in the jacc spec such as the  
jetspeed 2 portal permissions.  I've been thinking on and off about  
this and it might even be possible.  Here are some aspects to this  
problem:


- spec defined permissions, from the spec deployment descriptors.   
This can probably be used for any jacc implementation, so should  
remain in "core geronimo".


- Putting the permissions from the spec into the jacc  
PolicyConfiguration.  We use the  
ApplicationPolicyConfigurationManager gbean for this now, but that  
includes also code specific to our geronimo jacc implementation.   
Perhaps this can be split into 2 gbeans or a base gbean with the spec- 
required behavior can be written.


- Our plans include xml for a role >> principal mapping which is  
specific to our jacc implementation.  This info is added to the  
ApplicationPolicyConfigurationManager as well.  The use of our schema  
is hardcoded in our j2ee plans, but this could be turned into a  
namespace-driven choice of security builders.


So, what I'm thinking of is something like:

- define a SecurityBuilder interface primarily for the non-spec parts  
of the security setup.  The various j2ee builders can call into it at  
appropriate times.


- selection of a SecurityBuilder relates to configuration of the  
server, since it reflects the Policy installed.  I don't see how to  
have several JACC implementations running at once.  Each  
SecurityBuilder would presumably have its own namespace. Perhaps we  
can select the SecurityBuilder based on namespace, but this would  
push the discovery of incompatibility in JACC implementation to  
runtime.  This might or might not be acceptable or the best idea, I'm  
not sure.


- the SecurityBuilder would be responsible for adding the  
ApplicationPolicyConfigurationManager-like gbean to the  
deploymentContext and building up its configuration.


- as now, when the app starts, the  
ApplicationPolicyConfigurationManager gbean will configure the JACC  
PolicyConfiguration appropriately for its jacc implementation.   
Presumably it will need to object if it finds the wrong jacc  
implementation installed.


Comments? Objections? Questions?

thanks
david jencks

Re: Replication using totem protocol

On Wed, 18 Jan 2006, Jules Gosnell wrote:

> I haven't been able to convince myself to take the quorum approach
> because...
>
> shared-something approach:
> - the shared something is a Single Point of Failure (SPoF) - although
> you could use an HA something.

It's not really a spof. You just fail over to a different resource. All
you need is a lock. You could use two java processes anywhere on the
network which listen for a socket, and only one. If one is not listening,
you try the other one.

> - If the node holding the lock 'goes crazy', but does not die, the rest
> of the cluster becomes a fragment - so it becomes an SPoF as well.

If by 'goes crazy' you mean that it's up but it's not doing anything,
totem defends against by detecting processors which fail to make progress
after N token rotations, and when they do it declares them failed.

But if you mean that it just sends corrupt data or starts using broken
algorithms etc. then I would need to research it a bit. But definitely
defending against these byzantine failures will be more expensive. I
believe the solution is that you have to process operations on multiple
nodes and compare the results.

I believe this is how Tandem machines work. Each cpu step is voted on.
Byzantine failures can happen because of cosmic rays, or other
physics-related issues.

Definitely much more fun.

> - used in isolation, it does not take into account that the lock may be
> held by the smallest cluster fragment

Yes, it does. The question is, why do you have a partition? If you have a
partition because a network element failed, then put some redundancy in
your network topology. If the partition is virtual, i.e.
congestion-induced, then wait a few seconds for it to heal.

And if you get too many virtual partitions it means you either need to
tweak your failure detection parameters (token-loss-timeout in totem) or
your load is too high and you need to add some capacity to the cluster.

> shared-nothing approach:
> - I prefer this approach, but, as you have stated, if the two halves are
> equally sized...

I didn't mean to say that. In this approach you _must_ set a minimum
quorum which is _the_ majority of the size of the rack. If you own five
machines, make the quorum three.

> - What if there are two concurrent fractures (does this happen?)

It's no different than any other partition.

> - ActiveCluster notifies you of one membership change at a time - so you
> would have to decide on an algorithm for 'chunking' node loss, so that
> you could decide when a fragmentation had occurred...

The problem exists anyway. Even in totem you can have several
'configurations' installed in quick succession. In order to defend against
this you need to design your state transfer algorithms around it.

> perhaps a hybrid of the two would be able to cover more bases... -
> shared-nothing falling back to shared-something if your fragment is
> sized N/2.

You can definitely make a totally custom algorithm for determining your
majority partition, and it's a fact that hybrid approaches can solve
difficult problems, but for the reasons I said above I believe that you
can just fine if you have a redundant network and you keep some cpu
unused.

> As far as my plans for WADI, I think I am happy to stick with the, 'rely
> on affinity and keep going' approach.
>
> As far as situations where a distributed object may have more than one
> client, I can see that quorum offers the hope of a solution, but,
> without some very careful thought, I would still be hesitant to stake my
> shirt on it :-) for the reasons given above...
>
> I hadn't really considered 'pausing' a cluster fragment, so this is a
> useful idea. I guess that I have been thinking more in terms of
> long-lived fractures, rather than short-lived ones. If the latter are
> that much more common, then this is great input and I need to take it
> into account.
>
> The issue about 'chunking' node loss interests me... I see that the
> EVS4J Listener returns a set of members, so it is possible to express
> the loss of more than one node. How is membership decided and node loss
> aggregated ?

Read the totem protocol article. The membership protocol is in there. But
as I said you can still get a flurry of configurations installed one after
the other. It is only a problem if you plan to do your cluster
re-organization all at once.

Guglielmo

Re: login service refactoring



On Jan 18, 2006, at 6:29 AM, Alan D. Cabrera wrote:


[EMAIL PROTECTED] wrote, On 1/17/2006 7:50 AM:
I started refactoring login service along the lines discussed with  
Alan, David, and others at the apachecon. This includes  
simplifying login service, and authentication by assertion,  
delegation principals. David J, I know that you want pluggable  
api, have you already done some work on it?


This is great Simon!  Can you post a little more detail on how this  
would work?  If you can, put more detail on what the application  
developer would see in terms of how Geronimo would be configured  
and how application would be written to use the service.


I agree, this is great!  I have not had any time to think about this  
yet.  I would greatly appreciate some more info on what you are  
planning to do also.


thanks
david jencks




Regards,
Alan

Re: Build level for Geronimo and version info for dependency projects

2006-01-18 Thread Dain Sundstrom


On Jan 18, 2006, at 6:42 AM, Vamsavardhana Reddy wrote:


Hi,

I see that there is a ServerInfo interface in  
org.apache.geronimo.system.serverinfo package.  This has getVersion 
(), getBuildDate(), getBuildTime(), getBaseDirectory(), getCopyright 
() methods.  Is there any other information (like the svn revision  
for the server build, etc.) about the server that can be retrieved  
programmatically.


If you want to take a crack at it, it shouldn't be that difficult to  
add the svn url and revision number.  The ServerInfo data comes from  
the generated file org/apache/geronimo/system/serverinfo/geronimo- 
version.properties which is created by modules/system/maven.xml.  The  
tricky part is getting the data from svn into maven.


Is there a way to determine the version and build levels of each of  
the dependency projects like OpenEJB, Tomcat, Jetty etc?


Not specifically.  Each jar we include with Geronimo has a version  
number, but Geronimo is designed to support adding and removing of  
components so the components may not be there.  Geronimo is also  
designed to support multiple version of components running at the  
same time (so you can do a rolling upgrade), so it would be difficult  
to pin this down.


In the 1.x future, I hope to have better class loader diagnostics  
available which will let us determine which jars (including the  
version number) have been loaded into class loaders.


-dain

Re: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

2006-01-18 Thread Kevan Miller



On Jan 18, 2006, at 11:24 AM, Jeff Genender wrote:


So assuming this appears to be somewhat "examples" related, is this
truly a container problem, or just the jsp examples implementation?


IANASE, but it seems that any vulnerabilities must be fixed in the  
apps themselves -- certainly seems like the only course of action for  
G 1.0.1. I'm currently aware of problems with samples and the admin  
console.


Apps must insure they return appropriate content to clients. I don't  
see how a container could provide general XSS protection... I'm sure  
there are people who know much more than I on the topic...


--kevan

Re: Proper use of tags in configuration plans

 does not take text content.  You can look for
referenceType in
http://geronimo.apache.org/schemas-1.0/geronimo-config-1.0.xsd

Basically, referenceType extends patternType which holds a
gbean-nameGroup, which can be either a  (which holds a
full GBean name) or a bunch of separate elements.

If the referenced GBean is in the same plan, as it is in your example,
you can take the separate elements approach and all you probably need
is the name (the rest should default correctly).  So:

gb1
gb2

Thanks,
Aaron

On 1/18/06, Nelson A. Perez <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>
>   I am developing a configuration plan involving
> multiple GBeans. One of them, MainGBean, will make use
> of the other GBeans. I am specifying the dependencies
> as follows:
>
> 
>
> 
> xmlns="http://geronimo.apache.org/xml/ns/deployment";
>configId="task/SampleGBean"
>>
>
> 
> samples
>task
>1.0
> 
>
> 
>
>
> 
>
> 
>
>
> 
>
> 
> gb1
> gb2
> 
>
> 
>
>
>
> The idea is that MainGBean references gb1 and gb2 and
> makes use of them. However, I get errors related to
> the   tags and as a result it cant be
> deployed. If I remove the  tags, then it
> can be deployed but  NullPointerExceptions are thrown
> at run-time when MainGBean tries to make use of these
> two GBeans that it references. Any help on the proper
> use of the  tag will be appreciated.
>
> Thanks,
> NP.
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

Re: Clustering - initial overview doc... - where should we keep it ?

Can we resolve the Confluence vs. MoinMoin issue?  Everything is
currently in MoinMoin except the documentation that Hernan has been
working on, is that right?  If we're not committed to moving to
confluence, please put any Wiki content in MoinMoin.  If we are
committed to moving to confluence, let's move everything.  Was there
some progress on this issue at ApacheCon?

Thanks,
Aaron

On 1/18/06, Jules Gosnell <[EMAIL PROTECTED]> wrote:
> Hernan Cunico wrote:
>
> > Hi Jules,
> > can you put your docs in confluence!?
> >
> > There is already a section for performance in the TOC, it would be
> > great if you put the clustering documentation there.
>
>
> OK - can do, if everyone is happy with this...
>
> It is a pretty rough doc though... the rest of the stuff in there looks
> pretty polished... - this really is a work in progress... - is that OK ?
>
> Jules
>
> >
> > Here is the link to the TOC, to edit confluence you will have to
> > register first.
> >
> > http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692
> >
> >
> > Let me know if you need any help with confluence.
> >
> > Cheers!
> > Hernan
> >
> > Jules Gosnell wrote:
> >
> >> Guys,
> >>
> >> I have the beginnings of this doc...
> >>
> >> Where would be the best place to keep it ? Ideally it should be r/w
> >> by everyone, with history - SVN, WIKI or where ? What is best practice ?
> >>
> >> Also, if in SVN, what format - text, html, ... etc...
> >>
> >>
> >> Jules
> >>
>
>
> --
> "Open Source is a self-assembling organism. You dangle a piece of
> string into a super-saturated solution and a whole operating-system
> crystallises out around it."
>
> /**
>  * Jules Gosnell
>  * Partner
>  * Core Developers Network (Europe)
>  *
>  *www.coredevelopers.net
>  *
>  * Open Source Training & Support.
>  **/
>
>

Re: Clustering - initial overview doc... - where should we keep it ?


Hernan Cunico wrote:


Hi Jules,
can you put your docs in confluence!?

There is already a section for performance in the TOC, it would be 
great if you put the clustering documentation there.



OK - can do, if everyone is happy with this...

It is a pretty rough doc though... the rest of the stuff in there looks 
pretty polished... - this really is a work in progress... - is that OK ?


Jules



Here is the link to the TOC, to edit confluence you will have to 
register first.


http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692 



Let me know if you need any help with confluence.

Cheers!
Hernan

Jules Gosnell wrote:


Guys,

I have the beginnings of this doc...

Where would be the best place to keep it ? Ideally it should be r/w 
by everyone, with history - SVN, WIKI or where ? What is best practice ?


Also, if in SVN, what format - text, html, ... etc...


Jules




--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*www.coredevelopers.net
*
* Open Source Training & Support.
**/

Proper use of tags in configuration plans

2006-01-18 Thread Nelson A. Perez

Hi all,


  I am developing a configuration plan involving
multiple GBeans. One of them, MainGBean, will make use
of the other GBeans. I am specifying the dependencies
as follows:



http://geronimo.apache.org/xml/ns/deployment";
   configId="task/SampleGBean"
   >
 

samples
   task
   1.0   
   


   
   



   




gb1
gb2 






The idea is that MainGBean references gb1 and gb2 and
makes use of them. However, I get errors related to
the   tags and as a result it cant be
deployed. If I remove the  tags, then it
can be deployed but  NullPointerExceptions are thrown
at run-time when MainGBean tries to make use of these
two GBeans that it references. Any help on the proper
use of the  tag will be appreciated. 

Thanks,
NP.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

So assuming this appears to be somewhat "examples" related, is this
truly a container problem, or just the jsp examples implementation?

Jeff

Kevan Miller wrote:
> Presumably in response to Dave's email to Tomcat, the following changes
> were made to Tomcat samples, yesterday afternoon:
> 
> From:   [EMAIL PROTECTED]
> Subject: svn commit: r369933 - in
> /tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples: cal/cal2.jsp
> security/protected/index.jsp
> Date: January 17, 2006 4:52:05 PM EST
> To:   tomcat-dev@jakarta.apache.org
> Reply-To:   dev@tomcat.apache.org
> 
> Author: markt
> Date: Tue Jan 17 13:52:02 2006
> New Revision: 369933
> 
> URL: http://svn.apache.org/viewcvs?rev=369933&view=rev
> Log:
> Fix XSS issues in examples.
> 
> Modified:
> tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/cal/cal2.jsp
>
> tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
> 
> 
> Modified:
> tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/cal/cal2.jsp
> URL:
> http://svn.apache.org/viewcvs/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/cal/cal2.jsp?rev=369933&r1=369932&r2=369933&view=diff
> 
> ==
> 
> ---
> tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/cal/cal2.jsp
> (original)
> +++
> tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/cal/cal2.jsp
> Tue Jan 17 13:52:02 2006
> @@ -29,12 +29,12 @@
> 
>   Please add the following event:
>Date <%= table.getDate() %>
> - Time <%= time %> 
> + Time <%= util.HTMLFilter.filter(time) %> 
>  
>  
>  
>   
> - 
> +  util.HTMLFilter.filter(time) %>
>Description of the event  SIZE=20> 
>   
>  
> 
> Modified:
> tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
> 
> URL:
> http://svn.apache.org/viewcvs/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp?rev=369933&r1=369932&r2=369933&view=diff
> 
> ==
> 
> ---
> tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
> (original)
> +++
> tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp
> Tue Jan 17 13:52:02 2006
> @@ -49,11 +49,13 @@
>if (role.length() > 0) {
>  if (request.isUserInRole(role)) {
>  %>
> -  You have been granted role <%= role %>
> +  You have been granted role
> +  <%= util.HTMLFilter.filter(role) %>
>  <%
>  } else {
>  %>
> -  You have not been granted role <%= role %>
> +  You have not been granted role
> +  <%= util.HTMLFilter.filter(role) %>
>  <%
>  }
>}
> @@ -62,7 +64,7 @@
>  To check whether your username has been granted a particular role,
>  enter it here:
>  
> -
> +
>  
>  
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> From:   [EMAIL PROTECTED]
> Subject: svn commit: r369934 -
> /tomcat/container/tc5.5.x/webapps/docs/changelog.xml
> Date: January 17, 2006 4:53:04 PM EST
> To:   tomcat-dev@jakarta.apache.org
> Reply-To:   dev@tomcat.apache.org
> 
> Author: markt
> Date: Tue Jan 17 13:53:01 2006
> New Revision: 369934
> 
> URL: http://svn.apache.org/viewcvs?rev=369934&view=rev
> Log:
> Update changelog.
> 
> Modified:
> tomcat/container/tc5.5.x/webapps/docs/changelog.xml
> 
> Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
> URL:
> http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=369934&r1=369933&r2=369934&view=diff
> 
> ==
> 
> --- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
> +++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Jan 17
> 13:53:01 2006
> @@ -76,6 +76,13 @@
>
>  
>
> +  
> +
> +  
> +Fix some XSS issues in the JSP examples. (markt)
> +  
> +
> +  
>  
> 
>  
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> From:   [EMAIL PROTECTED]
> Subject: svn commit: r369935 - in
> /tomcat/container/branches/tc4.1.x/webapps/examples/jsp: cal/cal2.jsp
> security/protected/index.jsp
> Date: January 17, 2006 4:53:53 PM EST
> To:   tomcat-dev@jakarta.apache.org
> Reply-To:   dev@tomcat.apache.org
> 
> Author: markt
> Date: Tue Jan 17 13:53:49 2006
> New Revision: 369935
> 
> URL: http://svn.apache.org/viewcvs?rev=369935&view=rev
> Log:
> Fix XSS issues in examples.
> 
> Modified:
> tomcat/container/branches/tc4.1.x/webapps/examples/jsp/cal/cal2.jsp
>
> tomcat/container/branches/tc

Re: Clustering - initial overview doc... - where should we keep it ?


Hi Jules,
can you put your docs in confluence!?

There is already a section for performance in the TOC, it would be great if you put the clustering 
documentation there.


Here is the link to the TOC, to edit confluence you will have to register first.

http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=1692

Let me know if you need any help with confluence.

Cheers!
Hernan

Jules Gosnell wrote:

Guys,

I have the beginnings of this doc...

Where would be the best place to keep it ? Ideally it should be r/w by 
everyone, with history - SVN, WIKI or where ? What is best practice ?


Also, if in SVN, what format - text, html, ... etc...


Jules

Re: JBI Deployer

2006-01-18 Thread Philip Dodds

Hossam,

I've been thinking and we can probably switch it so that in the event of us
not finding the components.xml we can switch it back to the jbi.xml and see
if there are any assets in place there,  in this way we can support multiple
components and the more natural single component approach,  I'll try and get
that in place in the next week :)

Cheers

P

On 1/17/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
>
> Currently there are three projects...not sure quite where to put them,
> basically they are:
>
> servicemix-packaging-descriptors - The packaging descriptors and helper
> factories
> servicemix-packaging-eclipse-plugin - The Eclipse plugin itself
>
> maven2-eclipse-plugin-plugin - Horribly named but does what it says,
> basically a Maven2 plugin that can be used to generate the MANFEST.MF for
> Eclipse 3.0 based on the pom.xml
>
> On the beer note I'm still working out if I'll be in Aylesbury in Feb so I
> might be able to make claim to a few :)
>
> Cheers
>
> P
>
> On 1/17/06, James Strachan <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 17 Jan 2006, at 11:11, Philip Dodds wrote:
> > > We've been working on a re-usable deployment plugin for eclipse to
> > > try and simplify the process of create components and actually
> > > making them re-usable.  The basic idea is fairly simple,  when you
> > > build you JBI component,  whether it be a binding component or a
> > > service engine you include a components.xml in the META-INF
> > > directory, which holds information about your component,  and
> > > example of which is below:
> > >
> > > 
> > >   
> > >
> > > 1e194e80-7ee0-11da-bb92-0002a5d5c51b
> > > Groovy Script
> > > 
> > > A component that can be deployed with an embedded Groovy Script
> > > 
> > > 
> > >  > > description="Your Groovy Script" />
> > >  > >
> > > description="Example parameter"/>
> > >  > >
> > > description="Default destination" mep="robustInOnly" />
> > > 
> > > 
> > >
> > > In essence the idea of your components.xml is to describe your
> > > components, which can be either binding-components or service-
> > > engine,  you can also define embedded artifacts which are files you
> > > expect to be bundles with either your service engine or binding-
> > > component,  there is also space for parameters and also connections
> > > to other services.  The idea behind this is to express your
> > > requirements for your component so that someone knows what they
> > > need to provide to get your working,  the idea here is to make your
> > > component re-usable without needing the source code.
> > >
> > > Then basically we have two projects,  one which is the descriptors
> > > for this components.xml and also a file called assets.xml and the
> > > second is an eclipse plugin that you can install and then register
> > > your components with,  once you have the eclipse plugin installed
> > > in your eclipse you basically can goto preferences in eclipse and
> > > add all the packaged JBI components,  basically those JBI
> > > components with a jbi.xml that are your usual stuff but also with a
> > > components.xml in there.  Once you have registered them you can
> > > create a project and add a file with the extension .jbi,  this will
> > > open the JBI deployer which is basically just a GEF diagramming
> > > component,  however you will see you components (as registered from
> > > your components.xml) in the pallette, if you drop one on the canvas
> > > you will be able to configure the settings (those also defined in
> > > the components.xml) and therefore configure a re-usable JBI
> > > component.  If you component is a service engine you will see
> > > component and be able to press the + button to create service units
> > > inside,  note that in this case you can gather parameters at a
> > > service unit by added parameters etc at the service unit level ie:
> > >
> > > 
> > > 658c0460-7ee0-11da-ba83-0002a5d5c51c > > componentUuid>
> > > Translator
> > > 
> > > Unity's transformation service engine
> > > 
> > > 
> > > 
> > >  > > description="Translator Configuration" />
> > >  > > description="Example parameter"/>
> > >  > > description="Default destination"
> > > mep="robustInOnly" />
> > > 
> > > 
> > > 
> > > 
> > >
> > > Once you have set up your digram as you want it you can right click
> > > on a component or service assembly and choose deploy,  this will
> > > create the component zips by basically exploding the base jar
> > > (which the components.xml) and creating a new component injecting
> > > both the embeddedArtifacts and also the assets (which are the
> > > parameters gathered from the deployment editor),  therefore you
> > > would have META-INF/stored-assets.xml in either your binding-
> > > component or your service unit ie.
> > >
> > > 
> > >   script.groovy > > name>whizbang.groov

Re: Clustering - initial overview doc... - where should we keep it ?

2006-01-18 Thread Rajith Attapattu

Wiki might be a better idea for now so most people can contribute.
 
However if it's under svn then non-comiiters can only contribute via patches.
 
Another possiblity is to have it under the confluence thing that Hernan is working on.
 
Also with wiki there want be issue about the format (wether it's text,html..etc)
 
Whatever works best for the community.
 
Regards,
 
Rajith 
On 1/18/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
I'd say the Wiki if it's pretty open to being changed as we moveforward (which would be my guess) or the geronimo/site SVN if it's
permanent (as in, completely documents 1.0 and is not attempting tocover newer stuff).AaronOn 1/18/06, Jules Gosnell <[EMAIL PROTECTED]> wrote:
> Guys,>> I have the beginnings of this doc...>> Where would be the best place to keep it ? Ideally it should be r/w by> everyone, with history - SVN, WIKI or where ? What is best practice ?
>> Also, if in SVN, what format - text, html, ... etc...>>> Jules>> --> "Open Source is a self-assembling organism. You dangle a piece of> string into a super-saturated solution and a whole operating-system
> crystallises out around it.">> /**>  * Jules Gosnell>  * Partner>  * Core Developers Network (Europe)>  *>  *
www.coredevelopers.net>  *>  * Open Source Training & Support.>  **/>>

Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.

2006-01-18 Thread Rodent of Unusual Size

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jacek Laskowski wrote:
> 
> Am I reading it correctly that in CTR when a committer vetoed a
> commit, it *ought to* be backed out *as soon as it's happened* and
> discussed afterwards before being committed again?

No, the rules for handling a veto don't really change.  The
person who made the commit is generally given a chance to
back it out hirself first.  Someone else reverting it quickly
should only happen if it's egregiously broken and keeping
multiple aspects of development from moving forward.
- --
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist  http://Apache-Server.Com/

"Millennium hand and shrimp!"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQCVAwUBQ85c3prNPMCpn3XdAQIgSAQArMo3zqBGf1HpUGmriSw4GTf+C7EpvOu8
Kel6u8SivOlRz4eFlynbK6TZHRNp+XYCdC/RvO/eP33BXpfly9Q3U/CTtJ0mZP8G
woNvx+6vd25RLD+09lo+hxathvOUp7sJMIhYY4FKTk0PcwHT5nIVuW2PHoPYMTcN
Vzv/kmS+iqI=
=Tu3I
-END PGP SIGNATURE-

[jira] Created: (GERONIMO-1492) Many "org/apache/geronimo" configIds still live in source tree

2006-01-18 Thread Aaron Mulder (JIRA)

Many "org/apache/geronimo" configIds still live in source tree
--

 Key: GERONIMO-1492
 URL: http://issues.apache.org/jira/browse/GERONIMO-1492
 Project: Geronimo
Type: Bug
Versions: 1.0
Reporter: Aaron Mulder
 Fix For: 1.1, 1.0.1


I created a couple separate issues, but beyond those a quick search brought up 
a few more in magic G ball and day trader -- I stopped before it went any 
further, but we should grep for that and try to eliminate all the references to 
old-style config IDs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Clustering - initial overview doc... - where should we keep it ?

I'd say the Wiki if it's pretty open to being changed as we move
forward (which would be my guess) or the geronimo/site SVN if it's
permanent (as in, completely documents 1.0 and is not attempting to
cover newer stuff).

Aaron

On 1/18/06, Jules Gosnell <[EMAIL PROTECTED]> wrote:
> Guys,
>
> I have the beginnings of this doc...
>
> Where would be the best place to keep it ? Ideally it should be r/w by
> everyone, with history - SVN, WIKI or where ? What is best practice ?
>
> Also, if in SVN, what format - text, html, ... etc...
>
>
> Jules
>
> --
> "Open Source is a self-assembling organism. You dangle a piece of
> string into a super-saturated solution and a whole operating-system
> crystallises out around it."
>
> /**
>  * Jules Gosnell
>  * Partner
>  * Core Developers Network (Europe)
>  *
>  *www.coredevelopers.net
>  *
>  * Open Source Training & Support.
>  **/
>
>

[jira] Updated: (GERONIMO-1450) Console usage plans use old namspace & parentId

2006-01-18 Thread Aaron Mulder (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1450?page=all ]

Aaron Mulder updated GERONIMO-1450:
---

Summary: Console usage plans use old namspace & parentId  (was: Console 
usage plans use old namspace)
Description: 
The usage pages in the console show deployment plans, and the namespaces in 
those deployment plans don't have version numbers in them.  It's not disastrous 
as we should convert those, but it'd be much better to fix them.

Also, they have the wrong (o/a/g/Server) parentId, which is disastrous.

  was:The usage pages in the console show deployment plans, and the namespaces 
in those deployment plans don't have version numbers in them.  It's not 
disastrous as we should convert those, but it'd be much better to fix them.

   Priority: Critical  (was: Major)

> Console usage plans use old namspace & parentId
> ---
>
>  Key: GERONIMO-1450
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1450
>  Project: Geronimo
> Type: Bug
>   Components: console, documentation
> Versions: 1.0
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.0.1, 1.1

>
> The usage pages in the console show deployment plans, and the namespaces in 
> those deployment plans don't have version numbers in them.  It's not 
> disastrous as we should convert those, but it'd be much better to fix them.
> Also, they have the wrong (o/a/g/Server) parentId, which is disastrous.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Clustering - initial overview doc... - where should we keep it ?


Guys,

I have the beginnings of this doc...

Where would be the best place to keep it ? Ideally it should be r/w by 
everyone, with history - SVN, WIKI or where ? What is best practice ?


Also, if in SVN, what format - text, html, ... etc...


Jules

--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*www.coredevelopers.net
*
* Open Source Training & Support.
**/

[jira] Created: (GERONIMO-1491) ActiveMQ plan uses hardcoded obsolete org/apache/geronimo/ActiveMQ module name

2006-01-18 Thread Aaron Mulder (JIRA)

ActiveMQ plan uses hardcoded obsolete org/apache/geronimo/ActiveMQ module name
--

 Key: GERONIMO-1491
 URL: http://issues.apache.org/jira/browse/GERONIMO-1491
 Project: Geronimo
Type: Bug
  Components: ActiveMQ  
Versions: 1.0
Reporter: Aaron Mulder
Priority: Critical
 Fix For: 1.0.1, 1.1


See the gbeanName for the connectors in 
https://svn.apache.org/repos/asf/geronimo/tags/1.0.0/configs/activemq-broker/src/plan/plan.xml

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

2006-01-18 Thread Kevan Miller

Presumably in response to Dave's email to Tomcat, the following changes were made to Tomcat samples, yesterday afternoon:	From: 	  [EMAIL PROTECTED]	Subject: 	svn commit: r369933 - in /tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples: cal/cal2.jsp security/protected/index.jsp	Date: 	January 17, 2006 4:52:05 PM EST	To: 	  tomcat-dev@jakarta.apache.org	Reply-To: 	  dev@tomcat.apache.orgAuthor: marktDate: Tue Jan 17 13:52:02 2006New Revision: 369933URL: http://svn.apache.org/viewcvs?rev=369933&view=revLog:Fix XSS issues in examples.Modified:    tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/cal/cal2.jsp    tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jspModified: tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/cal/cal2.jspURL: http://svn.apache.org/viewcvs/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/cal/cal2.jsp?rev=369933&r1=369932&r2=369933&view=diff==--- tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/cal/cal2.jsp (original)+++ tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/cal/cal2.jsp Tue Jan 17 13:52:02 2006@@ -29,12 +29,12 @@  Please add the following event:   Date <%= table.getDate() %>- Time <%= time %> + Time <%= util.HTMLFilter.filter(time) %>   - +    Description of the event     Modified: tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jspURL: http://svn.apache.org/viewcvs/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp?rev=369933&r1=369932&r2=369933&view=diff==--- tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp (original)+++ tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr152/examples/security/protected/index.jsp Tue Jan 17 13:52:02 2006@@ -49,11 +49,13 @@   if (role.length() > 0) {     if (request.isUserInRole(role)) { %>-      You have been granted role <%= role %>+      You have been granted role+      <%= util.HTMLFilter.filter(role) %> <%     } else { %>-      You have not been granted role <%= role %>+      You have not been granted role+      <%= util.HTMLFilter.filter(role) %> <%     }   }@@ -62,7 +64,7 @@ To check whether your username has been granted a particular role, enter it here: -+  -To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]	From: 	  [EMAIL PROTECTED]	Subject: 	svn commit: r369934 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml	Date: 	January 17, 2006 4:53:04 PM EST	To: 	  tomcat-dev@jakarta.apache.org	Reply-To: 	  dev@tomcat.apache.orgAuthor: marktDate: Tue Jan 17 13:53:01 2006New Revision: 369934URL: http://svn.apache.org/viewcvs?rev=369934&view=revLog:Update changelog.Modified:    tomcat/container/tc5.5.x/webapps/docs/changelog.xmlModified: tomcat/container/tc5.5.x/webapps/docs/changelog.xmlURL: http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=369934&r1=369933&r2=369934&view=diff==--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Jan 17 13:53:01 2006@@ -76,6 +76,13 @@               +  +    +      +        Fix some XSS issues in the JSP examples. (markt)+      +    +    -To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]	From: 	  [EMAIL PROTECTED]	Subject: 	svn commit: r369935 - in /tomcat/container/branches/tc4.1.x/webapps/examples/jsp: cal/cal2.jsp security/protected/index.jsp	Date: 	January 17, 2006 4:53:53 PM EST	To: 	  tomcat-dev@jakarta.apache.org	Reply-To: 	  dev@tomcat.apache.orgAuthor: marktDate: Tue Jan 17 13:53:49 2006New Revision: 369935URL: http://svn.apache.org/viewcvs?rev=369935&view=revLog:Fix XSS issues in examples.Modified:    tomcat/container/branches/tc4.1.x/webapps/examples/jsp/cal/cal2.jsp    tomcat/container/branches/tc4.1.x/webapps/examples/jsp/security/protected/index.jspModified: tomcat/container/branches/tc4.1.x/webapps/examples/jsp/cal/cal2.jspURL: http://svn.apache.org/viewcvs/tomcat/container/branches/tc4.1.x/webapps/examples/jsp/cal/cal2.jsp?rev=369935&r1=369934&r2=369935&view=diff==--- tomcat/container/branches/tc4.1.x/webapps/examples/jsp/cal/cal2.jsp (original)+++ tomcat/container/branches/tc4.1.x/webapps/examples/jsp/cal/cal2.jsp Tue Jan 17 13:53:49 2006@@ -18,12 +18,12 @@  Please add the following event:   Date <%= table.getDate() %>- Time <%= time %> + Time <%= util.HTMLFilter.filter(time) %>   - +    Description of the event     Modified: tomcat/container/branches/tc4.1.x/webapps/examp

Re: Build Failure

2006-01-18 Thread Kevan Miller



On Jan 18, 2006, at 4:46 AM, Ryan Thomas wrote:


Hi David,

I gave that a go and I had the dependencies in my project.xml file.  
Manually updated cvs and ran maven, only to get the same error.


Where about's would this file be in my repo (and what file is it?)?  
I'm new to maven - hence the q's!



Ryan,
look in ~/.maven/repository/geronimo-spec/jars/geronimo-spec- 
corba-2.3-rc4.jar for the file.


I'm a little curious about the problem you're having. In your  
original post, you reported the following errors:


Ryan Thomas wrote:


Hey,
I've seen this in the archives and on google but I couldn't find a   
solution for it.
When building on my powerbook (jdk 1.4.2) I get the following  
error  (from the 'maven new' command).

Anyone got any ideas?
Maven Output:
[javac] Compiling 638 source files to /Users/ryan/dev/geronimo/  
openejb/modules/core/target/classes
[javac] /Users/ryan/dev/geronimo/openejb/modules/core/src/java/  
org/openejb/corba/MinorCodes.java:47: package   
com.sun.corba.se.internal.orbutil does not exist

[javac] import com.sun.corba.se.internal.orbutil.ORBConstants;
[javac]  ^
[javac] /Users/ryan/dev/geronimo/openejb/modules/core/src/java/  
org/openejb/corba/security/ClientSecurityInterceptor.java:54:  
cannot  find symbol

[javac] symbol  : class TAG_CSI_SEC_MECH_LIST
[javac] location: package org.omg.IOP
[javac] import org.omg.IOP.TAG_CSI_SEC_MECH_LIST;


ORBConstants should be in your JRE classes.jar (e.g. /System/Library/ 
Frameworks/JavaVM.framework/Versions/1.4.2/Classes/classes.jar). Are  
you sure Java 1.4.2 is being used by Maven?)


Your other errors are consistent with the build error described by  
Matt and David.


--kevan

Re: Fw: geronimo 1.0 - CSS vulnerabilities

2006-01-18 Thread Joe Bohn


I had an off-line discussion with Paul McMahan on this topic.

Our thoughts were that it is probably best to fix this problem in both 
places if possible.  The container fix seems best for not only the 
console but also other uses ... but it is outside of our control and may 
not be accepted by all containers we might support.  Hence, Paul is 
working on a solution for the portlet itself.  We will continue to 
pursue this with the container teams as well but we will ensure the 
safety for 1.0.1 in our portlet.


Joe

Matt Hogstrom wrote:
I think the Portlet is the right place to do this.  That way the user is 
protected from broken containers (of which we currently have 2).


John Sisson wrote:


Paul McMahan wrote:

Either approach should work but I would prefer to address the 
vulnerability in the log viewer portlet because it attaches the 
solution closest to where the specific problem is at.  Also, the 
logger will be called on every request and doing the extra string 
manipulations could affect the web container's throughput.


Best wishes,
Paul


This reflects my sentiments as well.

John



On 1/17/06, *Joe Bohn* <[EMAIL PROTECTED] 
> wrote:


Yes, this sounds like the best way to go.

Regarding the specific problem with the web console displaying 
the web
access log I'd like to get some consensus.  Is this something 
that the
containers should modify when storing the URL as part of a 
message in

the appropriate web log?  (I have confirmed this is a problem with
both
Tomcat and Jetty)

Or, should we address this within the web access log viewer and/or
management objects to modify the content of the log records when 
they

are being displayed.

My preference would be to make the modification at the time the log
record is created.

Joe













--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Build level for Geronimo and version info for dependency projects

2006-01-18 Thread Vamsavardhana Reddy

Hi,

I see that there is a ServerInfo interface in
org.apache.geronimo.system.serverinfo package.  This has
getVersion(), getBuildDate(), getBuildTime(), getBaseDirectory(),
getCopyright() methods.  Is there any other information (like the
svn revision for the server build, etc.) about the server that can be
retrieved programmatically.  Is there a way to determine the
version and build levels of each of the dependency projects like
OpenEJB, Tomcat, Jetty etc?

Thanks,
Vamsi

Re: login service refactoring


[EMAIL PROTECTED] wrote, On 1/17/2006 7:50 AM:

I started refactoring login service along the lines discussed with Alan, David, 
and others at the apachecon. This includes simplifying login service, and 
authentication by assertion, delegation principals. David J, I know that you 
want pluggable api, have you already done some work on it?


This is great Simon!  Can you post a little more detail on how this 
would work?  If you can, put more detail on what the application 
developer would see in terms of how Geronimo would be configured and how 
application would be written to use the service.



Regards,
Alan

Re: Fw: geronimo 1.0 - CSS vulnerabilities - response from Tomcat team

2006-01-18 Thread Dave Colasurdo

Concerning the CSS vulnerability, attached is my correspondence with the 
Tomcat team..

My original email**

 Original Message 
Subject: Possible Security exposure with Tomcat 5.5.15-beta
Date: Tue, 17 Jan 2006 14:46:06 -0500
From: Dave Colasurdo <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED],  [EMAIL PROTECTED]
CC: Kevan Miller <[EMAIL PROTECTED]>,  Jeff Genender
<[EMAIL PROTECTED]>

It appears a security exposure was detected in Geronimo v1 that seems to
be tracked back to to the Tomcat Container/Tomcat jsp-examples..

Specifically, hitting the following url seems to expose a vulnerability..

http://localhost:8080/jsp-examples/cal/cal2.jsp?time="/>alert('Gotcha')

It seems the vulnerability exists in Tomcat versions (5.5.9, 5.5.12 and
5.5.15-beta)..  though is not present in Tomcat 5.5.7..

BTW, It seems this problem was present prior to TC 5.5.7 and was fixed
in 5.5.7..  Perhaps it somehow was regressed.

Is a fix for this problem something that would be considered for
inclusion in Tomcat 5.5.15?  If so, would the fix be to the overall
container or to jsp-examples?

Thanks
-Dave-

*Clarification email**

 Original Message 
Subject: [Fwd: Possible Security exposure with Tomcat 5.5.15-beta]
Date: Tue, 17 Jan 2006 16:08:29 -0500
From: Dave Colasurdo <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED],  [EMAIL PROTECTED]
CC: [EMAIL PROTECTED],  [EMAIL PROTECTED]

One small correction.  I am seeing the same exposure in Tomcat 5.5.7..

-Dave-

***The response from the Tomcat team**

Dave,
Thank you for reporting this security issue.  We have analyzed the
issue and concluded that:

- It is only present in this example JSP,
- We already recommend users remove the examples and other unnecessary
webapps when they go to production, a fairly common procedure which
acts as a workaround for this problem,
- The issue was not fixed in 5.5.7, as you noted later, so this is not
a regression bug.  Similar issues were indeed fixed in 5.5.7, but not
this one,
- So we do not think the issue is critical.

The issue has been fixed in SVN and the fix will be available starting
with release 5.5.16.  However, because we don't think it's critical,
and because the workaround is already part of the common production
deployment scenario, we still plan to call 5.5.15 a stable release.

Thanks again,

Yoav (on behalf of the Tomcat team)

[jira] Commented: (GERONIMO-1482) Add CORBA spec version 3.0

2006-01-18 Thread Anders Hessellund Jensen (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-1482?page=comments#action_12363097
 ] 

Anders Hessellund Jensen commented on GERONIMO-1482:


Alan,

Some JAVA files cannot be generated from IDL. Those files usually come with the 
runtime environment. The files SUN provides with JDK 1.4.2 is really old 
(version 2.3.1). Thats why we did not need them in the old spec.

> Add CORBA spec version 3.0
> --
>
>  Key: GERONIMO-1482
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1482
>  Project: Geronimo
> Type: Task
>   Components: CORBA
> Reporter: Anders Hessellund Jensen
> Assignee: Alan Cabrera
>  Attachments: geronimo-spec-corba-3.0.zip
>
> I have created a 3.0 version of the CORBA spec. It is java / IDL files from 
> OMG with some modifications. 
> Consider where to put it. I suppose the sandbox would be most appropriate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: WADI clustering

Jules Gosnell wrote:

Oh Rajith - you've got me thinking :-(

I'm not happy with the last answer - lets try again

lets agree some points :

1) since changes made to sessions are made in app-space, apps are not 
written with the expectation that a change collision may occur and the 
container would not be able to avoid such a collision, it must never 
happen.

2) in order for a change-collision to occur multiple concurrent 
requests/invocations must hit multiple copies of the session

In the web world, clients commonly throw multiple concurrent requests 
at clusters, however, if we could assure total affinity, these would 
always arrive at the same copy, avoiding the chance of a collision. 
There are various situations within the web tier that may cause the 
breakdown of affinity. Different loadbalancers handle these situations 
with varying degrees of correctness. I have decided that it is safer 
to assume that, whilst affinity is a substantial optimisation, it 
cannot be relied on 100%.

So, in the web tier, it is possible for concurrent requests for the 
same session to arrive at different session copies. So we need a 
pessimistic distributed locking strategy to ensure that collisions do 
not occur.

In the EJB world, we have more control over the load-balancer, because 
it is effectively built into the proxy  that we supplied, and we could 
enforce the serial nature of invocations at this point. So it might be 
possible to move forward on the assumption that we don't need 
pessimistic locking (provided that no-one ever passes a session handle 
to another client).

I'm going to give this a little more thought...

I think the outcome will be that I can avoid some locking in the EJB 
world, but need to send the same messages anyway... but we'll see.

Thanks for getting me to revisit this,

BTW - if we do assume that we can rely on affinity 100% in the EJB tier 
then I am still not sure that I see any real advantage in holding 
multiple active copies of a session. I guess you will have to explain to 
me exactly why you would want to do this.

Finally, the locking system that WADI currently uses will only incur 
extra work, taking distributed locks, if affinity breaks down, so the 
cost of applying it to the SFSBs where, we hope for 100% affinity, 
should be 0.

Jules

Jules

Jules Gosnell wrote:

Rajith Attapattu wrote:

More question if you don't mind.

> 2.) Assuming sombody wants to do session replication (All

> Active) instead of (one Active and "n" backups) is there provision
> within the WADI api to plug in this stratergy?

>I'm giving this some thought in terms of SFSB support, I'm not 
aware of

>similar constraints in the EJB world...

>I guess we could relax this constraint in the web world, but I am not
>sure that I think that this is a good idea. Can you see a way to do 
this

>and maintain spec compliance and performance ?
Is WADI designed primarily for Web?? (bcos u talked about being 
servlet spec compliant) and u also mention about SFSB support.

WADI was initially designed for the web - because I saw the issues 
surrounding HttpSession distribution, particularly the requirement 
for a single 'active' session as unresolved in any open source 
offering and I thought it was about time that there was a truly 
compliant solution.

It soon became clear that many of the problems faced by sessions in 
the web-tier were also faced by sessions in the EJB-tier...

Can we abstract the Replication problem to a more higher level and 
have the two (or more if there is) stratergies as impls of the 
replication API that installs as a pluggin by the user.

Well, we could, but you would have to convince me that SFSBs would 
benefit from a 'multiple-active-sessions' approach... I haven't given 
it much thought, but I don't see any advantage - bear with me :

- in the EJB world, we own the client side proxy. We can impose 
strict affinity. An invocation arriving at a node that is not 
carrying the primary session copy will be an exceptional occurance.

- If you go with the 'single-active-session' model, and an invocation 
does land on a secondary, you then pay an exceptional cost - 
deserialisation and promotion (messaging) from secondary to primary. 
This is OK, since you are in an exceptional situation.

- If you go with the 'multiple-active-sessions' approach you have two 
choices regarding deserialisation of replication messages.

1) you can deserialise them as they arrive - bad idea, because 
deserialisation is extremely expensive and most of the time these 
copies will never be used.
2) you can deserialise them lazily - only bother to do the work, 
if/when an invocation arises.

Regardless of which you choose (and I hope you would choose 2), you 
are now in a situation where two copies of a session may diverge from 
each other. Lets say you make a change to one, then you make a change 
to the other, but the replication message from the first session 
arrives at the seco

Re: WADI clustering

Oh Rajith - you've got me thinking :-(

I'm not happy with the last answer - lets try again

lets agree some points :

1) since changes made to sessions are made in app-space, apps are not 
written with the expectation that a change collision may occur and the 
container would not be able to avoid such a collision, it must never happen.

2) in order for a change-collision to occur multiple concurrent 
requests/invocations must hit multiple copies of the session

In the web world, clients commonly throw multiple concurrent requests at 
clusters, however, if we could assure total affinity, these would always 
arrive at the same copy, avoiding the chance of a collision. There are 
various situations within the web tier that may cause the breakdown of 
affinity. Different loadbalancers handle these situations with varying 
degrees of correctness. I have decided that it is safer to assume that, 
whilst affinity is a substantial optimisation, it cannot be relied on 100%.

So, in the web tier, it is possible for concurrent requests for the same 
session to arrive at different session copies. So we need a pessimistic 
distributed locking strategy to ensure that collisions do not occur.

In the EJB world, we have more control over the load-balancer, because 
it is effectively built into the proxy  that we supplied, and we could 
enforce the serial nature of invocations at this point. So it might be 
possible to move forward on the assumption that we don't need 
pessimistic locking (provided that no-one ever passes a session handle 
to another client).

I'm going to give this a little more thought...

I think the outcome will be that I can avoid some locking in the EJB 
world, but need to send the same messages anyway... but we'll see.

Thanks for getting me to revisit this,

Jules

Jules Gosnell wrote:

Rajith Attapattu wrote:

More question if you don't mind.

> 2.) Assuming sombody wants to do session replication (All

> Active) instead of (one Active and "n" backups) is there provision
> within the WADI api to plug in this stratergy?

>I'm giving this some thought in terms of SFSB support, I'm not aware of
>similar constraints in the EJB world...

>I guess we could relax this constraint in the web world, but I am not
>sure that I think that this is a good idea. Can you see a way to do 
this

>and maintain spec compliance and performance ?
Is WADI designed primarily for Web?? (bcos u talked about being 
servlet spec compliant) and u also mention about SFSB support.

WADI was initially designed for the web - because I saw the issues 
surrounding HttpSession distribution, particularly the requirement for 
a single 'active' session as unresolved in any open source offering 
and I thought it was about time that there was a truly compliant 
solution.

It soon became clear that many of the problems faced by sessions in 
the web-tier were also faced by sessions in the EJB-tier...

Can we abstract the Replication problem to a more higher level and 
have the two (or more if there is) stratergies as impls of the 
replication API that installs as a pluggin by the user.

Well, we could, but you would have to convince me that SFSBs would 
benefit from a 'multiple-active-sessions' approach... I haven't given 
it much thought, but I don't see any advantage - bear with me :

- in the EJB world, we own the client side proxy. We can impose strict 
affinity. An invocation arriving at a node that is not carrying the 
primary session copy will be an exceptional occurance.

- If you go with the 'single-active-session' model, and an invocation 
does land on a secondary, you then pay an exceptional cost - 
deserialisation and promotion (messaging) from secondary to primary. 
This is OK, since you are in an exceptional situation.

- If you go with the 'multiple-active-sessions' approach you have two 
choices regarding deserialisation of replication messages.

1) you can deserialise them as they arrive - bad idea, because 
deserialisation is extremely expensive and most of the time these 
copies will never be used.
2) you can deserialise them lazily - only bother to do the work, 
if/when an invocation arises.

Regardless of which you choose (and I hope you would choose 2), you 
are now in a situation where two copies of a session may diverge from 
each other. Lets say you make a change to one, then you make a change 
to the other, but the replication message from the first session 
arrives at the second session after your second change and wipes it 
out, and the replication message from your second change then 
overwrites the first session with what is now a different value than 
that carried by the second you can detect these issues by 
versioning, but the best way to protect against them occuring (see 
reasons for needing a pessimistic algorithm below) is by having some 
form of distributed locking. In effect, the guy with the lock is the 
primary and the guy without it the secondary.

OK, so now we have

Re: WADI clustering

Rajith Attapattu wrote:

More question if you don't mind.

> 2.) Assuming sombody wants to do session replication (All

> Active) instead of (one Active and "n" backups) is there provision
> within the WADI api to plug in this stratergy?

>I'm giving this some thought in terms of SFSB support, I'm not aware of
>similar constraints in the EJB world...

>I guess we could relax this constraint in the web world, but I am not
>sure that I think that this is a good idea. Can you see a way to do this
>and maintain spec compliance and performance ?
Is WADI designed primarily for Web?? (bcos u talked about being 
servlet spec compliant) and u also mention about SFSB support.

WADI was initially designed for the web - because I saw the issues 
surrounding HttpSession distribution, particularly the requirement for a 
single 'active' session as unresolved in any open source offering and I 
thought it was about time that there was a truly compliant solution.

It soon became clear that many of the problems faced by sessions in the 
web-tier were also faced by sessions in the EJB-tier...

Can we abstract the Replication problem to a more higher level and 
have the two (or more if there is) stratergies as impls of the 
replication API that installs as a pluggin by the user.

Well, we could, but you would have to convince me that SFSBs would 
benefit from a 'multiple-active-sessions' approach... I haven't given it 
much thought, but I don't see any advantage - bear with me :

- in the EJB world, we own the client side proxy. We can impose strict 
affinity. An invocation arriving at a node that is not carrying the 
primary session copy will be an exceptional occurance.

- If you go with the 'single-active-session' model, and an invocation 
does land on a secondary, you then pay an exceptional cost - 
deserialisation and promotion (messaging) from secondary to primary. 
This is OK, since you are in an exceptional situation.

- If you go with the 'multiple-active-sessions' approach you have two 
choices regarding deserialisation of replication messages.

1) you can deserialise them as they arrive - bad idea, because 
deserialisation is extremely expensive and most of the time these copies 
will never be used.
2) you can deserialise them lazily - only bother to do the work, if/when 
an invocation arises.

Regardless of which you choose (and I hope you would choose 2), you are 
now in a situation where two copies of a session may diverge from each 
other. Lets say you make a change to one, then you make a change to the 
other, but the replication message from the first session arrives at the 
second session after your second change and wipes it out, and the 
replication message from your second change then overwrites the first 
session with what is now a different value than that carried by the 
second you can detect these issues by versioning, but the best way 
to protect against them occuring (see reasons for needing a pessimistic 
algorithm below) is by having some form of distributed locking. In 
effect, the guy with the lock is the primary and the guy without it the 
secondary.

OK, so now we have a working 'multiple-active-sessions' model - but hold 
on, it is doing lazy deserialisation and distributed locking - it looks 
very like the 'single-active-session' model

Does that help ?

We can abstract things like a ReplicationManager that handles/controls 
no of replicas etc.. and a ReplicatedSession which decides wether it's 
active or passive (backup) based on the parameters passed to the 
ReplicatedSessionFactory at create time from the ReplicationManager.

sure - and all of these things are already pluggable in WADI.

The ReplicationManager impl could be the stratergy that decides wether 
it maintains n of active replicas or 1 active and n backups or any 
other stratergy.

Yes it could - but I think that this is still being driven by your 
attachment to the multiple-active-sessions model and I do not see that 
as viable.

Also the ReplicatedSession could impl stratergies like in 
MemoryReplication or PassiveReplication (based on active or passive) 
or anything else. And PassiveReplication can be extended to file 
based, database backed (not recomended) or anything else.

WADI's replication strategy is already pluggable. We have a basic DB 
replication scheme and are working on the in-vm scheme. Other schemes 
could easily be added.

If we open up the API and let the user choose the stratergy they want 
then we are delaying our concerns to the user level and allow them to 
make the decesion.
I am sure we cannot address every situation, and the user is the best 
to judge about there env.

But we can always provide some sensible stratergies and recomendations 
and use cases around them to make an informed decesion.

Then We can leave the decesion to the user about 
spec-complient/performance.

What do u think??

Unless you can demonstrate a clear win for a strategy that is 
non-compli

Re: Virtual Hosts

2006-01-18 Thread Greg Wilkins

Jeff Genender wrote:

> I don't really see the disconnect between what you are saying,

there isn't - we are in strenuous agreement :-)

Re: WADI clustering

2006-01-18 Thread Gianny Damour

Rajith Attapattu wrote:

More question if you don't mind.

> 2.) Assuming sombody wants to do session replication (All

> Active) instead of (one Active and "n" backups) is there provision
> within the WADI api to plug in this stratergy?

>I'm giving this some thought in terms of SFSB support, I'm not aware of
>similar constraints in the EJB world...

>I guess we could relax this constraint in the web world, but I am not
>sure that I think that this is a good idea. Can you see a way to do this
>and maintain spec compliance and performance ?
Is WADI designed primarily for Web?? (bcos u talked about being 
servlet spec compliant) and u also mention about SFSB support.
Can we abstract the Replication problem to a more higher level and 
have the two (or more if there is) stratergies as impls of the 
replication API that installs as a pluggin by the user.

We can abstract things like a ReplicationManager that handles/controls 
no of replicas etc.. and a ReplicatedSession which decides wether it's 
active or passive (backup) based on the parameters passed to the 
ReplicatedSessionFactory at create time from the ReplicationManager.

This is a very good idea. A ReplicationManager could provide the 
management of replicas: we feed it a "primary" object; it delegates to a 
BackingStrategy the selection of backing storages, i.e. location and 
type of back-ups; and feeds to the selected ReplicaStorage a copy of the 
object to be replicated.

As previously stated by Jules, the BackingStrategy chooses the backing 
storages based on deployment characteristics, e.g. a storage hosted by a 
distinct physical box than the one hosting the "primary" object is 
preferred to a storage hosted on the same physical box than the "primary".

Also, the ReplicationManager could provide some ways to re-organize the 
backing storages, when a session has been migrated from one node to 
another. It notifies the other ReplicationManager hosted by each node of 
the cluster and instructs them that it is becoming the "primary" host of 
a replicated object (this object is uniquely identified by a key 
somehow). The ReplicationManager, which is currently the primary of this 
replicated object, releases the primary and replies back that the 
backing storages are hosted there, there and there. The new "primary" 
host requests to the BackingStrategy to re-assess the backing storages 
based on the new situation: I am now the "primary" host and the current 
backing storages are there.

The ReplicationManager impl could be the stratergy that decides wether 
it maintains n of active replicas or 1 active and n backups or any 
other stratergy.

Also the ReplicatedSession could impl stratergies like in 
MemoryReplication or PassiveReplication (based on active or passive) 
or anything else. And PassiveReplication can be extended to file 
based, database backed (not recomended) or anything else.

In the above scheme, the ReplicaStorage implements these memory, file or 
database strategies.

Does that sound reasonable?

Thanks,
Gianny

If we open up the API and let the user choose the stratergy they want 
then we are delaying our concerns to the user level and allow them to 
make the decesion.
I am sure we cannot address every situation, and the user is the best 
to judge about there env.

But we can always provide some sensible stratergies and recomendations 
and use cases around them to make an informed decesion.

Then We can leave the decesion to the user about 
spec-complient/performance.

What do u think??

>If a request arrives at a secondary, primary and secondary swap roles

>and processing happens locally.
>If a request arrives on a node with no copy of the relevant session, it
>may be relocated to the primary, or the primary to it.

1. Do u plan to have an abstraction around the above concerns as well??
So we can have impls of different stratergies, So people can 
decide wether they want to relocate the primary or the request.

In case of a relocation of either request or session I assume u 
have hidden the impls behind an interface/API sort of thing so ppl can 
do different impls of the same stratergies or impl their own stratergy.

2. In the event of a primary and secondary swapping roles or having n 
of active replicas don't we need some sort of distributed locking 
mechanism.
I heard that in memory locking should be optimistic and storage backed 
replicas should be pessimistic locking.

I hope I haven't got the too mixed up :)

Can u please touch on this problem as my knoweldge is limited on this 
area.

Regards,

Rajith.

On 1/17/06, *Jules Gosnell* <[EMAIL PROTECTED] 
> wrote:

Rajith Attapattu wrote:

>
>  Hi,
>
> Some of these questions came up after reading the thread on totem.
> However I started the new thread so that searching is easy and also
> want distract the intense discussions on totem with out-of-topic
> questions.
>
> Jules Go

[jira] Closed: (GERONIMO-1463) Tomcat doesn't always get the right servlet name when evaluating isUserInRole

 [ http://issues.apache.org/jira/browse/GERONIMO-1463?page=all ]
 
John Sisson closed GERONIMO-1463:
-

Resolution: Fixed

> Tomcat doesn't always get the right servlet name when evaluating isUserInRole
> -
>
>  Key: GERONIMO-1463
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1463
>  Project: Geronimo
> Type: Bug
>   Components: Tomcat
> Versions: 1.0
> Reporter: David Jencks
> Assignee: John Sisson
>  Fix For: 1.1, 1.0.1

>
> TomcatGeronimoRealm has a complicated way of trying to determine the servlet 
> name by resolving the context path.  Unfortunately it doesn't work very well. 
>  However, the servlet name is available from request.getWrapper.getName().  
> The wrapper in question wraps the servlet, not the request, so it should 
> always be available.
> In addition, the current code only sets the request on a thread local when 
> you access a secured page.  However there seems to be agreement that access 
> to unsecured pages after you have logged on should still have the Subject 
> available and give "logged in" answers to isUserInRole.  Therefore we have to 
> set the request when accessing any page.  Moving the setting to 
> PolicycontextValve should suffice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Build Failure

2006-01-18 Thread Ryan Thomas

Hi David,

I gave that a go and I had the dependencies in my project.xml file.  
Manually updated cvs and ran maven, only to get the same error.

Where about's would this file be in my repo (and what file is it?)?  
I'm new to maven - hence the q's!

Cheers,

-Ryan

On 18/01/2006, at 7:45 PM, David Jencks wrote:

Hmm, it worked on my laptop :-)

I find the m:xxx goals aren't always reliable.  Can you try
cd openejb
cvs -q up -dP
grep geronimo-spec-corba modules/core/project.xml
#you should see:  geronimo-spec-corbaartifactId>

#or look on line 145 and you should see:

  geronimo-spec
  geronimo-spec-corba
  2.3-rc4

   true

This jar contains the missing classes.  You might try building just  
the core module:

cd modules/core
maven

If you have already downloaded this jar and still get the error try  
deleting it from your local maven repo and re-downloading, perhaps  
it is corrupted.  If this still doesn't help check that the missing  
classes are indeed in the jar in the correct package.

Hope this helps.

thanks
david jencks

On Jan 17, 2006, at 11:33 PM, Ryan Thomas wrote:

Hey Guys,

Gave it a try and I ended up with the same error (this was after  
the maven m:fresh-checkout).

Any further idea's, or can't I build it on this machine?

Cheers,

-Ryan

On 18/01/2006, at 3:45 PM, Ryan Thomas wrote:

Thanks guys,

I'll give it a go when I get home from work (~2 hours).

Cheers,

-Ryan

On 1/18/06, David Jencks < [EMAIL PROTECTED]> wrote:We  
should always test first before replying :-)

You seem to be the first to discover that the build was broken after
a change at around 10:00 PM last night.  Thanks for reporting this
and we are trying to figure out the best way to fix it.

thanks
david jencks

On Jan 17, 2006, at 2:26 AM, Ryan Thomas wrote:

> Hey,
>
> I've seen this in the archives and on google but I couldn't find a
> solution for it.
>
> When building on my powerbook (jdk 1.4.2) I get the following  
error

> (from the 'maven new' command).
>
> Anyone got any ideas?
>
> Maven Output:
> [javac] Compiling 638 source files to /Users/ryan/dev/ 
geronimo/

> openejb/modules/core/target/classes
> [javac] /Users/ryan/dev/geronimo/openejb/modules/core/src/ 
java/

> org/openejb/corba/MinorCodes.java:47: package
> com.sun.corba.se.internal.orbutil does not exist
> [javac] import  
com.sun.corba.se.internal.orbutil.ORBConstants ;

> [javac]  ^
> [javac] /Users/ryan/dev/geronimo/openejb/modules/core/src/ 
java/

> org/openejb/corba/security/ClientSecurityInterceptor.java:54:
> cannot find symbol
> [javac] symbol  : class TAG_CSI_SEC_MECH_LIST
> [javac] location: package org.omg.IOP
> [javac] import org.omg.IOP.TAG_CSI_SEC_MECH_LIST;
>
> java -version output:
> java version " 1.4.2_09"
> Java(TM) 2 Runtime Environment, Standard Edition (build  
1.4.2_09-232)

> Java HotSpot(TM) Client VM (build 1.4.2-54, mixed mode)
>
> Cheers,
>
> Ryan Thomas

--
Ryan Thomas
[EMAIL PROTECTED]

[jira] Created: (GERONIMO-1490) setjavaenv.bat is not called by deploy.bat

setjavaenv.bat is not called by deploy.bat
--

 Key: GERONIMO-1490
 URL: http://issues.apache.org/jira/browse/GERONIMO-1490
 Project: Geronimo
Type: Bug
  Components: startup/shutdown  
Versions: 1.0
Reporter: John Sisson
 Assigned to: John Sisson 
Priority: Trivial
 Fix For: 1.1, 1.0.1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Replication using totem protocol


lichtner wrote:


On Tue, 17 Jan 2006, Jules Gosnell wrote:

 


just when you thought that this thread would die :-)
   



I think Jeff Genender wanted a discussion to be sparked, and it worked.

 


So, I am wondering how might I use e.g. a shared disc or majority voting
in this situation ? In order to decide which fragment was the original
cluster and which was the piece that had broken off ? but then what
would the piece that had broken off do ? shutdown ?
   



Wait to rejoin the cluster. Since it is not "the" cluster, it waits. It is
not safe to make any updates.

 


_How_ a groups decides it is "the" cluster can be done in several ways.
Shared-disk cluster can do by a locking operation on a disk (I would have
to research the details on this), a cluster with a database can get a lock
from the database (and keep the connection open). And one way to do this
in a shared-nothing cluster is to use a quorum of N/2 + 1, where is the
maximum number of nodes. Clearly it has to be the majority or else you can
have a split-brain cluster.
 

I haven't been able to convince myself to take the quorum approach 
because...


shared-something approach:
- the shared something is a Single Point of Failure (SPoF) - although 
you could use an HA something.
- If the node holding the lock 'goes crazy', but does not die, the rest 
of the cluster becomes a fragment - so it becomes an SPoF as well.
- used in isolation, it does not take into account that the lock may be 
held by the smallest cluster fragment


shared-nothing approach:
- I prefer this approach, but, as you have stated, if the two halves are 
equally sized...

- What if there are two concurrent fractures (does this happen?)
- ActiveCluster notifies you of one membership change at a time - so you 
would have to decide on an algorithm for 'chunking' node loss, so that 
you could decide when a fragmentation had occurred...


perhaps a hybrid of the two would be able to cover more bases... - 
shared-nothing falling back to shared-something if your fragment is 
sized N/2.


As far as my plans for WADI, I think I am happy to stick with the, 'rely 
on affinity and keep going' approach.


As far as situations where a distributed object may have more than one 
client, I can see that quorum offers the hope of a solution, but, 
without some very careful thought, I would still be hesitant to stake my 
shirt on it :-) for the reasons given above...


I hadn't really considered 'pausing' a cluster fragment, so this is a 
useful idea. I guess that I have been thinking more in terms of 
long-lived fractures, rather than short-lived ones. If the latter are 
that much more common, then this is great input and I need to take it 
into account.


The issue about 'chunking' node loss interests me... I see that the 
EVS4J Listener returns a set of members, so it is possible to express 
the loss of more than one node. How is membership decided and node loss 
aggregated ?


Thanks again for your time,


Jules

 


Do you think that we need to worry about situations where a piece of
state has more than one client, so a network partition may result in two
copies diverging in different and incompatible directions, rather than
only one diverging.
   



If you use a quorum or quorum-resource as above you do not have this
problem. You can turn down the requests or let them block until the
cluster re-discovers the 'failed' nodes.

 


I can imagine this happening in an Entity Bean (but
we should be able to use the DB to resolve this) or an application POJO.
I haven't considered the latter case and it looks pretty hopeless to me,
unless you have some alternative route over which the two fragments can
communicate... but then, if you did, would you not pair it with your
original network, so that the one failed over to the other or replicated
its activity, so that you never perceived a split in the first place ?
Is this a common solution, or do people use other mechanisms here ?
   



I do believe that membership and quorum is all you need.

Guglielmo
 




--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

/**
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
*www.coredevelopers.net
*
* Open Source Training & Support.
**/

Re: Build Failure

Hmm, it worked on my laptop :-)

I find the m:xxx goals aren't always reliable.  Can you try
cd openejb
cvs -q up -dP
grep geronimo-spec-corba modules/core/project.xml
#you should see:  geronimo-spec-corbaartifactId>

#or look on line 145 and you should see:

  geronimo-spec
  geronimo-spec-corba
  2.3-rc4

   true

This jar contains the missing classes.  You might try building just  
the core module:

cd modules/core
maven

If you have already downloaded this jar and still get the error try  
deleting it from your local maven repo and re-downloading, perhaps it  
is corrupted.  If this still doesn't help check that the missing  
classes are indeed in the jar in the correct package.

Hope this helps.

thanks
david jencks

On Jan 17, 2006, at 11:33 PM, Ryan Thomas wrote:

Hey Guys,

Gave it a try and I ended up with the same error (this was after  
the maven m:fresh-checkout).

Any further idea's, or can't I build it on this machine?

Cheers,

-Ryan

On 18/01/2006, at 3:45 PM, Ryan Thomas wrote:

Thanks guys,

I'll give it a go when I get home from work (~2 hours).

Cheers,

-Ryan

On 1/18/06, David Jencks < [EMAIL PROTECTED]> wrote:We should  
always test first before replying :-)

You seem to be the first to discover that the build was broken after
a change at around 10:00 PM last night.  Thanks for reporting this
and we are trying to figure out the best way to fix it.

thanks
david jencks

On Jan 17, 2006, at 2:26 AM, Ryan Thomas wrote:

> Hey,
>
> I've seen this in the archives and on google but I couldn't find a
> solution for it.
>
> When building on my powerbook (jdk 1.4.2) I get the following error
> (from the 'maven new' command).
>
> Anyone got any ideas?
>
> Maven Output:
> [javac] Compiling 638 source files to /Users/ryan/dev/geronimo/
> openejb/modules/core/target/classes
> [javac] /Users/ryan/dev/geronimo/openejb/modules/core/src/java/
> org/openejb/corba/MinorCodes.java:47: package
> com.sun.corba.se.internal.orbutil does not exist
> [javac] import com.sun.corba.se.internal.orbutil.ORBConstants ;
> [javac]  ^
> [javac] /Users/ryan/dev/geronimo/openejb/modules/core/src/java/
> org/openejb/corba/security/ClientSecurityInterceptor.java:54:
> cannot find symbol
> [javac] symbol  : class TAG_CSI_SEC_MECH_LIST
> [javac] location: package org.omg.IOP
> [javac] import org.omg.IOP.TAG_CSI_SEC_MECH_LIST;
>
> java -version output:
> java version " 1.4.2_09"
> Java(TM) 2 Runtime Environment, Standard Edition (build  
1.4.2_09-232)

> Java HotSpot(TM) Client VM (build 1.4.2-54, mixed mode)
>
> Cheers,
>
> Ryan Thomas

--
Ryan Thomas
[EMAIL PROTECTED]

[jira] Closed: (GERONIMO-1344) Get java usage help when a trailing slash '/' is in GERONIMO_HOME environment variable when running geronimo.bat

 [ http://issues.apache.org/jira/browse/GERONIMO-1344?page=all ]
 
John Sisson closed GERONIMO-1344:
-


> Get java usage help when a trailing slash '/' is in GERONIMO_HOME environment 
> variable when running geronimo.bat
> 
>
>  Key: GERONIMO-1344
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1344
>  Project: Geronimo
> Type: Bug
>   Components: startup/shutdown
> Versions: 1.0
> Reporter: John Sisson
> Assignee: John Sisson
> Priority: Minor
>  Fix For: 1.0.1, 1.1

>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Resolved: (GERONIMO-1344) Get java usage help when a trailing slash '/' is in GERONIMO_HOME environment variable when running geronimo.bat