Seam JMS module refactoring/restructuring
by John D. Ament
Gents,
I've been working diligently (whenever I have time) to get the seam JMS
module up and running on the new test suite format. One thing I've noticed
is that because of the caveats of using JMS In SE vs. EE, it didn't just
work to run weld ee embedded and within a container tests by themselves. It
also became clear that in general this wouldn't work outside of a container
because of differences in how to start open mq vs. hornetq vs. activemq.
Even working in a remote JNDI provider (similar to how weblogic JMS works)
it wouldn't have worked quite right.
Soemthing I started a while ago (maybe 4-5 weeks) was to separate various
impls to different modules. I want to go ahead and move forward with this
approach. This would provide the main api and impl (across all impls) as
well as a domain specific impl (e.g. seam-jms-ee-impl) that contains
functionality for EE environments. As a result, when running the test
suite, you are verifying the api, impl, the domain specific impl and the
test suite for that specific combination.
Does anyone have any concerns with this approach?
John
13 years, 2 months
Catch, Config and Servlet modules merged with Solder
by Shane Bryzak
Just a heads up to everyone,
I've merged the catch, config and servlet modules into Solder, so
committers/integrators for these modules should no longer send any pull
requests or merge any changes for these modules, instead they should now
go into Solder.
There's still a few additional steps that need to be carried out -
1) documentation still needs to be merged
2) JIRA issues merged and the old modules deleted
3) sfwk.org updated to reflect the change
4) seam-bom updated
5) modules or examples that use catch, config or servlet need to be updated
FYI, the new package names are:
Seam Catch - org.jboss.solder.exception
Seam Config - org.jboss.solder.config
Seam Servlet - org.jboss.solder.servlet
Any questions or concerns, ask away. We'll be hammering out the
remaining items that I listed above over the next couple of days.
Shane
13 years, 2 months
cdi/weld/seam - testing failed deployments in arquillian
by Martin Kouba
Hi,
recently during CDI TCK arquillian migration (1.1 branch) we had to
replace test harness @ExpectedDeploymentException in tests expecting
deployment failure.
So currently in TCK we use @ShouldThrowException(Exception.class) on
arquillian deployment method. Indeed testing generic Exception is not
the best solution but in fact right now we cannot test exact deployment
causewhile there are no standardized CDI deployment-relatedexceptions
(in CDI 1.1 there will be - see CDI-118 Standardize deployment-related
exception classes). Also note that "Adding this annotation will force
@{@link Deployment} to be testable = false which will force @{@link
RunAsClient}".
The other possibility is to use something like Assert.fail("Deployment
should have failed...") or assert false in test method. Seam
Compatibility and Weld use this approach.
The question is whether to standardize this among all cdi/weld/seam
tests. I think we should use the arquillian way (@ShouldThrowException)
while its more obvious that we expect deployment failure and use
relevant expected exceptions as soon as CDI 1.1 arrives.
WDYT?
M
--
Martin Kouba
JBoss Quality Assurance Engineer
E-mail: mkouba(a)redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
13 years, 2 months
Solder Testsuite update 2
by Dan Allen
Fantastic! Good work.
-Dan
---------- Forwarded message ----------
From: Marek Schmidt <
reply+i-1691451-c32d2a63f3bd03cabdcf4cb6a304e2d5daf15ab9(a)reply.github.com>
Date: Tue, Sep 20, 2011 at 16:33
Subject: [solder] Testsuite update 2 (#49)
To: Dan Allen <dan.j.allen(a)gmail.com>
Yet another testsuite structure update, now even more simpler.
This request includes Ken's changes (rebased) which brings non-arquillian
unit tests back into impl/
Working Weld Embedded (default) and AS7 profiles (with one test failure,
which I consider a bug in Solder and/or AS7)
This patch also removes the hacky MavenArtifactResolver and uses a
hard-coded paths, such as ../impl/target/solder-impl.jar to ZipImport Solder
Modules. I believe this is now the most robust method for importing
artifacts from the same project, for which MavenDependencyResolver cannot be
used. That is, until the MavenImporter is ready (which should be Real Soon
Now, see SHRINKWRAP-325). The only downside of this is that <finalName/> has
been added to solder POMs, so that the build outputs have a reliable file
name.
You can merge this Pull Request by running:
git pull https://github.com/maschmid/solder testsuite-update-2
Or you can view, comment on it, or merge it online at:
https://github.com/seam/solder/pull/49
-- Commit Summary --
* yet another testsuite structure
* rebase Ken's testsuite updates, moved unit tests back to impl/
--
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
13 years, 2 months
Re: [seam-dev] Testsuite discussion notes
by Shane Bryzak
Was it decided who would take care of the testsuite restructure? I must
admit I wasn't paying much attention during this discussion ;)
On 19/09/11 23:39, Jozef Hartinger wrote:
> INTEGRATION TESTS
>
> Structure:
>
> - api
> - impl
> - testsuite / src / test / java
>
> Container-specific issues
> - there will be a BaseDeploymentFactory that creates base deployment
> based on a system property (arquillian container name)
> - there will be no common package scheme for now
>
> Default profile
> - weld embedded
> - skipped tests if weld embedded does not make sense in the context of
> the module
>
>
> FUNCTIONAL TESTS
> - m4 will be used to generate pom files from our templates (stored in
> Seam QA github)
>
13 years, 2 months
DWG Meeting minutes
by Shane Bryzak
People present:
Jason Porter
Ken Finnigan
Shane Bryzak
1) Standardised error codes
We discussed the idea of implementing standard error codes throughout
all Seam modules. These error codes would be unique, and allow Seam
developers to reference a central database (such as Seam University)
describing each error and possible workarounds. The error codes
themselves will be prefixed with a 2 or 3 letter code (that represents
the module), followed by a number. For example:
[SEC-1234] Invalid credentials supplied
The SEC prefix represents an exception in the Seam Security module.
Other modules would have different codes, for example CAT = Seam Catch,
VAL = Seam Validation, SVL = Seam Servlet, and so forth. The number
part of the error code will start at 0000 for each module. The error
message itself should support internationalisation, which will be a
bonus to our non-english speaking users. Each module will define its
own internationalised message resources. Ken is going to work on
creating a new API in Solder which we can use to perform the logging of
these errors.
2) Inter-module dependencies
The second topic we discussed was how we manage dependencies between
modules. It was agreed that wherever possible, dependencies should be
optional. An example of this is the dependency that seam-faces has on
seam-catch. In some cases it may be necessary for a module to have a
hard dependency on another module, however if this becomes an issue in
the future we may look at alternatives such as creating sub-modules that
separate the integration from the rest of the module.
If anyone has any questions, feel free to ask. We will be holding the
DWG meeting in TeamSpeak once per month, on the first tuesday of the
month - details can be found in the seam-dev calendar.
Thanks,
Shane
13 years, 2 months
Enabling extensions
by Pete Muir
Seam team, and others on the CDI EG,
Looking for feedback on an issue Marius and I discussed in CDI 1.0. This is potentially an issue - we weren't sure if people had seen it in the real world, hopefully you may have seen feedback in the forums or at conferences.
This relates closely to the interceptor/decorator/alternative enabling discussion.
Typically an extension class is packaged in a jar, along with a META-INF/services/javax.enterprise.inject.spi.Extension file which enables it. However, this means that an application, or another extension, has no way of disabling extensions.
Is this a problem, really? Or just theoretically.
13 years, 2 months
