I guess jBPM 3 support also includes jBPM 4 ?

And I think Excel (and maybe PDF) support is a lot more important than the JMS bridge and GWT. I can't remember of any project without the need for at least a basic Excel export functionality.

I agree with William. I would like to see PDF/Excel and Mail before jBPM3, JMS and GWT.

Hopefully in the first release.

I'll see if the Excel module priority could be escalated ;-) Needs the new, improved Document(Store/Servlet) first, though.

I concur with the above, Excel and PDF are absolutely vital. We won't be able to upgrade our projects to Seam 3 without those. Frankly, they are some of the most useful features of Seam.

Seam2 application should wait until christmas before adopting Seam3. This means that a Seam2 app can't run on a JEE6 container before 2011.
Really we can't have backwards compatibility before that date?
And will Seam2 support be emulated throught a CDI extension or native engine?

Seam 2 stuff will most likely be done through an extension.

What prevents a Seam 2 from running on a Java EE 6 (please don't use JEE or Bill Shannon will be upset) ;-) server if the deployers are ported?

What about inclusion/exclusion of hot redeployment tool/feature (e.g. fakereplace or JRebel)? And what about Seam special classloader, will that be improved and/or included in Seam 3?

I want Seam 3 to provide hotdeploy, Excel, Mail and PDF-support before I upgrade my projects for Java EE 6.

I want Seam 3 to provide Spring Integration

Seam PDF, excel, mail support, as mentionned in the previous comments, should be included in first release of Seam 3. Definetely, the Seam features we are using the most.

Backwards comptability with Seam 2 should be pushed forward too.

Hot deployment feature included would be a nice addition.

Agree. PDF and excel support is more important. Import/export files too. How about seam-gen imporvement (my favorite one :D ) ? Oh, and my experience when using seam PDF is hard to generate complex PDF, especially if you deal with margin, padding etc, or want to fix the content with the templated paper.

By the way, if seam excel export is great, how if PDF support replaced by jasper/birt support?

Nicklas Karlsson wrote on Apr 22, 2010 21:25:
What prevents a Seam 2 from running on a Java EE 6 (please don't use JEE or Bill Shannon will be upset) ;-) server if the deployers are ported?

I tried on GFV3 and found an unsolveable conflic: Seam2 uses an Hibernate Validator that can't be bundled in a container providing JPA 2.0 and hibernate 3.5.

But if someone was successful deploying a Seam 2 application in newest Glassfish, please tell me something ;).

Hi,

for my projects - Excel, RTF, and PDF are really essential. I would really appreciate the priorities for these feature would become high enough!

Regards Jan

Alberto Gori wrote on Apr 22, 2010 21:00:
Seam2 application should wait until christmas before adopting Seam3. This means that a Seam2 app can't run on a JEE6 container before 2011.
Really we can't have backwards compatibility before that date?
And will Seam2 support be emulated throught a CDI extension or native engine?

We are looking at emulating the Seam 2 engine running on top of CDI. To get this going sooner I suggest making a start on a prototype - you can email the dev list or chat to us on IRC for hints :-)

Alberto Gori wrote on Apr 23, 2010 09:17:

Nicklas Karlsson wrote on Apr 22, 2010 21:25:
What prevents a Seam 2 from running on a Java EE 6 (please don't use JEE or Bill Shannon will be upset) ;-) server if the deployers are ported?

I tried on GFV3 and found an unsolveable conflic: Seam2 uses an Hibernate Validator that can't be bundled in a container providing JPA 2.0 and hibernate 3.5. But if someone was successful deploying a Seam 2 application in newest Glassfish, please tell me something ;).

You need to upgrade 2 to Hibernate Validator 4, and use the legacy module IIRC. I suspect this version should be compatible with newer Hibernate too.

Arbi Sookazian wrote on Apr 22, 2010 21:35:
What about inclusion/exclusion of hot redeployment tool/feature (e.g. fakereplace or JRebel)? And what about Seam special classloader, will that be improved and/or included in Seam 3?

Good point. This will be provided as part of Weld (not Seam), as it's something to be done at the low level. I definitely want to get this functionality in place before we release Seam 3!

Thanks for all the feedback on the Excel/PDF modules. We should be able to get these moved up the priority scale (the migration is quite straightforward) - any volunteers to help out?

But if someone was successful deploying a Seam 2 application in newest Glassfish, please tell me something ;).

