1:48 a.m.
Trying to open http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
gives a:
"
Site temporarily disabled
This page has been temporarily disabled due to a misconfigured custom
domain.
Are you the site owner? Follow the instructions for setting up a custom
domain with GitHub pages to update your site's DNS records to point to
the proper IP address.
You can find more information in our GitHub Pages legacy IP deprecation
blog post. If you have any questions, please contact support.
"
The above causes a WildFly test failure http://pastebin.com/fm8VMCcb
(from org.hibernate.service.internal.JaxbProcessor.unmarshal).
Scott
2:13 a.m.
Related question, should we instead be using the
org/hibernate/hibernate-configuration-3.0.dtd in
hibernate-core-4.3.7.Final.jar (instead of accessing the hibernate.org
website)?
On 11/18/2014 07:48 PM, Scott Marlow wrote:
Trying to open
http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
gives a:
"
Site temporarily disabled
This page has been temporarily disabled due to a misconfigured custom
domain.
Are you the site owner? Follow the instructions for setting up a custom
domain with GitHub pages to update your site's DNS records to point to
the proper IP address.
You can find more information in our GitHub Pages legacy IP deprecation
blog post. If you have any questions, please contact support.
"
The above causes a WildFly test failure http://pastebin.com/fm8VMCcb
(from org.hibernate.service.internal.JaxbProcessor.unmarshal).
Scott
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:57 p.m.
There was a DNS related change required for GH pages with custom domains.
Just tested it, it is working again, so I guess Emmanuel has done the
required configuation. May take a while though until it has been propagated
to all DNS servers.
--Gunnar
Am 19.11.2014 01:49 schrieb "Scott Marlow" <smarlow(a)redhat.com>:
Trying to open
http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
gives a:
"
Site temporarily disabled
This page has been temporarily disabled due to a misconfigured custom
domain.
Are you the site owner? Follow the instructions for setting up a custom
domain with GitHub pages to update your site's DNS records to point to
the proper IP address.
You can find more information in our GitHub Pages legacy IP deprecation
blog post. If you have any questions, please contact support.
"
The above causes a WildFly test failure http://pastebin.com/fm8VMCcb
(from org.hibernate.service.internal.JaxbProcessor.unmarshal).
Scott
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:53 p.m.
On 19 November 2014 01:13, Scott Marlow <smarlow(a)redhat.com> wrote:
Related question, should we instead be using the
org/hibernate/hibernate-configuration-3.0.dtd in
hibernate-core-4.3.7.Final.jar (instead of accessing the hibernate.org
website)?
I'd agree that it's generally not a good idea to rely on external web
services in your tests. Although in this case it's turned out useful
as we got your notification about the problem :)
Sanne
On 11/18/2014 07:48 PM, Scott Marlow wrote:
> Trying to open http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
> gives a:
>
> "
> Site temporarily disabled
>
> This page has been temporarily disabled due to a misconfigured custom
> domain.
>
> Are you the site owner? Follow the instructions for setting up a custom
> domain with GitHub pages to update your site's DNS records to point to
> the proper IP address.
>
> You can find more information in our GitHub Pages legacy IP deprecation
> blog post. If you have any questions, please contact support.
> "
>
> The above causes a WildFly test failure http://pastebin.com/fm8VMCcb
> (from org.hibernate.service.internal.JaxbProcessor.unmarshal).
>
> Scott
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:48 p.m.
On 11/19/2014 08:53 AM, Sanne Grinovero wrote:
On 19 November 2014 01:13, Scott Marlow <smarlow(a)redhat.com>
wrote:
> Related question, should we instead be using the
> org/hibernate/hibernate-configuration-3.0.dtd in
> hibernate-core-4.3.7.Final.jar (instead of accessing the hibernate.org
> website)?
I'd agree that it's generally not a good idea to rely on external web
services in your tests. Although in this case it's turned out useful
as we got your notification about the problem :)
I'm not exactly sure what I need to change in the tests to use the local
org/hibernate/hibernate-configuration-3.0.dtd (ORM jar) copy of the DTD.
I tried a few different options but the only thing that helped was
removing the DTD reference.
For example, what should
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi...
be changed to?
I tried changing the "PUBLIC" to "SYSTEM" but that didn't seem to
make a
difference (also tried adding a classpath reference which some forum
posts talked about doing).
Sanne
>
> On 11/18/2014 07:48 PM, Scott Marlow wrote:
>> Trying to open http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
>> gives a:
>>
>> "
>> Site temporarily disabled
>>
>> This page has been temporarily disabled due to a misconfigured custom
>> domain.
>>
>> Are you the site owner? Follow the instructions for setting up a custom
>> domain with GitHub pages to update your site's DNS records to point to
>> the proper IP address.
>>
>> You can find more information in our GitHub Pages legacy IP deprecation
>> blog post. If you have any questions, please contact support.
>> "
>>
>> The above causes a WildFly test failure http://pastebin.com/fm8VMCcb
>> (from org.hibernate.service.internal.JaxbProcessor.unmarshal).
>>
>> Scott
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:04 p.m.
2014-11-19 16:48 GMT+01:00 Scott Marlow <smarlow(a)redhat.com>:
On 11/19/2014 08:53 AM, Sanne Grinovero wrote:
> On 19 November 2014 01:13, Scott Marlow <smarlow(a)redhat.com> wrote:
>> Related question, should we instead be using the
>> org/hibernate/hibernate-configuration-3.0.dtd in
>> hibernate-core-4.3.7.Final.jar (instead of accessing the hibernate.org
>> website)?
>
> I'd agree that it's generally not a good idea to rely on external web
> services in your tests. Although in this case it's turned out useful
> as we got your notification about the problem :)
I'm not exactly sure what I need to change in the tests to use the local
org/hibernate/hibernate-configuration-3.0.dtd (ORM jar) copy of the DTD.
I tried a few different options but the only thing that helped was
removing the DTD reference.
For example, what should
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi...
be changed to?
I tried changing the "PUBLIC" to "SYSTEM" but that didn't seem to
make a
difference (also tried adding a classpath reference which some forum
posts talked about doing).
I don't think that's something which can (or should) be controlled within
the test.
Rather the code processing the XML file in ORM should make sure to use the
local version of the DTD. That's how it's done in Validator:
https://github.com/hibernate/hibernate-validator/blob/master/engine/src/m...
Not sure how helpful it is though, as this is for XSDs and we're using JAXB
to do the parsing, so it may be a bit different to do in ORM.
--Gunnar
>
> Sanne
>
>>
>> On 11/18/2014 07:48 PM, Scott Marlow wrote:
>>> Trying to open
http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
>>> gives a:
>>>
>>> "
>>> Site temporarily disabled
>>>
>>> This page has been temporarily disabled due to a misconfigured custom
>>> domain.
>>>
>>> Are you the site owner? Follow the instructions for setting up a custom
>>> domain with GitHub pages to update your site's DNS records to point to
>>> the proper IP address.
>>>
>>> You can find more information in our GitHub Pages legacy IP deprecation
>>> blog post. If you have any questions, please contact support.
>>> "
>>>
>>> The above causes a WildFly test failure http://pastebin.com/fm8VMCcb
>>> (from org.hibernate.service.internal.JaxbProcessor.unmarshal).
>>>
>>> Scott
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:17 p.m.
Hi,
> For example, what should
>
>
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi...
> be changed to?
>
> I tried changing the "PUBLIC" to "SYSTEM" but that didn't
seem to make a
> difference (also tried adding a classpath reference which some forum
> posts talked about doing).
>
I don't think that's something which can (or should) be controlled within
the test.
+1
Rather the code processing the XML file in ORM should make sure to
use the
local version of the DTD. That's how it's done in Validator:
Right, and if I am not mistaken we "took" the approach from ORM in the first
place.
It might be though, that it is part of the unreleased ORM 5 code.
Not sure how helpful it is though, as this is for XSDs and we're
using JAXB
to do the parsing, so it may be a bit different to do in ORM.
I might be imagining this, but I thought this remote lookup of DTD has been addressed
quite some time back. Maybe I am also missing something here. What version of
ORM are we dealing with here?
--Hardy
5:26 p.m.
ORM has had local resolution of these DTDs forever. Something is amiss in
your set up. I just ran ORM tests and the DTDs are being resolved locally
properly.
Can you make sure control is getting through our registered
EntityResolver? Ultimately, this should be resolved
by org.hibernate.internal.util.xml.DTDEntityResolver
On Wed, Nov 19, 2014 at 10:04 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
2014-11-19 16:48 GMT+01:00 Scott Marlow <smarlow(a)redhat.com>:
> On 11/19/2014 08:53 AM, Sanne Grinovero wrote:
> > On 19 November 2014 01:13, Scott Marlow <smarlow(a)redhat.com> wrote:
> >> Related question, should we instead be using the
> >> org/hibernate/hibernate-configuration-3.0.dtd in
> >> hibernate-core-4.3.7.Final.jar (instead of accessing the
hibernate.org
> >> website)?
> >
> > I'd agree that it's generally not a good idea to rely on external web
> > services in your tests. Although in this case it's turned out useful
> > as we got your notification about the problem :)
>
> I'm not exactly sure what I need to change in the tests to use the local
> org/hibernate/hibernate-configuration-3.0.dtd (ORM jar) copy of the DTD.
> I tried a few different options but the only thing that helped was
> removing the DTD reference.
>
> For example, what should
>
>
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi...
> be changed to?
>
> I tried changing the "PUBLIC" to "SYSTEM" but that didn't
seem to make a
> difference (also tried adding a classpath reference which some forum
> posts talked about doing).
>
I don't think that's something which can (or should) be controlled within
the test.
Rather the code processing the XML file in ORM should make sure to use the
local version of the DTD. That's how it's done in Validator:
https://github.com/hibernate/hibernate-validator/blob/master/engine/src/m...
Not sure how helpful it is though, as this is for XSDs and we're using JAXB
to do the parsing, so it may be a bit different to do in ORM.
--Gunnar
> >
> > Sanne
> >
> >>
> >> On 11/18/2014 07:48 PM, Scott Marlow wrote:
> >>> Trying to open
> http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
> >>> gives a:
> >>>
> >>> "
> >>> Site temporarily disabled
> >>>
> >>> This page has been temporarily disabled due to a misconfigured custom
> >>> domain.
> >>>
> >>> Are you the site owner? Follow the instructions for setting up a
custom
> >>> domain with GitHub pages to update your site's DNS records to
point
to
> >>> the proper IP address.
> >>>
> >>> You can find more information in our GitHub Pages legacy IP
deprecation
> >>> blog post. If you have any questions, please contact support.
> >>> "
> >>>
> >>> The above causes a WildFly test failure http://pastebin.com/fm8VMCcb
> >>> (from org.hibernate.service.internal.JaxbProcessor.unmarshal).
> >>>
> >>> Scott
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:35 p.m.
On 11/19/2014 11:26 AM, Steve Ebersole wrote:
ORM has had local resolution of these DTDs forever. Something is
amiss
in your set up. I just ran ORM tests and the DTDs are being resolved
locally properly.
Thanks for checking.
Can you make sure control is getting through our registered
EntityResolver? Ultimately, this should be resolved
by org.hibernate.internal.util.xml.DTDEntityResolver
I'll give this a try.
On Wed, Nov 19, 2014 at 10:04 AM, Gunnar Morling <gunnar(a)hibernate.org
<mailto:gunnar@hibernate.org>> wrote:
2014-11-19 16:48 GMT+01:00 Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>>:
> On 11/19/2014 08:53 AM, Sanne Grinovero wrote:
> > On 19 November 2014 01:13, Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
> >> Related question, should we instead be using the
> >> org/hibernate/hibernate-configuration-3.0.dtd in
> >> hibernate-core-4.3.7.Final.jar (instead of accessing thehibernate.org
<http://hibernate.org>
> >> website)?
> >
> > I'd agree that it's generally not a good idea to rely on external
web
> > services in your tests. Although in this case it's turned out useful
> > as we got your notification about the problem :)
>
> I'm not exactly sure what I need to change in the tests to use the local
> org/hibernate/hibernate-configuration-3.0.dtd (ORM jar) copy of the DTD.
> I tried a few different options but the only thing that helped was
> removing the DTD reference.
>
> For example, what should
>
>https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/cfgfile/CfgFileTestCase.java#L54
> be changed to?
>
> I tried changing the "PUBLIC" to "SYSTEM" but that
didn't seem to make a
> difference (also tried adding a classpath reference which some forum
> posts talked about doing).
>
I don't think that's something which can (or should) be controlled
within
the test.
Rather the code processing the XML file in ORM should make sure to
use the
local version of the DTD. That's how it's done in Validator:
https://github.com/hibernate/hibernate-validator/blob/master/engine/src/m...
Not sure how helpful it is though, as this is for XSDs and we're
using JAXB
to do the parsing, so it may be a bit different to do in ORM.
--Gunnar
> >
> > Sanne
> >
> >>
> >> On 11/18/2014 07:48 PM, Scott Marlow wrote:
> >>> Trying to open
> http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
> >>> gives a:
> >>>
> >>> "
> >>> Site temporarily disabled
> >>>
> >>> This page has been temporarily disabled due to a
misconfigured custom
> >>> domain.
> >>>
> >>> Are you the site owner? Follow the instructions for setting
up a custom
> >>> domain with GitHub pages to update your site's DNS records to
point to
> >>> the proper IP address.
> >>>
> >>> You can find more information in our GitHub Pages legacy IP
deprecation
> >>> blog post. If you have any questions, please contact support.
> >>> "
> >>>
> >>> The above causes a WildFly test failure
http://pastebin.com/fm8VMCcb
> >>> (from org.hibernate.service.internal.JaxbProcessor.unmarshal).
> >>>
> >>> Scott
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:46 p.m.
I should have been more complete :)
You can either set a breakpoint or crank up logging on that class.
Breakpoint debugging is probably better as you could see the whole call
stack. These resolvers use a lot of delegation. You could also look
at org.hibernate.cfg.Configuration#entityResolver to verify which specific
resolver is being used.
On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow <smarlow(a)redhat.com> wrote:
On 11/19/2014 11:26 AM, Steve Ebersole wrote:
> ORM has had local resolution of these DTDs forever. Something is amiss
> in your set up. I just ran ORM tests and the DTDs are being resolved
> locally properly.
>
Thanks for checking.
> Can you make sure control is getting through our registered
> EntityResolver? Ultimately, this should be resolved
> by org.hibernate.internal.util.xml.DTDEntityResolver
>
I'll give this a try.
> On Wed, Nov 19, 2014 at 10:04 AM, Gunnar Morling <gunnar(a)hibernate.org
> <mailto:gunnar@hibernate.org>> wrote:
>
> 2014-11-19 16:48 GMT+01:00 Scott Marlow <smarlow(a)redhat.com
> <mailto:smarlow@redhat.com>>:
>
> > On 11/19/2014 08:53 AM, Sanne Grinovero wrote:
> > > On 19 November 2014 01:13, Scott Marlow <smarlow(a)redhat.com
> <mailto:smarlow@redhat.com>> wrote:
> > >> Related question, should we instead be using the
> > >> org/hibernate/hibernate-configuration-3.0.dtd in
> > >> hibernate-core-4.3.7.Final.jar (instead of accessing
> thehibernate.org <http://hibernate.org>
>
> > >> website)?
> > >
> > > I'd agree that it's generally not a good idea to rely on
external
> web
> > > services in your tests. Although in this case it's turned out
> useful
> > > as we got your notification about the problem :)
> >
> > I'm not exactly sure what I need to change in the tests to use the
> local
> > org/hibernate/hibernate-configuration-3.0.dtd (ORM jar) copy of
> the DTD.
> > I tried a few different options but the only thing that helped was
> > removing the DTD reference.
> >
> > For example, what should
> >
> >https://github.com/wildfly/wildfly/blob/master/testsuite/
> integration/basic/src/test/java/org/jboss/as/test/
> integration/jpa/cfgfile/CfgFileTestCase.java#L54
> > be changed to?
> >
> > I tried changing the "PUBLIC" to "SYSTEM" but that
didn't seem to
> make a
> > difference (also tried adding a classpath reference which some forum
> > posts talked about doing).
> >
>
> I don't think that's something which can (or should) be controlled
> within
> the test.
>
> Rather the code processing the XML file in ORM should make sure to
> use the
> local version of the DTD. That's how it's done in Validator:
>
>
> https://github.com/hibernate/hibernate-validator/blob/
> master/engine/src/main/java/org/hibernate/validator/internal/xml/
> ValidationXmlParser.java
>
> Not sure how helpful it is though, as this is for XSDs and we're
> using JAXB
> to do the parsing, so it may be a bit different to do in ORM.
>
> --Gunnar
>
>
> > >
> > > Sanne
> > >
> > >>
> > >> On 11/18/2014 07:48 PM, Scott Marlow wrote:
> > >>> Trying to open
> > http://hibernate.org/dtd/hibernate-configuration-3.0.dtd,
> > >>> gives a:
> > >>>
> > >>> "
> > >>> Site temporarily disabled
> > >>>
> > >>> This page has been temporarily disabled due to a
> misconfigured custom
> > >>> domain.
> > >>>
> > >>> Are you the site owner? Follow the instructions for setting
> up a custom
> > >>> domain with GitHub pages to update your site's DNS records
to
> point to
> > >>> the proper IP address.
> > >>>
> > >>> You can find more information in our GitHub Pages legacy IP
> deprecation
> > >>> blog post. If you have any questions, please contact support.
> > >>> "
> > >>>
> > >>> The above causes a WildFly test failure
> http://pastebin.com/fm8VMCcb
> > >>> (from
org.hibernate.service.internal.JaxbProcessor.unmarshal).
> > >>>
> > >>> Scott
> > >>> _______________________________________________
> > >>> hibernate-dev mailing list
> > >>> hibernate-dev(a)lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>
> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>>
> > >>
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev(a)lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.
> jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
7:15 p.m.
http://pastebin.com/Baz7FRyf is an initial call stack into
org.hibernate.service.internal.JaxbProcessor. I'm debugging on the
Hibernate 4.3 branch and don't hit any break points in
org.hibernate.cfg.Configuration#entityResolver. Perhaps I ended up in
the wrong class, not sure. I also set break points in
org.hibernate.internal.util.xml.DTDEntityResolver (don't see
org.hibernate.internal.util.__xml.DTDEntityResolver).
The first exception that I see is http://pastebin.com/CYd0aNzE
On 11/19/2014 11:46 AM, Steve Ebersole wrote:
I should have been more complete :)
You can either set a breakpoint or crank up logging on that class.
Breakpoint debugging is probably better as you could see the whole call
stack. These resolvers use a lot of delegation. You could also look
at org.hibernate.cfg.Configuration#entityResolver to verify which
specific resolver is being used.
On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
On 11/19/2014 11:26 AM, Steve Ebersole wrote:
ORM has had local resolution of these DTDs forever. Something
is amiss
in your set up. I just ran ORM tests and the DTDs are being
resolved
locally properly.
Thanks for checking.
Can you make sure control is getting through our registered
EntityResolver? Ultimately, this should be resolved
by org.hibernate.internal.util.__xml.DTDEntityResolver
I'll give this a try.
8:43 p.m.
Ah, there is a difference in how core and hem are loading these. This is
likely a bug, could you open a Jira?
On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow(a)redhat.com> wrote:
http://pastebin.com/Baz7FRyf is an initial call stack into
org.hibernate.service.internal.JaxbProcessor. I'm debugging on the
Hibernate 4.3 branch and don't hit any break points in
org.hibernate.cfg.Configuration#entityResolver.
Perhaps I ended up in the wrong class, not sure. I also set break points
in org.hibernate.internal.util.xml.DTDEntityResolver (don't see
org.hibernate.internal.util.__xml.DTDEntityResolver).
The first exception that I see is http://pastebin.com/CYd0aNzE
On 11/19/2014 11:46 AM, Steve Ebersole wrote:
> I should have been more complete :)
>
> You can either set a breakpoint or crank up logging on that class.
> Breakpoint debugging is probably better as you could see the whole call
> stack. These resolvers use a lot of delegation. You could also look
> at org.hibernate.cfg.Configuration#entityResolver to verify which
> specific resolver is being used.
>
> On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow <smarlow(a)redhat.com
> <mailto:smarlow@redhat.com>> wrote:
>
> On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>
> ORM has had local resolution of these DTDs forever. Something
> is amiss
> in your set up. I just ran ORM tests and the DTDs are being
> resolved
> locally properly.
>
>
> Thanks for checking.
>
>
> Can you make sure control is getting through our registered
> EntityResolver? Ultimately, this should be resolved
> by org.hibernate.internal.util.__xml.DTDEntityResolver
>
>
> I'll give this a try.
>
>
>
9:33 p.m.
On 11/19/2014 02:43 PM, Steve Ebersole wrote:
Ah, there is a difference in how core and hem are loading these.
This
is likely a bug, could you open a Jira?
I created HHH-9511 for this.
On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
http://pastebin.com/Baz7FRyf is an initial call stack into
org.hibernate.service.__internal.JaxbProcessor. I'm debugging on
the Hibernate 4.3 branch and don't hit any break points in
org.hibernate.cfg.__Configuration#entityResolver. Perhaps I ended
up in the wrong class, not sure. I also set break points in
org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
org.hibernate.internal.util.____xml.DTDEntityResolver).
The first exception that I see is http://pastebin.com/CYd0aNzE
On 11/19/2014 11:46 AM, Steve Ebersole wrote:
I should have been more complete :)
You can either set a breakpoint or crank up logging on that class.
Breakpoint debugging is probably better as you could see the
whole call
stack. These resolvers use a lot of delegation. You could also
look
at org.hibernate.cfg.__Configuration#entityResolver to verify which
specific resolver is being used.
On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
<smarlow(a)redhat.com <mailto:smarlow@redhat.com>
<mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> wrote:
On 11/19/2014 11:26 AM, Steve Ebersole wrote:
ORM has had local resolution of these DTDs forever.
Something
is amiss
in your set up. I just ran ORM tests and the DTDs are
being
resolved
locally properly.
Thanks for checking.
Can you make sure control is getting through our registered
EntityResolver? Ultimately, this should be resolved
by org.hibernate.internal.util.____xml.DTDEntityResolver
I'll give this a try.
8:44 p.m.
Hibernate.org is down (seeing WildFly testsuite failures).
On 11/19/2014 03:33 PM, Scott Marlow wrote:
On 11/19/2014 02:43 PM, Steve Ebersole wrote:
> Ah, there is a difference in how core and hem are loading these. This
> is likely a bug, could you open a Jira?
I created HHH-9511 for this.
>
> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow(a)redhat.com
> <mailto:smarlow@redhat.com>> wrote:
>
> http://pastebin.com/Baz7FRyf is an initial call stack into
> org.hibernate.service.__internal.JaxbProcessor. I'm debugging on
> the Hibernate 4.3 branch and don't hit any break points in
> org.hibernate.cfg.__Configuration#entityResolver. Perhaps I ended
> up in the wrong class, not sure. I also set break points in
> org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
> org.hibernate.internal.util.____xml.DTDEntityResolver).
>
> The first exception that I see is http://pastebin.com/CYd0aNzE
>
> On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>
> I should have been more complete :)
>
> You can either set a breakpoint or crank up logging on that class.
> Breakpoint debugging is probably better as you could see the
> whole call
> stack. These resolvers use a lot of delegation. You could also
> look
> at org.hibernate.cfg.__Configuration#entityResolver to verify which
> specific resolver is being used.
>
> On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
> <smarlow(a)redhat.com <mailto:smarlow@redhat.com>
> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>>
wrote:
>
> On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>
> ORM has had local resolution of these DTDs forever.
> Something
> is amiss
> in your set up. I just ran ORM tests and the DTDs are
> being
> resolved
> locally properly.
>
>
> Thanks for checking.
>
>
> Can you make sure control is getting through our registered
> EntityResolver? Ultimately, this should be resolved
> by org.hibernate.internal.util.____xml.DTDEntityResolver
>
>
> I'll give this a try.
>
>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:19 p.m.
Why and where do we have such a dependency?
Carlo
On 02/03/2015 08:44 PM, Scott Marlow wrote:
Hibernate.org is down (seeing WildFly testsuite failures).
On 11/19/2014 03:33 PM, Scott Marlow wrote:
> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>> Ah, there is a difference in how core and hem are loading these. This
>> is likely a bug, could you open a Jira?
> I created HHH-9511 for this.
>
>> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow(a)redhat.com
>> <mailto:smarlow@redhat.com>> wrote:
>>
>> http://pastebin.com/Baz7FRyf is an initial call stack into
>> org.hibernate.service.__internal.JaxbProcessor. I'm debugging on
>> the Hibernate 4.3 branch and don't hit any break points in
>> org.hibernate.cfg.__Configuration#entityResolver. Perhaps I ended
>> up in the wrong class, not sure. I also set break points in
>> org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
>> org.hibernate.internal.util.____xml.DTDEntityResolver).
>>
>> The first exception that I see is http://pastebin.com/CYd0aNzE
>>
>> On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>>
>> I should have been more complete :)
>>
>> You can either set a breakpoint or crank up logging on that class.
>> Breakpoint debugging is probably better as you could see the
>> whole call
>> stack. These resolvers use a lot of delegation. You could also
>> look
>> at org.hibernate.cfg.__Configuration#entityResolver to verify which
>> specific resolver is being used.
>>
>> On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>> <smarlow(a)redhat.com <mailto:smarlow@redhat.com>
>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>>
wrote:
>>
>> On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>>
>> ORM has had local resolution of these DTDs forever.
>> Something
>> is amiss
>> in your set up. I just ran ORM tests and the DTDs are
>> being
>> resolved
>> locally properly.
>>
>>
>> Thanks for checking.
>>
>>
>> Can you make sure control is getting through our registered
>> EntityResolver? Ultimately, this should be resolved
>> by org.hibernate.internal.util.____xml.DTDEntityResolver
>>
>>
>> I'll give this a try.
>>
>>
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:22 p.m.
Great question! Scott?
On Tue, Feb 3, 2015 at 2:19 PM, Carlo de Wolf <cdewolf(a)redhat.com> wrote:
Why and where do we have such a dependency?
Carlo
On 02/03/2015 08:44 PM, Scott Marlow wrote:
> Hibernate.org is down (seeing WildFly testsuite failures).
>
> On 11/19/2014 03:33 PM, Scott Marlow wrote:
>
>> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>>
>>> Ah, there is a difference in how core and hem are loading these. This
>>> is likely a bug, could you open a Jira?
>>>
>> I created HHH-9511 for this.
>>
>> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow(a)redhat.com
>>> <mailto:smarlow@redhat.com>> wrote:
>>>
>>> http://pastebin.com/Baz7FRyf is an initial call stack into
>>> org.hibernate.service.__internal.JaxbProcessor. I'm debugging on
>>> the Hibernate 4.3 branch and don't hit any break points in
>>> org.hibernate.cfg.__Configuration#entityResolver. Perhaps I
>>> ended
>>> up in the wrong class, not sure. I also set break points in
>>> org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
>>> org.hibernate.internal.util.____xml.DTDEntityResolver).
>>>
>>> The first exception that I see is http://pastebin.com/CYd0aNzE
>>>
>>> On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>>>
>>> I should have been more complete :)
>>>
>>> You can either set a breakpoint or crank up logging on that
>>> class.
>>> Breakpoint debugging is probably better as you could see the
>>> whole call
>>> stack. These resolvers use a lot of delegation. You could
>>> also
>>> look
>>> at org.hibernate.cfg.__Configuration#entityResolver to
>>> verify which
>>> specific resolver is being used.
>>>
>>> On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>>> <smarlow(a)redhat.com <mailto:smarlow@redhat.com>
>>> <mailto:smarlow@redhat.com
<mailto:smarlow@redhat.com>>>
>>> wrote:
>>>
>>> On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>>>
>>> ORM has had local resolution of these DTDs forever.
>>> Something
>>> is amiss
>>> in your set up. I just ran ORM tests and the DTDs
>>> are
>>> being
>>> resolved
>>> locally properly.
>>>
>>>
>>> Thanks for checking.
>>>
>>>
>>> Can you make sure control is getting through our
>>> registered
>>> EntityResolver? Ultimately, this should be resolved
>>> by org.hibernate.internal.util.__
>>> __xml.DTDEntityResolver
>>>
>>>
>>> I'll give this a try.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
9:43 p.m.
HHH-9511 shows the call stack (should answer where/why).
On 02/03/2015 03:22 PM, Steve Ebersole wrote:
Great question! Scott?
On Tue, Feb 3, 2015 at 2:19 PM, Carlo de Wolf <cdewolf(a)redhat.com
<mailto:cdewolf@redhat.com>> wrote:
Why and where do we have such a dependency?
Carlo
On 02/03/2015 08:44 PM, Scott Marlow wrote:
Hibernate.org is down (seeing WildFly testsuite failures).
On 11/19/2014 03:33 PM, Scott Marlow wrote:
On 11/19/2014 02:43 PM, Steve Ebersole wrote:
Ah, there is a difference in how core and hem are
loading these. This
is likely a bug, could you open a Jira?
I created HHH-9511 for this.
On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow
<smarlow(a)redhat.com <mailto:smarlow@redhat.com>
<mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>>
wrote:
http://pastebin.com/Baz7FRyf is an initial call stack into
org.hibernate.service.____internal.JaxbProcessor. I'm
debugging on
the Hibernate 4.3 branch and don't hit any break
points in
org.hibernate.cfg.____Configuration#entityResolver.
Perhaps I ended
up in the wrong class, not sure. I also set
break points in
org.hibernate.internal.util.____xml.DTDEntityResolver
(don't see
org.hibernate.internal.util.______xml.DTDEntityResolver).
The first exception that I see is
http://pastebin.com/CYd0aNzE
On 11/19/2014 11:46 AM, Steve Ebersole wrote:
I should have been more complete :)
You can either set a breakpoint or crank up
logging on that class.
Breakpoint debugging is probably better as
you could see the
whole call
stack. These resolvers use a lot of
delegation. You could also
look
at
org.hibernate.cfg.____Configuration#entityResolver to
verify which
specific resolver is being used.
On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
<smarlow(a)redhat.com
<mailto:smarlow@redhat.com> <mailto:smarlow@redhat.com
<mailto:smarlow@redhat.com>>
<mailto:smarlow@redhat.com
<mailto:smarlow@redhat.com> <mailto:smarlow@redhat.com
<mailto:smarlow@redhat.com>>>> wrote:
On 11/19/2014 11:26 AM, Steve Ebersole
wrote:
ORM has had local resolution of
these DTDs forever.
Something
is amiss
in your set up. I just ran ORM
tests and the DTDs are
being
resolved
locally properly.
Thanks for checking.
Can you make sure control is getting
through our registered
EntityResolver? Ultimately, this
should be resolved
by
org.hibernate.internal.util.______xml.DTDEntityResolver
I'll give this a try.
_________________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
<mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/__mailman/listinfo/hibernate-dev
<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
_________________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/__mailman/listinfo/hibernate-dev
<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
10:15 a.m.
For info hibernate.org <http://hibernate.org/> seems to be “down” *if* you are
behind the Red Hat VPN (I can still access though). So that’s probably some IT filtering
going on because we are some kind of subversive site. That makes sense :)
Anyways, fixing the dtd resolution to go local only remains important.
On 03 Feb 2015, at 20:44, Scott Marlow <smarlow(a)redhat.com>
wrote:
Hibernate.org is down (seeing WildFly testsuite failures).
On 11/19/2014 03:33 PM, Scott Marlow wrote:
> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>> Ah, there is a difference in how core and hem are loading these. This
>> is likely a bug, could you open a Jira?
>
> I created HHH-9511 for this.
>
>>
>> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow(a)redhat.com
>> <mailto:smarlow@redhat.com>> wrote:
>>
>> http://pastebin.com/Baz7FRyf is an initial call stack into
>> org.hibernate.service.__internal.JaxbProcessor. I'm debugging on
>> the Hibernate 4.3 branch and don't hit any break points in
>> org.hibernate.cfg.__Configuration#entityResolver. Perhaps I ended
>> up in the wrong class, not sure. I also set break points in
>> org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
>> org.hibernate.internal.util.____xml.DTDEntityResolver).
>>
>> The first exception that I see is http://pastebin.com/CYd0aNzE
>>
>> On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>>
>> I should have been more complete :)
>>
>> You can either set a breakpoint or crank up logging on that class.
>> Breakpoint debugging is probably better as you could see the
>> whole call
>> stack. These resolvers use a lot of delegation. You could also
>> look
>> at org.hibernate.cfg.__Configuration#entityResolver to verify which
>> specific resolver is being used.
>>
>> On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>> <smarlow(a)redhat.com <mailto:smarlow@redhat.com>
>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>>
wrote:
>>
>> On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>>
>> ORM has had local resolution of these DTDs forever.
>> Something
>> is amiss
>> in your set up. I just ran ORM tests and the DTDs are
>> being
>> resolved
>> locally properly.
>>
>>
>> Thanks for checking.
>>
>>
>> Can you make sure control is getting through our registered
>> EntityResolver? Ultimately, this should be resolved
>> by org.hibernate.internal.util.____xml.DTDEntityResolver
>>
>>
>> I'll give this a try.
>>
>>
>>
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:29 a.m.
Hi,
I am NOT in Red Hat VPN/Network and I do confirm the site is up.
Niko
2015-02-04 10:15 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
For info hibernate.org <http://hibernate.org/> seems to be
“down” *if* you are behind the Red Hat VPN (I can still access though). So that’s probably
some IT filtering going on because we are some kind of subversive site. That makes sense
:)
Anyways, fixing the dtd resolution to go local only remains important.
> On 03 Feb 2015, at 20:44, Scott Marlow <smarlow(a)redhat.com> wrote:
>
> Hibernate.org is down (seeing WildFly testsuite failures).
>
> On 11/19/2014 03:33 PM, Scott Marlow wrote:
>> On 11/19/2014 02:43 PM, Steve Ebersole wrote:
>>> Ah, there is a difference in how core and hem are loading these. This
>>> is likely a bug, could you open a Jira?
>>
>> I created HHH-9511 for this.
>>
>>>
>>> On Wed, Nov 19, 2014 at 12:15 PM, Scott Marlow <smarlow(a)redhat.com
>>> <mailto:smarlow@redhat.com>> wrote:
>>>
>>> http://pastebin.com/Baz7FRyf is an initial call stack into
>>> org.hibernate.service.__internal.JaxbProcessor. I'm debugging on
>>> the Hibernate 4.3 branch and don't hit any break points in
>>> org.hibernate.cfg.__Configuration#entityResolver. Perhaps I ended
>>> up in the wrong class, not sure. I also set break points in
>>> org.hibernate.internal.util.__xml.DTDEntityResolver (don't see
>>> org.hibernate.internal.util.____xml.DTDEntityResolver).
>>>
>>> The first exception that I see is http://pastebin.com/CYd0aNzE
>>>
>>> On 11/19/2014 11:46 AM, Steve Ebersole wrote:
>>>
>>> I should have been more complete :)
>>>
>>> You can either set a breakpoint or crank up logging on that class.
>>> Breakpoint debugging is probably better as you could see the
>>> whole call
>>> stack. These resolvers use a lot of delegation. You could also
>>> look
>>> at org.hibernate.cfg.__Configuration#entityResolver to verify which
>>> specific resolver is being used.
>>>
>>> On Wed, Nov 19, 2014 at 10:35 AM, Scott Marlow
>>> <smarlow(a)redhat.com <mailto:smarlow@redhat.com>
>>> <mailto:smarlow@redhat.com
<mailto:smarlow@redhat.com>>> wrote:
>>>
>>> On 11/19/2014 11:26 AM, Steve Ebersole wrote:
>>>
>>> ORM has had local resolution of these DTDs forever.
>>> Something
>>> is amiss
>>> in your set up. I just ran ORM tests and the DTDs are
>>> being
>>> resolved
>>> locally properly.
>>>
>>>
>>> Thanks for checking.
>>>
>>>
>>> Can you make sure control is getting through our registered
>>> EntityResolver? Ultimately, this should be resolved
>>> by org.hibernate.internal.util.____xml.DTDEntityResolver
>>>
>>>
>>> I'll give this a try.
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3362
days inactive
3439
days old
18 comments
8 participants
participants (8)
-
Carlo de Wolf -
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik -
Nicolas Helleringer -
Sanne Grinovero -
Scott Marlow -
Steve Ebersole