Bug in ELTools

[vsvetoslavov]

I am sorry I can't provide source to reproduce this one - it will be too much of a hassle - I am doing a facelets component (ui:composition) called propertiesEditor, inside it I place another custom facelets component (another ui:composition) called propertyColumn, and the propertiesEditor contains a grid inside which I place the propertyColumn tags which produce datatableColumn-s. Anyway, this is way too much magic to be worth reproducing. Long story short - I get a weird exception: Stirng index out of range: -3 I can attach the stack trace if necessary, but here's the top lines of the last cause

Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -3
	at java.lang.String.substring(String.java:1967)
	at net.bootsfaces.beans.ELTools.evaluteBaseForMojarra(ELTools.java:366)
	at net.bootsfaces.beans.ELTools.readAnnotations(ELTools.java:337)
	at net.bootsfaces.beans.ELTools.readAnnotations(ELTools.java:408)

So I opened ELTools there we have this:

		String exp = p_expression.getExpressionString();
		int endOfBaseName = exp.lastIndexOf('.');
		int mapDelimiterPos = exp.lastIndexOf('[');
		if (mapDelimiterPos >= 0) {
			int mapEndDelimiterPos = exp.lastIndexOf(']');
			if (endOfBaseName < mapEndDelimiterPos) {
				endOfBaseName = mapDelimiterPos; // treat the [...] as field
			}
		}

		String basename = exp.substring(2, endOfBaseName);

Now obviously if the name contains no . or [, we end up with substring(2, -1) which seems wrong. In my case, changing the control's required="#{required3}" to required="#{[required3]}" led me to a different error about a property not being writable. What is more interesting, though, is that changing the <b:inputText> that I was using to <h:inputText> works just fine - no even property not writable exception. I can show more details via some private channel, because, as I said before, I think it is not worth it reproducing my entire scenario, it is way too complex and one can easily get lost there (at least I can) :) But my point was about ELTools - should this logic be changed? To me it seems wrong to expect always names with either . or surrounded by [ ].... BootsFaces Version: 1.2.0

[stephanrauh]

BootsFaces 1.3 has a guard preventing the exception. Instead, it logs a warning ("there's no getter to access"). Would you mind to run a test with your application and BootsFaces 1.3.0? Does this solve the bug?

If so, we should remove the warning. When I implemented the code, I didn't think of your use case, but of course, it's a valid one. So I don't see a point in emitting confusing warnings in the log file.

[vsvetoslavov]

@stephanrauh The problem is the first exception - the string index one. As for the second - the list is a read only property, I think it is wrong to look for a setter of a collection-typed property. Instead, things should be applied on the items of the collection. But again - this could be an error on my side - I get so lost in all my sh*t there, that I can not guarantee... :) I will try switching to BF1.3 and see if this changes.

[stephanrauh]

You're right, the ELTools code is one of the most sophisticated classes in BootsFaces. :) It's useful, but as time passes, I'm starting to learn there are many more use cases than I've dreamed of when I created the class. That said, I'm looking forward to the result of your BF 1.3 compatibility test!

[vsvetoslavov]

I just tried v. 1.3. The exception about the string index is gone (hurray!) but I still can't use the <b:inputText> in my case. @stephanrauh Can you test with a composite component (ui:composition with a taglib) and inside that composite component - a b:inputText, and having an attribute in the composite component for allowing the component consumer to define what value to edit in the b:inputText? Example ui:composite ...<b:inputText value="#{editorValue}" />... </ui:composite> and in the taglib definition you can define an attribute(String) editorValue. I also tried passing an object and propertyName and declaring editor value like <c:set var="editorValue" value="#{myObject[myProperty]}" /> But this does not work. I'd expect that the output from any errors is much more meaningful to bootsfaces devs than to me ;)

[stephanrauh]

Currently I'm abroad, so please apologize my slow answers. It's a nasty surprise only a part of the bug is solved. I'll have a look - but it may take a while.

[stephanrauh]

@vsvetoslavov Did you try this?

(That doesn't work. I suppose the right way to do it is to pass #{myBean.myAttribute}, not just the variable name. In this case, you can simply omit the type of the attribute. Have a look at my second commit, maybe it's what you're looking for).

[stephanrauh]

I'm afraid development of BootsFaces has slowed down considerably. We'll never manage to address this issue. Let's close it.