Re: [aspectj-users] AspectJ 1.9.21.2 maintenance release

[Mario Ivankovits via aspectj-users]

As always! Thank you! :-)

As a short heads up, I have some issues with that version and the version 
before within the IDE. I just filed a bug with IntellilJ about that.

https://youtrack.jetbrains.com/issue/IDEA-349094/Cannot-read-the-array-length-because-buf-is-null


Had not much change right now to look into that in more detail. But might be 
able to do so if required.


Best regards

Mario


> Am 13.03.2024 um 10:50 schrieb Alexander Kriegisch via aspectj-users 
> :
> 
> Dear AspectJ users,
> 
> we are pleased to announce the AspectJ maintenance release 1.9.21.2 
> supporting Java 21. Please note that since 1.9.19, the minor-minor version 
> indicates the corresponding latest Java release (byte code version) supported 
> by the AspectJ compiler and weaver. I.e., 1.9.21.2 → Java 21.
> 
>  
> Improvements
> 
> Previously, when targeting the same join point from multiple around advices 
> in annotation-style @AspectJ syntax, there were limitations in functionality 
> in concurrent (multi-threaded) situations, if the around advice code was not 
> inlined. This was improved in AspectJ 1.9.9 
>  
> (see also issue #128 
> ), but the improvement 
> only applied to child threads directly created during aspect execution and 
> would fail for pre-existing, long-lived threads, e.g. thread pools used by 
> executor services. Furthermore, the improvement could lead to memory leaks, 
> not cleaning up thread-local references to posssibly expensive objects. In 
> such situations, users had to switch to native-syntax aspects which never had 
> that problem to begin with due to their different internal structure.
>  
> Now, issue #141  has 
> been resolved, closing the gap and, as well as possible given their different 
> internal structure, bringing @AspectJ aspects up to par with native-syntax 
> aspects in concurrent situations, while simultaneously also addressing the 
> memory leak issue #288 
> . This is a 
> substantial improvement, and annotation-style syntax users are strongly 
> engouraged to upgrade. Thanks to user pagrawalgit for raising the memory leak 
> issue and triggering me to think about the concurrency issue more broadly and 
> finally solve both in one shot.
> Other changes and bugfixes
> 
> The fix for issue #277 
>  in AspectJ 1.9.21.1 
> introduced a regression bug in the optional weaving cache now fixed in issue 
> #285 . Thanks to user 
> Kimming Lau for raising and re-testing both issues.
> 
> Other notes about 1.9.21.x
> 
> Since 1.9.21, the AspectJ compiler AJC (contained in the aspectjtools 
> library) no longer works on JDKs 11 to 16. The minimum compile-time 
> requirement is now JDK 17 due to upstream changes in the Eclipse Java 
> Compiler (subset of JDT Core), which AspectJ is a fork of. You can still 
> compile to legacy target versions as low as Java 1.3 when compiling plain 
> Java code or using plain Java ITD constructs which do not require the AspectJ 
> runtime aspectjrt, but the compiler itself needs JDK 17+. Just like in 
> previous AspectJ versions, both the runtime aspectjrt and the load-time 
> weaver aspectjweaver still only require JRE 8+.
> History: Since 1.9.7, the AspectJ compiler AJC needed JDK 11+, before then 
> JDK 8+.
> Resources
> 
> For more detailed release information, please read the release notes 
> .
> The current artifacts (runtime, weaver, compiler, matcher) are available on 
> Maven Central.
> The AspectJ installer can be found on GitHub 
> .
> There is also an AJDT update site for Eclipse 4.30 (2023-12) 
> . Unfortunately, 
> updates sites for previous Eclipse versions , e.g. 4.26 (2022-12) and 4.23 
> (2022-03) are no longer compatible with AspectJ 1.9.21, because the latter 
> dependes on upstream Eclipse changes. So if you want to use ADJT builds with 
> Eclipse IDE, you need to upgrade to 2023-12. Otherwise, you can only use 
> AspectJ 1.9.21 via Maven build, not via direct IDE. On top of that, you also 
> need an extra update site for Eclipse 2023-12 itself 
> . 
> The IDE guide 
> 
>  explains, why this is necessary.
> On GitHub, there also is a short guide describing options for setting up a 
> development environment 
> .
> See here 
> 

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Mario Ivankovits]

Hi!

Just for the records: My test included the JVM startup time. Yours start 
counting in main() where the JVM is already up - and probably some of the 
classpath scanning already took place because of the inheritance from 
„javafx.application.Application“ .
Your test shows „showing: 298 shown: 468“ on my machine.

A „native“ splash screen usually should start up at the very first, before the 
JVM starts.


Best regards,
Mario


> Am 05.06.2018 um 19:04 schrieb Weiqi Gao :
> 
> Here's a more accurate (but still rough) timing application:
> 
> import javafx.application.Application;
> import javafx.stage.Stage;
> import javafx.scene.Scene;
> import javafx.scene.control.*;
> import javafx.scene.layout.*;
> 
> public class Main extends Application {
>private static long t1;
>private static long t2;
>private static long t3;
>private static long t4;
> 
>public void start(Stage stage) {
>t2 = System.currentTimeMillis();
>Label l1 = new Label("main:" + t1);
>Label l2 = new Label("start:   " + (t2 - t1));
>Label l3 = new Label("");
>Label l4 = new Label("");
>VBox vbox = new VBox(l1, l2, l3, l4);
>Scene scene = new Scene(vbox);
>stage.setScene(scene);
>stage.setTitle("Timing Demo");
>stage.setOnShowing(e -> {
>t3 = System.currentTimeMillis();
>l3.setText("showing: " + (t3 - t2) + ", " + (t3 - t1));
>});
>stage.setOnShown(e -> {
>t4 = System.currentTimeMillis();
>l4.setText("shown:   " + (t4 - t3) + ", " + (t4 - t1));
>});
>stage.show();
>}
> 
>public static void main(String[] args) {
>t1 = System.currentTimeMillis();
>launch(args);
>}
> }
> 
> The result of running it on my Dell laptop with Intel Core i7-6820HQ
> @2.70GHz,CPU and NVIDIA Quadro M1000M display adapter is attached:
> 
> Essentially, it took less than half a second for a dead simple JavaFX Stage
> to be visible.
> 
> Here's the timing number for 10 consecutive runs: 422, 440, 426, 442, 418,
> 441, 432, 444, 470, 453
> 
> --
> Weiqi Gao
> weiqi...@gmail.com
> 
> On Tue, Jun 5, 2018 at 10:46 AM, Scott Palmer  wrote:
> 
>> Yes, my only comment was that if we can get a window up using standard Java
>> GUI frameworks fast enough, then the complexity of adding splashscreen
>> support to the launcher isn't justified.
>> Mario's example shows that is it 1-2 seconds to get a window up.  That is a
>> bit high.  If it was under 1s then I would suggest not bothering, it isn't,
>> so keep it on the list of desired features.
>> 
>> Scott
>> 
>> On Tue, Jun 5, 2018 at 8:21 AM Pedro Duque Vieira <
>> pedro.duquevie...@gmail.com> wrote:
>> 
>>> Sorry, perhaps it was I who misunderstood the debate..
>>> 
>>> On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus  wrote:
>>> 
 Maybe I misunderstood the question but to my opinion the real question
>> is
 whether the new java packager has to provide the support for a splash
 screen
 or not. This has nothing to do with the question whether applications
 should
 have a splash screen or not because if we find that todays Java is fast
 enough
 to display a simple window in less than a second or so, then the Java
>> GUI
 (Swing or JavaFX) could provide a splash screen itself. There is then
>> no
 need
 for an additional mechanism provided my the packager.
 
 Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira:
 
 Hi,
> 
> I agree with Johan and others, a splash screen is valuable and needed.
> 
> Microsoft applications that run on Windows itself (think Word, Excel,
> etc),
> they have a splash screen, Intelllij has a splash screen (it's swing
>>> based
> AFAIK), etc.. If a Microsoft application running on its own operating
> system needs a splash screen then chances are pretty high that there
>>> will
> be Java apps that'll need a splash screen.
> 
> Cheers,
> 
> 
> 
 
>>> 
>>> 
>>> --
>>> Pedro Duque Vieira
>>> 
>> 
> 
> 
> 
> -- 
> Weiqi Gao (高为奇)
> weiqi...@gmail.com
> http://weiqigao.blogspot.com/

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Mario Ivankovits]

Hi!

I’ve just test with this very small JavaFX Application:

public class TstFx extends Application
{
@Override
public void start(Stage primaryStage) throws Exception
{
Label root = new Label("test");
Scene scene = new Scene(root, 800, 600);
primaryStage.setOnShown(evt -> System.exit(1));

primaryStage.setScene(scene);
primaryStage.show();
}

public static void main(String[] args)
{
launch(args);
}
}

As you can see, the program forcibly exits once the stage is shown. So, using 
„time“ I can simply measure the time required until the stage should be visible 
on screen.

Starting this with an incredible huge classpath (the one we have to use in 
production) I get this times:
real 0m1.885s
user 0m3.372s
sys 0m0.433s

Using a really small classpath I can come down to:
real 0m1.639s
user 0m2.208s
sys 0m0.297s


MacBook late 2016.

The „user" difference seems to be just because of the classpath scanning. No 
static initialization happening, because this TstFx does not reference any 
other class.

Best regards,
Mario


Am 04.06.2018 um 18:22 schrieb Scott Palmer 
mailto:swpal...@gmail.com>>:

Nobody is arguing against splash screens.  I’m simply suggesting that the JVM 
startup is not slow enough that we need special handling of this in native code.

If Java can get a window displayed in under half a second there is no need for 
the added complexity to support a native splash screen in the launcher.

The idea that cinit code *can* be slow is not really the issue here unless it 
isn’t possible to get a window displayed quickly even when there is no 
significant initialization other than to get that window= shown.  Don’t put 
heavy initialization in the main class when you want a splash screen.  Use a 
pre-main class that shows the splash screen and calls the “real” main class.

It makes sense to understand if we have this problem before making a complex 
solution.

Scott


On Jun 4, 2018, at 10:44 AM, Pedro Duque Vieira 
mailto:pedro.duquevie...@gmail.com>> wrote:

Hi,

I agree with Johan and others, a splash screen is valuable and needed.

Microsoft applications that run on Windows itself (think Word, Excel, etc),
they have a splash screen, Intelllij has a splash screen (it's swing based
AFAIK), etc.. If a Microsoft application running on its own operating
system needs a splash screen then chances are pretty high that there will
be Java apps that'll need a splash screen.

Cheers,


--
Pedro Duque Vieira

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

[Mario Ivankovits]

A preloader/splash-screen will/should also hide the JVM startup time.

Best regards,
Mario


> Am 03.06.2018 um 09:57 schrieb Tom Schindl :
> 
> On 01.06.18 19:42, Johan Vos wrote:
>> I'm not saying a preloader is really a requirement, but I know of a few
>> applications that are using it and benefiting from it.
>> 
>> The preloader functionality is more than just a splash screen, and I see
>> this valuable for instance when static initializers of classes that are
>> used in the main class may take a lot of time.
> 
> Then I'd argue that you can easily refactor your main-class ;-)
> 
> Tom

Re: [aspectj-users] AspectJ 1.9.0 released

[Mario Ivankovits]

Great news! Thank you!

Best regards,
Mario

Am 02.04.2018 um 21:55 schrieb Andy Clement 
>:

AspectJ 1.9.0 is finally released, after multiple betas and release candidates. 
 The README can be found here:
https://eclipse.org/aspectj/doc/released/README-190.html - thanks to everyone 
in the community who provided feedback, sample code and test cases to iron out 
as many issues as possible.

The key changes in 1.9.0:
- primary change is that it supports compiling/weaving Java 9 code/modules.
- some new APIs have been added to the runtime jar, these are used by the 
generated code when building join points. It should reduce the amount of class 
loading done at runtime. If you try it out (you need to turn on a flag to try 
it out), any feedback is welcome!
- Incorporates the Spring AOP improvements that were made in recent 1.8.X 
releases.

It should appear in central in the next day or so.

cheers,
Andy
___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: modules versus SDK's

[Mario Ivankovits]

+1 on providing JavaFX as „simple“ dependency.

Question is how to deal with the native libraries. Provide an artifact per 
platform?

compile: 'javafx:javax.graphics-osx:11.0.0'
compile: 'javafx:javax.graphics-win:11.0.0'
compile: 'javafx:javax.graphics-pi:11.0.0‘

These bundles might just contain the native libraries and each of them depend 
on e.g.

compile: 'javafx:javax.graphics:11.0.0‘

which contains just the JavaFX Java sources.

That way one can build a cross-platfrom bundle with all native libraries or a 
slim bundle for a specific target.


Best regards,
Mario

> Am 26.03.2018 um 10:50 schrieb Johan Vos :
> 
> Hi,
> 
> I want to start a discussion on distributing JavaFX as an SDK versus
> distributing its modules via the traditional build and distribution
> mechanisms.
> 
> Personally, I think relying on an SDK is too much a barrier. It requires
> users to manually download software from the exact right place, and
> "install" it on the exact right target. If a version changes, you have to
> manage that manually.
> 
> That is how JavaFX was distributed before it was bundled with the JDK, so
> it makes sense to provide that option (although me and others will probably
> never use that).
> 
> Today however, when a developer has a dependency on a library or framework
> (including property files and native code), he uses his build tools (e.g.
> maven/gradle) to manage the download/install//update of those
> libaries/frameworks.
> If you rely on Spring, Apache Commons, slf4j,... you don't download those
> SDK's but you point to the group-name-version triplet in your pom.xml or
> build.gradle file. I don't see why JavaFX would be different here.
> 
> When someone is new to JavaFX, or is considering JavaFX, I think chances on
> success will be much bigger if that person simply needs to add e.g.
> dependencies {
>compile: 'javafx:javax.graphics:11.0.0'
> }
> to his build.gradle and then rely on gradle (or maven) and jcenter/sonatype
> to make sure the correct version with all its dependencies are installed
> (in a maven/gradle local cache)
> 
> - Johan

Re: Building OpenJFX 9 with OpenJDK 9+181

[Mario Ivankovits]

Hi!

I had the same problems when I tried to build JavaFX for the Raspberry PI this 
weekend.

I „fixed" that by adding the —add-exports to the build.gradle file.
The Google Drive Link will guide you to a hacky patch to the build.gradle file 
(+ some other changes). I was able to build JavaFX then. Beware: This patch 
also disables the systemTests.

https://copy-con.blogspot.co.at/2017/10/java-9-with-javafx-for-raspberry-pi.html#links

Best regards,
Mario


Am 10.10.2017 um 16:15 schrieb Kevin Rushforth 
>:

This sounds like a bootstrap problem. I suspect that we are missing the needed 
--add-exports in build.gradle to build using a JDK that does not already have 
javafx.* modules.

I filed the following bug to track this:

https://bugs.openjdk.java.net/browse/JDK-8189111

As a workaround, you can use the Oracle JDK 9 build as the boot JDK.

-- Kevin


Emmanuel Bourg wrote:
Hi,

I've some trouble building OpenJFX 9 with OpenJDK 9+181 and Gradle 3.2.1
on Debian. I get the following compilation errors:


/home/ebourg/openjfx9/modules/javafx.base/src/main/java/com/sun/javafx/binding/SelectBinding.java:47:
error: package sun.util.logging is not visible
 import sun.util.logging.PlatformLogger.Level;
^
   (package sun.util.logging is declared in module java.base, which
does not export it to module javafx.base)

/home/ebourg/openjfx9/modules/javafx.base/src/main/java/com/sun/javafx/property/PropertyReference.java:36:
error: package sun.reflect.misc is not visible
 import sun.reflect.misc.ReflectUtil;
   ^
   (package sun.reflect.misc is declared in module java.base, which
does not export it to module javafx.base)


I tried exporting the _JAVA_OPTIONS variable defined in
README-java-options and adding --add-opens parameters to build.gradle
but it didn't work.

What am I missing?

Emmanuel Bourg

Re: [aspectj-users] Plans for 1.9.0 release

[Mario Ivankovits]

Hi Andy!

The ant task has a minor bug.

The COMPLIANCE_INPUTS for 1.9 is missing the minus sign.
Without that it is not possible to configure the compliance level and the error
[ant:iajc] [error   0]: error Compliance level '1.4' is incompatible with 
target level '9'. A compliance level '9' or better is required
shows up.

With this fix and the compliance configuration on the ant task I was able to 
build our project and it seems to work as expected.


Index: taskdefs/src/org/aspectj/tools/ant/taskdefs/AjcTask.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- taskdefs/src/org/aspectj/tools/ant/taskdefs/AjcTask.java(revision 
d159d8d96ba83edca8ca7aefdd1ad785912f9164)
+++ taskdefs/src/org/aspectj/tools/ant/taskdefs/AjcTask.java(revision )
@@ -255,7 +255,7 @@

static final String[] TARGET_INPUTS = new String[] { "1.1", "1.2", 
"1.3", "1.4", "1.5", "1.6", "1.7", "1.8", "1.9" };
static final String[] SOURCE_INPUTS = new String[] { "1.3", "1.4", 
"1.5", "1.6", "1.7", "1.8", "1.9" };
-   static final String[] COMPLIANCE_INPUTS = new String[] { "-1.3", 
"-1.4", "-1.5", "-1.6", "-1.7", "-1.8", "1.9" };
+   static final String[] COMPLIANCE_INPUTS = new String[] { "-1.3", 
"-1.4", "-1.5", "-1.6", "-1.7", "-1.8", "-1.9" };

private static final ICommandEditor COMMAND_EDITOR;




Am 25.09.2017 um 19:00 schrieb Andy Clement 
>:

Hey,

1.9.0.BETA-7 is actually there now (spring milestones maven repo), published 
last night.This includes:
- update to latest JDT compiler
- Compilation/weaving performance on Java 9 now similar to Java8.

I am trying to get to an RC very soon but there are a few more things I must do 
before I consider it good enough, my rough target is end of the week but it 
depends on how many distractions I get :)

> right now 1.8.10 version doesn't work in such projects.

It would be helpful for anyone/everyone to share any issues you have with the 
1.9 betas so I can make sure I have them on the TODO list, email here or 
bugzilla issues are fine.

many thanks,
Andy


On 23 September 2017 at 01:25, Krzysztof Krason 
> wrote:
Hello,
Is there a plan for releasing 1.9.0 version soon? I see that there is a 
1.9.0.BETA-6 in Spring Milestones maven repo and I'm wondering if you have some 
plans on releasing it to maven central or creating 1.9.0 and releasing it there?

This would greatly help with projects that want to use Java 9 and AspectJ, 
right now 1.8.10 version doesn't work in such projects.

Regards,
Krzysztof Krason


___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[jira] [Updated] (JSPWIKI-1032) layout and img src fixes

[Mario Ivankovits (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JSPWIKI-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Ivankovits updated JSPWIKI-1032:
--
Attachment: fixed_image_src_link_fixed_layout_in_ie_11.patch

> layout and img src fixes
> 
>
> Key: JSPWIKI-1032
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1032
> Project: JSPWiki
>  Issue Type: Bug
>  Components: Templates and UI
>Affects Versions: 2.10.3
>Reporter: Mario Ivankovits
>Priority: Trivial
> Attachments: fixed_image_src_link_fixed_layout_in_ie_11.patch
>
>
> The attaches patch will fix:
> * Use image "src" attribute instead of "href"
> * Rendering glitches in IE 11 due to different interpretation of flex
> http://stackoverflow.com/questions/21600345/flexbox-and-internet-explorer-11-displayflex-in-html
> > "IE10 and IE11 default values for flex are 0 0 auto rather than 0 1 auto,
> > as per the draft spec, as of September 2013"
> > So in plain words, if somewhere in your CSS you have something like this:
> > flex:1 , that is not translated the same way in all browsers. Try changing 
> > it
> > to 1 0 0 and I believe you will immediately see that it -kinda- works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JSPWIKI-1032) layout and img src fixes

[Mario Ivankovits (JIRA)]

Mario Ivankovits created JSPWIKI-1032:
-

 Summary: layout and img src fixes
 Key: JSPWIKI-1032
 URL: https://issues.apache.org/jira/browse/JSPWIKI-1032
 Project: JSPWiki
  Issue Type: Bug
  Components: Templates and UI
Affects Versions: 2.10.3
Reporter: Mario Ivankovits
Priority: Trivial
 Attachments: fixed_image_src_link_fixed_layout_in_ie_11.patch

The attaches patch will fix:

* Use image "src" attribute instead of "href"
* Rendering glitches in IE 11 due to different interpretation of flex
http://stackoverflow.com/questions/21600345/flexbox-and-internet-explorer-11-displayflex-in-html

> "IE10 and IE11 default values for flex are 0 0 auto rather than 0 1 auto,
> as per the draft spec, as of September 2013"
> So in plain words, if somewhere in your CSS you have something like this:
> flex:1 , that is not translated the same way in all browsers. Try changing it
> to 1 0 0 and I believe you will immediately see that it -kinda- works.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[aspectj-users] Java 9 sun.boot.class.path gone

[Mario Ivankovits]

Hi!

In latest Java 9 builds the „sun.boot.class.path“ is gone. Due to this, the 
core java classes can no longer be found by aspectj.
On AspectJs earlyJava9 branch I’ve patched it like this to make that work again.


Index: weaver/src/org/aspectj/weaver/bcel/ClassPathManager.java
===
--- weaver/src/org/aspectj/weaver/bcel/ClassPathManager.java(revision 
f8b86ff2c03a77e47e87573b59bc43c57cfdee38)
+++ weaver/src/org/aspectj/weaver/bcel/ClassPathManager.java(revision )
@@ -38,6 +38,7 @@

 import org.aspectj.bridge.IMessageHandler;
 import org.aspectj.bridge.MessageUtil;
+import org.aspectj.util.LangUtil;
 import org.aspectj.weaver.BCException;
 import org.aspectj.weaver.UnresolvedType;
 import org.aspectj.weaver.WeaverMessages;
@@ -70,6 +71,11 @@
if (trace.isTraceEnabled())
trace.enter("", this, new Object[] { classpath, 
handler });
entries = new ArrayList();
+
+   if (LangUtil.is19VMOrGreater()) {
+   entries.add(new JImageEntry(null));
+   }
+
for (Iterator i = classpath.iterator(); i.hasNext();) {
String name = i.next();
addPath(name, handler);

Regards,
Mario

smime.p7s
Description: S/MIME cryptographic signature
___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Client reconnect problems

[Mario Ivankovits]

Hi list!

I started to use Ignite (1.1.0-incubating) for a network message bus where I 
have a server node and several client nodes using the TcpClientDiscoverySpi.

On first startup, it does not matter in which order I start my Ignite sever or 
client. Each other waits as expected to have the grid running. But if I kill 
the server, the client fails to reconnect to it.

I have a simple test for this. 
Just start the class TestIgniteClient with program parameter „s“ and again with 
„c“ so you have two instances running. Then you should see the message „I am 
here“ flowing from the server to the client.
Once you kill the server process („s“) and restart it, you will get a lot of 
exception on the client and it will not reconnect.

Is there something I do wrong, or should I file a JIRA about that?

Thanks for your help.


===exception==
SCHWERWIEGEND: Failed to refresh partition map 
[oldest=--0001--0001, rmts=[], 
loc=445a949f-dd26-4998-8c1c-4faa05ceed81]
class org.apache.ignite.IgniteCheckedException: Failed to send message (node 
may have left the grid or TCP connection cannot be established due to firewall 
issues) [node=TcpDiscoveryNode [id=--0001--0001, 
addrs=[10.0.0.102, 0:0:0:0:0:0:0:1, 127.0.0.1], sockAddrs=[/10.0.0.102:8025, 
/0:0:0:0:0:0:0:1:8025, /127.0.0.1:8025], discPort=8025, order=1, intOrder=1, 
loc=false, ver=1.1.0#20150520-sha1:6da491f4, isClient=false], 
topic=TOPIC_CACHE, msg=GridDhtPartitionsSingleMessage 
[parts={-2100569601=GridDhtPartitionMap 
[nodeId=445a949f-dd26-4998-8c1c-4faa05ceed81, updateSeq=4, size=0], 
689859866=GridDhtPartitionMap [nodeId=445a949f-dd26-4998-8c1c-4faa05ceed81, 
updateSeq=4, size=0], 1325947219=GridDhtPartitionMap 
[nodeId=445a949f-dd26-4998-8c1c-4faa05ceed81, updateSeq=4, size=0]}, 
super=GridDhtPartitionsAbstractMessage [exchId=null, lastVer=GridCacheVersion 
[topVer=0, nodeOrderDrId=0, globalTime=0, order=1434179630276], 
super=GridCacheMessage [msgId=4, depInfo=null, err=null, skipPrepare=false]]], 
policy=SYSTEM_POOL]
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:952)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1016)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:389)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.sendLocalPartitions(GridCachePartitionExchangeManager.java:664)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.refreshPartitions(GridCachePartitionExchangeManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.refreshPartitions(GridCachePartitionExchangeManager.java:603)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1700(GridCachePartitionExchangeManager.java:57)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:967)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to send 
message to remote node: TcpDiscoveryNode 
[id=--0001--0001, addrs=[10.0.0.102, 0:0:0:0:0:0:0:1, 
127.0.0.1], sockAddrs=[/10.0.0.102:8025, /0:0:0:0:0:0:0:1:8025, 
/127.0.0.1:8025], discPort=8025, order=1, intOrder=1, loc=false, 
ver=1.1.0#20150520-sha1:6da491f4, isClient=false]
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1574)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:138)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:949)
... 9 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to connect to 
node (is node still alive?). Make sure that each GridComputeTask and 
GridCacheTransaction has a timeout set in order to prevent parties from waiting 
forever in case of network issues [nodeId=--0001--0001, 
addrs=[/0:0:0:0:0:0:0:1:47100, /127.0.0.1:47100, /10.0.0.102:47100]]
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:1842)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:1671)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:1612)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$4000(TcpCommunicationSpi.java:140)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$RecoveryWorker.body(TcpCommunicationSpi.java:2452)
at 

