hi L3 and john. I was thinking about the persistence.xml. Would using piping make sense to read/parse the fields from the persistence.xml and then pass them to GenerateEntities? so "read-persistence | generate-entities" ? ...I'm not sure if a plugin can read a file, but if it could, a little file-reader/parser might work? On Fri, 2011-04-15 at 12:04 -0400, Lincoln Baxter, III wrote:

All of the data you require about persistence.xml should be available from the PersistenceFacet On Fri, Apr 15, 2011 at 3:14 PM, Lincoln Baxter, III < lincolnbaxter(a)gmail.com&gt; wrote: -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

In theory, it should be possible to gain access to the AppServer JNDI connections by: - Use Forge itself to inspect persistence.xml - If it detects JNDI connection settings, generate an EE webapp with the persistence.xml and hibernate-tools embedded inside. - Deploy the webapp, which then generates the entities for the project. - Undeploy and destroy the temp project. Paul Bakker is using a similar technique to generate deployments using Arquillian: https://issues.jboss.org/browse/SEAMFORGE-109 ~Lincoln On Sat, Apr 16, 2011 at 2:48 AM, Max Rydahl Andersen < max.andersen(a)redhat.com&gt; wrote: -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

If persistence.xml only has a JNDI connection string, then you'll need to access that connection in order to connect to the database. Over-engineered? possibly. Alternatives to connecting w/JNDI? And what if your code is not compilable ? Your code is never deployed to the appserver. Only Forge-generated code would ever be deployed in this manner. ~Lincoln On Sat, Apr 16, 2011 at 1:18 PM, Max Andersen <manderse(a)redhat.com&gt; wrote: > Why would you want to require a running and fully confugured Appserver for > doing reverse engineering ? > Sounds like a very overengineered approach ? > And what if your code is not compilable ? > /max (sent from my phone) > On 16/04/2011, at 16.24, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com> wrote: > In theory, it should be possible to gain access to the AppServer JNDI > connections by: > - Use Forge itself to inspect persistence.xml > - If it detects JNDI connection settings, generate an EE webapp with > the persistence.xml and hibernate-tools embedded inside. > - Deploy the webapp, which then generates the entities for the project. > - Undeploy and destroy the temp project. > Paul Bakker is using a similar technique to generate deployments using > Arquillian: > <https://issues.jboss.org/browse/SEAMFORGE-109> https://issues.jboss.org/browse/SEAMFORGE-109 > ~Lincoln > On Sat, Apr 16, 2011 at 2:48 AM, Max Rydahl Andersen <&lt;max.andersen(a)redhat.com> max.andersen(a)redhat.com&gt; wrote: >> The persistence.xml just needs to be on the classpath at >> META-INF/persistence.xml as defined by the spec. >> (assuming you use jpaconfiguration) >>> But how often will a persistence.xml actually have the database connection >> info ? >>> if it is the persistence.xml used for deploying then it will contain the >> datasource name and >> nothing else aka. not enough info for hibernate tools nor hibernate it >> self to connect "outside" the server. >>> This is why in hibernate tools (both ant and eclipse version) we allow you >> to specify a properties file >> to use that will override anything found in persistence.xml on the >> classpath/default hibernate configuration semantics. >>> Until Forge it self gets a notion of database connection info I would >> suggest using this separate properties file >> for development connection info would be the simplest/easiest approach ? >> (we even have a "standard" name for >> it with default content to get the best non-invasive behavior) >>> here is what seam 2 projects made by seamgen and/or jboss tools looks >> like: >> #File used by hibernate tools to override <datasource> and other container >> specific settings in persistence.xml >> hibernate.connection.password= >> hibernate.connection.username=sa >> hibernate.connection.driver_class=org.hsqldb.jdbcDriver >> hibernate.dialect=org.hibernate.dialect.HSQLDialect >> hibernate.connection.url=jdbc:hsqldb:. >>>> hibernate.connection.provider_class=org.hibernate.connection.DriverManagerConnectionProvider >> hibernate.datasource= >> hibernate.transaction.manager_lookup_class= >>> The default (bad?) name is hibernate-console.properties. >>> Notice, the last three elements would probably be better off being >> defaulted in forge plugin to ensure >> hibernate won't start doing any of its JEE integration code just because >> you have a peristence.xml with >> datasource and jta tx info in it. >>> /max >>> On Apr 15, 2011, at 18:55, brian wrote: >>>>> >> > hi L3 and john. >> >> > I was thinking about the persistence.xml. Would using piping make sense >> > to read/parse the fields from the persistence.xml and then pass them to >> > GenerateEntities? >> >> > so "read-persistence | generate-entities" ? >> >> > ...I'm not sure if a plugin can read a file, but if it could, a little >> > file-reader/parser might work? >> >> >> > On Fri, 2011-04-15 at 12:04 -0400, Lincoln Baxter, III wrote: >> >> Hi John! >> >>> >> Thank you for your interest! I think it's fair to say that we are >> >> "close" to having a fully-functional database reverse-engineering >> >> plugin, but we are not there yet. Brian (ccd) has been doing some work >> >> recently (when he has time) to get Max Andersen's prototype up and >> >> running. The prototype is here, but has a few shortcomings: >> >>> >> <https://github.com/forge/plugin-hibernate-tools>> https://github.com/forge/plugin-hibernate-tools >> >> 1. Connection settings are hardcoded >> >> 2. JDBC drivers are not included with the plugin >> >> 3. Does not take persistence.xml into account, if it exists >> >> In short, it works, but is not usable yet; however, these are all >> >> things that can be worked on if you are interested! And I would be >> >> more than happy to help you get together with Brian and get two brains >> >> working on this! Would you be intersted in that? >> >>> >> No matter your level of commitment, I would recommend joining the dev >> >> and users lists: >> >> * <https://lists.jboss.org/mailman/listinfo/forge-dev>> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> * <https://lists.jboss.org/mailman/listinfo/forge-users>> https://lists.jboss.org/mailman/listinfo/forge-users >> >> Just let me know and I'll get you all the info that you'll need :) >> >> ~Lincoln >> >>> >> On Thu, Mar 17, 2011 at 8:57 PM, John du Clos < <duclosjj(a)yahoo.com>> duclosjj(a)yahoo.com>> >> wrote: >> >> Hi Lincoln- >> >>> >> I was chatting with Dan Allen and he mentioned you are working >> >> on Forge and specifically the reverse engineering feature from >> >> the database. I wanted to reach out to you to see if you have >> >> any early versions you need testers to help you verify this >> >> feature. >> >>> >> I look forward to hearing from you! >> >> John >> >>> >> --- On Wed, 3/16/11, Dan Allen < <dan.j.allen(a)gmail.com>> dan.j.allen(a)gmail.com&gt; wrote: >> >>> >>> >> From: Dan Allen < <dan.j.allen(a)gmail.com>> dan.j.allen(a)gmail.com>> >> Subject: Re: Mojavelinux.com Feedback: seam-gen and >> >> cdi/weld >> >> To: <duclosjj@yahoo.com&gt;duclosjj(a)yahoo.com >> >> Date: Wednesday, March 16, 2011, 9:33 PM >> >>> >> Hey John, >> >> Thanks for reading the book. I'm glad it helped you >> >> along. I know about those painful days of J2EE you are >> >> talking about. >> >> The best way to get started atm is using the Maven >> >> archetype. >> >> <http://tinyurl.com/gojavaee>> http://tinyurl.com/gojavaee >> >> That gives you a starter project. We don't yet have >> >> the reverse engineering yet for this environment. That >> >> what Forge will offer soon. Check out the issue >> >> tracker or mailing list for updates. >> >> Hope that gets you started. Cheers, >> >> - Dan Allen >> >> Sent from my Android-powered phone: >> >> An open platform for carriers, consumers and >> >> developers >> >> On Mar 16, 2011 9:04 PM, < <duclosjj(a)yahoo.com>> duclosjj(a)yahoo.com&gt; wrote: >> >>> Submitted by: John duClos < <duclosjj@yahoo.com&gt;duclosjj(a)yahoo.com>> on >> >> Wednesday, March 16th, 2011 @ 9:04:25 pm (-0400) >> >>>> >>> Online Form Fields >> >>> ------------------ >> >>>> >>> Url: >> >>>> >>>> >>> Message: >> >>> Dan- >> >>>> >>> I purchased your Seam book when it was published and >> >> am a supporter of >> >>> the Seam framework since I lived the challenging >> >> days of early J2EE >> >>> development. >> >>>> >>> I work with database centric solutions and seam-gen >> >> allowed me to >> >>> develop solutions in record time by getting my >> >> project started very >> >>> quickly. I'd like to start implementing JEE 6/CDI >> >> with JBoss AS 6, but >> >>> I can't seem to find a way to issue the seam-gen >> >> command. >> >>>> >>> I looked at Forge but that is not where seam-gem >> >> was. Do you know of a >> >>> valid seam-gen solution for JEE 6/CDI based projects >> >> (Seam 3). >> >>>> >>> Thanks, >> >>> John >> >>>> >>> Client Variables >> >>> ---------------- >> >>>> >>> HTTP_USER_AGENT: >> >>> Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; >> >> Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR >> >> 3.5.21022; .NET CLR 3.5.30729; MDDS; .NET CLR >> >> 3.0.30729; MS-RTC LM 8; AskTB5.4) >> >>>> >>>> >>> >>> >>> >>> >> -- >> >> Lincoln Baxter, III >> >> <http://ocpsoft.com>http://ocpsoft.com >> >> <http://scrumshark.com>http://scrumshark.com >> >> "Keep it Simple" >> >> >> > _______________________________________________ >> > forge-dev mailing list >> > <forge-dev@lists.jboss.org&gt;forge-dev(a)lists.jboss.org >> > <https://lists.jboss.org/mailman/listinfo/forge-dev>> https://lists.jboss.org/mailman/listinfo/forge-dev >>> /max >> <http://about.me/maxandersen>http://about.me/maxandersen >>>>> -- > Lincoln Baxter, III > <http://ocpsoft.com>http://ocpsoft.com > <http://scrumshark.com>http://scrumshark.com > "Keep it Simple" -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"