Weird bug when extending a Component

[Franck Routier]

Hi all,

I have been working on tests on my nested rendering stuff, and while
testing, I thought I had introduced a bug somewhere...
But it turns out to be a bug in stock Barracuda. Well, a weird one...

The scenario is :

1) extend a component :

class Mytext extends BText {
    public Mytext(String str) { super(str);}
}

2) manually bind an instance of it to a node

Document page =
DefaultDOMLoader.getGlobalInstance().getDOM(CompEx5HTML.class);
n = page.getElementById("SimpleManualID");
Mytext text = new Mytext("a sample text");
text.setView(new DefaultView(n));
root.addChild(text);

3) also return another instance from, say, BTemplate

n = page.getElementById("SimpleTemplateID");
        if (n!=null) {
            BTemplate templateComp = new BTemplate(new
SimpleTemplateModel());
            templateComp.setView(new DefaultTemplateView(n));
            root.addChild(templateComp);
        }
}

class SimpleTemplateModel extends AbstractTemplateModel {
        public String getName() {
            return "Test1";
        }
        public Object getItem(String key) {
            ViewContext vc = getViewContext();
            if (key.equals("Mytext")) {
                return new Mytext("Text from template");
            }
          else return super.getItem(key);
        }


Render all this and you get the following exception :

java.lang.NullPointerException
        at
org.barracudamvc.core.comp.AbstractBComponent.findRendererFactory(AbstractBComponent.java:225)
        at
org.barracudamvc.core.comp.AbstractBComponent.getRenderer(AbstractBComponent.java:195)
        at
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:401)
        at
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
        at
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
        at
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
        at
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
        at
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
        at
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
        at
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
        at
org.barracudamvc.core.comp.renderer.TemplateHelper.render(TemplateHelper.java:131)
        at
org.barracudamvc.core.comp.renderer.html.HTMLTemplateRenderer.renderComponent(HTMLTemplateRenderer.java:88)
        at
org.barracudamvc.core.comp.BComponent.renderView(BComponent.java:647)
        at org.barracudamvc.core.comp.BComponent.render(BComponent.java:557)
        at org.barracudamvc.core.comp.BComponent.render(BComponent.java:576)
        at org.barracudamvc.core.comp.BComponent.render(BComponent.java:473)
        at
org.barracudamvc.core.comp.helper.ComponentGateway.handleDefault(ComponentGateway.java:316)
        at
org.barracudamvc.core.comp.helper.ComponentGateway.doGet(ComponentGateway.java:205)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)


I think it has something to do with the fact that RendererFactory class
and registration are static, and rfDomMap in AbstractBComponent also is
static, but I must admit I can't fully explain what is happening.

The fact is that you barely extends BText, or any other component, but
with the ability to nest components, you will tend to do so (to create
complex ones)...

I can provide a complete example if needed, but I don't have a patch
yet... Can anyone find some time to look at this and give his opinion ?

Franck





--

Barracuda mailing list

Barracuda@...

http://www.objectweb.org/wws/lists/projects/barracuda

[Jacob Kjome]

I'm not sure what the issue is, off the top of my head.  And I'm not sure I'll
get a chance to look at it over the weekend.  Hopefully Christian or others can
comment.

Jake

Quoting Franck Routier <franck.routier@...>:

> Hi all,
>
> I have been working on tests on my nested rendering stuff, and while
> testing, I thought I had introduced a bug somewhere...
> But it turns out to be a bug in stock Barracuda. Well, a weird one...
>
> The scenario is :
>
> 1) extend a component :
>
> class Mytext extends BText {
>     public Mytext(String str) { super(str);}
> }
>
> 2) manually bind an instance of it to a node
>
> Document page =
> DefaultDOMLoader.getGlobalInstance().getDOM(CompEx5HTML.class);
> n = page.getElementById("SimpleManualID");
> Mytext text = new Mytext("a sample text");
> text.setView(new DefaultView(n));
> root.addChild(text);
>
> 3) also return another instance from, say, BTemplate
>
> n = page.getElementById("SimpleTemplateID");
>         if (n!=null) {
>             BTemplate templateComp = new BTemplate(new
> SimpleTemplateModel());
>             templateComp.setView(new DefaultTemplateView(n));
>             root.addChild(templateComp);
>         }
> }
>
> class SimpleTemplateModel extends AbstractTemplateModel {
>         public String getName() {
>             return "Test1";
>         }
>         public Object getItem(String key) {
>             ViewContext vc = getViewContext();
>             if (key.equals("Mytext")) {
>                 return new Mytext("Text from template");
>             }
>           else return super.getItem(key);
>         }
>
>
> Render all this and you get the following exception :
>
> java.lang.NullPointerException
>         at
>

org.barracudamvc.core.comp.AbstractBComponent.findRendererFactory(AbstractBComponent.java:225)
>         at
>

org.barracudamvc.core.comp.AbstractBComponent.getRenderer(AbstractBComponent.java:195)
>         at
>
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:401)
>         at
>
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>         at
>
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>         at
>
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>         at
>
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>         at
>
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>         at
>
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>         at
>
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>         at
>
org.barracudamvc.core.comp.renderer.TemplateHelper.render(TemplateHelper.java:131)
>         at
>
org.barracudamvc.core.comp.renderer.html.HTMLTemplateRenderer.renderComponent(HTMLTemplateRenderer.java:88)
>         at
> org.barracudamvc.core.comp.BComponent.renderView(BComponent.java:647)
>         at org.barracudamvc.core.comp.BComponent.render(BComponent.java:557)
>         at org.barracudamvc.core.comp.BComponent.render(BComponent.java:576)
>         at org.barracudamvc.core.comp.BComponent.render(BComponent.java:473)
>         at
>
org.barracudamvc.core.comp.helper.ComponentGateway.handleDefault(ComponentGateway.java:316)
>         at
>
org.barracudamvc.core.comp.helper.ComponentGateway.doGet(ComponentGateway.java:205)