[jira] [Created] (IGNITE-928) Array out of bounds in IgniteUtils.filterReachable

[Mario Ivankovits (JIRA)]

Mario Ivankovits created IGNITE-928:
---

 Summary: Array out of bounds in IgniteUtils.filterReachable
 Key: IGNITE-928
 URL: https://issues.apache.org/jira/browse/IGNITE-928
 Project: Ignite
  Issue Type: Bug
  Components: general
 Environment: Ignite 1.0.5
Reporter: Mario Ivankovits


There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)

public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;

if (addrs.isEmpty())
return Collections.emptyList();

if (addrs.size() == 1) {
if (reachable(addrs.get(1), reachTimeout))
return Collections.singletonList(addrs.get(1));

return Collections.emptyList();
}

Regards,
Mario



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-928) Array out of bounds in IgniteUtils.filterReachable

[Mario Ivankovits (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Ivankovits updated IGNITE-928:

Description: 
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)

{noformat}
public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;

if (addrs.isEmpty())
return Collections.emptyList();

if (addrs.size() == 1) {

if (reachable(addrs.get(1), reachTimeout))

return Collections.singletonList(addrs.get(1));


return Collections.emptyList();
}
{noformat}

Regards,
Mario

  was:
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)

public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;

if (addrs.isEmpty())
return Collections.emptyList();

if (addrs.size() == 1) {

if (reachable(addrs.get(1), reachTimeout))

return Collections.singletonList(addrs.get(1));


return Collections.emptyList();
}

Regards,
Mario


 Array out of bounds in IgniteUtils.filterReachable
 --

 Key: IGNITE-928
 URL: https://issues.apache.org/jira/browse/IGNITE-928
 Project: Ignite
  Issue Type: Bug
  Components: general
 Environment: Ignite 1.0.5
Reporter: Mario Ivankovits

 There is an Array out of bounds exception in IgniteUtils.filterReachable.
 You ask for list size == 1 and then get(1) instead of get(0)
 {noformat}
 public static ListInetAddress filterReachable(ListInetAddress addrs) {
 final int reachTimeout = 2000;
 if (addrs.isEmpty())
 return Collections.emptyList();
 if (addrs.size() == 1) {
 if (reachable(addrs.get(1), reachTimeout))
 return Collections.singletonList(addrs.get(1));
 return Collections.emptyList();
 }
 {noformat}
 Regards,
 Mario



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-928) Array out of bounds in IgniteUtils.filterReachable

[Mario Ivankovits (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Ivankovits updated IGNITE-928:

Description: 
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)

public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;

if (addrs.isEmpty())
return Collections.emptyList();

if (addrs.size() == 1) {

if (reachable(addrs.get(1), reachTimeout))

return Collections.singletonList(addrs.get(1));


return Collections.emptyList();
}

Regards,
Mario

  was:
There is an Array out of bounds exception in IgniteUtils.filterReachable.
You ask for list size == 1 and then get(1) instead of get(0)

public static ListInetAddress filterReachable(ListInetAddress addrs) {
final int reachTimeout = 2000;

if (addrs.isEmpty())
return Collections.emptyList();

if (addrs.size() == 1) {
if (reachable(addrs.get(1), reachTimeout))
return Collections.singletonList(addrs.get(1));

return Collections.emptyList();
}

Regards,
Mario


 Array out of bounds in IgniteUtils.filterReachable
 --

 Key: IGNITE-928
 URL: https://issues.apache.org/jira/browse/IGNITE-928
 Project: Ignite
  Issue Type: Bug
  Components: general
 Environment: Ignite 1.0.5
Reporter: Mario Ivankovits

 There is an Array out of bounds exception in IgniteUtils.filterReachable.
 You ask for list size == 1 and then get(1) instead of get(0)
 public static ListInetAddress filterReachable(ListInetAddress addrs) {
 final int reachTimeout = 2000;
 if (addrs.isEmpty())
 return Collections.emptyList();
 if (addrs.size() == 1) {
 if (reachable(addrs.get(1), reachTimeout))
 return Collections.singletonList(addrs.get(1));
 return Collections.emptyList();
 }
 Regards,
 Mario



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: NPE in VirtualFlow

[Mario Ivankovits]

Thanks!

I’ve created the issue for this https://javafx-jira.kenai.com/browse/RT-39752 
and will try to create a test case in the next few days.

Best regards,
Mario


Am 02.01.2015 um 22:18 schrieb Chien Yang 
chien.y...@oracle.commailto:chien.y...@oracle.com:

The closest I can find that is somewhat related to TableView and NPE, but not 
exactly the same issue is the following JIRA:

https://javafx-jira.kenai.com/browse/RT-39624

Please file a JIRA once you have a reproducible test case ready. Here is a link 
on how to file a bug report with us:
https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report

Thanks,
- Chien

On 12/26/2014 1:30 AM, Mario Ivankovits wrote:
Hi!

Every now and then I get the exception down there (starting with JavaFX 
8u40-b18 if I remember correctly)

It seems it has something to to with the fact that the items list of one of my 
TableViews gets cleared and so no cells are visible any more.
I was not yet able to always reproduce that. I will try to do that, but 
probably someone has a clue anyway?

BR,
Mario

java.lang.NullPointerException
at 
com.sun.javafx.scene.control.skin.VirtualFlow.getCellIndex(VirtualFlow.java:1726)
at 
com.sun.javafx.scene.control.skin.VirtualFlow.addLeadingCells(VirtualFlow.java:1274)
at 
com.sun.javafx.scene.control.skin.VirtualFlow.layoutChildren(VirtualFlow.java:1194)
at 
com.sun.javafx.scene.control.skin.VirtualFlow.setCellCount(VirtualFlow.java:231)
at 
com.sun.javafx.scene.control.skin.TableViewSkinBase.updateRowCount(TableViewSkinBase.java:554)
at 
com.sun.javafx.scene.control.skin.VirtualContainerBase.checkState(VirtualContainerBase.java:113)
at 
com.sun.javafx.scene.control.skin.VirtualContainerBase.layoutChildren(VirtualContainerBase.java:108)
at 
com.sun.javafx.scene.control.skin.TableViewSkinBase.layoutChildren(TableViewSkinBase.java:683)
at javafx.scene.control.Control.layoutChildren(Control.java:576)
at javafx.scene.Parent.layout(Parent.java:1076)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Scene.doLayoutPass(Scene.java:552)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2397)
at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:314)
at com.sun.javafx.tk.Toolkit$$Lambda$243/122134773.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:313)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:340)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:525)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334)
at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$41/2090707712.run(Unknown 
Source)
at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)

NPE in VirtualFlow

[Mario Ivankovits]

Hi!

Every now and then I get the exception down there (starting with JavaFX 
8u40-b18 if I remember correctly)

It seems it has something to to with the fact that the items list of one of my 
TableViews gets cleared and so no cells are visible any more.
I was not yet able to always reproduce that. I will try to do that, but 
probably someone has a clue anyway?

BR,
Mario

java.lang.NullPointerException
at 
com.sun.javafx.scene.control.skin.VirtualFlow.getCellIndex(VirtualFlow.java:1726)
at 
com.sun.javafx.scene.control.skin.VirtualFlow.addLeadingCells(VirtualFlow.java:1274)
at 
com.sun.javafx.scene.control.skin.VirtualFlow.layoutChildren(VirtualFlow.java:1194)
at 
com.sun.javafx.scene.control.skin.VirtualFlow.setCellCount(VirtualFlow.java:231)
at 
com.sun.javafx.scene.control.skin.TableViewSkinBase.updateRowCount(TableViewSkinBase.java:554)
at 
com.sun.javafx.scene.control.skin.VirtualContainerBase.checkState(VirtualContainerBase.java:113)
at 
com.sun.javafx.scene.control.skin.VirtualContainerBase.layoutChildren(VirtualContainerBase.java:108)
at 
com.sun.javafx.scene.control.skin.TableViewSkinBase.layoutChildren(TableViewSkinBase.java:683)
at javafx.scene.control.Control.layoutChildren(Control.java:576)
at javafx.scene.Parent.layout(Parent.java:1076)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Scene.doLayoutPass(Scene.java:552)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2397)
at com.sun.javafx.tk.Toolkit.lambda$runPulse$30(Toolkit.java:314)
at com.sun.javafx.tk.Toolkit$$Lambda$243/122134773.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:313)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:340)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:525)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334)
at 
com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$41/2090707712.run(Unknown 
Source)
at 
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)

IOOB and null values in ComboBox

[Mario Ivankovits]

Hi!

Hi!

I am having a list of ComboBox entries where the first entry often is „null“, 
which means e.g. ALL

Now, with 8u40-b04 I am getting IOOB exception when I select a null value in 
any ComboBox.

I tracked it down to ComboBoxListViewSkin.updateValue where the list of 
selections is cleared if the ComboBox.getValue() returns „null“.

I see quite a lot of checks against „null“, e.g. in 
MultipleSelectionModelBase.select(Object), so that a patch might be a lot of 
work.

Are „null values not supported?


Best regards,
Mario

The final exception:
java.lang.IndexOutOfBoundsException
at 
com.sun.javafx.scene.control.ReadOnlyUnbackedObservableList.subList(ReadOnlyUnbackedObservableList.java:136)
at 
javafx.collections.ListChangeListener$Change.getAddedSubList(ListChangeListener.java:242)
at 
com.sun.javafx.scene.control.behavior.ListViewBehavior.lambda$new$178(ListViewBehavior.java:264)
at 
com.sun.javafx.scene.control.behavior.ListViewBehavior$$Lambda$586/903982873.onChanged(Unknown
 Source)
at 
javafx.collections.WeakListChangeListener.onChanged(WeakListChangeListener.java:88)
at 
com.sun.javafx.collections.ListListenerHelper$Generic.fireValueChangedEvent(ListListenerHelper.java:329)
at 
com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:73)
at 
com.sun.javafx.scene.control.ReadOnlyUnbackedObservableList.callObservers(ReadOnlyUnbackedObservableList.java:75)
at 
javafx.scene.control.MultipleSelectionModelBase.clearAndSelect(MultipleSelectionModelBase.java:331)
at 
javafx.scene.control.ListView$ListViewBitSetSelectionModel.clearAndSelect(ListView.java:1440)
at 
com.sun.javafx.scene.control.behavior.CellBehaviorBase.simpleSelect(CellBehaviorBase.java:260)
at 
com.sun.javafx.scene.control.behavior.CellBehaviorBase.doSelect(CellBehaviorBase.java:224)
at 
com.sun.javafx.scene.control.behavior.CellBehaviorBase.mousePressed(CellBehaviorBase.java:150)
at 
com.sun.javafx.scene.control.skin.BehaviorSkinBase$1.handle(BehaviorSkinBase.java:95)
at 
com.sun.javafx.scene.control.skin.BehaviorSkinBase$1.handle(BehaviorSkinBase.java:89)
at 
com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:218)
at 
com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
at 
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:238)
at 
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
at 
com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
at 
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
at 
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at 
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at 
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at 
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at 
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at 
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at 
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at 
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at 
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
at javafx.event.Event.fireEvent(Event.java:198)
at javafx.scene.Scene$MouseHandler.process(Scene.java:3719)
at javafx.scene.Scene$MouseHandler.access$1500(Scene.java:3447)
at javafx.scene.Scene.impl_processMouseEvent(Scene.java:1723)
at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2456)
at 
com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:350)
at 
com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:275)
at java.security.AccessController.doPrivileged(Native Method)
at 
com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$344(GlassViewEventHandler.java:385)
at 
com.sun.javafx.tk.quantum.GlassViewEventHandler$$Lambda$244/792645374.get(Unknown
 Source)
at 
com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:386)
at 

outstanding resource locks

[Mario Ivankovits]

Hi!

Is there anything further I can do to see which resources are locked so I can 
see if this is my fault and to release them properly?
How to interpret this output?

Thanks for any info.   


Outstanding resource locks detected:
ES2 Vram Pool: 76.571.592 used (28,5%), 76.571.592 managed (28,5%), 268.435.456 
total
118 total resources being managed
average resource age is 540,5 frames
57 resources at maximum supported age (48,3%)
6 resources marked permanent (5,1%)
2 resources have had mismatched locks (1,7%)
2 resources locked (1,7%)
79 resources contain interesting data (66,9%)
0 resources disappeared (0,0%)

Outstanding resource locks detected:
ES2 Vram Pool: 141.193.956 used (52,6%), 141.193.956 managed (52,6%), 
268.435.456 total
136 total resources being managed
average resource age is 467,8 frames
57 resources at maximum supported age (41,9%)
6 resources marked permanent (4,4%)
5 resources have had mismatched locks (3,7%)
5 resources locked (3,7%)
82 resources contain interesting data (60,3%)
0 resources disappeared (0,0%)


Best regards,
Mario

[jira] [Commented] (VFS-210) Wrapper-Mode VFS

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999688#comment-13999688
 ] 

Mario Ivankovits commented on VFS-210:
--

Hi Bernd!

Sorry for my late response. Sure, you can do whatever it requires to keep the 
project running! Thanks for that!

Best regards,
Mario

 Wrapper-Mode VFS
 

 Key: VFS-210
 URL: https://issues.apache.org/jira/browse/VFS-210
 Project: Commons VFS
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
 Fix For: 2.1


 VFS should behave more like a wrapper to the underlaying library than a full 
 blown filesystem.
 This should solve the following problems:
 * access of hidden files/directories
 * access to special folders
 * speed up FTP access



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: Ability to decorate ChangeListener

[Mario Ivankovits]

Thanks for your answer!

One thing, I think, we can agree on, is that it is overly complex for an OO 
language to decorate things like these listeners.
What about introducing another interface like ChangeListenerDecoration with a 
special named „boolean decorates(ChangeListener)) method and call this if the 
listeners hold by *ExpressionHelp class implements that interface?

BTW: If we care about symmetry, why not change the 
listener.equals(otherListener) to listener == otherListener at all? Then, there 
are not implementation details one can make use of.
I even might argue that it is a security risk to use the .equals() the way it 
is now, as an evil listener implementation is able to remove all listeners from 
the list by simply returning true from equals()
It should be the responsibility of the listener in the list to know if the 
passed in listener justify the removal of itself, right? … from a security 
standpoint! :-) 

Regards,
Mario


Am 24.03.2014 um 07:31 schrieb Martin Sladecek martin.slade...@oracle.com:

 Mario,
 thanks for your suggestion, but I think your specific case will not justify 
 the change. First of all, as it was already said, equals should be symmetric. 
 Knowing the implementation, you could rely on the fact that either the equals 
 is called on the provided listener or on the listeners already in the list. 
 Might be that somebody else would need the asymmetry to be implemented in the 
 listener provided to removeListener() method and the current situation 
 suits him, so why do the change for your case?
 
 Anyway, relying on some implementation-specific behaviour is generally a sign 
 of bad code practice, so it should give you a hint that you should find a 
 different solution (like the one you discussed with Tomas already). It might 
 happen that the code would be changed / re-factored in the future or some bug 
 would be fixed there and behaviour will change again, breaking your 
 application in some future JFX version.
 
 Regards,
 -Martin
 
 
 On 22.3.2014 15:47, Mario Ivankovits wrote:
 The only thing which I ask for is to flip this „if in the *ExpressionHelper 
 classes:
 So, JavaFX does not break anything and it is up to the app developer to take 
 the risk or not.
 
 
if (listener.equals(changeListeners[index])) {
 
 If we flip this to
 
if (changeListeners[index].equals(listener))
 
 
 
 Am 22.03.2014 um 15:42 schrieb Kevin Rushforth 
 kevin.rushfo...@oracle.commailto:kevin.rushfo...@oracle.com:
 
 If you are talking about a change to the JavaFX API, we are not likely to 
 accept such a change if it breaks the contract of equals() or hashcode(). In 
 your own app it may not matter, but it is dangerous to assume it won't 
 matter to anyone. Martin owns the core libraries and can comment further.
 
 -- Kevin
 
 
 Mario Ivankovits wrote:
 
 Hi Thomas!
 
 Thanks for your input. Because I want to decorated listeners added by JavaFX 
 core I can not use the sub/unsub pattern.
 Your second proposal is almost what I do right now. In removeListener I 
 consult a map where the decorated listeners and their undecorated one lives.
 
 Regarding the symmetric doubts. Such listeners will always be removed by 
 passing in the undecorated object to removeListener.
 They should act like a transparent proxy.
 
 Even if this breaks the equals paradigm, in this special case I can 
 perfectly live with an equals/hashCode implementation like this below.
 It won’t break your app; as long as both objects do not live in the same 
 HashSet/Map …. for sure - but why should they?
 
 @Override
 public boolean equals(Object obj)
 {
 return obj == delegate; //  this == obj
 }
 
 @Override
 public int hashCode()
 {
 return delegate.hashCode();
 }
 
 
 Regards,
 Mario
 
 
 Am 22.03.2014 um 14:22 schrieb Tomas Mikula 
 tomas.mik...@gmail.commailto:tomas.mik...@gmail.com:
 
 
 
 A simpler and more universal solution is to also override removeListener:
 
 public void removeListener(ChangeListener? super T listener) {
super.removeListener(decorated(listener));
 }
 
 And the equals() method on decorated listeners only compares the
 delegates (thus is symmetric).
 
 Regards,
 Tomas
 
 
 On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula 
 tomas.mik...@gmail.commailto:tomas.mik...@gmail.com wrote:
 
 
 The suspicious thing about your solution is that your smart
 implementation of equals() is not symmetric.
 
 In case the observable value is visible only within your project, you
 could do this:
 
interface Subscription {
void unsubscribe();
}
 
class MyObservableValueT implements ObservableValueT {
public Subscription subscribe(ChangeListener? extends T listener) {
ChangeListenerT decorated = decorate(listener);
   addListener(decorated);
   return () - removeListener(decorated);
}
}
 
 and use subscribe()/unsubscribe() instead of addListener()/removeListener

Re: Ability to decorate ChangeListener

[Mario Ivankovits]

Am 24.03.2014 um 15:36 schrieb Martin Sladecek martin.slade...@oracle.com:

 On 24.3.2014 15:24, Mario Ivankovits wrote:
 But, after this discussion I do not see why one ever used .equals() at all.
 
 Look, it does not fit my needs, I do not see any use-case where one would 
 add an removeListener with asymmetric .equals() and thus it is better you 
 use == I think.
 This clarifies that EXACTLY the added listener instance is required to 
 remove any listener AND it gives no room to discussions like we had because 
 the indention is perfectly clear - even to those reading JavaFX core code 
 and bug fixing things in JavaFX.
 For me this would be fine and understandable - I will go the 
 decorator-cache-map so I will be fine always.
 
 One example might be in bidirectional binding. There's a special listener 
 that takes the 2 properties that are bound together and it's equals returns 
 true if the other listener is of the same class and it's two properties (no 
 matter in what order) are identical. This way, you can just write 
 Bindings.unbindBidirectional() and the internal implementation does not need 
 to remember the listener instance anywhere. The equals() is symmetric in this 
 case, but == would not work here.
 
 -Martin

Ah - Thanks for this lesson!
:-)

OMG … just looked up the code. The implementation of BidirectionalBinding uses 
weak references and it might happen that you ExpressionHelperBase.trim() them 
out of the listener list if either side of the bound property got garbage 
collected.
This means, if I decorated them, they will stay in my map because there is 
add/removeListener asymmetry. (just to use the word symmetry again ;-) )

So, it is even more complicated to decorate that stuff.
How much I’d love to see a DecoratedListener interface like you have for 
WeakListener … but yay … :-(


Thanks for listening anyway! :-)

Regards,
Mario

Re: Ability to decorate ChangeListener

[Mario Ivankovits]

Hi Thomas!

Thanks for your input. Because I want to decorated listeners added by JavaFX 
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult 
a map where the decorated listeners and their undecorated one lives.

Regarding the symmetric doubts. Such listeners will always be removed by 
passing in the undecorated object to removeListener.
They should act like a transparent proxy.

Even if this breaks the equals paradigm, in this special case I can perfectly 
live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same 
HashSet/Map …. for sure - but why should they? 

@Override
public boolean equals(Object obj)
{
return obj == delegate; //  this == obj
}

@Override
public int hashCode()
{
return delegate.hashCode();
}


Regards,
Mario


