another Trails/Hibernate newbie question

[Mark Dzmura]

Hi:

I have numerous persistent classes that I'd like Hibernate to see.  Moving from a simple prototype to something more complicated,
many of my @entity classes are in sub-projects packaged as jar's and included in the main Trails webapp, in the lib/ directory.

However, the Hibernate SchemaUpdate seems only to find classes in the trails project - in the classes/ directory.  Entity classes inside
jars in the lib/ directory are not discovered.

How can I get SchemaUpdate to find ALL classes annotated with @Entity ??

Thanks,
Mark

[Kalle Korhonen-2]

The classes are discovered by Java apt and the corresponding entries written to the hibernate.cfg.xml by our HibernateAnnotationProcessorFactory. Apt works similarly to javac (even merged into javac in Java 6) and as such, entities in already compiled libraries cannot unfortunately be discovered this way. As an immediate solution, I'd just manage mapping of those entities myself. You should add lines like "<mapping class=" com.mypackage.MyLibEntity"/> to your hibernate.cfg.xml file in src/main/resources for the entities that come from libraries. These won't be overwritten; our Apt processor just adds entries to the configuration for the classes that are to be compiled. This isn't too bad as presumably, libs should be more stable than the code you are currently developing. This is also the approach taken in the security example for using the built-in entity org.trails.security.ExipiringKey for a remember-me implementation with rolling cookies, take a look.

In the long run, using an Entity Manager might solve it for you if you are running in J2EE container. More generally, integrating with JBoss micro container is in the roadmap as a possibility. We'll take a look into it at some point but I wouldn't hold my breath :)

Kalle

On 10/8/07, Mark Dzmura <mark.dzmura@...> wrote:

Hi:

I have numerous persistent classes that I'd like Hibernate to see.  Moving from a simple prototype to something more complicated,
many of my @entity classes are in sub-projects packaged as jar's and included in the main Trails webapp, in the lib/ directory.

However, the Hibernate SchemaUpdate seems only to find classes in the trails project - in the classes/ directory.  Entity classes inside
jars in the lib/ directory are not discovered.

How can I get SchemaUpdate to find ALL classes annotated with @Entity ??

Thanks,
Mark

[Mark Dzmura]

Thanks for the clear explanations.

Still not working for me, though ... I added my POJO' s to src/main/resources/hibernate.cfg.xml.

mvn clean
mvn jetty:run-exploded

I looked in the exploded war at target/<mywebapp>/WEB-INF/classes/hibernate.cfg.xml, and it looks like the original (none of my mappings are there):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" " http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>
  <session-factory>
    <mapping class="com.skymark.MyDomainObject"/>
  </session-factory>
</hibernate-configuration>

I took a look at the source to HibernateAnnotationProcessorFactory in FishEye (most recent version), and it looks like it just reads the file, adds new mappings, and writes the file... but there is one place where it uses an xpath expression, it looks like, to remove trails-specific classes...
SO, I added another mapping for the class "org.trails.your.mother" and re-built - lo and behold, the fake "org.trails" class was in the target hibernate.cfg.xml!

Is this what's intended, or is the sense of the xpath expression backwards ??

Thanks,
Mark

On 10/8/07, Kalle Korhonen <kalle.o.korhonen@...> wrote:

The classes are discovered by Java apt and the corresponding entries written to the hibernate.cfg.xml by our HibernateAnnotationProcessorFactory. Apt works similarly to javac (even merged into javac in Java 6) and as such, entities in already compiled libraries cannot unfortunately be discovered this way. As an immediate solution, I'd just manage mapping of those entities myself. You should add lines like "<mapping class=" com.mypackage.MyLibEntity"/> to your hibernate.cfg.xml file in src/main/resources for the entities that come from libraries. These won't be overwritten; our Apt processor just adds entries to the configuration for the classes that are to be compiled. This isn't too bad as presumably, libs should be more stable than the code you are currently developing. This is also the approach taken in the security example for using the built-in entity org.trails.security.ExipiringKey for a remember-me implementation with rolling cookies, take a look.

In the long run, using an Entity Manager might solve it for you if you are running in J2EE container. More generally, integrating with JBoss micro container is in the roadmap as a possibility. We'll take a look into it at some point but I wouldn't hold my breath :)

