date:20070817

FYI: New Continuum instance

2007-08-17 Thread Grzegorz Kossakowski


Hi,

With help of Brett Porter I'm just in process of creating new Continuum setup for Cocoon at a new 
Continuum instance[1]. Brett told me that old one when we used to have Cocoon built is going to be 
shut down soon.


The advantages of a new instance are significant:
1. It's Continuum 1.1 that supports build profiles and one of already set up profile is Java 1.4 
that we can use so Cocoon is checked against compatibility with Java 1.4. Nice, don't you think? :-)
2. It's less bloated. Old Continuum was a real mess and as Brett told me it had almost no 
maintainers. This may change.

3. It's considerably faster and has new neat options like projects group.
4. Broken notifications should work now.

For the beginning I'll try to replicate old setup and if it works we can discuss if we want 
something to adjust. If you want to be added to project group developers (so you can edit settings 
for Cocoon) just register at Continuum and give me your username.


[1] http://vmbuild1.apache.org/continuum/

--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection
***
*** incessantly so I'll not be able to respond to e-mails 
***
*** regularly and my work will be somehow irregular.  
***
*** I'm already trying to switch ISP but it will take handful amount of time. 
***

Re: Pipeline components and Object Model issues

2007-08-17 Thread Grzegorz Kossakowski

Joerg Heinicke pisze:

On 14.08.2007 12:26 Uhr, Grzegorz Kossakowski wrote:

The problem is that Object Model is a signleton object (more
precisely, with call scope defined in cocoon-servlet-service-impl)

So the problem is not with internal pipelines at all since they are
scoped anyway? Or does this apply only for servlet service? Do other
internal protocol still exist at all?

Yes, it's not problem with internal pipelines (internal requests made by servlet:) because they are
scoped. No, it's general problem and if servlet service is not used this problem emerges in
internal requests, also (because scope is not used).

What internal proctol do you have in mind? A cocoon: I guess, so it still exists and it's main
reason for keeping complicated environment handling and complicated code of sitemap's treeprocessor.
Since servlet: protocol replaces (or is going to replace) all functionality of cocoon: we need to
start thinking about deprecating it in a future.

To elaborate on it further, the situation is similar to the situation
when thread-unsafe component is used in two threads at the same time.

This comparison does not really apply. You don't get corrupted state but
some last-wins situation in case of conflicts. If two components in a
pipeline have the same parameter the last one added wins. So the result
is actually predictable - but unwanted of course.

Not entirely true. ObjectModel can be modified during component's execution at random times, really.
It happens all the time in template generator where Object Model is passed almost everywhere and it
depends on incoming SAX events if OM will be modified. So it's predictable during setup phase but
not during execution.

This fully establish analogy between thread-unsafe components and OM, IMO.

I wonder if that scope makes much sense. It's a 1:1-relationship to
the component anyway. What we need is only a wrapper that delegates
read-only access to parent object model in case the child could not
serve the requested value. Maybe we just talk about the same ...

Yes, we talk about the same but I want OM to be casual Spring bean but scoped properly. This way we
get necessary wrapper but in transparent way so component's can take advantage of Dependency
Injection when it comes to OM.

I could agree with you that introduction of scope does not make sense in 1:1-relationship but since
component can make internal requests and if we want to provide some environment forwarding/sharing
(see COCOON-2050[1] and [RT] The big picture of Servlet Service Framework e-mail[2] for examples
where it could be needed) we will need to obtain OM and we should get exactly the same OM component
making a request have.

Actually this whole problem reminds me of session attributes in portlet
environment. A portlet's session attributes work exactly like written
above - but all are stored within the global HTTP session though by
prefixing the session attribute names with a portlet-unique string. And
I wonder how fast we will observe another requirement: I know that I
might break something but I WANT make this attribute globally
available. This concept is known in portlet session attributes. You can
enforce writing an attribute straight to the global session. See the
corresponding methods on PortletSession [1] (actually they call it
scope as well).