Am 22.03.2014 um 14:22 schrieb Tomas Mikula tomas.mik...@gmail.com:

 A simpler and more universal solution is to also override removeListener:
 
 public void removeListener(ChangeListener? super T listener) {
super.removeListener(decorated(listener));
 }
 
 And the equals() method on decorated listeners only compares the
 delegates (thus is symmetric).
 
 Regards,
 Tomas
 
 
 On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula tomas.mik...@gmail.com wrote:
 The suspicious thing about your solution is that your smart
 implementation of equals() is not symmetric.
 
 In case the observable value is visible only within your project, you
 could do this:
 
interface Subscription {
void unsubscribe();
}
 
class MyObservableValueT implements ObservableValueT {
public Subscription subscribe(ChangeListener? extends T listener) {
ChangeListenerT decorated = decorate(listener);
   addListener(decorated);
   return () - removeListener(decorated);
}
}
 
 and use subscribe()/unsubscribe() instead of addListener()/removeListener():
 
Subscription sub = observableValue.subscribe(listener);
// ...
sub.unsubscribe();
 
 Of course this is not possible if you need to pass the observable
 value to the outside world as ObservableValue.
 
 Regards,
 Tomas
 
 On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits ma...@datenwort.at wrote:
 Hi!
 
 In one of my ObservableValue implementations I do have the need to decorate 
 ChangeListener added to it.
 Today this is somewhat complicated to implement, as I have to keep a map of 
 the original listener to the decorated one to being able to handle the 
 removal process of a listener. Because the outside World did not know that 
 I decorated the listener and the instance passed in to removeListener ist 
 the undecorated one.
 
 We can make things easier with a small change in 
 ExpressionHelper.removeListener. When iterating through the listener list, 
 the listener passed in as argument to removeListener is asked if it is 
 equal to the one stored
 
if (listener.equals(changeListeners[index])) {
 
 If we flip this to
 
if (changeListeners[index].equals(listener)) {
 
 a listener decoration can be smart enough to not only check against itself, 
 but also against its delegate.
 
 What do you think?
 
 I could prepare a patch for the *ExpressionHelper classes.
 
 
 Best regards,
 Mario
 
 

Re: Ability to decorate ChangeListener

[Mario Ivankovits]

The only thing which I ask for is to flip this „if in the *ExpressionHelper 
classes:
So, JavaFX does not break anything and it is up to the app developer to take 
the risk or not.


   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener))



Am 22.03.2014 um 15:42 schrieb Kevin Rushforth 
kevin.rushfo...@oracle.commailto:kevin.rushfo...@oracle.com:

If you are talking about a change to the JavaFX API, we are not likely to 
accept such a change if it breaks the contract of equals() or hashcode(). In 
your own app it may not matter, but it is dangerous to assume it won't matter 
to anyone. Martin owns the core libraries and can comment further.

-- Kevin


Mario Ivankovits wrote:

Hi Thomas!

Thanks for your input. Because I want to decorated listeners added by JavaFX 
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult 
a map where the decorated listeners and their undecorated one lives.

Regarding the symmetric doubts. Such listeners will always be removed by 
passing in the undecorated object to removeListener.
They should act like a transparent proxy.

Even if this breaks the equals paradigm, in this special case I can perfectly 
live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same 
HashSet/Map …. for sure - but why should they?

@Override
public boolean equals(Object obj)
{
return obj == delegate; //  this == obj
}

@Override
public int hashCode()
{
return delegate.hashCode();
}


Regards,
Mario


Am 22.03.2014 um 14:22 schrieb Tomas Mikula 
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com:



A simpler and more universal solution is to also override removeListener:

public void removeListener(ChangeListener? super T listener) {
   super.removeListener(decorated(listener));
}

And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).

Regards,
Tomas


On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula 
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com wrote:


The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.

In case the observable value is visible only within your project, you
could do this:

   interface Subscription {
   void unsubscribe();
   }

   class MyObservableValueT implements ObservableValueT {
   public Subscription subscribe(ChangeListener? extends T listener) {
   ChangeListenerT decorated = decorate(listener);
  addListener(decorated);
  return () - removeListener(decorated);
   }
   }

and use subscribe()/unsubscribe() instead of addListener()/removeListener():

   Subscription sub = observableValue.subscribe(listener);
   // ...
   sub.unsubscribe();

Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.

Regards,
Tomas

On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits 
ma...@datenwort.atmailto:ma...@datenwort.at wrote:


Hi!

In one of my ObservableValue implementations I do have the need to decorate 
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of the 
original listener to the decorated one to being able to handle the removal 
process of a listener. Because the outside World did not know that I decorated 
the listener and the instance passed in to removeListener ist the undecorated 
one.

We can make things easier with a small change in 
ExpressionHelper.removeListener. When iterating through the listener list, the 
listener passed in as argument to removeListener is asked if it is equal to the 
one stored

   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener)) {

a listener decoration can be smart enough to not only check against itself, but 
also against its delegate.

What do you think?

I could prepare a patch for the *ExpressionHelper classes.


Best regards,
Mario

Re: Ability to decorate ChangeListener

[Mario Ivankovits]

Yep, null throws a NullPointerException in addListener by design (also in 
removeListener) - the listener collection is safe.



Am 22.03.2014 um 15:50 schrieb Kevin Rushforth 
kevin.rushfo...@oracle.commailto:kevin.rushfo...@oracle.com:

What if changeListeners[index] is null? Maybe this is already illegal

Anyway, let's see what Martin has to say. In the mean time you file a JIRA 
enhancement request (issuetype=Tweak) if you like.

-- Kevin


Mario Ivankovits wrote:
The only thing which I ask for is to flip this „if in the *ExpressionHelper 
classes:
So, JavaFX does not break anything and it is up to the app developer to take 
the risk or not.


   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener))



Am 22.03.2014 um 15:42 schrieb Kevin Rushforth 
kevin.rushfo...@oracle.commailto:kevin.rushfo...@oracle.com:

If you are talking about a change to the JavaFX API, we are not likely to 
accept such a change if it breaks the contract of equals() or hashcode(). In 
your own app it may not matter, but it is dangerous to assume it won't matter 
to anyone. Martin owns the core libraries and can comment further.

-- Kevin


Mario Ivankovits wrote:

Hi Thomas!

Thanks for your input. Because I want to decorated listeners added by JavaFX 
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult 
a map where the decorated listeners and their undecorated one lives.

Regarding the symmetric doubts. Such listeners will always be removed by 
passing in the undecorated object to removeListener.
They should act like a transparent proxy.

Even if this breaks the equals paradigm, in this special case I can perfectly 
live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same 
HashSet/Map …. for sure - but why should they?

@Override
public boolean equals(Object obj)
{
return obj == delegate; //  this == obj
}

@Override
public int hashCode()
{
return delegate.hashCode();
}


Regards,
Mario


Am 22.03.2014 um 14:22 schrieb Tomas Mikula 
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com:



A simpler and more universal solution is to also override removeListener:

public void removeListener(ChangeListener? super T listener) {
   super.removeListener(decorated(listener));
}

And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).

Regards,
Tomas


On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula 
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com wrote:


The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.

In case the observable value is visible only within your project, you
could do this:

   interface Subscription {
   void unsubscribe();
   }

   class MyObservableValueT implements ObservableValueT {
   public Subscription subscribe(ChangeListener? extends T listener) {
   ChangeListenerT decorated = decorate(listener);
  addListener(decorated);
  return () - removeListener(decorated);
   }
   }

and use subscribe()/unsubscribe() instead of addListener()/removeListener():

   Subscription sub = observableValue.subscribe(listener);
   // ...
   sub.unsubscribe();

Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.

Regards,
Tomas

On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits 
ma...@datenwort.atmailto:ma...@datenwort.at wrote:


Hi!

In one of my ObservableValue implementations I do have the need to decorate 
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of the 
original listener to the decorated one to being able to handle the removal 
process of a listener. Because the outside World did not know that I decorated 
the listener and the instance passed in to removeListener ist the undecorated 
one.

We can make things easier with a small change in 
ExpressionHelper.removeListener. When iterating through the listener list, the 
listener passed in as argument to removeListener is asked if it is equal to the 
one stored

   if (listener.equals(changeListeners[index])) {

If we flip this to

   if (changeListeners[index].equals(listener)) {

a listener decoration can be smart enough to not only check against itself, but 
also against its delegate.

What do you think?

I could prepare a patch for the *ExpressionHelper classes.


Best regards,
Mario

Re: Ability to decorate ChangeListener

[Mario Ivankovits]

Probably you avoid the map, but it requires to decorate the listener again, 
right?
If you think about the tons of observable values and add/removeListener 
operations in an tree view when scrolling it might get costly and put pressure 
on the GC.

Anyway, I will be more than happy to assist with a cleaner solution by 
introduction an interface like DecoratedChangeListener which provides a special 
.equalsChangeListener(ChangeListener other) method.


Am 22.03.2014 um 15:55 schrieb Tomas Mikula 
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com:

Hi Mario,

even if your proposal gets accepted, you would still depend on an
implementation detail of JavaFX, which is always good to avoid.

To sum up, my second proposal compared to your current solution:

(+) your equals() stays symmetric;
(+) no need for an extra Map of listeners.

My second proposal compared to your desired solution if your proposal
is accepted:

(+) your equals() stays symmetric;
(+) you don't depend on an implementation detail in JavaFX.

Best,
Tomas

On Sat, Mar 22, 2014 at 3:47 PM, Mario Ivankovits 
ma...@datenwort.atmailto:ma...@datenwort.at wrote:
The only thing which I ask for is to flip this „if in the *ExpressionHelper
classes:
So, JavaFX does not break anything and it is up to the app developer to take
the risk or not.

  if (listener.equals(changeListeners[index])) {

If we flip this to

  if (changeListeners[index].equals(listener))




Am 22.03.2014 um 15:42 schrieb Kevin Rushforth 
kevin.rushfo...@oracle.commailto:kevin.rushfo...@oracle.com:

If you are talking about a change to the JavaFX API, we are not likely to
accept such a change if it breaks the contract of equals() or hashcode(). In
your own app it may not matter, but it is dangerous to assume it won't
matter to anyone. Martin owns the core libraries and can comment further.

-- Kevin


Mario Ivankovits wrote:

Hi Thomas!

Thanks for your input. Because I want to decorated listeners added by JavaFX
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I
consult a map where the decorated listeners and their undecorated one lives.

Regarding the symmetric doubts. Such listeners will always be removed by
passing in the undecorated object to removeListener.
They should act like a transparent proxy.

Even if this breaks the equals paradigm, in this special case I can
perfectly live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same
HashSet/Map …. for sure - but why should they?

   @Override
   public boolean equals(Object obj)
   {
   return obj == delegate; //  this == obj
   }

   @Override
   public int hashCode()
   {
   return delegate.hashCode();
   }


Regards,
Mario


Am 22.03.2014 um 14:22 schrieb Tomas Mikula 
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com:



A simpler and more universal solution is to also override removeListener:

public void removeListener(ChangeListener? super T listener) {
  super.removeListener(decorated(listener));
}

And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).

Regards,
Tomas


On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula 
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com
wrote:


The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.

In case the observable value is visible only within your project, you
could do this:

  interface Subscription {
  void unsubscribe();
  }

  class MyObservableValueT implements ObservableValueT {
  public Subscription subscribe(ChangeListener? extends T listener) {
  ChangeListenerT decorated = decorate(listener);
 addListener(decorated);
 return () - removeListener(decorated);
  }
  }

and use subscribe()/unsubscribe() instead of addListener()/removeListener():

  Subscription sub = observableValue.subscribe(listener);
  // ...
  sub.unsubscribe();

Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.

Regards,
Tomas

On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits 
ma...@datenwort.atmailto:ma...@datenwort.at
wrote:


Hi!

In one of my ObservableValue implementations I do have the need to decorate
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of
the original listener to the decorated one to being able to handle the
removal process of a listener. Because the outside World did not know that I
decorated the listener and the instance passed in to removeListener ist the
undecorated one.

We can make things easier with a small change in
ExpressionHelper.removeListener. When iterating through the listener list,
the listener passed in as argument to removeListener is asked if it is equal
to the one stored

  if (listener.equals(changeListeners[index])) {

If we flip

Ability to decorate ChangeListener

[Mario Ivankovits]

Hi!

In one of my ObservableValue implementations I do have the need to decorate 
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of the 
original listener to the decorated one to being able to handle the removal 
process of a listener. Because the outside World did not know that I decorated 
the listener and the instance passed in to removeListener ist the undecorated 
one.

We can make things easier with a small change in 
ExpressionHelper.removeListener. When iterating through the listener list, the 
listener passed in as argument to removeListener is asked if it is equal to the 
one stored

if (listener.equals(changeListeners[index])) {

If we flip this to

if (changeListeners[index].equals(listener)) {

a listener decoration can be smart enough to not only check against itself, but 
also against its delegate.

What do you think?

I could prepare a patch for the *ExpressionHelper classes.


Best regards,
Mario

AW: ntlm with ms exchange server not working since java 1.7

[Mario Ivankovits]

Hi!

I too did a lot of research on the internet regarding this http header field 
... and didn't find something which defines a correct behavior for the server 
during the negotiation phase.
The two phases the NTLM requires is a Microsoft extension, covered in many 
details, but not able to answer this special question.

Though, the first 401 response is definitely allowed to respond with multiple 
www-authenticate values. Be it comma-separated or by sending the field multiple 
times.
This can be found in [1]  section 14.47 (something you experts are surely aware 
of .. *trying not to step on some ones toes* ;-) )
Further in [2] you can read, that a client should pick the most secure method 
it supports and start authentication then.

Well, not much of news till here.

Now my interpretation of the above: A client should pick the most secure 
authentication it is able to serve for the server and try this method. On 
failure, try the next method.
With this in mind, I setup an IIS site which allows Negotiate, NTLM, Digest and 
Basic and tried to open an java.net.URL against it.
To my surprise Digest will be chosen first (this is documented in 
sun.net.www.protocol.http.AuthenticationHeader, but wrong I think, shouldn't it 
be read like this:  negotiate - kerberos - ntlm - digest - basic) - also no 
other method will be tried yet.

Said that, I think the correct solution to this case will be to capture the 
already tried authentication methods until we don't know how to proceed.
Instead of passing dontUseNegotiate to the AuthenticationHeader, we will pass 
in a Set of already tried authentication methods.
This also should make it possible to avoid the use of inNegotiate. 
 
What do you think?
I think I am going to play a bit with this idea ... :-)

Ciao,
Mario

[1] http://www.ietf.org/rfc/rfc2616.txt
[2] http://msdn.microsoft.com/en-us/library/aa479391.aspx

-Ursprüngliche Nachricht-
Von: Weijun Wang [mailto:weijun.w...@oracle.com] 
Gesendet: Montag, 10. Oktober 2011 17:33
An: Chris Hegarty
Cc: Mario Ivankovits; net-dev@openjdk.java.net
Betreff: Re: ntlm with ms exchange server not working since java 1.7

During an NTLM handshake, I've never seen a server mentioning another scheme. 
As seen in message #4, the NTLM header still contains data, so there should not 
be WWW-Authenticate: Negotiate header.

That said, this is only my experience. I tried to find any words on this from 
an RFC but failed.

-Max



On Oct 10, 2011, at 7:48 AM, Chris Hegarty chris.hega...@oracle.com wrote:

 Max [to'ed],
 
 Does this look familiar? Is it wrong for the server to be returning 
 WWW-Authenticate: Negotiate during NTLM handshake?
 
 -Chris.
 
 On 08/10/2011 14:41, Mario Ivankovits wrote:
 Hi net-devs,
 
 I hope you do not mind that I post to this list, but I hope I can 
 provide enough in-depth information about the problem to justify the 
 post here.
 
 Accessing a “normal” ntlm protected resource – a simple index.html in 
 an protected directory on an IIS 7.5 server - the ntlm authentication 
 works fine.
 
 However, trying to access the Microsoft Exchange 2010 webservice 
 failes with “401 Unauthorized”.
 
 I used this few lines to debug the connection/authentication process
 
 URL url = new URL(https://exchange/ews/Services.wsdl;);
 
 byte[] buf = new byte[10240];
 
 int read = url.openStream().read(buf);
 
 System.err.println(new String(buf, 0, read));
 
 This snipped works fine in java 1.6, but failes with an IOException 
 (http status 401) in java 1.7.
 
 I found an interesting difference when accessing the “normal” 
 web-page and the exchange webservice.
 
 When accessing the web-page, the server answers “WWW-Authenticate:
 Negotiate” just after the first 401 response which triggers the 
 authentication process then. In contrast, when accessing the Exchange 
 webservice the “WWW-Authenticate: Negotiate” is sent during the 
 negotiation process too, which then triggers the inNegotiate flag in 
 sun.net.www.protocol.http.HttpURLConnection in getInputStream and let 
 the negotiation process fail.
 
 If I hack the response values and change any subsequent Negotiate to 
 e.g. NegotiateXX, then the inNegotiate flag will not change and the 
 authentication process will finish and authentication finally works.
 
 Here is the request/response cycle which fail then:
 
 #1: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent:
 Java/1.7.0_02-ea}{Host: exchange }{Accept: text/html, image/gif, 
 image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}
 
 #2: {null: HTTP/1.1 401 Unauthorized}{Server:
 Microsoft-IIS/7.5}{WWW-Authenticate: Negotiate}{WWW-Authenticate:
 NTLM}{X-Powered-By: ASP.NET}{Date: Sat, 08 Oct 2011 13:17:39
 GMT}{Content-Length: 0}
 
 #3: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent:
 Java/1.7.0_02-ea}{Host: exchange }{Accept: text/html, image/gif, 
 image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}{Authorization:
 NTLM MY_NTLM_DATA}
 
 #4: {null: HTTP/1.1 401 Unauthorized}{Server

ntlm with ms exchange server not working since java 1.7

[Mario Ivankovits]

Hi net-devs,

I hope you do not mind that I post to this list, but I hope I can provide 
enough in-depth information about the problem to justify the post here.


Accessing a normal ntlm protected resource - a simple index.html in an 
protected directory on an IIS 7.5 server - the ntlm authentication works fine.
However, trying to access the Microsoft Exchange 2010 webservice failes with 
401 Unauthorized.

I used this few lines to debug the connection/authentication process
URL url = new URL(https://exchange/ews/Services.wsdl;);
byte[] buf = new byte[10240];
int read = url.openStream().read(buf);
System.err.println(new String(buf, 0, read));

This snipped works fine in java 1.6, but failes with an IOException (http 
status 401) in java 1.7.


I found an interesting difference when accessing the normal web-page and the 
exchange webservice.

When accessing the web-page, the server answers WWW-Authenticate: Negotiate 
just after the first 401 response which triggers the authentication process 
then. In contrast, when accessing the Exchange webservice the 
WWW-Authenticate: Negotiate is sent during the negotiation process too, which 
then triggers the inNegotiate flag in 
sun.net.www.protocol.http.HttpURLConnection in getInputStream and let the 
negotiation process fail.
If I hack the response values and change any subsequent Negotiate to e.g. 
NegotiateXX, then the inNegotiate flag will not change and the authentication 
process will finish and authentication finally works.

Here is the request/response cycle which fail then:

#1: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent: Java/1.7.0_02-ea}{Host: 
exchange }{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; 
q=.2}{Connection: keep-alive}
#2: {null: HTTP/1.1 401 Unauthorized}{Server: 
Microsoft-IIS/7.5}{WWW-Authenticate: Negotiate}{WWW-Authenticate: 
NTLM}{X-Powered-By: ASP.NET}{Date: Sat, 08 Oct 2011 13:17:39 
GMT}{Content-Length: 0}
#3: {GET /ews/Services.wsdl HTTP/1.1: null}{User-Agent: Java/1.7.0_02-ea}{Host: 
exchange }{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; 
q=.2}{Connection: keep-alive}{Authorization: NTLM MY_NTLM_DATA}
#4: {null: HTTP/1.1 401 Unauthorized}{Server: 
Microsoft-IIS/7.5}{WWW-Authenticate: NTLM SERVER_NTLM_DATA}{WWW-Authenticate: 
Negotiate}{X-Powered-By: ASP.NET}{Date: Sat, 08 Oct 2011 13:17:39 
GMT}{Content-Length: 0}

Exception in thread main java.io.IOException: Server returned HTTP response 
code: 401 for URL: https://exchange/ews/Services.wsdl
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1612)
at 
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
at java.net.URL.openStream(URL.java:1035)



Does this make sense to you?
It seems to me the inNegotiate handling needs a review as it does not work in 
all cases.

I hope my informations are of any help to fix this issue.

Ciao,
Mario

Re: [VFS] Softening the exceptions...

[Mario Ivankovits]

Hi!

Am 25.10.2010 um 21:13 schrieb James Carman ja...@carmanconsulting.com:

 On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
 ggreg...@seagullsoftware.com wrote:
 
 So for VFS, you would prefer that all error handling be done with unchecked 
 
 
 In a nutshell, yes.  So, it's a pretty easy change.  You'd just change
 the superclass of FileSystemException.

To bring in my two 2ct. I foo think that the FileSystemException could be a 
runtime exception. As long as it represents a non-recoverable exception. 
Something which might throw things like a filenotfoundexception should be 
checked, still.

What I would like to say is, simply changing the exception inheritance is not 
sufficient and for no ones help. We need to work out a concept which method 
throws which checked or unchecked exception.

As we had Hibernate in the thread, I think Hibernate has gone too far in this 
question and you have to be very familiar with the API to know which exception 
to catch when. This does not help if you are going to translate a technical 
exception to something meaningful for the user.

The problem with VFS is that it throws mostly just a FSE without any chance to 
get the real cause in you program - you have to parse the message - which is 
bad.

Ciao,
Mario 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

AW: [jira] Created: (EXTCDI-57) revisit Conversation#end

[Mario Ivankovits]

+1 for #1

 

Yes, is is obvious that close() closes immediately.

 

Ciao,

Mario

 

Von: Gerhard [mailto:gerhard.petra...@gmail.com] 
Gesendet: Samstag, 18. September 2010 17:52
An: MyFaces Development
Betreff: Re: [jira] Created: (EXTCDI-57) revisit Conversation#end

 

+1 for #1

 

regards,

gerhard

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



 

2010/9/18 Gerhard Petracek (JIRA) dev@myfaces.apache.org

revisit Conversation#end


Key: EXTCDI-57
URL: https://issues.apache.org/jira/browse/EXTCDI-57
Project: MyFaces CODI
 Issue Type: Task
 Components: JEE-JSF12-Module, JEE-JSF20-Module
   Reporter: Gerhard Petracek


we should think about the naming of this important api, because std. cdi
conversations offer the same method.

codi conversations are very similar to orchestra conversations.

in orchestra #end means that the conversation gets terminated immediately.
currently we have the same with codi conversations.

if we would like to add an additional api which terminates the conversation
after the rendering process (= behavior of std. cdi conversations), we would
have to introduce a name which might confuse users.

we have the following options:

#1:
renaming #end to #close - it's more clear to users that it works
differently (compared to std. cdi conversations).
so we still have #end if we add an additional api for terminating the
conversation at the end of the request.
if we won't introduce the additional api, we still have a method which
indicates that the termination process works differently compared to std.
cdi conversations.
the only disadvantage is that it isn't intuitive for users who used
orchestra.

