Discussion:
hibernate.cfg.xml and mapping files not found by NetBeans platform
Sanford
2007-04-20 14:30:05 UTC
Permalink
I had hibernate working fine in the Netbeans 5.5 IDE when I wasn't using Netbeans as a rich client platform. Hibernate isn't working now.

In Netbeans, I've created a module suite project. Also created a couple of module projects. I installed hibernate under a library wrapper project. My module projects have a dependency to the hibernate library wrapper. Hibernate runs just fine, but it can't find the hibernate.cfg.xml file or the class mapping files.

I was able to work around finding the hibernate.cfg.xml file by specifying a path (but this obviously isn't ideal):

File configFile = new File("d:\dev\projects\hibernate.cfg.xml");
Configuration cfg = new Configuration();
cfg.configure(filename);

I'm using the following method to lookup the mapping files:

cfg.addclass(org.sanford.model.Class1.class);

Before moving to Netbeans as a platform, this successfully found the mapping file in org\sanford\model\build\classes.

I could really use some help figuring out where to put the hibernate.cfg.xml and mapping files and how to instruct NetBeans platform to reference them.

Thanks,

Andy
Stanczak Group
2007-04-21 17:47:51 UTC
Permalink
I'm in the same boat. I'm just not sure where to put the files. Nothing
seems to be found. I've moved them all over. You get any further with this?
Post by Sanford
I had hibernate working fine in the Netbeans 5.5 IDE when I wasn't
using Netbeans as a rich client platform. Hibernate isn't working now.
In Netbeans, I've created a module suite project. Also created a
couple of module projects. I installed hibernate under a library
wrapper project. My module projects have a dependency to the
hibernate library wrapper. Hibernate runs just fine, but it can't
find the hibernate.cfg.xml file or the class mapping files.
I was able to work around finding the hibernate.cfg.xml file by
File configFile = new File("d:\dev\projects\hibernate.cfg.xml");
Configuration cfg = new Configuration();
cfg.configure(filename);
cfg.addclass(org.sanford.model.Class1.class);
Before moving to Netbeans as a platform, this successfully found the
mapping file in org\sanford\model\build\classes.
I could really use some help figuring out where to put the
hibernate.cfg.xml and mapping files and how to instruct NetBeans
platform to reference them.
Thanks,
Andy
--
Justin Stanczak
Stanczak Group
812-735-3600

"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
Fabrizio Giudici
2007-04-21 18:28:06 UTC
Permalink
Post by Stanczak Group
I'm in the same boat. I'm just not sure where to put the files.
Nothing seems to be found. I've moved them all over. You get any
further with this?
Post by Sanford
I had hibernate working fine in the Netbeans 5.5 IDE when I wasn't
using Netbeans as a rich client platform. Hibernate isn't working now.
In Netbeans, I've created a module suite project. Also created a
couple of module projects. I installed hibernate under a library
wrapper project. My module projects have a dependency to the
hibernate library wrapper. Hibernate runs just fine, but it can't
find the hibernate.cfg.xml file or the class mapping files. I was
able to work around finding the hibernate.cfg.xml file by
File configFile = new File("d:\dev\projects\hibernate.cfg.xml");
Configuration cfg = new Configuration();
cfg.configure(filename);
cfg.addclass(org.sanford.model.Class1.class);
Before moving to Netbeans as a platform, this successfully found
the mapping file in org\sanford\model\build\classes.
I could really use some help figuring out where to put the
hibernate.cfg.xml and mapping files and how to instruct NetBeans
platform to reference them.
Thanks,
Andy
This works for me: I have a specialized module names Persistence
which holds a Configuration instance. Then:

1) If the hibernate.hbm.xml file is in the same folder as the class
it refers to, this just works:

configuration.addClass(clazz);

2) It the config file is in another directory;

