You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Santiago Gala <sg...@hisitech.com> on 2001/09/21 17:06:13 UTC
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
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.
Are you aware of such problem? 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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/24/01 3:09 PM, "Jason van Zyl" <jv...@apache.org> wrote:
> On 9/24/01 2:57 PM, "Santiago Gala" <sg...@hisitech.com> wrote:
>
>> 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.
The problem was that it forces a flush after every reference render, rather
than let the Writer buffer.
(I don't think this would have worked completely, as you would also want it
after literals, but that's another issue.)
The problem it was solving, if I remember, is that you want to flush to the
OutputStream in order that the intermixed portlet output goes out to the
client in the correct order.
Why couldn't the portlet framework do the flush before invoking a portlet?
You would have to give a reference to the Writer to the 'portlet tool' in
the Velocity context, but that seems like it would be manageable. (Or some
kind of wrapper...)
That way, Velocity can be as efficient as possible, taking advantage of the
buffering of the Writer, and yet the bytes will be flushed before any
portlet writes....
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Jason van Zyl <jv...@apache.org>.
On 9/24/01 2:57 PM, "Santiago Gala" <sg...@hisitech.com> 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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Santiago Gala <sg...@hisitech.com>.
Jason van Zyl wrote:
>On 9/24/01 1:40 PM, "Santiago Gala" <sg...@hisitech.com> wrote:
>
>>I CC: this discussion about problems with current Turbine-2 cvs to
>>Jetspeed-dev, so that everyone is aware of the status. Also, to provoke
>>discussion on Turbine convergence and code base clean up.
>>
>
>Ok, that's good.
>
>
>>>>- 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?
>>>
>>>
>>As ${webapp.dir} is defined in VariableResourceService, and this code is
>>supposed to run unchanged, it should work. But it is not. It looks as a
>>true nightmare to debug, but I'll try in the next days.
>>
>>But also ${webappRoot} is defined in TurbineResourceService (and we call
>>super.init(...)), so I don't understand why it is not expanded.
>>
>
>If you want I can add ${webapp.dir} to the turbine resources if that makes
>things easier for you right now. Than you can slowly move your ${webapp.dir}
>references to ${webappRoot} references. If this this helps you remove your
>dependence of VariableResources than I do whatever I can.
>
>
Both should work, but none does. This is what puzzles me. We have no
more than 10 references to those variables, so it should not be a
problem to change. The problem is that both VariableResourceService and
its parent class TurbineResourceService fail in my setup, and I can see
why...
>
>>>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.
>>>
>>Yes, it looks as a good idea. I can take care to "remove"
>>VariableResourceService for Jetspeed, and send you patches for
>>TurbineResourceService (turbine-2)
>>
>
>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.
>
>>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
>
>>>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.
>>>
>>If we have a smaller code base, and use more external modules, we will
>>have more people "working for us" ;) So we will be able to concentrate
>>in content aggregation.
>>
>
>That would be fantastic, I would love to see that :-)
>
>
>>>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
>>>
>>This was developed "experimentally" by Raphael, and the aim was to move
>>it to Turbine ASAP. That moving it takes six months is not entirely our
>>fault. FWIK, neither Raphael nor me are Turbine committers.
>>
>
>Ok, what's done is done. Let's start again and try to get the code into the
>turbine repository.
>
>
>>>- thread pooling is not portal specific
>>>
>>This was already there when Raphael and I joined Jetspeed. It was
>>originally developed by Kevin. We have just patched it to keep it
>>working. I don't see any similar service in Turbine.
>>
>
>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.
>
>>>- 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.
>
>>>- 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.
>
>>>- 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.
>
>>>
>>>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.
>>>
>>Yes, we all know that Open Source is about choice and experimentation,
>>and then consolidation of good ideas. I will offer you a new one:
>>
>>- Jetspeed has already a JSP Template Service (It has been migrated to
>>Turbine) and a Velocity Template Service (I think it is actually
>>Turbine's code). I'm working on a SAX XSLT Template Service. Should I
>>implement it directly as a Turbine Service or as a Jetspeed Service to
>>be migrated later to Turbine?
>>
>
>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.
>
>
>
>>>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.
>>>
>>This is no longer true. Since approx one year ago, all changes are
>>bringing us more and more in line with Turbine. Most changes during this
>>period have been devoted to use Velocity instead of/in addition to JSP,
>>and to adapt Jetspeed to the Pull philosophy.
>>
>
>Ok, cool.
>
>
>>As we are closer, more conflicts get exposed, but this is not a bad
>>thing. It rather reflects that our code is closer to Turbine. When it is
>>not, it is due to our lack or knowledge or misunderstanding of Turbine
>>internals or forthcoming code. At least, that is how I see it.
>>
>
>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.
>
>>>
>>>>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.
>>>
>>A big problem is that we have no time to digest the number of mail lists
>>we are subscribed to, and this means that sometimes we are not aware of
>>efforts in Turbine, or in Commons projects. This is a big problem, and I
>>will try to stay more in synchrony with Turbine in the future.
>>
>
>In the future changes in other projects won't cause so much grief as the
>Turbine 3.x API will be an isolated entity but again I have no problem
>helping with 2.x. I know that's it's hard to keep up with changes in Turbine
>but the 2.x tree has been stable now for a while. We've only been adding bug
>fixes and I've add some code to allow a turbine app to run from a cvs
>layout.
>
>>Also, I think we should release another Jetspeed alpha Real Soon Now, as
>>people is using versions that are old, both in terms of functionality
>>and of the version of Turbine they use. I think that when Turbine-2.2 is
>>released it would be a very good moment, and I expect it will happen
>>soon. This is the reason why I'm tracking Turbine-2 cvs very actively.
>>
>
>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.
>
>
>>>>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?
>>>
>>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.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Jason van Zyl <jv...@apache.org>.
On 9/24/01 1:40 PM, "Santiago Gala" <sg...@hisitech.com> wrote:
> I CC: this discussion about problems with current Turbine-2 cvs to
> Jetspeed-dev, so that everyone is aware of the status. Also, to provoke
> discussion on Turbine convergence and code base clean up.
Ok, that's good.
>>>
>>> - 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?
>>
>>
> As ${webapp.dir} is defined in VariableResourceService, and this code is
> supposed to run unchanged, it should work. But it is not. It looks as a
> true nightmare to debug, but I'll try in the next days.
>
> But also ${webappRoot} is defined in TurbineResourceService (and we call
> super.init(...)), so I don't understand why it is not expanded.
If you want I can add ${webapp.dir} to the turbine resources if that makes
things easier for you right now. Than you can slowly move your ${webapp.dir}
references to ${webappRoot} references. If this this helps you remove your
dependence of VariableResources than I do whatever I can.
>>
>> 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.
>>
> Yes, it looks as a good idea. I can take care to "remove"
> VariableResourceService for Jetspeed, and send you patches for
> TurbineResourceService (turbine-2)
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.
> 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.
>>
>> 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.
>>
> If we have a smaller code base, and use more external modules, we will
> have more people "working for us" ;) So we will be able to concentrate
> in content aggregation.
That would be fantastic, I would love to see that :-)
>>
>> 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
>>
> This was developed "experimentally" by Raphael, and the aim was to move
> it to Turbine ASAP. That moving it takes six months is not entirely our
> fault. FWIK, neither Raphael nor me are Turbine committers.
Ok, what's done is done. Let's start again and try to get the code into the
turbine repository.
>>
>> - thread pooling is not portal specific
>>
> This was already there when Raphael and I joined Jetspeed. It was
> originally developed by Kevin. We have just patched it to keep it
> working. I don't see any similar service in Turbine.
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.
>>
>> - 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.
>>
>> - daemons are not portal specific
>>
> Ditto.
Ditto.
>>
>> - 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.
>>
>> - 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.
>>
>>
>> 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.
>>
> Yes, we all know that Open Source is about choice and experimentation,
> and then consolidation of good ideas. I will offer you a new one:
>
> - Jetspeed has already a JSP Template Service (It has been migrated to
> Turbine) and a Velocity Template Service (I think it is actually
> Turbine's code). I'm working on a SAX XSLT Template Service. Should I
> implement it directly as a Turbine Service or as a Jetspeed Service to
> be migrated later to Turbine?
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.
> 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.
>>
>> 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.
>>
> This is no longer true. Since approx one year ago, all changes are
> bringing us more and more in line with Turbine. Most changes during this
> period have been devoted to use Velocity instead of/in addition to JSP,
> and to adapt Jetspeed to the Pull philosophy.
Ok, cool.
> As we are closer, more conflicts get exposed, but this is not a bad
> thing. It rather reflects that our code is closer to Turbine. When it is
> not, it is due to our lack or knowledge or misunderstanding of Turbine
> internals or forthcoming code. At least, that is how I see it.
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.
>>
>>
>>> 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.
>>
> A big problem is that we have no time to digest the number of mail lists
> we are subscribed to, and this means that sometimes we are not aware of
> efforts in Turbine, or in Commons projects. This is a big problem, and I
> will try to stay more in synchrony with Turbine in the future.
In the future changes in other projects won't cause so much grief as the
Turbine 3.x API will be an isolated entity but again I have no problem
helping with 2.x. I know that's it's hard to keep up with changes in Turbine
but the 2.x tree has been stable now for a while. We've only been adding bug
fixes and I've add some code to allow a turbine app to run from a cvs
layout.
>
> Also, I think we should release another Jetspeed alpha Real Soon Now, as
> people is using versions that are old, both in terms of functionality
> and of the version of Turbine they use. I think that when Turbine-2.2 is
> released it would be a very good moment, and I expect it will happen
> soon. This is the reason why I'm tracking Turbine-2 cvs very actively.
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.
>>
>>> 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?
>>
> 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.
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Jason van Zyl <jv...@apache.org>.
On 9/24/01 1:40 PM, "Santiago Gala" <sg...@hisitech.com> wrote:
> I CC: this discussion about problems with current Turbine-2 cvs to
> Jetspeed-dev, so that everyone is aware of the status. Also, to provoke
> discussion on Turbine convergence and code base clean up.
Ok, that's good.
>>>
>>> - 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?
>>
>>
> As ${webapp.dir} is defined in VariableResourceService, and this code is
> supposed to run unchanged, it should work. But it is not. It looks as a
> true nightmare to debug, but I'll try in the next days.
>
> But also ${webappRoot} is defined in TurbineResourceService (and we call
> super.init(...)), so I don't understand why it is not expanded.
If you want I can add ${webapp.dir} to the turbine resources if that makes
things easier for you right now. Than you can slowly move your ${webapp.dir}
references to ${webappRoot} references. If this this helps you remove your
dependence of VariableResources than I do whatever I can.
>>
>> 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.
>>
> Yes, it looks as a good idea. I can take care to "remove"
> VariableResourceService for Jetspeed, and send you patches for
> TurbineResourceService (turbine-2)
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.
> 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.
>>
>> 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.
>>
> If we have a smaller code base, and use more external modules, we will
> have more people "working for us" ;) So we will be able to concentrate
> in content aggregation.
That would be fantastic, I would love to see that :-)
>>
>> 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
>>
> This was developed "experimentally" by Raphael, and the aim was to move
> it to Turbine ASAP. That moving it takes six months is not entirely our
> fault. FWIK, neither Raphael nor me are Turbine committers.
Ok, what's done is done. Let's start again and try to get the code into the
turbine repository.
>>
>> - thread pooling is not portal specific
>>
> This was already there when Raphael and I joined Jetspeed. It was
> originally developed by Kevin. We have just patched it to keep it
> working. I don't see any similar service in Turbine.
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.
>>
>> - 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.
>>
>> - daemons are not portal specific
>>
> Ditto.
Ditto.
>>
>> - 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.
>>
>> - 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.
>>
>>
>> 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.
>>
> Yes, we all know that Open Source is about choice and experimentation,
> and then consolidation of good ideas. I will offer you a new one:
>
> - Jetspeed has already a JSP Template Service (It has been migrated to
> Turbine) and a Velocity Template Service (I think it is actually
> Turbine's code). I'm working on a SAX XSLT Template Service. Should I
> implement it directly as a Turbine Service or as a Jetspeed Service to
> be migrated later to Turbine?
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.
> 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.
>>
>> 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.
>>
> This is no longer true. Since approx one year ago, all changes are
> bringing us more and more in line with Turbine. Most changes during this
> period have been devoted to use Velocity instead of/in addition to JSP,
> and to adapt Jetspeed to the Pull philosophy.
Ok, cool.
> As we are closer, more conflicts get exposed, but this is not a bad
> thing. It rather reflects that our code is closer to Turbine. When it is
> not, it is due to our lack or knowledge or misunderstanding of Turbine
> internals or forthcoming code. At least, that is how I see it.
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.
>>
>>
>>> 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.
>>
> A big problem is that we have no time to digest the number of mail lists
> we are subscribed to, and this means that sometimes we are not aware of
> efforts in Turbine, or in Commons projects. This is a big problem, and I
> will try to stay more in synchrony with Turbine in the future.
In the future changes in other projects won't cause so much grief as the
Turbine 3.x API will be an isolated entity but again I have no problem
helping with 2.x. I know that's it's hard to keep up with changes in Turbine
but the 2.x tree has been stable now for a while. We've only been adding bug
fixes and I've add some code to allow a turbine app to run from a cvs
layout.
>
> Also, I think we should release another Jetspeed alpha Real Soon Now, as
> people is using versions that are old, both in terms of functionality
> and of the version of Turbine they use. I think that when Turbine-2.2 is
> released it would be a very good moment, and I expect it will happen
> soon. This is the reason why I'm tracking Turbine-2 cvs very actively.
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.
>>
>>> 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?
>>
> 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.
--
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/01 10:40 AM, "Santiago Gala" <sg...@hisitech.com> wrote:
> FWIK, neither Raphael nor me are Turbine committers.
What does that have to do with anything?
We can give you commit access if you request it and start sending in
patches. So far, you have sent in few patches and haven't requested it.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/24/01 10:40 AM, "Santiago Gala" <sg...@hisitech.com> wrote:
> FWIK, neither Raphael nor me are Turbine committers.
What does that have to do with anything?
We can give you commit access if you request it and start sending in
patches. So far, you have sent in few patches and haven't requested it.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Santiago Gala <sg...@hisitech.com>.
I CC: this discussion about problems with current Turbine-2 cvs to
Jetspeed-dev, so that everyone is aware of the status. Also, to provoke
discussion on Turbine convergence and code base clean up.
Jason van Zyl wrote:
>On 9/24/01 6:17 AM, "Santiago Gala" <sg...@hisitech.com> wrote:
>
>>Jason van Zyl wrote:
>>
>>>On 9/21/01 11:06 AM, "Santiago Gala" <sg...@hisitech.com> 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?
>
>
As ${webapp.dir} is defined in VariableResourceService, and this code is
supposed to run unchanged, it should work. But it is not. It looks as a
true nightmare to debug, but I'll try in the next days.
But also ${webappRoot} is defined in TurbineResourceService (and we call
super.init(...)), so I don't understand why it is not expanded.
>
>>- 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.
>
Yes, it looks as a good idea. I can take care to "remove"
VariableResourceService for Jetspeed, and send you patches for
TurbineResourceService (turbine-2)
WRT ExtendedProperties, I don't have a current working copy, to look if
the functionality is OK for us. I could checkout a copy.
>
>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.
>
If we have a smaller code base, and use more external modules, we will
have more people "working for us" ;) So we will be able to concentrate
in content aggregation.
>
>
>
>>>
>>>>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
>
This was developed "experimentally" by Raphael, and the aim was to move
it to Turbine ASAP. That moving it takes six months is not entirely our
fault. FWIK, neither Raphael nor me are Turbine committers.
>
>- thread pooling is not portal specific
>
This was already there when Raphael and I joined Jetspeed. It was
originally developed by Kevin. We have just patched it to keep it
working. I don't see any similar service in Turbine.
>
>- 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).
>
>- daemons are not portal specific
>
Ditto.
>
>- 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.
>
>- 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 .
>
>
>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.
>
Yes, we all know that Open Source is about choice and experimentation,
and then consolidation of good ideas. I will offer you a new one:
- Jetspeed has already a JSP Template Service (It has been migrated to
Turbine) and a Velocity Template Service (I think it is actually
Turbine's code). I'm working on a SAX XSLT Template Service. Should I
implement it directly as a Turbine Service or as a Jetspeed Service to
be migrated later to Turbine?
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).
>
>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.
>
This is no longer true. Since approx one year ago, all changes are
bringing us more and more in line with Turbine. Most changes during this
period have been devoted to use Velocity instead of/in addition to JSP,
and to adapt Jetspeed to the Pull philosophy.
As we are closer, more conflicts get exposed, but this is not a bad
thing. It rather reflects that our code is closer to Turbine. When it is
not, it is due to our lack or knowledge or misunderstanding of Turbine
internals or forthcoming code. At least, that is how I see it.
>
>>>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.
>
A big problem is that we have no time to digest the number of mail lists
we are subscribed to, and this means that sometimes we are not aware of
efforts in Turbine, or in Commons projects. This is a big problem, and I
will try to stay more in synchrony with Turbine in the future.
Also, I think we should release another Jetspeed alpha Real Soon Now, as
people is using versions that are old, both in terms of functionality
and of the version of Turbine they use. I think that when Turbine-2.2 is
released it would be a very good moment, and I expect it will happen
soon. This is the reason why I'm tracking Turbine-2 cvs very actively.
>
>>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?
>
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.
>
>
>>>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: turbine-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Santiago Gala <sg...@hisitech.com>.
I CC: this discussion about problems with current Turbine-2 cvs to
Jetspeed-dev, so that everyone is aware of the status. Also, to provoke
discussion on Turbine convergence and code base clean up.
Jason van Zyl wrote:
>On 9/24/01 6:17 AM, "Santiago Gala" <sg...@hisitech.com> wrote:
>
>>Jason van Zyl wrote:
>>
>>>On 9/21/01 11:06 AM, "Santiago Gala" <sg...@hisitech.com> 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?
>
>
As ${webapp.dir} is defined in VariableResourceService, and this code is
supposed to run unchanged, it should work. But it is not. It looks as a
true nightmare to debug, but I'll try in the next days.
But also ${webappRoot} is defined in TurbineResourceService (and we call
super.init(...)), so I don't understand why it is not expanded.
>
>>- 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.
>
Yes, it looks as a good idea. I can take care to "remove"
VariableResourceService for Jetspeed, and send you patches for
TurbineResourceService (turbine-2)
WRT ExtendedProperties, I don't have a current working copy, to look if
the functionality is OK for us. I could checkout a copy.
>
>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.
>
If we have a smaller code base, and use more external modules, we will
have more people "working for us" ;) So we will be able to concentrate
in content aggregation.
>
>
>
>>>
>>>>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
>
This was developed "experimentally" by Raphael, and the aim was to move
it to Turbine ASAP. That moving it takes six months is not entirely our
fault. FWIK, neither Raphael nor me are Turbine committers.
>
>- thread pooling is not portal specific
>
This was already there when Raphael and I joined Jetspeed. It was
originally developed by Kevin. We have just patched it to keep it
working. I don't see any similar service in Turbine.
>
>- 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).
>
>- daemons are not portal specific
>
Ditto.
>
>- 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.
>
>- 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 .
>
>
>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.
>
Yes, we all know that Open Source is about choice and experimentation,
and then consolidation of good ideas. I will offer you a new one:
- Jetspeed has already a JSP Template Service (It has been migrated to
Turbine) and a Velocity Template Service (I think it is actually
Turbine's code). I'm working on a SAX XSLT Template Service. Should I
implement it directly as a Turbine Service or as a Jetspeed Service to
be migrated later to Turbine?
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).
>
>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.
>
This is no longer true. Since approx one year ago, all changes are
bringing us more and more in line with Turbine. Most changes during this
period have been devoted to use Velocity instead of/in addition to JSP,
and to adapt Jetspeed to the Pull philosophy.
As we are closer, more conflicts get exposed, but this is not a bad
thing. It rather reflects that our code is closer to Turbine. When it is
not, it is due to our lack or knowledge or misunderstanding of Turbine
internals or forthcoming code. At least, that is how I see it.
>
>>>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.
>
A big problem is that we have no time to digest the number of mail lists
we are subscribed to, and this means that sometimes we are not aware of
efforts in Turbine, or in Commons projects. This is a big problem, and I
will try to stay more in synchrony with Turbine in the future.
Also, I think we should release another Jetspeed alpha Real Soon Now, as
people is using versions that are old, both in terms of functionality
and of the version of Turbine they use. I think that when Turbine-2.2 is
released it would be a very good moment, and I expect it will happen
soon. This is the reason why I'm tracking Turbine-2 cvs very actively.
>
>>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?
>
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.
>
>
>>>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: turbine-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Jason van Zyl <jv...@apache.org>.
On 9/24/01 6:17 AM, "Santiago Gala" <sg...@hisitech.com> wrote:
> Jason van Zyl wrote:
>
>> On 9/21/01 11:06 AM, "Santiago Gala" <sg...@hisitech.com> 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: turbine-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Santiago Gala <sg...@hisitech.com>.
Jason van Zyl wrote:
>On 9/21/01 11:06 AM, "Santiago Gala" <sg...@hisitech.com> 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 :-?
- 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.
>
>
>>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.
>
>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.
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. 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?
>
>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.
>
>>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: turbine-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Heads up: ExtendedProperties [Problem with Jetspeed]
Posted by Jason van Zyl <jv...@apache.org>.
On 9/21/01 11:06 AM, "Santiago Gala" <sg...@hisitech.com> 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.
> 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.
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 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.
> 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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org