#2:
keeping the current api (#end) for terminating the conversation immediately.
so we will need a name for an api which ends the conversation after the
rendering process.
(we could use #close. but then we have #end which works differently
(compared to std. cdi conversations) and #close also doesn't really express
the difference (and other names might sound strange). so we might end up
with confused users.)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

 



smime.p7s
Description: S/MIME cryptographic signature

Re: Exclusive broker access

[Mario Ivankovits (Apache)]

We are sorry we have to inform you that this functionality is not yet 
implemented, but is planned for the Q1 release in 2019.


;-)) sorry, couldn't resist ... I guess, you wouldn't want your mail sent to 
commons-dev, no?


Ciao,
Mario

-Ursprüngliche Nachricht-
Von: Emmanuel Bourg [mailto:ebo...@apache.org] 
Gesendet: Freitag, 09. Juli 2010 10:44
An: Commons Developers List
Betreff: Exclusive broker access

Hi,

Is there a way to enforce a per account exclusive access to the broker? 
For example if a user has an opened connection to the broker, when he 
opens another connection the first one is automatically closed.

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Long transactions

[Mario Ivankovits]

Hi!

I know, I might sound like a broken record already ...

But also consider using a JPA-like persistence provider like Ebean [1].
If you are going to deatach your objects, you can avoid the persistence
context at all.

Ebean just maintains a persistence context per transaction. So, if you are
having processes which reads the same row from the database multiple times
you'll get the same instance from the cache, but reads outside of a
transaction result in immediately detached object.
For sure, without the persistence context you have to call
ebean.save(instance) on your entities instead of relying on a
session.commit(), but this is a very low price to pay compared to all the
hassle you have with a long running persistence context.

Lazy loading is still possible with Ebean anyway! And not only this, it also
learns (if configured) from your application which relations you use and
which properties and next time will autotune the select to just fetch those
properties and relation.
No need to define a 1:n relation eager or lazy, it just learns that
(optional for sure!).

I can say, I am quite happy with this library!
I even replaced Hibernate by it. Probably you have to put some effort into
the transition, but for me it made things alot easier again.


Ciao,
Mario

[1] www.avaje.org

-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de] 
Gesendet: Freitag, 02. Juli 2010 10:12
An: MyFaces Discussion
Betreff: Re: Long transactions

 Mike you left out the obvious one, simply use a conversation 
framework.

Definitely true, but not always applicable. I would e.g. not recommend using
long running transactions for public pages. This will increase the session
footprint big times and you'll get more easily vulnerable for DOS attacks
this way.

Otoh, for intranet apps or pages with a limited reach, frameworks like
Orchestra will really make your life way easier.

FYI: we are currently working on getting Orchestra style conversations
ported over to our MyFaces Extensions for CDI (EXTCDI / CODI).

LieGrue,
strub




- Original Message 
 From: Werner Punz werner.p...@gmail.com
 To: users@myfaces.apache.org
 Sent: Fri, July 2, 2010 9:39:05 AM
 Subject: Re: Long transactions
 
 Mike you left out the obvious one, simply use a conversation framework.
The 
 problem is not transactions but it is that the entity manger is 
dropped 
 along the way hence silently detaching all objects and running 
you into 
 detached error hell. (You still can either setup your jpa 
provider so that 
 lazy loading can happen outside of transaction barriers 
or prefetch 
 everything via fetch join)

I personally found as soon as you go to a 
 conversation framework things 
become way easier (although not entirely 
 easy)

Also what was the problem with holder objects. I personally am 
 thinking 
of moving that way especially since JPA allows to map it 
 transparently 
via queries like following select new FakeHolder(
 target=_blank href=http://entity.id;entity.id, entity) 
from 
 EntityClass entity).

The downside is that you need more logic for pushing 
 the data back into 
the entity objects before writing. But the fake holder 
 pattern is 
exactly what iBatis enforces (although it has the write back 
 logic 
pushed into the configuration) and it works out well in a web centric 
 
szenario.


WErner


Am 01.07.10 23:54, schrieb Mike 
 Kienenberger:
 I am, sort of.

 You really can't leave the 
 transaction open beyond the request
 response as it may never 
 complete.

 Some of the ways you can deal with it 
 are:

 1) work with fake holder entities that get changed back 
 into real
 entities at the final commit.   Very ugly -- tried this 
 one at first,
 but I don't use it anymore.

 2) Work with 
 detached objects.  Reattach them back right before the
 final 
 commit.   This is what I currently do.I basically invented 
 a
 Unit-Of-Work framework that runs over the top of JPA.The 
 unit of
 work has a separate persistence manager that loads an object, 
 then
 immediately detaches it.   Our framework requires each object 
 to call
 save() to commit changes.   When in the UoW, all save does 
 is add the
 object to a change-tracker (inserts, deletes, updates).  
   Then when
 the UoW is committed, the objects are persisted or 
 merged, then
 committed all in one method call.

 But in 
 all honesty, this approach also has caused us a lot of hassles.
  
   We are most likely going to dump JPA and replace it with Apache
 
 Cayenne, which uses a real unit of work concept.

 Another option 
 for you might be to use an implementation-specific unit
 of work provided 
 by your JPA implementation.   However, I don't know
 if you might 
 have other issues.   I used Cayenne before I used JPA,
 and I know 
 Cayenne does exactly what I need.

 A third option you could 
 consider if you want to risk leaving the
 transaction 
 open.

 a) Catch the window onunload event, and mixed with ajax, 
 send an ajax
 request 

Re: Long transactions

[Mario Ivankovits]

And, btw, Orchestra is still useful then, but there is no need to attach it
to the PersistenceContext then.
It just acts as a simple conversation scope provider without any magic
associated with the database layer. = easier spring configuration too.

Ciao,
Mario


-Ursprüngliche Nachricht-
Von: Mario Ivankovits [mailto:ma...@ops.co.at] 
Gesendet: Freitag, 02. Juli 2010 10:27
An: 'MyFaces Discussion'
Betreff: Re: Long transactions

Hi!

I know, I might sound like a broken record already ...

But also consider using a JPA-like persistence provider like Ebean [1].
If you are going to deatach your objects, you can avoid the persistence
context at all.

Ebean just maintains a persistence context per transaction. So, if you are
having processes which reads the same row from the database multiple times
you'll get the same instance from the cache, but reads outside of a
transaction result in immediately detached object.
For sure, without the persistence context you have to call
ebean.save(instance) on your entities instead of relying on a
session.commit(), but this is a very low price to pay compared to all the
hassle you have with a long running persistence context.

Lazy loading is still possible with Ebean anyway! And not only this, it also
learns (if configured) from your application which relations you use and
which properties and next time will autotune the select to just fetch those
properties and relation.
No need to define a 1:n relation eager or lazy, it just learns that
(optional for sure!).

I can say, I am quite happy with this library!
I even replaced Hibernate by it. Probably you have to put some effort into
the transition, but for me it made things alot easier again.


Ciao,
Mario

[1] www.avaje.org

-Ursprüngliche Nachricht-
Von: Mark Struberg [mailto:strub...@yahoo.de] 
Gesendet: Freitag, 02. Juli 2010 10:12
An: MyFaces Discussion
Betreff: Re: Long transactions

 Mike you left out the obvious one, simply use a conversation 
framework.

Definitely true, but not always applicable. I would e.g. not recommend using
long running transactions for public pages. This will increase the session
footprint big times and you'll get more easily vulnerable for DOS attacks
this way.

Otoh, for intranet apps or pages with a limited reach, frameworks like
Orchestra will really make your life way easier.

FYI: we are currently working on getting Orchestra style conversations
ported over to our MyFaces Extensions for CDI (EXTCDI / CODI).

LieGrue,
strub




- Original Message 
 From: Werner Punz werner.p...@gmail.com
 To: users@myfaces.apache.org
 Sent: Fri, July 2, 2010 9:39:05 AM
 Subject: Re: Long transactions
 
 Mike you left out the obvious one, simply use a conversation framework.
The 
 problem is not transactions but it is that the entity manger is 
dropped 
 along the way hence silently detaching all objects and running 
you into 
 detached error hell. (You still can either setup your jpa 
provider so that 
 lazy loading can happen outside of transaction barriers 
or prefetch 
 everything via fetch join)

I personally found as soon as you go to a 
 conversation framework things 
become way easier (although not entirely 
 easy)

Also what was the problem with holder objects. I personally am 
 thinking 
of moving that way especially since JPA allows to map it 
 transparently 
via queries like following select new FakeHolder(
 target=_blank href=http://entity.id;entity.id, entity) 
from 
 EntityClass entity).

The downside is that you need more logic for pushing 
 the data back into 
the entity objects before writing. But the fake holder 
 pattern is 
exactly what iBatis enforces (although it has the write back 
 logic 
pushed into the configuration) and it works out well in a web centric 
 
szenario.


WErner


Am 01.07.10 23:54, schrieb Mike 
 Kienenberger:
 I am, sort of.

 You really can't leave the 
 transaction open beyond the request
 response as it may never 
 complete.

 Some of the ways you can deal with it 
 are:

 1) work with fake holder entities that get changed back 
 into real
 entities at the final commit.   Very ugly -- tried this 
 one at first,
 but I don't use it anymore.

 2) Work with 
 detached objects.  Reattach them back right before the
 final 
 commit.   This is what I currently do.I basically invented 
 a
 Unit-Of-Work framework that runs over the top of JPA.The 
 unit of
 work has a separate persistence manager that loads an object, 
 then
 immediately detaches it.   Our framework requires each object 
 to call
 save() to commit changes.   When in the UoW, all save does 
 is add the
 object to a change-tracker (inserts, deletes, updates).  
   Then when
 the UoW is committed, the objects are persisted or 
 merged, then
 committed all in one method call.

 But in 
 all honesty, this approach also has caused us a lot of hassles.
  
   We are most likely going to dump JPA and replace it with Apache
 
 Cayenne, which uses a real unit of work concept

Re: Problems with orchestra and JSF 2

[Mario Ivankovits]

Heya!

Please check the url parameter conversationContext has been added to each
and every url.

If it is missing, a new context will be created each request and then a new
bean will be created too.

Now you sure would like to know why it is missing ... if it is missing.

Hmmm ... do you use portlets or such?


Ciao,
Mario

PS: Sorry for top-posting, Mail-Client oddities ... :)

-Ursprüngliche Nachricht-
Von: Bruno Aranda [mailto:brunoara...@gmail.com] 
Gesendet: Donnerstag, 01. Juli 2010 14:42
An: MyFaces Discussion
Betreff: Re: Problems with orchestra and JSF 2

What I can see as well after putting a method with the @PostConstruct
annotation, is that this method is called every request, as if the
conversation didn't exist before, which is not true.

I am outputting the orchestra logs in the console, and I can see:

2010-07-01 14:05:32,729 [qtp33228489-20] DEBUG (DebugPhaseListener,40) -
Before phase: RESTORE_VIEW(1)
2010-07-01 14:05:32,823 [qtp33228489-20] DEBUG (Conversation,108) - start
conversation:general

NEW INSTANCE PUBCONTROLLER HASH: 9f720d

 POST CONS PUB === 9f720d

NEW INSTANCE PUBCONTROLLER HASH: 147f75
NEW INSTANCE PUBCONTROLLER HASH: 1bbefe8

2010-07-01 14:05:32,844 [qtp33228489-20] DEBUG (Conversation,176) - put bean
to conversation:org.springframework.beans.factory.support.Dispo
sablebeanadap...@25394361
(bean=org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchest
rascop...@17167e6
)
2010-07-01 14:05:32,846 [qtp33228489-20] DEBUG (Conversation,176) - put bean
to conversation:org.apache.myfaces.orchestra.conversation.sprin
g.PersistenceContextConversationInterceptor.PERSISTENCE_CONTEXT(bean=org.apa
che.myfaces.orchestra.conversation.spring.PersistenceContextClos
e...@81f22c)
2010-07-01 14:05:32,847 [qtp33228489-20] DEBUG (Conversation,176) - put bean
to conversation:publicationController(bean=uk.ac.ebi.intact.edi
tor.controller.curate.publication.publicationcontrol...@9f720d)
2010-07-01 14:05:32,853 [qtp33228489-20] DEBUG (DebugPhaseListener,35) -
After phase: RESTORE_VIEW(1)
...

The bean is called publicationController, which should be maintained in a
conversation called general. And I see this every request. This is the
bean class annotations:

@Controller
@Scope( conversation.access )
@ConversationName( general )
public class PublicationController extends AnnotatedObjectController {
...}

I fail to see why the bean is not re-used as the conversation is not ended.

And then, if I let the conversation expire, I see the message as many times
as instances have been created (three requests in my case to the same
page...).

2010-07-01 14:39:28,563 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
2010-07-01 14:39:28,565 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
2010-07-01 14:39:28,566 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general

So I am not sure what is happening here :(

Bruno

On 1 July 2010 13:27, Bruno Aranda brunoara...@gmail.com wrote:

 I see, yes, that could explain it as Spring is creating proxies all over
 the place to make some of the annotations work. However I am not doing
 anything in the constructors, but for instance, if I set a property on a
 backing bean (conversation.access scope), when I click on a button that
 value seems to have been lost, as if I was accessing another object...
 probably something to do with proxies as well and orchestra?

 Thanks!

 Bruno


 On 1 July 2010 13:22, Mark Struberg strub...@yahoo.de wrote:

 Hi Bruno!

  First, could someone explain me why the
  beans constructor
 is called multiple times?

 What you see might  be an effect of proxies.
 Usually if a subclassing proxy gets initialised, the constructor of the
 proxied class gets called.
 This is the reason why it's not suggested to use constructors for
 initialisations at all but instead use
 @PostConstruct (resp @PreDestroy instead of finalize)

 LieGrue,
 strub


 - Original Message 
  From: brunoaranda brunoara...@gmail.com
  To: MyFaces Discussion users@myfaces.apache.org
  Sent: Thu, July 1, 2010 12:55:30 PM
  Subject: Problems with orchestra and JSF 2
 
  Hi,

 I am having some troubles with orchestra maintaining some beans
  in
 conversation access scope. First, could someone explain me why the
  beans
 constructor is called multiple times? In my app I have multiple beans
  with
 the same conversation name and when I access one of the other beans from
  my
 bean, it seems as it is picking a new instance. The same scenario works
  fine
 using session beans, but of course then I lose all the nice
  transaction
 management from Orchestra. Anyone with an idea where I can I
  look? How is
 people dealing with JPA and transactions scoping multiple
  requests in JSF 2?

 I am having another issue as well. Even if I have one
  bean, the data seems
 not to be in the model when I click on a button that
  invokes a 

AW: potential problem: FtpFileObject caches children when not attached

[Mario Ivankovits]

Hi!

 

Hmmm … I tried to reproduce it like this:

 

   FileObject fos =
VFS.getManager().resolveFile(ftp://XYZ.com/public/ test with space, fops);

   fos.getType();

   fos.getChildren();

 

   fos.refresh();

   fos.getType();

   fos.getChildren();

 

After the refresh() I just get one ftp list … can you please outline with
code how to reproduce the problem.

Thanks!

 

Ciao,

Mario

 

 

Von: Kirill Safonov [mailto:kirill.safo...@gmail.com] 
Gesendet: Mittwoch, 12. Mai 2010 17:07
An: 'Commons Users List'
Cc: Mario Ivankovits
Betreff: potential problem: FtpFileObject caches children when not attached

 

Hello,

 

While digging a bit into FTP performance, I’ve noticed the following:

 

When FtpFileObject.refresh() is called, FtpFileObject.children field is
reset to null in FtpFileObject.doDetach(), and AbstractFileObject.attached
flag is set to false (this is OK)

But, if then FtpFileObject.getChildFile() is called (this may happen when
getType() is invoked for one of the child files – see below), current
implementation will ignore ‘attached’ state and silently fill children cache
by calling doGetChildren().

 

The result is that FtpFileObject remains in inconsistent state: it is not
attached with AbstractFileObject.type field = null, child names cache
(AbstractFileObject.children)  = null, but has children cache bulit.

 

I’m not currently sure which consequences it may cause.

 

What I’ve found up to date is that when I load list of children I see that
two FTP LIST commands are issued: 

-  first one is to list the children themselves

-  then parent file is refreshed since CacheStrategy is ON_RESOLVE
(this is actually another issue I’d like to discuss, since it gives a
performance drop clearing the children cache right after is was build)

-  and then another LIST call that comes from child.getType(). If
there was no inconsistency I described above, this LIST would have been
called for each of the children.

 

Hope all this makes sense,

 Regards,

 Kirill



smime.p7s
Description: S/MIME cryptographic signature

RE: Need to switch to subclassing?

[Mario Ivankovits]

Hi!

I'd definitely would go the subclassing route.

The problem you describe here is one of my biggest concerns of how Spring's AOP 
works.
This is just not real AOP - it is dynamic proxy creation - not more, not less.

An average developer will never be able to figure out what is going wrong here.

I had this problem once too, the solution I used then was not to use (the 
implicit) this., but to 
use a reference to the service object (the proxy instance).
In your case this would mean you need to get access to the proxy and then call
thisProxy.importLegacyEmployees.
That way the call goes through the AOP layer ... but ... I'd consider it as 
nasty workaround.

Ciao,
Mario

-Original Message-
From: Mark Struberg [mailto:strub...@yahoo.de] 
Sent: Tuesday, May 11, 2010 7:30 AM
To: dev@openwebbeans.apache.org
Subject: Need to switch to subclassing?

Hi!

There is a subtle difference between implementing interceptors via proxy or via 
subclasses.

I have the following service which imports data from a legacy system into my 
db. Since commits are very performance intense, they should get imported in 
packages of 100. So I'll get 100 'Employees' from my legacy system and then 
call a @Transactional method to store them in my own database.

public void ImportService() {
  public void importEmployee() {
ListLegacyEmployee les;
while ((les = getNext100EmployeesFromLegacy()) != nul) {
  importLegacyEmployees(le);
}
  }

  @Transactional
  protected importLegacyEmployees(ListLegacyEmployee les) {
for (LegacyEmployee le: les) {
  employeeService.store(le);
}
  }
}

This would actually _not_ when using proxies for the interceptor handling, 
because calling a method on an own class doesn't invoke the proxyhandler.

So is this expected to work?

Sure, I could easily move the importLegacyEmployees() to an own service, but 
that would infringe classic OOP heavily imo.

Gurkan, what does the spec say here, I did find nothing. The old spec 
explicitly mentioned that we need to use subclassing, but I cannot find this 
anymore.

LieGrue,
strub

[jira] Created: (VFS-307) VFS issues a lot of FTP commands when listing a directory

[Mario Ivankovits (JIRA)]

VFS issues a lot of FTP commands when listing a directory
-

 Key: VFS-307
 URL: https://issues.apache.org/jira/browse/VFS-307
 Project: Commons VFS
  Issue Type: Improvement
Reporter: Mario Ivankovits


Hello Mario,
 
We at JetBrains are implementing support for (S)FTP sync in our IDEs using 
Commons VFS. When looking at the performance, we noticed that FTP provider is 
somewhat not perfect: see my discussion with Ralph. 
 
So the question is: why FtpClientWrapper changes the current directory to issue 
'LIST' command and restoring it back afterwards instead of issuing single 'LIST 
relpath'? 
 
Subversion says it was you who introduced this behavior far back in 2008. Hope 
you remember those times and reason why you did this.
 
Thanks a lot in advance,
 
Kirill Safonov
JetBrains, Inc
http://www.jetbrains.com
Develop with pleasure!
 


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (VFS-307) VFS issues a lot of FTP commands when listing a directory

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863727#action_12863727
 ] 

Mario Ivankovits commented on VFS-307:
--

The change happened when implementing the umbrella issue [1] more concret it 
was the issue [2] for which we did this.

Hmmm ... 

So, I see three ways to move on:
1) leave as is, which surely is a performance penalty and not good for any DIE
2) change to try first LIST path and fallback to the current way if directory 
is not found
3) change to LIST path and try to escape the path in a way which makes it 
work with spaces in it

I'll try to see if I can make 3 work and go up the list then  :-)


 VFS issues a lot of FTP commands when listing a directory
 -

 Key: VFS-307
 URL: https://issues.apache.org/jira/browse/VFS-307
 Project: Commons VFS
  Issue Type: Improvement
Reporter: Mario Ivankovits

 Hello Mario,
  
 We at JetBrains are implementing support for (S)FTP sync in our IDEs using 
 Commons VFS. When looking at the performance, we noticed that FTP provider is 
 somewhat not perfect: see my discussion with Ralph. 
  
 So the question is: why FtpClientWrapper changes the current directory to 
 issue 'LIST' command and restoring it back afterwards instead of issuing 
 single 'LIST relpath'? 
  
 Subversion says it was you who introduced this behavior far back in 2008. 
 Hope you remember those times and reason why you did this.
  
 Thanks a lot in advance,
  
 Kirill Safonov
 JetBrains, Inc
 http://www.jetbrains.com
 Develop with pleasure!
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (VFS-307) VFS issues a lot of FTP commands when listing a directory

[Mario Ivankovits (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VFS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Ivankovits resolved VFS-307.
--

Fix Version/s: Nightly Builds
   Resolution: Fixed

Please give it a try

 VFS issues a lot of FTP commands when listing a directory
 -

 Key: VFS-307
 URL: https://issues.apache.org/jira/browse/VFS-307
 Project: Commons VFS
  Issue Type: Improvement
Reporter: Mario Ivankovits
 Fix For: Nightly Builds


 Hello Mario,
  
 We at JetBrains are implementing support for (S)FTP sync in our IDEs using 
 Commons VFS. When looking at the performance, we noticed that FTP provider is 
 somewhat not perfect: see my discussion with Ralph. 
  
 So the question is: why FtpClientWrapper changes the current directory to 
 issue 'LIST' command and restoring it back afterwards instead of issuing 
 single 'LIST relpath'? 
  
 Subversion says it was you who introduced this behavior far back in 2008. 
 Hope you remember those times and reason why you did this.
  
 Thanks a lot in advance,
  
 Kirill Safonov
 JetBrains, Inc
 http://www.jetbrains.com
 Develop with pleasure!
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (VFS-307) VFS issues a lot of FTP commands when listing a directory

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863765#action_12863765
 ] 

Mario Ivankovits commented on VFS-307:
--

It seems there is no FTP spec which allows to escape/quote a path so that it 
works on each and every ftp server.

So I landed at solution 2 similar to what the patch in VFS-123 proposed. It 
seems to work with my ftp server.

 VFS issues a lot of FTP commands when listing a directory
 -

 Key: VFS-307
 URL: https://issues.apache.org/jira/browse/VFS-307
 Project: Commons VFS
  Issue Type: Improvement
Reporter: Mario Ivankovits
 Fix For: Nightly Builds


 Hello Mario,
  
 We at JetBrains are implementing support for (S)FTP sync in our IDEs using 
 Commons VFS. When looking at the performance, we noticed that FTP provider is 
 somewhat not perfect: see my discussion with Ralph. 
  
 So the question is: why FtpClientWrapper changes the current directory to 
 issue 'LIST' command and restoring it back afterwards instead of issuing 
 single 'LIST relpath'? 
  
 Subversion says it was you who introduced this behavior far back in 2008. 
 Hope you remember those times and reason why you did this.
  
 Thanks a lot in advance,
  
 Kirill Safonov
 JetBrains, Inc
 http://www.jetbrains.com
 Develop with pleasure!
  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

ContextsService for standalone applications

[Mario Ivankovits]

Hi!



I am developing a standalone Swing Application and trying to make use of CDI 
(using openwebbeans). Also for being more fit when discussing Orchestra 
related things :-)