configuration.addInputStream(Thread.currentThread
().getContextClassLoader().getResourceAsStream("it/tidalwave/
bluemarine/gallery/adapter/Gallery.hbm.xml"));
configuration.addClass(clazz);

In both cases you must be sure that the SessionFactory is recreated
_after_ the configuraiton.addXXX() methods.

sessionFactory = configuration.buildSessionFactory();
--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
***@tidalwave.it - mobile: +39 348.150.6941
Stanczak Group
2007-04-21 18:52:35 UTC
Permalink
So programmatic configuration is the only way? The other option I was
looking at was using a Options panel to hold the Hibernate configuration
options and then just load the classes like you're showing. Does that
sound like it would work? Also is the a tutorial on using the options panel?
Post by Stanczak Group
I'm in the same boat. I'm just not sure where to put the files.
Nothing seems to be found. I've moved them all over. You get any
further with this?
Post by Sanford
I had hibernate working fine in the Netbeans 5.5 IDE when I wasn't
using Netbeans as a rich client platform. Hibernate isn't working now.
In Netbeans, I've created a module suite project. Also created a
couple of module projects. I installed hibernate under a library
wrapper project. My module projects have a dependency to the
hibernate library wrapper. Hibernate runs just fine, but it can't
find the hibernate.cfg.xml file or the class mapping files. I was
able to work around finding the hibernate.cfg.xml file by specifying
File configFile = new File("d:\dev\projects\hibernate.cfg.xml");
Configuration cfg = new Configuration();
cfg.configure(filename);
cfg.addclass(org.sanford.model.Class1.class);
Before moving to Netbeans as a platform, this successfully found
the mapping file in org\sanford\model\build\classes.
I could really use some help figuring out where to put the
hibernate.cfg.xml and mapping files and how to instruct NetBeans
platform to reference them.
Thanks,
Andy
This works for me: I have a specialized module names Persistence which
1) If the hibernate.hbm.xml file is in the same folder as the class it
configuration.addClass(clazz);
2) It the config file is in another directory;
configuration.addInputStream(Thread.currentThread().getContextClassLoader().getResourceAsStream("it/tidalwave/bluemarine/gallery/adapter/Gallery.hbm.xml"));
configuration.addClass(clazz);
In both cases you must be sure that the SessionFactory is recreated
_after_ the configuraiton.addXXX() methods.
sessionFactory = configuration.buildSessionFactory();
--Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
--
Justin Stanczak
Stanczak Group
812-735-3600

"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
Fabrizio Giudici
2007-04-21 19:02:28 UTC
Permalink
Post by Stanczak Group
So programmatic configuration is the only way?
Don't know if it's the only way... I only know that it works :-)
Post by Stanczak Group
The other option I was looking at was using a Options panel to hold
the Hibernate configuration options and then just load the classes
like you're showing. Does that sound like it would work?
Theoretically it should work, the only requirement is that you have a
single instance of Configuration shared to all the modules. But I
don't have precisely understood what you mean to do.
--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
***@tidalwave.it - mobile: +39 348.150.6941
Stanczak Group
2007-04-21 19:51:57 UTC
Permalink
It seems like with NB's being an application framework there would be a
set way and/or clear path to do this kind of thing. Simple put I need to
supply Hibernate and Log4J with configuration files. Not knowing
everything about NB's I'm having trouble seeing a clear method using
this application framework.
Post by Fabrizio Giudici
Post by Stanczak Group
So programmatic configuration is the only way?
Don't know if it's the only way... I only know that it works :-)
Post by Stanczak Group
The other option I was looking at was using a Options panel to hold
the Hibernate configuration options and then just load the classes
like you're showing. Does that sound like it would work?
Theoretically it should work, the only requirement is that you have a
single instance of Configuration shared to all the modules. But I
don't have precisely understood what you mean to do.
--Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
--
Justin Stanczak
Stanczak Group
812-735-3600

"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
Sanford
2007-04-22 11:24:25 UTC
Permalink
Totally agree with you. Wouldn't it be nice to have a "configuration file
wrapper project" like the library wrapper on the netbeans menu. You could
then specify which other projects depended on it...

Andy