Kalle

On 10/8/07, Mark Dzmura <mark.dzmura@...> wrote:

Hi:

I have numerous persistent classes that I'd like Hibernate to see.  Moving from a simple prototype to something more complicated,
many of my @entity classes are in sub-projects packaged as jar's and included in the main Trails webapp, in the lib/ directory.

However, the Hibernate SchemaUpdate seems only to find classes in the trails project - in the classes/ directory.  Entity classes inside
jars in the lib/ directory are not discovered.

How can I get SchemaUpdate to find ALL classes annotated with @Entity ??

Thanks,
Mark

[Kalle Korhonen-2]

On 10/9/07, Mark Dzmura <mark.dzmura@...> wrote:

Thanks for the clear explanations.
Still not working for me, though ... I added my POJO' s to src/main/resources/hibernate.cfg.xml.
I looked in the exploded war at target/<mywebapp>/WEB-INF/classes/hibernate.cfg.xml, and it looks like the original (none of my mappings are there):
I took a look at the source to HibernateAnnotationProcessorFactory in FishEye (most recent version), and it looks like it just reads the file, adds new mappings, and writes the file... but there is one place where it uses an xpath expression, it looks like, to remove trails-specific classes...

SO, I added another mapping for the class "org.trails.your.mother" and re-built - lo and behold, the fake " org.trails" class was in the target hibernate.cfg.xml!

No, the xpath is "mapping[not(starts-with(@class, '"
                    + TRAILS_PACKAGE + "'))]";

So it removes classes that are *not* in Trails package. So uh-huh... it won't work for you. I suppose the original reason was that it was meant to be maintained automatically. But I don't think enforcing that makes sense and you have a good case against it. Would you mind filing an issue on this in our JIRA?

As a sad short-time work-around, is it an option for you to keep your entities in org.trails package? If not, I can easily fix this in the 1.1.x branch, but it'd mean you have to use 1.1.2-SNAPSHOT for the time being. Would that be okay? As ugly as it is, I'm hesitant to push out a new release just to fix this.

Kalle
 

Is this what's intended, or is the sense of the xpath expression backwards ??

Thanks,
Mark

On 10/8/07, Kalle Korhonen <kalle.o.korhonen@...> wrote:

The classes are discovered by Java apt and the corresponding entries written to the hibernate.cfg.xml by our HibernateAnnotationProcessorFactory. Apt works similarly to javac (even merged into javac in Java 6) and as such, entities in already compiled libraries cannot unfortunately be discovered this way. As an immediate solution, I'd just manage mapping of those entities myself. You should add lines like "<mapping class=" com.mypackage.MyLibEntity"/> to your hibernate.cfg.xml file in src/main/resources for the entities that come from libraries. These won't be overwritten; our Apt processor just adds entries to the configuration for the classes that are to be compiled. This isn't too bad as presumably, libs should be more stable than the code you are currently developing. This is also the approach taken in the security example for using the built-in entity org.trails.security.ExipiringKey for a remember-me implementation with rolling cookies, take a look.

In the long run, using an Entity Manager might solve it for you if you are running in J2EE container. More generally, integrating with JBoss micro container is in the roadmap as a possibility. We'll take a look into it at some point but I wouldn't hold my breath :)

Kalle

On 10/8/07, Mark Dzmura <mark.dzmura@...> wrote:

Hi:

I have numerous persistent classes that I'd like Hibernate to see.  Moving from a simple prototype to something more complicated,
many of my @entity classes are in sub-projects packaged as jar's and included in the main Trails webapp, in the lib/ directory.

However, the Hibernate SchemaUpdate seems only to find classes in the trails project - in the classes/ directory.  Entity classes inside
jars in the lib/ directory are not discovered.

How can I get SchemaUpdate to find ALL classes annotated with @Entity ??

Thanks,
Mark

[Alejandro Scandroli]

Hi Mark

The xpath is to skip Trails's entities only (btw, I think we removed them all)
As a quick workaround you can remove the apt plugin from the pom.xml

                                <groupId>org.apache.myfaces.tobago</groupId>
                                <artifactId>maven-apt-plugin</artifactId>