>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>
>
> I think it has something to do with the fact that RendererFactory class
> and registration are static, and rfDomMap in AbstractBComponent also is
> static, but I must admit I can't fully explain what is happening.
>
> The fact is that you barely extends BText, or any other component, but
> with the ability to nest components, you will tend to do so (to create
> complex ones)...
>
> I can provide a complete example if needed, but I don't have a patch
> yet... Can anyone find some time to look at this and give his opinion ?
>
> Franck
>
>
>

--

Barracuda mailing list

Barracuda@...

http://www.objectweb.org/wws/lists/projects/barracuda

[Franck Routier]

Hi,

ok, I think I have tracked down this particular bug. Here is what happens :

1) MyText, a component extending BText, is manually bound to a node.
2) at rendering phase, AbstractBComponent.getRendererFactory is called
for MyText and the node class (HTMLElementImpl in my case)
3) no rfCompMap exists for MyText, as BText creates one for BText.class,
not MyText.class, and MyText does not override the static
installRendererFactory
4) so getRendererFactory can't find rfCompMap and looks for one using
MyText superclass : BText. Hurray, there is one.
5) but renderer factory for BText / HTMLElementImpl still is null (BText
registers one for HTMLElemenet interface, not its implementation)
6) one is found on HTMLElementImpl superclass HTMLElement. Fine.
7) now we try to be clever... we register this new couple to avoid this
long lookup next time. So we register MyText / HTMLElementImpl...

8) So, now BTemplate is retrieves a MyText component from its model. It
renders and :

9) at rendering phase, AbstractBComponent.getRendererFactory is called
for MyText and the node class HTMLElement
10) getRendererFactory find a rfDomMap for MyText (we just created an
entry for MyText at step 7.)
11) but no rendererFactory, even for HTMLElement superclasses and
interfaces (namely Element and Node)
12) so, we call the protected method findRenderderFactory on
MyText.class and HTMLElement.getSuperClass(). The later is null.
13) NPE in findRendererFactory !!!

So, now for the fix :

1) simply don't register new combinations (step 7). But this might have
an impact on performance (minor ?)
or
2) register every new combination on comp.getSuperClass if rfDomMap was
found on superclass
or
3) register every rendererFactory of comp.getSuperClass for comp if
rfDomMap was found on superclass
or
4) register rf for comp + every superclass / interface of domCl
or
5) mix 3 and 4

Well, I would tend to go for 1. Simple, straightforward. I don't think
if will have a great impact on performance, but I might be wrong here.
So here is my question : does anyone have an opinion on the matter ?

Franck

Jacob Kjome a écrit :

> I'm not sure what the issue is, off the top of my head.  And I'm not sure I'll
> get a chance to look at it over the weekend.  Hopefully Christian or others can
> comment.
>
> Jake
>
> Quoting Franck Routier <franck.routier@...>:
>
>  
>> Hi all,
>>
>> I have been working on tests on my nested rendering stuff, and while
>> testing, I thought I had introduced a bug somewhere...
>> But it turns out to be a bug in stock Barracuda. Well, a weird one...
>>
>> The scenario is :
>>
>> 1) extend a component :
>>
>> class Mytext extends BText {
>>     public Mytext(String str) { super(str);}
>> }
>>
>> 2) manually bind an instance of it to a node
>>
>> Document page =
>> DefaultDOMLoader.getGlobalInstance().getDOM(CompEx5HTML.class);
>> n = page.getElementById("SimpleManualID");
>> Mytext text = new Mytext("a sample text");
>> text.setView(new DefaultView(n));
>> root.addChild(text);
>>
>> 3) also return another instance from, say, BTemplate
>>
>> n = page.getElementById("SimpleTemplateID");
>>         if (n!=null) {
>>             BTemplate templateComp = new BTemplate(new
>> SimpleTemplateModel());
>>             templateComp.setView(new DefaultTemplateView(n));
>>             root.addChild(templateComp);
>>         }
>> }
>>
>> class SimpleTemplateModel extends AbstractTemplateModel {
>>         public String getName() {
>>             return "Test1";
>>         }
>>         public Object getItem(String key) {
>>             ViewContext vc = getViewContext();
>>             if (key.equals("Mytext")) {
>>                 return new Mytext("Text from template");
>>             }
>>           else return super.getItem(key);
>>         }
>>
>>
>> Render all this and you get the following exception :
>>
>> java.lang.NullPointerException
>>         at
>>
>>    
> org.barracudamvc.core.comp.AbstractBComponent.findRendererFactory(AbstractBComponent.java:225)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.AbstractBComponent.getRenderer(AbstractBComponent.java:195)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:401)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.renderer.TemplateHelper.render(TemplateHelper.java:131)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.renderer.html.HTMLTemplateRenderer.renderComponent(HTMLTemplateRenderer.java:88)
>  
>>         at
>> org.barracudamvc.core.comp.BComponent.renderView(BComponent.java:647)
>>         at org.barracudamvc.core.comp.BComponent.render(BComponent.java:557)
>>         at org.barracudamvc.core.comp.BComponent.render(BComponent.java:576)
>>         at org.barracudamvc.core.comp.BComponent.render(BComponent.java:473)
>>         at
>>
>>    
> org.barracudamvc.core.comp.helper.ComponentGateway.handleDefault(ComponentGateway.java:316)
>  
>>         at
>>
>>    
> org.barracudamvc.core.comp.helper.ComponentGateway.doGet(ComponentGateway.java:205)
>  
>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>>
>>
>> I think it has something to do with the fact that RendererFactory class
>> and registration are static, and rfDomMap in AbstractBComponent also is
>> static, but I must admit I can't fully explain what is happening.
>>
>> The fact is that you barely extends BText, or any other component, but
>> with the ability to nest components, you will tend to do so (to create
>> complex ones)...
>>
>> I can provide a complete example if needed, but I don't have a patch
>> yet... Can anyone find some time to look at this and give his opinion ?
>>
>> Franck
>>
>>
>>
>>    
>
>
>
>
>  
> ------------------------------------------------------------------------
>
>
>
> --
>
> Barracuda mailing list
>
> Barracuda@...
>
> http://www.objectweb.org/wws/lists/projects/barracuda
>
>  

