On Mon, 17 Oct 2005 09:59 pm, Emmanouil Batsis wrote: > On Monday 17 October 2005 12:59, Michael Ralston wrote: > > I'm just sending it to the list so some people who are interested in > > implementing something similar can get an idea of how I did it. > > Great, thanks. From what i can see you have submitted patches to the lenya > codebase itself, to become more EJB-friendly but not parts from the actual > implementation right?
Yep, attached to this email is a tar of the Session and Entity Beans I made. Note that the actual beans doing stuff are in 'net.stral.access' the beans in 'net.stral.contact' are what I was attaching to the access beans for storing business related information which lenya has no concern with. Also as my last email said, these beans were implemented on a very early version of JBoss EJB3 and they don't work anymore. > > > When I find where I put the code for the actual entity beans etc, I'll > > post that too. But it was written on an early alpha version of Jboss > > EJB3, and it no longer compiles as the api has changed quite a bit. > > I'm currently implementing the backend using session beans and Hibernate 3 > (which is now JBoss' EJB 3 implementation) but without actually using the > EJB 3 entity persister etc; just session beans over DAOs on JBoss. This > approach can be tweacked to work on all appservers (i currently deploy > Hibernate POJOs as a HAR). > Why did you choose to use Hibernate directly, rather than via Entity beans? Just curious as to what other approach I could have taken with my implementation. > > I will eventually rewrite all this code to work with lenya 1.4. If anyone > > else is interesting in a database backend for lenya, let me know and we > > can use this as a starting point. > > Sounds cool but what are we going to use as a workspace to collaborate? > I have a server on the net which I can set up a cvs/subversion server or something if you want to cooperate that way. > Currenty my implementation is as follows: > Mine was fairly similar, but I stayed completely within the JBoss EJB implementation. > > I think the furthest we can go for the lenya trunk (besides making the > signatures more EJB-friendly) is to provide configurable lenya.ac > implementations that will depend on an EJB provided by the user(hence the > configurable part) and an additional interface for that EJB to implement. > Not sure what you mean here, can you explain what the configuration will specify? I was designing my EJB implementation so that it could store info for many lenya websites running inside a single application server (with apache mod proxy etc). It stores which directory the lenya publication is running from so users are unique across publications. In this way it didn't really need any configuration. > I'm currently trying to figure out how to move everything to the database, > including users, groups, roles and user rights and metadata per document > etc. My biggest trouble is to figure out the right places to hook my EJBs > to update this information (when a document is created for example, how to > create the initial metadata and rights for it in the DB). In my research I found that lenya has interfaces for just about everything, I then found which classes implemented these interfaces using File IO, and then I reimplemented those to talk to beans. I haven't looked into it too deeply, but I can see where that would be possible for some other parts of lenya, eg the scheduler (which has serious issues with garbage collection when running on windows). I'm not sure if moving the metadata into a database would be that useful, some of the metadata should be available for the xslt to extra and stick into the header tag of the output html. I think it's a really sticky area, when do you leave things in files and when do you put them in a database? You don't want to over-complicate lenya by moving too much into a database as I think lenya's simplicity (in the rendering pipeline anyway) is one of its advantages. Michael
ejb3.tar.gz
Description: application/tgz
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
