After checking the current changes to the realm, in the past, we will set the geronimo-admin for the Engine, which means that all the web-apps belong to the Engine will use the realm setting from its parent if no setting is set for those web-apps. Currently, the realm for the Engine is remained for Tomcat's default setting, which uses users.xml. So far, I did not see any effect to our existing console applications, I am not sure whether we need to recover it. IMO, keep the current way is better. Any comment ? Ivan
2009/6/22 Ivan <[email protected]> > > > 2009/6/22 David Jencks <[email protected]> > >> >> On Jun 21, 2009, at 10:20 PM, Ivan wrote: >> >> >> >> 2009/6/22 David Jencks <[email protected]> >> >>> >>> On Jun 19, 2009, at 9:18 PM, Ivan wrote: >>> >>> Currently, what I can see are >>> 1. Recover those configurations that we used for Tomcat in the >>> server.xml >>> >>> >>> For connectors, I may have done most of this in my work for (3).... could >>> use some checking. I'd also like to see if I can make the tomcat connectors >>> use our thread pool -- a new feature I've wanted for years :-) >>> >>> 2. Update the console codes, and decide whether we need to keep the >>> functions like add/remove connectors. If keep, the way we do it is to >>> add/remove ConnectorGBean or to marshall/remarshall server.xml. >>> 3. Make those settings in the server.xml not hardcoded. >>> >>> >>> I implemented this here, not sure if I'll get it committed today or >>> tomorrow >>> >> >> I committed this in rev 787153. I exposed the replacement code the local >> attribute manager uses. I'm thinking of modifying the activemq integration >> to use this method instead of spring property substitution. >> > > Native support from Geronimo for the subsitution is better, for ActiveMQ > integration, IIRC, maybe a bit extra work needs, for i add some extra > properties to the property configuration, which are not contained in the > config-substitution. > >> >> >>> 4. Recover those GBeans that console/other components used, such as >>> AccessLogValve etc. >>> >>> >>> Maybe the AccessLogValve can fish its valve out of the server like the >>> engine gbean now does? >>> >> >> I will try to do it, Valve is a bit different with the Engine, for it >> has no name attribute, and Engine/Host all could hold to a list of them. >> My way is to use the "seq" to identify it, like what it is done by its >> object name. >> >> >> Looking forward to seeing this! >> > > DONE with At revision: 787174. > BTW, I guess that we also need to look at the realm setting for Tomcat. > >> >> thanks >> david jencks >> >> >>> thanks >>> david jencks >>> >>> >>> I would like to work at parts of them, if we have decided to import this >>> feature in 2.2. And I suggest that we open a JIRA for each of them, so that >>> we could track them clearly. >>> Thanks ! >>> Ivan >>> >>> 2009/6/20 David Jencks <[email protected]> >>> >>>> After fixing the HostGBean in web app plan problem I don't have a very >>>> clear idea of what's missing here. If one of you do could you please list >>>> in detail what needs to be done? >>>> thanks >>>> david jencks >>>> >>>> On Jun 19, 2009, at 8:51 AM, Ivan wrote: >>>> >>>> It is easy to add the SSL connector, the things that Jack concens is >>>> that, how do the changes affect other components, I think. >>>> Ivan >>>> >>>> 2009/6/19 Kevan Miller <[email protected]> >>>> >>>>> >>>>> On Jun 19, 2009, at 2:31 AM, Jack Cai wrote: >>>>> >>>>> Looks like this is going be a piece of non-trivial work. Considering >>>>>> that we are going for a 2.2 release, should we re-evaluate whether this >>>>>> feature should be in 2.2? My gut feeling is no. We should really stablize >>>>>> the code and resovle TCK issues. >>>>>> >>>>> >>>>> If it's *hard* to add the SSL connector configuration, then something >>>>> is clearly wrong. Personally, I'd be pretty interested in seeing this type >>>>> of support in 2.2. The more Tomcat apps/configurations that just run on >>>>> Geronimo, the better off we are... >>>>> >>>>> --kevan >>>>> >>>> >>>> >>>> >>>> -- >>>> Ivan >>>> >>>> >>>> >>> >>> >>> -- >>> Ivan >>> >>> >>> >> >> >> -- >> Ivan >> >> >> > > > -- > Ivan > -- Ivan