--

Barracuda mailing list

Barracuda@...

http://www.objectweb.org/wws/lists/projects/barracuda

[Franck Routier]

After thinking about it, I implemented 2)
- installRendererFactory(rf, cl.getSuperClass(), domCl) when rfCompMap
was found for cl.getSuperClass()

But apart from the fix, I wonder if getRendererFactory would work if I
have a component extending from MyText...

... (tbc)

Franck Routier a écrit :

> Hi,
>
> ok, I think I have tracked down this particular bug. Here is what
> happens :
>
> 1) MyText, a component extending BText, is manually bound to a node.
> 2) at rendering phase, AbstractBComponent.getRendererFactory is called
> for MyText and the node class (HTMLElementImpl in my case)
> 3) no rfCompMap exists for MyText, as BText creates one for
> BText.class, not MyText.class, and MyText does not override the static
> installRendererFactory
> 4) so getRendererFactory can't find rfCompMap and looks for one using
> MyText superclass : BText. Hurray, there is one.
> 5) but renderer factory for BText / HTMLElementImpl still is null
> (BText registers one for HTMLElemenet interface, not its implementation)
> 6) one is found on HTMLElementImpl superclass HTMLElement. Fine.
> 7) now we try to be clever... we register this new couple to avoid
> this long lookup next time. So we register MyText / HTMLElementImpl...
>
> 8) So, now BTemplate is retrieves a MyText component from its model.
> It renders and :
>
> 9) at rendering phase, AbstractBComponent.getRendererFactory is called
> for MyText and the node class HTMLElement
> 10) getRendererFactory find a rfDomMap for MyText (we just created an
> entry for MyText at step 7.)
> 11) but no rendererFactory, even for HTMLElement superclasses and
> interfaces (namely Element and Node)
> 12) so, we call the protected method findRenderderFactory on
> MyText.class and HTMLElement.getSuperClass(). The later is null.
> 13) NPE in findRendererFactory !!!
>
> So, now for the fix :
>
> 1) simply don't register new combinations (step 7). But this might
> have an impact on performance (minor ?)
> or
> 2) register every new combination on comp.getSuperClass if rfDomMap
> was found on superclass
> or
> 3) register every rendererFactory of comp.getSuperClass for comp if
> rfDomMap was found on superclass
> or
> 4) register rf for comp + every superclass / interface of domCl
> or
> 5) mix 3 and 4
>
> Well, I would tend to go for 1. Simple, straightforward. I don't think
> if will have a great impact on performance, but I might be wrong here.
> So here is my question : does anyone have an opinion on the matter ?
>
> Franck
>
> Jacob Kjome a écrit :
>> I'm not sure what the issue is, off the top of my head.  And I'm not
>> sure I'll
>> get a chance to look at it over the weekend.  Hopefully Christian or
>> others can
>> comment.
>>
>> Jake
>>
>> Quoting Franck Routier <franck.routier@...>:
>>
>>  
>>> Hi all,
>>>
>>> I have been working on tests on my nested rendering stuff, and while
>>> testing, I thought I had introduced a bug somewhere...
>>> But it turns out to be a bug in stock Barracuda. Well, a weird one...
>>>
>>> The scenario is :
>>>
>>> 1) extend a component :
>>>
>>> class Mytext extends BText {
>>>     public Mytext(String str) { super(str);}
>>> }
>>>
>>> 2) manually bind an instance of it to a node
>>>
>>> Document page =
>>> DefaultDOMLoader.getGlobalInstance().getDOM(CompEx5HTML.class);
>>> n = page.getElementById("SimpleManualID");
>>> Mytext text = new Mytext("a sample text");
>>> text.setView(new DefaultView(n));
>>> root.addChild(text);
>>>
>>> 3) also return another instance from, say, BTemplate
>>>
>>> n = page.getElementById("SimpleTemplateID");
>>>         if (n!=null) {
>>>             BTemplate templateComp = new BTemplate(new
>>> SimpleTemplateModel());
>>>             templateComp.setView(new DefaultTemplateView(n));
>>>             root.addChild(templateComp);
>>>         }
>>> }
>>>
>>> class SimpleTemplateModel extends AbstractTemplateModel {
>>>         public String getName() {
>>>             return "Test1";
>>>         }
>>>         public Object getItem(String key) {
>>>             ViewContext vc = getViewContext();
>>>             if (key.equals("Mytext")) {
>>>                 return new Mytext("Text from template");
>>>             }
>>>           else return super.getItem(key);
>>>         }
>>>
>>>
>>> Render all this and you get the following exception :
>>>
>>> java.lang.NullPointerException
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.AbstractBComponent.findRendererFactory(AbstractBComponent.java:225)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.AbstractBComponent.getRenderer(AbstractBComponent.java:195)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:401)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.renderer.TemplateHelper.render(TemplateHelper.java:131)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.renderer.html.HTMLTemplateRenderer.renderComponent(HTMLTemplateRenderer.java:88)
>>
>>  
>>>         at
>>> org.barracudamvc.core.comp.BComponent.renderView(BComponent.java:647)
>>>         at
>>> org.barracudamvc.core.comp.BComponent.render(BComponent.java:557)
>>>         at
>>> org.barracudamvc.core.comp.BComponent.render(BComponent.java:576)
>>>         at
>>> org.barracudamvc.core.comp.BComponent.render(BComponent.java:473)
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.helper.ComponentGateway.handleDefault(ComponentGateway.java:316)
>>
>>  
>>>         at
>>>
>>>    
>> org.barracudamvc.core.comp.helper.ComponentGateway.doGet(ComponentGateway.java:205)
>>
>>  
>>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
>>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>>>
>>>
>>> I think it has something to do with the fact that RendererFactory class
>>> and registration are static, and rfDomMap in AbstractBComponent also is
>>> static, but I must admit I can't fully explain what is happening.
>>>
>>> The fact is that you barely extends BText, or any other component, but
>>> with the ability to nest components, you will tend to do so (to create
>>> complex ones)...
>>>
>>> I can provide a complete example if needed, but I don't have a patch
>>> yet... Can anyone find some time to look at this and give his opinion ?
>>>
>>> Franck
>>>
>>>
>>>
>>>    
>>
>>
>>
>>
>>  
>> ------------------------------------------------------------------------
>>
>>
>>
>> --
>>
>> Barracuda mailing list
>>
>> Barracuda@...
>>
>> http://www.objectweb.org/wws/lists/projects/barracuda
>>
>>  
>
>
>
> ------------------------------------------------------------------------
>
>
>
> --
>
> Barracuda mailing list
>
> Barracuda@...
>
> http://www.objectweb.org/wws/lists/projects/barracuda
>
>  

