I’m not an dtd expert but what I think happened is we added support for this stuff if one writes the Annotations programatically
(which is what our tests doit) but we didn’t update our dtd. If you compiled from source it is here.
Hi,
Referring to the doc http://www.terracotta.org/confluence/display/docs1/AspectWerkz+Pattern+Language , I tried to configure several methods in a class for auto-lock, but I got error message from TC plugin, which told me that the string given does not follow the pattern language. Hope anybody can figure out the cause here…
The methods that need marking out do not follow similar patterns. So I created an annotation class and mark all those methods with it. The method expression is:
@PlayMethod * org.red5.server.stream.PlaylistSubscriberStream$PlayEngine.* (..), where “PlayMethod” is an annotation that locates in the same package as PlaylistSubscriberStream.
As is described in the doc, the method expression takes the form:
<return\_type\_pattern> <package\_and\_class\_pattern>
So I also tried this:
@PlayMethod \* \* org.red5.server.stream.PlaylistSubscriberStream$PlayEngine.\*(..)
But unfortunately I got the same error. I haven't tried to force running the TC server.
Any clues?
--
I cannot tell why this heart languishes in silence. It is for small needs it never asks, or knows or remembers. -- Tagore
Best Regards
Steven Gong
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
tc-users mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-users
</div>
{:.comment-heading}
### **Eugene Kuleshov** 2007-05-26
I committed fix for the xsd schema and will add in-container test later. In a mean time you can try build from trunk.
I am tempted to remove those regexp patterns from xsd, because they aren’t completely match to the real expressions and expressions are validated by AW anyways. Maybe we can move expression validation somewhere closer to config loading.
Still doesn’t work for me. Do we have to do something to make the changes to the xsd take effect. I half remember us having to but I don’t remember what.
I’m not an dtd expert but what I think happened is we added support for this stuff if one writes the Annotations programatically (which is what our tests doit) but we didn’t update our dtd. If you compiled from source it is here.
./code/base/common/src.resources/com/tc/config/schema/terracotta-3.xsd
I filed a bug and will see if we can get it worked out quickly.
http://jira.terracotta.org/jira/browse/CDV-281
Cheers, Steven Harris
Director of Engineering [email protected] www.terracotta.org
On May 26, 2007, at 5:41 AM, Steven Gong wrote:
Hi, Referring to the doc http://www.terracotta.org/confluence/display/docs1/AspectWerkz+Pattern+Language , I tried to configure several methods in a class for auto-lock, but I got error message from TC plugin, which told me that the string given does not follow the pattern language. Hope anybody can figure out the cause here…
The methods that need marking out do not follow similar patterns. So I created an annotation class and mark all those methods with it. The method expression is: @PlayMethod * org.red5.server.stream.PlaylistSubscriberStream$PlayEngine.* (..), where “PlayMethod” is an annotation that locates in the same package as PlaylistSubscriberStream.
As is described in the doc, the method expression takes the form:
I committed fix for the xsd schema and will add in-container test later. In a mean time you can try build from trunk.
I am tempted to remove those regexp patterns from xsd, because they aren’t completely match to the real expressions and expressions are validated by AW anyways. Maybe we can move expression validation somewhere closer to config loading.
Still doesn’t work for me. Do we have to do something to make the changes to the xsd take effect. I half remember us having to but I don’t remember what.
Shoot. I forgot to regenerate config classes (another reason to remove those patterns). Committed updated tcconfig-xmlbeans-generated.jar now.
Lets create a seperate issue for the getting rid of the patterns so that we can close this one out. thx for taking care of this!
Is this fixed?
Should be fixed in trunk now. I’ve added some test cases into ConfigLoaderTest