----- Original Message -----
From: "Stanczak Group" <***@stanczakgroup.com>
To: <***@openide.netbeans.org>
Sent: Saturday, April 21, 2007 3:51 PM
Subject: Re: [openide-dev] hibernate.cfg.xml and mapping files not found by
NetBeans platform
Post by Stanczak Group
It seems like with NB's being an application framework there would be a
set way and/or clear path to do this kind of thing. Simple put I need to
supply Hibernate and Log4J with configuration files. Not knowing
everything about NB's I'm having trouble seeing a clear method using this
application framework.
Post by Fabrizio Giudici
Post by Stanczak Group
So programmatic configuration is the only way?
Don't know if it's the only way... I only know that it works :-)
Post by Stanczak Group
The other option I was looking at was using a Options panel to hold the
Hibernate configuration options and then just load the classes like
you're showing. Does that sound like it would work?
Theoretically it should work, the only requirement is that you have a
single instance of Configuration shared to all the modules. But I don't
have precisely understood what you mean to do.
--Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
--
Justin Stanczak
Stanczak Group
812-735-3600
"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
Fabrizio Giudici
2007-04-22 12:35:53 UTC
Permalink
Post by Sanford
Totally agree with you. Wouldn't it be nice to have a
"configuration file wrapper project" like the library wrapper on
the netbeans menu. You could then specify which other projects
depended on it...
Post by Stanczak Group
It seems like with NB's being an application framework there would
be a set way and/or clear path to do this kind of thing. Simple
put I need to supply Hibernate and Log4J with configuration files.
Not knowing everything about NB's I'm having trouble seeing a
clear method using this application framework.
Well, you don't need any special project type here: just a plain
module which contains the configuration files and feed them to the
proper API. As I said, I have one for Hibernate; and I add that I
have another for the logging stuff.
--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
***@tidalwave.it - mobile: +39 348.150.6941
Manas, Eduard
2007-04-24 08:45:58 UTC
Permalink
Sometime ago we discussed a similar problem:
http://www.netbeans.org/issues/show_bug.cgi?id=98102

Basically the current module organisation, while it is powerful and
keeps things simple, it makes life hell when you want to work with 3rd
party frameworks like hibernate and spring (or both together as in my
case!).

A solution that was suggested is to have the option for several modules
to share same class loader, which is different to having cyclical module
dependencies. This solution, however, was swiftly discarded because it
was against the 'purity' of the current Netbeans module structure.

Not sure if there were further talks on this.

Eduard

-----Original Message-----
From: Sanford [mailto:***@maine.rr.com]
Sent: Sunday, April 22, 2007 12:24 PM
To: ***@openide.netbeans.org
Subject: Re: [openide-dev] hibernate.cfg.xml and mapping files not found
by NetBeans platform

Totally agree with you. Wouldn't it be nice to have a "configuration
file wrapper project" like the library wrapper on the netbeans menu.
You could then specify which other projects depended on it...

Andy


----- Original Message -----
From: "Stanczak Group" <***@stanczakgroup.com>
To: <***@openide.netbeans.org>
Sent: Saturday, April 21, 2007 3:51 PM
Subject: Re: [openide-dev] hibernate.cfg.xml and mapping files not found
by NetBeans platform
Post by Stanczak Group
It seems like with NB's being an application framework there would be
a set way and/or clear path to do this kind of thing. Simple put I
need to supply Hibernate and Log4J with configuration files. Not
knowing everything about NB's I'm having trouble seeing a clear method
using this application framework.
Post by Fabrizio Giudici
Post by Stanczak Group
So programmatic configuration is the only way?
Don't know if it's the only way... I only know that it works :-)
Post by Stanczak Group
The other option I was looking at was using a Options panel to hold
the Hibernate configuration options and then just load the classes
like you're showing. Does that sound like it would work?
Theoretically it should work, the only requirement is that you have a
single instance of Configuration shared to all the modules. But I
don't have precisely understood what you mean to do.
--Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave
s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
--
Justin Stanczak
Stanczak Group
812-735-3600
"All that is necessary for the triumph of evil is that good men do nothing."
Edmund Burke
David Strupl
2007-04-24 09:01:52 UTC
Permalink
Hello,

I don't think that the possibility "was swiftly discarded because it
was against the 'purity' of the current Netbeans module structure."

I believe it was not implemented because nobody was willing to invest
enough energy to bring the solution to life.
]
Please note that nothing prevents you from modifying the module system
and use the modified version. While of course there are big benefits of
using the stock NetBeans core when there is no way forward you can patch
it as you like.