--

Barracuda mailing list

Barracuda@...

http://www.objectweb.org/wws/lists/projects/barracuda

[Jacob Kjome]

Hi Franck,

I updated the trunk with XMLC-2.2.14 as well as a
couple other jar updates and minor build.xml
updates to get rid of warnings under
Ant-1.7.0.  Would you mind making these changes
on the branches we care about?  I don't have time
tonight, nor am I overly familiar dealing with
SVN branching/tagging.  Here's the change set....

Modified: D:\dev\Barracuda\WEB-INF\A_Changes_History.txt
Modified: D:\dev\Barracuda\WEB-INF\bin\build.xml
Modified: D:\dev\Barracuda\WEB-INF\bin\version.properties
Modified: D:\dev\Barracuda\WEB-INF\jars\A_ReadMe.txt
Deleting: D:\dev\Barracuda\WEB-INF\jars\commons-fileupload-1.1.1.jar
Adding:
D:\dev\Barracuda\WEB-INF\jars\commons-fileupload-1.2.jar
application/octet-stream
Deleting: D:\dev\Barracuda\WEB-INF\jars\commons-io-1.2.jar
Adding:
D:\dev\Barracuda\WEB-INF\jars\commons-io-1.3.1.jar  application/octet-stream
Deleting: D:\dev\Barracuda\WEB-INF\jars\jtidy-r7-xmlc-2.2.13.jar
Adding:
D:\dev\Barracuda\WEB-INF\jars\jtidy-r7-xmlc-2.2.14.jar
application/octet-stream
Deleting: D:\dev\Barracuda\WEB-INF\jars\xmlc-all-runtime-2.2.13.jar
Adding:
D:\dev\Barracuda\WEB-INF\jars\xmlc-all-runtime-2.2.14.jar
application/octet-stream
Deleting: D:\dev\Barracuda\WEB-INF\jars\xmlc-taskdef-2.2.13.jar
Adding:
D:\dev\Barracuda\WEB-INF\jars\xmlc-taskdef-2.2.14.jar  application/octet-stream
Modified:
D:\dev\Barracuda\WEB-INF\src\org\barracudamvc\contrib\dbroggisch\webapp\build.xml

Modified:
D:\dev\Barracuda\WEB-INF\src\org\barracudamvc\contrib\sam\webapp\build.xml


BTW, you may want to update A_Changes_History.txt with your recent changes.

thanks,

Jake

At 01:05 PM 3/12/2007, you wrote:
 >
 >Hi Franck,
 >
 >I think we should get the latest release of
XMLC into 2.1.  That should be the
 >last checkin required.  I'll see if I can do
this tonight unless you want to do
 >it.  If you do, make sure to remember to update the README files in lib/jar
 >directory as well as update the version.properties file to reference the new
 >versions.  Note the updated version would be XMLC-2.2.14, not 2.3_beta3.
 >
 >Then make sure the contrib stuff builds...
 >
 >ant contrib -Dsubproject=all -Dsubtarget=rewar
 >
 >
 >Jake
 >
 >Quoting Franck Routier <franck.routier@...>:
 >
 >> Hi,
 >>
 >> I have commited a patch to :
 >> - avoid NPE when calling findRendererFactory with a null
 >> domCl.getSuperclass()
 >> - search for renderers on Component superclasses, to handle custom
 >> component extending from a standard BComponent with unlimited depth
 >>
 >> As this last try is done last, I am pretty sure it won't impact
 >> performance, as the previous code is still used first.
 >>
 >> I have committed the fix in trunk, branches/legacy-pre-jdk15 and tags/2.1
 >> This should be the first and last time we commit in 2.1 !!! But I wanted
 >> to have all known bugs fixed in 2.1 before communicating on it and
 >> considering it a release.
 >>
 >> So now I think we are ready to let the world