Removing the apt plugin will make you responsible for (manually)
updating hibernate.cfg.xml whenever you create a new Entity.

Alejandro.


On 10/9/07, Mark Dzmura <mark.dzmura@...> wrote:

> Thanks for the clear explanations.
>
> Still not working for me, though ... I added my POJO' s to
> src/main/resources/hibernate.cfg.xml.
>
> mvn clean
> mvn jetty:run-exploded
>
> I looked in the exploded war at
> target/<mywebapp>/WEB-INF/classes/hibernate.cfg.xml, and it
> looks like the original (none of my mappings are there):
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate
> Configuration DTD 3.0//EN" "
> http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
>
> <hibernate-configuration>
>   <session-factory>
>     <mapping class="com.skymark.MyDomainObject"/>
>   </session-factory>
> </hibernate-configuration>
>
> I took a look at the source to
> HibernateAnnotationProcessorFactory in FishEye (most recent
> version), and it looks like it just reads the file, adds new mappings, and
> writes the file... but there is one place where it uses an xpath expression,
> it looks like, to remove trails-specific classes...
> SO, I added another mapping for the class "org.trails.your.mother" and
> re-built - lo and behold, the fake "org.trails" class was in the target
> hibernate.cfg.xml!
>
> Is this what's intended, or is the sense of the xpath expression backwards
> ??
>
> Thanks,
> Mark
>
>
>
> On 10/8/07, Kalle Korhonen <kalle.o.korhonen@...> wrote:
> > The classes are discovered by Java apt and the corresponding entries
> written to the hibernate.cfg.xml by our
> HibernateAnnotationProcessorFactory. Apt works similarly to
> javac (even merged into javac in Java 6) and as such, entities in already
> compiled libraries cannot unfortunately be discovered this way. As an
> immediate solution, I'd just manage mapping of those entities myself. You
> should add lines like "<mapping class=" com.mypackage.MyLibEntity"/> to your
> hibernate.cfg.xml file in src/main/resources for the entities that come from
> libraries. These won't be overwritten; our Apt processor just adds entries
> to the configuration for the classes that are to be compiled. This isn't too
> bad as presumably, libs should be more stable than the code you are
> currently developing. This is also the approach taken in the security
> example for using the built-in entity
> org.trails.security.ExipiringKey for a remember-me
> implementation with rolling cookies, take a look.
> >
> > In the long run, using an Entity Manager might solve it for you if you are
> running in J2EE container. More generally, integrating with JBoss micro
> container is in the roadmap as a possibility. We'll take a look into it at
> some point but I wouldn't hold my breath :)
> >
> > Kalle
> >
> >
> >
> >
> > On 10/8/07, Mark Dzmura < mark.dzmura@...> wrote:
> > > Hi:
> > >
> > > I have numerous persistent classes that I'd like Hibernate to see.
> Moving from a simple prototype to something more complicated,
> > > many of my @entity classes are in sub-projects packaged as jar's and
> included in the main Trails webapp, in the lib/ directory.
> > >
> > > However, the Hibernate SchemaUpdate seems only to find classes in the
> trails project - in the classes/ directory.  Entity classes inside
> > > jars in the lib/ directory are not discovered.
> > >
> > > How can I get SchemaUpdate to find ALL classes annotated with @Entity ??
> > >
> > > Thanks,
> > > Mark
> > >
> > >
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Mark Dzmura]

Guys, thanks for the quick and targeted replies.  I thought that the sense was backwards,
since it appeared to be removing anything but org.trails classes, but there weren't any in the
source file...

For the short term, I will try Alejandro's fix of commenting out the apt plugin.
I HOPE it doesn't do anything else important with annotations?
(Also had to comment out the <exclude> which prevents the original hibernate.cfg.xml from being copied over...)

I hope that by the next minor release y'all can come up with a reasonable way to accomodate
this scenario.

Longer term, it would be useful to have an approach to designating entities
which could accomodate users who wanted everything to happen "under the hood",
but also folks who wanted to specify things exactly.

My suggestion:

I'm fairly new to Java annotations, but don't all the annotations end up in the class file?
If so, then the trails build process could have a processor which, in parallel to apt looking
at source files in the immediate project, could look at class files/jars/etc in dependencies
(or at least ones specified by the user. - so it would be useful to have a way to include/exclude
classes from the search by various criteria.)

As usual, Trails should just do something sensible by default, but allow the user to enrich
the behavior with some XML configuration, perhaps as attributes to a plugin in the top-level .pom file ??

Just my thoughts.

Thanks,
Mark

On 10/9/07, Alejandro Scandroli <alejandroscandroli@...> wrote:

Hi Mark

The xpath is to skip Trails's entities only (btw, I think we removed them all)
As a quick workaround you can remove the apt plugin from the pom.xml

                                <groupId>org.apache.myfaces.tobago</groupId>
                                <artifactId>maven-apt-plugin</artifactId>

Removing the apt plugin will make you responsible for (manually)
updating hibernate.cfg.xml whenever you create a new Entity.

Alejandro.


On 10/9/07, Mark Dzmura <mark.dzmura@...> wrote:

> Thanks for the clear explanations.
>
> Still not working for me, though ... I added my POJO' s to
> src/main/resources/hibernate.cfg.xml.
>
> mvn clean
> mvn jetty:run-exploded
>
> I looked in the exploded war at
> target/<mywebapp>/WEB-INF/classes/hibernate.cfg.xml, and it
> looks like the original (none of my mappings are there):

>

> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate
> Configuration DTD 3.0//EN" "
> http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
>
> <hibernate-configuration>
>   <session-factory>
>     <mapping class="com.skymark.MyDomainObject "/>
>   </session-factory>
> </hibernate-configuration>
>
> I took a look at the source to
> HibernateAnnotationProcessorFactory in FishEye (most recent
> version), and it looks like it just reads the file, adds new mappings, and
> writes the file... but there is one place where it uses an xpath expression,
> it looks like, to remove trails-specific classes...
> SO, I added another mapping for the class "org.trails.your.mother " and
> re-built - lo and behold, the fake "org.trails" class was in the target
> hibernate.cfg.xml!
>
> Is this what's intended, or is the sense of the xpath expression backwards
> ??
>
> Thanks,
> Mark
>
>
>
> On 10/8/07, Kalle Korhonen <kalle.o.korhonen@...> wrote:
> > The classes are discovered by Java apt and the corresponding entries
> written to the hibernate.cfg.xml by our
> HibernateAnnotationProcessorFactory. Apt works similarly to
> javac (even merged into javac in Java 6) and as such, entities in already
> compiled libraries cannot unfortunately be discovered this way. As an
> immediate solution, I'd just manage mapping of those entities myself. You
> should add lines like "<mapping class=" com.mypackage.MyLibEntity"/> to your
> hibernate.cfg.xml file in src/main/resources for the entities that come from
> libraries. These won't be overwritten; our Apt processor just adds entries
> to the configuration for the classes that are to be compiled. This isn't too
> bad as presumably, libs should be more stable than the code you are
> currently developing. This is also the approach taken in the security
> example for using the built-in entity
> org.trails.security.ExipiringKey for a remember-me
> implementation with rolling cookies, take a look.
> >
> > In the long run, using an Entity Manager might solve it for you if you are
> running in J2EE container. More generally, integrating with JBoss micro
> container is in the roadmap as a possibility. We'll take a look into it at
> some point but I wouldn't hold my breath :)
> >
> > Kalle
> >
> >
> >
> >
> > On 10/8/07, Mark Dzmura < mark.dzmura@...> wrote:
> > > Hi:
> > >
> > > I have numerous persistent classes that I'd like Hibernate to see.
> Moving from a simple prototype to something more complicated,
> > > many of my @entity classes are in sub-projects packaged as jar's and
> included in the main Trails webapp, in the lib/ directory.
> > >
> > > However, the Hibernate SchemaUpdate seems only to find classes in the
> trails project - in the classes/ directory.  Entity classes inside
> > > jars in the lib/ directory are not discovered.
> > >
> > > How can I get SchemaUpdate to find ALL classes annotated with @Entity ??
> > >
> > > Thanks,
> > > Mark
> > >
> > >
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email