1 2 Previous Next 21 Replies Latest reply on Jun 4, 2005 3:53 AM by mikezzz

    More jASEN

      From the "Integrating jASEN" thread one of the jASEN developers said that the dictionaries simply need to be available on the classpath.

      For a first cut deployment w/o Hibernate can I use /server/default/data as the storage location of the data? Will that path be available to the jASEN engine without code mods?

      If not, should the data simply go into mail.ear/mail.sar/META-INF/???

      Many thanks!

      rjsjr

        • 1. Re: More jASEN
          pilhuhn

          I am not sure, if I understood your question correctly, but data/ is (afaik) not on the classpath, while conf/ is.

          • 2. Re: More jASEN

            I would put it inside the mail.sar for the time being.

            • 3. Re: More jASEN

              Right now I'm doing my testing by using the JBoss IDE inside of Eclipse and I've put the two data directories onto the classpath manually. That is obviously not going to work for a real deployment. So what I really need to know is "Where does the data go?"

              The jASEN developers tell me that I have to have the data in the classpath and I was hoping that the data directory would be the appropriate place since I am storing data after all.

              The conf directory may be appropriate though.

              If it isn't appropriate, let me know where it should go...

              rjsjr

              • 4. Re: More jASEN

                 

                "mikezzz" wrote:
                I would put it inside the mail.sar for the time being.


                Where in the .sar? In WEB-INF/lib? Directly in the .sar itself?

                In putting it into the .sar does that make it an "official" part of the distribution? Is that what you want or do you want it to be an optional element? If optional then how do you get it included w/o exploding the .ear file? Two distros perhaps, one with and one without?

                If the data files are in the .sar how easily can it be updated with new definitions?

                It just might be a lot easier to do the Hibernate based Map implementation rather than make these sorts of decisions :)

                rjsjr

                • 5. Re: More jASEN

                  Okay, okay, okay I'll say it so you don't have to.

                  I'm being an idiot. The data would go directly into the .sar and not worry about META-INF/lib...

                  Sigh...

                  • 6. Re: More jASEN

                    It would probably need to go at the base level of SAR.

                    It would require that the user redeploy the application to update the file. However I believe that this needs to happen whenever the configuration changes also so not such a big deal.

                    It kinda depends how we are treating the dictionaries. If you are treating them as configuration then inside the SAR is reasonably valid place for it to go. If the dictionaries are considered as application data then the database is a better place (this is my preference).

                    Mike.

                    • 7. Re: More jASEN

                      Now that I've recovered from my temporary insanity...

                      I was having trouble with deploying a build when I discovered that there are two sections of the build.xml in which I need to specify libs and the config data - one in the jar task for mail.sar and the other in the copy-to sub-task of the mkunwrapped task for creating dev-deploy. So that leads me to my question of...

                      Why does the mkunwrapped task use its own list of files to copy rather than
                      a) Building all of the binary distributables and then exploding them to the dev-deploy directory or
                      b) Using one or more Ant filesets defined outside of the tasks to be referenced inside of the task?

                      I understand that item (a) may not be the desired way to go because you then add a dependency. So why not item (b)? Is there a technical reason that it should not be done?

                      If there is no technical reason and there are no objections then I will move the build to use common filesets to simplify maintenance. If there are objections, let me know what they are and I will either work around them or not do it.

                      The second issue I ran into is that when running the app in the Eclipse/JBoss IDE debugger everything worked great. But when I deployed (after getting the data files into the .sar appropriately) I got exceptions saying that my mail could not be persisted because there was a problem with Hibernate. I've never used Hibernate (I will be happy to make jASEN's map thingy be my first implementation of it after I get the base deploy working) so I don't know if I'm simply missing something off of my classpath or what. The exception I received is...

                      10:07:56,647 INFO [Mail] all headers after loading: MailHeadersImpl (6): [hdr(R
                      eceived = 'Received: from localhost.localdomain.com (localhost 127.0.0.1) by loc
                      alhost.localdomain.com/JBossMail 1.0M3 (127.0.0.1)
                       with SMTP id 1116342476647559.2326712449285; Tue, 17 May 2005 10:07:56 -
                      0500 (CDT)'), hdr(To = 'To: <acoliver@localhost.localdomain.com>'), hdr(From = '
                      From: <acoliver@localhost.localdomain.com>'), hdr(Subject = 'Subject: error'), h
                      dr(Content-Type = 'Content-Type: text/plain; charset=us-ascii'), hdr(Content-Tra
                      nsfer-Encoding = 'Content-Transfer-Encoding: 8bit')]
                      10:07:56,717 DEBUG [PagedStore] Creating Store Item
                      10:07:56,737 DEBUG [SessionFactoryObjectFactory] JNDI lookup: jbossmail.Hibernat
                      eSessionFactory
                      10:07:56,737 DEBUG [SessionFactoryObjectFactory] lookup: uid=8a8a82eb03eb303c010
                      3eb303d680000
                      10:07:56,918 DEBUG [SessionImpl] opened session
                      10:07:56,928 DEBUG [JTATransaction] Looking for UserTransaction under: UserTrans
                      action
                      10:07:56,928 DEBUG [JTATransaction] Obtained UserTransaction
                      10:07:56,928 DEBUG [JTATransaction] beginning new transaction
                      10:07:56,928 DEBUG [HibernateUtil] Begin Transaction: createStoreItem:701837
                      10:07:56,998 DEBUG [PagedStore] Rollback Transaction: 701837
                      10:07:56,998 DEBUG [JTATransaction] rollback
                      10:07:56,998 DEBUG [SessionImpl] transaction completion
                      10:07:57,008 ERROR [PagedStore] Failed to create store item. No persister for: o
                      rg.jboss.mail.store.paged.Blob
                      10:07:57,008 DEBUG [SessionImpl] closing session
                      10:07:57,008 ERROR [Mail] org.jboss.mail.store.StoreException: net.sf.hibernate.
                      MappingException: No persister for: org.jboss.mail.store.paged.Blob
                      org.jboss.mail.store.StoreException: net.sf.hibernate.MappingException: No persi
                      ster for: org.jboss.mail.store.paged.Blob
                       at org.jboss.mail.store.paged.PagedStore.createStoreItem(PagedStore.java
                      :477)
                       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
                      java:39)
                       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
                      sorImpl.java:25)
                       at java.lang.reflect.Method.invoke(Method.java:585)
                       at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
                      er.java:144)
                       at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
                       at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
                       at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
                      java:249)
                       at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
                       at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvoc
                      ationHandler.java:201)
                       at $Proxy84.createStoreItem(Unknown Source)
                       at org.jboss.mail.message.StoredMailBody.newInstance(StoredMailBody.java
                      :60)
                       at org.jboss.mail.message.MailBodyManager.createMailBody(MailBodyManager
                      .java:38)
                       at org.jboss.mail.message.MailBodyManager.createMailBody(MailBodyManager
                      .java:83)



                      Many thanks!

                      rjsjr

                      • 8. Re: More jASEN

                        This exception normally means that it can't find the {Class}.hbm.xml files. Make sure there is a mail.har archive inside the mail.ear and that it contains org/jboss/mail/store/paged/Page.hbm.xml and org/jboss/mail/store/paged/Blob.hbm.xml.

                        Mike.

                        • 9. Re: More jASEN

                          All I have is
                          mail.ear/mail.har/org/jboss/mail/msgstore/hn/

                          that contains
                          HnMessageStore.class
                          HnStoredMessage.class

                          I did an update from CVS right after I posted my message to see if I was out of date but that didn't help.

                          rjsjr

                          • 10. Re: More jASEN

                            I just took a look at the source tree in Eclipse (did another refresh from the root to make sure) and there is only one file in src/hbm and that is the HnStoredMessage xml file.

                            Are the xml files generated or should they have been committed?

                            rjsjr

                            • 11. Re: More jASEN

                              They are generated into build/hbm during the build process. It sounds like the changes you made to the build.xml may have broken this.

                              A clean and deploy generates all of the correct files for me.

                              Mike.

                              • 12. Re: More jASEN

                                When I go into Eclipse and run the "clean" target followed by the "xdoclet" target I get the files that you describe located in
                                build/hbm/**

                                When I run the dev-deploy task I go to
                                build/deploy/dev/mail.har/org/jboss/mail

                                and find only the msgstore directory in there, not the store directory that you are describing.

                                I open up the actual .har file in WinZip and browse through the files and see that the files you describe are in the appropriate location.

                                This tells me that the dev-deploy isn't including those files for the .har. I'm guessing someone updated the jar task but not the copyfiles task...

                                Which is why I want to use common filesets.

                                I would like explicit permission from Mike or Andrew to go forward with this since this is a substantive change in a common file versus simply adding my goodies in here and there...

                                rjsjr

                                • 13. Re: More jASEN

                                  Aaaah, that sounds correct. I tend to use the deploy rather than the dev-deploy task.

                                  Write the code, make it work, send the patch (Ideally 2 patchs, one for the build and one for jASEN, so that we can verify each indenpendently).

                                  If it breaks something we'll fix it, or get you to fix it, or (in my case) shout, kick things and throw our toys from the pram :-)....

                                  Mike.

                                  • 14. Re: More jASEN

                                    I posted a patch named "build.xml-patch.txt" into the wiki patch upload directory.

                                    The purpose of this patch is to create a collection of commone fileset elements used by the mail.sar and mail.har sub-tasks of the jar and mkunwrapped tasks so that maintaining file lists for the deploy and dev-deploy options only has to be performed in one location.

                                    The jASEN specific contributions to the build.xml are commented out in this patch and will not be included in any build.

                                    You can contact me by sending an email to my forum username at gmail.com.

                                    Many thanks!

                                    rjsjr

                                    1 2 Previous Next