Naturally a Swing Application consists of multiple threads. At least the main 
thread and the so called Event Dispatcher Thread (EDT) for UI handling.

Beside this you will find a lot of other short-time threads handling actions 
triggered by the user through the UI.



The problem I have is the org.apache.webbeans.spi.se.DefaultContextsService 
class which uses ThreadLocals to store all the contexts.



I think this is not right, at least not for all the contexts provided.

For example the ApplicationContext, SessionContext, SingletonContext and 
DependentContext should be a simple member of the class. Not sure about (CDI 
like) ConversationContext.

The RequestContext might be arguable to life with the Thread - however, the 
developer need to take care to destroy the RequestContext manually somehow - 
or something we can implment into the Swing Application Framework.



For now I solved that by providing my own ContextsService impl through 
openwebbeans.properties.





Also, like in Weld, I'd love to see some utility class to startup CDI in an 
standalone app. Once you figured out it is easy already, but it can be even 
more easy, and we can provide some predefined events like ContainerInitialized 
[1].





Said that (and given my observations are correct), what do you think about 
starting up a webbeans-se module where we put these things together?

It won't grow to a huge project, though.



Ciao,

Mario



[1] 
http://www.jarvana.com/jarvana/view/org/jboss/weld/weld-se/1.0.0-CR2/weld-se-1.0.0-CR2-javadoc.jar!/org/jboss/weld/environment/se/events/ContainerInitialized.html



smime.p7s
Description: S/MIME cryptographic signature

[jira] Created: (OWB-349) ignore exception during type hierarchy scan

[Mario Ivankovits (JIRA)]

ignore exception during type hierarchy scan
---

 Key: OWB-349
 URL: https://issues.apache.org/jira/browse/OWB-349
 Project: OpenWebBeans
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.0
 Environment: JDK 1.6.0_17
Reporter: Mario Ivankovits
Assignee: Gurkan Erdogdu
 Attachments: invalid_superclass_type.patch

During classpath scan OWB crashes with an MalformedParameterizedTypeException 
exception.

This exception happens in ClassUtils.setTypeHierarchy when trying to get the 
GenericSuperclass.

It seems I can not fix this exception on my side as the code compiles and works 
fine and the class I inherit from is a class of a used library.

I think the system should not fail anyway. A warning that a type needs to be 
ignored should be enough ...


Attached is a patch which makes OWB correctly startup here by doing so.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (ORCHESTRA-42) Unresolved dependency of org.apache.commons.el.Logger

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/ORCHESTRA-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845215#action_12845215
 ] 

Mario Ivankovits commented on ORCHESTRA-42:
---

Hmmm ... The shared_* packages are generated out of the common myfaces shared 
stuff.

So, this needs to be fixed in myfaces - if this can be fixed at all.

I'll move this issue.

 Unresolved dependency of org.apache.commons.el.Logger
 -

 Key: ORCHESTRA-42
 URL: https://issues.apache.org/jira/browse/ORCHESTRA-42
 Project: MyFaces Orchestra
  Issue Type: Bug
Affects Versions: 1.3.1
 Environment: Deploying to Glassfish v2
Reporter: Bart Kummel
Priority: Minor

 When deploying an application that uses Orchestra Core 1.3.1, I get a 
 ClassNotFoundException on org.apache.commons.el.Logger. The work around is of 
 course to manually download Apache Commons EL and add is as a dependency. The 
 solution to this bug can be:
 - removing the dependency
 - mentioning the dependency in the docs.
 Stack trace:
 java.lang.NoClassDefFoundError: org/apache/commons/el/Logger
   at 
 org.apache.myfaces.shared_orchestra.util.ClassUtils.clinit(ClassUtils.java:44)
   at 
 org.apache.myfaces.orchestra.annotation.spring.AnnotationsInfoInitializer.postProcessBeanFactory(AnnotationsInfoInitializer.java:93)
   at 
 org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:553)
   at 
 org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:536)
   at 
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:362)
   at 
 org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
   at 
 org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
   at 
 org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
   at 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4523)
   at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:5184)
   at com.sun.enterprise.web.WebModule.start(WebModule.java:326)
   at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973)
   at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688)
   at 
 com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584)
   at 
 com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222)
   at 
 com.sun.enterprise.web.WebContainer.loadJ2EEApplicationWebModules(WebContainer.java:1147)
   at 
 com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:141)
   at 
 com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244)
   at 
 com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336)
   at 
 com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210)
   at 
 com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645)
   at 
 com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:928)
   at 
 com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:912)
   at 
 com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:461)
   at 
 com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176)
   at 
 com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
   at 
 com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226)
   at 
 com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
   at 
 com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132)
   at 
 com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
   at 
 com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919)
   at 
 com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:276)
   at 
 com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:294

[jira] Commented: (MYFACES-2604) Unresolved dependency of org.apache.commons.el.Logger

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845216#action_12845216
 ] 

Mario Ivankovits commented on MYFACES-2604:
---

Could someone of the MyFaces masters please have a look at it.

Thanks! :-)

 Unresolved dependency of org.apache.commons.el.Logger
 -

 Key: MYFACES-2604
 URL: https://issues.apache.org/jira/browse/MYFACES-2604
 Project: MyFaces Core
  Issue Type: Bug
 Environment: Deploying to Glassfish v2
Reporter: Bart Kummel
Priority: Minor

 When deploying an application that uses Orchestra Core 1.3.1, I get a 
 ClassNotFoundException on org.apache.commons.el.Logger. The work around is of 
 course to manually download Apache Commons EL and add is as a dependency. The 
 solution to this bug can be:
 - removing the dependency
 - mentioning the dependency in the docs.
 Stack trace:
 java.lang.NoClassDefFoundError: org/apache/commons/el/Logger
   at 
 org.apache.myfaces.shared_orchestra.util.ClassUtils.clinit(ClassUtils.java:44)
   at 
 org.apache.myfaces.orchestra.annotation.spring.AnnotationsInfoInitializer.postProcessBeanFactory(AnnotationsInfoInitializer.java:93)
   at 
 org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:553)
   at 
 org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:536)
   at 
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:362)
   at 
 org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
   at 
 org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
   at 
 org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
   at 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4523)
   at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:5184)
   at com.sun.enterprise.web.WebModule.start(WebModule.java:326)
   at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973)
   at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688)
   at 
 com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584)
   at 
 com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222)
   at 
 com.sun.enterprise.web.WebContainer.loadJ2EEApplicationWebModules(WebContainer.java:1147)
   at 
 com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:141)
   at 
 com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244)
   at 
 com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336)
   at 
 com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210)
   at 
 com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645)
   at 
 com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:928)
   at 
 com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:912)
   at 
 com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:461)
   at 
 com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176)
   at 
 com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
   at 
 com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226)
   at 
 com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
   at 
 com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132)
   at 
 com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
   at 
 com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919)
   at 
 com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:276)
   at 
 com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:294)
   at 
 com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.deploy(ApplicationsConfigMBean.java:555)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method

Re: [TRINIDAD] German umlauts get ignored when entered in inputText

[Mario Ivankovits]

Hi!


Probably have a look at this: 
http://www.jroller.com/mert/entry/utf_8_encoding_with_jsf

Also, given you use Tomact, the connector's encoding configurations might be 
interesting for you: http://tomcat.apache.org/tomcat-5.5-doc/config/http.html


Not sure if Trinidad has something special here, though.

Ciao,
Mario


-Ursprüngliche Nachricht-
Von: schneidc [mailto:simon.w...@gmx.de] 
Gesendet: Montag, 15. März 2010 09:20
An: users@myfaces.apache.org
Betreff: [TRINIDAD] German umlauts get ignored when entered in inputText


Hi,

on my pages (encoded in utf-8) I have no problem displaying german umlauts
like ä ö ü, but when entered in a tr:inputText... the actual string is
missing the umlauts. E.g. if I enter Böhm the string in the managed bean
equals Bhm.

How's that and what can I do about it?

Thanks
Simon
-- 
View this message in context: 
http://old.nabble.com/-TRINIDAD--German-umlauts-get-ignored-when-entered-in-%3CinputText%3E-tp27901371p27901371.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.



smime.p7s
Description: S/MIME cryptographic signature

Re: [TRINIDAD] German umlauts get ignored when entered in inputText

[Mario Ivankovits]

Did you try the connector stuff either?

If you have configured e.g. an access-valve this might force the container
to choose a charset either, and it might choose the wrong one.

Ciao,
Mario

-Ursprüngliche Nachricht-
Von: schneidc [mailto:simon.w...@gmx.de] 
Gesendet: Montag, 15. März 2010 10:32
An: users@myfaces.apache.org
Betreff: Re: [TRINIDAD] German umlauts get ignored when entered in
inputText


Hi Mario,

thanks for the tip, but unfortunately adding the filter didn't help. The
umlauts are still missing in the strings.
-- 
View this message in context:
http://old.nabble.com/-TRINIDAD--German-umlauts-get-ignored-when-entered-in-
%3CinputText%3E-tp27901371p27901990.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.



smime.p7s
Description: S/MIME cryptographic signature

Re: [TRINIDAD] German umlauts get ignored when entered in inputText

[Mario Ivankovits]

Sorry, I have absolutely no clue with Webspehere, but a search in google
with websphere utf-8 brings up the following:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzatz
/51/admin/help/trun_svr_utf.html

Ciao,
Mario

-Ursprüngliche Nachricht-
Von: schneidc [mailto:simon.w...@gmx.de] 
Gesendet: Montag, 15. März 2010 11:45
An: users@myfaces.apache.org
Betreff: Re: [TRINIDAD] German umlauts get ignored when entered in
inputText


Hi,

I'm using Websphere App Server and didn't find anything similar to the
Tomcat connectors, yet.
-- 
View this message in context:
http://old.nabble.com/-TRINIDAD--German-umlauts-get-ignored-when-entered-in-
%3CinputText%3E-tp27901371p27902599.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.



smime.p7s
Description: S/MIME cryptographic signature

RE: Google SoC

[Mario Ivankovits]

Hi!

 - Extend Orchestra use Conversations based on the JSF 2.0 custom scope
 API, Extend Orchestra to work with Spring Conversations, to do
 File-New Window Handling

Any idea how this should work?
What magic is Spring Conversations using here?

Ciao,
Mario

RE: Google SoC

[Mario Ivankovits]

Hi!



From: Leonardo Uribe [mailto:lu4...@gmail.com]
Sent: Tuesday, March 09, 2010 7:54 PM
To: MyFaces Development
Subject: Re: Google SoC







- Extend Orchestra use Conversations based on the JSF 2.0 custom scope
API, Extend Orchestra to work with Spring Conversations, to do
File-New Window Handling


I was thinking based on a suggestion done on JSFDays to take advantage on 
trinidad pageFlowScope code (like we did with flash scope on myfaces 2.0), and 
refactor that code to allow orchestra conversation scope work without spring 
(using the new JSF 2.0 custom scope).



 [Mario Ivankovits] Orchestra without Spring, that surely would be great. One 
thing to keep in mind is that we need AOP or at least proxying to inject the 
current conversation into the bean. Not too complicated, though.

But what does this have to do with trinidad's pageFlowScope?

If we leave the EntityManager thing out of line, we just need a JSF 2.0 scope 
impl and the proxying/interception stuff which is handled by Spring currently.



Ciao,

Mario

AW: [VOTE] codi as a new myfaces extensions sub-project

[Mario Ivankovits]

+1

 

 

Von: gerhard.petra...@gmail.com [mailto:gerhard.petra...@gmail.com] Im
Auftrag von Gerhard Petracek
Gesendet: Dienstag, 16. Februar 2010 12:01
An: MyFaces Development
Betreff: [VOTE] codi as a new myfaces extensions sub-project

 

hi @ all,

 

we have collected a lot of possible features for ext-cdi/codi and we have
several people who are interested in working on it [1].

so we should vote about the new module officially.

 


---

[ ] +1 for: codi should become a myfaces extensions sub-project

[ ] +0

[ ] -1 for: codi shouldn't become a myfaces extensions sub-project


---

 

the module should be hosted at [2].

i think we have a clear winner for the name: MyFaces CODI

(svn and jira will use (ext-)cdi to be consistent with the other extension
modules.)

 

regards,

gerhard

 

[1] http://wiki.apache.org/myfaces/Extensions/CDI/DevDoc/Drafts

[2] http://svn.apache.org/repos/asf/myfaces/extensions/cdi/

 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



smime.p7s
Description: S/MIME cryptographic signature

AW: [ANNOUNCE] release of myfaces orchestra 1.4

[Mario Ivankovits]

Great to see a new release!!

 

:-)

 

Thanks Leonardo!

 

Von: Leonardo Uribe [mailto:lu4...@gmail.com] 
Gesendet: Samstag, 19. Dezember 2009 01:09
An: annou...@apache.org; annou...@myfaces.apache.org
Cc: MyFaces Development; MyFaces Discussion
Betreff: [ANNOUNCE] release of myfaces orchestra 1.4

 

The Apache MyFaces team is pleased to announce the release of
Apache MyFaces Orchestra Core 1.4

This release add support for portlets and new modules for compile orchestra
with jsf 1.2 and 2.0 implementations.

Also, orchestra core15 was merged in orchestra core module, because JDK 1.4
has reached its End of Life.

Get a full overview at Orchestra's homepage [1].

The release notes for 1.4 can be found here:
*
http://svn.apache.org/repos/asf/myfaces/orchestra/tags/core-1_4/RELEASE-NOTE
S.txt

The distribution is available at
 * http://myfaces.apache.org/orchestra/download.html

Apache MyFaces Orchestra is available in the central Maven repository
under Group ID org.apache.myfaces.orchestra.

Regards,
Leonardo Uribe

[1] http://myfaces.apache.org/orchestra



smime.p7s
Description: S/MIME cryptographic signature

RE: 100% CPU Usage and blocking concurrent Threads when using t:saveState

[Mario Ivankovits]

Ja, a ConcurrentMap might do the trick, but the thing is, this is out of our 
scope, isn't it?

These maps are create by the servlet container and thus are part of the servlet 
spec. And even then, they are created by tomcat.

I am afraid, there is nothing we can do.
As far as I remember, there was about a discussion about synchronizing against 
those map in the servelt container. But this has been abandoned for performance 
reasons.

Ciao,
Mario

 -Ursprüngliche Nachricht-
 Von: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] Im
 Auftrag von Jakob Korherr
 Gesendet: Donnerstag, 10. Dezember 2009 10:35
 An: MyFaces Discussion
 Betreff: Re: 100% CPU Usage and blocking concurrent Threads when using
 t:saveState
 
 I agree with Mario. It really seams llike the internal structure of the
 TreeMap is destroyed, thus ending in some infinite loop and causing
 100%
 CPU.
 
 Shouldn't we generally synchronize those Maps or use ConcurrentMaps?
 
 Regards,
 
 Jakob Korherr
 
 2009/12/10 Mario Ivankovits ma...@ops.co.at
 
For me, this clearly looks like concurrent usage of the request
 map.
 
  All the servlet scopes (session, request, …) are not thread safe and
 one
  has to assure that they are not accessed at the same time by multiple
  threads.
 
 
 
  This turns out to be hard as e.g. there is no standard how to
 synchronize
  against the session map. As a side note: I often wonder why this does
 not
  lead to much more problems in the wild …
 
 
 
  Anyway, in your case it seems the internal datastructure of the
 request map
  is damaged - which in fact is strange as I do not know when the
 request map
  will be accessed by multiple threads.
 
 
 
  Sorry that this is not a solution, but it should give you a clue
 where to
  look next …
 
 
 
  Ciao,
 
  Mario
 
 
 
  *Von:* Jan Baudisch [mailto:jan.baudi...@gmx.net]
  *Gesendet:* Donnerstag, 10. Dezember 2009 08:02
  *An:* MyFaces Discussion
  *Betreff:* 100% CPU Usage and blocking concurrent Threads when using
  t:saveState
 
 
 
  Hello MyFaces Community,
 
 
 
  we are using MyFaces 1.2.0 with Tomahawk Sandbox  1.1.5 and have the
  problem, that once in a while we get 100% CPU Usage and blocking
 concurrent
  threads because of using t:saveState
 
 
 
  A thread dump shows that the threads always stops at
 
 
 
  at java.util.TreeMap.put(TreeMap.java:545)
 
  at
 
 org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager.addSav
 eStateBean(RedirectTrackerManager.java:306)
 
  at
 
 org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolv
 er.resolveVariable(RedirectTrackerVariableResolver.java:50)
 
 
 
  (The complete thread dump is attached). The problem shows up on one
 system
  with heavy concurrent usage and JxBrowser as client.
 
 
 
  After we kill these threads using Lambda Probe, the CPU Usage
 normalizes.
 
 
 
  The problem occurs in that method:
 
 
 
  ...
 
  public void addSaveStateBean(String expressionString, Object
 value)
 
  {
 
  if(log.isDebugEnabled())
 
  log.debug(addSaveStateBean:  + expressionString + 
 value= +
  value);
 
  requestBeanMap.put(expressionString, value);
 
  }
 
  ...
 
  private final Map requestBeanMap = new TreeMap(); ...
 
 
 
  As the problem is really severe for us, any hints are highly
 appreciated.
 
 
 
  Many thanks in advance,
 
  -- Jan
 
 
 


smime.p7s
Description: S/MIME cryptographic signature

RE: 100% CPU Usage and blocking concurrent Threads when using t:saveState

[Mario Ivankovits]

Ah ... ok, sorry, didn't remember exactly. Ok, this changes things.

Yes, synchronizing in one way or the other might help here.

The ConcurrentSkipListMap is JDK 1.6 only, so might not make it as patch
into myfaces, but a simple synchronize() around each requestBeanMap access
might do the trick either. I do not suspect that you notice any performance
loss.

Please try and report back!

Ciao,
Mario


 -Ursprüngliche Nachricht-
 Von: Jan Baudisch [mailto:jan.baudi...@gmx.net]
 Gesendet: Donnerstag, 10. Dezember 2009 11:58
 An: MyFaces Discussion
 Betreff: Re: 100% CPU Usage and blocking concurrent Threads when using
 t:saveState
 
 Hello Mario and Jakob,
 
 thank you very much for your ideas on this problem.
 
 As far as I understood, the map that is causing the trouble is
 initialized inside class RedirectTrackerManager, and not by the
 application container:
 
 protected Map getRequestBeanMap()
 {
 if (requestBeanMap == null)
 {
 requestBeanMap = new TreeMap();
 }
 
 return requestBeanMap;
 }
 
 so what do you think of using a concurrent counterpart of TreeMap
 instead, e.g. java.util.concurrent.ConcurrentSkipListMap?
 
 Best regards,
 -- Jan
 
 Am 10.12.2009 um 11:08 schrieb Mario Ivankovits:
 
  Ja, a ConcurrentMap might do the trick, but the thing is, this is out
 of our scope, isn't it?
 
  These maps are create by the servlet container and thus are part of
 the servlet spec. And even then, they are created by tomcat.
 
  I am afraid, there is nothing we can do.
  As far as I remember, there was about a discussion about
 synchronizing against those map in the servelt container. But this has
 been abandoned for performance reasons.
 
  Ciao,
  Mario
 
  -Ursprüngliche Nachricht-
  Von: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] Im
  Auftrag von Jakob Korherr
  Gesendet: Donnerstag, 10. Dezember 2009 10:35
  An: MyFaces Discussion
  Betreff: Re: 100% CPU Usage and blocking concurrent Threads when
 using
  t:saveState
 
  I agree with Mario. It really seams llike the internal structure of
 the
  TreeMap is destroyed, thus ending in some infinite loop and causing
  100%
  CPU.
 
  Shouldn't we generally synchronize those Maps or use ConcurrentMaps?
 
  Regards,
 
  Jakob Korherr
 
  2009/12/10 Mario Ivankovits ma...@ops.co.at
 
   For me, this clearly looks like concurrent usage of the request
  map.
 
  All the servlet scopes (session, request, …) are not thread safe
 and
  one
  has to assure that they are not accessed at the same time by
 multiple
  threads.
 
 
 
  This turns out to be hard as e.g. there is no standard how to
  synchronize
  against the session map. As a side note: I often wonder why this
 does
  not
  lead to much more problems in the wild …
 
 
 
  Anyway, in your case it seems the internal datastructure of the
  request map
  is damaged - which in fact is strange as I do not know when the
  request map
  will be accessed by multiple threads.
 
 
 
  Sorry that this is not a solution, but it should give you a clue
  where to
  look next …
 
 
 
  Ciao,
 
  Mario
 
 
 
  *Von:* Jan Baudisch [mailto:jan.baudi...@gmx.net]
  *Gesendet:* Donnerstag, 10. Dezember 2009 08:02
  *An:* MyFaces Discussion
  *Betreff:* 100% CPU Usage and blocking concurrent Threads when
 using
  t:saveState
 
 
 
  Hello MyFaces Community,
 
 
 
  we are using MyFaces 1.2.0 with Tomahawk Sandbox  1.1.5 and have
 the
  problem, that once in a while we get 100% CPU Usage and blocking
  concurrent
  threads because of using t:saveState
 
 
 
  A thread dump shows that the threads always stops at
 
 
 
 at java.util.TreeMap.put(TreeMap.java:545)
 
 at
 
 
 org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager.addSav
  eStateBean(RedirectTrackerManager.java:306)
 
 at
 
 
 org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolv
  er.resolveVariable(RedirectTrackerVariableResolver.java:50)
 
 
 
  (The complete thread dump is attached). The problem shows up on one
  system
  with heavy concurrent usage and JxBrowser as client.
 
 
 
  After we kill these threads using Lambda Probe, the CPU Usage
  normalizes.
 
 
 
  The problem occurs in that method:
 
 
 
  ...
 
 public void addSaveStateBean(String expressionString, Object
  value)
 
 {
 
 if(log.isDebugEnabled())
 
 log.debug(addSaveStateBean:  + expressionString + 
  value= +
  value);
 
 requestBeanMap.put(expressionString, value);
 
 }
 
  ...
 
 private final Map requestBeanMap = new TreeMap(); ...
 
 
 
  As the problem is really severe for us, any hints are highly
  appreciated.
 
 
 
  Many thanks in advance,
 
  -- Jan
 
 
 
 
 really severe for us, any hints are highly
  appreciated.
 
 
 
  Many thanks in advance,
 
  -- Jan
 
 
 



smime.p7s
Description: S/MIME cryptographic signature

RE: 100% CPU Usage and blocking concurrent Threads when using t:saveState

[Mario Ivankovits]

For me, this clearly looks like concurrent usage of the request map.

All the servlet scopes (session, request, …) are not thread safe and one has
to assure that they are not accessed at the same time by multiple threads.

 

This turns out to be hard as e.g. there is no standard how to synchronize
against the session map. As a side note: I often wonder why this does not
lead to much more problems in the wild …

 

Anyway, in your case it seems the internal datastructure of the request map
is damaged - which in fact is strange as I do not know when the request map
will be accessed by multiple threads.

 

Sorry that this is not a solution, but it should give you a clue where to
look next …

 

Ciao,

Mario

 

Von: Jan Baudisch [mailto:jan.baudi...@gmx.net] 
Gesendet: Donnerstag, 10. Dezember 2009 08:02
An: MyFaces Discussion
Betreff: 100% CPU Usage and blocking concurrent Threads when using
t:saveState

 