From my purist point of view I would say: just don't even think about it! ;)
However, I know that from time to time we have bend the rules and the solution already exists with
current design. OM can be extended by implementing ObjectModelProvider interface so some entries are
added to OM during it's creation. Now you can reference to such bean (that should have prototype
scope for example) in pipeline component and modify it directly bypassing all OM mechanisms. This
way you lost all protection but you are not limited by any scopes and so on.

But I'll repeat: don't do this and if you insist on doing it don't be surprised if something does
not work.

How is the object model injected into such a sitemap component? Still
via setup()?

As I said earlier, OM is just a Spring bean so it's going to be injected using
Spring's mechanisms.

--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection
***
*** incessantly so I'll not be able to respond to e-mails
***
*** regularly and my work will be somehow irregular.
***
*** I'm already trying to switch ISP but it will take handful amount of time.
***

Re: FYI: New Continuum instance

2007-08-17 Thread Grzegorz Kossakowski


Grzegorz Kossakowski pisze:

3. It's considerably faster and has new neat options like projects group.


Actually it's going to be upgraded soon so you may experience something opposite - slowness and 
instability but it's temporary.


--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection
***
*** incessantly so I'll not be able to respond to e-mails 
***
*** regularly and my work will be somehow irregular.  
***
*** I'm already trying to switch ISP but it will take handful amount of time. 
***

Re: Cocoon Spring configurator

2007-08-17 Thread Carsten Ziegeler

Joerg Heinicke wrote:
 Carsten Ziegeler cziegeler at apache.org writes:
 
 Carsten, when I recommended the bean map today [1] I wondered how it actually
 works. The documentation talks about jar drop-in [2] which does not seem to be
 the full truth. Please correct me if I'm wrong ...
:)

 
 The BeanMap looks for all beans of a particular type. Therefore the beans 
 needs
 to be registered in the application context.
Yes, that's true - so you can use the bean map standalone without
using anything else from the configurator.

 So far so good, but here I think
 the drop-in fails. Even if the jar includes the configuration the bean does 
 not
 get added automatically to the application context. Only the other parts of
 Cocoon Spring configurator enable this functionality. (If that's correct this
 should better be added to the BeanMap documentation.) 
Yes, that's true - the bean map is just a map of some registered beans.
Together with the other functionality of the spring configurator you get
 the automatic configuration stuff - and if such a configuration
contains beans for the map, they are added to the map of course.
Yepp, I think this needs some clarifications in the docs.

 Which class exactly does
 this? And how much stuff is hard-coded in it? You don't want to have paths 
 like
 /META-INF/cocoon/spring when using Cocoon Spring configurator independently 
 from
 Cocoon. It's probably not that hard to change but we should do it before
 propagating it :)
There are constants defined in
org.apache.cocoon.spring.configurator.impl.Constants.

So changing this is very simple. The whole loading is done through own
xml elements (the settings element). Most classes in
org.apache.cocoon.spring.configurator.impl deals with this stuff.

Carsten

-- 
Carsten Ziegeler
[EMAIL PROTECTED]

Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine

2007-08-17 Thread Daniel Fagerstrom

Grzegorz Kossakowski skrev:

Daniel Fagerstrom pisze:

Grzegorz Kossakowski skrev:

Vadim Gritsenko (JIRA) pisze:

Actually, such syntax is supported[1] in our code for almost two
years now.

The new syntax is supported but it is plugable and the default
settings is using the old syntax. I didn't find any detailed design
discussion about the design in the archives, the idea is suggested in
http://marc.info/?l=xml-cocoon-devm=110651769909483w=2.

For the actual implementation, the parsing of a string with embedded
expression calls (a string template) is plugable using the interface
o.a.c.template.expression.StringTemplateParser. The current syntax is
handles by JXTGStringTemplateParser and the new one by
DefaultStringTemplateParser. The choice of string template parser is
done in
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/main/resources/META-INF/cocoon/avalon/cocoon-template.xconf.

The whole string template mechanism (the package
o.a.c.template.expression) could preferably be reused in the sitemap
as well. To do this the package needs to be moved to the core
(cocoon-expression-language) and refactored a little bit, the
dependencies on o.a.c.template.environment.ParsingContext and
o.a.c.template.environment.ErrorHolder needs to be removed and a more
appropriate package name should be found.

