Even after some discussion I'm not sure exactly what you mean by this.

The way I'm thinking of merging the two would result the possibility of deployments with and without (JACC) security enabled for the web app. This would be similar to how the ejb containers can include/exclude security interceptors based on their configuration.

If you want people to be able to run geronimo + jetty without geronimo-spec-j2ee-jacc-1.0-xx.jar and geronimo-security-xx.jar installed, that could be harder, but I'm not convinced it is possible today. Have you tried it? The jetty builder certainly references the security builder, but this might not be a problem if the security elements are not in the plan.

Can you clarify what you mean?

thanks
david jencks

On Dec 6, 2004, at 11:29 PM, Alan D. Cabrera wrote:

The reason that we have JettyWebAppJACCContext and JettyWebAppContext is that I thought that there might be people who want to use jetty in geronimo w/out JACC. If this is not the case, then it makes sense to merge the two.


Regards, Alan

        -----Original Message-----
        From: David Jencks [mailto:[EMAIL PROTECTED]
        Sent: Tue 12/7/2004 1:22 AM
        To: [EMAIL PROTECTED]
        Cc:
        Subject: jetty-deployer branch will be merged back to trunk shortly
        
        

The djencks/jetty-deployer1/trunk branch is basically working perfectly
so I plan to merge it back to trunk shortly.

missing features:

1. default locale configs. These can be specified in web.xml but there
aren't any defaults like jetty has in default-web.xml yet. Are these
actually useful?

2. default filters work but they are automatically mapped to /*. The
default filter mapping isn't quite done.

could be improved:

I think we should merge JettyWebAppJACCContext into JettyWebAppContext
and make whether the security interceptors are added dependent on
configuration.

thanks
david jencks






Reply via email to