Hello MyFaces Community,

 

we are using MyFaces 1.2.0 with Tomahawk Sandbox  1.1.5 and have the
problem, that once in a while we get 100% CPU Usage and blocking concurrent
threads because of using t:saveState

 

A thread dump shows that the threads always stops at

 

at java.util.TreeMap.put(TreeMap.java:545)

at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager.addSaveStat
eBean(RedirectTrackerManager.java:306)

at
org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolver.re
solveVariable(RedirectTrackerVariableResolver.java:50)

 

(The complete thread dump is attached). The problem shows up on one system
with heavy concurrent usage and JxBrowser as client.

 

After we kill these threads using Lambda Probe, the CPU Usage normalizes.

 

The problem occurs in that method:

 

...

public void addSaveStateBean(String expressionString, Object value)

{

if(log.isDebugEnabled())

log.debug(addSaveStateBean:  + expressionString +  value= +
value);

requestBeanMap.put(expressionString, value);

}

...

private final Map requestBeanMap = new TreeMap(); ...

 

As the problem is really severe for us, any hints are highly appreciated.

 

Many thanks in advance,

-- Jan 

 



smime.p7s
Description: S/MIME cryptographic signature

RE: [orchestra] could we do a release of this artifacts?

[Mario Ivankovits]

As far as I know, a release should be fine!

 

Ciao,

Mario

 

 

Von: Leonardo Uribe [mailto:lu4...@gmail.com] 
Gesendet: Dienstag, 01. Dezember 2009 23:46
An: MyFaces Development
Betreff: [orchestra] could we do a release of this artifacts?

 

Hi

I would like to add a module for orchestra and jsf 2.0 and do a release of
orchestra in the next days. Is any special step required to do it?

or there is some issue that needs to be solved before release it?

regards,

Leonardo Uribe



smime.p7s
Description: S/MIME cryptographic signature

RE: [vfs] JDK 1.5

[Mario Ivankovits]

Hi!
 
 looking at Ralph's comment in
 https://issues.apache.org/jira/browse/VFS-254
 I am questionning myself, if there's any reason why vfs 2.0 should
 still
 have JDK 1.4 as requirement and not JDK 1.5.

If it is just me, I'd be happy to drop 1.4 dependency - Past votes were 
declined. Probably the time is ripe now.

If it is worth to generify the API is another story - as Ralph pointed out, the 
next logical step for VFS is to support the upcomming JDK 1.7 file.spi stuff. 
That is also my view, and hopefully falls into times where I have more time 
left to spend for VFS again.
Having a complete new api I see no point putting efforts into generifying the 
current api.
If we discover that the JDK 1.7 api is too limiting thigs might change, though.

On the other hand, as the VFS api is today, generifying it might be a 
no-brainer ;-)
We event might manage to generify without changed the VFS api - keeping it 
backward compatible. 

Ciao,
Mario

RE: [orchestra] latest code in core project is not JDK 1.4 compatible

[Mario Ivankovits]

Hi!

Even if you advertised at the beginning, I too think that JDK 1.4 compatibility 
is no longer a must.
Merging core15 might then be the logical step.

Are you going to volunteer? ;-)

Ciao,
Mario

Von: Leonardo Uribe [mailto:lu4...@gmail.com]
Gesendet: Mittwoch, 14. Oktober 2009 01:21
An: MyFaces Development
Betreff: [orchestra] latest code in core project is not JDK 1.4 compatible

Hi

Checking some stuff in orchestra, I have seen that some code in core project 
is not JDK 1.4 compatible.

The question is given JDK 1.4 has reached its end of service life, shouldn't we 
move forward and make orchestra JDK 1.5 and upper compatible? That means also 
merge core15 code with core. Note that if this is not true, we have to 
change/revert some code already committed to make it JDK 1.4 compatible (for 
example, do not make the call to ThreadLocal.remove() on FrameworkAdapter).

regards

Leonardo Uribe

[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763854#action_12763854
 ] 

Mario Ivankovits commented on ORCHESTRA-40:
---

I think we all agree, having a decent handling for this thing is a long missing 
feature here in JSF land.

I also agree that it is much more a virulent problem when you use a 
conversation framework as it is much likely that you run into problems with the 
database else.

The question is if we need it strongly integrated into Orchestra. I've looked 
at the patch, and beside that something gets stored into the 
conversationContext I can not see anything which can not be solved using normal 
JSF phase listeners.
And for storing into the conversationContext we can create a scope which does 
this (instead of accessing it directly). You also gain the ability to decide on 
which level the tokens are kept.
If you do not use Orchestra you simply can the manager bean into the session 
then.

I'd say this component qualifies for its own project, e.g. within our ext 
(sorry, lost the name) project. On the other hand, I understand that - compared 
to seam and webflow - people await such functionality from Orchestra too.
If we add this to Orchestra, I'd like to see it in a separated module, e.g. 
orchestra-jsfext. Would this be feasible?


As for the technical aspect of this patch, I have some notes:
1) Does this solution work with ajax, or will an ajax request trigger a 
DOUBLE_SUBMIT_OR_RELOAD_TYPE notification? I think ajax detection needs to be 
added, at least to detect JSF 2.0 alike ajax requests.

2) I see you store the token in the request parameter. Probably - in the 
context of ajax - storing it as attribute on the UIViewRoot might be better.
If you have to deal with ajax requests you are able to update this value then 
with the new token.

I am also constantly thinking about moving the conversationContext paramter 
into the UIViewRoot - but this is another story.


3) We should also add a default TransactionTokenListener which behaves in a way 
we think an application should react on these events.People than can use it to 
jump start the system. Probably something like MyTransactionTokenListener with 
a faces message added so the user will get some feedback.


4) I'd like to have a way to ignore some requests. E.g. if you issue an jsf 
action which will just stream a PDF to the user (without page change), the 
browser stay on the page, but the token has been used then.
The current token needs to be added to the list of used tokens at the end of 
the request then. Probably an API like 
TransactionTokenManager.getInstance().ignoreRequest() suppress this addittion 
then for the current request. The token can then be used again.
Also trinidad has at least two components which open a window and just report 
the value back to the main window.
Probably we also need a way to ignore requests based on an URL pattern to deal 
with that?


Ciao,
Mario

 A transaction token component inspired by the struts transaction processor
 --

 Key: ORCHESTRA-40
 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
 Project: MyFaces Orchestra
  Issue Type: New Feature
  Components: Conversation
Affects Versions: 1.3.1
Reporter: Bernd Bohmann
Assignee: Simon Kitching
 Attachments: 
 ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, 
 ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, 
 ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch


 A transactionToken Component for orchestra inspired by the struts transaction 
 processor.
 The transaction token is to be used for enforcing a single request for a 
 particular transaction.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: [VOTE] use of jul or commons logging on myfaces core 2.0

[Mario Ivankovits]

IMHO configuring the logger has to be solved by the used container.

Ciao,
Mario


Von: Simon Lessard [mailto:simon.lessar...@gmail.com]
Gesendet: Donnerstag, 01. Oktober 2009 16:57
An: MyFaces Development
Betreff: Re: [VOTE] use of jul or commons logging on myfaces core 2.0

+1 for jul. However, I think we should add an utility class 
(ServletContextListnener? This is the easiest way I know of, if it qualifies 
for easiest at all) in myfaces-shared or extension to make it easier to 
configure the logger because it's way more annoying to configure than 
commons-logging backed with log4j imho.


Regards,

~ Simon
On Thu, Oct 1, 2009 at 1:25 AM, Mario Ivankovits 
ma...@ops.co.atmailto:ma...@ops.co.at wrote:

+1 for jul



reduces dependencies - and sun also use it, no?





Von: Leonardo Uribe [mailto:lu4...@gmail.commailto:lu4...@gmail.com]
Gesendet: Donnerstag, 01. Oktober 2009 04:06
An: MyFaces Development
Betreff: [VOTE] use of jul or commons logging on myfaces core 2.0



Hi

Right now, facelets code added to myfaces core 2.0.x branch uses jul in this 
form:

protected final static Logger log = 
Logger.getLogger(facelets.viewhandler);

But the original myfaces code uses commons logging, (so if there is no 
agreement about use jul, we should unify logging code using commons-logging).

It is necessary to unify in one way or another the code of 2.0.x branch, but 
before that, it is necessary to ask the community about this issue.

So, please vote in this way:

+1 for jul
+1 for commons-logging
+0
-1 and let the code as is (and a reason why).

regards,

Leonardo Uribe

RE: [VOTE] use of jul or commons logging on myfaces core 2.0

[Mario Ivankovits]

+1 for jul

reduces dependencies - and sun also use it, no?


Von: Leonardo Uribe [mailto:lu4...@gmail.com]
Gesendet: Donnerstag, 01. Oktober 2009 04:06
An: MyFaces Development
Betreff: [VOTE] use of jul or commons logging on myfaces core 2.0

Hi

Right now, facelets code added to myfaces core 2.0.x branch uses jul in this 
form:

protected final static Logger log = 
Logger.getLogger(facelets.viewhandler);

But the original myfaces code uses commons logging, (so if there is no 
agreement about use jul, we should unify logging code using commons-logging).

It is necessary to unify in one way or another the code of 2.0.x branch, but 
before that, it is necessary to ask the community about this issue.

So, please vote in this way:

+1 for jul
+1 for commons-logging
+0
-1 and let the code as is (and a reason why).

regards,

Leonardo Uribe

RE: Orchestra multi-bean Conversation strange behaviour

[Mario Ivankovits]

Hi!

Check if the conversationContext= url parameter is correctly passed through the 
link.


Ciao,
Mario


 -Ursprüngliche Nachricht-
 Von: jid1 [mailto:ideligian...@velti.com]
 Gesendet: Montag, 21. September 2009 12:24
 An: users@myfaces.apache.org
 Betreff: Orchestra multi-bean Conversation strange behaviour
 
 
 Hi,
 
 I have a the usual example problem (Master/Detail). I have the
 following
 beans defined:
   bean id=personSearchBean class=xxx.PersonSearchBean
   scope=conversation.access
 orchestra:conversationName=conv1
   /bean
   bean id=personDetailsBean class=xxx.PersonDetailsBean
   scope=conversation.access
 orchestra:conversationName=conv1
   /bean
 
 I pass the details from personSearchBean to  personDetailsBean from
 within
 the JSF using:
 tr:commandLink textAndAccessKey=#{person.name}
 action=#{personDetailsBean.viewPerson} partialSubmit=true
   tr:setActionListener from=#{person}
 to=#{personDetailsBean.person} /
 /tr:commandLink
 
 Now the debug info: (Implements ConversationBindingListener)
 13:15:48,559 DEBUG PersonSearchBean:81 - valueBound...
 (click...view)
 13:17:12,216 DEBUG PersonDetailsBean:23 - Instance: 0 (unique runtime
 object
 id)
 13:17:12,262 DEBUG PersonDetailsBean:47 - valueBound...
 13:17:12,278 DEBUG PersonDetailsBean:29 - setting person: Jon myId=0
 13:17:12,278 DEBUG PersonDetailsBean:30 - conversation name=conv1
 13:17:12,278 DEBUG PersonDetailsBean:52 - valueUnbound...
 13:17:12,294 DEBUG PersonSearchBean:86 - valueUnbound...
 (as you can see at this point it unbound this conversation)
 13:17:12,419 DEBUG PersonDetailsBean:23 - Instance: 1
 13:17:12,434 DEBUG PersonDetailsBean:47 - valueBound...
 13:17:12,434 DEBUG PersonDetailsBean:35 - Reading person from: 1
 13:17:12,434 DEBUG PersonDetailsBean:36 - conversation name=conv1
 
 note: I have tried using conversation.manual because I am using AJAX
 and it
 could mess things up but same behaviour.
 
 13:22:57,231 DEBUG PersonSearchBean:81 - valueBound...
 13:23:00,653 DEBUG PersonDetailsBean:23 - Instance: 0
 13:23:00,684 DEBUG PersonDetailsBean:47 - valueBound...
 13:23:00,700 DEBUG PersonDetailsBean:29 - setting person: Man myId=0
 13:23:00,716 DEBUG PersonDetailsBean:30 - conversation name=conv1
 (create new instance but though because it is manual it is not unbound)
 13:23:00,856 DEBUG PersonDetailsBean:23 - Instance: 1
 13:23:00,856 DEBUG PersonDetailsBean:47 - valueBound...
 13:23:00,856 DEBUG PersonDetailsBean:35 - Reading person from: 1
 13:23:00,856 DEBUG PersonDetailsBean:36 - conversation name=conv1
 --
 View this message in context: http://www.nabble.com/Orchestra-multi-
 bean-Conversation-strange-behaviour-tp25530275p25530275.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.

RE: MyFaces Spring Orchestra Best Practice

[Mario Ivankovits]

Hi!

You can use two strategies:

1) use conversation.access (as you outlined) with the same conversationName. 
You can configure the conversationName in your spring config. Just use the same 
name for aBean and bBean.
This makes it easy to pass the selected bean to the second bean, and due to the 
same conversationName they share the same persistenceContext and it is no 
longer bad to pass around entities. It depends on how many additional data you 
load on your detail bean, if you load a lot of things strategy 2 might be 
better.

2) still use conversation.acces, but do not configure a conversationName. You 
end up having two persistence contexts.
In this scenario you should not pass around the entity bean, but just pass the 
primary key of the entity and reload the entity in bBean

Might be something like this:
tr:setActionListener from=#{aBean.key} to=#{bBean.selectedEntityKey} /

2a) Now, you have an additional possibility. If you would like to detach the 
knowledge of the aView how to pass the key to the bView you can configure the 
UrlParameterNavigationHandler.

Look at the book excerpt here: 
http://books.google.at/books?id=FPxif81mgYoClpg=PA195ots=W7nh7z6p1Zdq=orchestra%20UrlParameterNavigationHandlerpg=PA196#v=onepageq=orchestra%20UrlParameterNavigationHandlerf=false

Using the navigation-case configuration you are now able to pass the key from 
one view to the other.
On the receiving side you have to use the parameterMap to fetch the key and 
reload the entity then.

It depends on your application if it is feasable to render the key in the url. 
It makes them bookmarkable, but also vulnerable.


In this area it is hard to tell what is best practice.
I normally use 1 or 2 and sometimes 2a  :-)

Ciao,
Mario

-Ursprüngliche Nachricht-
Von: jid1 [mailto:ideligian...@velti.com] 
Gesendet: Freitag, 18. September 2009 17:01
An: users@myfaces.apache.org
Betreff: MyFaces Spring Orchestra Best Practice


hello,

I am trying to implement the following:

Backing bean A is used to render search results
Backing bean B is used to render the specific details of one result

I am setting both beans to conversation.access and don't want to 'access'
them from different components (as it's not supposed to be best practice)

Also I could use:
tr:setActionListener from=#{aBean} to=#{bBean.selection} /

But:
a. The first component will access the second in the JSF domain
b. I would like to do it from the backing bean so I can call 
Conversation.getCurrentInstance().invalidate();

Can you please tell me the 'best practice' solution?
(ideally speaking these are in the same conversation, but let's say they
aren't). Any documentation links very welcomed!! 

Thanks
-- 
View this message in context: 
http://www.nabble.com/MyFaces-Spring-Orchestra-Best-Practice-tp25510295p25510295.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

AW: [VFS] Minimum Java version

[Mario Ivankovits]

 Well, if you're going to make a jump, why go to something that's EOSL very 
 soon?

For me, JDK 1.6 would be fine too.
But, I'd say this is just a minor issue as the main things one will notice 
(generics, enhanced for syntax) are there with JDK 1.5.
Are there any API changes critical for VFS to use? I don't think so.

The next big jump VFS might see will be JDK 1.7 as then they come with a 
pluggable file provider [1] thingy too. We will see, how VFS fits there.
In fact, I think VFS3 will provide just filesystem providers for JDK 1.7 - 
don't know if they can deal with layered filesystems though.


Ciao,
Mario

[1] http://openjdk.java.net/projects/nio/javadoc/java/nio/file/FileSystem.html


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: Concurrent requests and Orchestra

[Mario Ivankovits]

Hi!

A PersistenceContext is not thread safe, therefore, Orchestra tries to avoid 
that by locking the request.
It would be nice, if Orchestra does this just for requests requireing a 
PersistenceContext. But till today, we did not manage to spend some time to 
optimize that code.

You can set the webapp init parameter 
org.apache.myfaces.orchestra.CoreConfig:SERIALIZE_REQUESTS to false so that 
Orchestra does not check for thread safety.

You then have to ensure threadsafety against the PersistenceContext yourself 
(which might not be easy … not to say, impossible :-( )

Ciao,
Mario


Von: vojtech.zav...@gmail.com [mailto:vojtech.zav...@gmail.com] Im Auftrag von 
Vojtech Zavrel
Gesendet: Donnerstag, 20. August 2009 10:51
An: users@myfaces.apache.org
Betreff: Concurrent requests and Orchestra

Hi,
 we have a problem with concurrent request using combination Orchestra + Spring 
+ Trinidad. The application uses more than one window per session, so we have 
migrated all our beans to orchestra's conversation scope using 
conversation.manual.
We have a progress bar which is poling AJAX request during the main request is 
being done. Once user is waiting to the main request, there are partial 
requests each five seconds using Trinidad Javascript API. To be able handle 
more requests the partial request goes in another frame with same 
conversationContext.
Both partial and full request are accessing to the same bean. And this is the 
problem because there is there is ReentrantLock used not to be able to access 
to FacesContex from different thread. So that means, that we are not able to 
access to the progressbar model and the partial request is locked till the full 
request is finished. But I haven't understood why there is this concurrent 
limitatins because they aren't in other scopes.

This is the comment from the source code:

// Fetch a context for this request if one already exists, and lock it
72 // so that concurrent requests that affect this context block until
73 // this request is complete. Not doing so can cause races for resources
74 // within the current context, such as beans or PersistenceContexts.

But what kind of races and why there are not same problems using other scopes. 
Can anybody explain me the reasons please? Is there any possibility how to make 
a workaround?

Thanks


Daemon Thread [http-8080-1] (Suspended)
Object.wait(long) line: not available [native method] [local variables 
unavailable]
_ReentrantLock.lockInterruptibly() line: 80
ConversationContext.lockInterruptablyForCurrentThread() line: 475
ContextLockRequestHandler.init(FacesContext) line: 96
OrchestraFacesContextFactory$1.init(OrchestraFacesContextFactory, 
FacesContext, boolean, LinkedList, FacesContext) line: 119
OrchestraFacesContextFactory.getFacesContext(Object, Object, Object, Lifecycle) 
line: 100
RequestParameterFacesContextFactory.getFacesContext(Object, Object, Object, 
Lifecycle) line: 92
FacesContextFactoryImpl.getFacesContext(Object, Object, Object, Lifecycle) 
line: 64
FacesServlet.service(ServletRequest, ServletResponse) line: 260
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 
290
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206
TrinidadFilterImpl._invokeDoFilter(ServletRequest, ServletResponse, 
FilterChain) line: 238
TrinidadFilterImpl._doFilterImpl(ServletRequest, ServletResponse, FilterChain) 
line: 195
TrinidadFilterImpl.doFilter(ServletRequest, ServletResponse, FilterChain) line: 
138
TrinidadFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 92
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 
235
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206
LicenseFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 123
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 
235
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206
ResponseHeaderFilter.doFilter(ServletRequest, ServletResponse, FilterChain) 
line: 54
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 
235
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206
SessionTimeoutFilter.doFilter(ServletRequest, ServletResponse, FilterChain) 
line: 116
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 
235
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206
StandardWrapperValve.invoke(Request, Response) line: 233
StandardContextValve.invoke(Request, Response) line: 175
StandardHostValve.invoke(Request, Response) line: 128
ErrorReportValve.invoke(Request, Response) line: 102
StandardEngineValve.invoke(Request, Response) line: 109
CoyoteAdapter.service(Request, Response) line: 263
Http11Processor.process(Socket) line: 844
Http11Protocol$Http11ConnectionHandler.process(Socket) line: 584
JIoEndpoint$Worker.run() line: 447
Thread.run() line: 619

RE: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/FileSystemOptions.java

[Mario Ivankovits]

Hi!

 From personal experience, I've found working with it
 to be awkward and brittle. I would much prefer to have each provider
 subclass FileSystemOptions and provide the getters and setters there. Then,
 at least, you could do an instanceof on the FileSystemOptions and determine
 what options are actually supposed to be there.

Look, The FileSystemOptions holds options for various filesystem 
implementations - at the same time!
The reason for this is, that, given the url is provided by the user, you simply 
do not know which real implementation will be used.
Thus, you have to provide e.g. ftp settings and sftp settings at the same time 
and let VFS decide which options to use - depending on the URL provided by the 
user.

Why would you like to pass in an option-set using a concrete config class if 
the URL is anything else then concrete.
Also, a layered filesystem might require different settings e.g. 
compression-level of a zip-file on an ftp share.

This might require you to configure the zip filesystem (compression) AND the 
ftp filesystem (active/passive mode)

Also, the idea was to implement some sort of GlobalFileSystemOptions, the 
filesystem implementation then does not need to be changed, just the 
FileSystemOptions have to take care of that.


IF you use the options in a way which allows you to know which kind of 
filesystem will be used - good - but then the builder is just another layer, 
but not awkward and brittle I think.


I wont say that there aren't other ways to solve that, but using simple 
inheritance and instanceof is not the correct way.

Hmmm ... what I can think of is to refactor things that way:

* FileSystemOptions holds just a map of configurations like MapClass, 
FileSystemOption
* FileSystemOptions.set(Class vfsFilesystemClass, FileSystemOption options)

FileSystemOption then can be a concrete instance of a set of configurations for 
one specific filesystem, so you might have HttpFileSystemOption, 
SftpFileSystemOption etc. Each of them holding all possible filesystem options.

Sure, this completely breaks backward compatibility - and the 
GlobalFileSystemOptions thing needs to be solved somehow.

Ciao,
Mario

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[jira] Commented: (ORCHESTRA-43) IllegalStateException on application startup when using conversations with beans that implement ApplicationListener

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/ORCHESTRA-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12735612#action_12735612
 ] 

Mario Ivankovits commented on ORCHESTRA-43:
---

Does it makes sense to have a conversation scoped bean implementing the 
ApplicationListener?

I'd suggest to make a separate bean for the ApplicationListener use case, and 
then, inject that bean (I assume you need some informations from this event) 
into the conversation scoped bean.

Starting a conversation from within an application-start-event is not possible.

 IllegalStateException on application startup when using conversations with 
 beans that implement ApplicationListener
 ---

 Key: ORCHESTRA-43
 URL: https://issues.apache.org/jira/browse/ORCHESTRA-43
 Project: MyFaces Orchestra
  Issue Type: Bug
Affects Versions: 1.3.1
 Environment: Spring 2.5.6
Reporter: Jose Luis Freire
Priority: Critical

 If we have a bean with conversation scope that implements 
 ApplicationListener, on application startup we get a 
 java.lang.IllegalStateException: FrameworkAdapter not found.
 This happens because a application start event is fired and at that time no 
 HTTP session is in progress.
 The stack trace is:
 java.lang.IllegalStateException: FrameworkAdapter not found
   at 
 org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:120)
   at 
 org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:96)
   at 
 org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.getRealBean(AbstractSpringOrchestraScope.java:330)
   at 
 org.apache.myfaces.orchestra.conversation.spring.ScopedBeanTargetSource.getTarget(ScopedBeanTargetSource.java:73)
   at 
 org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:666)
   at 
 org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:616)
   at 
 com.vianobis.campaign.web.activity.ActivityListBackend$$EnhancerByCGLIB$$975174a6.onApplicationEvent(generated)
   at 
 org.springframework.context.event.SimpleApplicationEventMulticaster$1.run(SimpleApplicationEventMulticaster.java:78)
   at 
 org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49)
   at 
 org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:76)
   at 
 org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:274)
   at 
 org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:736)
   at 
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:383)
   at 
 org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
   at 
 org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
   at 
 org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
   at 
 org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)
   at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
   at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
   at 
 org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
   at 
 org.apache.catalina.core.StandardService.start(StandardService.java:516)
   at 
 org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
   at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: svn commit: r797267 - in /commons/proper/configuration/trunk/src/java/org/apache/commons/configuration: FileSystem.java VFSFileSystem.java