...
To sum up, new syntax has been introduced during refactoring of
Template block and since community already voted to switch to
refactored code it also voted for new syntax.

The vote was not about removing the current syntax. It was about
switching default implementation of the JXTG concept.

Speaking about myself I prefer much more language prefixes and I
think we should go for it. The question that we need to answer is if
we want to support #{} syntax in sitemap? Since it was never there I
don't think it makes sense to do so.

Using the string template mechanism in the sitemap we get the current
JXTG syntax for free, but I would advice users to not use it.

Daniel, I implemented what you proposed

Good.
but not committed yet due to regression it introduces. Basically, I
implemented handling of sitemap expressions in
LegacyStringTemplateParser (JXTGStringTemplateParser in the past) and
it's seems to work ok with basic tests. However,
LegacyStringTemplateParser is also used in Template block so, as
result of my changes, one will be able to evaluate sitemap expressions
in templates. It's not that bad but it introduces small regression.
One of the points with plugability is that you can have several
implementations of the interface ;)

I suggest that you leave LegacyStringTemplateParser as it was before and
put your new code in a LegacySitemapStringTemplateParser that only is
used in the sitemap. Then you of course need to see if you get any
regression in the sitemap.

But I wonder why you want to combine the JXTG and sitemap template
syntax at all, why not just people chose between the old syntax and the
new unified syntax. I suggest that you start a new less technical thread
about how you want to have the expression syntax in the sitemap and the
templates, so that the rest of the community can have opinions.
With old implementation of JXTGStringTemplateParser it was possible to
escape { character but not mandatory. With new implementation it's
mandatory because it will be parsed as sitemap expression otherwise. I
tried to search for all occurrences of such unescaped { with this
command:
find | xargs grep http://apache.org/cocoon/templates/jx/1.0; -l |
xargs grep -E \?xml -l | xargs grep -E [^#\$][{] -l | grep -E
--invert-match .svn|target

and got following results:
./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/dreamteam/content/teamTemplate.jx

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/file_explorer_template.xml

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/inplace_edit_template.xml

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/datasource_chooser_template.xml

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/dynamicrepeater_template.xml

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/sampletree_template.xml

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/xmlresult_template.xml

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/carselector_template.xml

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/multipage_template.xml

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/xdoceditor_template.xml

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/tasktree_template.xml

./blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/dynamicrepeater_dojo_template.xml

Re: [jira] Commented: (COCOON-2110) Evaluate expressions defined in cocooon-expression-language-api in Sitemap engine

2007-08-17 Thread Grzegorz Kossakowski

Daniel Fagerstrom pisze:
One of the points with plugability is that you can have several
implementations of the interface ;)

;)

After sleeping with this problem in mind I'm starting to wonder, too. ;-)
It's good that nobody have seen this code that made gluing possible, it's
nightmare...

No, not without a detailed evaluation of alternative solutions, a cost
and benefit analyze of the change and a vote.

Ok, enough points to distance me from introducing back incompatibility :)

Are you starting to see some pattern in my responses to your suggestions
about create back incompatibility ;)

There is another one: When I start to talk about back incompatibility it's a sign I'm stuck and need
to talk with someone more experienced to get an advice. ;)

[HEADS-UP] Changes to Sitemap's TreeProcessor

2007-08-17 Thread Grzegorz Kossakowski


Hello,

I've applied changes in r567057 that were discussed here[1]. Briefly speaking, this change allow us 
to switch to new unified expressions by changing one line of configuration in this[2] file:


  property name=stringTemplateParser 
ref=org.apache.cocoon.el.parsing.StringTemplateParser/legacySitemap/


If you change it to:

  property name=stringTemplateParser 
ref=org.apache.cocoon.el.parsing.StringTemplateParser/default/


You will immediately get a possibility to use new expressions in sitemap, like:

  map:transform type=xslt src=style.xsl
!-- here we assume that default EL is JXPath --
map:parameters name=param1 value={$cocoon/request/parameters/param1}/
  /map:transform

While that is neat it could introduce very unexpected problems and bugs. I've touched very core 
functionality of TreeProcessor and it was first, brave attempt to introduce Spring to TreeProcessor. :-)