know Barracudamvc 2.1 is out :)
 >>
 >> Franck
 >>
 >>
 >>
 >> Franck Routier a écrit :
 >> > After thinking about it, I implemented 2)
 >> > - installRendererFactory(rf, cl.getSuperClass(), domCl) when rfCompMap
 >> > was found for cl.getSuperClass()
 >> >
 >> > But apart from the fix, I wonder if getRendererFactory would work if I
 >> > have a component extending from MyText...
 >> >
 >> > ... (tbc)
 >> >
 >> > Franck Routier a écrit :
 >> >> Hi,
 >> >>
 >> >> ok, I think I have tracked down this particular bug. Here is what
 >> >> happens :
 >> >>
 >> >> 1) MyText, a component extending BText, is manually bound to a node.
 >> >> 2) at rendering phase, AbstractBComponent.getRendererFactory is
 >> >> called for MyText and the node class (HTMLElementImpl in my case)
 >> >> 3) no rfCompMap exists for MyText, as BText creates one for
 >> >> BText.class, not MyText.class, and MyText does not override the
 >> >> static installRendererFactory
 >> >> 4) so getRendererFactory can't find rfCompMap and looks for one using
 >> >> MyText superclass : BText. Hurray, there is one.
 >> >> 5) but renderer factory for BText / HTMLElementImpl still is null
 >> >> (BText registers one for HTMLElemenet interface, not its implementation)
 >> >> 6) one is found on HTMLElementImpl superclass HTMLElement. Fine.
 >> >> 7) now we try to be clever... we register this new couple to avoid
 >> >> this long lookup next time. So we register MyText / HTMLElementImpl...
 >> >>
 >> >> 8) So, now BTemplate is retrieves a MyText component from its model.
 >> >> It renders and :
 >> >>
 >> >> 9) at rendering phase, AbstractBComponent.getRendererFactory is
 >> >> called for MyText and the node class HTMLElement
 >> >> 10) getRendererFactory find a rfDomMap for MyText (we just created an
 >> >> entry for MyText at step 7.)
 >> >> 11) but no rendererFactory, even for HTMLElement superclasses and
 >> >> interfaces (namely Element and Node)
 >> >> 12) so, we call the protected method findRenderderFactory on
 >> >> MyText.class and HTMLElement.getSuperClass(). The later is null.
 >> >> 13) NPE in findRendererFactory !!!
 >> >>
 >> >> So, now for the fix :
 >> >>
 >> >> 1) simply don't register new combinations (step 7). But this might
 >> >> have an impact on performance (minor ?)
 >> >> or
 >> >> 2) register every new combination on comp.getSuperClass if rfDomMap
 >> >> was found on superclass
 >> >> or
 >> >> 3) register every rendererFactory of comp.getSuperClass for comp if
 >> >> rfDomMap was found on superclass
 >> >> or
 >> >> 4) register rf for comp + every superclass / interface of domCl
 >> >> or
 >> >> 5) mix 3 and 4
 >> >>
 >> >> Well, I would tend to go for 1. Simple, straightforward. I don't
 >> >> think if will have a great impact on performance, but I might be
 >> >> wrong here.
 >> >> So here is my question : does anyone have an opinion on the matter ?
 >> >>
 >> >> Franck
 >> >>
 >> >> Jacob Kjome a écrit :
 >> >>> I'm not sure what the issue is, off the top of my head.  And I'm not
 >> >>> sure I'll
 >> >>> get a chance to look at it over the weekend.  Hopefully Christian or
 >> >>> others can
 >> >>> comment.
 >> >>>
 >> >>> Jake
 >> >>>
 >> >>> Quoting Franck Routier <franck.routier@...>:
 >> >>>
 >> >>>
 >> >>>> Hi all,
 >> >>>>
 >> >>>> I have been working on tests on my nested rendering stuff, and while
 >> >>>> testing, I thought I had introduced a bug somewhere...
 >> >>>> But it turns out to be a bug in stock Barracuda. Well, a weird one...
 >> >>>>
 >> >>>> The scenario is :
 >> >>>>
 >> >>>> 1) extend a component :
 >> >>>>
 >> >>>> class Mytext extends BText {
 >> >>>>     public Mytext(String str) { super(str);}
 >> >>>> }
 >> >>>>
 >> >>>> 2) manually bind an instance of it to a node
 >> >>>>
 >> >>>> Document page =
 >> >>>> DefaultDOMLoader.getGlobalInstance().getDOM(CompEx5HTML.class);
 >> >>>> n = page.getElementById("SimpleManualID");
 >> >>>> Mytext text = new Mytext("a sample text");
 >> >>>> text.setView(new DefaultView(n));
 >> >>>> root.addChild(text);
 >> >>>>
 >> >>>> 3) also return another instance from, say, BTemplate
 >> >>>>
 >> >>>> n = page.getElementById("SimpleTemplateID");
 >> >>>>         if (n!=null) {
 >> >>>>             BTemplate templateComp = new BTemplate(new
 >> >>>> SimpleTemplateModel());
 >> >>>>             templateComp.setView(new DefaultTemplateView(n));
 >> >>>>             root.addChild(templateComp);
 >> >>>>         }
 >> >>>> }
 >> >>>>
 >> >>>> class SimpleTemplateModel extends AbstractTemplateModel {
 >> >>>>         public String getName() {
 >> >>>>             return "Test1";
 >> >>>>         }
 >> >>>>         public Object getItem(String key) {
 >> >>>>             ViewContext vc = getViewContext();
 >> >>>>             if (key.equals("Mytext")) {
 >> >>>>                 return new Mytext("Text from template");
 >> >>>>             }
 >> >>>>           else return super.getItem(key);
 >> >>>>         }
 >> >>>>
 >> >>>>
 >> >>>> Render all this and you get the following exception :
 >> >>>>
 >> >>>> java.lang.NullPointerException
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.AbstractBComponent.findRendererFactory(Abst
 >ractBComponent.java:225)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.AbstractBComponent.getRenderer(AbstractBCom
 >ponent.java:195)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHel
 >per.java:401)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(Temp
 >lateHelper.java:153)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHel
 >per.java:836)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(Temp
 >lateHelper.java:153)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHel
 >per.java:836)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(Temp
 >lateHelper.java:153)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHel
 >per.java:836)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(Temp
 >lateHelper.java:153)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.renderer.TemplateHelper.render(TemplateHelp
 >er.java:131)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.renderer.html.HTMLTemplateRenderer.renderCo
 >mponent(HTMLTemplateRenderer.java:88)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>> org.barracudamvc.core.comp.BComponent.renderView(BComponent.java:647)
 >> >>>>         at
 >> >>>> org.barracudamvc.core.comp.BComponent.render(BComponent.java:557)
 >> >>>>         at
 >> >>>> org.barracudamvc.core.comp.BComponent.render(BComponent.java:576)
 >> >>>>         at
 >> >>>> org.barracudamvc.core.comp.BComponent.render(BComponent.java:473)
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.helper.ComponentGateway.handleDefault(Compo
 >nentGateway.java:316)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>>
 >> >>>>
 >> >>>
 >>
 >org.barracudamvc.core.comp.helper.ComponentGateway.doGet(ComponentGate
 >way.java:205)
 >> >>>
 >> >>>
 >> >>>>         at
 >> >>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
 >> >>>>         at
 >> >>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
 >> >>>>
 >> >>>>
 >> >>>> I think it has something to do with the fact that RendererFactory
 >> >>>> class
 >> >>>> and registration are static, and rfDomMap in AbstractBComponent
 >> >>>> also is
 >> >>>> static, but I must admit I can't fully explain what is happening.
 >> >>>>
 >> >>>> The fact is that you barely extends BText, or any other component, but
 >> >>>> with the ability to nest components, you will tend to do so (to create
 >> >>>> complex ones)...
 >> >>>>
 >> >>>> I can provide a complete example if needed, but I don't have a patch
 >> >>>> yet... Can anyone find some time to look at this and give his
 >> >>>> opinion ?
 >> >>>>
 >> >>>> Franck
 >> >>>>
 >> >>>>
 >> >>>>
 >> >>>>
 >> >>>
 >> >>>
 >> >>>
 >> >>>
 >> >>>
 >> >>>