[Mario Ivankovits]

Hi!

 
 Modified:
 commons/proper/configuration/trunk/src/java/org/apache/commons/configur
 ation/VFSFileSystem.java
 
 -private FileSystemOptions setHttpOptions(FileSystemOptions opts,
 Map map)
 +private void setProperty(FileSystemConfigBuilder builder,
 FileSystemOptions options,
 + String key, Object value)
  {
 -setDefaultOptions(opts, map);
 +String methodName = set + key.substring(0,1).toUpperCase() +
 key.substring(1);
 +Class[] paramTypes = new Class[2];
 +paramTypes[0] = FileSystemOptions.class;
 +paramTypes[1] = value.getClass();

Hmmm ... I am not quite sure of the rest of the code, but did you see the 
DelegatingFileSystemOptionsBuilder [1]?

It also sets the configuration using reflection based on just strings.


Ciao,
Mario


[1] 
http://commons.apache.org/vfs/apidocs/org/apache/commons/vfs/util/DelegatingFileSystemOptionsBuilder.html

AW: [VOTE] Change community@ list settings

[Mario Ivankovits]

+1


-Ursprüngliche Nachricht-
Von: Jukka Zitting [mailto:jukka.zitt...@gmail.com] 
Gesendet: Dienstag, 07. Juli 2009 23:28
An: community@apache.org
Betreff: [VOTE] Change community@ list settings

Hi,

This mailing list is currently publicly archived, but only open for
Apache committers to subscribe and post to. This list policy was set
by a vote [1] in 2002. I would like to change this list to be open to
everyone just like all our public project mailing lists.

Why? Three reasons: a) the extra moderation settings make it hard for
people to post here [2,3], b) external mail archives can't easily get
updates of recent posts [4], and c) I see no reason to restrict the
Apache community to include just the committers. This list is today
very different from what it was in 2002.

So, please vote on changing the settings of this list so that everyone
is free to subscribe or post to this list (only posts from
non-subscribers are moderated, see [5] for details). This majority
vote is open for the next seven days.

[ ] +1 Change list settings (allow anyone to subscribe or post)
[ ] -1 Keep the current settings

My vote is +1.

[1] 
http://mail-archives.apache.org/mod_mbox/www-community/200211.mbox/3dc3a725.50...@apache.org
[2] 
http://mail-archives.apache.org/mod_mbox/www-community/200905.mbox/510143ac0905260745y75f5a2f3h33c305c0dcff9...@mail.gmail.com
[3] 
http://mail-archives.apache.org/mod_mbox/www-community/200907.mbox/510143ac0907030544n49a3c50ctb937b2ccee4a7...@mail.gmail.com
[4] http://apache.markmail.org/search/?q=list:org.apache.community
[5] https://issues.apache.org/jira/browse/INFRA-2127

BR,

Jukka Zitting

-
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org


-
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org

AW: Shale Annotations

[Mario Ivankovits]

Hmmm … it might be worth looking at using Orchestra without Spring. Guice is 
not an option for your clients either, is it?

If you do not use Spring, you also do not use its persistence capabilities ;-) 
So then, using a CGLIB based (or whatever enhancer lib) approach which simply 
enhances the beans in a way which is required by Orchestra might be enough.

Sure, we can not yet use the faces-config.xml to configure the managed beans 
for Orchestra.
But probably we can introduce something like a orchestra-config.xml for the 
scope and managed bean configuration.

@community: What do you think? Is it worth it?

Ciao,
Mario


Von: Kito Mann [mailto:kito.m...@virtua.com]
Gesendet: Dienstag, 07. Juli 2009 23:45
An: MyFaces Development
Betreff: Re: Shale Annotations

The problem with using Orchestra is that it requires Spring, which is an extra 
framework that some organizations don't necessarily need. Although JSF 
managed beans aren't that great, sometimes they're a better choice than 
integrating Spring into the project.
---
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99  http://twitter.com/jsfcentral
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3

On Tue, Jul 7, 2009 at 4:46 PM, Bruno Aranda 
brunoara...@gmail.commailto:brunoara...@gmail.com wrote:
Hi,

What about just using MyFaces Orchestra? It does many of the thing the
shale tiger extensions used to do (and even includes lots of useful
features). You have the Orchestra view controller annotations and if
you want more annotations, you can use the Spring ones to register
backing beans and so on...

Cheers,

Bruno

2009/7/7 Kito Mann kito.m...@virtua.commailto:kito.m...@virtua.com:
 Hello everyone,

 I know that MyFaces is in the process of swallowing Shale Test. What do you
 guys think about swallowing Shale Annotations, too? I know it's a dead-end
 add-on considering JSF 2, but I run into enough clients that aren't going to
 be using JSF 2 for a lng time, and could use annotation support today.
 Given Shale's retired status, they're never going to touch it.

 Thoughts?
 ---
 Kito D. Mann -- Author, JavaServer Faces in Action
 http://twitter.com/kito99  http://twitter.com/jsfcentral
 http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
 http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
 +1 203-404-4848 x3

RE: AW: slf4j and myfaces

[Mario Ivankovits]

Start voting? ;-)


From: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Sent: Saturday, June 06, 2009 11:45 AM
To: MyFaces Development
Subject: Re: AW: slf4j and myfaces

yes the -1 vote would be a veto in view of slf4j
- no agreement - we would vote about jul.

or as mario suggested - let's start voting about jul.

@mario:
yes - i'll wait until monday for sure. and we should vote a bit longer than 
usual - due to holidays (+ it's an important topic for all myfaces projects)

regards,
gerhard

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2009/6/6 Ganesh gan...@j4fry.orgmailto:gan...@j4fry.org
Hi,


 we could also vote first about slf4j and everybody who prefers jul should 
 vote -1
 if we don't have a majority for slf4j, we have to vote about jul.
 is that ok for everybody?
From http://www.apache.org/foundation/voting.html my understanding of a -1 
vote is different from this.

 Vetos

A code-modification proposal may be stopped dead in its tracks by a -1 vote by 
a qualified voter. This constitutes a veto, and it cannot be overruled nor 
overridden by anyone. Vetos stand until and unless withdrawn by their casters.

To prevent vetos from being used capriciously, they must be accompanied by a 
technical justification showing why the change is bad (opens a security 
exposure, negatively affects performance, etc.). A veto without a justification 
is invalid and has no weight. 

Better use the fraction system for voting on the logging system:

  * +0: 'I don't feel strongly about it, but I'm okey with this.'
  * -0: 'I won't get in the way, but I'd rather we didn't do this.'
  * -0.5: 'I don't like this idea, but I can't find any rational justification 
for my feelings.'
  * ++1: 'Wow! I like this! Let's do it!'
  * -0.9: 'I really don't like this, but I'm not going to stand in the way if 
everyone else wants to go ahead with it.'
  * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills 
necessary to help out.'

Best regards,
Ganesh

AW: [VOTE] jul instead of commons-logging

[Mario Ivankovits]

+1

Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Dienstag, 09. Juni 2009 20:33
An: MyFaces Development
Betreff: [VOTE] jul instead of commons-logging

hi,

short description:
this first vote is about the switch from commons-logging (cl) to 
java.util.logging (jul).
it's a binding vote for the next releases of all myfaces libs which are 
currently using commons-logging.
so e.g. trinidad isn't affected. details are available at [1]

if there won't be a majority, we will open a second vote (switch from 
commons-logging to slf4j).


[ ] +1 for replacing cl with jul
[ ] +0
[ ] -1 for keeping cl or to force a second vote for slf4j as replacement


regards,
gerhard

[1] http://www.nabble.com/slf4j-and-myfaces-td23890255.html

Re: spring security/acegi and myFaces orchestra conversation scope

[Mario Ivankovits]

Hi!

 Is there a proper way to integrate spring security on an conversation scope, 
 provided by orchestra, so that one can login for each conversation 
 separately?

Phu, we too use Spring Security, but to authenticate against the whole session.

First, I think you meant you would like to authenticate against a conversation 
context, no? The conversation context is the one responsible to do the window 
separation and to hold multiple conversations.

Your use case is pretty sophisticated. Unhappily I have no clue if it can work 
at all. You have to find a way to let Spring Security get/fetch the principal 
from the conversation context. Are you using form authentication? Else you 
might run into problems where the browser sends already known user credentials 
to any login request.

Probably, best will be you implement your own security layer :-(
 

Ciao,
Mario

AW: [vfs] MemcachedFilesCache for Google App Engine (object serialization)

[Mario Ivankovits]

Hi!

 I think the answer is: the FilesCache is used to optimize resolveFile()
 performance, and to reuse FileObject instances, but is not used to cache the
 actual file content.

Thats correct!


Ciao,
Mario

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

AW: slf4j and myfaces

[Mario Ivankovits]

Sorry, for top-posting, but Outlook makes it too hard to do it right ;-)

Well, yet another configuration option for configuring our logging facade (yes, 
you are right, it is a facade) is for sure also not a good option.

As a last note to this discussion I'd like to say, that not dealing with the 
class loader issue does not mean that the webapp-reloading-memory-leak has been 
addressed in some way.

Anyway, if you think it (slf4j) is a good way to go, I'll not stand in between 
:-) 

Ciao,
Mario

-Ursprüngliche Nachricht-
Von: Manfred Geiler [mailto:manfred.gei...@gmail.com] 
Gesendet: Freitag, 05. Juni 2009 20:50
An: MyFaces Development
Betreff: Re: slf4j and myfaces

On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits ma...@ops.co.at wrote:
 Hi!

 Could one please eloberate a little bit more in detail what the pros are of
 slf4j?

Pros:
No class loader ambiguousness (as you mentioned)
You get what you define (especially when using maven):
compile-dependency to slf4j-api
runtime-dependency to slf4j-adapter of YOUR choice
-- that's it!

No wild guessing like with JCL: Use Log4j if it is anywhere in the
(web container) classpath, else use Java logging... What, if I want to
use Java logging although there is Log4j in the classpath?!
Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not again...
Yes, I know commons-logging.properties solves this, but that's
awful... (BTW, I hate properties files in the root package namespace!)


 Notice, I switched to it in our company project - but always using the
 commons-logging api and just used the slf4j-over-cl wrapper. This is
 something wich is possible for each and ever user of myfaces already, just
 by adjusting the depencendcies correctly.

Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part
that reroutes JCL calls to the slf4j API.
Yes, that is a possible solution, but keep in mind that this is kind
of a hack. It is actually a reimplementation of the JCL API
(namespace) that routes all calls to SLF4J.
It's meant as runtime solution for legacy libs. Using it as compile
time dependency might be a shortcut, but my feeling says it's not the
nicest solution.


 Lately I even switched to my own logging wrapper, but this is another story.
 In the end, everything still uses the cl API which is proven to work fine.
 (I created the org.apache.commons.logging package structure with my own
 classes - which for sure is not possible for myfaces!).

yet another logging wrapper WHY do so many people feel they must
write such a thing? JCL and slf4j ARE ready-to-use logging wrappers.
So???


 I still think, that using the cl api is the best we can do for our users. If
 they then use cl as implementation - and if this is considered good - is
 another story, but nothing WE should anticipate.

They CAN use JCL if myfaces uses slf4j. They just define a
slf4j-jcl-x.x.x.jar runtime-dependency and everything is fine.


 As far as I can say the cl api is rock solid, just the class-loader stuff is
 a pain. But (again AFAIK), slf4j does not solve it, it just does not deal
 with it.

slf4j DOES solve the problem by avoiding highly sophisticated classloader magic!


 Before we start using any other logging api I'd suggest to build our own
 thin myfaces-logging wrapper where one then can easily plug in log4j, cl,
 jul (java utils ogging) or whatever - we do not even have to provide any
 other impl than for jul.

yet another logging wrapper... (see above)

How would you implement such a pluggable wrapper? Yet another
(mandatory) config parameter. System property? Servlet context param?
Come on!
What about this: looking for existing well-known logging
implementations and define some priority rules... Dejavu. See the
problem?


 As a plus, this then will remove a dependency - a dependency to any logging
 framework - which - in terms of dependencies can be considered as a good
 thing, no?

You buy this good thing by re-implementing SLF4J and/or JCL.
Serious. I cannot imagine a wrapper (actually a facade, right?)
implementation that is versatile for the developers and pluggable for
the users and has less source code than any of the well-known logging
facade APIs (slf4j and jcl). They both are actually meant to heal the
java world from proprietary yet another logging facades/wrappers!


+1 for using SLF4J as logging facade for future MyFaces developments
(JSF 2.0, ...)
+0 for replacing JCL by SLF4J for all existing code (if someone is
volunteering to do the job I have no problem with that...)


--Manfred
anfred

AW: slf4j and myfaces

[Mario Ivankovits]

But why not use java.util.logging then at all. There is an example [1] which 
shows how to reroute it to any other logging impl.

This too will remove the need of any logging dependency then.

Look, with slf4j you will end with three dependencies.

* the slf4j api
* the commons-logging to slf4j bridge (for all the other libraries your app is 
going to use and which still are using commons-logging)
* the slf4j impl (an since the impl itself provides nothing than the bridge, 
you need the logging impl to)

If you are going to use java.util.logging - which is a pain to setup, but 
sufficient for many use-cases - these are three (up to four) dependencies too 
much - just for logging!

I think, this will not be a bad move - and moves us completely out of line of 
this question once and for all I think.

The java.util.logging api itself provides the same possibilities than we have 
today in our libraries - just different namings.

Ciao,
Mario

[1] http://wiki.apache.org/myfaces/Trinidad_and_Common_Logging

-Ursprüngliche Nachricht-
Von: Mario Ivankovits [mailto:ma...@ops.co.at] 
Gesendet: Samstag, 06. Juni 2009 08:08
An: 'MyFaces Development'
Betreff: AW: slf4j and myfaces

Sorry, for top-posting, but Outlook makes it too hard to do it right ;-)

Well, yet another configuration option for configuring our logging facade (yes, 
you are right, it is a facade) is for sure also not a good option.

As a last note to this discussion I'd like to say, that not dealing with the 
class loader issue does not mean that the webapp-reloading-memory-leak has been 
addressed in some way.

Anyway, if you think it (slf4j) is a good way to go, I'll not stand in between 
:-) 

Ciao,
Mario

-Ursprüngliche Nachricht-
Von: Manfred Geiler [mailto:manfred.gei...@gmail.com] 
Gesendet: Freitag, 05. Juni 2009 20:50
An: MyFaces Development
Betreff: Re: slf4j and myfaces

On Fri, Jun 5, 2009 at 19:49, Mario Ivankovits ma...@ops.co.at wrote:
 Hi!

 Could one please eloberate a little bit more in detail what the pros are of
 slf4j?

Pros:
No class loader ambiguousness (as you mentioned)
You get what you define (especially when using maven):
compile-dependency to slf4j-api
runtime-dependency to slf4j-adapter of YOUR choice
-- that's it!

No wild guessing like with JCL: Use Log4j if it is anywhere in the
(web container) classpath, else use Java logging... What, if I want to
use Java logging although there is Log4j in the classpath?!
Someone dropped a log4j.jar in the tomcat/lib folder. Oh no, not again...
Yes, I know commons-logging.properties solves this, but that's
awful... (BTW, I hate properties files in the root package namespace!)


 Notice, I switched to it in our company project - but always using the
 commons-logging api and just used the slf4j-over-cl wrapper. This is
 something wich is possible for each and ever user of myfaces already, just
 by adjusting the depencendcies correctly.

Guess, you meant the jcl-over-slf4j.jar bridge, right? That's the part
that reroutes JCL calls to the slf4j API.
Yes, that is a possible solution, but keep in mind that this is kind
of a hack. It is actually a reimplementation of the JCL API
(namespace) that routes all calls to SLF4J.
It's meant as runtime solution for legacy libs. Using it as compile
time dependency might be a shortcut, but my feeling says it's not the
nicest solution.


 Lately I even switched to my own logging wrapper, but this is another story.
 In the end, everything still uses the cl API which is proven to work fine.
 (I created the org.apache.commons.logging package structure with my own
 classes - which for sure is not possible for myfaces!).

yet another logging wrapper WHY do so many people feel they must
write such a thing? JCL and slf4j ARE ready-to-use logging wrappers.
So???


 I still think, that using the cl api is the best we can do for our users. If
 they then use cl as implementation - and if this is considered good - is
 another story, but nothing WE should anticipate.

They CAN use JCL if myfaces uses slf4j. They just define a
slf4j-jcl-x.x.x.jar runtime-dependency and everything is fine.


 As far as I can say the cl api is rock solid, just the class-loader stuff is
 a pain. But (again AFAIK), slf4j does not solve it, it just does not deal
 with it.

slf4j DOES solve the problem by avoiding highly sophisticated classloader magic!


 Before we start using any other logging api I'd suggest to build our own
 thin myfaces-logging wrapper where one then can easily plug in log4j, cl,
 jul (java utils ogging) or whatever - we do not even have to provide any
 other impl than for jul.

yet another logging wrapper... (see above)

How would you implement such a pluggable wrapper? Yet another
(mandatory) config parameter. System property? Servlet context param?
Come on!
What about this: looking for existing well-known logging
implementations and define some priority rules... Dejavu. See the
problem?


 As a plus, this then will remove a dependency

AW: slf4j and myfaces

[Mario Ivankovits]

Hi!

 There are two pros of slf4j I did not mention yet:
 1. parameterized messages, which make it possible to omit those ugly
 if (logger.isDebugEnabled()) {... conditions, without performance
issue: see http://www.slf4j.org/faq.html#logging_performance

http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Logger.html

Seems that JUL support this too if we use the log() methods.

I've looked at the java source. JUL is using MessageFormat.Format then in the 
formatter only if there is a placeholder in the message ({0-{4).
Not that bad.

 2. it's no longer possible to forget the log message by writing
 logger.error(exc) instead of logger.error(an error has occured,
 exc). This is because the slf4j api is strict and only allows a
 String (and not an Object) as first argument.

Funny, JUL also has no log(ex) method, just log(String, ex) (+ level for sure). 
Seems the JUL API is not that bad :-)


 What I'm not sure is
 if the JUL to other logging impl bridge is multiple application
 friendly. What happens if the JUL root handler is replaced (thats what
 these bridges seem to do). Does this influence the servlet container
 logging and other apps as well?

Seems to be true, JUL is not container friendly by default. But this needs to 
be addressed by the container (and the Java Spec guys ;-) ).
It seems, this is the reason for JULI, the Tomcat logging impl.
Also JBoss solved that (as they use Tomcat ?!). See for a documentation here:

http://www.jboss.org/file-access/default/members/jbossweb/freezone/docs/latest/logging.html

They replace the LogManager by a container friendly LogManager. The JUL using 
app does not need to know that.

Yeah, seems JUL can be our salvation finally ;-)

Ciao,
Mario

Re: slf4j and myfaces

[Mario Ivankovits]

 that would be possible as well. i just started with slf4j since we already 
 discussed it and udo wrote about the switch to slf4j in the next release...

 we could also vote first about slf4j and everybody who prefers jul should 
 vote -1

Just wait until Monday if possible, then enough developers should have 
commented on the thread already.
Probably it is clear then already that a vote for JUL is enough.


 (i don't like the idea that every myfaces project ends up with its special 
 logging framework dependency.)

Yes, thats true.

Ciao,
Mario

AW: slf4j and myfaces

[Mario Ivankovits]

Hi!

 The only downside I see is that we might break compatibility for java 
 1.4 since JUL gut some overhaul between 1.4 and 5, but on the other hand 
 is it really important anymore?
 Which projects still have to be on 1.4

In 1.4.2 the log methods in question were already there. So - as a logging user 
only - this might not be a problem. 

http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html


Ciao,
Mario

Re: Myfaces 2.0 PPR ResponseWriter impl

[Mario Ivankovits]

Hi!

Not sure if this adds any value to this discussion, but


  The only question is how facelets handles this case, but I assume 
  faclets simply skips comments and passes it through with out.write!
 I'm talking about !-- on the page level, not on the component level. 
 Facelets will treat !-- as markup. Tags nested inside will still be 
 evaluated. With the writeElement/writeAttribute solution this could end 
 up in script being evaluated though nested inside !-- --.

You can configure this using facelets.SKIP_COMMENTS=true (what we did). 
Comments are comments then (and skipped)

Hopefully mojarra will provide a setting for this too, and, even better, have 
true as default.

Ciao,
Mario

AW: slf4j and myfaces

[Mario Ivankovits]

Hi!

Could one please eloberate a little bit more in detail what the pros are of 
slf4j?

Notice, I switched to it in our company project - but always using the 
commons-logging api and just used the slf4j-over-cl wrapper. This is something 
wich is possible for each and ever user of myfaces already, just by adjusting 
the depencendcies correctly.

Lately I even switched to my own logging wrapper, but this is another story. In 
the end, everything still uses the cl API which is proven to work fine. (I 
created the org.apache.commons.logging package structure with my own classes - 
which for sure is not possible for myfaces!).


I still think, that using the cl api is the best we can do for our users. If 
they then use cl as implementation - and if this is considered good - is 
another story, but nothing WE should anticipate.
As far as I can say the cl api is rock solid, just the class-loader stuff is a 
pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it.

Before we start using any other logging api I'd suggest to build our own thin 
myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java 
utils ogging) or whatever - we do not even have to provide any other impl than 
for jul.
As a plus, this then will remove a dependency - a dependency to any logging 
framework - which - in terms of dependencies can be considered as a good 
thing, no?

Ciao,
Mario

Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Freitag, 05. Juni 2009 17:18
An: MyFaces Development
Betreff: slf4j and myfaces

hello all,

again the logging-framework topic :)
there were several discussions about it and i'm not aware of an agreement.

udo wrote [1]:
replace commons-logging with slf4j

as i know we agreed on using one logging framework dependency for all myfaces 
projects.
if i remember correctly, most of us prefer slf4j.

- i suggest to vote about using slf4j in all myfaces projects.
(at least if a project is using an external logging framework.)

regards,
gerhard

