On 24 Jan 2013, at 8:25 PM, Steve Ebersole wrote:
> I am looking into the problem of hibernate-issues no longer getting Jira
> notifications. One possible reason is the use of the custom
> "Participants" field in our notification scheme. I am wondering if we
> ought to remove that rule from
The field collects "participants" (creator, assignee, commenters).
There is then a rule in the notification scheme which says that all
participants should get notified.
Autowatch is a little different than. Autowatch says to add a person
to the issue's watcher list when they comment on an iss
testcase reminder should be fixed now.
On Mon 25 Mar 2013 07:28:13 AM CDT, Steve Ebersole wrote:
> The field collects "participants" (creator, assignee, commenters).
> There is then a rule in the notification scheme which says that all
> participants should get notified.
>
> Autowatch is a little
On 25 Jan 2013, at 1:41 PM, Steve Ebersole wrote:
> testcase reminder should be fixed now.
Thanks. Works.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
The one reason I am leery of relying solely on autowatch (and dropping
participants) is that I am pretty sure that autowatch is not
retro-active. Meaning if you have commented on a issue and have been
receiving continuing notifications there is a danger you will no longer
get notifications. U
Not a JAXB expert, so take this all with a grain of salt...
http://docs.oracle.com/javaee/5/api/javax/xml/bind/annotation/XmlSchema.html
is completely unintelligible to me. I guess it assumes a certain level
of XML/JAXP knowledge that I simple lack.
I'd be interested to see what happens if you
Hi Strong,
As per my understanding of JAXB, you can't use one set of JAXB binding
classes for unmarshalling XML files which use different schemas (or
different namespaces).
I can see the following options:
1) Generate different sets of binding classes for the different XSD
versions (namespaces)
We just had a great discussion with Eric on IRC.
Essentially his suggestion (along the same lines the Gunnar suggested)
was to use xslt to adjust the incoming documents to one version (the
latest) of the xsd and use that for jaxb.
An xslt for such a transformation can be seen here:
http://stac
I assume LegacyJPAEventReader is the attempt to work around that in the
general approach discussed?
I wonder if that is working though, as for sure another thing we need
to do there is to alter the version attribute returned on the root. If
the incoming orm.xml, for example, says 1.0 as the ve
Yes, version attribute and namespace would have to be updated to the 2.1
values.
IMO it would still make sense to have a validation step using the original
schema (e.g. the 1.0 one) before, since validation with the 2.1 schema
wouldn't reject any (wrong) elements in e.g. a 1.0 document which where
Well I just noticed that the class is at least attempting to also alter
the version in the StAX events. We'll just have to wait to hear from
Strong whether this setup currently out on github works or not. It is
essentially the approach discussed on IRC.
As for performing the validation up fro
> 2) I am not sure what exact scenario you are are thinking about, but I do not
> see any problem with validating a 1.0 or 2.0 compliant doc with the 2.1 xsd.
I meant cases like this:
...
...
This would not be legal as per the 1.0 schema, since
"delimited-identifier
True. But not sure we care.
On Mon 25 Mar 2013 02:59:13 PM CDT, Gunnar Morling wrote:
> |>|2) I am not sure what exact scenario you are are thinking about, but I do
> not see any problem with validating a 1.0 or 2.0 compliant doc with the 2.1
> xsd.
> I meant cases like this:
>
>
> ...
>
13 matches
Mail list logo
