Hey Tim,
Adam just said that he's forced to use the RI for right now so I'm not
sure it really implies anything about Faces. Presumably, however, if we
can get Trinidad to run on the RI, then it would make a hell of a
testcase for MyFaces JSR252 implementation when it's released.
Scott
, Scott O'Bryan [EMAIL PROTECTED] wrote:
Is there a place where we could store public API's that are not part of
Faces in MyFaces? Would this be the shared-impl package? We'll likely
need to support an interface to handle some of our filter
functionality from a portlet. This interface would need
I don't think we really have one yet. I can jump on that if you guys
want. Michael Freedman is the Spec Lead and he is someone I work with
on a regular basis.
Scott
Arash Rajaeeyan wrote:
hello
who is in charge for JSR 301 here?
--
Arash Rajaeeyan
or
moved to a commons object so it can be extended by other renderkits?
Secondly, do you have support for the
PortletRender/ActionRequest/Response objects:?
Scott O'Bryan
Bernd Bohmann wrote:
Hello,
I have setup two modules for possible inclusion in the common myfaces
code base.
One module
Bernd Bohmann wrote:
Secondly, do you have support for the
PortletRender/ActionRequest/Response objects:?
Currently not, but you are invited to add it.
Being that I was going to do it from scratch, you're on. :) Once
again the commons project rears it's ugly head. :) We'll need this
, is there any one from Myfaces ?
I have requested to become a member, but I am not sure if they
accept
me!
On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I don't think we really have one yet. I can jump on that if you
guys
want. Michael Freedman is the Spec Lead and he is someone I work
solution should cover both
multi-part form and lifecycle concepts.
On 10/12/06, *Scott O'Bryan* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Arash,
Is this the multi-part form ExternalContext or the much simplified
pre/post lifecycle stuff?
Scott
Arash Rajaeeyan wrote
I don't know why it's like this either, but unfortunately the snipit
defines a very clear behavior. Breaking this contract will break thew
1.2 spec.
Scott
Matthias Wessendorf wrote:
to fast... :)
my question was, why not as abstract method and let the details to the
impl...
and we need
jsf_state || jsf_state_64 || jsf_view_param params will break
jsf 1.2
Since we don't touch the API RespStMgr. guy.
-M
On 10/19/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
I don't know why it's like this either, but unfortunately the
snipit
defines a very clear behavior
Yeah, no doubt.
Matthias Wessendorf wrote:
agreed with the *spec* point of you.
but again, don't we need to ask the question that craig pointed out?
Let's see how http://host/app/page.faces?foo=bar will
bring fun to the isPostback() thing :)
-M
Hey Guys,
All arguments about the need for a common code package aside (yes, I
will continue to champion this), Trinidad has the need to create
container abstractions for some of our initialization services. We're
basically going to use the external context to pass into these services
Yay.. Thanks Martin.
Martin Marinschek wrote:
There is nothing offending in copying any of the classes over from
MyFaces-Impl to Trinidad!
regards,
Martin
On 11/8/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey Guys,
All arguments about the need for a common code package aside (yes, I
Hey Matthias? Are you getting this while connected through Oracle? If
so, I don't know what causes it, but flushing your repository fixes it.
It does the same thing for me but seems to work at home. shrug
Scott
Matthias Wessendorf wrote:
is it related to timezone? or locale ?
(I don't
Moving this to Dev list since it belongs there... :)
Martin Marinschek wrote:
Hi Scott,
interesting, thanks for the further clarification. I see the problems
very clearly now. Well then - let's start off this portlet bridge, and
see where it brings us to!
regards,
Martin
On 6/11/07, Scott
, Scott O'Bryan [EMAIL PROTECTED] wrote:
Martin,
PPR in Portlets CAN be implemented using certain portlet
implementations. But it cannot be done with generic JSR-168. Here are
a number of problems although I'm sure there are more:
1. Action Requests have portal artifacts. This means
Hey Renderkit guys. We have an open question on the 301 EG regarding
namespacing clientId's. As you well know, Faces does not currently
namespace it's client id's. Although we're looking at asking that this
be added to Faces 2.0, it's not in Faces 1.2. We've discussed many
options and the
?
Thomas
On 6/11/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey Martin,
One thing we could look at if 286 won't be released for a while is an
extension to Trinidad to support a plugable ppr system. This would be
a lot of work but we could have plugins for various portals that would
allow us
of the getRenderer method on the renderkit. But my gut
feeling is that's a terrible idea and would be pretty difficult to
implement this functionality for each renderer.
Scott O'Bryan
Adam Winer wrote:
On 6/13/07, *Scott O'Bryan* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hey
Have we tried logging a bug against the 1.2 ref impl that simply says
clientId's are not namespaced and see where that gets us? :)
Scott O'Bryan wrote:
Thomas,
Jeanne is probably better to answer this question but I'll take a
quick stab at it. Right now we have a portlet skin in Trinidad
/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Adam,
Thanks for the input. Big help. You're right about the renderer kit
thing, I've been up working on this pretty late and it's all a mush at
this point. :) I totally agree that I don't even know if it's
practial to do that. They were talking
I agree with Adam. The distinction is NOT post vs. get, rather the
distinction is something that's a piece of a page v.s something that's a
complete page.
So what's the difference. The difference is that the Portal sees action
urls as needing to be posted in context of the main page. On an
Couple more clairifications:
1. You can post into resource and action urls. Portals always allow a
post for sending parameters. They just don't allow you to muck with the
url on client side.
2. The distinction should be based solely on whether the resource is the
main page or not. You
are required to have exactly the same behavior!?!
-- Adam
On 6/14/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
I agree with Adam. The distinction is NOT post vs. get, rather the
distinction is something that's a piece of a page v.s something that's a
complete page.
So what's the difference
That's the rule of thumb. Yes.
Martin Marinschek wrote:
May I try to put this shorter -
actionUrl -- you'll see all portlets output, except you link to an
external page,
resourceUrl -- you'll see only your output always
is correct?
regards,
Martin
On 6/14/07, Scott O'Bryan [EMAIL
, Martin Marinschek [EMAIL PROTECTED] wrote:
We should open a JIRA issue to go through MyFaces and fix this
wherever necessary.
thanks!
regards,
Martin
On 6/14/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
That's the rule of thumb. Yes.
Martin Marinschek wrote:
May I try to put this shorter
be specified as 301. The 1.2 code I think we can
change, but I havn't taken a look at the state of the portal stuff in
that release yet.
Scott
Scott O'Bryan wrote:
Adam,
I think Trinidad is working (although I havn't checked the inline
frame lately). Still, it would probably be prudent
:) I'm not being clear.
Ok, the current bridge implementations don't take into account the
complexity of this issue. And as you said, Adam, the Faces spec isn't
much help either. But someone who is using the current Faces
implementation with the current bridge is expecting their
.
Scott
Scott O'Bryan wrote:
:) I'm not being clear.
Ok, the current bridge implementations don't take into account the
complexity of this issue. And as you said, Adam, the Faces spec isn't
much help either. But someone who is using the current Faces
implementation with the current bridge
Hello everyone,
This is a heads up. As you may or may not know, the JSR-301 EG and
Oracle (who is leading the project) has been trying to move the JSR-301
R.I. Development branch to Apache. In particular Apache MyFaces. I am
please to announce that Oracle has gotten all the approvals it
One more comment, the unit tests that will hopefully be made as part of
the Maven build will be developed as part of this project and I have
hopes they will be a lot more comprehensive then the tests provided by
the TCK. :) That's up to the community to help with that however.
Scott
Scott
I'll double check, but I think the TCK will be liscenced using the
Apache 2.0, it's just that Oracle will maintain the copyrights. As per
agreements with the JCP, the TCK can only enforce the specification
which is developed by the Java Community EG. I know Martin is on the
Expert Group
.
Form that side, all is fine :)
-Matthias
I would tend to think that in this case, a direct code grant
would be ok,
what does everyone else think?
regards,
Martin
On 7/25/07, Scott O'Bryan [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote
-open to say that Scott O'Bryan has said the
bridge-team will try everything to release the according TCK under the
ASL license as well.
In comparison to the recent incubation projects in MyFaces, which are
ADF-Faces -- Trinidad and the Rich Client Framework the codebase is
not very large and would
the bridge swap in a custom UIViewRoot implementation
if *not* by registering a subclass of UIViewRoot on the application
(which can be done declaratively in META-INF/faces-config.xml)?
-- Adam
On 7/26/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey guys,
There is some oddness that I'm seeing
:) Yup. Sounds good to me.
Martin Marinschek wrote:
Sure, I said you gonna try everything - if it is completely against
the rules, you can't do it.
regards,
Martin
On 7/26/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Cool, thanks Martin. Just make sure they know if they ask that we
] wrote:
I will post a mail questioning whether this code-grant can come in via
IPC or as an incubation project to the incubator list.
regards,
Martin
On 7/26/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Martin,
Thanks for the link. This is one of those strange cases where the
project could
implementations so we need to play nicely with them.
Scott
Scott O'Bryan wrote:
One more comment, the unit tests that will hopefully be made as part
of the Maven build will be developed as part of this project and I
have hopes they will be a lot more comprehensive then the tests
provided by the TCK
to wrap it, if it
doesn't it is wrapped by the portlet-bridge's own UIViewRoot.
regards,
Martin
On 7/27/07, Adam Winer [EMAIL PROTECTED] wrote:
On 7/26/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
This will not work in cases where a renderkit may override the UIViewRoot
Sorry, createView.
Scott O'Bryan wrote:
I'll check, but I think using createViewRoot will be sufficient.
Scott
Adam Winer wrote:
OK, yes, but Trinidad *does not need an alternative ViewRoot*.
So, what should Trinidad be doing when it creates a UIViewRoot?
-- Adam
On 7/29/07, Martin
, there is no need to wrap it,
if it
doesn't it is wrapped by the portlet-bridge's own UIViewRoot.
regards,
Martin
On 7/27/07, Adam Winer [EMAIL PROTECTED] wrote:
On 7/26/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
This will not work
and there are several functions in CoreRenderUtils,
PartialPageUtils, XhtmlUtils, and PartialPageRendererUtils which query
this capability.
Scott
Scott O'Bryan wrote:
Let me see if I can find it.. I know that the _partialPageSubmit does
a full page submit when inside of a portal and that the portal
these checks in place, still the
partialPageSubmit function is rendered out in this part of the code.
Therefore, only client-side code can change something about the
partial page submit, which it doesn't, if _checkLoadNoPPR is not
called.
regards,
Martin
On 7/31/07, Scott O'Bryan [EMAIL PROTECTED] wrote
, as all Java code rendered both
PPR and non-PPR versions, but now some code now only renders
PPR markup and relies on the client code to switch back to
full page rendering if needed.
-- Adam
On 7/31/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
The rendering capabilities are set
Hey, that's an interesting idea. It's so crazy it just might work.
For the short term, I'm sure we can modify the _partialPageSubmit script
to just call the full submit script. I looked at doing that when I
first added in the portal code, but the current mechanism seemed to work
correctly
something you can
rely on if need be?
regards,
Martin
On 8/1/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey, that's an interesting idea. It's so crazy it just might work.
For the short term, I'm sure we can modify the _partialPageSubmit script
to just call the full submit script. I looked
Hey Martin,
Many of this stuff also won't work in a remote portal behind WSRP.
The portal enhancements I made to Trinidad work for portal PPR, but it's
going to be container specific until 286 comes out. I don't think we
should be adding portal specific changes to Trinidad personally.
Marinschek wrote:
Hi Scott,
yes, sure, we were saying this initially - if we suspect a portlet and
a servlet share the same session, then we can't distribute the
portlets via WSRP.
regards,
Martin
On 8/8/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey Martin,
Many of this stuff also won't work
, I'll also be ok if I have to patch every Trinidad version we
want to use for this, cause this is really too special - except you
guys think we should include it somewhere somehow, as other people
need it as well.
regards,
Martin
On 8/10/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Not only
Hey everyone. After tearing though the buerocracy much slower then I
would have liked, I uploaded the code to MYFACES-1664 for the JSR-301
Portlet Bridge. This code should comply with the latest public draft of
the JSR-301 specification and, once we figure out where to put this and
get it
Hey everyone. After tearing though the bureaucracy much slower then I
would have liked, I uploaded the code to MYFACES-1664 for the JSR-301
Portlet Bridge. This code should comply with the latest public draft of
the JSR-301 specification and, once we figure out where to put this and
get it
Sounds good to me. Should we open up a discussion though on where
this should be committed so that we can hit the ground running once the
paperwork is listed?
Scott
Matthias Wessendorf wrote:
On 8/17/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey everyone. After tearing though
1.1 should run in a
portlet... (very simplified statement)
So, no not a replacement, just an IMPL of the java SPEC ;-)
On 8/17/07, Alexander Wallace [EMAIL PROTECTED] wrote:
Does this bridge replace Tomahawk bridge?
On Aug 17, 2007, at 10:39 AM, Scott O'Bryan wrote:
Sounds good to me
.x
-Matthias
On 8/17/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Sounds good to me. Should we open up a discussion though on where
this should be committed so that we can hit the ground running once the
paperwork is listed?
Scott
Matthias Wessendorf wrote:
On 8/17/07, Scott O'Bryan
[EMAIL PROTECTED] wrote:
Does this bridge replace Tomahawk bridge?
On Aug 17, 2007, at 10:39 AM, Scott O'Bryan wrote:
Sounds good to me. Should we open up a discussion though on
where this should be committed so that we can hit the ground
running once the paperwork is listed
an IMPL of the java SPEC ;-)
On 8/17/07, Alexander Wallace [EMAIL PROTECTED] wrote:
Does this bridge replace Tomahawk bridge?
On Aug 17, 2007, at 10:39 AM, Scott O'Bryan wrote:
Sounds good to me. Should we open up a discussion though on
where this should be committed so that we can
. But
we won't know for sure until people start trying it out.
Scott
Alexander Wallace wrote:
Does this bridge replace Tomahawk bridge?
On Aug 17, 2007, at 10:39 AM, Scott O'Bryan wrote:
Sounds good to me. Should we open up a discussion though on where
this should be committed so that we can
statement)
So, no not a replacement, just an IMPL of the java SPEC ;-)
On 8/17/07, Alexander Wallace [EMAIL PROTECTED] wrote:
Does this bridge replace Tomahawk bridge?
On Aug 17, 2007, at 10:39 AM, Scott O'Bryan wrote:
Sounds good to me. Should we open up a discussion though
Wessendorf [EMAIL PROTECTED] wrote:
Hi,
yes pom as well.
and also files in:
-META-INF/services/
-META-INF/
@myfaces: a bug
On 8/17/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey, it looks like I did the impl, just not the API. I'm fixing that now.
That said, does the liscence
Done... (mostly). See my comment in the JIRA ticket.
Scott O'Bryan wrote:
Yeah, I agree. I'll try to get that as soon as I can, but it's good
to know it won't hold up the committing. :)
Scott
Matthias Wessendorf wrote:
but all this, can be fixed, when it's already committed.
We needed
Hello everyone,
Trinidad has an internal class
(org.apache.myfaces.trinidadinternal.util.ExternalContextUtils) which
contains some convenience methods used throughout Trinidad in order to
handle ExternalContext objects which may be backed by a portal. It is
used especially inside Trinidad's
, *Matthias Wessendorf* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I am fine w/ it.
On 8/29/07, Scott O'Bryan [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hello everyone,
Trinidad has an internal class
I'm in the process of fixing TRINIDAD-667. Essentially what is
happening is, if a particular service appears more then once in the
webapp (either through multiple references in the classpath or because
it exists in multiple files), that service is returned twice by the
only one that goes with 301 (like this one ;-) )
-M
On 8/17/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Right. But for 1.2 and higher JSF implementations, you would not need
to use another bridge. This one should be the only one you'd need.
Scott
Matthias Wessendorf wrote:
yeah
Wessendorf [EMAIL PROTECTED] wrote:
Hi,
yes pom as well.
and also files in:
-META-INF/services/
-META-INF/
@myfaces: a bug
On 8/17/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey, it looks like I did the impl, just not the API. I'm fixing that now.
That said, does the liscence need
, but is essentially invalid html.
regards,
Martin
On 8/31/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
What I envisioned for Trinidad is namespacing the CSS file and loading
it outside of the head. Would something like that be a possibility for
Tomohawk? I mean I imagine any bridge would have
Martin, I have them listed in the project's main POM file. It's
basically Michael Freedman, Lei Oh, and myself.
Scott O'Bryan
Martin Marinschek wrote:
Anyone else who contributed to the bridge from within Oracle?
regards,
Martin
On 9/3/07, Matthias Wessendorf [EMAIL PROTECTED] wrote
I agree on this. I think we were talking about the subproject being
named jsf-portlet-bridge or portlet bridge. Should the Jira issues list
be the same? Also, presumably this project will cover future JSR's on
this same API.
Mike Kienenberger wrote:
It's probably too late to do anything
:-)
Martin, I have an ICLA on file. I think Michael Freedman has submitted
one as well and will hopefully even be on the mailing lists soon,
participating in all the Apache Goodness.
We in the United States were off on Monday for labor-day. Which, for
some reason, means we don't have to
Sorry for the unnecessary comment. Looks like Matthias already handled it.
Scott O'Bryan wrote:
:-)
Martin, I have an ICLA on file. I think Michael Freedman has
submitted one as well and will hopefully even be on the mailing lists
soon, participating in all the Apache Goodness.
We
:) Yay teamwork. I'm off for one day and all my work gets done for me.
Martin Marinschek wrote:
Yeah, Matthias, Manfred and Wendy have gone forward - long live Open
Source communities!
;)
regards,
Martin
On 9/5/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Sorry for the unnecessary
javascript - I just add it dynamically on the client. Works for
all major browsers just fine.
regards,
Martin
On 9/4/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
How are you getting the stylesheet reference into the header now?
JSR-168 does not have a means of doing this.
Scott
Martin Marinschek
As for issue #1, I think we've pretty much got all of the undated items
done, but we're waiting for approval from the Spec lead on an open issue
regarding the API of the bridge. Initially the Spec lead was following
the pattern of JSR-168 and he was including the API as part of the
spec.
as part of OpenSource projects so I
really don't forsee an issue.
Matthias Wessendorf wrote:
On 9/26/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
As for issue #1, I think we've pretty much got all of the undated items
done, but we're waiting for approval from the Spec lead on an open issue
Reporter: Scott O'Bryan
Fix For: 1.0.0-SNAPSHOT
In order to maintain consistency with the MyFaces codebase, this code donation
should follow similar coding standards to other MyFaces projects. Most notably:
* private methods and properties use a leading underscore
* static properties
Hey guys,
Good news!! I got permission to change the copyrights on the API for
the portlet bridge code donation. The JSR EG is simply going to
copyright the spec and the JavaDocs (like what's in the Faces Spec).
I've got a local environment which fixes some of the issues I've been
items are under the Apache 2.0 liscence and are scheduled for
inclusion in the ASF
So my question is, do I make the updates to the ip-clearance form or do you?
Also, where do I list the initial committers to the project?
Thanks,
Scott O'Bryan
Lawrence Mandel wrote:
Manfred,
You need
is earned.
On 10/10/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey Manfred,
I think I've *finally* got everything worked out for the copyright
sections of the ip-clearance for this contribution done and uploaded.
We ran into some last minute licensing issues that should be completely
resolved now
who needs such permissions?
--Manfred
On 10/4/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey guys,
Good news!! I got permission to change the copyrights on the API for
the portlet bridge code donation. The JSR EG is simply going to
copyright the spec and the JavaDocs (like what's
be advantageous.
Scott
--Manfred
On 10/11/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey Manfred,
I think I've *finally* got everything worked out for the copyright
sections of the ip-clearance for this contribution done and uploaded.
We ran into some last minute licensing issues that should
+1 (non-binding)
Scott
Mike Kienenberger wrote:
+1
On 10/15/07, Thomas Spiegl [EMAIL PROTECTED] wrote:
+1
On 10/15/07, Paul McMahan [EMAIL PROTECTED] wrote:
+1 (non-binding)
Best wishes,
Paul
On Oct 15, 2007, at 7:03 AM, Manfred Geiler wrote:
This is the official vote
Well it looks like we got enough +1 votes and no -1 votes. What's next?
Scott
Grant Smith wrote:
+1
On 10/15/07, *Scott O'Bryan* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
+1 (non-binding)
Scott
Mike Kienenberger wrote:
+1
On 10/15/07, Thomas Spiegl
Hey guys, assuming there are not objections from incubator, I'm doing
what I can to try to get the bridge project ready so we can hit the
ground running. I was wondering what you guys thought about adding a
couple of components to the jsr-301 jira project.
First off, I would like to add impl
.
But first we would have to find a proper key.
MFPB for MyFaces portlet bridge?
or JSFPB?
Other suggestions?
--Manfred
On 10/18/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Sure Manfred. If you would. I can then go and assign the existing Jira
tickets in the appropriate categories.
BTW, thanks
Or we could give it a codename like Tito or something... :)
Scott O'Bryan wrote:
Yeah. I like JSFPB but it doesn't matter to me. I wasn't sweating
the JSR-301 in JIRA too much because the decription of the project was
accurate. But if you're offering to fix it, I think it would be better
after jsr 301...
Well, renaming a Jira key is not possible.
What I could do is create a knew Jira project and bulk move all issues.
But first we would have to find a proper key.
MFPB for MyFaces portlet bridge?
or JSFPB?
Other suggestions?
--Manfred
On 10/18/07, Scott O'Bryan [EMAIL PROTECTED] wrote
to the view root component. Instead, the bridge should be
registering the component type for the special view root in the
application, so that calls to createComponent return the one needed
for the bridge.
-Andrew
On 10/18/07, Scott O'Bryan (JIRA) dev@myfaces.apache.org wrote:
[
https
a
non-namespaced view root. When running as a portlet, however, the
viewroot is a naming container and will handle namespacing.
Does this make sense?
Scott
Scott O'Bryan wrote:
Andrew,
Faces will not let us do this. The Portlet UIViewRoot implements a
naming container and has some other
.
If folks prefer a codename I offer Ponte.
Ponte means bridge in Italian.
-Mike-
Scott O'Bryan wrote:
Hmm. +1 to PortletBridge. It's the closest we have to what the
subproject is likely to be named.
Scott
Mike Kienenberger wrote:
Either a codename or PortletBridge would make
.
FYI: I also had to manually assign 1.0.0-SNAPSHOT as affected
version to all issues, hope that is ok.
--Manfred
On 10/19/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Well there you go. PortletBridge has my vote.
Mike Kienenberger wrote:
PORTLETBRIDGE is shorter than
GERONIMODEVTOOLS, so I
Hey guys, the code donation for the JSR-301 Portlet Bridge IP-Clearance
has been accepted by lazy consensus on the incubator list so I think
we're ready to add this into svn.
Thanks to everyone who helped during this process.
Scott
So who is willing to commit this? I think Manfred said something about
doing this for us.
Scott
Matthias Wessendorf wrote:
Yes, you're right, just saw the thread, you closed there.
Cool!
-M
On 10/22/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey guys, the code donation for the JSR-301
not already assigned Components to issues because they
seem to be lost.
FYI: I also had to manually assign 1.0.0-SNAPSHOT as affected
version to all issues, hope that is ok.
--Manfred
On 10/19/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
Well there you go. PortletBridge has my vote.
Mike Kienenberger
Wow... That's brave of them
Dennis Byrne wrote:
Caucho claims to have implemented and released JSF 2.0 [1] before the
spec was finished!
[1] http://www.caucho.com/press/2007-10-07.xtp
--
Dennis Byrne
, Scott O'Bryan (JIRA) dev@myfaces.apache.org wrote:
[
https://issues.apache.org/jira/browse/TRINIDAD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott O'Bryan updated TRINIDAD-134:
---
Status: Patch Available (was: Open
Indeed the serialVersionUID is used to distinguish between two versions
of the same class. And simply put, it's a performance enhancement. If
serialVersionUID is not present, Java will calculate one based on the
hash (I think). The thing is that needing to calculate a hash each
time a class
:
Yeah, let Manfred do it.
If he is to busy, I'll do it...
-M
On 10/22/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
So who is willing to commit this? I think Manfred said something
about
doing this for us.
Scott
Matthias Wessendorf wrote:
Yes
:
Yeah, let Manfred do it.
If he is to busy, I'll do it...
-M
On 10/22/07, Scott O'Bryan [EMAIL PROTECTED] wrote:
So who is willing to commit this? I think Manfred said something
about
doing this for us.
Scott
Matthias Wessendorf wrote
: Bug
Reporter: Matthias Weßendorf
Assignee: Scott O'Bryan
Priority: Blocker
BridgeRenderRequestWrapper.java
in pack. org.apache.myfaces.portlet.faces.bridge.wrapper is missing.
+1 non-binding
I also have some suggestions for things to go into this project which
would be helpful.
Scott
Paul Spencer wrote:
+1 for the commons project.
Paul Spencer
Mario Ivankovits wrote:
Hi!
1) Will their be a JSF version specific version, i.e. commons_1.2 and
commons_2.0?
+1to this. I do agree that unsupported too strong, but having to
support dual code-lines for enhancements is hindering enhancements to
Trinidad. It should be the responsibility of the 1.2 branch to make
sure that people moving from 1.0.x to 1.2 have an easy upgrade path but
I see no reason
1 - 100 of 1260 matches
Mail list logo