[1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html

AW: slf4j and myfaces

[Mario Ivankovits]

Why?

I think our wrapper can do pretty much the same than slf4j does. Having a
public static Log log = LogFactory.getLog(MyClass.class)
can easily be supported by our logging framework.

Then, any known logging framework has the most possible information available, 
whatever it does with it.

If a logging framework use a static position of the stack trace, to gather its 
information, is bound to fail anyway and has to be considered a bad 
implementation, no?

AFAIK, in terms of cl class loader issues, having a static log ist not bad if 
the logging facade has been loaded with the same class-loader than the library 
were loaded. Which should always be the case with our own wrapper.

Yes, I know, we end up having a slf4j within myfaces. But I see no point having 
a dependency to such a simple API - which exactly adds no value, but forces 
every cl user to setup the sfl4j-over-cl bridge.

IMHO, the java way to do it is to provide our own simple logging wrapper, by 
using jul as default impl. I know that jul sucks, but this then can easily be 
customized by the developer.

Mojarra also uses jul, no? So good or bad, this i something we have to deal 
with anyway - providing a pluggable logging api is fair enough then. I think, 
most of the time the user will not care and just start using jul.

Too bad that SUN did not manage to provide a logging api which has been widely 
accepted :-(

Ciao,
Mario

Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Freitag, 05. Juni 2009 20:22
An: MyFaces Development
Betreff: Re: slf4j and myfaces

@mario:
which logging frameworks would be supported by such a wrapper. i can just 
mention that there are logging frameworks out there which internally force an 
exception and statically use entry x of the call hierarchy - so such a wrapper 
would lead to wrong logging information.

regards,
gerhard

(after reformulating the previous mail quite quickly the text wasn't perfect - 
but i think you know what i mean...)


2009/6/5 Gerhard Petracek 
gerhard.petra...@gmail.commailto:gerhard.petra...@gmail.com
@matthias:

yes - that's the reason for my comment: ...external logging framework...
@udo:
imo we should discuss the logging topic before we have a release which already 
uses slf4j - especially the suggestion of mario sounds interesting.


regards,
gerhard

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces


2009/6/5 Mario Ivankovits ma...@ops.co.atmailto:ma...@ops.co.at


Hi!



Could one please eloberate a little bit more in detail what the pros are of 
slf4j?



Notice, I switched to it in our company project - but always using the 
commons-logging api and just used the slf4j-over-cl wrapper. This is something 
wich is possible for each and ever user of myfaces already, just by adjusting 
the depencendcies correctly.



Lately I even switched to my own logging wrapper, but this is another story. In 
the end, everything still uses the cl API which is proven to work fine. (I 
created the org.apache.commons.logging package structure with my own classes - 
which for sure is not possible for myfaces!).





I still think, that using the cl api is the best we can do for our users. If 
they then use cl as implementation - and if this is considered good - is 
another story, but nothing WE should anticipate.

As far as I can say the cl api is rock solid, just the class-loader stuff is a 
pain. But (again AFAIK), slf4j does not solve it, it just does not deal with it.



Before we start using any other logging api I'd suggest to build our own thin 
myfaces-logging wrapper where one then can easily plug in log4j, cl, jul (java 
utils ogging) or whatever - we do not even have to provide any other impl than 
for jul.

As a plus, this then will remove a dependency - a dependency to any logging 
framework - which - in terms of dependencies can be considered as a good 
thing, no?



Ciao,

Mario



Von: Gerhard Petracek 
[mailto:gerhard.petra...@gmail.commailto:gerhard.petra...@gmail.com]
Gesendet: Freitag, 05. Juni 2009 17:18
An: MyFaces Development
Betreff: slf4j and myfaces



hello all,

again the logging-framework topic :)
there were several discussions about it and i'm not aware of an agreement.

udo wrote [1]:
replace commons-logging with slf4j

as i know we agreed on using one logging framework dependency for all myfaces 
projects.
if i remember correctly, most of us prefer slf4j.

- i suggest to vote about using slf4j in all myfaces projects.
(at least if a project is using an external logging framework.)

regards,
gerhard

[1] http://www.nabble.com/Re%3A-Trinidad-vs-Tobago-p23884581.html

AW: [vfs] Google App Engine plug-in (GaeVFS)

[Mario Ivankovits]

Hi!

  http://gaevfs.appspot.com/

cool stuff!

 This is kind of cool. My first thought was that it might be nice to  
 include it in VFS itself, but after looking at 
 http://code.google.com/appengine/terms.html 
   I have my doubts that including this at Apache would be doable even  
 as an optional component. However, I see no reason it couldn't be  
 referenced on the web site and added to providers.xml to load if it is  
 present. Unless, of course, someone else has a different opinion.

There is no need to add this to VFS's providers.xml as a vfs plugin is able to 
provides its own vfs-providers.xml [1] which will be loaded by VFS then 
automatically.

Ciao,
Mario

[1] http://commons.apache.org/vfs/api.html

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: [vfs] why is FileSystemConfigBuilder.setParam() protected?

[Mario Ivankovits]

 This is one of my least favorite parts of VFS. To configure  
 FileSystemOptions you have to use the appropriate  
 FileSystemConfigBuilder. I can't tell you why it was done this way as  
 it precedes my involvement, but I've considered reinventing this more  
 than once. It isn't pretty.

The reason I have done it that way was simply to have type-safe configuration 
parameters.
I hate it to have just setParam(String, String) or something like this.

It also was necessary to being able to mix parameters for multiple file-system 
implementations as
1) your url might create a layered filesystem
2) you never know exactly which filesystem implementation is going to be used

So, I still like this approach.

For the setParam(String, String) approach VFS provides the 
DelegatingFileSystemOptionsBuilder which then allows you to use 
setConfigString/setConfigClass which accepts just strings and uses reflection 
to coerce it to the required type. This was created to populate the 
configuration e.g. from an ant script or a properties file.

Ciao,
Mario

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

RE: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in

[Mario Ivankovits]

Hi!

 1. Is the LRUFilesCache safe for production use? GAE/J won't allow using
 the default SoftRefFilesCache because it doesn't allow background threads.
 I 've found a few really old messages saying things like SoftRefFilesCache
 is the only implementation suitable for production use and other file
 cache implementation might cause resouce leaks, etc.

Yes, these messages are still true. Sad to say that, but I realized that too 
late and planned to fix this, which is not that easy.

Using any thing else than the SoftRefFilesChache will introduce memory leaks as 
the file-system object will not be discarded. You have to call close() on the 
filesystem, or even better call close on the DefaultFileSystemManager at all 
and do not use the VFS.getManager() singleton approach.
That will also ensure that each and every resource used by the underlaying 
libraries are closed then too.


Ciao,
Mario

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[vfs] caching (was: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in)

[Mario Ivankovits]

Hi!


 Actually, I commented out the call to filesystemclose in  
 SoftRelFilesCache. While looking at the FileSystem implementation I  
 realized that the way close is implemented is not thread safe and  
 can't be called while the system is running.  I believe the fix for  
 this is non-trivial.

That is strange, there should be no real problem if it is not thread safe as no 
other thread is holding a reference to a fileObject any more.

Anyway, I think (and I had this on my todo to discuss this earlier, but my work 
load is still way too high :-( ) all this needs a major refactoring.

First of all, instead of FileManager.resolveFile() we should introduce 
FileManager.mount(path) FileManager.unmount(FileObject).

mount will always create a new file-system which will be kept only within the 
FileObject.

A file-system then will go away when the last FileObject is out of scope, or 
when one calls FileManager.unmount(FileObject).

All the synchronization stuff might be possible to be removed and leaf to the 
user application. I'd say, 90% of the use-case of VFS do not need 
synchronization as there is no need to reuse the same instance of the 
FileObject between threads. But probably I get this wrong.

Given we keep the FileManager.resolveFile() (which then routes to .mount(path)) 
the side effect would be:

1) VFS.getManager().resolveFile(/tmp) != VFS.getManager().resolveFile(/tmp)
2) VFS.getManager().mount(/tmp) != VFS.getManager().mount(/tmp)

3) FileObject fo = VFS.getManager().mount(/tmp);
fo.resolveFile(a) == fo.resolveFile(a)

4) FileObject fo2 = VFS.getManager().mount(/tmp);
fo2.resolveFile(a) == fo2.resolveFile(a)
fo.resolveFile(a) != fo2.resolveFile(a)


If we could argue that, the internals of VFS might become much easier again, 
and stuff like LRUFilesCache or even NullFilesCache might start to work.
Sure, with a NullFilesCache then even 3 is not true, but this is expected then.


H  If we would like to go that way I might try to spent a night or two 
to implement it. With VFS 2.0 it is THE time to do it, but yes, it might delay 
the release again. This is something which happend with VFS always, probably a 
bad spell - or just me ;-)


Ciao,
Mario


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: [vfs] LRUFilesCache safe for production use? Google App Engine/Java plug-in

[Mario Ivankovits]

Yes, I think so.


-Original Message-
From: Vince Bonfanti [mailto:vbonfa...@gmail.com] 
Sent: Tuesday, May 26, 2009 1:14 PM
To: Commons Developers List
Subject: Re: [vfs] LRUFilesCache safe for production use? Google App 
Engine/Java plug-in

My code will always run within a servlet, so I can close() the filesystem
when the servlet is destroyed. In this case, I should be OK using
LRUFilesCache?

Thanks,

Vince
On Tue, May 26, 2009 at 2:28 AM, Mario Ivankovits ma...@ops.co.at wrote:

 Hi!

  1. Is the LRUFilesCache safe for production use? GAE/J won't allow using
  the default SoftRefFilesCache because it doesn't allow background
 threads.
  I 've found a few really old messages saying things like
 SoftRefFilesCache
  is the only implementation suitable for production use and other file
  cache implementation might cause resouce leaks, etc.

 Yes, these messages are still true. Sad to say that, but I realized that
 too late and planned to fix this, which is not that easy.

 Using any thing else than the SoftRefFilesChache will introduce memory
 leaks as the file-system object will not be discarded. You have to call
 close() on the filesystem, or even better call close on the
 DefaultFileSystemManager at all and do not use the VFS.getManager()
 singleton approach.
 That will also ensure that each and every resource used by the underlaying
 libraries are closed then too.


 Ciao,
 Mario



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: [vfs] Dependency to compress

[Mario Ivankovits]

 before ages VFS included the compress classes with own namespace,
 cause compress wasn't released and VFS had to go ahead. It was planned
 to replace those vfs.compress classes with a dependency to commons
 compress. If this is still the plan, I will create an issue for it and
 would do it straight after my holidays next week :-), if it doesn't
 conflict with the release of the planned version 2.0.

I think, best would be to start in VFS sandbox a _writeable_ zip/whatever impl 
using commons-compress. Once it works, we can drop the old impl and the copied 
classes.

Ciao,
Mario

RE: VFS LocalFile#getLocalFile() protected?

[Mario Ivankovits]

Hi!

Not every FileObject can be represented as a local file, and thus getLocalFile 
ist protected.

What you can do is to replicate the file:

File file = fileObject.getFileSystem().replicateFile(fileObject, 
Selectors.SELECT_SELF);

For the local filesystem this simply exposes the local file object (no real 
replication takes place). For any other file object, e.g. a reference to a file 
within a zip file real replication takes place and the file will be copied to a 
temporary place.

Ciao,
Mario

-Original Message-
From: Ryan McKinley [mailto:ryan...@gmail.com] 
Sent: Friday, May 15, 2009 4:37 AM
To: user@commons.apache.org
Subject: VFS LocalFile#getLocalFile() protected?

Is there any reason LocalFile#getLocalFile() is protected rather then  
public?

Since the process to reconstruct a File object is kinda clunky, it  
would be nice to just have access directly to the file object.

ryan

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

org


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

RE: [VFS] anonymous debug logging

[Mario Ivankovits]

Hi!


 From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
 
 I'm not a big fan of that.

Me too, any decent logging facility should allow to configure the logger on a 
per package level, so no problem to make the logging silent for a given 
package.


 I'd prefer to switch to SLF4J and just replace

Everyone in commons land is using commons-logging, no?
There is no good reason to leave this path. Sure, for my work-projects I use 
slf4j too, lately I even use the Java Logging API (which is worse), but always 
by using a the commons-logging API (not the Impl, just the API)

Everyone wanting to use slf4j can easily do that by using the 
slf4j-commons-logging adapter and removing the commons-logging jar. Not a big 
deal.
There is no benefit in switching to slf4j at all for commons-vfs, or?

 
   if (log.isDebugEnabled())
   {
   log.debug(putFile:  + file.getName());
   }
 
 with
 
   logger.entry(file.getName());


This is not the same, in the second example getName() gets evaluated every 
time, regardless of the configured log-level. Depending on how complicated it 
is to collect the message, this might become a performance problem. the if 
(log.isXXXEnabled()) prevents that.

I'd prefer to keep it the way it is. 

Ciao,
Mario

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: Orchestra Core 1.3.1 Released

[Mario Ivankovits]

YAH ! :-)

 -Original Message-
 From: Simon Kitching [mailto:skitch...@apache.org]
 Sent: Thursday, March 05, 2009 3:44 PM
 To: MyFaces Discussion
 Subject: Orchestra Core 1.3.1 Released
 
 The Apache MyFaces Orchestra team is pleased to announce the release of
 Apache MyFaces Orchestra Core 1.3.1
 
 This is a bugfix release that fixes a small number of issues with
 release 1.3. There is no need to upgrade if you are not experiencing
 any
 of the issues listed in the release notes.
 
 Get a full overview at Orchestra's homepage [1].
 
 The release notes for 1.3.1 can be found here:
 *
 http://svn.apache.org/repos/asf/myfaces/orchestra/tags/core-
 1_3_1/RELEASE-NOTES.txt
 
 The distribution is available at
  * http://myfaces.apache.org/orchestra/download.html
 
 Apache MyFaces Orchestra is available in the central Maven repository
 under Group ID org.apache.myfaces.orchestra.
 
 
 Regards,
 Simon
 
 [1] http://myfaces.apache.org/orchestra

RE: [VOTE] Orchestra 1.3.1 release candidate

[Mario Ivankovits]

+1 Checked it now and looks good!

---
Mario

visit my blog at http://copy-con.blogspot.com/


 -Original Message-
 From: Mario Ivankovits [mailto:ma...@ops.co.at]
 Sent: Tuesday, March 03, 2009 8:12 AM
 To: 'MyFaces Development'
 Subject: RE: [VOTE] Orchestra 1.3.1 release candidate
 
 +0 (I trust you made a high quality package again :-) )
 
  -Original Message-
  From: Simon Kitching [mailto:skitch...@apache.org]
  Sent: Monday, March 02, 2009 9:58 PM
  To: MyFaces Development
  Subject: [VOTE] Orchestra 1.3.1 release candidate
 
  Hi All,
 
  I think it's time to release an update to Orchestra Core; we have
 about
  half-a-dozen minor/medium bugs fixed.
 
  Therefore I have created a release candidate for orchestra-core
 1.3.1.
 
  Please have a look at these artifacts and vote:
 
  [1] http://people.apache.org/builds/myfaces/m2-staging-
  repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3.1
  [2] http://people.apache.org/~skitching/orchestra-core-
 1.3.1/index.html
  [3] https://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-
  1_3_1-prepare/RELEASE-NOTES.txt
 
  Note that the link from the site to the 1.3.1 release notes isn't
 there
  yet - it can't be done until after the vote has passed and the
 release-
  branch has been made a tag :-). But that's just a trivial site
 update..
 
  
  [ ] +1 for community members who have reviewed the bits
  [ ] +0
  [ ] -1 for fatal flaws that should cause these bits not to be
 released,
and why..
  
 
 
 
  Thanks!
 
  Simon
 

RE: [VOTE] Orchestra 1.3.1 release candidate

[Mario Ivankovits]

+0 (I trust you made a high quality package again :-) )

 -Original Message-
 From: Simon Kitching [mailto:skitch...@apache.org]
 Sent: Monday, March 02, 2009 9:58 PM
 To: MyFaces Development
 Subject: [VOTE] Orchestra 1.3.1 release candidate
 
 Hi All,
 
 I think it's time to release an update to Orchestra Core; we have about
 half-a-dozen minor/medium bugs fixed.
 
 Therefore I have created a release candidate for orchestra-core 1.3.1.
 
 Please have a look at these artifacts and vote:
 
 [1] http://people.apache.org/builds/myfaces/m2-staging-
 repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3.1
 [2] http://people.apache.org/~skitching/orchestra-core-1.3.1/index.html
 [3] https://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-
 1_3_1-prepare/RELEASE-NOTES.txt
 
 Note that the link from the site to the 1.3.1 release notes isn't there
 yet - it can't be done until after the vote has passed and the release-
 branch has been made a tag :-). But that's just a trivial site update..
 
 
 [ ] +1 for community members who have reviewed the bits
 [ ] +0
 [ ] -1 for fatal flaws that should cause these bits not to be released,
   and why..
 
 
 
 
 Thanks!
 
 Simon
 

RE: [VFS]HttpConnectionManager

[Mario Ivankovits]

Hi!


 -Original Message-
 From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
 Sent: Monday, February 23, 2009 8:29 AM
 
 Thanks Mario.  VFS-164 wasn't really clear. Was the problem the limit
 to 2 connections per host that MultiThreadedHttpConnectionManager has
 by default?

Sorry, I can't remember :-( Yes, I think it hang, and I am not sure if the 
maxConnectionsPerHost existed at this time, or probably I just overlooked it 
*grmpf*.

 I've added maxConnectionsPerHost and
 maxTotalConnections to HttpFileSystemConfigBuilder and also allowed
 them to be specified as system properties.

You would make a lot of people happy (I think) if you implement this in a 
commons way, so that every FileSystemOption can also be specified using system 
properties. Or did you already? :-)

Something like -Dvfsopt.ftp.passiveMode=true

You can use the DelegatingFileSystemOptionsBuilder to help you here.

FileSystemOptions fso = new FileSystemOptions();
DelegatingFileSystemOptionsBuilder delegate = new 
DelegatingFileSystemOptionsBuilder(VFS.getManager());
delegate.setConfigString(fso, sftp, identities, c:/tmp/test.ident);
delegate.setConfigString(fso, http, proxyPort, 8080);
delegate.setConfigClass(fso, sftp, userinfo, TrustEveryoneUserInfo.class);

by iterating over the System properties, taking each vfsopt.* and split it so 
taht you can pass it to setConfigString.

This can do the trick.

Ciao,
Mario

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: [VFS]HttpConnectionManager

[Mario Ivankovits]

Hi!
 -Original Message-
 From: Ralph Goers [mailto:ralph.go...@dslextreme.com]
 Sent: Monday, February 23, 2009 7:28 AM
 
 What I'd like to know is, was there more to VFS-164 than is stated in
 the issue and is this change sufficient? Or do I need to create yet
 another HttpConnectionManager?

No, it was just VFS-164 and if you found another solution to that which allows 
multiple files now it is good! :-)

Ciao,
Mario

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[jira] Commented: (VFS-203) FileObject..getName().getURI() returns URIs with spaces

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675791#action_12675791
 ] 

Mario Ivankovits commented on VFS-203:
--

Hmmm  normally escaping these special charachters should do the trick, e.g. 
%20 instead of space.

It might not look nice, but this is how URIs work (IMHO)

 FileObject..getName().getURI() returns URIs with spaces
 ---

 Key: VFS-203
 URL: https://issues.apache.org/jira/browse/VFS-203
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 1.0
Reporter: Tim Lebedkov

 Windows supports file names with spaces and '#'. AFAIK spaces are not allowed 
 in URIs and # will be interpreted as an URI fragment.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: Problem Using Orchestra with Realm after Session-Timeout

[Mario Ivankovits]

Hi!
 -Original Message-
 From: Filip Lyncker [mailto:lync...@lyth.de]
 Sent: Thursday, February 12, 2009 11:29 AM

Yep, here it is:
 javax.faces.application.ViewExpiredException:
 viewId:/pages/start/actuell.jsf - View /pages/start/actuell.jsf could
 not be restored.


 if (is11CompatEnabled(facesContext)) { // the faces

What you can do ist to figure out how to enable the JSF 1.1 compat mode, which 
then will simply rerender the page.
Or you try/catch the ViewExpired exception in an filter (probably) and forward 
to your login/menu/whatever page.

The first suggestion might restore the page in an invalid state as all the 
beans are gone, so I'd opt for the second suggestion (try/catch).
Unhappily I've never done this myself (... I should have ...). I'd start with a 
servlet filter .. or a PhaseListener.

Anyone else with a better solution?

Yes, a third one: If you are using richfaces you can use the a4j:poll component 
on each page which polls the server, lets say, once every minute. This will 
prevent the session from timeout as long as the browser points to your 
application. This also allows you to configure a very short session timeout (5 
minutes) as nothing bad happens as long as the browser is open. This is very 
much like a RichClient behaviour.
BTW: This is the solution we use in our application.

Ciao,
Mario

RE: orchestra/datatable/datascroller LazyInitializationException

[Mario Ivankovits]

Hi!
 -Original Message-
 From: Carl Howarth [mailto:carl.howa...@dlapiper.com]
 Sent: Wednesday, February 11, 2009 11:56 AM

   bean name=searchParametersBean
 class=com.xxx.SearchParametersBean
 scope=conversation.access
 property name=serviceBean ref=serviceBean /
 property name=searchResultsBean ref=searchResultsBean /
   /bean
 
   bean name=searchResultsBean class=com.xxx.SearchResultsBean
 scope=conversation.access/
 
 Before orchestra, all collections were EAGERly fetched and the results
 set
 was kept alive in the search results bean using a t:saveState / tag.

Do you still use t:saveState too? Just in case, this should not be required .. 
nor used as then the entity is detached.
Also, when passing back the result, just pass back the primary key and reload 
the entity from the result bean. An entity from another conversation is 
detached once the conversation is invalidated/not accessed anymore, thus reload 
the entity in the target conversation to have it associated with the right 
EntityManager/PersistenceContext.

Ciao,
Mario

RE: Problem Using Orchestra with Realm after Session-Timeout

[Mario Ivankovits]

Hi!

 What normally happens then is that the JSF implementation will just log
 an unable to restore view message to its logfile, and simply *render*
 the specified page rather than doing a postback, just as if the user
 had done a GET request for the url rather than a POST request.

Unhappily JSF 1.2 will throw an ViewExpiredException or so  very annoying!
Well, not too annoying, but you should take care of that in some way to prevent 
propagating this to the user ... what we do ATM btw :-)

 Getting the source jarfile for MyFaces JSF is easy; we publish it in
 the Maven repository along with the binary jarfiles. I don't know where
 to find the source for Mojarra releases...

https://javaserverfaces.dev.java.net/download.html

Ciao,
Mario

RE: Scanning for annotated classes in MyFaces 2

[Mario Ivankovits]

Hi!

 -Original Message-
 From: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com]
 Mario, I've been looking at the Shale code that handles the annotation
 scanning, but I saw it uses Reflection and standard Java ClassLoaders
 for scanning the classpath for JSF artifacts. What's your experience
 with the performance of this? Does Shale heavily rely on specifying a
 base package to be efficient?

Hmmm, it is a long time back we used it  at least during development times 
it was very annoying not having specified the packages. If I remember 
correctly, with defining it, scanning-time drop down from something aroung 30 
seconds to under 1 second.

Wouldn't it be sufficient to do it that way for a first version of MyFaces 2.0?
Do you think Mojarra will come up with a more sophisticated solution which 
bypasses the standard reflection stuff and uses something like Javasisst? I 
doubt.

Ciao,
Mario