From jdavault at redhat.com Wed Mar 12 13:08:38 2014 From: jdavault at redhat.com (jdavault at redhat.com) Date: Wed, 12 Mar 2014 10:08:38 -0700 Subject: [seam-dev] Seam Migration Questions Message-ID: <53209496.5050701@redhat.com> Hello Seam-Forums, Seam-Issues, and Seam-Dev, I am working with a customer who is migrating from Seam 2.2 to Seam 3, JSF 1.2 to 2.0, RichFaces 3.3 to 4.0, and also will be using CDI (Weld) moving forward. I haven't found any specific migration documents that directly address the Seam migration, but I have found a lot of discussions about this migration being a difficult one and comments that a migration strategy document needs to exist for this. Here are the important questions I am looking to answer for our customer that I cannot currently answer myself: 1) If you navigate to this web URL: http://seamframework.org/Seam3/Solder, you'll notice that Red Hat states active development has stopped for this project and been moved to Apache Deltaspike. The customer is concerned that if they upgrade to Seam 3/Solder now, they will have to upgrade again shortly thereafter to something else due to this change. Can we guarantee that we will support their upgrade moving forward? If not, what is or what will be the alternative technologies in its stead? 2) The customer makes extensive use of Seam 2 remoting for their banking security application. Is there an equivalent in CDI (Weld) that will allow them to continue using remoting? If not, what alternatives do we offer in it's place? 3) The customer has noted that Seam3 doesn't make use of components.xml which they currently use in Seam2. Where does this code get ported to in Seam3? 4) The customer currently uses Seam-managed Hibernate Sessions: he guesses they are not supported in CDI and wishes to know what is the best way to go moving forward? For example, something that is more conforming to JPA2 was mentioned. I have snapshots of the current configurations for components.xml, pages.xml, and the current logging configuration. Please let me know if providing any of these would be useful to help answer the questions. Any help is appreciated. Regards, Jon DaVault Consultant 206.369.2304 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20140312/51a5fa37/attachment.html From jdavault at redhat.com Wed Mar 12 22:00:08 2014 From: jdavault at redhat.com (Jon Da Vault) Date: Wed, 12 Mar 2014 22:00:08 -0400 (EDT) Subject: [seam-dev] Seam 2.2 migration to Seam 3 In-Reply-To: <973408302.5601069.1394674894957.JavaMail.zimbra@redhat.com> Message-ID: <1555218976.5602434.1394676008475.JavaMail.zimbra@redhat.com> Hello list members, Earlier today I posed a couple questions that did receive one response. The response has spawned a few more of my own questions and I have included the response in my conversation/further questions below. The original question is in red, and the response is also called-out and in red. The continuation question is in green. There are a couple new questions posed after the continued (green and red) question portion. Thanks for your help! 1) The customer makes extensive use of Seam 2 remoting for their banking security application. Is there an equivalent in CDI (Weld) that will allow them to continue using remoting? If not, what alternatives do we offer in it's place? Mailing List Response: You can take a look at Errai, or simply use JAX-RS. Q: Seam 3 appears to have it's own remoting functionality available much like Seam 2. URL: http://seamframework.org/Seam3/RemotingModule As you'll note, there is a large disclaimer stating that active development for the project is halted and that the project is also deprecated. However, I feel that if the customer moves from Seam 2 remoting to Seam 3 remoting they will incur a smaller amount of work than if they were to consider adopting a new technology such as Errai or JAX-RS as you've suggested as best cases. While they are interested in adopting a better or more appropriate technology for their application, they still want to rapidly make the move to Seam 3/Solder/CDI/Weld in the meantime and I think this sets them up nicely for migrating the rest of the technologies over. What the customer is extremely interested in knowing is if these technologies now sitting as-is (3.1 Snapshot I believe) can be said to be categorically stable and functional currently for this sort of temporary use case with full knowledge they aren't supported moving forward? If so, are there any migration documents available? If no migration documents are available, do you have anywhere you can point me in order to get a head start on creating one myself for our client? Do you agree with this short-term-win approach? 2) The customer currently uses Seam-managed Hibernate Sessions: he guesses they are not supported in CDI and wishes to know what is the best way to go moving forward? For example, something that is more conforming to JPA2 was mentioned. Mailing List Response : Moving to a more standard JPA environment would be best Q: Here again, there seems to be a Seam 3 persistence module available as before and I wonder if the customer could utilize this in the short term while preparing for an adoption of a new persistence technology lsuch as, say, just Hibernate? The URL I'm referencing is: http://seamframework.org/Seam3/PersistenceModule 3) Given that components.xml is a large part of their implementation in Seam2, how can we break it up to conform with CDI/Weld/Seam3? Mailing List Response: All depends on what is in their components.xml, there's no simple answer here. Q: I agree with this response. I do, however, have a snapshot of the components.xml and I know that it needs to be broken up into a few different places. Does anyone have experience in doing this? Please reply and I will send you the components.xml document if you'd like to assist in helping me to map the pieces to the appropriate places. If there's sufficient documentation online, as always, please direct me to it. Lastly, if you're not tired of reading my questions yet there are a couple new ones below: First new question: "There used to be a class in Seam 2 called org.jboss.seam.faces.Redirect. We use this a few times to force a redirect in different cases. for example: 1. When user enters a valid URL but is not yet logged on; view is captured and user returned to it after successful logon. 2. When we detect that a user is no longer logged on; we redirect to a ?Logon expired page? So, the question is: What do I replace this with? I looked in Seam 3 but it doesn?t appear to have been implemented (at least not in the seam-faces jar)." Second new question: Regarding their current usage of Seam 2 "We use the class org.jboss.seam.async.Dispatcher to create long running threads in the container. Can you tell me what I should use instead?" Again, if there are any documents or web sites that deal with these questions specifically regarding migration I would greatly appreciate having them sent to me. Thank You, Jon Da Vault Consultant 206.369.2304 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20140312/6e1214ec/attachment-0001.html From lincolnbaxter at gmail.com Wed Mar 12 23:05:49 2014 From: lincolnbaxter at gmail.com (Lincoln Baxter, III) Date: Wed, 12 Mar 2014 23:05:49 -0400 Subject: [seam-dev] Seam 2.2 migration to Seam 3 In-Reply-To: <1555218976.5602434.1394676008475.JavaMail.zimbra@redhat.com> References: <973408302.5601069.1394674894957.JavaMail.zimbra@redhat.com> <1555218976.5602434.1394676008475.JavaMail.zimbra@redhat.com> Message-ID: Hi there, I have some (probably not very positive) answers, but here goes. In general Seam 3 is "as is" and will not be patched, improved, or otherwise changed unless the client (or another community member) wishes to do so. On top of that, patches submitted will probably not be merged or released since the last release was over a year ago now at this point if I am not mistaken. You'd have to find a committer who is willing to dredge this up again :) I'm not saying it's impossible, but there will be some pretty serious barriers to getting improvements made. Aside from that, I believe Seam 2 is still a supported Red Hat project (Seam 3 never made it that far.) 1) You can try your luck with upgrading to Seam 3, but know that would be upgrading your customer to a project that is officially cancelled and will not be continued. There are still quite a few known bugs that were never fixed. Errai is still actively developed and has a good community. JAX-RS is a standard, and will be around for a long time to come, so I would probably echo what was said on the list. That being said, there is good in Seam 3, and a lot of good work went into it, so if you are OK with the circumstances around this project, then I would say continue at your own risk, but you may find it works. 2) Look at the CDI conversation scope with JPA and an @PersistenceContext(type=EXTENDED) context. This is effectively the same thing as a Seam-Managed Hibernate Session, except it will not be closed and re-opened before/after RESTORE_VIEW phase. However, you can use EJB @TransactionAttribute methods to do your work in a transaction where required. (See this article for more info on that: http://ocpsoft.org/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/(The article is about Spring, but many concepts are shared with Seam 2.) 3) There isn't really a good XML configuration mechanism in Java EE (other than the basic web.xml, persistence.xml, ejb-jar.xml, etc...) So I don't really have a good recommendation for you here. *New questions:* If you are looking for functionality to control Routing and Navigation, check out http://ocpsoft.org/rewrite/ (with the rewrite-integration-faces module) or http://ocpsoft.org/prettyfaces/, which includes both of the former - either of these projects will give you access to several utility classes such as the "Navigate" class, and other things, but all said, JSF2 has much better support for navigation than JSF 1.2 did (which is what I guess you are using if the customer is still on JSF 2.2) Here is an example of the user logged being redirected if not logged in: http://ocpsoft.org/rewrite/examples/#section-4 I hope this is helpful, but I do wish I had better news. I would really consider Errai or just plain Java EE with JAX-RS. I can't really recommend that anyone start using Seam 3 now, several years after its demise. ~Lincoln On Wed, Mar 12, 2014 at 10:00 PM, Jon Da Vault wrote: > Hello list members, > > Earlier today I posed a couple questions that did receive one response. > The response has spawned a few more of my own questions and I have included > the response in my conversation/further questions below. The original > question is in red, and the response is also called-out and in red. The > continuation question is in green. There are a couple new questions posed > after the continued (green and red) question portion. Thanks for your help! > > 1) The customer makes extensive use of Seam 2 remoting for their banking > security application. Is there an equivalent in CDI (Weld) that will allow > them to continue using remoting? If not, what alternatives do we offer in > it's place? > Mailing List Response: You can take a look at Errai, or simply use JAX-RS. > Q: Seam 3 appears to have it's own remoting functionality available much > like Seam 2. URL: http://seamframework.org/Seam3/RemotingModule > As you'll note, there is a large disclaimer stating that active > development for the project is halted and that the project is also > deprecated. However, I feel that if the customer moves from Seam 2 remoting > to Seam 3 remoting they will incur a smaller amount of work than if they > were to consider adopting a new technology such as Errai or JAX-RS as > you've suggested as best cases. While they are interested in adopting a > better or more appropriate technology for their application, they still > want to rapidly make the move to Seam 3/Solder/CDI/Weld in the meantime and > I think this sets them up nicely for migrating the rest of the technologies > over. What the customer is extremely interested in knowing is if these > technologies now sitting as-is (3.1 Snapshot I believe) can be said to be > categorically stable and functional currently for this sort of temporary > use case with full knowledge they aren't supported moving forward? If so, > are there any migration documents available? If no migration documents are > available, do you have anywhere you can point me in order to get a head > start on creating one myself for our client? Do you agree with this > short-term-win approach? > > 2) The customer currently uses Seam-managed Hibernate Sessions: he guesses > they are not supported in CDI and wishes to know what is the best way to go > moving forward? For example, something that is more conforming to JPA2 was > mentioned. > Mailing List Response: Moving to a more standard JPA environment would be > best > Q: Here again, there seems to be a Seam 3 persistence module available as > before and I wonder if the customer could utilize this in the short term > while preparing for an adoption of a new persistence technology lsuch as, > say, just Hibernate? The URL I'm referencing is: > http://seamframework.org/Seam3/PersistenceModule > > 3) Given that components.xml is a large part of their implementation in > Seam2, how can we break it up to conform with CDI/Weld/Seam3? > Mailing List Response: All depends on what is in their components.xml, > there's no simple answer here. > Q: I agree with this response. I do, however, have a snapshot of the > components.xml and I know that it needs to be broken up into a few > different places. Does anyone have experience in doing this? Please reply > and I will send you the components.xml document if you'd like to assist in > helping me to map the pieces to the appropriate places. If there's > sufficient documentation online, as always, please direct me to it. > > > Lastly, if you're not tired of reading my questions yet there are a couple > new ones below: > > *First new question:* "There used to be a class in Seam 2 called > org.jboss.seam.faces.Redirect. We use this a few times to force a > redirect in different cases. > > for example: > > 1. When user enters a valid URL but is not yet logged on; view is > captured and user returned to it after successful logon. > > 2. When we detect that a user is no longer logged on; we redirect to > a "Logon expired page" > > So, the question is: What do I replace this with? I looked in Seam 3 > but it doesn't appear to have been implemented (at least not in the > seam-faces jar)." > > *Second new question:* Regarding their current usage of Seam 2 "We use > the class org.jboss.seam.async.Dispatcher to create long running threads in > the container. Can you tell me what I should use instead?" > > Again, if there are any documents or web sites that deal with these > questions specifically regarding migration I would greatly appreciate > having them sent to me. > > Thank You, > > Jon Da Vault > Consultant > 206.369.2304 > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20140312/416538cc/attachment.html From mnovotny at redhat.com Thu Mar 13 05:58:26 2014 From: mnovotny at redhat.com (Marek Novotny) Date: Thu, 13 Mar 2014 10:58:26 +0100 Subject: [seam-dev] Seam 2.2 migration to Seam 3 In-Reply-To: <1555218976.5602434.1394676008475.JavaMail.zimbra@redhat.com> References: <1555218976.5602434.1394676008475.JavaMail.zimbra@redhat.com> Message-ID: <53218142.8070907@redhat.com> Jon, If you need any Redhat official answers use wfk-pm-list or jboss-migration at redhat.com Now to your questions in frame of Seam/Seam3 projects, my response is inline On 03/13/2014 03:00 AM, Jon Da Vault wrote: > Hello list members, > > Earlier today I posed a couple questions that did receive one > response. The response has spawned a few more of my own questions and > I have included the response in my conversation/further questions > below. The original question is in red, and the response is also > called-out and in red. The continuation question is in green. There > are a couple new questions posed after the continued (green and red) > question portion. Thanks for your help! > > 1) The customer makes extensive use of Seam 2 remoting for their > banking security application. Is there an equivalent in CDI (Weld) > that will allow them to continue using remoting? If not, what > alternatives do we offer in it's place? You mean Seam remoting, right? Lincoln's answer is correct for moving to Java EE 6 standards. The question is what the customer prefers or needs, big migration like develop it from the ground as it probably ends due some differences between Seam2 and Seam3/Java EE6 standards. Or use Seam 2.3 with updates to Java EE 6 integration. And please don't advice them to use Seam 3 if you don't want to be your own supporter. > Mailing List Response: You can take a look at Errai, or simply use JAX-RS. > Q: Seam 3 appears to have it's own remoting functionality available > much like Seam 2. URL: http://seamframework.org/Seam3/RemotingModule > As you'll note, there is a large disclaimer stating that active > development for the project is halted and that the project is also > deprecated. However, I feel that if the customer moves from Seam 2 > remoting to Seam 3 remoting they will incur a smaller amount of work > than if they were to consider adopting a new technology such as Errai > or JAX-RS as you've suggested as best cases. While they are interested > in adopting a better or more appropriate technology for their > application, they still want to rapidly make the move to Seam > 3/Solder/CDI/Weld in the meantime and I think this sets them up nicely > for migrating the rest of the technologies over. What the customer is > extremely interested in knowing is if these technologies now sitting > as-is (3.1 Snapshot I believe) can be said to be categorically stable > and functional currently for this sort of temporary use case with full > knowledge they aren't supported moving forward? If so, are there any > migration documents available? If no migration documents are > available, do you have anywhere you can point me in order to get a > head start on creating one myself for our client? Do you agree with > this short-term-win approach? Migration documents in JBoss Developer project http://www.jboss.org/jdf/migrations/get-started/ Some other inspiration see http://www.jboss.org/jdf/examples/get-started/ > > 2) The customer currently uses Seam-managed Hibernate Sessions: he > guesses they are not supported in CDI and wishes to know what is the > best way to go moving forward? For example, something that is more > conforming to JPA2 was mentioned. > Mailing List Response: Moving to a more standard JPA environment would > be best > Q: Here again, there seems to be a Seam 3 persistence module available > as before and I wonder if the customer could utilize this in the short > term while preparing for an adoption of a new persistence technology > lsuch as, say, just Hibernate? The URL I'm referencing is: > http://seamframework.org/Seam3/PersistenceModule Move to JPA2. If you need extended Deltaspike persistence use Deltaspike on CDI - http://deltaspike.apache.org/data.html > > 3) Given that components.xml is a large part of their implementation > in Seam2, how can we break it up to conform with CDI/Weld/Seam3? > Mailing List Response: All depends on what is in their components.xml, > there's no simple answer here. And that is simply true, you need to evalute the features you need or you have to as a must. > Q: I agree with this response. I do, however, have a snapshot of the > components.xml and I know that it needs to be broken up into a few > different places. Does anyone have experience in doing this? Please > reply and I will send you the components.xml document if you'd like to > assist in helping me to map the pieces to the appropriate places. If > there's sufficient documentation online, as always, please direct me > to it. Use jboss-migration at redhat.com, that is specifically for helping with migrations of existing application supported by Redhat. > > > Lastly, if you're not tired of reading my questions yet there are a > couple new ones below: > > *First new question:* "There used to be a class in Seam 2 called > org.jboss.seam.faces.Redirect. We use this a few times to force a > redirect in different cases. > > for example: > > 1. When user enters a valid URL but is not yet logged on; view > is captured and user returned to it after successful logon. > > 2. When we detect that a user is no longer logged on; we > redirect to a "Logon expired page" > > So, the question is: What do I replace this with? I looked in Seam > 3 but it doesn't appear to have been implemented (at least not in the > seam-faces jar)." JSF 2 has got navigation rules and redirection. You can use it instead of pages.xml in Seam 2. > > *Second new question:* Regarding their current usage of Seam 2 "We use > the class org.jboss.seam.async.Dispatcher to create long running > threads in the container. Can you tell me what I should use instead?" TimerService in Java EE 6 is enhanced and is basically replacement for Seam 2 Asynchronous. http://docs.oracle.com/javaee/6/tutorial/doc/bnboy.html http://docs.oracle.com/javaee/6/api/javax/ejb/TimerService.html > > Again, if there are any documents or web sites that deal with these > questions specifically regarding migration I would greatly appreciate > having them sent to me. > > Thank You, > > Jon Da Vault > Consultant > 206.369.2304 > > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev -- Marek Novotny -- WFK and Seam Product Lead Red Hat Czech s.r.o. Purkynova 99 612 45 Brno -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20140313/c0c3a52c/attachment-0001.html From denis.forveille at gmail.com Thu Mar 13 12:22:29 2014 From: denis.forveille at gmail.com (Denis Forveille) Date: Thu, 13 Mar 2014 12:22:29 -0400 Subject: [seam-dev] Seam 2.2 migration to Seam 3 In-Reply-To: <1555218976.5602434.1394676008475.JavaMail.zimbra@redhat.com> References: <973408302.5601069.1394674894957.JavaMail.zimbra@redhat.com> <1555218976.5602434.1394676008475.JavaMail.zimbra@redhat.com> Message-ID: Hi, We have done the (almost) same move for our many Seamv2/JSFv1.2/RFv3.3/JPA-Hibenate-WebSphere v7.0 applications to CDIv1/JSF2.0/Primefacesv4/JPA-Hibenate-/WebSpherev8.5.5 and we faced the same questions you are asking As you probably already know, most of what makes Seam 2 so great is now part of CDI and JSF 2.0, but unfortunately not all. For the missing parts, Seam 3 was not an option (code being merged to DS) and we tried to "fill the gaps" with CODI (that is being merged into DS) and the still-in-development-DetaSpike project but, after many so-called "migration proof of concepts" we finally decided to just build our own "CDIUtils" library with the missing parts, with code borrowed from CODI, DS and omnifaces. DS is a great framework but it does not really fits with our needs (Do lots of thing we don't need and do other thing in a way we don't like, as the "Strong typed navigation model/paradigm) Our applications are all composed of many module: 1 JPA jar, 1 EJB module, a WAR (Contains no Java except Primefaces related artefacts) , a "UnitTest" jar and eventually a batch jar. The EJB at high level contains "Page Controllers (Mostly SFSB or POJOs)", "Managers (SLSB)", MDBs and Web Service endpoints (SLSB). Our CDIUtils lib is composed of 7 jars: - base jar with CDI components to manage property files, JSF Messages + AJAX-aware JSF 2.0 exception handler (thanks to omnifaces), Entity+Rollback CDI comp producers, JSF v2.0 locale, a CDI PageContext (=JSF ViewContext assignable to producer), super classes for Controlers, Managers, WebServices and batches and a few other goodies.. - batch: with classes to bootstrap weld-se and CDI alternatives to EntityManager and Rollback providers, and alternatives to non-se contexts (Request, Conversation..) - jpa: depends on hibernate with a dedicated DB2 Dialect - security: depend on Apache Shiro: Shiro-CDI integration that expose 2 interfaces to application : authentication adn registry management - pdf: depends on the FOSS version of iText, Cloned from the Seam 2 PDF facelets tags + a CDi component to render Facelets with PDF tags programatically - WebSphere: depends on WebSphere, with the Hibernate JTA provider and second level cache implementation - test: depends on junit and selenium with a CDIfied Junit4Runner and CDI alternatives to EntityManager and Rollback providers, and non-j2se contexts (Request, Conversation..) It seems to be a lot of code, but in reality it is not. It just exposed the missing artefacts that were in Seam 2, not in JSF 2.0 and CDI In a few words, we don't have any more a pages.xml nor components files and we do not depends on external CDI related libs : - Transactions are managed by the EJB Container itself - JPA/HIbernate session are managed by our EntityManager CDI producer + an @AroundInvoke annotated method in our Ctrl+Manager+MDB+batch superclass that attach the em at each EJB method call and so solve the (in-)famous "Hibernate lazy instantiation exception" solved by Seam 2 in its time - Seam 2 security is replaced by by Apache Shiro with a nice shiro.ini file that is similar to pages.xml for this - Seam 2 PDF is replaced by our own lib - thanks to JSF 2.0, navigation is done directly with the name of the page without teh need to pages.xml file - CDI basic conversation management is enough for us, so we use it. We had to replace Seam 2 outjection, it's just a different way on thinking on CDI.. - The EntityManager producer was a bit tricky to create because it must work in SFLB, SFSB, MDB, J2SE... and due to CDI contexts, but it now work great - We use weld for junit/batch even if WAS comes with a modified version of OWB because of some bugs in different interpretation of CDI - Moving from RichFaces to Primefaces was not so difficult and -this is our perception- easier to use I know this does not exactly answer your question but I thought that it may be intersting for you to share our experience how we are moving out from Seam 2 and I'm concisous that our situation may be different from other (Usage of EJB ..) If you need more details, I will be happy to share them. On some days I'm thinking about writing somewhere what we did to migrate and eventually share our "CDIUtils" source code (ie create an open source project) lib but I'm not sure that that code is "universal" enough for that Cheers Denis 2014-03-12 22:00 GMT-04:00 Jon Da Vault : > Hello list members, > > Earlier today I posed a couple questions that did receive one response. > The response has spawned a few more of my own questions and I have included > the response in my conversation/further questions below. The original > question is in red, and the response is also called-out and in red. The > continuation question is in green. There are a couple new questions posed > after the continued (green and red) question portion. Thanks for your help! > > 1) The customer makes extensive use of Seam 2 remoting for their banking > security application. Is there an equivalent in CDI (Weld) that will allow > them to continue using remoting? If not, what alternatives do we offer in > it's place? > Mailing List Response: You can take a look at Errai, or simply use JAX-RS. > Q: Seam 3 appears to have it's own remoting functionality available much > like Seam 2. URL: http://seamframework.org/Seam3/RemotingModule > As you'll note, there is a large disclaimer stating that active > development for the project is halted and that the project is also > deprecated. However, I feel that if the customer moves from Seam 2 remoting > to Seam 3 remoting they will incur a smaller amount of work than if they > were to consider adopting a new technology such as Errai or JAX-RS as > you've suggested as best cases. While they are interested in adopting a > better or more appropriate technology for their application, they still > want to rapidly make the move to Seam 3/Solder/CDI/Weld in the meantime and > I think this sets them up nicely for migrating the rest of the technologies > over. What the customer is extremely interested in knowing is if these > technologies now sitting as-is (3.1 Snapshot I believe) can be said to be > categorically stable and functional currently for this sort of temporary > use case with full knowledge they aren't supported moving forward? If so, > are there any migration documents available? If no migration documents are > available, do you have anywhere you can point me in order to get a head > start on creating one myself for our client? Do you agree with this > short-term-win approach? > > 2) The customer currently uses Seam-managed Hibernate Sessions: he guesses > they are not supported in CDI and wishes to know what is the best way to go > moving forward? For example, something that is more conforming to JPA2 was > mentioned. > Mailing List Response: Moving to a more standard JPA environment would be > best > Q: Here again, there seems to be a Seam 3 persistence module available as > before and I wonder if the customer could utilize this in the short term > while preparing for an adoption of a new persistence technology lsuch as, > say, just Hibernate? The URL I'm referencing is: > http://seamframework.org/Seam3/PersistenceModule > > 3) Given that components.xml is a large part of their implementation in > Seam2, how can we break it up to conform with CDI/Weld/Seam3? > Mailing List Response: All depends on what is in their components.xml, > there's no simple answer here. > Q: I agree with this response. I do, however, have a snapshot of the > components.xml and I know that it needs to be broken up into a few > different places. Does anyone have experience in doing this? Please reply > and I will send you the components.xml document if you'd like to assist in > helping me to map the pieces to the appropriate places. If there's > sufficient documentation online, as always, please direct me to it. > > > Lastly, if you're not tired of reading my questions yet there are a couple > new ones below: > > *First new question:* "There used to be a class in Seam 2 called > org.jboss.seam.faces.Redirect. We use this a few times to force a > redirect in different cases. > > for example: > > 1. When user enters a valid URL but is not yet logged on; view is > captured and user returned to it after successful logon. > > 2. When we detect that a user is no longer logged on; we redirect to > a "Logon expired page" > > So, the question is: What do I replace this with? I looked in Seam 3 > but it doesn't appear to have been implemented (at least not in the > seam-faces jar)." > > *Second new question:* Regarding their current usage of Seam 2 "We use > the class org.jboss.seam.async.Dispatcher to create long running threads in > the container. Can you tell me what I should use instead?" > > Again, if there are any documents or web sites that deal with these > questions specifically regarding migration I would greatly appreciate > having them sent to me. > > Thank You, > > Jon Da Vault > Consultant > 206.369.2304 > > > _______________________________________________ > seam-dev mailing list > seam-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20140313/8839e358/attachment.html