Re: [Shale-Spring] update to 2.0.1 ?
+1 for updating to Java 1.5. Obviously we need to be clear in the docs. Sean On 4/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: :) On 4/20/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Matthias Wessendorf wrote: Later than expected, but my hard disk crashed, I am days behind my schedule :( Lucky guy if you are JUST DAYS behind your schedule . ;-) --- Mario -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: See You In Amsterdam?
Matthias I ran it by my wife about stopping in Germany but we both feel there's not enough time and we would be rushed (we only have a week since the little one will staying behind.) We would rather go to Germany as part of a separate trip and come see you then! We'll be arriving in Amsterdam on Saturday night so I'd love to try and get together with you before the conference starts. Email me offlist and we can make a plan. Sean On 2/2/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: how long are you staying in Europe, Sean ? wanna see Germany ? On 2/2/07, Sean Schofield [EMAIL PROTECTED] wrote: Craig, My wife and I are both going to be there. We're also planning on arriving early. Sean On 1/26/07, Craig McClanahan [EMAIL PROTECTED] wrote: My general session on Shale got accepted for ApacheCon Europe 2007 ... it's Friday May 4 at 10h30. Hope to see anyone else who is coming there! And I'm planning on coming in early enough for Queen's Day on Monday. Now I just need to go find an orange shirt ... Craig -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [jira] Resolved: (SHALE-334) API links broken on Shale View Controller site
Fixed a couple of links to javadocs on the index page, plus a relative reference to the test framework. Feel free to reopen if you find any more, but *please* be specific about where the links are. Sorry. All of the API links that I checked were broken so I assumed the problem was a general one. Sean
Dialog navigation woes
I'm trying to use the new dialog stuff in a production app. Previously I had only been using dialogs in popup windows (with no browser back buttons to worry about.) Now I think I'm running into the same problems as Rahul and others have reported. I will describe my usecase where I think the results are unexpected. I'm working on a website for a marina. Most of the site navigation links bring up other pages but when they click on boats, a shale dialog is started that helps them to browse the list of available boats. The dialog is completely transparent to the user. The same site menu navigation options appear on the page and the user has no idea they are in a dialog. If in the middle of browsing through the listing the user wants to start over they will likely click the boats link again. This time it appears to do nothing. In reality its starting the dialog which is picking up where it left off. The end result is the user is stuck. Is this really desirable behavior? Maybe we should at least have the option to restart the dialog? Also, if the user bookmarks any of the pages in the dialog, they are pretty much screwed. I realize there is a larger bookmarking in JSF issue here but I'm looking for some ideas. TIA, Sean
Re: Dialog navigation woes
IIRC, you filed some RFE requests against dialog for a similar use case, and we listened :-). You can fake a restart by programmatically stopping the current dialog, and then programmatically starting a new one. Does that do the trick for you? I guess this means an action method that returns dialog:BoatsDialog after killing the dialog instance? Otherwise how would the user be able to stop the dialog simply by clicking a link? To do this, simply gain access to the DialogContext object (its session scoped under key dialog) and call stop(). Then get the DialogContextManager (session scoped under key Constants.MANAGER_BEAN) and call create(). Yes I saw this in the docs. Its definitely an improvement but I stil think the default (resume the dialog) can be a bit unexpected. I'm also running into problems with the MyFaces scrollable datatable. If you click on page 2 nothing happens. I take it the NavigationHandler is swallowing the null nav outcome still? Craig Sean
Re: Site perms
Is everyone ok with permissions now? Sean On 11/7/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 11/7/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/7/06, James Mitchell [EMAIL PROTECTED] wrote: No, I haven't run anything from my machine in about 6 months. The nightlies for Struts and Tiles are currently being done on my account on the Struts zone. Other than a few permission issues on minotaur, that process has been pretty much flawless. It looks like Continuum on the MyFaces zone is deploying the snapshots and the website: http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/View.vm/fid/maven2Project/id/186;jsessionid=buundeman9fk James, you mentioned Struts and Tiles, are you doing anything for Shale? Sorry James .. I mis-remembered what was going on for the Shale nightlies. Craig, is that script running from your account on the MyFaces zone? Yes. -- Wendy Craig
Re: How are Tiger Annotations enabled?
Hmm ... there are at least the following prerequisites for this to work: * The shale-view-xxx.jar file contains a tag library that, among other things, includes a listener declaration that sets up the basics and (if the Tiger extensions are also in the webapp) does the Tiger-specific stuff. Do you have this JAR in your webapp? If not, and you try adding it, does that make things work? (If this does the trick, then the problem is a result of the recent split-out of the view functionality ... we'll have to come up with an alternative approach that doesn't require shale-view). Yes I have shale-view in my app so its not that. * Does your JSF implementation (either MyFaces or the RI) initialize correctly without needing an explicit declaration in web.xml? This matters, because both implementations presume that the servlet container will do the spec-compliant thing of recognizing listeners declared in tag libraries. IIRC, this was a problem for older versions of Jetty, but I thought it had been addressed in later versions. This might be the issue. I'm not sure if a listener inside of a tag library works in Jetty. I'm guessing this is the problem. What if I explicitly declare the listener in web.xml? Would that work in this case? By the way, I'm using the latest JSF 1.2 RI b/c I want a few of the new 1.2 features. Craig Sean
[OT] Google Code Search
I just found out about this[1]. You can now search public SVN and CVS repositories. Pretty cool. Sean [1]http://www.google.com/codesearch
Re: svn commit: r465991 - in /shale/framework/trunk: shale-application/src/site/ shale-application/src/site/xdoc/ shale-apps/src/site/ shale-clay/src/site/ shale-core/src/site/ shale-remoting/src/site
Nice work. The website is much improved! On 10/20/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/19/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/19/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: NOTE -- I am not deleting the now-obsolete feature-xxx.xml pages yet ... that needs to be coordinated with installing redirects on the website so that the existing links in the world do not get broken. Oops... I already deleted two of them last week without redirecting. OK, I've installed redirects (an .htaccess file in /www/shale.apache.org) for the application, dialog, remoting, test, tiger, and view subprojects. I'll delete the corresponding features files tomorrow, after verifying that the web site has been updated and correctly does the redirects. Craig -- Wendy
Release docs
We should probably make clear in the next release about how there is a new shale-application project and that you will need to change your pom.xml (to add a new dependency) and web.xml (to reflect the new listener package name). This tripped me up on my own app. Of course it was easy to fix since I knew these changes were in the works. Sean
Re: Shale-related Tiles 2 issue - solved but not pretty
Yes AFAIK the latest Tomahawk will work with the RI. I've been out of the loop on the mailing lists for a few weeks so I could be wrong on that though. Sean On 10/4/06, Greg Reddin [EMAIL PROTECTED] wrote: On Oct 3, 2006, at 7:01 PM, Gregg Leichtman wrote: I'm in the process of setting up to test this. I should have an answer to this by the end of the week. I was hoping not to have to move to the RI, because I wanted access to the MyFaces extensions. Sorry for my ignorance, but it seems like I've seen messages from people who are using the RI with MyFaces extensions like Tomahawk, etc. Have you tried that at all or have you maybe researched it more than me and found it to not be viable? Greg
Re: [PROPOSAL] Migrate Dialog2 Support From Sandbox To Framework
+1 On 9/29/06, Greg Reddin [EMAIL PROTECTED] wrote: +1 On Sep 28, 2006, at 8:41 PM, Craig McClanahan wrote: The work we've done on the dialog support in the sandbox is showing clear earmarks of success. We can now support 100% of the functionality that actually works in the original implementation, plus have addressed a number of outstanding bug and RFE issues (plus supported a few extra enhancements like programmatic starting of a dialog that were not explicitly mentioned in an issue). I think it is now time to incorporate the results of this effort back into the mainline trunk code. Specifically, I propose to do the following: * Eliminate the original org.apache.shale.dialog (and child packages) code from shale-core. Yes, this is pretty abrupt, but developers who only use the APIs we've exposed for application use will not be affected -- it only impacts those who are using APIs targeted for framework users, and those folks need to be more accomodating about API evolution. * Create new modules under frameworks as follows: - shale-dialog (copied from sandbox shale-dialog2 with package names (etc.) changed from org.apache.shale.dialog2 to org.apache.shale.dialog. - shale-dialog-basic (copied from sandbox shale-dialog2-legacy with packgae names (etc.) changed from org.apache.shale.dialog2.legacy to org.apache.shale.dialog.basic. - shale-dialog-scxml (copied from sandbox shale-dialog2-scxml with package names (etc.) changed from org.apache.shale.dialog2.scxml to org.apache.shale.dialog.scxml. * Update website content in a manner consistent with the refactoring proposal I just sent out. * If we accept the SCXML implementation, start a vote to accept Rahul as a Shale committer. As with the refactoring proposal, I've got some time available starting tomorrow night and through the weekend to devote to these changs, if there are no objections. Thoughts? Craig
Re: Shale home page
Not volunteering here but I definitely think we could streamline things so that its easier to navigate. IMO we have too much crammed onto that first page. sean On 9/25/06, Wendy Smoak [EMAIL PROTECTED] wrote: Someone on IRC brought up a good point about the Shale home page: We don't say what Shale *is* until 1/3 of the way down the page. I think the information in the paragraph that starts Thus, Shale is... belongs up at the top of the page. Thoughts? Volunteers to fix it? :) -- Wendy
Re: Objection to (part of) r440205
Craig,
I'm a little confused. What is the difference between returning null
and delegating to the wrapped navigation handler, which in the case of
the default implementation, will also return null? I guess in most
cases I can think of the dialog as the only thing that should be
handling navigation while the dialog is in progress. It seems to
violate the principals of delegation though. You are not giving
anyone else a chance to deal with the outcome. I will try to think of
another usecase that might convince you.
For now I guess I'm cool with you reverting it (we can always add it
back later.)
Sean
On 9/10/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 9/10/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
On 9/9/06, Craig McClanahan [EMAIL PROTECTED] wrote:
Sean's changes fo the dialog2 sandbox implementation in r440205 includes
the
following change that I object to:
---
shale/sandbox/shale-dialog2/src/main/java/org/apache/shale/dialog2/faces/Dialog2NavigationHandler.java
(original)
+++
shale/sandbox/shale-dialog2/src/main/java/org/apache/shale/dialog2/faces/Dialog2NavigationHandler.java
Mon Sep 4 16:52:55 2006
@@ -135,6 +135,9 @@
+ context + ' with navigation to viewId '
+ viewId + ');
}
+if (viewId == null) {
+original.handleNavigation(context, fromAction,
outcome);
+}
}
navigate(context, viewId);
My objection is on two grounds:
* Philosophically, navigation within a dialog should be self contained,
and attempts to navigate via an outcome not defined by the dialog
definition should be treated as an error condition. Otherwise, we're
going to find ourselves in situations when the actual navigation being
performed is non-deterministic ... it's based on what (if any) dialogs
called me as a subdialog, so I have to do a lot more searching to
find problems. It also makes static analysis of an application to
determine
whether all its outcome values are legal virtually impossible.
snip/
I'm in agreement with the above, and we cannot undermine the benefits
of static analysis -- we need that end-to-end approach from modeling
to generation to testing.
As a sidebar, there are practical considerations (such as global
navbars) that we should perhaps explore via sample dialogs in the
sandbox, and attempt to establish a set of best practice guidelines
for the same (such as mapping those to some end states?).
I've got a big chunk of time reserved this afternoon to focuson dialog2, and
examples are definitely on the list of things I want to work on. Besides
menus, another really common usecase I'd like to see us cover gracefully is
a popup window (which starts its own dialog instance, per our current
approach) that can gracefuly pull data from the dialog of the main page at
startup, and push data back again when the popup dialog finishes.
Although this particular change only delegates to the original
navigation handler if the last state executed returned null, the
stated justification for this action (delegate when we don't know
what the response means) does not match the reality here. In
particular, a null return from a state is a *deliberate* decision by
the dialog to stay on the current view id. That decision should be
respected.
snap/
I've always been seeing that change in light of Sean's earlier commit
r440216 [1]. This means that the legacy implementation returns null in
two cases, deliberately or on IllegalStateException in transition()
(which is masked into a null return).
The latter sounds like the wrong approach -- to be consistent with a self
contained paradigm for dialog definitions, it should really throw the
exception. Among the details to be addressed is documentation, and a
tightening up on the Javadoc contracts about exceptions and return values.
* Technically, this particular change doesn't look like it will accomplish
anything anyway, because it is not followed by a return statement.
Instead, control will fall through to the call to navigate() anyway.
snip/
Indeed.
-Rahul
[1] http://svn.apache.org/viewvc?view=revrevision=440216
Craig
Re: Can't seem to get Dialog2NavigationHandler working
OK the problem was with my h:commandLink. It was not nested inside a h:form and thus behaving weirdly. Tomahawk used to compensate for this by creating a dummy form but we found that caused problems with the RI. I do have a new problem, however, which is that it can't seem to find my dialog definitions (its telling me the dialog doesn't exist.) I created a new issue on this, SHALE-271 sean On 9/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 9/1/06, Sean Schofield [EMAIL PROTECTED] wrote: The nav handler is in fact declared and the classname seems correct to me. That was the first thing I checked. Have you run an actual dialog yet or are you still in the just getting things to compile stage? My focus so far has indeed been just getting to the compiles-clean stage. Getting it to actually work is definitely the next thing to do (and I'll be spending some time on this weekend). Sean Craig On 9/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 9/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I can't seem to get Dialog2NavigationHandler working properly (I'm using the 1.2 RI.) It appears that the faces-config.xml in the jar file is beaing read based on this: 2006-09-01 14:27:11,587 [main] INFO org.apache.myfaces.config.FacesConfigurator - Reading config jar:file:/D:/open-source/shale-goodies/shale-petstore/target/shale-petstore/WEB-INF/lib/shale- dialog2-1.0.4-SNAPSHOT.jar!/META-INF/faces-config.xml Unfortunately, it does not appear that the handleNavigation method is being called. I'm also using the 1.0.4-SNAPSHOT of core but with the decorated NavigationHandlers that shouldn't matter. Maybe its possible that the method is getting called and my IDE debugger isn't showing it. I know that this command link certainly isn't working: h:commandLink action=dialog2:Checkout Any ideas? It's probably a botched faces-config.xml file inside the shale-dialog2-xxx.jar file ... if the custom navigation handler isn't declared (or if the classname is wrong), it won't ever get invoked. I'll take a look. Sean Craig
Re: Can't seem to get Dialog2NavigationHandler working
Two things -- first, how recent are the bits you're using? I've been making *lots* of changes through yesterday (a fun way to spend the commercials while Oregon was whomping on Stanford :-), and the legacy implementation now works for me. I've also checked in a test app (shale-test-dialog2-legacy) into the sandbox. This webapp can be used manually to experiment (it even has a split-screen mode so you can play with two active dialogs in two different frames), plus it's got a basic system integration test (mvn -Pitest clean install) to run a couple of simple scenarios automatically. Next I'll see about doing something similar for the SCXML implementation. Yeah I realized you had made changes but only after I tried to check in and the file was no longer in SVN! No big deal, it was a minor change and I just copied and pasted it into the new location. BTW, I'm glad we renamed the Contexts interface - that was too confusing having both Context and Contexts. The second thing is that, at the moment, you have to explicitly declare your dialog configuration files in web.xml: context-param param-nameorg.apache.shale.dialog2.legacy.CONFIGURATION/param-name param-value/WEB-INF/dialog-config.xml/param-value /context-param On my list of corrections is making it recognize this default location automatically ... should be an easy fix. Yes this was the problem. The param name was still configured for the current dialog implementation. Craig Sean
Can't seem to get Dialog2NavigationHandler working
I can't seem to get Dialog2NavigationHandler working properly (I'm using the 1.2 RI.) It appears that the faces-config.xml in the jar file is beaing read based on this: 2006-09-01 14:27:11,587 [main] INFO org.apache.myfaces.config.FacesConfigurator - Reading config jar:file:/D:/open-source/shale-goodies/shale-petstore/target/shale-petstore/WEB-INF/lib/shale-dialog2-1.0.4-SNAPSHOT.jar!/META-INF/faces-config.xml Unfortunately, it does not appear that the handleNavigation method is being called. I'm also using the 1.0.4-SNAPSHOT of core but with the decorated NavigationHandlers that shouldn't matter. Maybe its possible that the method is getting called and my IDE debugger isn't showing it. I know that this command link certainly isn't working: h:commandLink action=dialog2:Checkout Any ideas? Sean
Re: Can't seem to get Dialog2NavigationHandler working
The nav handler is in fact declared and the classname seems correct to me. That was the first thing I checked. Have you run an actual dialog yet or are you still in the just getting things to compile stage? Sean On 9/1/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 9/1/06, Sean Schofield [EMAIL PROTECTED] wrote: I can't seem to get Dialog2NavigationHandler working properly (I'm using the 1.2 RI.) It appears that the faces-config.xml in the jar file is beaing read based on this: 2006-09-01 14:27:11,587 [main] INFO org.apache.myfaces.config.FacesConfigurator - Reading config jar:file:/D:/open-source/shale-goodies/shale-petstore/target/shale-petstore/WEB-INF/lib/shale- dialog2-1.0.4-SNAPSHOT.jar!/META-INF/faces-config.xml Unfortunately, it does not appear that the handleNavigation method is being called. I'm also using the 1.0.4-SNAPSHOT of core but with the decorated NavigationHandlers that shouldn't matter. Maybe its possible that the method is getting called and my IDE debugger isn't showing it. I know that this command link certainly isn't working: h:commandLink action=dialog2:Checkout Any ideas? It's probably a botched faces-config.xml file inside the shale-dialog2-xxx.jar file ... if the custom navigation handler isn't declared (or if the classname is wrong), it won't ever get invoked. I'll take a look. Sean Craig
Re: [dialog] Progress on weekend experiments
On 8/28/06, Craig McClanahan [EMAIL PROTECTED] wrote:
I've checked in some progress on my experiments with how we can improve the
Dialog functionality. Even though they're not done yet, they are far enough
along to want some feedback and to make them available for experimentation
and further development. This mail will serve as a record of my thinking so
far, so you can get a feel for why I took the approach I've taken so far.
Great. I think we should do more of this sandbox in progress type
stuff. Its easier to contribute your own ideas if the other person
hasn't nailed everything down yet.
Initially, I wanted to address two shortcomings and one expanded feature in
our current approach:
* Make it possible for a single user to have multiple active dialog
instances
(although limited to one per JSF view, per our discussion).
Great. I see this also handles the aborted dialog case (user closes
popup window.) Nicely done.
* Make it possible to programmatically start up a dialog instance, as well
as
start one with a prefix on a logical outcome.
This will be real nice. I see how the create method establishes a
context but will this work in a popup scenario? User clicks on a
Start dialog link and the dialog starts in a new popup window. I'm
thinking one could use a view controller for your pop up window and
call the necessary create method. Does the programmer need to find
the first page of the dialog on their own in this instance?
* Make it possible to plug in different state machine implementations
(i.e. Commons SCXML), perhaps with different detailed feature sets.
I nice to have bonus.
I have *not* tried to address synchronizing state when the user presses the
browser navigation buttons yet. One can of worms at a time :-). Rahul had
some comments earlier today on how SWF deals with this. Seam does something
similar, and we'll undoubtedly need to add functionality here later.
Don't worry. We're not going to solve this anytime soon.
To address these initial concerns, I focused first on abstracting out the
APIs that an application *using* the dialog feature should have to interact
with, and then providing generic integration for the navigation handler that
can start a new dialog, or operate an existing one. The guts of actually
processing the transitions, then, is delegated to a state-machine-specific
implementation. The key APIs are (so far) incredibly simple -- they are in
the shale-dialog2 module in the sandbox. There are two fundamental
interfaces:
org.apache.shale.dialog2.Context:
* Represents the current state of an active dialog instance (similar to
Status in the current implementation)
* One instance per active dialog, rather than one per user
* Cached in a o.a.s.dialog2.Contexts object stored in session scope (see
below)
in between requests
* Generic phase listener (o.a.s.dialog2.faces.Dialog2PhaseListener) is
responsible
for saving and restoring access to the right instance:
- Before render response, caches the identifier of the currently ative
instance
(if any) in the JSF component tree, as a generic attribute of the view
root.
- After restore view, pulls the dialog identifier out, grabs the cached
Context
instance from the session scope Contexts object, and exposes it as a
request
scope attribute under a well known key (dialog2 for the moment).
* As we did in the original impl, Context exposes a data property for the
app to
store whatever it wants. So, binding expressions work very similarly to
what they
did before (#{dialog2.data.name}), but with the bugfix that it is one
instance per view
instead of one instance per user.
* Contains an advance() method that can be called to have the state machine
work its
way through the transitions until it runs into a state that needs input
from the user (in
the terminology of the existing impl, that means when you hit a view
state). The advance
method returns the view id of the page to display, and a generic
navigation handler
implementation (o.a.s.dialog2.faces.Dialog2NavigationHandler) then does
the actual
JSF navigation. NOTE - this navigation handler is generally the only code
that should
call this method.
Context stuff looks good. I'm going to try creating a few dialogs
later tonight to actually test it out. Maybe even add some test
cases.
org.apache.shale.dialog2.Contexts:
The name confuses me. I would prefer to call it ContextManager or
something like that. IMO its too confusing (visually) to have Context
and Contexts. They are too similar looking and I find myself stopping
and saying Now which one is it again?
* Defined by a particular implementation as a session scoped managed bean
that is
stored under a well known key.
* Maintains a cache of Context instances for the current user, keyed by
dialog identifiers,
so we get the one-per-view capability.
* Includes a create() method so that you can programmatically start a dialog
instance.
The
Re: [dialog] Progress on weekend experiments
@Craig,
Two questions regarding your initial check in ...
1.) Why doesn't the navigation handler call render response after
setting the view? Is that something that is frowned upon? I noticed
the myfaces implementation does this (perhaps incorrectly.)
2.) Why does LegacyContext need a reference to Contexts? Its
currently not being used. No big deal - I know its the sandbox - but
did you have something in mind for this reference?
Off to create a few test dialogs. I will report back shortly.
Sean
On 8/31/06, Sean Schofield [EMAIL PROTECTED] wrote:
On 8/28/06, Craig McClanahan [EMAIL PROTECTED] wrote:
I've checked in some progress on my experiments with how we can improve the
Dialog functionality. Even though they're not done yet, they are far enough
along to want some feedback and to make them available for experimentation
and further development. This mail will serve as a record of my thinking so
far, so you can get a feel for why I took the approach I've taken so far.
Great. I think we should do more of this sandbox in progress type
stuff. Its easier to contribute your own ideas if the other person
hasn't nailed everything down yet.
Initially, I wanted to address two shortcomings and one expanded feature in
our current approach:
* Make it possible for a single user to have multiple active dialog
instances
(although limited to one per JSF view, per our discussion).
Great. I see this also handles the aborted dialog case (user closes
popup window.) Nicely done.
* Make it possible to programmatically start up a dialog instance, as well
as
start one with a prefix on a logical outcome.
This will be real nice. I see how the create method establishes a
context but will this work in a popup scenario? User clicks on a
Start dialog link and the dialog starts in a new popup window. I'm
thinking one could use a view controller for your pop up window and
call the necessary create method. Does the programmer need to find
the first page of the dialog on their own in this instance?
* Make it possible to plug in different state machine implementations
(i.e. Commons SCXML), perhaps with different detailed feature sets.
I nice to have bonus.
I have *not* tried to address synchronizing state when the user presses the
browser navigation buttons yet. One can of worms at a time :-). Rahul had
some comments earlier today on how SWF deals with this. Seam does something
similar, and we'll undoubtedly need to add functionality here later.
Don't worry. We're not going to solve this anytime soon.
To address these initial concerns, I focused first on abstracting out the
APIs that an application *using* the dialog feature should have to interact
with, and then providing generic integration for the navigation handler that
can start a new dialog, or operate an existing one. The guts of actually
processing the transitions, then, is delegated to a state-machine-specific
implementation. The key APIs are (so far) incredibly simple -- they are in
the shale-dialog2 module in the sandbox. There are two fundamental
interfaces:
org.apache.shale.dialog2.Context:
* Represents the current state of an active dialog instance (similar to
Status in the current implementation)
* One instance per active dialog, rather than one per user
* Cached in a o.a.s.dialog2.Contexts object stored in session scope (see
below)
in between requests
* Generic phase listener (o.a.s.dialog2.faces.Dialog2PhaseListener) is
responsible
for saving and restoring access to the right instance:
- Before render response, caches the identifier of the currently ative
instance
(if any) in the JSF component tree, as a generic attribute of the view
root.
- After restore view, pulls the dialog identifier out, grabs the cached
Context
instance from the session scope Contexts object, and exposes it as a
request
scope attribute under a well known key (dialog2 for the moment).
* As we did in the original impl, Context exposes a data property for the
app to
store whatever it wants. So, binding expressions work very similarly to
what they
did before (#{dialog2.data.name}), but with the bugfix that it is one
instance per view
instead of one instance per user.
* Contains an advance() method that can be called to have the state machine
work its
way through the transitions until it runs into a state that needs input
from the user (in
the terminology of the existing impl, that means when you hit a view
state). The advance
method returns the view id of the page to display, and a generic
navigation handler
implementation (o.a.s.dialog2.faces.Dialog2NavigationHandler) then does
the actual
JSF navigation. NOTE - this navigation handler is generally the only code
that should
call this method.
Context stuff looks good. I'm going to try creating a few dialogs
later tonight to actually test it out. Maybe even add some test
cases
Re: [dialog] Using SCXML to describe Shale dialogs
I have few initial concerns after looking over the excellent documentation and examples on the Commons SCXML site. So far, my concerns are as follows: 1.) I'm not wild about having to run an XSL transform on dialogs during compile time but the SCXML approach to configuring dialogs seems to involve excessive XML if you're not using UML. Don't get me wrong. Its a very cool concept but I'm not sure going from UML to dialog config is the most important feature in a dialog solution. 2.) Each dialog needs its own SCXML file. In one extreme use case where you have a ten step dialog and you want to have individual single step dialogs for each of ten steps, you'd need 11 SCXML files. 3.) Global transitions need to be configured in each of the SCXML files (is that right?) While I realize these should be ideally coming from the UML, the reality is a lot of people will not be using SC to design their dialogs. I haven't made up my mind on SCXML - in fact I seem to be swinging back and forth. Even if we don't go with it right away, I think it merits further study (and a place in our sandbox.) I'm curious as to what others think. Sean On 8/24/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/24/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ Yes, the UML notation on a transition is: event[guard_condition] Simply put, the states that have faces.outcome listed as the event are view states (wait for the postback event) and the others are action states. snap/ Sorry, the above should read: ... the states that have faces.outcome listed as the event *on outbound transitions* are view states ... -Rahul You can skip the event, the guard condition or both on a transition. Eventless transitions get evaluated as soon as executable content onentry for that state is done. The symbol and text label under the checkCookie state label implies execute that method binding expression on entering the state (which gives us the logical outcome to choose the outbound transition). -Rahul
Re: [dialog] className attribute
@Sean - I take it you are using this attribute? Any ideas here? Can you please explain (again) how you use it? There may be other ways to achieve the desired results, from an SCXML PoV. Ofcourse, that will only be applicable for new applications. Basically there were a bunch of shortcoming in Shale dialog (many of which we are talking about addressing now) so I had need to subclass DialogImpl with my own class. The configuration stuff that shipped with shale assumed that your dialogs would be the DialogImpl class which was inconvenient. So following the DRY principle, I asked Craig to patch in the classname attribute so that users could take advantage of the digester rules, etc. I would say this would be a useful feature to have in any future direction of Shale dialogs. The fact that Dialog is an interface would suggest its expected that users might provide their own impl. It would suck for users to have to provide their own configuration when the default one was 99.9% sufficient. -Rahul Sean
Re: [dialog] How to use a common view with different dialog managed beans?
I think Paul was commenting on an earlier idea that I had about
scrapping #{dialog.data} in favor of a managed bean type solution. If
I'm reading his message correctly he raises some good points. I think
we're past that idea now though in favor of keeping #{dialog.data} but
no longer blowing away the context when entering a subdialog.
Sean
On 8/25/06, Paul Spencer [EMAIL PROTECTED] wrote:
Rahul,
This was not a how to do I do this question. It was in reference to
the current Dialog Manager design effort.
Paul Spencer
Rahul Akolkar wrote:
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/25/06, Paul Spencer [EMAIL PROTECTED] wrote:
An advantage with the current dialog.data bean is that it allows a the
use of a common view when the underlying data objects are different.
How
would this be done with dialog managed beans?
As an example the AbstractPayment class has a CreditCard and a Check
implementation. Both the Pay By Check and Pay by CreditCard
share a
common view that collects the billing address information. In the
current implementation, that view uses #{dialog.data.billingZipCode} to
pass the billing zip code regardless of the actual class. With dialog
managed beans their will be a check and creditCard bean so how would
the
billing zip code be referenced in the common view? So unless their
is a
way to alias the beans in the dialog configuration, the billing address
view can not be shared.
You are limited to a single instance of #{dialog.data}, but that bean
itself
can have properties that are, in fact , beans ... and you can nest as
deeply
as you like. So, your Payment class (the one you use as the data bean
for
one of the processes could have a property of type AddressBean, and you
could therefore have binding expressions like
#{dialog.data.address.zipCode}
to talk to it. The only collaboration that would be needed here is
that all
of the 'outer data beans that used an AddressBean would need to store it
under the same property name. You don't have to worry if the type of the
data bean is different, because the EL machinery takes care of all
of that
for you.
snip/
And IIU your class diagram correctly, having the zip in the
AbstractPayment automatically takes care of this. All you would then
need to do is populate #{dialog.data} with either the CreditCard or
the Check bean via the setup action state in the corresponding
dialog.
-Rahul
Paul Spencer
Craig
Re: Review Core JSF coverage of Shale dialogs?
When's the book supposed to be published? For those who are anxious to learn JSF and can't wait for the 2nd edition, I suggest you get the first edition now! I wish I had it way back when I was first trying to understand JSF. I'm happy to review the whole book if you need a reviewer. Sean On 8/24/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: David Geary [EMAIL PROTECTED] Would anyone like to review material on Shale dialogs from the upcoming 2nd ed of Core JSF (about 15 pages)? I have an example with a Bill Pay dialog that has a Wire Transfer subdialog. The data entered into the subdialog is incorporated into the enclosing dialog's data, so it's pertinent to our current dialog discussion. I'd love to review this section or pretty much any chapter :--) david Gary
Re: [Invitation To Design Discussion] - The Shale Dialog Manager Feature
I'm ready to start contributing. Craig already has a pretty good start on the wiki. My plan is to add a few features ideas to the wiki and also to post those features ideas here for discussion. Sean On 8/23/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/21/06, Craig McClanahan [EMAIL PROTECTED] wrote: If you have tried out the dialog manager feature of Shale, you're probably well aware that it has some limitations and bugs. Indeed, I see improving this as the most important thing to tackle next. In reviewing the outstanding bug reports, it looks like we will need to rearchitect the current implementation. That means now is a good opportunity to review the requirements that the feature tries to meet, as well as evaluate a few implementation approaches, before we tackle the code itself. To that end, I've set up a wiki page[1] where we'll accumulate current thinking. snip/ Great, this interests me quite a bit :-) I'll make some comments on there later today or tomorrow. Not sure what the protocol is here, for user comments, but I'll prefix with [Rahul] for some such, for good measure. -Rahul [1] http://wiki.apache.org/shale/DialogManagerFeature [2] http://shale.apache.org/mail-lists.html
Re: Handling JIRA issues tagged with 1.0.3-SNAPSHOT
Isn't this the same set of issues you just changed to Unknown in step 2? If so, how do you find them again? Step 2 is *unresolved* issues. Basically you don't want any issues to be on a 1.0.3-SNAPSHOT roadmap since there is no such thing anymore. So you change the fix version to unknown and reschedule these issues manually at some future point. This is just common sense which is why we didn't have to do this for any issues when I did a search just to make sure. Craig Sean
Re: Nightly build problem
Everything seems to be builidng correctly now. Initially I was also having trouble building locally so I think it was an issue with ibiblio. Sean On 8/20/06, Sean Schofield [EMAIL PROTECTED] wrote: It seems like there is a problem with the nightly builds[1.] From the logs it looks like a permissions issue. I will investigate when I get a chance. Sean [1] http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/Summary.vm/fid/continuumProject
Re: [VOTE] Shale Version 1.0.3 Release
+1 (Binding) On 8/20/06, Craig McClanahan [EMAIL PROTECTED] wrote: At long last :-), the bits are ready for a vote. All of the following files have md5 and sha1 checksums, and are in addition signed by my code signing key. They correspond to revision 433108 in the SVN repository, which I'm about to tag as APACHE_SHALE_1_0_3. (1) Maven Snapshot Repository At Apache: (http://people.apache.org/repo/m2-snapshot-repository) org.apache.shale.extras:mailreader-jpa:1.0.3 org.apache.shale:shale-apps-parent:1.0.3 org.apache.shale:shale-clay:1.0.3 org.apache.shale:shale-core:1.0.3 org.apache.shale:shale-dist:1.0.3 org.apache.shale:shale-parent:1.0.3 org.apache.shale:shale-remoting:1.0.3 org.apache.shale:shale-spring:1.0.3 org.apache.shale:shale-test:1.0.3 org.apache.shale:shale-tiger:1.0.3 org.apache.shale:shale-tiles:1.0.3 (If you have tested previous test builds of 1.0.3, you'll need to clear your local m2 repository to pick up these bits) (2) Release Artifacts (http://people.apache.org/~craigmcc/shale-proposed-release-1.0.3/) mailreader-jpa-1.0.3.zip shale-blank-1.0.3.zip shale-clay-usecases-1.0.3.zip shale-framework-1.0.3.zip shale-mailreader-1.0.3.zip shale-mailreader-jpa-1.0.3.zip shale-sql-browser-1.0.3.zip shale-usecases-1.0.3.zip (3) Vote Please review these artifacts, and test their signatures, then vote on whether we should release them as Apache Shale version 1.0.3. If it passes we'll hold a quality vote later on. [ ] +1 (Binding) for PMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released My vote is +1 (Binding) Craig McClanahan
Re: Handling JIRA issues tagged with 1.0.3-SNAPSHOT
I'll take care of this and update the wiki with the steps necessary. Sean On 8/21/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/21/06, Craig McClanahan [EMAIL PROTECTED] wrote: * Create a new version 1.0.3 * Bulk change of issues tagged 1.0.3-SNAPSHOT to 1.0.3, turning off email notification * Remove the old 1.0.3-SNAPSHOT version. I think you can just change the description of 1.0.3-SNAPSHOT to 1.0.3. Sean? -- Wendy
Re: Handling JIRA issues tagged with 1.0.3-SNAPSHOT
I took care of everything. Here are the steps for our future release template wiki. NOTE: We still need a meaningful description and release date for the new 1.0.3 version. 1.) Create a new JIRA version for the release (ex. 1.0.3) 2.) Search and then bulk change unresolved issues with a fix for of the old snapshot version (ex. 1.0.3-SNAPSHOT) and change to Unknown. At this point in the process, there shouldn't be any issues left on the roadmap but do a search (and bulk change) if necessary. For all bulk changes be sure to uncheck the Send mail for this update option on Step 3. 3.) Search and then bulk change resolved issues with a fix for of the old snapshot version (ex. 1.0.3-SNAPSHOT) and change to the new version (ex. 1.0.3). For all bulk changes be sure to uncheck the Send mail for this update option on Step 3. 4.) Archive the old version. This allows you to still search on issues that were *reported* against a SNAPSHOT version yet it prevents you from reporting new issues against the SNAPSHOT. Sean On 8/21/06, Sean Schofield [EMAIL PROTECTED] wrote: I'll take care of this and update the wiki with the steps necessary. Sean On 8/21/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/21/06, Craig McClanahan [EMAIL PROTECTED] wrote: * Create a new version 1.0.3 * Bulk change of issues tagged 1.0.3-SNAPSHOT to 1.0.3, turning off email notification * Remove the old 1.0.3-SNAPSHOT version. I think you can just change the description of 1.0.3-SNAPSHOT to 1.0.3. Sean? -- Wendy
Re: Test 1.0.3 Artifacts (Round 2)
We can tweak the procedure next time ... but for this time I'm going to try to role the final set of bits to propose for the vote this evening. Can we please hold up on commits until after I finish that, tag it, and update the POMs for 1.0.4-SNAPSHOT? That will work. Craig Sean
Re: Tiger (annotations) + Facelets
)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:615)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:150)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle(Server.java:272)
at
org.mortbay.jetty.HttpConnection.handlerRequest(HttpConnection.java:402)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:648)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:488)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:198)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:317)
at
org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
/snip
On 8/8/06, Sean Schofield [EMAIL PROTECTED] wrote:
Facelets and Tiger annotations work fine for me. I'm not using the
view controller stuff yet (@Init) but @Bean and @Property work fine
for me. As soon as I finish refactoring for the new package names I
will check into shale-goodies.
Sean
On 8/7/06, Sean Schofield [EMAIL PROTECTED] wrote:
I'm about to add the annotations stuff to my petstore app (which uses
facelets) so I will let you know what I find shortly.
Sean
On 8/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
not only @Bean(...)
also
@Init
public void myInit() {
System.out.println(getClass());
_name = FUNKY DJ!;
}
is not working
On 8/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
hi,
anybody used Tiger w/ Facelets?
I get (in Jetty6)
javax.faces.el.PropertyNotFoundException: /index.xhtml @23,102
value=#{helloWorldBacking.name}: Target Unreachable, identifier
'helloWorldBacking' resolved to null
at
com.sun.facelets.el.LegacyValueBinding.isReadOnly(LegacyValueBinding.java:84)
thx
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Confluence Wiki Anyone?
So there would be 2 wikis? One for official documenation (confluence) and one for community based documentation (current)? To me the current Shale website is a bit overwhelming with information. I like the idea of moving all of the getting started docs to confluence and organizing them by subproject. We just need a prominent link on the main page to direct users to. The Getting Started link seems to be a growing trend and its the first thing I look for when I start with a new technology. -1 for separate confluence wikis for each version. I think we can add version-appropriate notes where needed and keep stuff in one wiki. Maybe separate sections for each version if there are major installation gotchas but definitely not a separate wiki. For release plans, I definitely think a separate page for each version would be fine. Sean On 8/9/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Confluence as documentation is excellent. We've moved all of the Apache Podling Cayenne's documentation to Confluence over the last year or so. Just be aware that infrastructure frowns on using Confluence for anything other than a static website (or document) generator (for example, using it as a general purpose wiki) because of technical issues with Confluence. On 8/9/06, Greg Reddin [EMAIL PROTECTED] wrote: On Aug 8, 2006, at 7:00 PM, Wendy Smoak wrote: The space naming convention would probably give us SHLx___ Do we want to have just one space, and use it like we use Moin, or do we want to push most of the project docs to the wiki? I don't know anything about Confluence so I can't comment on its usability or features, but I *love* the idea of using a wiki for doc. It's so much easier to contribute to. In the second case we might want SHLxDEV for our notes on how to use Maven and Subversion for various things, and another one for docs that get exported and included in the distribution. I'm ok with that so long as we don't make it too hard for people to know where to contribute or look for info. Greg
Re: Confluence Wiki Anyone?
Another topic of concern was allowing people who have not been granted committer status the ability to edit the official documentation for a project. We could limit this to just committers like we do now for the website (where the docs are now.) Ideally we could add people by invitation and this could be a stepping-stone to becoming a committer. Sean
Re: Confluence Wiki Anyone?
On the other hand, anyone I am willing to trust with the web content is also someone I would trust with repository access :-). We should probably stick to the current Apache way whenever possible. Its not worth adding such a distinction if it gets us sidetracked from our main business. Better to add a few new committers who have demonstrated competence in Shale and expressed an interest in helping with the documentation. Craig Sean
Re: Tiger (annotations) + Facelets
Facelets and Tiger annotations work fine for me. I'm not using the
view controller stuff yet (@Init) but @Bean and @Property work fine
for me. As soon as I finish refactoring for the new package names I
will check into shale-goodies.
Sean
On 8/7/06, Sean Schofield [EMAIL PROTECTED] wrote:
I'm about to add the annotations stuff to my petstore app (which uses
facelets) so I will let you know what I find shortly.
Sean
On 8/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
not only @Bean(...)
also
@Init
public void myInit() {
System.out.println(getClass());
_name = FUNKY DJ!;
}
is not working
On 8/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
hi,
anybody used Tiger w/ Facelets?
I get (in Jetty6)
javax.faces.el.PropertyNotFoundException: /index.xhtml @23,102
value=#{helloWorldBacking.name}: Target Unreachable, identifier
'helloWorldBacking' resolved to null
at
com.sun.facelets.el.LegacyValueBinding.isReadOnly(LegacyValueBinding.java:84)
thx
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: SHALE-219 -- Still want it for 1.0.3?
1.0.3 is going to be another alpha/beta release right? We still need to fix the dialog issues such as SHALE-48 before we go legit right? I'm assuming the goal is to have a solid 1.0.4 release just before Apache Con no? If so, then I imagine we're going to be busy in September. My personal roadmap will involve helping Craig to resolve the dialog problems and getting a nice version of shale-petstore ready. That plus my day job will keep me busy these next few weeks. Sean On 8/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: This issue[1] is the last functionality related one flagged in JIRA for 1.0.3. Do we still want to do it first, or can we target that for a later release and move on towards getting 1.0.3 out the door now? Craig [1] http://issues.apache.org/struts/browse/SHALE-219
Re: Tiger (annotations) + Facelets
I'm about to add the annotations stuff to my petstore app (which uses
facelets) so I will let you know what I find shortly.
Sean
On 8/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
not only @Bean(...)
also
@Init
public void myInit() {
System.out.println(getClass());
_name = FUNKY DJ!;
}
is not working
On 8/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
hi,
anybody used Tiger w/ Facelets?
I get (in Jetty6)
javax.faces.el.PropertyNotFoundException: /index.xhtml @23,102
value=#{helloWorldBacking.name}: Target Unreachable, identifier
'helloWorldBacking' resolved to null
at
com.sun.facelets.el.LegacyValueBinding.isReadOnly(LegacyValueBinding.java:84)
thx
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
Yep. What we would need to know is the from address on the commit emails, so we know what address to subscribe. I changed the email from public to moderated so I could discover the sender: [EMAIL PROTECTED] You'd think Google would have figured this stuff out already :-). Yes but its a work in progress so we will let it slide. I suspect we want minimal barriers to participation here, so I'd throw it open. We can change things later if we get too much spam etc. Google is warning about spam if you leave it wide open but I guess we can deal with that when the time comes. In particular, we should set the group to accept public email (it took my test message submitted via the web interface, but not the one I emailed from my gmail account). That should at least make the commit emails work, so we can see what the right from address is. That's weird taht you could only send email from your interface. Can you send again from your gmail account to test if its moderated or not? I changed you to owner as well so you can have the dubious honor of assisting in the group management. Go ahead an change it to wide open public email once you test your gmail again. Craig Sean
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
Lets think on the package names a bit. OK. What about just org.shale? So for petstore we have org.shale.petstore as the package name with org.shale as the maven group name. Craig Sean
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
The only problem with com.google is if we move it from being hosted on google.com (a distinct possibility at this point.) Sean On 8/4/06, Greg Reddin [EMAIL PROTECTED] wrote: I think I prefer that too. shale.org doesn't appeal to me for some reason I can't really put my finger on. Greg On Aug 4, 2006, at 2:03 PM, James Mitchell wrote: I prefer com.google.shalegoodies Your thoughts? -- James Mitchell 678.910.8017 On Aug 4, 2006, at 11:30 AM, Sean Schofield wrote: Lets think on the package names a bit. OK. What about just org.shale? So for petstore we have org.shale.petstore as the package name with org.shale as the maven group name. Craig Sean
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
shale.goodies.petstore ? I like it except for one problem. What is the maven group id? If it starts with shale, people browsing ibiblio might get confused and wonder where the rest of the stuff is? Wendy Sean
Wikipedia: More Licensing Questions
Anyone know if we can we use photos and descriptions from the wikipedia for the petstore example? Sean
Re: Wikipedia: More Licensing Questions
Most of the images seem to be: GNU Free Documentation License, Version 1.2. What about the text? Any ideas on that? Sean On 8/3/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote: Anyone know if we can we use photos and descriptions from the wikipedia for the petstore example? Looks like it depends on the image: http://en.wikipedia.org/wiki/Wikipedia:Image_copyright_tags -- Wendy
Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
I'm considering an option that Craig mentioned earlier - moving this to google's new open source area. While I understand the reasons for the tight restrictions that ASF has, it makes it difficult to host a fully functional sample app using several different technologies. On google (and presumably dev.java.net), we can also distribute binaries wither hibernate, etc. That will allow more people to use the app. No matter how easy you make it, some people are just putoff by compiling their own source. I admit, sometimes I fall into this category (if my interest is only casual.) If we do move it, I'd still like some loose integration between shale and this project. This would include links to the shale-petstore from the shale site and referring people on the user list to the shale-petstore when it serves as an appropriate example. Thoughts? Sean On 8/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/3/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote: Most of the images seem to be: GNU Free Documentation License, Version 1.2. What about the text? Any ideas on that? Are you asking about the text on Wikipedia? There's a notice at the bottom of every page: All text is available under the terms of the GNU Free Documentation License. As for whether we can use the text or images, if GFDL is not listed on Cliff's page [1] then I would ask on [EMAIL PROTECTED] I suspect the GNU license for docs will have issues, so asking on legal-discuss would be a good idea. In the mean time, note that the original Blueprints PetStore application (including content and images) is BSD-licensed, so we can use stuff from there. https://blueprints.dev.java.net) Craig [1] http://people.apache.org/~cliffs/3party.html -- Wendy
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
I'm ok with shale-goodies as long as we can release artifacts as different versions, etc. I'm assuming that's the case. I think we're all curious about the google option so lets go ahead with it. We can always move it in a few months if it doesn't pan out. Right now there;s just shale-petstore and it wouldn't be the end of the world to lose the svn history if we had to move it. my gmail is sean.schofield Sean ps. Google is also doing something cool which is allowing you to host your domain email through them. There is a beta test going on and they accepted my application. Something to consider for folks who have their own domain for business purposes. On 8/3/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: The only difference between project owner and project member is access to the admin screens for the project itself. Both have commit rights. I'll set you as a member if you want just that. I didn't know that was an option. Just 'member' will be fine for me, too. Thanks, Wendy
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
Any reason why we can't use org.apache.shale for the package names still? I can't really think of a better package name off hand. Sean On 8/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote: I'm ok with shale-goodies as long as we can release artifacts as different versions, etc. I'm assuming that's the case. I think we're all curious about the google option so lets go ahead with it. We can always move it in a few months if it doesn't pan out. Right now there;s just shale-petstore and it wouldn't be the end of the world to lose the svn history if we had to move it. I set up a maven/trunk/master-pom analogous to what we have in the Apache repository ... you could set up shale-petstore/trunk to make it independently branchable and so on. We could even set up a current externals later. We'll have to think about the package names (and Maven artifact ids) here ... I used shale-goodies:shale-goodies:1-SNAPSHOT for the initial master pom, but haven't checked in any code yet. my gmail is sean.schofield Added. Sean ps. Google is also doing something cool which is allowing you to host your domain email through them. There is a beta test going on and they accepted my application. Something to consider for folks who have their own domain for business purposes. That is pretty cool. Craig
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
Lets think on the package names a bit. I set up a google group for us. I tried adding the svn commit messages to the group but I'm not sure that's possible. Maybe we just add each commiter manually as we go? Sean On 8/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote: Any reason why we can't use org.apache.shale for the package names still? I can't really think of a better package name off hand. Using org.apache.shale.x would seem to create a false perception that the goodies were actually a formal part of the Shale project, and would contradict the project description claim in that regard. We should use goodies or shalegoodies or something like that. Sean Craig On 8/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote: I'm ok with shale-goodies as long as we can release artifacts as different versions, etc. I'm assuming that's the case. I think we're all curious about the google option so lets go ahead with it. We can always move it in a few months if it doesn't pan out. Right now there;s just shale-petstore and it wouldn't be the end of the world to lose the svn history if we had to move it. I set up a maven/trunk/master-pom analogous to what we have in the Apache repository ... you could set up shale-petstore/trunk to make it independently branchable and so on. We could even set up a current externals later. We'll have to think about the package names (and Maven artifact ids) here ... I used shale-goodies:shale-goodies:1-SNAPSHOT for the initial master pom, but haven't checked in any code yet. my gmail is sean.schofield Added. Sean ps. Google is also doing something cool which is allowing you to host your domain email through them. There is a beta test going on and they accepted my application. Something to consider for folks who have their own domain for business purposes. That is pretty cool. Craig
Re: Should we move shale-petstore somewhere else? Was -- Re: Wikipedia: More Licensing Questions
Well the email list is not public atm. That's probably the problem. We could create a shell gmail account for the svn emails and have that same account subscribed to the group. Then set up forwarding. That should work. Which brings us to the issue of the list permissions. One option is to require the moderator approval to join the list (I believe that's what its set to now.) We could rubber stamp people who want to join but also remove them if they're acting like assholes. Or just let the floodgates open. The problem with the open flood gate approach is that it would be hard to switch back to the other model if we changed our mind. I'm not sure where I stand on this. What does the rest of the group think? Sean On 8/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote: Lets think on the package names a bit. OK. I set up a google group for us. I tried adding the svn commit messages to the group but I'm not sure that's possible. Maybe we just add each commiter manually as we go? Hmm ... looks like you have it set up right ... maybe commit mail isn't working yet. It also looks like we can only have one destination address for the commits. Sean Craig On 8/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote: Any reason why we can't use org.apache.shale for the package names still? I can't really think of a better package name off hand. Using org.apache.shale.x would seem to create a false perception that the goodies were actually a formal part of the Shale project, and would contradict the project description claim in that regard. We should use goodies or shalegoodies or something like that. Sean Craig On 8/3/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote: I'm ok with shale-goodies as long as we can release artifacts as different versions, etc. I'm assuming that's the case. I think we're all curious about the google option so lets go ahead with it. We can always move it in a few months if it doesn't pan out. Right now there;s just shale-petstore and it wouldn't be the end of the world to lose the svn history if we had to move it. I set up a maven/trunk/master-pom analogous to what we have in the Apache repository ... you could set up shale-petstore/trunk to make it independently branchable and so on. We could even set up a current externals later. We'll have to think about the package names (and Maven artifact ids) here ... I used shale-goodies:shale-goodies:1-SNAPSHOT for the initial master pom, but haven't checked in any code yet. my gmail is sean.schofield Added. Sean ps. Google is also doing something cool which is allowing you to host your domain email through them. There is a beta test going on and they accepted my application. Something to consider for folks who have their own domain for business purposes. That is pretty cool. Craig
Upgraded MyFaces Dependency to 1.1.4-SNAPSHOT
I changed the MyFaces dependency in Shale to 1.1.4-SNAPSHOT. Tomahawk 1.1.4-SNAPSHOT (used by the new shale-petstore) will not work properly using the old 1.1.1 dependency. Please rebuild the shale framework before attempting to build shale-petstore or you will inject the old 1.1.1 jars into the webapp and break it. There are ways around this but I think we should be upgrading to the latest MyFaces stuff. 1.1.4 is supposedly close to release at this point. Sean
[petstore] Need Hibernate Help
I checked in the beginnings of the shale-petstore app. Unfortunately hibernate is giving me some weird results. I have a category: dogs and a subcategory: terriers. When asking for the inventory, Hibernate is giving me back the correct hiearchy, plus an additional top level node for terriers. This additional top level node is not correct. Can anyone take a look and see what's going on here? I've been staring at this for a while and the answer eludes me. I have checked the mapping from service and that part seems to be working fine. So I think its either Hibernate, or the manual association stuff I am doing in my domain objects. TIA, Sean
Re: svn commit: r427223 - /shale/sandbox/shale-petstore/pom.xml
According to the facelets site (section 1.2) the EL RI is also needed for facelets[1]. That's probably why I am getting the following stack trace: SEVERE: Error Rendering View[/welcome.xhtml] com.sun.facelets.FaceletException: Could not instantiate feature[compiler.ExpressionFactory]: com.sun.el.ExpressionFactoryImpl at com.sun.facelets.compiler.Compiler.featureInstance(Compiler.java:153) at com.sun.facelets.compiler.Compiler.createExpressionFactory(Compiler.java:127) at com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:193) ... I must have hard-copied that dep into the project and now that I'm using maven its not working. Sean [1] https://facelets.dev.java.net/nonav/docs/dev/docbook.html On 7/31/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 7/31/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: schof Date: Mon Jul 31 12:30:46 2006 New Revision: 427223 URL: http://svn.apache.org/viewvc?rev=427223view=rev Log: changed JSF dep to RI; added jsp-2.1 api dp (still need to get the EL dependency added) I asked about this issue internally, and here's the answer I got: as of JSP 2.1, the new unified EL APIs are still part of the JSP specification, so the classes themselves are supposed to be in the jsp-api jar that your new dependency references. If/when the unified EL classes are separated into their own JSR (probably in some future maintenance rev of the JSP spec) they will be split out into their own JAR and published separately. Craig
Re: svn commit: r427223 - /shale/sandbox/shale-petstore/pom.xml
Well the api seems to be solved by including the jsp 2.1 dependency. Unfortunately the EL-RI needs to be grabbed from the glassfish project and installed manually. Perhaps we can get Sun to make that available in ibiblio? Sean On 7/31/06, Greg Reddin [EMAIL PROTECTED] wrote: On Jul 31, 2006, at 3:16 PM, Sean Schofield wrote: According to the facelets site (section 1.2) the EL RI is also needed for facelets[1]. That's probably why I am getting the following stack trace: I was able to find the el-api JAR on a java.net maven repo, but I couldn't find the ri JAR anywhere. For our project we set up an internal maven repo that contains those JAR files until they put them in a public place. Greg
Re: [petstore] Need Hibernate Help
I *finally* fixed this problem.
The problem was with the query. The correct query should be:
public ListCategory getCategories() {
return getHibernateTemplate().find(from Category category
where category.parentCategory is null);
}
The where clause is needed to weed out categories with a parent
category. Since I'm constructing a tree, I just want the top level
and then lazily grab the rest as we go.
Sean
On 7/31/06, Sean Schofield [EMAIL PROTECTED] wrote:
I've got the maven build working (once you install the el-ri.jar in
your maven repo.) But I decided to post the key ingredients of the
problem here for those who don't want to get this running locally.
I switched for the in memory hypersonic db to mysql just so I could
visually inspect the data to make sure it conformed to my
expectations. I was suprised to see that the data was being stored
correctly so maybe there is a problem with my hb query?
1.) Test data is created using the following:
Category dogs = new Category(Dogs);
Category terriers = new Category(Terriers);
dogs.addChildCategory(terriers);
categoryDao.store(dogs);
2.) Data is mapped as follows:
hibernate-mapping package=org.apache.shale.petstore.domain
class name=org.apache.shale.petstore.domain.Category
id name=id
column=CATEGORY_ID
generator class=native/
/id
property name=description/
set name=pets
table=PET
inverse=true
cascade=all-delete-orphan
key column=CATEGORY_ID/
one-to-many class=Pet/
/set
set name=childCategories
table=CATEGORY
inverse=true
cascade=all-delete-orphan
key column=PARENT_CATEGORY_ID/
one-to-many class=Category/
/set
many-to-one
name=parentCategory
column=PARENT_CATEGORY_ID
class=Category
cascade=none/
/class
/hibernate-mapping
3.) Category domain object looks like:
public class Category implements Serializable {
private SetCategory childCategories = new LinkedHashSetCategory();
private SetPet pets = new HashSetPet();
private Category parentCategory;
private String description;
private Long id;
public Category(String description) {
this.description = description;
}
public Category() {}
public void setDescription(String description) {
this.description = description;
}
public String getDescription() {
return description;
}
public SetCategory getChildCategories() {
return childCategories;
}
// Private accessor method provided for use in Hibernate
private void setChildCategories(SetCategory childCategories) {
this.childCategories = childCategories;
}
public void addChildCategory(Category childCategory) {
if (childCategory == null)
throw new IllegalArgumentException(Null child category);
if (childCategory.getParentCategory() != null)
childCategory.getParentCategory().getChildCategories().remove(childCategory);
childCategory.setParentCategory(this);
childCategories.add(childCategory);
}
public SetPet getPets() {
return pets;
}
// Private accessor method provided for use in Hibernate
private void setPets(SetPet pets) {
this.pets = pets;
}
public void addPet(Pet pet) {
if (pet == null)
throw new IllegalArgumentException(Null pet);
pet.changeCategory(this);
pets.add(pet);
}
public Category getParentCategory() {
return parentCategory;
}
public void setParentCategory(Category parentCategory) {
this.parentCategory = parentCategory;
}
// Private accessor method provided for use in Hibernate
private void setId(Long id) {
this.id = id;
}
public Long getId() {
return id;
}
public boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (!(obj instanceof Category)) {
return false;
}
Category rhs = (Category)obj;
return new EqualsBuilder()
.append(description, rhs.getDescription())
//.append(parentCategory, rhs.getParentCategory())
.isEquals();
}
public int hashCode() {
return new HashCodeBuilder(17, 47).
append(description).
//append(parentCategory).
toHashCode();
}
4.) Code to retrieve the object looks like:
public ListCategory getCategories() {
return getHibernateTemplate().find(from Category category);
}
Any ideas on this? Since the data is being stored correctly I have
three theories:
A.) Hibernate query is incorrect. The query above in #4 is so simple
this is hard to believe.
B.) The mapping is incorrect. Again, since the data is being written
to the db correctly this doesn't seem right
Re: [petstore] Need Hibernate Help
Well I need to get caught up on my shale subprojects then! Thanks for the pointer. Sean On 7/31/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 7/31/06, Sean Schofield [EMAIL PROTECTED] wrote: I won't be able to look into this deeply until tonight, but the comment about Hypersonic makes me think we might have a second license issue to deal with on this application. You might want to think about using Derby for the back end instead. That's what my JPA based example uses. I'll have to look into what you did. Does Derby provide an in-memory db option? That's what I'm looking for ... Yes it does have an in-memory mode. Indeed, shale-sql-browser uses Derby in this way. Craig Craig Sean
Do we need JIRA issues for sandbox stuff?
I anticipate a lot of changes to the shale-petstore over the next few weeks since this is a work in progress. Do I really need a JIRA issue for every little thing? My thinking is that sandbox stuff should be exempt from this requirement. This will encourage people to do an early check in so people can participate. Will a descriptive SVN message suffice here? Sean
Re: Source Repository Organization and Release Strategy Thoughts
I was also going to suggest just shipping this one as source. We will have to exclude the the incompatibly licensed dependencies from the default build, which means 'mvn install' would still build a war that doesn't work. (Back to that 'reading the directions' thing again. :) ). But 'mvn install -Phibernate' would. Why do we have to exclude the incompatible licenses from the default build? That seems like a strange requirement. If it is in fact a requirement, we should be working to get it changed. What about a java.net project instead? Also, can we host the full app on our zone? Wendy Sean
Re: Source Repository Organization and Release Strategy Thoughts
Why is CDDL an issue? That was on Cliff's list of acceptable licenses. I wasn't sure which licenses were cool and which weren't. Google also just announced that they're going to do hosting of open source prrojects[1]. They are in the early days (don't even have infrastructure in place for downloading releases yet), but it has some interesting ideas. If you like labels in GMail, you'll like their approach to issue tracking. (By the way, Greg Stein is the engineering manager at Google for this project.) I really like JIRA but I'd be curious to see what their alternative for issue tracking is. My instinct is to stick with a more established host since we'd like this to be available and we'd like it to be easy for people to access it. I'm not wild about Sourceforge. What do you think about java.net? I'm sure you investigated it when you were considering Shale options. By the way, are you aware of any Apache restrictions on using depedencies like Hibernate in Maven? It seems like excluding them from the default build would be a idiotic policy. With everyone switching to Maven now, it would just push projects that want to use Maven right out of the ASF. I tried to register shale as a project, but they've got an interesting twist in the signup process ... if you duplicate the name of an existing SourceForge project, they ask the owner of that project for an ok (on the theory that you might just be trying to do a land grab on the project names. We could undoubltedly do shale-goodies or shale-petstore or whatever there, if we wanted. Is Shale a sourceforge project? Craig Sean
Re: Shale Nightly Builds
I noticed the download link on the website doesn't work. Maybe we want a download page similar to myfaces?[1] I seem to recall we had a page describing the artifacts, etc. ... Sean [1] http://myfaces.apache.org/download.html On 7/25/06, Craig McClanahan [EMAIL PROTECTED] wrote: Thanks to some help from Sean, I now have an account on the MyFaces zone ( myfaces.zones.apache.org), and I have ported the nightly build process for Shale to there. It should run at around 2am Pacific time, as it always has, although the MyFaces zone (at least) is running in GMT so I had to adjust the crontab fire-up time to compensate. The updated script has been checked into the maven/etc directory of the repository, and it now includes the mailreader-jpa library and shale-mailreader-jpa sample webapp. Tonight's builds should be dated 20060725, as usual. Craig
Re: shale-test build failure
There is no shale zone yet. For now we can use either Struts or MyFaces zone. MyFaces zone might make sense b/c it also has its own repo for newly released artifacts (before they make it to ibiblio?) Should we make inquiries on the myfaces-dev list asking if its ok to piggy back on the MyFaces zone for now? Sean On 7/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: fixed btw. where is the continuum zone for shale ? -Matt On 7/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: wups ... did I the patch wrong ? lemme check On 7/13/06, Wendy Smoak [EMAIL PROTECTED] wrote: I'm not able to compile shale-test: Compiling 36 source files to c:\svn\shale\shale-test\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure c:\svn\shale\shale-test\src\main\java\org\apache\shale\test\mock\MockFacesContex t.java:[100,16] setCurrentInstance(javax.faces.context.FacesContext) in org.apac he.shale.test.mock.MockFacesContext cannot override setCurrentInstance(javax.fac es.context.FacesContext) in javax.faces.context.FacesContext; overridden method is static -- Wendy -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: svn commit: r419798 - in /shale/trunk/shale-test: pom.xml src/main/java/org/apache/shale/test/jmock/ src/main/java/org/apache/shale/test/jmock/AbstractJsfTestCase.java
That reminds me that we have a wiki to start building ... Sean On 7/7/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 7/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: matzew Date: Thu Jul 6 21:29:59 2006 New Revision: 419798 URL: http://svn.apache.org/viewvc?rev=419798view=rev Log: SHALE-210. Adding support for JMock to the shale test framework Added: shale/trunk/shale-test/src/main/java/org/apache/shale/test/jmock/ shale/trunk/shale-test/src/main/java/org/apache/shale/test/jmock/AbstractJsfTestCase.java Please configure your Subversion client to add svn:eol-style and svn:keywords properties to new files. http://wiki.apache.org/struts/StrutsMaintenanceSvn Thanks, Wendy
Re: SHALE-123
I agree that there are a couple of major dialog bugs that need to be addressed before rolling this out. I'm happy to try and help once we come up with a plan of attack. Sean On 7/6/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 7/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey, anyone looked at SHALE-123 ? Back at my old company I found a guy like that very useful. This PhaseListener is not intended to go to the META-INF/faces-config.xml It should be up to a user/developer. This concept (and a bunch of others around the dialog feature) are definitely on the list of things I want to look at over the next couple weeks. Dialog is the key functionality area that, IMHO, keeps Shale from being ready for a GA release ... but there are a number of overlapping requirements, and I want to make sure we take a shot at meeting all of them, not just some of them. WDT? -Matthias Craig -- Matthias Wessendorf futher stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