We use NetBeans as a base for our application - currently we use patched
release50 version. You can find all our changes on branch
platform_32247-50 - I am trying hard to get all our changes to the trunk
so we might eventually use plain NB 6.0. But if we will find that we
need a patch we will use a patched version again. I don't think there is
anything wrong with that approach.

If I remember correctly people didn't want to invest their time to
patches that might get rejected from the code base. I understand only
partially their position - they have always the possibility to run their
patched version for their application so the possible effort of creating
the patch is not wasted IMHO.

Best regards,

David
Post by Manas, Eduard
http://www.netbeans.org/issues/show_bug.cgi?id=98102
Basically the current module organisation, while it is powerful and
keeps things simple, it makes life hell when you want to work with 3rd
party frameworks like hibernate and spring (or both together as in my
case!).
A solution that was suggested is to have the option for several modules
to share same class loader, which is different to having cyclical module
dependencies. This solution, however, was swiftly discarded because it
was against the 'purity' of the current Netbeans module structure.
Not sure if there were further talks on this.
Eduard
Manas, Eduard
2007-04-24 13:48:24 UTC
Permalink
David,
Post by David Strupl
I believe it was not implemented because nobody was willing to invest
enough energy to bring the solution to life
... in other words, it was swiftly discarded ;)

Personally I don't like branches. They make maintenance a nightmare. I
remember one company I worked for where they had a branch for each
customer. Each bug fix needed to be patched in most branches. Testing
time required for each branch was expensive (doing same/similar
testing), plus developing new functionality and then merging it back
into branches a problem. Put simply that approach just doesn't scale.
Eventually they saw the light and we re-designed the application so that
branches were no longer needed for maintaining customer code.

I am happy branching off 5.0 works for you. I don't think however this
is a good solution for many people. To start with you need to have a
good internal knowledge of the Netbeans platform. Many people either
don't have time, or just don't want to know this. Additionally you need
considerable efforts to keep up to date with patches. Merging new
functionality added in 5.5 or 6.0 will just be a lot of effort.
Finally, once you decide to upgrade to the latest version (e.g. 6.0),
you might end up with the headache that most of your custom changes your
application depends on will not be there.

Using the non-branched officially maintained version saves you from all
these headaches (well at least that's the theory).

Eduard

-----Original Message-----
From: David Strupl [mailto:***@solutions.cz]
Sent: Tuesday, April 24, 2007 10:02 AM
To: ***@openide.netbeans.org
Subject: Re: [openide-dev] hibernate.cfg.xml and mapping files not found
by NetBeans platform

Hello,

I don't think that the possibility "was swiftly discarded because it was
against the 'purity' of the current Netbeans module structure."

I believe it was not implemented because nobody was willing to invest
enough energy to bring the solution to life.
]
Please note that nothing prevents you from modifying the module system
and use the modified version. While of course there are big benefits of
using the stock NetBeans core when there is no way forward you can patch
it as you like.

We use NetBeans as a base for our application - currently we use patched
release50 version. You can find all our changes on branch
platform_32247-50 - I am trying hard to get all our changes to the trunk
so we might eventually use plain NB 6.0. But if we will find that we
need a patch we will use a patched version again. I don't think there is
anything wrong with that approach.

If I remember correctly people didn't want to invest their time to
patches that might get rejected from the code base. I understand only
partially their position - they have always the possibility to run their
patched version for their application so the possible effort of creating
the patch is not wasted IMHO.

Best regards,

