is there a way to use wildcard for all *.class in a package when doing
cfg.addResource()?

adding classes one by one is difficult in my set up.

Thanks

no, but you can add a directory or jar of mapping files.

Have you considered using Annotations/JPA with that autodiscovery will work for you - even for hbm.xml files.

I am back on this topic again, because now I am concerned about deployment on Tomcat.

When deploying with a .war in a co-hosted environment, you generally do not have tight control on the absolute file path. Referencing .xml embedded in a jar file is also not so convenient (at least it requires a path change compared to the development environment).

shouldn't there be a addJar() which takes just the jar file name instead of File, since the JVM can always find the jar file from its classpath.

Is this actually a show stopper for deploying with .war? how do people get around it?

it's called JPA which standardizes/enables automatically scanning of the classpath.

just because it is a standard, doesn't mean it meets developer's needs.

do you have a solution for the concerns I raised?

what part of use JPA API's is not clear ? :)

You can use hibernate entity manager to do what you want - e.g. scan the classpath for entities.

/max

well, I looked at all the methods for HibernateFactory. which api scans the classpath?

http://www.hibernate.org/hib_docs/entit ... ml_single/

// Use persistence.xml configuration
EntityManagerFactory emf = Persistence.createEntityManagerFactory("manager1")
EntityManager em = emf.createEntityManager(); // Retrieve an application managed entity manager

Session s = (Session)em.getDelegate();

and have whatever hibernate specific fun you want.

ic, you are suggesting pulling all the entitymanager and annotation stuff to get this one additional feature. I gather it means there is no way to scan the classpath using only the core.

that's a bit much for adding one function. it would be very very nice if this feature can be added in the future in the core. here is my vote!!

eh - so you would rather have us add more bulk to the core which anyway is 90% of what "all" the entitymanager and annotation stuff is.

For you it would mean many fewer lines of configuration for adding 2-3 *small* jars to your project....can't understand why that is something to avoid.

btw. you are more than welcome to just take the code in entitymanager to do the autoscanning and then just use that to initialize hibernate - its opensource (and would end up with the same "weight" IMO).

I suggest adding the feature because

1. I did not think this feature in terms of "bulk", like 2-3 jars and a configuration file are more likely considered a bulk for deployment bundling.

2. The Configuration class has all the relevant methods, addClass, addJar, addFile. it seems addJar from the classpath would just complete the set very nicely.

I don't know all of the api's needed to accomplish this off the top of my head. I just imagine it isn't exact a bulk. Of course, if this represents a substantial effort, as you are suggesting, then mine is not a good suggestion.

i'm saying it is not trivial and adding yet another way of scanning (and configuration of it) is not something that is trivial nor really wanted.

yes, you reminded me the need of another configuration file. which what I am trying to eliminate. Right now, I use a properties file to indicate where the hbm files are to Configuration. replacing that with a configuration file for EntityManager gets me no where.

But thanks for pointing out the options.

eh - you would remove the need for that properties file if you used autoscanning...

I know. But using autoscan I would need to add persistence.xml.

save one, add one, there is hardly any incentive to make the change.