On 9/24/01 2:57 PM, "Santiago Gala" <[EMAIL PROTECTED]> wrote:
> Jason van Zyl wrote:
>
>>
>> If you need the additional getStringArray() and getVector() to do the
>> variable interpolation than I can easily lift those from the jetspeed code
>> and add them the TurbineResources if that will help.
>>
>>
> This looks good. Then I can remove references to VariableResourceService
> in the code, and use TurbineResourceService. Then we can see if the
> problem is due to subclassing/class loading, or there is some problem
> missing there.
Ok, I will add those method today. Watch for the message.
>>
>>> WRT ExtendedProperties, I don't have a current working copy, to look if
>>> the functionality is OK for us. I could checkout a copy.
>>>
>> The ExtendedProperties that I'm refering to exists in the
>> commons-collections package now and you probably won't need it until you
>> move toward Turbine 3.x.
>>
>>
>>
> I imagine it comes from the one with the same name that was in Turbine
> earlier (before release of Turbine-2). It was
> org.apache.turbine.util.ExtendedProperties
Not quite the same thing anymore, in Velocity I rolled up Configurations,
ConfigurationRepository and ExtendedProperties and called it Configuration.
Than we move it to the commons where its name change again to
ExtendedProperties. The ExtendedProperties in the commons is an combination
of all the above mentioned classes.
>>>
>>
>> There is a pooling service in turbine, but primarily my point is that when
>> something new is developed for jetspeed, something generic like pooling,
>> that it should go into turbine not jetspeed.
>>
>>
> We should look if there is something suitable in Commons. I agree this
> code should not be in Jetspeed.
>
>>
>>>> - disk caches are not portal specific
>>>>
>>> Ditto. I have patched this code extensively, but it is not originally
>>> mine. It was developed by Kevin. Again, I don't know of any alternative
>>> implementation, and it is surely needed (to avoid that each page hit
>>> implies like 20 HTTP request to foreign servers, thus making Jetspeed
>>> unusable).
>>>
>>
>> Again this is something that is generally useful for all applications. I
>> realize that the code is in the state that it is when you arrive but it
>> doesn't mean it has to remain that way.
>>
>>
> There is people that disagrees on this one. We could use only the memory
> cache, and use a reverse proxy to cache cacheable resources (something
> like Squid). But this means that Jetspeed would need a more complex
> setup for basic installations, so there is a trade off between
> simplicity of basic war and more professional setups.
I would like to work together to make a new caching system. Either using the
commons code or the code that Aaron Smuts is working on. Both deal with
memory and disk caches. The caching service we currently have needs some
help.
>
>>
>>>> - daemons are not portal specific
>>>>
>>> Ditto.
>>>
>>
>> Ditto.
>>
>>
> Here, a suitable alternative would be to use the ScheduleService,
> something that does not look that difficult to test.
That would be cool. I think that anything you can use from Turbine is a good
thing.
>>
>>>> - localized template services are not portal specific
>>>>
>>> Again, this was offered as a patch to Turbine even before we had it
>>> working. It was developed when turbine had nothing similar. I remember
>>> that it was even considered bad in list discussions, as we needed
>>> localization including ContentType. Even now, it does not support
>>> generic resources (we need much more than localized templates, we need
>>> localized resources). Currently, we have ContentType/Language/Country...
>>> with a fall back.
>>>
>>
>> We can try it again. I hadn't played with the template service at that
>> point, but I'm intimately familiar with it now and I know that localization
>> is a big issue in general so it's something that would be good to work out.
>>
>>
> David told me he was looking wether Turbine's service can cope with the
> PSML resources, to get rid of our service.
Ok, I've tried a couple working on this with David and just ran out of time.
I think it can be done.
>>
>>>> - and I could probably find 10 other examples
>>>>
>>> Not that many, I think you have already quoted most of the friction
>>> points. :-) Now, I think we should go on moving code that is generic
>>> enough to Turbine .
>>>
>>
>> Ok, sounds good to me. We can start simple with the VariableResources.
>>
>>
> It looks a simple place to start clean up.
>
>>
>>
>> You can develop it in the jetspeed codebase for testing but use turbine
>> package names and when it works and is tested than we can move it into the
>> turbine repository. With Turbine 3.x this will definitely be easier because
>> the services framework has been separated.
>>
>>
> It looks like a way to go, although it can confuse people thinking that
> it comes from Turbine distribution. If we use generic classes to
> encapsulate calls, then the services will be instantiated by name, so it
> should be no pain to change package names. But this depends on having
> good encapsulation of calls in a generic class.
>
>>
>>> The idea is that, instead of having ECS objects or Byte/Character
>>> Streams to aggregate the response, it will establish a chain of SAX
>>> event handlers, and use SAX end to end. There will be adaptors to mix
>>> Stream content with SAX content, so that a portal can mix the different
>>> templates in the same page (it will not be efficient, though).
>>>
>>
>> Ok, it's not something that I'm familiar with but it sounds like many people
>> would be interested.
>>
>>
>>
>> Exposing the conflicts is good, we definitely need to define how turbine is
>> used. This will definitely be better in Turbine 3.x but I'll help do
>> whatever I can for 2.x app. I work on Tambora full-time which is a 2.x app
>> so I definitely have a vested interested in seeing 2.x have full support.
>>
> I think Jetspeed should remain a Turbine-2 application for some time. I
> don't know what other people thinks.
That's totally fine. But I know that dealing with Turbine 3.x will be a lot
easier and definitely less painful when it's finished. It won't be done for
a while and I certainly wouldn't recommend a quick rush to 3.x anyway.
>>
>> Cool. I don't know when 2.2 will be out. Things are working but I would like
>> to release 2.2 with released versions of the components we use to try and
>> make maintenance easier. I would also like to get the next version of the
>> TDK finished too.
>>
> Yes. Raphael sent a patch to Velocity for enabling the mixing of
> different portlets in the same request. I'm not sure if this patch is
> already in velocity cvs. I think we should release when we get a
> Turbine-2.2+Velocity-1.2 release.
We've seen this patch, and I'm not sure this is the best approach. It works
for your portlets but I'm not sure if it's the best thing for the velocity
code base. I think the thread of discussion petered out, I don't know where
it stands. I don't think Geir was too thrilled with the patch.
>>>> 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?
>>>>
>>> It was a bug fix. ExtendedProperties did not escape commas in values
>>> back then. We had values that contained commas inside, and this provoked
>>> ClassCastExceptions in our code, as commas were taken as multiple
>>> values. I'm not sure about its current state. I'm speaking about April
>>> or so, before Turbine-2 release.
>>>
>>
>> Is there anyway you could check this again in the current turbine code base.
>> If the problem is still there than I will apply your patches if you send
>> them to me.
>>
>>
> Where are properties read in Turbine-2? I will check there and also in
> Commons ExtendedProperties.
All in the org.apache.turbine.services.resources package. I will update that
today so you should be able to use it in Jetspeed. The extended properties
is only used in Turbine 3.x.
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> 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]
