glassfish and Seam Faces error.
by Sebastian E. Ovide
Hi All,
I am getting SEVERE: Class [ Lorg/jboss/logging/Logger; ] not found. Error
while loading [ class
org.jboss.seam.international.timezone.DefaultTimeZoneProducer ] when trying
to include Seam Faces into my poms...
so I've downloaded the sample (seam-faces-examples-short-ly) and tried to
run in... getting the same error.
I'm using NetBeans 6.9.1 and running the application from there (with
GlassFish)
any ideas ?
--
Sebastian E. Ovide
14 years, 10 months
JIRA right for SeamMail
by Cody Lerum
Not sure who handles this, but can I get setup with the correct
permissions for SEAMMAIL in JIRA? I don't seem to be able to
edit/assign/close tickets.
user: clerum
Thanks!
-C
14 years, 11 months
Seam 3 > Logging solution
by Antoine Sabot-Durand
Just to know if there are use cases where weld-logger is a better choice than Jboss Logging (with Seam Solder integration) or is this last solution the best in all circumstances ?
Antoine SABOT-DURAND
15 years
Seam 2.2.1.CR3 testing status
by Ondřej Skutka
Hi!
We've finished the Seam 2.2.1 CR3 testing.
What has been tested:
- Initial testing as per release-process.txt
- Documentation review
- JBSEAM-4754
- JBSEAM-3347 - updated
- Unit and Integration tests
- seam-gen tests
- JBSEAM-4751 - Test task not working in a seam-gen project
- JBSEAM-4753 - seam-gen tests fail in icefaces configuration
- JBoss Tools 3.2.0 Beta 2 (20101206)
- JBIDE-7931 Seam EL code completion of built-in components does not work in JBoss Tools for projects created in seam-gen
! - JBIDE-7932 - Critical - New Seam EAR project fails to deploy to JBoss AS 6 CR1
! - JBIDE-7957 - Blocker - JBoss Tools crashes editing a facelets template
- JBIDE-7958 - TestNG tests fail in Seam project
- Functional tests against JBoss AS 6.0.0.CR1, Tomcat 6.0.29, JBoss AS 5.1.0, JBoss AS 4.2.3, JBoss Embedded beta-3.SP10 in Tomcat 6.0.29
- JBSEAM-4750 - Unable to run ftests for tomcat and jboss-embedded due to missing build target (ran manually)
- JBSEAM-4752 - A chatroom example works only in Firefox web browser
- JBSEAM-4663 - backbuttoningAfterLogoutWithAjaxTest fails in Booking example
- Cluster tests
- Portlet Bridge (using JBossPortletBridge-2.1.0.FINAL and GateIn-3.1.0-FINAL-jbossas)
Issues denoted with exclamation mark are critical or blockers.
Ondra
15 years
combined JAR artifacts
by Dan Allen
Module leads,
As you know, we've established API artifacts for each of the Seam modules.
Having an API is obviously very important, but for the purposes of getting
started quickly, its good to also have the option of the combined API+impl
JAR (catering to "it's just one JAR file")
Thus, each module should include a "combined" submodule that shades the API
and implementation(s) into a single artifact. The name of the shaded
artifact is seam-{module}. It should not include any dependencies, only the
API and impl. Additionally, it should not be declared as a dependency when
linking to another module because it's not the official artifact.
You can use the combined build in either solder [1] or persistence [2] as a
reference. If anyone has any suggestions about how to make it better, please
chime in. As always, this is a proposal.
-Dan
p.s. I will mention, though, that the reason I could not put this plugin
configuration in the implementation submodule is due to a limitation w/ the
shade plugin. You cannot shorten the artifactId, only append to it, meaning
you can't set it to seam-persistence in the seam-persistence-impl submodule.
[1] https://github.com/seam/solder/blob/master/combined/pom.xml
[2] https://github.com/seam/persistence/blob/master/combined/pom.xml
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
15 years
Re: [seam-dev] Transition to Seam Solder
by Stuart Douglas
On 21/12/2010, at 7:35 PM, Dan Allen wrote:
> seam-parent 5 and seam-bom 3.0.0.b04 are now ready.
>
> I also updated config and persistence to use all the new dependency management goodness. All tests pass, as far as I can tell.
>
> I've noticed that we are going to have to address an issue with the migration from Weld 1.1.0.Beta1 to CR1...it's not a drop in replacement. Neither the config nor persistence tests will pass on CR1. We need to dig deeper. I will give you a hint though...the order of the type parameters on ProcessProducer and ProcessProducerMethod has inverted. You can see this in the Solder LoggerExtension test. So we'll cross that bridge in time.
I think that this is an issue with Arquillian not being compatible with 1.0.0.CR1.
Stuart
>
> For now, release away!
>
> -Dan
>
> On Tue, Dec 21, 2010 at 1:01 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> On Mon, Dec 20, 2010 at 11:42 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com> wrote:
> Both my modules have been switched over to solder. Hopefully I will release tonight.
>
> Thanks Stuart. Actually, if you hold off, I'm going to switch your modules over to a new parent, thus aligning some of the dependencies. I'll send you an update when I'm done. Working now.
>
> -Dan
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
>
>
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
15 years
Java EE API artifacts
by Dan Allen
Module leads,
I'd like to propose that whenever you need to link to a Java EE API
artifact, that you use the ones listed in the JBoss Java EE 6 spec bom [1].
The reason is that we have control over these API artifacts and thus can
rely on them. As you may be aware, the Java EE 6 APIs are inconsistently
published to the Maven repositories. It also makes it easy for us to align
on the APIs we are using for compilation across modules.
Java EE 6 APIs should always be marked as provided, so there should be no
affect on consumers of the Seam modules. Basically, it doesn't matter what
we use, so we want to use the least painful option.
Here's an example of the JPA API:
<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.0-api</artifactId>
<scope>provided</scope>
</dependency>
The versions get inherited from the seam-bom.
-Dan
[1]
http://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/jb...
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
15 years