David
Post by David Strupl
http://www.netbeans.org/issues/show_bug.cgi?id=98102
Basically the current module organisation, while it is powerful and
keeps things simple, it makes life hell when you want to work with 3rd
party frameworks like hibernate and spring (or both together as in my
case!).
A solution that was suggested is to have the option for several
modules to share same class loader, which is different to having
cyclical module dependencies. This solution, however, was swiftly
discarded because it was against the 'purity' of the current Netbeans
module structure.
Post by David Strupl
Not sure if there were further talks on this.
Eduard
David Strupl
2007-04-24 14:38:38 UTC
Permalink
Hello,
Post by Manas, Eduard
Using the non-branched officially maintained version saves you from all
these headaches (well at least that's the theory).
I totally agree here. That's why we are trying hard to bring all of our
changes to the trunk.

But sometimes there is no other way - e.g. when we start using NB
version, say 5.0, it is close to release or already released. And if we
want to make some change there what other option do we have? We need a
feature or bugfix and are not willing to wait 2 years for the next
release. Not talking about the controversial cases when we are the only
ones that need such a change (but even there we are trying to find some
way to e.g. add only a hook to be able to change the default) ...

But to return the original topic: the problem there was that the patch
was not on the table (yet) and the people feel discouraged to even work
on it when there was a feeling it might be rejected. I hope I said that
I understand their position but at the same time I understand the module
owner's position that he did not want to maintain something he does not
need. And in such situation the branching seemed appropriate from my
perspective.

I hope that my posts are not too much pro-branching - it was not the
intention. Using the common code base is much better --- I just felt I
should have mentioned that the branching option is always there ...

Br,

David
Manas, Eduard
2007-04-24 15:50:15 UTC
Permalink
I understand the module owner's position that he did not want to
maintain something he does not need.

The other side of the coin is that Netbeans is trying to establishing
the platform as a leading framework in which to develop applications.
In my opinion the position "we don't need this because it is not of use
to the IDE" does not help towards achieving this goal.

The key to Netbeans platform is to attract as many developers and
applications as possible, so that when eventually Sun decides to pull
the plug, its user base is large enough to keep it going. Or even
better, they decide to invest more resources because it is more popular.
This fix is needed to attract developers and applications using well
known and popular libraries such as spring, hibernate, Jasper reports or
JFreeChart.

Eduard


-----Original Message-----
From: David Strupl [mailto:***@solutions.cz]
Sent: Tuesday, April 24, 2007 3:39 PM
To: ***@openide.netbeans.org
Subject: Re: [openide-dev] hibernate.cfg.xml and mapping files not found
by NetBeans platform

Hello,
Using the non-branched officially maintained version saves you from
all these headaches (well at least that's the theory).
I totally agree here. That's why we are trying hard to bring all of our
changes to the trunk.

But sometimes there is no other way - e.g. when we start using NB
version, say 5.0, it is close to release or already released. And if we
want to make some change there what other option do we have? We need a
feature or bugfix and are not willing to wait 2 years for the next
release. Not talking about the controversial cases when we are the only
ones that need such a change (but even there we are trying to find some
way to e.g. add only a hook to be able to change the default) ...

But to return the original topic: the problem there was that the patch
was not on the table (yet) and the people feel discouraged to even work
on it when there was a feeling it might be rejected. I hope I said that
I understand their position but at the same time I understand the module
owner's position that he did not want to maintain something he does not
need. And in such situation the branching seemed appropriate from my
perspective.

I hope that my posts are not too much pro-branching - it was not the
intention. Using the common code base is much better --- I just felt I
should have mentioned that the branching option is always there ...

Br,

David

Javier Molina
2007-04-23 09:16:45 UTC
Permalink
Post by Sanford
In Netbeans, I've created a module suite project. Also created a couple
of module projects. I installed hibernate under a library wrapper
project. My module projects have a dependency to the hibernate library
wrapper. Hibernate runs just fine, but it can't find the
hibernate.cfg.xml file or the class mapping files.
I was able to work around finding the hibernate.cfg.xml file by
File configFile = new File("d:\dev\projects\hibernate.cfg.xml");
Configuration cfg = new Configuration();
cfg.configure(filename);
I am using hibernate within NB successfully. I have a library wrapper
for Hibernate and a different module called Persistence with the
configuration files. This module has a class called "PersistenceBroker"
(in package, let's say, com.example) that initializes the
SessionFactory. It loads the configuration file like this:


String configFilePath = "/com/example/hibernate.cfg.xml";
URL configFileURL = PersistenceBroker.class.getResource(configFilePath);
Configuration configuration = (new
Configuration()).configure(configFileURL);


Try and see if using a URL instead of trying to load from a file helps you
Loading...