generate entities in JBossTools
by Dan Allen
Max,
Save me. Where does JBossTools get the org.jboss.seam.tool.Util class
from? I added a method to it named isToOne() but FreeMarker doesn't
seem to want to find this method when running generate-entities
through JBossTools. My guess is that there is some other JAR somewhere
that is being used rather than lib/gen/jboss-seam-gen.jar in the Seam
distribution, but I could be wrong.
On another note, we should move this isToOne() method into Hibernate
Tools anyway. If you take a look at it (src/gen), I needed to create
it because currently this information is not exposed as a built-in
function call. A one-to-one and a many-to-one mapping are represented
exactly the same in the UI, so I was able to offer an extra feature
for those wanting to see one-to-one relationships in the UI out of the
reverse engineering process. Only, it is causing JBossTools to bomb at
the moment.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
16 years, 1 month
rewrite filter: logging and outbound rewriting
by Dan Allen
First, let me say that I like the rewrite support in Seam 2.1 (I just
discovered it a couple of days ago). I have one concern and one
suggestion. First, my concern.
The logging level in the filter is too high. Reporting the matching
paths should be a debug-level log, not an info-level log. It's a
simple matter of ratio. The log messages at info level are now being
dominated by this filter. Perhaps it can report a summary when it
matches, but now it is reporting the details about how it is locating
the match.
Second, it appears that this filter does not offer outbound rewriting.
If the link on my page has a URL that would match, it is not being
rewritten. Is this planned? If not, can we plan it?
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
16 years, 1 month
Seam 2.1.0.GA
by Pete Muir
All,
We have closed most of the major issues for Seam 2.1.0.GA, leaving a
few issues. So, I would like to have a code freeze for the GA release
on Wednesday morning (east coast) this week.
Norman, you've still got a load of open doc issues, how are you
getting on with them? Also, you have a couple of bugs, if you haven't
made any progress with them, can you unassign them and I'll take a look.
Thanks for all the hard work guys :)
Pete
16 years, 1 month
AMF/Java Serialization strategy
by Dan Allen
A client asked me the other day to recommend for him an AMF/Java
Serialization strategy to use with his Seam application. At the Italy
meeting, Christian mentioned that while the current solutions have
merit, we might want to consider putting forth our own implementation.
Any thoughts, or should we just integrate/recommend GraniteDS? We
don't have to solve this problem right now (and I'm not necessarily
calling for responses), but I think it is good to list as an item on
the roadmap.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
16 years, 1 month
a modest seam-gen style upgrade
by Dan Allen
You may have noticed by now that seam-gen has gotten a modest style
upgrade in the trunk. This upgrade is based on "style mods" I have
been maintaining while working on the source code for Seam in Action
(I had to dress up the screenshots for the show). Understand that this
is just a first step in making seam-gen applications look more
presentable, but nonetheless, and important first step.
Below is a list of the enhancements (perhaps something worth blogging about):
1. Added a favicon of the Seam logo
- personally, I think this is the coolest and simplest enhancement
- by the way, we should consider use this favicon for
seamframework.org because I made it transparent
2. Icons for each level of error message (warn, error, info)
3. Stripped the border and background from global messages and fixed
the indenting to accommodate the icons
- the messages were still using the style from the original orange
theme seam-gen projects had
4. Used a RichFaces XCSS resource so that the theme matches the
currently selected RichFaces theme
- I also applied some of the RichFaces gradients to form controls to
make the forms look better (w/ very little CSS)
The only downside of the new theme is that the Visual Editor in
JBossTools doesn't understand the XCSS file (which resides in the
stylesheets directory). Therefore, I left behind the old theme.css and
put an instruction in template.xhtml about switching to the static
theme.css for previews. It would be great if the Visual Editor could
interpret the XCSS file. This opens up so much flexibility for
extending the RichFaces theme.
The commit also came with some other goodies:
1. seam-gen WAR projects now have a consolidated compile target
2. two new targets reexplode and redeploy, which do a clean unexplode
explode or clean undeploy deploy, respectively
3. restart now detects if you have deployed an exploded or packaged
archive and restarts it appropriately (before it bombed if you had a
packaged archive deployed)
4. EAR projects now compile groovy scripts on the classpath (deploying
raw .groovy files requires more research)
5. Added a "head" named insertion in the template.xhtml so that you
can add additional markup in <head> on a per-page basis
6. Global messages now reside in template.xhtml with a Facelets
parameter you can use to turn them off on a per-page basis
7. Changed src/action to src/hot and src/model to src/main
8. Added the view folder to the classpath for tests so that page
actions defined in *.page.xml are invoked during testing (previously
the tests only read the global pages.xml file)
9. Added a javadoc task to the build
10. The default username is admin and the password is blank.
Developers never got to see the failure login scenario out of the box
because we let any credentials through (obviously, with the new
security stuff, we don't even need the authenticator component, but
that is a next step perhaps)
All in all, what these upgrades should do is make your demos of Seam
look just a touch prettier and give you a few more wrenches for
development. There are still plenty of improvements that could be
made.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
16 years, 1 month
renaming source directories in a seam-gen project
by Dan Allen
I would like to propose that we modify the name of the source
directories in a seam-gen project so they better reflect how they are
built rather than what classes they might contain. The current paths
are:
src/action
src/model
The src/action directory works as the hot deployable classpath when
running in development mode. In production mode, they both get dumped
into the same classpath. Here is the renaming I am proposing:
src/action -> src/hot
src/model -> src/main (or src/static)
I am *not* looking for a major change here. This is just a small task
that I feel would just cause less confusion. For instance, I often
recommend to clients to move classes that have "solidified" out of the
hot deployment directory so that they are not constantly reloaded
(hence wasting build time). But currently it feels unnatural to put an
action component under src/model.
I would like to know if these names are okay and if, perhaps, you have
a better choice for "src/main". I really don't expect objections to
"src/hot", but you have a chance to speak up.
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
16 years, 1 month
How to reduce UserTransaction lookups
by Jay Balunas
I took a quick stab at a fix for the transaction lookup problem. I will
create a related jira for this issue, so that we can track it and resolve it
for Seam 2.1.1.
All of the JNDI requests for UserTransaction go through the
org.jboss.seam.transaction.Transaction class (see :
http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/transa...).
This is an event scoped component so its lifecycle covers the entire
request from RESTORE_VIEW through RENDER_RESPONSE.
I modified it (see attached patch file) so that it stores the result of the
transaction lookup (UserTransaction, EjbTransaction, or NoTransaction). It
then returns this result the next time a transaction is requested.
This drastically cuts down the number of JNDI lookups. For the wiki user
forum front page the number of lookups went from 114 to 6!! One at the very
start of the RESTORE_VIEW phase. Then the 5 others are after the
REDER_RESPONSE phase. I'm assuming because of ajax related calls for
caching.
I ran this change through the 25 and 50 user performance runs and saw a
small increase in performance, but I have not yet investigated the details
in the profiler to determine exactly where we are spending the time now. I
would guess that we are not not blocking as heavily on the InitialContext
lookups, but instead are passing through that code quickly and hitting
further blocks, or processing bottlenecks in the persistence layer.
I looked a bit at using synchronizations in an attempt to clear the stored
value if the transaction is completed during the event scope but I ran into
some issues with that. The current approach seems to working fine, and the
wiki behaves normally, but I wanted to get some more opinions on this
What is the risk of caching this transaction instance in the event scope?
How can we determine when/if the transaction is not valid anymore - do we
need to?
Does the behavior need to be different for UTTransaction vs CMTTransaction?
Thanks,
Jay
--
blog: http://in.relation.to/Bloggers/Jay
16 years, 1 month
Gary Pinkham ?
by Max Rydahl Andersen
Hi,
Anyone know subject under gpinkham(a)comcast.net ?
He has signed up under http://www.jboss.org/contributor the 8/1/07, but I
was just first today made aware I had to go there so had not seen it
before now.
--
/max
16 years, 1 month
XSRF and JSF2
by Christian Bauer
Because it is back on Slashdot again today, I remembered why the
"let's automatically build a view if we don't have one in RESTORE VIEW
phase" proposal in JSF 2.0 was not sitting right with me.
You need a little background on XSRF (Wikipedia or something) and see
the older discussion here and especially my last comment:
http://www.seamframework.org/Community/IsSeamRemotingVulnerableToCrossSit...
I actually now think that we should have a cryptographically strong
(and of course mandatory) view identifier for better XSRF protection.
There are some other solutions worth discussing but AFAIK most of the
good ones involve a token/session mapping of some kind, so we run into
the "view has expired" problem again.
16 years, 1 month
WebResource
by Nicklas Karlsson
Hi,
Working on the s:debug tag and loading of css/js/image resources I
noticed WebResource, how is it used? Are you just supposed to put your
stuff
in subpackages of org.jboss.seam.ui.resource?
I notice that there are a few custom implementations of
AbstractResource but since all I'd like to do is serve static
resources from a JAR file, would
it be a good idea if there would be some sort of general
WebResourceStore (in the same manner as there is a GraphicImageStore)
and the WebResource
would use the WebResourceStore in the same manner as
GraphicImageResource uses GraphicImageStore (although that one seems
to be used for one-time-fetches)?
I could then e.g. in my tag encode do
Check that resources are not already added
Get byte[] from resource
ResourceWrapper wrapper = new ResourceWrapper(bytedata, mimetype);
WebResourceStore.instance().put(wrapper, stringhandle)
and then have the resources available in session scope...
---
Nik
16 years, 1 month
