0swald

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 49 total)
  • Author
    Posts
  • in reply to: Rewrite performance plans #26375

    0swald
    Participant

    Ooops, my bad, integration projects are performing perfectly, it was actually Mojarra that had been producing such HUGE delays.
    And whoever read this, I tell you what, NEVER EVER use Mojarra in its current level of technical and organisational maturity if you’re able and in position to switch onto Apache MyFaces!! Especially with ajaxified projects. I did the switch yesterday and now I have FIVE (!!) times increase in performance along with much lower memory and CPU footprints. It’s amazing.

    in reply to: Rewrite & Weblogic, useful info and bugfix #25837

    0swald
    Participant

    Hi Lincoln!
    Sure, I’ll reformat styling (braces), add more comments and send the pull request. You’ll see that the code is 100% the same when it comes to class handling, but with a different package recursion algorithm.

    We dont have a commercial WL CI either, we were just considering to migrate from buggy GF, so the Rewrie was tested as a part of migration tests against the evaluation version of WL – http://www.oracle.com/technetwork/middleware/weblogic/downloads/index.html And yes, there will no problem for me to test the Rewrite against it as many times as needed, I’m mostly worried about other server platforms – Tomcat, JBoss, etc which I’m not familiar with. Hope tests will be ok.

    Regards,
    Osw.

    in reply to: Rewrite & Weblogic, useful info and bugfix #25832

    0swald
    Participant

    No quite. Rewrite wont work at all if SCAN_LIB_DIRECTORY isn’t set to true, but, in addition to SCAN_LIB_DIRECTORY = true, the bug should be fixed, WebClassesFinder dies with an IllegalStateException when /WEB-INF/classes/ is empty.

    Now what WL does. It takes all the client classes, leaving /WEB-INF/classes/ completely empty, and packages them into the /WEB-INF/lib/_wl_cls_gen.jar, to be exact.
    Google says many frameworks are suffering from such behavior, but this is not the case with Rewrite – just make WebClassesFinder skip empty classes folder, let users know that SCAN_LIB_DIRECTORY should be activated for WL, and we’re all happy))

    in reply to: Rewrite & Weblogic, useful info and bugfix #25830

    0swald
    Participant

    Hi Christian,

    I’m afraid I wont be able to explain what I’ve changed)) I spent several hours understanding the code in vain, and finally decided to rewrite the recursion from scratch. I think there is a bug in calculating relative path, most probably because it’s always been doing with respect to /WEB-IN/classes/ folder. I just reproduced the recursion and left comments on code variables and their resulting values. As I said, it works correctly for both WL and GF, but definitely requires more thorough testing, involving other server platforms. I’d appreciate it very much if you (we) could solve this issue. Either by testing and implementing my source code or, and this’d be pure WL bugfix, by using your code with a simple preliminary check on /WEB-IN/classes/ right in the public void findClasses(ClassVisitor visitor) – empty or not, if empty then exit w/o recursion.

    Regards,
    Osw.

    in reply to: security related isuue #25197

    0swald
    Participant

    Christian thanks!
    But I cant find snapshots page, have you moved it somewhere?

    in reply to: security related isuue #25190

    0swald
    Participant

    Hi Christian,

    It’s not only that we’re addicted, but we’re also very dependent on the Rewrite now. The behavior you’ve described sounds logical, I totally agree, but at this very moment I’m mostly concerned about RuntimeException being caught where it shouldn’t be. Sorry, it’s critical because it interferes with a significant and security-related part of the Java EE architecture, I vote for an immediate patch so one could use latest official snapshots instead of using own patched versions of Rewrite as we started doing as of yesterday. Hope you understand me.

    Regards,
    /Osw

    in reply to: security related isuue #25188

    0swald
    Participant

    Looking forward to you both to decide upon the subject, I’d appreciate any, even temporary solution as we’re now seriously addicted to the Rewrite))
    I could issue a patch if you agree to the re-throwing runtime exceptions as a workaround.

    in reply to: security related isuue #25186

    0swald
    Participant

    Lincoln, there is another option, I just had a look at the RewriteException and, in case you prefer to throw namely this particular one, here is it:

    
        for (ExpressionLanguageProvider provider : getProviders()) {
          try {
            return providerCallable.call(event, context, provider);
          } catch (RuntimeException e) {
            throw new RewriteException(e.getMessage(), e);
          } catch (Exception e) {
            exceptions.add(e);
          }
        }
    

    The above would also make it possible to unwrap the source exception for proper error handling.

    in reply to: security related isuue #25185

    0swald
    Participant

    Hi Lincoln,

    Actually it wasn’t my EL, here I’m using the stock one from rewrite-servlet-2.0.6-SNAPSHOT, I’ve removed all of my custom libraries while examining the issue. Actually there’s no need in further study – catching ALL exceptions is generally wrong idea in EE environment, Servlet request isn’t only about pages, it also creates and holds a security context which is propagated along with each and every call to underlying components of an EE server. If a proxy of an EJB finds the security context insufficient for execution, it throws a subclass of an EJBAccessException, which is the subclass of RuntimeException and which finally breaks the execution of a filter/servlet. You could handle such situations via web.xml (error-page) or via exception-handler-factory in JSF, but not when these exceptions are swallowed by the Rewrite.

    I see only two options here:
    1) don’t catch any exceptions at all, let it be the responsibility of an ExpressionLanguageProvider.
    2) don’t catch any runtime exceptions (as I did above), this seems more natural to me, because the RewriteException thrown is also a runtime one. Thus, unless you have a very very special exception handling somewhere deep in your code (which it seems you don’t), there is nothing you lose in this case.

    What do you think?

    Regards,
    Andrew


    0swald
    Participant

    Hi Christian,
    yes, I do understand how difficult it was create annotations for all cases, especially in such a zoo of JSF and CDI beans, I was thinking of it too, and here is my proposal:

    1. The Rewrite engine checks the bean annotation (CDI or JSF)
    2. If it’s JSF then the engine automatically creates all the actions and bindings as deferred after the RESTORE_VIEW phase.
    3. If the user wants to fine-tune the phase, then he uses a stand-alone @Phase(before=, after=) annotation or something like that.

    As for class inheritance, the only thing you could do is to get rid of the action and parameter annotation handlers and start examining the bean class via reflection as I did in my AbstractClassHandler<A extends Annotation>. This approach isn’t flawless – when examining the class you should already know all the method- or field-level annotations you might encounter in the class. And even worse – all other non-class-level enriching annotation handlers become to no use.

    PS: and yes, I do actively use view-scoped beans when it comes to ajaxfied page, there’s no CDI equivalent for such cases.

    • This reply was modified 6 years, 3 months ago by  0swald.

    0swald
    Participant

    Lincoln, sorry for late response, was busy to death.

    1. Actually I’m not the right person to give an advice on how to reshuffle modules or their dependencies cause my interests lie solely with JSF and I have very little knowledge of Spring or whatever else frameworks your project is targeting. But yes, that’d be great if users could have a one-stop Faces Rewrite library, and I see no cons why it shouldn’t look like the old good PrettyFaces, which still remains unbeaten even after the release of rewrite-integration-faces, imho.

    2. I don’t have much knowledge on what current rewrite-config-prettyfaces if capable of, haven’t tested it, but if my lib covers the necessary functionality, then yes, sources are free for reuse. I cant promise much of my time, though I’d be proud to contribute and look after/be responsible for some pieces of the Rewrite project. Then you take the lead, I’ll need some guidance on how to start.


    0swald
    Participant

    Hi Lincoln,
    Finding annotation API was a piece of cake, just Alt+F7 (find usages) on @Join in Netbeans plus spi packages which gave me the hint)) Using SPI was excellent idea btw.

    As for rewrite-config-prettyfaces, I was just afraid that was just a compatibility layer with less support and no further development. Now, when I have all the sources, I understand that I might have been wrong. But, being wrong, I still don’t understand why would you need to develop both the rewrite-config-prettyfaces and rewrite-integration-faces and why would you create new faces-specific annotations like @Deferred or @IgnorePostback when you already have Prettyfaces at hand? Maybe I’m still lacking the overall picture of the project and don’t get where is it going with regard to faces support.

    Regarding why I don’t like the design of rewrite-intergation-faces – mostly because it does not support class inheritance and does not allow multiple @Join annotations, it’s one of the major design flaws, not a MVC style at least. Plus the necessity of mixing annotations from both rewrite-servlet and rewrite-integration-faces, with one of them (@Deferred) being always necessary when developing JSF – a bit clumsy approach imho.

    in reply to: Multiple @Join annotation at the same MBean? #24518

    0swald
    Participant

    Hi,

    No, multiple @Join annotations are not possible, I had the same question and Christian has offered some workarounds for such situations (see this thread http://ocpsoft.org/support/topic/what-happened-to-prettyfaces/), but all in all the lack of such possibility, critical in my case, has forced me to create my own extension on the top of rewrite-servlet and rewrite-integration-faces which allows multiple @Join annotations per bean. Rewrite uses SPI, which allows pluggable annotation processing, so it’s easy, you could have a look at how I did it on https://github.com/0swald/rewrite-integration-faces-easypack .

    As for multiple @RequestAction, afaik they’re possible (one per method) and appended one by one to the Rule’s execution queue.


    0swald
    Participant

    Lincoln, finally I’ve published my library, here it is: https://github.com/0swald/rewrite-integration-faces-easypack , feel free to reuse the code if you and your team find it interesting. I did my best commenting the sources and learning git))


    0swald
    Participant

    Lincoln, these aren’t actually ‘changes’, this is a library built on top of rewrite and rewrite-integration-faces – actually a more JSF-friendly substitution for the latter, a dozen of classes (annotations, handlers and utility ones) making the Rewrite more convenient for JSF projects, that’s all, very much like the old prettyfaces 3.x. I did it because I totally disagree with the design, core functionality, tools and means provided by rewrite-integration-faces, no offense))

    And yes, sure, I will publish my sources so you could have a look at them, probably in a day or two.
    PS: what about my pull requests? I’m new to github and could miss something out when submitting patches.

Viewing 15 posts - 1 through 15 (of 49 total)