I have Seam2 application run successfully on Glassfish v3 but only in JSF 1.2 mode. All Hibernate 3.4 libraries were copied to WEB-INF/lib and I forced Glassfish classloader to prefer war libraries first (

<class-loader delegate="false" />

However we still stick on GF v2.1 because there is no advantages to use JSF 1.2 in Java EE6 environment. Hope Seam 2.2.1 will properly support JSF2...

From my position instead - Support for Errai/GWT, i'd prefer Spring integration and Reporting. And maybe than postpone candidate release. In either case everyone will get the possibility to touch every component on the way like those two what we have now - am i right ? :)

1 for Spring Integration.

Java EE 6 looks great and we are really considering moving our (legacy) platform from Spring to Weld. One key point is the integration of the new code base with the old one (that will not be migrated any time soon) and would be great having Spring Integration to help manage this.

Pete Muir wrote on Apr 23, 2010 13:43:
Thanks for all the feedback on the Excel/PDF modules. We should be able to get these moved up the priority scale (the migration is quite straightforward) - any volunteers to help out?

How would one go about this, out of curiosity? Download the source, start making changes and sending in patches?

Drew wrote on Apr 23, 2010 20:42:
How would one go about this, out of curiosity? Download the source, start making changes and sending in patches?

Well step 1 is getting the modules migrated to Seam 3 and that is not that compilicated since they don't interact with Seam/CDI that heavily. This step is more hindered by the how can we make headless JSF rendering useful in Seam 3 and how should the content be delivered in Seam 3 problems and not by lack of workforce and is probably best handled by the module leads.

When the migration is done, however, we will certainly accept help. Ask around for suitable JIRAs to sink your teeth into or provide your own suggestions and we'll tell you where to start looking. Patches will then we accepted/reviewed/applied by the module leads until a certain point where we see that you know your ways around (or get tired) and just give you commit access ;-)

Pretty much normal open source project procedures, in other words.

xsalefter wrote on Apr 23, 2010 09:01:
Agree. PDF and excel support is more important. Import/export files too.

Import should be pretty trivial. We could have a component like

  @Inject ExcelImport excelImport;

  byte[] excelData;

  List<Float> salaries = excelImport.import(excelData).getWorkSheet("employees").getColumn(5);

which would just be a thin wrapper around jexcelapi

xhtml rendering will be pretty much the same as in Seam 2

dataTable converting will probably need some sort of intermediate metadata format so that we can have features from RichFaces and ICEfaces etc that go beyond the JSF datatable...

I don't see any request for Seam security. Some applications might not have excel/pdf export, but, in my opinion, all applications need a login/logout page and some basic security stuff, right? So my vote is Seam Security. If that security thing is very easy to implemented, could anybody tell me how (or give me a link to a tutorial)? Thanks.

Thai Dang Vu wrote on Apr 26, 2010 18:08:
I don't see any request for Seam security. Some applications might not have excel/pdf export, but, in my opinion, all applications need a login/logout page and some basic security stuff, right? So my vote is Seam Security. If that security thing is very easy to implemented, could anybody tell me how (or give me a link to a tutorial)? Thanks.

The security module is already in so it doesn't need requests ;-) Check the module link in the menu.

I vote for security and more JSF 2 support.

Persistence context management is trivial enough to do using producers/disposers in CDI so I would peg it as lower priority, however if it goes hand in hand with Transaction management then it should be higher.

I personally think the JMS event bridge is a very cool concept, if I understand correctly (remote events!). I definitely have a system which could be overhauled to use that, but I know it's probably not needed by the majority of apps so my vote is for low priority on this item.