[
http://issues.apache.org/jira/browse/BEEHIVE-827?page=comments#action_12314137
]
Rich Feit commented on BEEHIVE-827:
---
I'm still looking at this, and trying to figure out if there's any way to move
onCreate() inside the Faces request, or whether it's
[ http://issues.apache.org/jira/browse/BEEHIVE-800?page=all ]
Eddie O'Neil updated BEEHIVE-800:
-
Priority: Blocker (was: Critical)
Bumping to a 'blocker' as we shouldn't ship Beehive 1.0 (Incubating) without
using v2 XMLBeans.
Need to upgrade
[
http://issues.apache.org/jira/browse/BEEHIVE-827?page=comments#action_12314151
]
Mike Arnold commented on BEEHIVE-827:
-
I think the workaround would be fine for me, personally. I think for the sake
of JSF integration with PageFlows, however, the
[
http://issues.apache.org/jira/browse/BEEHIVE-827?page=comments#action_12314159
]
Rich Feit commented on BEEHIVE-827:
---
I agree, and I think I can actually move creation of the backing bean inside
the Faces request (right before the view is
[ http://issues.apache.org/jira/browse/BEEHIVE-672?page=all ]
Julie Zhuo updated BEEHIVE-672:
---
Fix Version: V1
(was: v1m1)
Verified the fix is not in v1m1. The trunk has the fix in place as of
svn191545. Chaging the Fix Version back
[ http://issues.apache.org/jira/browse/BEEHIVE-672?page=all ]
Julie Zhuo closed BEEHIVE-672:
--
Close, see last comment.
samples/.README.txt needs to be updated to match dist
-
Key:
[
http://issues.apache.org/jira/browse/BEEHIVE-800?page=comments#action_12314170
]
Jacob Danner commented on BEEHIVE-800:
--
Watching the xmlbeans mailing list, it looks like they are about to vote on a
final V2 candidate in the next couple of days
Yeah, I've been watching that as well. Ran through the build /
tests last night and didn't see any problems with their RC.
Unless anyone has a concern about taking the new apache-xbean.jar, I
was going to get that checked in today.
Let me know.
Eddie
On 6/21/05, Jacob Danner (JIRA)
All--
I've written a small, standalone JUnit test container that can be
used for out-of-container testing of Controls. This is a pretty
simple set of classes that are described below.
When a test class runs, a new control container context is created
and control fields declared with
[ http://issues.apache.org/jira/browse/BEEHIVE-801?page=all ]
daryoush mehrtash updated BEEHIVE-801:
--
Attachment: beehive801.diff
This patch is refactoring of the model pacakge to implement items b-e in the
list below. This doesn't include the a,
[ http://issues.apache.org/jira/browse/BEEHIVE-827?page=all ]
Rich Feit resolved BEEHIVE-827:
---
Fix Version: V1
Resolution: Fixed
Assign To: (was: Rich Feit)
Fixed with revision 191736. Mike, let me know if this resolves the issue
NullPointerException when calling
PageFlowUtils.getCurrentActionResolver(request)
-
Key: BEEHIVE-830
URL: http://issues.apache.org/jira/browse/BEEHIVE-830
Project: Beehive
Type: Bug
According to
http://incubator.apache.org/beehive/controls/controlsProgramming.html,
there are four possible ways for user to instantiate controls:
1. declarative instantiation without property reset(@Control);
2. declarative instantiation with property reset(@Control with
@Property);
3.
[ http://issues.apache.org/jira/browse/BEEHIVE-830?page=all ]
Rich Feit resolved BEEHIVE-830:
---
Fix Version: V1
Resolution: Fixed
With revision 191747 I've added a version of getCurrentActionResolver that
accepts the ServletContext as an
Would it make sense for the TemplatedURLFormatter (seems like the
top-level thing) to live in the ServletContext?
And (taking the collapsing further), could it be that we'd have only two
top-level objects: the TemplatedURLFormatter and the URLTemplatesFactory
(or URLTemplateFactory)?
Rich
Thanks Eddie, it sounds great. It will be nice to have a standard junit test
container for all of the system controls.
- Chad
On 6/21/05, James Song [EMAIL PROTECTED] wrote:
According to
http://incubator.apache.org/beehive/controls/controlsProgramming.html,
there are four possible ways
Yes, I agree. I was also thinking that the URLTemplateDescriptor
was looking an aweful lot like a wrapper that didn't do much
other than have the URLTemplatesFactory object as member data.
I think that URLTemplateDescriptor could go away and we'd just
have the URLTemplatesFactory (as a top-level
17 matches
Mail list logo
