On 9/24/01 6:17 AM, "Santiago Gala" <[EMAIL PROTECTED]> wrote:
> Jason van Zyl wrote:
>
>> On 9/21/01 11:06 AM, "Santiago Gala" <[EMAIL PROTECTED]> wrote:
>>
>>> Jason van Zyl wrote:
>>>
>>>> Hi,
>>>>
>>>> I've added ${variable} interpolation to the ExtendedProperties class so
>>>> if you want to take advantage of this feature you'll have to update
>>>> your commons-collections jar. This is for turbine 3.x. The variable
>>>> interpolation now works in 2.x but the ResourcesService was modified
>>>> directly.
>>>>
>>> Since you changed it (or maybe other changes in turbine-2 HEAD) jetspeed
>>> no longer works. It builds, but all services that need this feature
>>> receive empty strings. It seems related to a problem with the ordering
>>> of service initialization, where the ${webappRoot}/${webapp.dir} vars
>>> are not defined when we are trying to use them.
>>>
>>
>> I just built jetspeed but didn't run it. I will try to find the problem
>> ASAP. This is definitely a result of a lack of API and the oddness in which
>> jetspeed has extended certain parts of Turbine.
>>
>> I'll look into it and find the problem. I think I know what the problem is.
>>
> I made it run by doing the following:
>
> - Changing webapp.dir to webappRoot everywhere (it includes TR.p, JR.p
> and CastorRegistryService.java). It is funny as, from what I inspect the
> code, it should not be needed. But it is :-?
I'm not following entirely. What do you need to do that you weren't
expecting to have to?
> - Wrapping calls to serviceCont,getString() in
> conf.getServletContext().getRealPath(). This is due to the fact that
> ${webappRoot} or ${webapp.dir} do not get expanded. I'm checking why it
> happens in other cases. I think it is a race condition with service
> initialization, but I'm not yet sure.
>
> < directory = serviceConf.getString("directory");
> < mapFile = serviceConf.getString("mapping",DEFAULT_MAPPING);
> ---
>> directory = conf.getServletContext().getRealPath(
> serviceConf.getString("directory") );
>> mapFile = conf.getServletContext().getRealPath(
> serviceConf.getString("mapping",DEFAULT_MAPPING) );
>
> It looks like, in other uses of ${webappRoot}, it gets correctly
> expanded. It looks again like the ResourceService returned by doing
>
> ResourceService serviceConf =
> ((TurbineServices)TurbineServices.getInstance())
>
> .getResources(RegistryService.SERVICE_NAME);
>
> (RegistryService.SERVICE_NAME equals "Registry")
>
> in the init( ServletConfig ) method of CastorRegistryService is not
> properly initialized. We are inheriting the TurbineResourceService by a
> VariableResourceService, and this can introduce problems during
> initialization. I'm trying to find the problems and get rid of the
> Jetspeed specific service, now that we have a turbine equivalent.
How about we work toward just using TurbineResources in Jetspeed and we'll
move any remaining code in the the jetspeed VariableResources class into
the TurbineResources class. The only code I've borrowed so far is variable
interpolation in strings i.e. on the getString() method.
In the VariableResources class the interpolation is also implemented for
getStringArray() and getVector() I believe. It would be nice if the code for
VariableResources could be collapse into TurbineResources (and
ExtendedProperties for Turbine 3.0) and have Jetspeed drop VariableResources
all together.
>>
>>
>>> Are you aware of such problem?
>>>
>>
>> I wasn't aware of the problem, but I am making many changes to the TDK so
>> that I can build all turbine applications to check for compatibility
>> problems during runtime. Gump will catch problems in the build but what is
>> happening with jetspeed is what I dread. People digging into the code
>> anywhere and everywhere to get something to work.
>>
> If something can be done (the language allows it) and it is not clearly
> documented, then you can not complain if people does it. I would say
> that anything that is not forbidden is permitted.
So during development of a project that you know to be based on a parent
project if something isn't clearly documented than you ask no questions and
proceed as you wish? There is no doubt that with the Turbine 2.x code that
you can do pretty much anything but do you honestly think this is the best
thing for the project? I personally don't feel that's a good way to proceed
and it's not good for your project.
And I will definitely complain as the Jetspeed project continually and
persistently implements functionality that should be present in Turbine:
- variable interpolation is not portal specific
- thread pooling is not portal specific
- disk caches are not portal specific
- daemons are not portal specific
- localized template services are not portal specific
- and I could probably find 10 other examples
Turbine is not well documented, everyone knows that but the Jetspeed project
has never helped in this regard and continually makes additions which are
expedient and serve the purposes of Jetspeed without much regard for
Turbine.
This is probably a good place to start than. I think that general variable
interpolation is something that all turbine apps could use so I'll make any
additions to the ResourcesService so that it will work in jetspeed if you
test jetspeed (I will soon be able to test it reliably myself).
I have seen pretty much zero activity on the jetspeed cvs list so your
divergent code base concerns me greatly because when there is activity the
project usually diverges further from Turbine which I don't think is good
for the Jetspeed project given how many complaints you still get about code
not working and difficulty installing Jetspeed.
>>
>> The variable interpolation is something that could have easily been added to
>> the Turbine codebase but was instead added directly to jetspeed. I am using
>> the code from jetspeed in the ResourceService in the turbine 2 repository so
>> I should be able find it fairly soon.
>>
>> I would like to slowly try to align jetspeed with the code in Turbine
>> because I'm not seeing much activity at all in jetspeed so the project would
>> benefit from any and all removal/collapsing of code where there is an
>> alternative in the turbine code base.
>>
> I'm wishing definitely to help here. I'm trying to reduce the Jetspeed
> code base to be able to maintain it effectively. Getting rid of
> duplications with turbine, as turbine evolves, is a must.
Great, glad to hear it.
> Don't forget that a lot of these alternatives are there because we
> started using them, and then a patch was sent to turbine. Quite a few
> times, patches sent to turbine for behaviour we needed were ignored or
> delayed.
I'll try not to let the patches slide, but I'm sure in some cases the
patches were seen as not adequate or hackish and you guys expected us to put
the code into Turbine because you needed some functionality that may not
have been thoughout with the greater turbine whole in mind.
I'm definitely willing to work with you to remedy the situation.
> As an example, I still have code in Jetspeed to check and
> escape commas in ExtendedProperties values, and the patch was sent to
> turbine and never applied. If and when it is applied, how do I know my
> duplicated method is no longer needed in the Jetspeed codebase?
Unit tests. Adding the code back to turbine and create unit tests. There are
now two places for property handling code. ExtendedProperties in the commons
collections used in turbine 3.0 and TurbineResources used in 2.x.
I'm not saying it will be easy moving all your code back into Turbine but we
have to try.
I also believe that commas are escaped, I will check because I thought this
was a feature. Was your patch for a bug you fixed or adding additional
functionality?
>>
>> I will soon be able to build and run jetspeed with the TDK and will be able
>> to find problems like this. I still find the jetspeed layout entirely
>> confusing and have only been able to get it to run on a few occasions. I
>> would like to eliminate this problem.
>>
> Let us communicate, then. Feel free to ask any question about Jetspeed
> internals (I don't know everything, Raphael and David know more about
> internals than myself, but I'm good at debugging). Currently I'm working
> on security and cleaning template implementation to add a new SAX
> template engine.
Ok, I definitely will over the next while.
>>
>>> Jetspeed works with current snapshot
>>> (nightly Sep 12). The change breaking us has taken place between Sep 13
>>> and today.
>>>
>>> I'm not able to understand what's going on.
>>>
>>>>
>>>> The upshot is that you can specify things like:
>>>>
>>>> myResouce = ${webappRoot}/resources/myResouce.xml
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