------------------------------------------------------------------------
 >> >>>
 >> >>>
 >> >>>
 >> >>>
 >> >>> --
 >> >>>
 >> >>> Barracuda mailing list
 >> >>>
 >> >>> Barracuda@...
 >> >>>
 >> >>> http://www.objectweb.org/wws/lists/projects/barracuda
 >> >>>
 >> >>>
 >> >>
 >> >>
 >> >>
 >> >> ------------------------------------------------------------------------
 >> >>
 >> >>
 >> >>
 >> >> --
 >> >>
 >> >> Barracuda mailing list
 >> >>
 >> >> Barracuda@...
 >> >>
 >> >> http://www.objectweb.org/wws/lists/projects/barracuda
 >> >>
 >> >>
 >> >
 >> >
 >> >
 >> > ------------------------------------------------------------------------
 >> >
 >> >
 >> >
 >> > --
 >> >
 >> > Barracuda mailing list
 >> >
 >> > Barracuda@...
 >> >
 >> > http://www.objectweb.org/wws/lists/projects/barracuda
 >> >
 >> >
 >>
 >>
 >>
 >>
 >
 >
 >
 >
 >
 >
 >
 >--
 >
 >Barracuda mailing list
 >
 >Barracuda@...
 >
 >http://www.objectweb.org/wws/lists/projects/barracuda





--

Barracuda mailing list

Barracuda@...

http://www.objectweb.org/wws/lists/projects/barracuda

[Franck Routier]

Hi,

I have commited a patch to :
- avoid NPE when calling findRendererFactory with a null
domCl.getSuperclass()
- search for renderers on Component superclasses, to handle custom
component extending from a standard BComponent with unlimited depth

As this last try is done last, I am pretty sure it won't impact
performance, as the previous code is still used first.

I have committed the fix in trunk, branches/legacy-pre-jdk15 and tags/2.1
This should be the first and last time we commit in 2.1 !!! But I wanted
to have all known bugs fixed in 2.1 before communicating on it and
considering it a release.

So now I think we are ready to let the world know Barracudamvc 2.1 is out :)

Franck



Franck Routier a écrit :