I tested my changes and everything seems to work as before but I don't understand all constructs in 
TreeProcessor so some obscure problems may arise.


Please test new changes with your applications and report problems so we can 
fix them ASAP.

[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74529
[2] 
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/resources/META-INF/cocoon/spring/StringTemplateParserVariableResolver.xml


--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection
***
*** incessantly so I'll not be able to respond to e-mails 
***
*** regularly and my work will be somehow irregular.  
***
*** I'm already trying to switch ISP but it will take handful amount of time. 
***

New expressions' syntax

2007-08-17 Thread Grzegorz Kossakowski


Hi,

I would like to discuss a new syntax for expressions or more precisely for string templates that are 
going to be default in Cocoon.


In order to clarify things I'll provide vocabulary that corresponds to current 
implementation.

  Expression
Expressions are just strings that can be interpreted in certain language 
like Jexl or JXPath.
Expressions can contain prefix that gives hint how to interpret them. Some 
examples:
  * jxpath:$cocoon/request - JXPath
  * bean.HelperMethod(sth) - Jexl
  * ${bean1.bean2} - this is _not_ an expression (more below)

  String template
String templates are strings that contain both expressions (wrapped in some 
special characters)
and literals mixed up. Examples:
  * This is literal, #{$cocoon/request}. - literal and JXPath expression 
wrapped in old way
  * ${bean1.bean2} - only Jexl expression wrapped in old way
  * Literal1 {request-param:param} Lieteral2 - two literals and sitemap 
expression wrapped using
   {} characters.

In this mail I would like to discuss these wrapping characters for string templates we are going to 
have by default at least in Template and Sitemap but very likely that also in Forms and other places 
where expressions can be useful.


Currently we use {} to wrap sitemap expressions. We use #{} to wrap JXPath, ${} to wrap Jexl, @{} to 
wrap Javascript expressions, all in Template only.


One of my big goals is to make you think only about one string template, one wrapping chars and 
whatever you like number of expression languages you like everywhere in Cocoon. When achieving this 
goal I must keep back-compatibility in mind all the time as Daniel is patiently reminding me.


I think that I have not introduced any back-incompatibility so far even I wanted several times. I 
guess it's the hardest time because I'm I want to:

  a) allow people migrate to new expressions both in Template and Sitemap 
smoothly
  b) stay 100% back-compatible with old code behaviour while implementing new ways of expression 
evaluation and most importantly Object Model construction

  c) avoid confusion about what's new and what's old

This leads us to small but very important question: how we wrap new expressions? If I'm not wrong, 
current preference  has been to wrap new expressions in {}, Daniel confirms[1] this view.


My own opinion is that plain {} are ok in sitemap but will not work well in general. If choose {} as 
wrapping characters everything put between this characters will be considered as expression. If you 
additionally remember that all strings inside elements are treated as String templates you may start 
to be warned. Take a look this[2] file's snippet:


  style type=text/css
#files { border-collapse: collapse; border-left: dotted black 1px; }
#files td { padding: 0.1em; border-bottom: dotted black 1px; }
.selected { background: #D0D0D0; }
  /style

It's a content of jx template but obviously we don't want generator/transformer to interpret this 
CSS declarations as Cocoon expressions! We would need to escape {} wrapping characters:


  style type=text/css
#files \{ border-collapse: collapse; border-left: dotted black 1px; \}
#files td \{ padding: 0.1em; border-bottom: dotted black 1px; \}
.selected \{ background: #D0D0D0; \}
  /style

It's ugly, don't you think?

Next choice could be to use ${}. The problem with this characters is that they are already used in 
Template and if we don't pick Jexl language as default it will break current templates not to 
mention confusion it would cause. We could come up with %{}, !{} or whatever is not used yet. 
Everyone's keyboard has lot of remaining symbols waiting for use but I wonder if we really want/need 
new wrappers.


I'm stuck. Thoughts?

[1] http://marc.info/?l=xml-cocoon-devm=118703810504930w=2
[2] 
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-sample/src/main/resources/COB-INF/forms/file_explorer_template.xml


--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

56 matches

Mail list logo