Re: Groovy 3.0.20 Release Date
I did actually run into something when going over the Grails repos with 3.0.20-SNAPSHOT. https://issues.apache.org/jira/browse/GROOVY-11250 Den mån 11 dec. 2023 kl 22:35 skrev Mattias Reichel < mattias.reic...@gmail.com>: > Excellent! > I'll make sure to test with the snapshot version before that. > Maybe some other problem will surface. Already 27 bugs fixed since 3.0.19 > . > > Den mån 11 dec. 2023 kl 22:07 skrev Paul King : > >> We are planning another release before the end of the year - I'll >> start discussions with the team. We'll make sure 3_0_X is included. It >> would be great if you can use a 3_0_X snapshot version and ensure that >> works with Grails. >> >> On Tue, Dec 12, 2023 at 2:00 AM Mattias Reichel >> wrote: >> > >> > Hello groovy-users! >> > I'm new on the mailing list (although a user of groovy myself since pre >> v1), so first of all, thanks to the "Groovy team" for your excellent work >> over the years! >> > >> > I am writing to kindly request information regarding the release of >> Groovy 3.0.20 or a prospective release date in the near term. >> > >> > My interest is first and foremost that of >> https://issues.apache.org/jira/browse/GROOVY-11242 that was promptly >> addressed after being reported a couple of days ago. I am collaborating >> with the Grails team in upgrading the Groovy version of Grails 6 to the >> latest Groovy 3 patch release, and the resolution of this particular issue >> is essential to overcoming a current roadblock in our efforts. >> > >> > I understand the complexities involved in the release process and >> appreciate your hard work in maintaining the quality of the Groovy language >> project. >> > >> > Many thanks >> > Mattias Reichel >> >
[jira] [Created] (GROOVY-11250) Compilation fails when accessing getter with shortcut notation on Java class
Mattias Reichel created GROOVY-11250: Summary: Compilation fails when accessing getter with shortcut notation on Java class Key: GROOVY-11250 URL: https://issues.apache.org/jira/browse/GROOVY-11250 Project: Groovy Issue Type: Bug Components: Static compilation Affects Versions: 3.0.20 Reporter: Mattias Reichel Example project that demonstrates the issue: [https://github.com/matrei/bug-groovy-java-getter] Workaround: Use long form o.getName() instead of o.name -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Groovy 3.0.20 Release Date
Excellent! I'll make sure to test with the snapshot version before that. Maybe some other problem will surface. Already 27 bugs fixed since 3.0.19 . Den mån 11 dec. 2023 kl 22:07 skrev Paul King : > We are planning another release before the end of the year - I'll > start discussions with the team. We'll make sure 3_0_X is included. It > would be great if you can use a 3_0_X snapshot version and ensure that > works with Grails. > > On Tue, Dec 12, 2023 at 2:00 AM Mattias Reichel > wrote: > > > > Hello groovy-users! > > I'm new on the mailing list (although a user of groovy myself since pre > v1), so first of all, thanks to the "Groovy team" for your excellent work > over the years! > > > > I am writing to kindly request information regarding the release of > Groovy 3.0.20 or a prospective release date in the near term. > > > > My interest is first and foremost that of > https://issues.apache.org/jira/browse/GROOVY-11242 that was promptly > addressed after being reported a couple of days ago. I am collaborating > with the Grails team in upgrading the Groovy version of Grails 6 to the > latest Groovy 3 patch release, and the resolution of this particular issue > is essential to overcoming a current roadblock in our efforts. > > > > I understand the complexities involved in the release process and > appreciate your hard work in maintaining the quality of the Groovy language > project. > > > > Many thanks > > Mattias Reichel >
Groovy 3.0.20 Release Date
Hello groovy-users! I'm new on the mailing list (although a user of groovy myself since pre v1), so first of all, thanks to the "Groovy team" for your excellent work over the years! I am writing to kindly request information regarding the release of Groovy 3.0.20 or a prospective release date in the near term. My interest is first and foremost that of https://issues.apache.org/jira/browse/GROOVY-11242 that was promptly addressed after being reported a couple of days ago. I am collaborating with the Grails team in upgrading the Groovy version of Grails 6 to the latest Groovy 3 patch release, and the resolution of this particular issue is essential to overcoming a current roadblock in our efforts. I understand the complexities involved in the release process and appreciate your hard work in maintaining the quality of the Groovy language project. Many thanks Mattias Reichel
[jira] [Created] (GROOVY-11242) Stackoverflow error when calling super from overridden method
Mattias Reichel created GROOVY-11242:
Summary: Stackoverflow error when calling super from overridden
method
Key: GROOVY-11242
URL: https://issues.apache.org/jira/browse/GROOVY-11242
Project: Groovy
Issue Type: Bug
Components: Static compilation
Affects Versions: 3.0.19, 3.0.18, 3.0.17, 3.0.16, 3.0.15, 3.0.14
Reporter: Mattias Reichel
Fix For: 4.0.0-alpha-1
The following script throws Stackoverflow error when calling super.add(Object
o) from overridden add(Object o) (it ends up calling itself). With
@CompileDynamic on the overridden method the code works.
{code:java}
import groovy.transform.CompileStatic
@CompileStatic
class MySet extends DirtyCheckingSet {
MySet(Set delegate, DirtyCheckable entity, String propertyName) {
super(delegate, entity, propertyName)
}
@Override
boolean add(Object o) {
def added = super.add(o) // <-- Offending command
println "Added $o"
return added
}
}
@CompileStatic
class MyEntity implements DirtyCheckable {
String myProperty
}
@CompileStatic
class DirtyCheckingSet extends DirtyCheckingCollection implements Set {
DirtyCheckingSet(Set target, DirtyCheckable parent, String property) {
super(target, parent, property)
}
}
@CompileStatic
trait DirtyCheckable {
void markDirty(String propertyName) {
println "$propertyName marked dirty"
}
}
@CompileStatic
class DirtyCheckingCollection implements Collection {
final @Delegate Collection target
final DirtyCheckable parent
final String property
DirtyCheckingCollection(Collection target, DirtyCheckable parent, String
property) {
this.target = target
this.parent = parent
this.property = property
}
@Override
boolean add(Object o) {
parent.markDirty(property)
target.add(o)
}
}
MySet set = new MySet([] as Set, new MyEntity([myProperty: 'hello']),
'myProperty')
set.add('myProperty')
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
RE: [dom4j-user] The entity name must immediately follow the '' in the entity reference
Hi, you say you have an xml file, but you really don't according to: http://www.w3.org/TR/REC-xml#syntax / Mattias Reichel -Original Message- From: [EMAIL PROTECTED] [mailto:dom4j-user- [EMAIL PROTECTED] On Behalf Of Lee Peik Feng Sent: den 1 december 2003 08:33 To: [EMAIL PROTECTED] Subject: [dom4j-user] The entity name must immediately follow the '' in the entity reference Hi, I have an XML file containing the line as follow: Param Name = Artist Value = Jacky Cheung Pang / When I try to parse the file SAXReader reader = new SAXReader(); Document document = reader.read(myfile);--- error occur here I get the error below: org.dom4j.DocumentException: Error on line 45 of document : The entity name must immediately follow the '' in the entity reference. Nested exception: The entity name must immediately follow the '' in the entity reference. at org.dom4j.io.SAXReader.read(SAXReader.java:339) at org.dom4j.io.SAXReader.read(SAXReader.java:256) I understand that when parser encounters the special char , it expects an entity reference. By changing the to amp; could solve my prob but the XML file is generated by another program. Currently I will read the xml file, assign the content to a String and then replace all but this method is not secure as if the do mean an entity reference, then I'll get error. How could I overcome this issue? Any workaround? Any help is appreciated. Thank you. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ dom4j-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dom4j-user --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ dom4j-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dom4j-user
RE: [dom4j-user] Processing Instruction problem with removeProcessingInstruction() method
Hi, The xml declaration is not a processing instruction. So you cannot remove it this way. Use the setSuppressDeclaration() method of OutputFormat and feed it to your XMLWriter constructor. Cheers /Mattias -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of JavaXML Developer Sent: den 9 augusti 2002 14:03 To: [EMAIL PROTECTED] Subject: [dom4j-user] Processing Instruction problem with removeProcessingInstruction() method Hi All, I badly need help to get removeProcessingInstruction() method wrok. If anybody could suggest me a solution, would highly be appreciated. Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs
RE: [Jaxen] Possible bug with processing instructions
Ok, but it doesn't work with node() or processing-instruction() either a b/ ?toc order-by=x? c/ /a c.selectSingleNode(preceding-sibling::*) returns b c.selectSingleNode(preceding-sibling::node()) returns b c.selectSingleNode(preceding-sibling::processing-instruction()) returns null /Mattias -Original Message- From: [EMAIL PROTECTED] [mailto:jaxen-interest- [EMAIL PROTECTED]] On Behalf Of James Strachan Sent: den 19 april 2002 12:44 To: Mattias Reichel; 'bob mcwhirter' Cc: [EMAIL PROTECTED] Subject: Re: [Jaxen] Possible bug with processing instructions From: Mattias Reichel [EMAIL PROTECTED] Hmm, Switching to preceding axis for clarity, but issue is the same. From Michael Kay's XSLT Programmers Reference 2nd Edition by Wrox Press, page 364: preceding: This selects all the nodes that appear before the origin node, excluding the ancestors of the origin, in reverse document order. If the origin is an element node, this effectively means that it contains all the text nodes, element nodes, comments, and processing instructions in the document that finish before the start tag of the origin element. The preceding axis will never contain attribute or namespace nodes. Is he dead wrong here or what? The XPath spec also says... the preceding-sibling axis contains all the preceding siblings of the context node; if the context node is an attribute node or namespace node, the preceding-sibling axis is empty The issue is how does the '*' node test filter the axis. So the preceding-sibling axis contains all previous nodes of any type. Though using * filters the axis to just elements. Using node() will see all node types. Using processsing-instruction() will only see PIs etc. I think this is correct. Am about to build some more test cases to check this is how Jaxen behaves... James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
RE: [Jaxen] Possible bug with processing instructions
Hmm, Switching to preceding axis for clarity, but issue is the same. From Michael Kay's XSLT Programmers Reference 2nd Edition by Wrox Press, page 364: preceding: This selects all the nodes that appear before the origin node, excluding the ancestors of the origin, in reverse document order. If the origin is an element node, this effectively means that it contains all the text nodes, element nodes, comments, and processing instructions in the document that finish before the start tag of the origin element. The preceding axis will never contain attribute or namespace nodes. Is he dead wrong here or what? /Mattias -Original Message- From: [EMAIL PROTECTED] [mailto:jaxen-interest- [EMAIL PROTECTED]] On Behalf Of bob mcwhirter Sent: den 18 april 2002 15:47 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: Re: [Jaxen] Possible bug with processing instructions XPath spec, 2.3: Every axis has a principal node type. If an axis can contain elements, then the principal node type is element; otherwise, it is the type of the nodes that the axis can contain. Thus, * For the attribute axis, the principal node type is attribute. * For the namespace axis, the principal node type is namespace. * For other axes, the principal node type is element. --- So, preceding-sibling::* will select the preceding sibling of the type 'element', as I read it. Am I misinterpreting the spec? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Hi, I'm using dom4j and of course also jaxen for some xml processing. Got into trouble when trying to get a hold of a processing instruction via an xpath expression. Example: a b/ ?toc order-by=x? c/ /a c.selectSingleNode(preceding-sibling::*[1]); returns b. Best Regards Mattias Reichel ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
RE: [Jaxen] Possible bug with processing instructions
I use dom4j 1.3 -Original Message- From: [EMAIL PROTECTED] [mailto:jaxen-interest- [EMAIL PROTECTED]] On Behalf Of bob mcwhirter Sent: den 18 april 2002 16:18 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: RE: [Jaxen] Possible bug with processing instructions Hmmm... Sounds like a bug. So, standard questions: Which version of dom4j are you using? James? Any thoughts? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Nope! -Original Message- From: bob mcwhirter [mailto:[EMAIL PROTECTED]] Sent: den 18 april 2002 16:09 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: RE: [Jaxen] Possible bug with processing instructions Actually, now that I re-read the spec, I'm not certain what my point was. (One of those days). Okay, an axis has a primary node type, but, so what? Hmm... Does preceding-sibling::node() manage to find the PI? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Hmm, Switching to preceding axis for clarity, but issue is the same. From Michael Kay's XSLT Programmers Reference 2nd Edition by Wrox Press, page 364: preceding: This selects all the nodes that appear before the origin node, excluding the ancestors of the origin, in reverse document order. If the origin is an element node, this effectively means that it contains all the text nodes, element nodes, comments, and processing instructions in the document that finish before the start tag of the origin element. The preceding axis will never contain attribute or namespace nodes. Is he dead wrong here or what? /Mattias -Original Message- From: [EMAIL PROTECTED] [mailto:jaxen-interest- [EMAIL PROTECTED]] On Behalf Of bob mcwhirter Sent: den 18 april 2002 15:47 To: Mattias Reichel Cc: [EMAIL PROTECTED] Subject: Re: [Jaxen] Possible bug with processing instructions XPath spec, 2.3: Every axis has a principal node type. If an axis can contain elements, then the principal node type is element; otherwise, it is the type of the nodes that the axis can contain. Thus, * For the attribute axis, the principal node type is attribute. * For the namespace axis, the principal node type is namespace. * For other axes, the principal node type is element. --- So, preceding-sibling::* will select the preceding sibling of the type 'element', as I read it. Am I misinterpreting the spec? -bob On Thu, 18 Apr 2002, Mattias Reichel wrote: Hi, I'm using dom4j and of course also jaxen for some xml processing. Got into trouble when trying to get a hold of a processing instruction via an xpath expression. Example: a b/ ?toc order-by=x? c/ /a c.selectSingleNode(preceding-sibling::*[1]); returns b. Best Regards Mattias Reichel ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest ___ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest
Re: Can't verify simple install.
Use www.myserver.com/servlet/SimpleServlet and not www.myserver.com/servlets/SimpleServlet Mattias Reichel - Original Message - From: "/dev/null" [EMAIL PROTECTED] To: "JRun-Talk" [EMAIL PROTECTED] Sent: Friday, September 22, 2000 9:36 AM Subject: Can't verify simple install. This is a multi-part message in MIME format. --=_NextPart_000_002B_01C0243D.DFD7A2F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NT 4.0 EE SP6a, IIS 4.0 JRun 2.3 I let the install run as normal. I had to go to the IIS web setup and = associate .jrun with the jrun.dll in the IIS_ROOT\scripts directory (the = jrun.dll was already there). Now I'm a little confused as to which exact directory my servlets should = be in for me to run them and why they aren't coming up. There are = several "samples" already set up in JRun\servlets, but none of them come = up. I try www.myserver.com/servlets/SimpleServlet, = www.myserver.com/servlets/SimpleServlet.JRun, = www.myserver.com/SimpleServlet etc... but I can't get anything to come = up. I've even compiled a simple "HelloWorld" and stuck it in just about = every "servlets" directory I've found under JRun, but no combination of = URL brings it up. I'm always getting HTTP 404 - File not found What's wrong? What directory should I be putting the compiled servlets = in? If I have a servlet there, what would prevent it from coming up = correctly? Thanks! --=_NextPart_000_002B_01C0243D.DFD7A2F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" HTMLHEAD META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR STYLE/STYLE /HEAD BODY bgColor=3D#ff DIVFONT face=3DVerdana size=3D2NT 4.0 EEnbsp;SP6a, IIS = 4.0/FONT/DIV DIVFONT face=3DVerdana size=3D2JRun 2.3/FONT/DIV DIVFONT face=3DVerdana size=3D2I let the install run as = normal.nbsp; I had to=20 go to the IIS web setup and associate .jrun with the jrun.dll in the=20 IIS_ROOT\scripts directory (the jrun.dll was already = there)./FONT/DIV DIVnbsp;/DIV DIVFONT face=3DVerdana size=3D2Now I'm a little confused as to which = exact=20 directory my servlets should be in for me to run them and why they = aren't coming=20 up.nbsp; There are several "samples" already set up in JRun\servlets, = but none=20 of them come up.nbsp; I try www.myserver.com/servlets/SimpleServlet,=20 www.myserver.com/servlets/SimpleServlet.JRun, = www.myserver.com/SimpleServlet=20 etc... but I can't get anything to come up.nbsp; I've even compiled a = simple=20 "HelloWorld" and stuck it in just about every "servlets" directory I've = found=20 under JRun, but no combination of URL brings it up.nbsp; I'm always = getting=20 HTTP 404 - File not found/FONT/DIV DIVnbsp;/DIV DIVFONT face=3DVerdana size=3D2What's wrong?nbsp; What directory = should I be=20 putting the compiled servlets in?nbsp; If I have a servlet there, what = would=20 prevent it from coming up correctly?/FONT/DIV DIVnbsp;/DIV DIVFONT face=3DVerdana size=3D2Thanks!/FONT/DIV/BODY/HTML --=_NextPart_000_002B_01C0243D.DFD7A2F0-- -- Archives: http://www.egroups.com/group/jrun-interest/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/jrun_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body. -- Archives: http://www.egroups.com/group/jrun-interest/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebarRstsbodyRsts/jrun_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