> After thinking about it, I implemented 2)
> - installRendererFactory(rf, cl.getSuperClass(), domCl) when rfCompMap
> was found for cl.getSuperClass()
>
> But apart from the fix, I wonder if getRendererFactory would work if I
> have a component extending from MyText...
>
> ... (tbc)
>
> Franck Routier a écrit :
>> Hi,
>>
>> ok, I think I have tracked down this particular bug. Here is what
>> happens :
>>
>> 1) MyText, a component extending BText, is manually bound to a node.
>> 2) at rendering phase, AbstractBComponent.getRendererFactory is
>> called for MyText and the node class (HTMLElementImpl in my case)
>> 3) no rfCompMap exists for MyText, as BText creates one for
>> BText.class, not MyText.class, and MyText does not override the
>> static installRendererFactory
>> 4) so getRendererFactory can't find rfCompMap and looks for one using
>> MyText superclass : BText. Hurray, there is one.
>> 5) but renderer factory for BText / HTMLElementImpl still is null
>> (BText registers one for HTMLElemenet interface, not its implementation)
>> 6) one is found on HTMLElementImpl superclass HTMLElement. Fine.
>> 7) now we try to be clever... we register this new couple to avoid
>> this long lookup next time. So we register MyText / HTMLElementImpl...
>>
>> 8) So, now BTemplate is retrieves a MyText component from its model.
>> It renders and :
>>
>> 9) at rendering phase, AbstractBComponent.getRendererFactory is
>> called for MyText and the node class HTMLElement
>> 10) getRendererFactory find a rfDomMap for MyText (we just created an
>> entry for MyText at step 7.)
>> 11) but no rendererFactory, even for HTMLElement superclasses and
>> interfaces (namely Element and Node)
>> 12) so, we call the protected method findRenderderFactory on
>> MyText.class and HTMLElement.getSuperClass(). The later is null.
>> 13) NPE in findRendererFactory !!!
>>
>> So, now for the fix :
>>
>> 1) simply don't register new combinations (step 7). But this might
>> have an impact on performance (minor ?)
>> or
>> 2) register every new combination on comp.getSuperClass if rfDomMap
>> was found on superclass
>> or
>> 3) register every rendererFactory of comp.getSuperClass for comp if
>> rfDomMap was found on superclass
>> or
>> 4) register rf for comp + every superclass / interface of domCl
>> or
>> 5) mix 3 and 4
>>
>> Well, I would tend to go for 1. Simple, straightforward. I don't
>> think if will have a great impact on performance, but I might be
>> wrong here.
>> So here is my question : does anyone have an opinion on the matter ?
>>
>> Franck
>>
>> Jacob Kjome a écrit :
>>> I'm not sure what the issue is, off the top of my head.  And I'm not
>>> sure I'll
>>> get a chance to look at it over the weekend.  Hopefully Christian or
>>> others can
>>> comment.
>>>
>>> Jake
>>>
>>> Quoting Franck Routier <franck.routier@...>:
>>>
>>>  
>>>> Hi all,
>>>>
>>>> I have been working on tests on my nested rendering stuff, and while
>>>> testing, I thought I had introduced a bug somewhere...
>>>> But it turns out to be a bug in stock Barracuda. Well, a weird one...
>>>>
>>>> The scenario is :
>>>>
>>>> 1) extend a component :
>>>>
>>>> class Mytext extends BText {
>>>>     public Mytext(String str) { super(str);}
>>>> }
>>>>
>>>> 2) manually bind an instance of it to a node
>>>>
>>>> Document page =
>>>> DefaultDOMLoader.getGlobalInstance().getDOM(CompEx5HTML.class);
>>>> n = page.getElementById("SimpleManualID");
>>>> Mytext text = new Mytext("a sample text");
>>>> text.setView(new DefaultView(n));
>>>> root.addChild(text);
>>>>
>>>> 3) also return another instance from, say, BTemplate
>>>>
>>>> n = page.getElementById("SimpleTemplateID");
>>>>         if (n!=null) {
>>>>             BTemplate templateComp = new BTemplate(new
>>>> SimpleTemplateModel());
>>>>             templateComp.setView(new DefaultTemplateView(n));
>>>>             root.addChild(templateComp);
>>>>         }
>>>> }
>>>>
>>>> class SimpleTemplateModel extends AbstractTemplateModel {
>>>>         public String getName() {
>>>>             return "Test1";
>>>>         }
>>>>         public Object getItem(String key) {
>>>>             ViewContext vc = getViewContext();
>>>>             if (key.equals("Mytext")) {
>>>>                 return new Mytext("Text from template");
>>>>             }
>>>>           else return super.getItem(key);
>>>>         }
>>>>
>>>>
>>>> Render all this and you get the following exception :
>>>>
>>>> java.lang.NullPointerException
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.AbstractBComponent.findRendererFactory(AbstractBComponent.java:225)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.AbstractBComponent.getRenderer(AbstractBComponent.java:195)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:401)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.renderer.TemplateHelper.render(TemplateHelper.java:131)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.renderer.html.HTMLTemplateRenderer.renderComponent(HTMLTemplateRenderer.java:88)
>>>
>>>  
>>>>         at
>>>> org.barracudamvc.core.comp.BComponent.renderView(BComponent.java:647)
>>>>         at
>>>> org.barracudamvc.core.comp.BComponent.render(BComponent.java:557)
>>>>         at
>>>> org.barracudamvc.core.comp.BComponent.render(BComponent.java:576)
>>>>         at
>>>> org.barracudamvc.core.comp.BComponent.render(BComponent.java:473)
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.helper.ComponentGateway.handleDefault(ComponentGateway.java:316)
>>>
>>>  
>>>>         at
>>>>
>>>>    
>>> org.barracudamvc.core.comp.helper.ComponentGateway.doGet(ComponentGateway.java:205)
>>>
>>>  
>>>>         at
>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
>>>>         at
>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>>>>
>>>>
>>>> I think it has something to do with the fact that RendererFactory
>>>> class
>>>> and registration are static, and rfDomMap in AbstractBComponent
>>>> also is
>>>> static, but I must admit I can't fully explain what is happening.
>>>>
>>>> The fact is that you barely extends BText, or any other component, but
>>>> with the ability to nest components, you will tend to do so (to create
>>>> complex ones)...
>>>>
>>>> I can provide a complete example if needed, but I don't have a patch
>>>> yet... Can anyone find some time to look at this and give his
>>>> opinion ?
>>>>
>>>> Franck
>>>>
>>>>
>>>>
>>>>    
>>>
>>>
>>>
>>>
>>>  
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Barracuda mailing list
>>>
>>> Barracuda@...
>>>
>>> http://www.objectweb.org/wws/lists/projects/barracuda
>>>
>>>  
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> --
>>
>> Barracuda mailing list
>>
>> Barracuda@...
>>
>> http://www.objectweb.org/wws/lists/projects/barracuda
>>
>>  
>
>
>
> ------------------------------------------------------------------------
>
>
>
> --
>
> Barracuda mailing list
>
> Barracuda@...
>
> http://www.objectweb.org/wws/lists/projects/barracuda
>
>  

--

Barracuda mailing list

Barracuda@...

http://www.objectweb.org/wws/lists/projects/barracuda

[Jacob Kjome]

Hi Franck,

I think we should get the latest release of XMLC into 2.1.  That should be the
last checkin required.  I'll see if I can do this tonight unless you want to do
it.  If you do, make sure to remember to update the README files in lib/jar
directory as well as update the version.properties file to reference the new
versions.  Note the updated version would be XMLC-2.2.14, not 2.3_beta3.

Then make sure the contrib stuff builds...

ant contrib -Dsubproject=all -Dsubtarget=rewar


Jake

Quoting Franck Routier <franck.routier@...>:

