Missing license files
-
Key: EXTSCRIPT-142
URL: https://issues.apache.org/jira/browse/EXTSCRIPT-142
Project: MyFaces Extensions Scripting
Issue Type: Bug
Reporter: Bernhard Huemer
Assignee
[
https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800189#action_12800189
]
Bernhard Huemer commented on MYFACES-2485:
--
To be honest, I'd consider
Hey,
sorry, I haven't noticed this thread, so I've already commented on the
according JIRA issue
(https://issues.apache.org/jira/browse/MYFACES-2485). Basically I've
already mentioned it there, but I think the reason why only the
contextDestroyed-callbacks are invoked is that Tomcat, by
[
https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800198#action_12800198
]
Bernhard Huemer commented on MYFACES-2485:
--
What I'm saying is basically don't
[
https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800228#action_12800228
]
Bernhard Huemer commented on MYFACES-2485:
--
Well, again I beg to differ, because
[
https://issues.apache.org/jira/browse/MYFACES-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800252#action_12800252
]
Bernhard Huemer commented on MYFACES-2485:
--
Yep, leaving
):
Bernhard Huemer schrieb:
I´d rather have a single pretictable triggering point than having
the compiler being triggered continously in unpredictable manner.
A standalone developer can code and save and can cause continous
errors. But at the time he hits refresh, he can be pretty sure that
his code
on and refresh
that at first, etc.. - doesn't work for cycles though).
regards,
Bernhard
Werner Punz wrote on 12/12/2009 03:09 PM (GMT):
Bernhard Huemer schrieb:
Under normal no locking circumstances, the beans get
replaced in the middle of the request because someone
else triggered
. the only advantage that synchronizing requests
has in this case is that it won't fail for that particular request, but
it will fail for the following ones as well).
regards,
Bernhard
Werner Punz wrote on 12/12/2009 08:00 PM (GMT):
Bernhard Huemer schrieb:
Okay, I'll tell you how that works in my
Hey,
but there is another issue regarding Windows yet, I
also have not set the mutexes in the compiler parts
to avoid windows filelocking if more than one user
hits the server.
now I'm not entirely sure anymore what you think this module's usage is
intended to be like or maybe I'm just
):
Bernhard Huemer schrieb:
Hey,
but there is another issue regarding Windows yet, I
also have not set the mutexes in the compiler parts
to avoid windows filelocking if more than one user
hits the server.
now I'm not entirely sure anymore what you think this module's usage
is intended
[
https://issues.apache.org/jira/browse/EXTSCRIPT-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12788897#action_12788897
]
Bernhard Huemer commented on EXTSCRIPT-27:
--
That's the issue I've already told
[
https://issues.apache.org/jira/browse/ORCHESTRA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12786455#action_12786455
]
Bernhard Huemer commented on ORCHESTRA-45:
--
Unfortunately I'm not really
UnsupportedOperationException(...);
}
}
);
}
// - Implement the interface ServletRequest now!
public Object getAttribute(String name) {
// ...
}
// ...
}
\\\
Hope that helps. :-)
regards,
Bernhard Huemer
On 12/01/2009 09:48PM GMT, Michael Concini wrote:
I need some help
(...);
}
}
);
}
// - Implement the interface ServletRequest now!
public Object getAttribute(String name) {
// ...
}
// ...
}
\\\
Hope that helps. :-)
regards,
Bernhard Huemer
On 12/01/2009 09:48PM GMT, Michael Concini wrote:
I need some help with the best way to handle
Personally I would prefer it if the artifact itself is responsible for
providing the corresponding class loader instead of using a try error
approach. This means that we would have to rewrite the configuration
parts of MyFaces so that not only the class name but also the class
loader to use
To clarify that a little bit more:
I'm more or less suggesting to introduce class loader extensions as
well, but I don't think that they should be stored centrally. Instead I
think each artifact should be able to provide the class loader extension!
Bernhard Huemer wrote:
Personally I would
or if I've over-engineered the whole OSGi
support thingy a little bit.
regards,
Bernhard
[1]: http://www.osgi.org/javadoc/r4v41/org/osgi/service/http/HttpService.html
Am 10. Juli 2009 03:20 schrieb Felix Röthenbacher froethenbac...@apache.org:
Bernhard Huemer schrieb:
Hi,
as I've announced something
Hi,
as I've announced something similar a few weeks ago (due to a disease,
however, I didn't have the time to contribute these changes yet), I'm
wondering how you implemented that with some modifications?
For example, Facelets built-in components (h:form, ...) didn't work
for me as Facelets
Hello,
recently I've thought of using JSF in an OSGi environment because of the
greater modularity it would provide for developers. JSF already provides
reusability regarding the user interface, i.e. JSF provides the
possibility to create user interface components, but what do you do if
you
a new module in myfaces commons is the right place to put this
efforts.
regards
Leonardo Uribe
2009/5/29 Bernhard Huemer bernhard.hue...@gmail.com
mailto:bernhard.hue...@gmail.com
Hello,
recently I've thought of using JSF in an OSGi environment because of
the greater modularity
);
}
}
\\\
However, there are other issue as well besides this one (no JSP
available, different approach to resource loading, some dependencies of
MyFaces aren't OSGi-friendly, ...).
regards,
Bernhard
Bernhard Huemer wrote:
Hello,
well, you can't simply attach OSGi support to an existing MyFaces
release
, I think I'll just have to convince you by implementing my idea,
but I'm going to use a seperate branch just as Simon suggested it. ;-)
regards,
Bernhard Huemer
On 10/28/2008 +0100,
Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
The problem is, that it is hard to ensure having
a
single conversation-model on a named conversation-model. I'd propose to
do it the other way around.
regards,
Bernhard Huemer
On 10/27/2008 +0100,
Simon Kitching [EMAIL PROTECTED] wrote:
Hi Bernhard,
It's great to see some design discussion about Orchestra!
Bernhard Huemer schrieb:
Hi folks
Hello,
The main problem I see with this approach is that you HAVE to use a
flow definition, else Orchestra has no chance to determine when to end
a conversation and when to reuse the current one.
Well, no, you don't have to use a flow definition. Managing the
conversation from a user's
is not the default one for
conversations.
regards,
Bernhard Huemer
[
https://issues.apache.org/jira/browse/ORCHESTRA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated ORCHESTRA-17:
-
Status: Patch Available (was: Reopened)
RequestParameterFacesContextFactory only
[
https://issues.apache.org/jira/browse/ORCHESTRA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607762#action_12607762
]
Bernhard Huemer commented on ORCHESTRA-17:
--
I've created a patch
[
https://issues.apache.org/jira/browse/MYFACES-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585411#action_12585411
]
Bernhard Huemer commented on MYFACES-1693:
--
Note that you can't use JSP 2.0
Hello,
I think that providing integration with the
OpenEntityManagerInViewFilter is much more preferable to adding another
managed scope. For example, think of a master-detail view at which the
user starts a new conversation by selecting one of the entries being
loaded via a
Hello,
additionally I'm concerned whether this breaks compatibility with
current (non JSR-301) portlet bridges ..
regards,
Bernhard
On 02/20/2008 +0100,
Matthias Wessendorf [EMAIL PROTECTED] wrote:
also...
doesn't this belong to the 12x trunk ?
My understanding is that the JSR 301 is kind
:
There is no compatibility for Trinidad with non JSR-301 bridges.
Scott
Bernhard Huemer wrote:
Hello,
additionally I'm concerned whether this breaks compatibility with
current (non JSR-301) portlet bridges ..
regards,
Bernhard
On 02/20/2008 +0100,
Matthias Wessendorf [EMAIL PROTECTED] wrote
Hello,
that's because there's a dependency to PortletNamingContainerUIViewRoot
even if you're using this StateManager in a Servlet environment (due to
the import). In order to overcome this issue Scott could introduce an
additional indirection so that the class Portlet..UIViewRoot will only
before actually using it. The
POM dependency shouldn't make a difference if I did this though.
You mind me asking what Bridge you are using? Also, are you using JSF 1.2?
Scott
Bernhard Huemer wrote:
Hello,
actually, I'm using Trinidad with a non JSR-301 bridge (even though it
requires some
on the portlet classes and it loads fine in a servlet
only environment. I may have to get at the class using reflection or
something to prevent it from preloading.
Scott
Bernhard Huemer wrote:
Hello,
that's because there's a dependency to
PortletNamingContainerUIViewRoot even if you're using
? Trinidad 1.1 portlets are not officially
supported even though they should work with some hacks and
workarounds. I'm thinking for 1.2, though, we really should enforce the
standard bridge. Do you agree?
Scott
Bernhard Huemer wrote:
Hello,
LOL. Seriously the Jsr301StateManagerImpl is the wrong
Hello,
I'm just wondering what version of the maven-eclipse- or the
maven-idea-plugin you're using because I've never had problems with the
maven-faces-plugin generating source in the target tree. mvn
eclipse:eclipse or mvn idea:idea configures the project properly at
least for me as I don't
Hello,
On 01/31/2008 +0100,
Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Bernhard,
On Thu, Jan 31, 2008 at 12:54 AM, Bernhard Huemer
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Hello,
I'm just wondering what version of the maven-eclipse- or the
maven-idea-plugin you're
[
https://issues.apache.org/jira/browse/MYFACES-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558381#action_12558381
]
Bernhard Huemer commented on MYFACES-1802:
--
Introducing a new interface with two
[
https://issues.apache.org/jira/browse/MYFACES-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558379#action_12558379
]
Bernhard Huemer commented on MYFACES-1802:
--
The problem is that it seems
: 1.1.5
Reporter: Bernhard Huemer
The JSF 1.1 specification requires any implementation to support Java 1.3 and
that's why the FacesException isn't allowed to utilize builtin exception
chaining mechanisms (i.e. initCause(), etc..) as they have been introduced in
Java 1.4. However
Issue Type: Bug
Affects Versions: 1.0.0-SNAPSHOT
Environment: Tomcat 5.5.20, Pluto 1.1.4, MyFaces 1.2.1-SNAPSHOT
(locally patched version)
Reporter: Bernhard Huemer
Priority: Critical
The JSF specification requires the ViewHandler to store the content-type
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543094
]
Bernhard Huemer commented on PORTLETBRIDGE-12:
--
Now it works like a charm (well, actually I had
Hello,
Actually, the problem is that you can't take part in the initialization
process, i.e. there is no way to add support for additional,
non-standard injection annotations. For example, I thought of rewriting
Dennis' Guice integration:
///
public class GuiceLifecycleProvider implements
s/as it doesn't additional complexity/as it doesn't introduce additional
complexity
Usually, errors don't matter, but I think it's more difficult to
understand otherwise.
On 11/13/2007 +0100,
Bernhard Huemer [EMAIL PROTECTED] wrote:
Hello,
Actually, the problem is that you can't take part
Hello,
Ok, I'll do that on Thursday, if you don't mind.
regards,
Bernhard
On 11/13/2007 +0100,
Paul McMahan [EMAIL PROTECTED] wrote:
On Nov 13, 2007, at 3:03 PM, Bernhard Huemer wrote:
However, if you really can't live with the seperation of
initialization and postconstruction, what about
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542014
]
Bernhard Huemer commented on PORTLETBRIDGE-12:
--
Of course not! The official patch will calculate
Affects Versions: 1.0.0-SNAPSHOT
Environment: Tomcat 5.5.20, Pluto 1.1.4, MyFaces 1.2.1-SNAPSHOT
(locally patched version)
Reporter: Bernhard Huemer
Priority: Critical
While restoring a view JSF tries to determine the view ID using some request
information (i.e
[
https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541363
]
Bernhard Huemer commented on MYFACES-1761:
--
I guess I have to agree that the specification leaves room
[
https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541122
]
Bernhard Huemer commented on MYFACES-1761:
--
In fact, I've even quoted the specification - Page 11, Spec
, 1.2.1-SNAPSHOT
Reporter: Bernhard Huemer
Fix For: 1.2.1-SNAPSHOT
The specification states that managed bean methods annotated with
@PostConstruct have to be called after the object is initialized and after
dependency injection is performed. However, MyFaces calls those
[
https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated MYFACES-1761:
-
Status: Patch Available (was: Open)
Handling PostConstruct annotations - wrong order
[
https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540625
]
Bernhard Huemer commented on MYFACES-1761:
--
Well, I'm not talking about full-fledged dependency injection
Hello,
I'm just wondering if anyone has tried out the JSP 2.0 integration that
I've proposed several weeks ago [1]? Maybe it's just me, but I think
that'd be a great addition for the next release.
So far I've tested it using the following environments:
- Tomcat 5.5.25 + Facelets 1.1.13
-
Hello,
that's what I've already detected.
That seems to be a trivial bug of the Maven Faces Plugin's
MyFacesComponentGenerator. In order to the generate the fancy getter,
it uses the name of the given parameter rather than the name of the
property.
regards,
Bernhard
On 10/17/2007 +0200,
[
https://issues.apache.org/jira/browse/MYFACES-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534956
]
Bernhard Huemer commented on MYFACES-1745:
--
That seems to be a trivial bug of the Maven Faces Plugin's
[
https://issues.apache.org/jira/browse/MYFACES-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533456
]
Bernhard Huemer commented on MYFACES-1737:
--
This bug seems to be a duplicate of
https
Hello,
I'm just wondering if there are other Maven Snapshot repositories beside
http://people.apache.org/repo/m2-snapshot-repository/; as it seems that
this repository is out of date. The myfaces-core artifacts haven't been
modified since Sept 01, 2007 (for example see:
Hello,
according to the Servlet specification:
///
The session-timeout element defines the default
session timeout interval for all sessions created
in this web application. The specified timeout
must be expressed in a whole number of minutes.
If the timeout is 0 or less, the container ensures
Hello,
according to the SVN Commit History (see MYFACES-1639 [1]) you've
knowingly removed the DTDs. As far as I know, that's the reason why
MyFaces 1.2 requires a connection to the internet when deploying a JSF
1.0 or JSF 1.1 application (see MYFACES-1690 [2], even though the
reporter
[
https://issues.apache.org/jira/browse/MYFACES-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520540
]
bhuemer edited comment on MYFACES-1693 at 8/20/07 6:44 AM:
---
I'll attach a patch
[
https://issues.apache.org/jira/browse/MYFACES-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520540
]
Bernhard Huemer commented on MYFACES-1693:
--
I'll attach a patch whitch enables you to run MyFaces
[
https://issues.apache.org/jira/browse/MYFACES-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520111
]
bhuemer edited comment on MYFACES-1244 at 8/16/07 4:40 AM:
---
It still seems that
[
https://issues.apache.org/jira/browse/MYFACES-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520111
]
Bernhard Huemer commented on MYFACES-1244:
--
It still seems that no one has commited this patch yet. Call
: JSR-252
Affects Versions: 1.2.0, 1.2.1-SNAPSHOT
Reporter: Bernhard Huemer
According to an inline comment (validation set to false during implementation
of 1.2, DigesterFacesConfigUnmarshallerImpl) and my personal experience,
configuration file validation hasn't been implemented so
[
https://issues.apache.org/jira/browse/MYFACES-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519658
]
Bernhard Huemer commented on MYFACES-1695:
--
Well, in fact the Expression Language Specification states
[
https://issues.apache.org/jira/browse/MYFACES-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519535
]
Bernhard Huemer commented on MYFACES-1694:
--
Currently MyFaces needs the mapping for the FacesServlet
[
https://issues.apache.org/jira/browse/MYFACES-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519535
]
bhuemer edited comment on MYFACES-1694 at 8/13/07 2:47 PM:
---
Currently MyFaces
[
https://issues.apache.org/jira/browse/MYFACES-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519308
]
Bernhard Huemer commented on MYFACES-1702:
--
I'm afraid that it doesn't work as it seems that you've mixed
[
https://issues.apache.org/jira/browse/MYFACES-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519319
]
Bernhard Huemer commented on MYFACES-1702:
--
Now it works like a charm. :-)
Error Handling
Type: Bug
Affects Versions: 1.2.0, 1.2.1-SNAPSHOT
Reporter: Bernhard Huemer
Priority: Critical
During the Invoke Application phase, a SetPropertyActionListener always throws
an AbortProcessingException claiming that the target has not been set, but
that's just
[
https://issues.apache.org/jira/browse/MYFACES-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated MYFACES-1703:
-
Status: Patch Available (was: Open)
f:setPropertyActionListener causes wrongful
[
https://issues.apache.org/jira/browse/MYFACES-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated MYFACES-1702:
-
Status: Patch Available (was: Open)
Error Handling FileNotFoundException
[
https://issues.apache.org/jira/browse/MYFACES-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated MYFACES-1702:
-
Status: Open (was: Patch Available)
Error Handling FileNotFoundException
Reporter: Bernhard Huemer
This Facelets-Error-Handler works fine when using MyFaces 1.1.6, but a I guess
a bug has been introduced while porting this code to MyFaces 1.2.1. Currently,
while setting up the HTML code to display the exception a FileNotFoundException
will be thrown because
[
https://issues.apache.org/jira/browse/MYFACES-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519142
]
Bernhard Huemer commented on MYFACES-1670:
--
The problem is a legacy PropertyResolver being required
[
https://issues.apache.org/jira/browse/MYFACES-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated MYFACES-1670:
-
Status: Patch Available (was: Open)
A dollar-type, 2 level EL expression evaluates
[
https://issues.apache.org/jira/browse/MYFACES-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519154
]
Bernhard Huemer commented on MYFACES-1697:
--
If I only had taken a look at this issue a few hours earlier
Reporter: Bernhard Huemer
As the topic suggests, the state gets reconstructed twice during the Restore
View phase. State reconstruction consists of decoding, decrypting and
decompressing (assuming that MyFaces has been configured to do so) the given
state (i.e. the javax.faces.ViewState request
[
https://issues.apache.org/jira/browse/MYFACES-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Huemer updated MYFACES-1701:
-
Status: Patch Available (was: Open)
The state gets reconstructed twice
restore the state because of a javax.crypto.BadPaddingException or
a java.io.StreamCorruptedException.
greets,
Bernhard Huemer
[1]:
http://jakarta.apache.org/jmeter/usermanual/jmeter_proxy_step_by_step.pdf
[2]:
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#HTTP_Proxy_Server
Am
number of the specification seems rather reasonable to
me.
greetings,
Bernhard Huemer
On 05/22/07, Paul Spencer [EMAIL PROTECTED] wrote:
I am also in agreement with Manfred's opinion.
If we tie the MyFaces version number to the spec, what do we do in the
following
cases:
1) A fix
Reporter: Bernhard Huemer
Priority: Trivial
Each implicit object defines its name by using a interned string literal,
such as for example the class ApplicationImplicitObject [1] does. The JLS
declares that literals are interned anyway (String objects have a constant
value
Issue Type: Improvement
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Bernhard Huemer
Priority: Trivial
Currently the implementation differs between field- and property-based
injection both in processing annotations and in invoking the appropriate method
to set
84 matches
Mail list logo
