I wanted to add a new addon to Forge that handles the Java EE security
- Add constraints to some resources
- Setup authentication mechanism (form, basic, digest, etc.)
- Assign realm to security constraints
- Create security roles
- If the realm is JDBC and JPA facet is installed, add an entity along with
some named queries
I looked in the Forge JIRA whether there is something like that and I found
this issue created almost a year and a half ago:
I read in the description though, that the addon should be also able to
setup groups and users inside a realm. Isn't that too server specific if
the realm is not JDBC? Maybe we could continue the communication in the
issue, so whoever is interested my add themselves as a watcher there?
The problem is:
We have this method: ErrorPageType getOrCreateErrorPage();
I’ll propose create a ErrorPageType getOrCreateErrorPage(String erroCode);
The getOrCreteErroPage only check if web.xml has an error-page. This case,
if I want do that:
String errorLocation =
The shrinkwrap only put an error-page. This case, only 404. :)
I fixed the FORGE-2072 with 2 methods because we need specify the
WebAppDescriptor for servelet-api version, but this case erro-page is a
common feature for two version of the api. No make sense sense to have two
interface to this method.
I think better to have:
WebAppDescriptor30 extends WebAppDescriptorCommons
WebAppDescritptor31 extends WebAppDescriptorCommons
I don’t think a valid idea create a descriptor in forge if we have the
shrinkwrap for that.
If it is a good suggestion, please.. open an issue in shrinkwrap. :)
Daniel Cunha (soro)
I resumed my Security addon development and reached my "favorite" point:
writing and executing UI command tests. I have attached here the output of
the test harness as well as the sample test that I wrote.
Here are some observations:
- It took one minute for Forge to run a simple UI test. And this is on
Linux. From my experience, if I run the same test on Windows, it would take
at least twice more
- Even though Lincoln explained it to me at least twice, setting up
@Deployment @AddonDependencies and AddonDependencyEntry's is still black
magic to me. I usually copy those hoping that I didn't miss anything, but
the result of this test proves that I missed something
- For the most part the test was starting furnace, checking the missing
dependencies, installing them one by one, but in the mean time it installed
their transitive dependencies and for each of these operations, Forge was
again shutting down and starting up furnace and weld. And then again
calculating missing dependencies. Most of these operations take usually
less than a second, but still there are so many of them that at the end it
piles up to a whole minute
- To be fair, some big chunks of this minute was taken by, what it seems
to me, resolution of transitive dependencies:
Dec 22, 2014 11:15:49 PM org.jboss.forge.furnace.impl.addons.AddonRunnable
INFO: >> Started container
[org.jboss.forge.addon:ui-test-harness,2.13.1-SNAPSHOT] - 133ms
Dec 22, 2014 11:15:58 PM
INFO: Deploying addon org.jboss.forge.addon:parser-xml,2.13.1-SNAPSHOT
Dec 22, 2014 11:16:12 PM org.jboss.forge.furnace.impl.addons.AddonRunnable
INFO: >> Started container [org.jboss.forge.addon:javaee,2.13.1-SNAPSHOT] -
Dec 22, 2014 11:16:24 PM
INFO: Deploying addon org.jboss.forge.addon:maven,2.13.1-SNAPSHOT
- The test failed with the following exception:
java.lang.IllegalStateException: Test runner could not locate test class
[org.jboss.forge.addon.javaee.security.ui.SecuritySetupCommandTest] in any
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
However, the real reason was hidden in the massive console output a bit
Dec 22, 2014 11:16:25 PM
INFO: WELD-000119: Not generating any bean definitions from
of underlying class loading error: Type
org.jboss.forge.addon.javaee.ProjectHelper from [Module
from AddonModuleLoader] not found. If this is unexpected, enable DEBUG
logging to see the full error.
Enough with the observations. What can we do about it? Well, I see the
following areas of improvement:
- Fight the black magic. It shouldn't be so hard to setup a test. What I
usually need is a UI test harness, project utilities, sometimes a parser
and the addon that I am testing
- Fight the slow startup time. So, we are using Arquillian. Imagine how
would you feel if Arquillian was setting up from scratch Wildfly or (oh
my!) WebLogic every time you run a Java EE test? Instead, it just relies on
the fact that the target runtime is there
So, can't we just create a composite test addon or something like that?
That we use as kind of arquillian container and we just update the needed
addons there. Instead of setting up everything from scratch. And in the
@Deployment method we simply list the addons (or even at smaller
granularity: files) that are changed and we want to be redeployed on top.
This doesn't look too far away form the Arquillian model that we are all
used to. And I believe that will be much faster to start (especially in the
so called 'remote' arquillian mode).
What do you think?
The other day on #IRC I mentioned having PermGen issues with the JBossAS
add-on. It's confirmed. During the HoL there are plenty of people who had
the same issue : install the JBoss add-on, start wildfly 8.1, build the
app, deploy it, go to the index.html page (fine), click on an Entity, bang
Alexis Hassler investigated it during the lab (see below). Basically, no
matter what PermGen you set, it's not taken into account.
Again, I really think this add-on should be looked after carefully, it's
---------- Forwarded message ----------
From: Alexis Hassler <alexis.hassler(a)gmail.com>
Date: Tue, Nov 11, 2014 at 11:37 AM
Subject: Re: Forge + Wildfly VM arguments
To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
Pas de changement avec
as-setup --server wildfly8 --installDir /opt/java/wildfly-8.1.0.Final/
--jvmargs "-Xmx512m -XX:MaxPermSize=256m"
2014-11-11 11:22 GMT+01:00 Alexis Hassler <alexis.hassler(a)gmail.com>:
> Avec un wf externe, démarré avec as-start.
> Pour info, en démarrant un wf 8.1 en ligne de commande "normale" :
> -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m
> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> http://www.jtips.info, http://blog.alexis-hassler.com,
I'm happy to announce the first release of the UPS Java Sender Forge Addon,
This addon will help the developer to integrate the Java Sender into their
Basically it provides 2 commands :
- unifiedpush-setup : will pull in the dependency and create a
pushConfiguration.json file that contains the needed information (UPS url,
PushAppID and master secret)
-unifiedpush-generate-service : will generate a small service that wraps
the Java Sender, you can then easily inject it into your business logic.
The nice thing about Forge 2 Addons, is that you get JBDS Integration for
"free" , so these 2 commands are available in JBDS as UI Wizards.
I created a blog entry for that which also contains a screencast :
The code is hosted here for now :
https://github.com/sebastienblanc/unifiedpush-addon but will soon be
migrated under the AeroGear org.
This event has been changed.
Title: Forge Status Meeting (IRC #forge)
When: Weekly from 10am to 11am on Tuesday Eastern Time (changed)
Where: #forge on irc.freenode.net
Calendar: Forge Project Calendar
* George Gastaldi - creator
* Lincoln Baxter, III
* Koen Aers
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
forge-dev(a)lists.jboss.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.