Problem rendering application migrated from EAP5.1 to AS7
by Sande Gilda
I am migrating an EAP5.1 application to AS7. It is using Seam 2.2 and
RichFaces 3.3.1. I have made the datasource changes. I have also made
the changes for the new modular class loader support. My server has all
the latest bug fixes to get past issues I've run into.
I am at the point where the server starts up successfully without errors
and my application deploys successfully, also without errors. However,
when hit the URL for my application in a browser, the JSF/xhtml tags do
not render. Only the html tags and plain text render on the page. When I
view source for the page, the tags are definitely there.
So, a partial section of the page source looks like this:
<p>Please login here</p>
<div class="dialog">
<h:panelGrid columns="2" rowClasses="prop" columnClasses="name,value">
<h:outputLabel for="username">Username</h:outputLabel>
<h:inputText id="username"
value="#{credentials.username}"/>
<h:outputLabel for="password">Password</h:outputLabel>
<h:inputSecret id="password"
value="#{credentials.password}"/>
<h:outputLabel for="rememberMe">Remember me</h:outputLabel>
<h:selectBooleanCheckbox id="rememberMe"
value="#{rememberMe.enabled}"/>
</h:panelGrid>
</div>
<p> <u>Users</u>
That part of the page renders like this:
Login
Please login here
Username Password Remember me
_Users_
I don't see any tag controls like input text, buttons, or other
controls. I tried upgrading to RichFaces 3.3.3 but it made no
difference. I also set the log level to DEBUG, but don't see any errors
in the server.log file.
Has anyone migrated a Seam 2.2 application successfully to AS7? I'm new
to Seam (and UI coding in general), so I'm looking for any pointers to
get around this issue.
Thanks,
Sande
12 years, 10 months
Re: [seam-dev] Removing the combined jar
by Ken Finnigan
+1 to the profile idea and +1 to removing combined jars, as I believe it
simplifies the artifacts being produced, especially in situations where a
module has multiple implementations and you don't necessarily want to bundle
them all together.
And we don't want to have different bundling techniques for modules that
multiple implementations and those that don't, too confusing.
>From my enterprise dev experience I can't recall a time when the number of
jars in an application became a concern, but I could have been lucky. I do
agree that when using Ant having multiple artifacts is a PITA, but those
using Ant know going in that dependency management with it is going to bring
its own kind of hell.
José, to your concern around needing to define multiple artifacts when using
Arquillian. From my interpretation of Dan's bundling idea I see that it can
be achieved in two ways:
1) Provide a set of commonly used Seam modules in a single jar
pre-packaged as suggested, ie. core, business, etc.
2) Provide a UI that allows a developer to pick and choose which modules
they want, then a background process is kicked off to actually shade all
those artifacts together into a single jar and the developer is notified
when that bundling is complete with a link to the download.
In either of the above situations you would be specifying the bundled jar as
a dependency for any Arquillian tests, thus reducing the number of
dependencies to be listed as most tests would probably touch on a Seam
module and Solder at a minimum, and possibly other modules as well.
Ken
On Fri, Jun 10, 2011 at 7:47 AM, José Rodolfo Carrijo de Freitas <
jose.freitas(a)softplan.com.br> wrote:
> +1 for profile jar Idea. -1 for removing combined jar.
>
> I agree with John and besides, there’re situations that is pretty useful,
> e.g. when using shrinkwap mavenresolver it’s easier having one combined jar
> (less code to write and keep)
>
>
>
> //war is a shrinkwrap web archive.
>
> war.addAsLibraries(DependencyResolvers.*use*(MavenDependencyResolver.*
> class*)
>
> .artifact(“org.jboss.seam.faces:seam-faces:3.1.0-SNAPSHOT”)
>
> .resolveAs(GenericArchive.*class*));
>
>
>
>
>
>
>
> Atenciosamente,
>
>
>
> José Rodolfo Carrijo de Freitas
> Analista de Sistemas
> Pesquisa e desenvolvimento
>
> Softplan/Poligraph
>
> + 55 48 3027-8000
>
> www.softplan.com.br
>
>
>
> *De:* seam-dev-bounces(a)lists.jboss.org [mailto:
> seam-dev-bounces(a)lists.jboss.org] *Em nome de *Dan Allen
> *Enviada em:* quinta-feira, 9 de junho de 2011 21:04
> *Para:* Jordan Ganoff
> *Cc:* seam-dev(a)lists.jboss.org
> *Assunto:* Re: [seam-dev] Removing the combined jar
>
>
>
> On Thu, Jun 9, 2011 at 20:00, Jordan Ganoff <jganoff(a)gmail.com> wrote:
>
> +1 for "profile" jars and removal of the combiner jar.
>
>
>
> I'd like to see a friendly user interface for choosing modules which would
> generate the required Maven/Gradle/Ivy dependency list you can copy/paste...
> that is of course if you're not using Forge. This would be hosted at the
> Seam University for example.
>
>
>
> That might be best for our new project site, which is in the ice box while
> we fight off some oppression. "Help! I'm being oppressed!"
>
>
>
> We could do this with a little jQuery magic :)
>
>
>
> -Dan
>
>
>
> --
>
> Dan Allen
>
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://www.google.com/profiles/dan.j.allen#about
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
12 years, 10 months
Removing the combined jar
by Shane Bryzak
We discussed this briefly on IRC, however I thought we should discuss it
on seam-dev before we make any concrete decision. To summarise the plan:
1. Remove the combined jar file from each of the modules
2. If the module has a single implementation, rename it to whatever the
combined jar was called.
E.g. for Seam Catch, the impl module would be called seam-catch.
3. If the module has multiple implementations, then add a suffix to the
artifact name that reflects the individual implementation.
E.g. Seam Reports has two implementations, which would be called
seam-reports-jasper (for Jasper reports) and seam-reports-pentaho (for
Pentaho).
4. Leave the API naming as it is, e.g. seam-reports-api.
The idea is that by importing the simplified module artifact name (i.e.
"seam-xxx") you would get the default implementation, which in turn
depends on the API. The advantage of this is that we won't break
backwards compatibility - e.g. someone currently declaring a dependency
on "seam-catch" in their pom file won't have their app broken when we
rename the modules. Also we remove the complexity introduced by having
a combined jar in the first place.
If you can spot any issues with this, please speak up now ;)
Shane
12 years, 10 months
Re: [seam-dev] Removing the combined jar
by George Gastaldi
I have to say that is such a pleasure to work with this team.
These ideas would certainly raise Seam to the top.
Em 09/06/2011, às 21:13, Shane Bryzak <sbryzak(a)redhat.com> escreveu:
Sounds good to me, as also the combined jars for various other profiles.
Jason, care to add this to the agenda for next week's IRC meeting and we can
flesh it out a little further?
On 10/06/11 08:40, Dan Allen wrote:
I suggested this a while back as the "Seam for Web Profile".
seam-web-profile.jar
Calling it seam.jar is *way* too ambiguous and is going to do nothing but
lead to confusion. Let's give the stack a name (such as "Seam for Web
Profile") and qualify the jar.
So +1 to that revised idea :)
-Dan
On Thu, Jun 9, 2011 at 18:26, Shane Bryzak <sbryzak(a)redhat.com> wrote:
> That's a fair point, however to address this (and for simplicity's sake)
> what if we were to provide a combined jar that included most of the
> modules? I would say that the following list represents the "core" of Seam:
>
> Solder
> Catch
> Config
> International
> JMS
> Mail
> Persistence
> REST
> Security
> Servlet
> Validation
>
> We would simply call this combined jar seam.jar, and on top of that, the
> developer would also add dependencies for whatever view technology they're
> using (i.e. seam-faces, errai or seam-wicket), and then the extra features
> if they require them (Cron, JCR, Remoting, Reports, Social, etc). That
> should greatly reduce the number of jar files in a deployment.
>
>
> On 10/06/11 08:08, John D. Ament wrote:
>
> -1
>
> In my opinion the combined jar helps keep the number of JAR files down in
> deployments.
>
> On Thu, Jun 9, 2011 at 12:54 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
>
>> +1
>>
>> -Dan
>>
>>
>> On Thu, Jun 9, 2011 at 00:12, Jason Porter <lightguard.jp(a)gmail.com>wrote:
>>
>>> +1
>>>
>>>
>>> On Wed, Jun 8, 2011 at 17:32, Shane Bryzak <sbryzak(a)redhat.com> wrote:
>>>
>>>> We discussed this briefly on IRC, however I thought we should discuss it
>>>> on seam-dev before we make any concrete decision. To summarise the
>>>> plan:
>>>>
>>>> 1. Remove the combined jar file from each of the modules
>>>> 2. If the module has a single implementation, rename it to whatever the
>>>> combined jar was called.
>>>> E.g. for Seam Catch, the impl module would be called seam-catch.
>>>> 3. If the module has multiple implementations, then add a suffix to the
>>>> artifact name that reflects the individual implementation.
>>>> E.g. Seam Reports has two implementations, which would be called
>>>> seam-reports-jasper (for Jasper reports) and seam-reports-pentaho (for
>>>> Pentaho).
>>>> 4. Leave the API naming as it is, e.g. seam-reports-api.
>>>>
>>>> The idea is that by importing the simplified module artifact name (i.e.
>>>> "seam-xxx") you would get the default implementation, which in turn
>>>> depends on the API. The advantage of this is that we won't break
>>>> backwards compatibility - e.g. someone currently declaring a dependency
>>>> on "seam-catch" in their pom file won't have their app broken when we
>>>> rename the modules. Also we remove the complexity introduced by having
>>>> a combined jar in the first place.
>>>>
>>>> If you can spot any issues with this, please speak up now ;)
>>>>
>>>> Shane
>>>> _______________________________________________
>>>> seam-dev mailing list
>>>> seam-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Jason Porter
>>> http://lightguard-jp.blogspot.com
>>> http://twitter.com/lightguardjp
>>>
>>> Software Engineer
>>> Open Source Advocate
>>> Author of Seam Catch - Next Generation Java Exception Handling
>>>
>>> PGP key id: 926CCFF5
>>> PGP key available at: keyserver.net, pgp.mit.edu
>>>
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>>
>>>
>>
>>
>> --
>> Dan Allen
>> Principal Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://www.google.com/profiles/dan.j.allen#about
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>
> _______________________________________________
> seam-dev mailing listseam-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
12 years, 10 months
Git Flow
by Jason Porter
Who has questions about Git Flow? Aside from sending out the same links I've
sent out in the past, I want to answer your questions about it before we
officially adopt the workflow for all seam modules.
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
12 years, 10 months
Hibernate 4.0 + Seam 2.x on AS7?
by Scott Marlow
Hi,
I saw the recent post about testing Seam 2.x on the (upcoming) JBoss AS7
and wanted to ask about Hibernate 4.0 support.
Currently in AS7, we inject the Hibernate (4.0) module dependencies into
application deployments, if we scan certain (@PersistenceUnit
@PersistenceContext or their equivalent deployment descriptor) )
annotations or a persistence.xml.
Any idea if Seam 2.x applications will also work with Hibernate 4.0?
Thanks,
Scott
12 years, 10 months
Access to SF.net and JBossDocs
by HitCity BCC
Hi,
I have released Seam Cron 3.0.0.Alpha1 into the Nexus repository, and it
looks like the sync to the JBoss releases repository is coming along:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/seam/c...
The next steps are to (1) upload the distribution to sf.net and (2)
upload the docs to /seam@filemgmt.jboss.org:docs_htdocs/seam/3. /I'm
therefore wondering if in each case I can either be granted appropriate
privileges or if someone with appropriate privileges can perform the
task for me?
Sorry I'm not sure which list was best for this.
Cheers,
Pete.
12 years, 10 months
Seam Security and @RestrictAtPhase
by Ove Ranheim
What does this message mean?
10:56:38,103 WARN [org.jboss.seam.faces.security.SecurityPhaseListener] Annotation %s is using the restrictAtViewMethod. Use a @RestrictAtPhase qualifier on the annotation instead.
I'm Seam Security JPA IDM.
Ove
12 years, 10 months