> Hi,
>
> I have commited a patch to :
> - avoid NPE when calling findRendererFactory with a null
> domCl.getSuperclass()
> - search for renderers on Component superclasses, to handle custom
> component extending from a standard BComponent with unlimited depth
>
> As this last try is done last, I am pretty sure it won't impact
> performance, as the previous code is still used first.
>
> I have committed the fix in trunk, branches/legacy-pre-jdk15 and tags/2.1
> This should be the first and last time we commit in 2.1 !!! But I wanted
> to have all known bugs fixed in 2.1 before communicating on it and
> considering it a release.
>
> So now I think we are ready to let the world know Barracudamvc 2.1 is out :)
>
> Franck
>
>
>
> Franck Routier a écrit :
> > After thinking about it, I implemented 2)
> > - installRendererFactory(rf, cl.getSuperClass(), domCl) when rfCompMap
> > was found for cl.getSuperClass()
> >
> > But apart from the fix, I wonder if getRendererFactory would work if I
> > have a component extending from MyText...
> >
> > ... (tbc)
> >
> > Franck Routier a écrit :
> >> Hi,
> >>
> >> ok, I think I have tracked down this particular bug. Here is what
> >> happens :
> >>
> >> 1) MyText, a component extending BText, is manually bound to a node.
> >> 2) at rendering phase, AbstractBComponent.getRendererFactory is
> >> called for MyText and the node class (HTMLElementImpl in my case)
> >> 3) no rfCompMap exists for MyText, as BText creates one for
> >> BText.class, not MyText.class, and MyText does not override the
> >> static installRendererFactory
> >> 4) so getRendererFactory can't find rfCompMap and looks for one using
> >> MyText superclass : BText. Hurray, there is one.
> >> 5) but renderer factory for BText / HTMLElementImpl still is null
> >> (BText registers one for HTMLElemenet interface, not its implementation)
> >> 6) one is found on HTMLElementImpl superclass HTMLElement. Fine.
> >> 7) now we try to be clever... we register this new couple to avoid
> >> this long lookup next time. So we register MyText / HTMLElementImpl...
> >>
> >> 8) So, now BTemplate is retrieves a MyText component from its model.
> >> It renders and :
> >>
> >> 9) at rendering phase, AbstractBComponent.getRendererFactory is
> >> called for MyText and the node class HTMLElement
> >> 10) getRendererFactory find a rfDomMap for MyText (we just created an
> >> entry for MyText at step 7.)
> >> 11) but no rendererFactory, even for HTMLElement superclasses and
> >> interfaces (namely Element and Node)
> >> 12) so, we call the protected method findRenderderFactory on
> >> MyText.class and HTMLElement.getSuperClass(). The later is null.
> >> 13) NPE in findRendererFactory !!!
> >>
> >> So, now for the fix :
> >>
> >> 1) simply don't register new combinations (step 7). But this might
> >> have an impact on performance (minor ?)
> >> or
> >> 2) register every new combination on comp.getSuperClass if rfDomMap
> >> was found on superclass
> >> or
> >> 3) register every rendererFactory of comp.getSuperClass for comp if
> >> rfDomMap was found on superclass
> >> or
> >> 4) register rf for comp + every superclass / interface of domCl
> >> or
> >> 5) mix 3 and 4
> >>
> >> Well, I would tend to go for 1. Simple, straightforward. I don't
> >> think if will have a great impact on performance, but I might be
> >> wrong here.
> >> So here is my question : does anyone have an opinion on the matter ?
> >>
> >> Franck
> >>
> >> Jacob Kjome a écrit :
> >>> I'm not sure what the issue is, off the top of my head.  And I'm not
> >>> sure I'll
> >>> get a chance to look at it over the weekend.  Hopefully Christian or
> >>> others can
> >>> comment.
> >>>
> >>> Jake
> >>>
> >>> Quoting Franck Routier <franck.routier@...>:
> >>>
> >>>
> >>>> Hi all,
> >>>>
> >>>> I have been working on tests on my nested rendering stuff, and while
> >>>> testing, I thought I had introduced a bug somewhere...
> >>>> But it turns out to be a bug in stock Barracuda. Well, a weird one...
> >>>>
> >>>> The scenario is :
> >>>>
> >>>> 1) extend a component :
> >>>>
> >>>> class Mytext extends BText {
> >>>>     public Mytext(String str) { super(str);}
> >>>> }
> >>>>
> >>>> 2) manually bind an instance of it to a node
> >>>>
> >>>> Document page =
> >>>> DefaultDOMLoader.getGlobalInstance().getDOM(CompEx5HTML.class);
> >>>> n = page.getElementById("SimpleManualID");
> >>>> Mytext text = new Mytext("a sample text");
> >>>> text.setView(new DefaultView(n));
> >>>> root.addChild(text);
> >>>>
> >>>> 3) also return another instance from, say, BTemplate
> >>>>
> >>>> n = page.getElementById("SimpleTemplateID");
> >>>>         if (n!=null) {
> >>>>             BTemplate templateComp = new BTemplate(new
> >>>> SimpleTemplateModel());
> >>>>             templateComp.setView(new DefaultTemplateView(n));
> >>>>             root.addChild(templateComp);
> >>>>         }
> >>>> }
> >>>>
> >>>> class SimpleTemplateModel extends AbstractTemplateModel {
> >>>>         public String getName() {
> >>>>             return "Test1";
> >>>>         }
> >>>>         public Object getItem(String key) {
> >>>>             ViewContext vc = getViewContext();
> >>>>             if (key.equals("Mytext")) {
> >>>>                 return new Mytext("Text from template");
> >>>>             }
> >>>>           else return super.getItem(key);
> >>>>         }
> >>>>
> >>>>
> >>>> Render all this and you get the following exception :
> >>>>
> >>>> java.lang.NullPointerException
> >>>>         at
> >>>>
> >>>>
> >>>
>

org.barracudamvc.core.comp.AbstractBComponent.findRendererFactory(AbstractBComponent.java:225)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>

org.barracudamvc.core.comp.AbstractBComponent.getRenderer(AbstractBComponent.java:195)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:401)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>
org.barracudamvc.core.comp.renderer.TemplateHelper.getNode(TemplateHelper.java:836)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>
org.barracudamvc.core.comp.renderer.TemplateHelper.copyChildNodes(TemplateHelper.java:153)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>
org.barracudamvc.core.comp.renderer.TemplateHelper.render(TemplateHelper.java:131)
> >>>
> >>>
> >>>>         at
> >>>>
> >>>>
> >>>
>
org.barracudamvc.core.comp.renderer.html.HTMLTemplateRenderer.renderComponent(HTMLTemplateRenderer.java:88)

> >>>
> >>>
> >>>>         at
> >>>> org.barracudamvc.core.comp.BComponent.renderView(BComponent.java:647)
> >>>