Well, Scanner and the code using it is I think isolated from the URL
protocols. But our default implementation that uses the JarVisitor code
is our attempt at supporting most environments. We managed to amke it
work for Websphere, Weblogic, Tomcat, plain SE etc. That's why this part
is so complicat
Hibernate ORM 4.2.0.Final and 4.1.11.Final were just released. The full
changelogs can be viewed here:
https://hibernate.atlassian.net/secure/ReleaseNote.jspa?projectId=10031&version=12753
https://hibernate.atlassian.net/secure/ReleaseNote.jspa?projectId=10031&version=12752
Note that this is the
Also, I think another reason that the current scanning code is so
complicated in the mapping file case is because we are not "just
scanning". If I understand correctly, we also use the
Scanner#getFilesInJar call as an opportunity to resolve named mappings
files.
Not saying its a bad thing to
https://hibernate.atlassian.net/browse/HHH-8086
But I will change that from Bug to New Feature if it was not previously
documented anywhere.
To be honest, little nervous doing this as it effects provider
portability.
On Mon 18 Mar 2013 11:09:22 AM CDT, Steve Ebersole wrote:
> Out of curiosity,
On 18.03.2013, at 17:09, Steve Ebersole wrote:
> Out of curiosity, where is this documented as being supported?
http://docs.jboss.org/hibernate/entitymanager/3.6/reference/en/html/configuration.html
The class element specifies a fully qualified class name that you will map. By
default all pro
Out of curiosity, where is this documented as being supported?
On Mon 18 Mar 2013 08:34:29 AM CDT, Steve Ebersole wrote:
> The spec does not say anything about explicitly specifying packages.
> I was not aware of handling for that in the old code which I have been
> trying to de-spaghetti for som
What would ScanOptions look like? What about this:
interface ScanOptions {
public boolean scanRootUrlForClasses();
public boolean scanNonRootUrlsForClasses();
public boolean detectHibernateMappingFiles();
}
I think that is the bare minimum amount of information needed to scan.
D
On Mon 18 Mar 2013 09:10:40 AM CDT, Emmanuel Bernard wrote:
>
> That was the point of the Scanning API in the first place: not to depend
> on specific APIs like the VirtualFile. That and the fact that JBoss AS
> had Jandex and we did not were the reason for Ales and me to have this
> interface.
Ok,
ORM called it "concurrent" but its really not. Its just "mutation
safe". Talking about its usage of IdentityMap.
And we do actually have a few uses of IdentityMap still left. The
problem with IdentityMap was always its use to store entities because we
could not rely on their equals/hashcode,
I don't know about Validator, but in the ORM case at least we didn't
need all the overhead of a concurrent / threadsafe implementation.
On 18 March 2013 14:21, Emmanuel Bernard wrote:
> Galder's work could very well be an interesting solution where we use
> IdentityMap.
>
> I know ORM has be usin
Galder's work could very well be an interesting solution where we use
IdentityMap.
I know ORM has be using it less with the bytecode rework but I think we
still use it in particular in Hibernate Validator.
___
hibernate-dev mailing list
hibernate-dev@lis
On Mon 2013-03-18 8:15, Steve Ebersole wrote:
> On Mon 18 Mar 2013 05:14:01 AM CDT, Emmanuel Bernard wrote:
> >
> >JBoss AS does use this contract so if you break it, we will need some
> >kind of compatibility matrix between Hibernate and JBoss AS and EAP.
> >Not unsurmountable but always a small
The spec does not say anything about explicitly specifying packages. I
was not aware of handling for that in the old code which I have been
trying to de-spaghetti for some time, I can add that capability back in.
On 03/18/2013 08:22 AM, Christian Bauer wrote:
> Trying to upgrade to 4.3-SNAPSHOT
Trying to upgrade to 4.3-SNAPSHOT, the
EntityManagerFactoryBuilderImpl.indexResource() is failing for my
persistence.xml configuration in Java SE with
Persistence.createEntityManagerFactory():
myDS
org.jpwh.model
org.jpwh.model.simple.Item
org.jpwh.model.simple.U
On Mon 18 Mar 2013 05:14:01 AM CDT, Emmanuel Bernard wrote:
>
> JBoss AS does use this contract so if you break it, we will need some
> kind of compatibility matrix between Hibernate and JBoss AS and EAP.
> Not unsurmountable but always a small annoyance.
> Maybe other environments also make use of
JBoss AS does use this contract so if you break it, we will need some
kind of compatibility matrix between Hibernate and JBoss AS and EAP.
Not unsurmountable but always a small annoyance.
Maybe other environments also make use of this interface but I am not
aware of them.
I'm surprised getUnqualif
16 matches
Mail list logo
