Protected vs Private in Bean

I am using a bean and when I use declare a variable as private such as:
private m_firstName = "";
public String getFirstName() {
return m_firstName;
I have this in my JSP
value="<%= customer.getFirstName() %>"
I get a NullPointerException.
But if I only change the bean to:
protected m_firstName = "";
I have my JSP page fine. The underlying HTML codes says:
value=""
So, I wonder why using protected and private matters?
THanks,
Martin

I have tested your code,but no problem.
List below is my write code:
////test01.java
public class test01
     private String lsh= "a";
     public String getLsh()
          return lsh;
////test01.jsp
<jsp:useBean id="test01" scope="page" class="test01" />
<%=test01.getLsh()%>
And the response is "a",not null.It's OK.

Similar Messages

  • There is a program unfortunately just called "Cookie" (so I can't be successful doing a search here) that is supposed to help protect our private information that resides on our computers.  Has anyone used this and is it worth buying?

    Unfortunately this discussion forum has changed and become confusing indeed.  It wanted me to put my entire question in a Subject box which wasn't labeled as such, and I find this strange.  Especially since now it tells me to repeat my question in this box, so here goes.
    Has anyone here used a program called 'Cookie' that is supposed to protect our private information from sites which could retrieve it when we surf the Net.  If so, do you consider the program worth buying?

    If you are referring to Cookie from SweetP Productions, I have tried it and not found it to work reliably, so I cannot recommend it. I've had the best results with the same company's free Safari Cookies, though it's not perfect (none of the cookie managers are, unfortunately):
    http://www.macupdate.com/app/mac/31018/safari-cookies
    Regards.

  • [svn:fx-3.x] 7499: Addendum to fix for BLZ-233 - adjust visibility of new internal heartbeat util methods to protected from private .

    Revision: 7499
    Author:   [email protected]
    Date:     2009-06-02 16:10:08 -0700 (Tue, 02 Jun 2009)
    Log Message:
    Addendum to fix for BLZ-233 - adjust visibility of new internal heartbeat util methods to protected from private.
    QA: No
    Doc: No
    Checkintests Pass: Yes
    Ticket Links:
        http://bugs.adobe.com/jira/browse/BLZ-233
    Modified Paths:
        flex/sdk/branches/3.x/frameworks/projects/rpc/src/mx/messaging/ChannelSet.as

    inspired2apathy wrote:
    ... The goal is a ScrollPane that automatically wraps the text inside it. I've just about got it, but I have one thing that's not working. If I just put the JTextArea{s} in as the Editor, then you lose the any text that doesn't fit inside whatever the initial size was. Instead, I put the JTextAreas inside a JScrollPane which works fine, except that I still have to determine the size of the JScrollPane in advance. I would like to make each Editor/JScrollPane start out with just a single line of text and expand until it reaches a certain small number of lines.
    ... What am I missing?THE BASICS. See if this isn't what you are trying to do.
    import javax.swing.JFrame;
    import javax.swing.JScrollPane;
    import javax.swing.JTextArea;
    public class Test
      public static void main(String[] args) {
        JTextArea ta = new JTextArea();
        ta.setLineWrap(true);
        ta.setWrapStyleWord(true);
        JScrollPane sp = new JScrollPane(ta);
        JFrame f = new JFrame();
        f.getContentPane().add(sp, "Center");
        f.setBounds(0, 0, 400, 300);
        f.setDefaultCloseOperation(f.EXIT_ON_CLOSE);
        f.setVisible(true); 
    }OP, your code was too long and complicated for me to compile and run. However, aren't you forgetting the two simple methods <tt>JTextArea.setLineWrap()</tt> and <tt>JTextArea.setWrapStyleWord()</tt>? Furthermore, I absolutely see no need for you to extend SWING components for demonstration this simple -- that is, if I understand your problem correctly.

  • Method "LOCK" is unknown or PROTECTED or PRIVATE for Value Node

    Hi Experts,
    Please help me to resolve this issue.
    I am unable to lock the entity for Value Node and I doing this because I want to edit my custom view of the assignment Block.
    Actually, I have created a custom view for custom BOL in BP_HEAD Component, Later I have added this view to the AccountDetailsViewSet of the BP_HEAD and Now I have added the Edit Button to my custom View in DO_PREPARE_OUTPUT Method of the view controller.
    And now when I about to write the code it says there is no lock method available for Value Node and also I am unable to edit the view
    Syntax Error: Method "LOCK" is unknown or PROTECTED or PRIVATE.
    DATA: lr_entity     TYPE REF TO CL_BSP_WD_VALUE_NODE.
          lr_entity ?= me->typed_context->Root->collection_wrapper->get_current( ).
          IF lr_entity->lock( ) EQ abap_true.  " I am receiving syntax error here.
            me->view_group_context->set_view_editable( me ).
          ENDIF.
    Thanks,
    Bujji

    Hi Bujji
    It is not possible to use lock on value node entity. If you want to set your view to editable, you can use the logic as seen in the method 'ASSIGN_EDITMODE_2_VIEWS' of the account view set impl class in standard.
    Hope this helps.
    Regards,
    Nisha

  • Accessing protected and private data of a class

    Hi friends,
    I have writen a sample code in oops abap but iam facing some problem.
    CLASS MAIN DEFINITION.
        public SECTION.
          DATA : VAR1(10) TYPE C VALUE 'NEW VALUE'.
          METHODS : PUBLIC.
      ENDCLASS.
      CLASS MAIN IMPLEMENTATION.
         METHOD : PUBLIC.
           WRITE : /5 VAR1.
              VAR1 = 'CHANGED'.
           WRITE : /5 VAR1.
         ENDMETHOD.
      ENDCLASS.
    START-OF-SELECTION.
        DATA :
               O_MAIN TYPE REF TO MAIN.
               CREATE OBJECT O_MAIN.
               CALL METHOD O_MAIN->PUBLIC.
    now its working fine as public methods can be access by all the people where as protected methods can be access by class and subclass so i can inherit the properties of above class and access the protected data.
    where as to access private data , private data can be access by class itself...
    so now how do i access the private data within the class...ie : how do i get the above output when i use a private section instead of public..
                CLASS MAIN DEFINITION.
        private SECTION.
          DATA : VAR1(10) TYPE C VALUE 'NEW VALUE'.
          METHODS : Private.
      ENDCLASS.
      CLASS MAIN IMPLEMENTATION.
         METHOD : Private.
           WRITE : /5 VAR1.
              VAR1 = 'CHANGED'.
           WRITE : /5 VAR1.
         ENDMETHOD.
      ENDCLASS.
    START-OF-SELECTION.
        DATA :
               O_MAIN TYPE REF TO MAIN.
               CREATE OBJECT O_MAIN.
               CALL METHOD O_MAIN->Private.
    iam getting a error saying you cannot access the private section...
    now private section can be accessed within the class but nt by others...
    to access the private section within the class how should i correct it...
    Regards
    kumar

    HAI,
    Private attributes or methods can be accessed directly by the Object but within the Scope of the Class, but not outside.
    Look at this:
    CLASS MAIN DEFINITION.
    public  SECTION.
    METHODS : Public.
    private SECTION.
    DATA : VAR1(10) TYPE C VALUE 'NEW VALUE'.
    METHODS : Private.
    ENDCLASS. " END of CLASS DEFINITION
    CLASS MAIN IMPLEMENTATION.
    METHOD : Public.
    CALL METHOD Private.
    ENDMETHOD.
    METHOD : Private.
    WRITE : /5 VAR1.
    VAR1 = 'CHANGED'.
    WRITE : /5 VAR1.
    ENDMETHOD.
    ENDCLASS. " END of CLASS IMPLEMENTATION
    START-OF-SELECTION.
    DATA:  O_MAIN TYPE REF TO MAIN.
    CREATE OBJECT O_MAIN.
    CALL METHOD O_MAIN->Public.
    PS: If there is any better alternative solution please share it .
    Best Regards,
    rama

  • Can java have Protected or Private Constructor

    Hi,
    can java have Priavte or protected constructor,
    as we know java have default and public constructor ,
    and in using singleton design patters we can use private & protected constructor,
    so, what is the main logic,
    Regards,
    Prabhat

    Hi,
    Yes, We can declare constructor as private/public/protected also.
    Having only private constructors means that you can't instantiate the class from outside the class (although instances could still be created from within the class - more about this later). However, when you instantiate a class, you must first initialize all superclasses of that class by invoking their constructors. If one of the superclasses has only private constructors declared, we have a problem. We can't invoke the superclass' constructor which means that we can't instantiate our object. Because of this, we've essentially made a class that can't be extended.
    example:
    class TheWorld
    private static TheWorld _instance = null;
    private TheWorld() {}
    public static TheWorld instance()
    if ( _instance == null )
    _instance = new TheWorld();
    return _instance;
    public void spin() {...}
    public class WorldUser
    public static void main(String[] args)
    TheWorld.instance().spin();
    }

  • Protected and Private...

    I have been coding in Java for the past couple years. However, I am still unclear to exactly what the difference is between private and protected variables/methods. So far, they look to be identical.
    If anyone is able to explain to me, exactly what the difference is (instantiation, inheritance, etc.), it would be greatly appreciated.
    Thanks,

    I have been coding in Java for the past couple years.
    However, I am still unclear to exactly what the
    e difference is between private and protected
    variables/methods. So far, they look to be
    identical.No offense intended, but I find this to be somewhat alarming. Two years coding Java is a bit long to go without understanding access modifiers. You should set aside some time to go back and review the basics. Here are some recommended resources:
    The Java� Tutorial - A practical guide for programmers
    The Java� Tutorial - Trail: Learning the Java Language
    New to Java Center
    Java Programming Notes - Fred Swartz
    How To Think Like A Computer Scientist
    Introduction to Computer Science using Java
    The Java Developers Almanac 1.4
    Object-Oriented Programming Concepts
    Object-oriented language basics
    Don't Fear the OOP
    Books:
    The Java Programming Language - 4th Edition
    Head First Java, by Bert Bates and Kathy Sierra
    Thinking in Java (Free online), by Bruce Eckel
    Core Java, by Cay Horstmann and Gary Cornell
    Effective Java, by Joshua Bloch

  • Protected vs Private w/ accessor methods

    What is the difference, is there one? Or is it just preference.
    Thank You

    He was pointing out a mistake in your first post. The point of an accessor is to allow access to a private member variable. However, if the accessor method is private just like the field it is supposedly providing access to, then there really is no point!

  • Private vs. protected, naming conventions etc.

    I've been grappling with a couple of frustrations with Forte, and I'm
    interested in feedback from others on this list regarding approaches
    they may have adopted to address these.
    One is that in the Forte workshops there is no way to view only the
    public methods and attributes of a class (we're still using V2 here; I'm
    assuming that V3 has not changed this). While referring to appropriate
    technical documentation for a class is obviously important, I still find
    myself opening up classes in the workshops to inspect the methods and
    attributes available. (What I really want to see is an integrated class
    browser. I sure hope Forte is working on something like this, or will
    open up their development environment to support third-party extensions.
    But that's an aside.)
    A convention I just recently adopted in my work is to name private
    methods and attributes with a beginning underscore ("_"). That way the
    private elements are sorted to the top of the list and can be easily
    differentiated from public elements. I'm curious, though, whether others
    have adopted similar or different approaches.
    I've also felt a bit frustrated over the lack of support for protected
    attributes/methods for TOOL classes. This strikes me as a rather
    bothersome shortcoming. The only approach I can think of is to make such
    elements public, but adopt the same or similar naming conventions as a
    strong hint to developers to avoid using these in clients of these
    classes. Again, I'd be very interested in hearing how others have dealt
    with this issue.
    Thanks.
    Michael Brennan
    Programmer/Analyst
    Amgen Inc.

    I sent this once before, but the list seemed to be having trouble late last
    week. If you get two copies of it... my apologies.
    OK, I couldn't resist joining the fray...
    At 10:56 AM 11/6/97 -0800, Michael Brennan wrote:
    >
    A convention I just recently adopted in my work is to name private
    methods and attributes with a beginning underscore ("_"). That way the
    private elements are sorted to the top of the list and can be easily
    differentiated from public elements. I'm curious, though, whether others
    have adopted similar or different approaches.You might even designate a single character before the underscore to denote
    that, just in case some environment (CORBA) doesn't like the "_". You could
    make it something like "Q" or "Z" or something that wouldn't normally be
    used alone at the start of a name.
    >
    I've also felt a bit frustrated over the lack of support for protected
    attributes/methods for TOOL classes. This strikes me as a rather
    bothersome shortcoming. The only approach I can think of is to make such
    elements public, but adopt the same or similar naming conventions as a
    strong hint to developers to avoid using these in clients of these
    classes. I share your desire for protected methods, but I have to disagree about
    protected attributes. Philosophically speaking, protected and public
    attributes are EVIL!! (I say "philosophically speaking" because, in the
    Forte environment, there are some valid reasons for using them based upon
    the visibility constraints of the language. In other languages, C++ and
    Java, for example, it's not even philosophically speaking - they're just
    evil!!)
    One of the principal reasons for adopting the object paradigm is to
    tightly control the impact of change - to provide good boundaries of
    encapsulation that change does not ripple beyond. If you think about it,
    one of the measures of the success of a superclass is the number of
    subclasses that it has (especially for a good dabstract interface). This
    says you have very nicely captured the semantics of the application domain
    in the interface of the superclass. So, let's imagine a superclass with
    protected attributes that are used by each of its 100 subclasses (probably
    more than you would have, but I'm illustrating my point - incidentally, I'm
    not talking about a hierarchy 100 deep; I'm talking about 100 subclasses
    that are all direct decendants of the superclass). Now you go and change
    one of the attributes. You must go look at all 100 subclasses to determine
    the impact of change. This is exactly the kind of thing the object paradigm
    was designed to eliminate.
    Protected methods, on the other hand, would be nice.
    And At 12:06 PM 11/6/97 -0800, Mark S. Potts wrote:
    >
    Forte inherits in a strange way when attributes are private. A
    superclass attribute that is made private is not accessible from any of
    its subclasses - this means that many of what you would consider private
    attributes in fact have to be public. Well, the definition of private means "not visible outside of the class
    where it is defined". I find it useful to think of the level of visibility
    the same as secrets. There are things that are not really secrets at all -
    it's ok if anyone knows them ("My name is Stephen"). These are public.
    Then, there are things that it's ok if my family knows, but I don't want
    the world to know - familial secrets, if you will ("I belch at the dinner
    table when I'm at home"). These are visible to descendant classes and we
    call them protected. Finally, there are things we don't want anyone else
    to know, no matter who they are ("I poisoned my mother-in-law"). These are
    private. We don't want anyone outside of ourselves to know these things.
    These are the classic definitions of public, protected and private (perhaps
    classic only because C++ defined them that way and everyone else just
    copied what it meant).
    Private attributes are not meant to be inherited by their subclasses.
    That's why they're private. And, yes, I would argue that that is completely
    correct. What you want, if you want them to be visible to subclasses, is
    "protected". Now, Forte doesn't support protected, but that's a different
    arguement - perhaps even an enhancement request.
    We also should not confuse what we need to do in a language/environment
    with what good OO principles are. For example, good OO design principles
    state that you do not have public or protected attributes. Period! You
    access them via accessors and mutators defined on the appropriate class.
    Now, in some environments, this will not give you the performance you need,
    so you open things up a bit. But, you shouldn't convince yourself that
    doing this is the ideal design, just that it was necessary for performance.
    The real problem here is that the performance of accessor and mutator
    functions is not fast enough. That's why we open it up. Not because it is
    good design. The proper way to fix the problem is to make accessors and
    mutators fast enough so that they can be used (C++, for example, does this
    with "inline" - not that C++ is my favorite language, it's not. But they
    have fixed this one area nicely.)
    Some would argue that this is correct and that inheritance does break thepure rules
    of encapsulation I don't think inheritance, properly handled (and Forte does properly
    handle it) breaks any rules of encapsulation. I would argure that the way
    they treat private attributes is quite correct.
    - but these people dont build applications!Hmmm... let's see... started building OO applications in 1985 (and building
    them ever since) in complex application domains like CAD/CAM/CAE, Air
    Traffic Control, Graphics/Imaging, Telecommunications, e-commerce,
    entertainment,... ...wrote (and teach) the Forte OO Analysis and Design
    course.
    I guess you're right. I don't build applications. I build robust,
    maintainable, extendable applications. ( ;-) ...nudge, nudge!)
    Stephen

  • Adobe Developers' overuse of 'private' instead of 'protected'

    I fear this will fall on deaf ears, but it has been a hurdle so many times that I'm compelled to attempt to make a difference by posting this message.
    Dear Adobe,
         Would you please find a way to instruct your developers that, although they've been taught in the ivory towers that anything not 'public' should be 'private', this is, in fact, nearly universally the wrong instruction.  When a developer finds a need to extend or subclass your class to make minor (or major) modifications, they will almost undoubtedly need access to some or many of the attributes which you've incorrectly assigned the label 'private' to.  Think 'protected'!   By default, anything not 'public' should be 'protected', not 'private'.  Marking all these attributes 'private' takes otherwise useful code and makes it useless so far as the object oriented design and inheritance is concerned.  'protected' is still inaccessible to *everything using the object*, with the single exception of an inherited class!  If someone is extending your class, these will still be nonpublic to everything else.  I am generally not arrogant enough to suppose that I can foresee all future uses and extensions to a class I am writing, which is a prerequisite to branding an attribute 'private'.  Unless there is an extremely good reason an attribute should be 'private', by default please make it 'protected' because you cannot foresee all the future use cases for your class that are killed with 'private'.
    Please?

    This has been discussed many times.  Anything public or protected has to be
    documented and then deprecated if we change our minds.  Lots of stuff
    therefore ends up being private so we can change our minds about it more
    quickly.  I wish we knew enough to make every method and property public or
    protected, but we don't.

  • Applying Private & Protected methods inside JSP

    I am trying to apply (or copy) codings from Servlet into JSP.
    One of the issue that I encountered was bringing Private and Protected methods that were listed inside the Servlet class (this case: public abstract class CatalogPage).
    If I only copy everything inside "Public void doGet", JSP would not work.
    1) My question is, is it better approach to apply Private and Protected method beside wrapping around with ( <%! %> (with !)) (like below)?
    I think I heard about using " ! " for private methods somewhere in the internet..
    Here is what I have at JSP.
    <%!
    Private CatalogItem[] items;
    Private String[] itemIDs;
    private String title;
    protected void setItems(String[] itemIDs) {
    protected void setTitle(String title) {
    %>
    <%
    if (items == null) {
    response.sendError(response.SC_NOT_FOUND,
    "Missing Items.");
    return;
    %>
    2) Is there any other ways I could make the functionality of Private and Protected methods
    work inside the JSP's <% %>?
    Thank you.
    Here is the original Servlet code.
    public abstract class CatalogPage extends HttpServlet {
      private CatalogItem[] items;
      private String[] itemIDs;
      private String title;
      protected void setItems(String[] itemIDs) {
        this.itemIDs = itemIDs;
        items = new CatalogItem[itemIDs.length];
        for(int i=0; i<items.length; i++) {
          items[i] = Catalog.getItem(itemIDs);
    protected void setTitle(String title) {
    this.title = title;
    public void doGet(HttpServletRequest request,
    HttpServletResponse response)
    throws ServletException, IOException {
    if (items == null) {
    response.sendError(response.SC_NOT_FOUND,
    "Missing Items.");
    return;
    response.setContentType("text/html");
    PrintWriter out = response.getWriter();
    String docType =
    "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0 " +
    "Transitional//EN\">\n";
    out.println(docType +
    "<HTML>\n" +
    "<HEAD><TITLE>" + title + "</TITLE></HEAD>\n" +
    "<BODY BGCOLOR=\"#FDF5E6\">\n" +
    "<H1 ALIGN=\"CENTER\">" + title + "</H1>");
    CatalogItem item;
    for(int i=0; i<items.length; i++) {
    out.println("<HR>");
    item = items[i];
    // Show error message if subclass lists item ID
    // that's not in the catalog.
    if (item == null) {
    out.println("<FONT COLOR=\"RED\">" +
    "Unknown item ID " + itemIDs[i] +
    "</FONT>");
    } else {
    out.println();
    String formURL =
    "/servlet/coreservlets.OrderPage";
    // Pass URLs that reference own site through encodeURL.
    formURL = response.encodeURL(formURL);
    out.println
    ("<FORM ACTION=\"" + formURL + "\">\n" +
    "<INPUT TYPE=\"HIDDEN\" NAME=\"itemID\" " +
    " VALUE=\"" + item.getItemID() + "\">\n" +
    "<H2>" + item.getShortDescription() +
    " ($" + item.getCost() + ")</H2>\n" +
    item.getLongDescription() + "\n" +
    "<P>\n<CENTER>\n" +
    "<INPUT TYPE=\"SUBMIT\" " +
    "VALUE=\"Add to Shopping Cart\">\n" +
    "</CENTER>\n<P>\n</FORM>");
    out.println("<HR>\n</BODY></HTML>");
    null

    I am trying to apply (or copy) codings from Servlet into JSP.What benefit is there to copying code from a servlet to a JSP? Is the servlet "working"?
    One of the issue that I encountered was bringing
    Private and Protected methods that were listed inside
    the Servlet class.
    If I just copy everything inside "Public void doGet",
    JSP would not work.Sounds like you need a redesign.
    1) My question is, is it better approach to apply
    Private and Protected method beside wrapping around
    with ( <%! %> (with !)) (like below)?
    I think I heard about using " ! " for private
    methods somewhere in the internet..Never heard of such a thing. Please cite the link if you have it.
    Here is what I have at JSP.Please, I can't look. This is wrong on so many levels. You've got scriptlet code, CSS style stuff, embedded HTML in one unmaintainable mess.
    Learn JSTL and CSS. Do not, under any circumstances, put scriptlet code in your JSP.
    The right way is to use the JSP purely as display and keep those protected and private methods on the server side where they belong. Have the JSP make a request to another object to do some work, get the result, and displa it.
    %

  • Password protecting history and removal of private browsing

    I am wondering if I can password protect the browsing history on this phone so it cannot be deleted without my permission. I would also like to remove or password protect the private browsing option... is this possible? Last of all can you hide or password the app store? I don't want to make addition users or lock up my entire phone just make it so it cannot be used inappropriately.

    You probably have '''Automatically start Firefox in a Private Browsing session''' selected in the Privacy tab in Options. That will cause those Tools menu items to be greyed-out. And when using that Option the (Private Browsing) line doesn't show in the Titlebar.
    http://support.mozilla.com/en-US/kb/Private+Browsing

  • Bean advice

    I want to use a JavaBean to represent a user in my application (a JSP/servlet app). But I am wondering if I have the right approach -- here is the basic idea:
    My bean, UserBean, has three properties (so far):
    - name (String)
    - password (String)
    - authorized (boolean)
    In addition to the getter/setter methods that I understand are required of all beans, I have one extra method (which will probably be protected or private in the final code):
    attemptAuthorization()
    which basically does the work of determining whether the name and password are a valid combination to call setAuthorized().
    Now, here's my two questions:
    (1) Is it okay to have this non-getter/setter method? It seems to me that for the most part, beans are pretty much just getters and setters.
    (2) Is it okay to have a setter method perform a side effect, such as calling the setAuthorized() setter method? Here is my code:
         * sets the <code>password</code> of the UserBean.  If the <code>name</code>
         * of the UserBean has already been set (is not null), this method attempts
         * to set the <code>authorized</code> property.
        public void setPassword(String password) {
            this.password = password;
            if (getName() != null) {
                attemptAuthorization();
        }It just seems like having methods that perform these kinds of side effects might invalidate my class from being a true javabean.
    Thanks!

    (1) Is it okay to have this non-getter/setter method?
    It seems to me that for the most part, beans are
    pretty much just getters and setters.
    (2) Is it okay to have a setter method perform a side
    effect, such as calling the setAuthorized()
    setter method? (1) and (2) are fine. You have a bean when you have a serializable class with a no-arg Ctor and get/set for the bean's properties, which,in your case, are 3 : name, password, and authorized.
    Keep in mind that adding side-effects is fine as long as you satisfy the basic requirements above. The only thing that too many of those side-effects might cause sometimes could be the re-usability of the bean in another context/JVM/machine...but that doesn't seem the case here.

  • How to get private fields from super class?

    Hi.
    I must get protected and private fields from a class. I know that sounds werid but I have a very good reason for doing so, ask if you want.
    I have tried the getDeclaredField(String) method, but it apparently doesn't return the fields declared by the super classes.
    What's the smartest solution to this?
    Thank you all.
    edit: note that the superclass hierarchy's length is 3 and that there are several classes at the bottom level.
    Edited by: bestam on Sep 24, 2009 2:05 PM

    bestam wrote:
    I do not claim I have invented a new programming language Sir, you must be mistaken. This is not turing complete.
    This is a language for describing Cards or a game's rules if you want.
    AspectJ isn't Turing complete but AspectJ is still a compiler.
    This is how I have been working :
    - I have implemented the core library in Java (what is a Player, what is an Effect, what is a Card, what is a BuildingCard, what is a Player's Turn and so on)
    - It also includes packages dedicated to service, able to retrieve and send data to the clients via sockets.
    - Then I have "hardcoded" a dozen of specific cards in Java, for testing and validating the core library. I have been doing so by extending the BuildinCard's class for example.
    - But my ultimate goal is not to code thoses 1.000+ cards of the game in Java. I chosed to design a little language so that I would end up writing cards faster. While I'm traversing the syntactical tree representing the card, I feed the card's fields one by one. Some of them are quite primitive, some other are more complex and have a recursive nature for instance.
    Providing detail for how you implemented it doesn't change anything about what I already said.
    Thus, this is not really a compiler as it doesn't transform a text in language A into a text in language B.
    You really need to understand more about what "compilers" and certainly compiler theory do before you decide what they can and cannot do.
    And your statement still does not change what I said.
    Is this wrose than the bean design pattern from JSP ? I'm not sure.
    Bean design? A "bean" has almost zero requirements.
    Aside of that, it's a bit harsh to be told "read the fucking manual" while I have written my first compiler some years ago.Not sure who that was directed. I suggested some reading material on compiler theory.
    If you think that your idea is ideal then knock yourself out. Since I doubt I will end up seeing it in anything that I must maintain it doesn't matter to me. But you did in fact ask what the best solution was.

  • Private key from 5.1 to 7.0

    Hi, we're currently upgrading from WebLogic server 5.1 to 7.0. The private
    key generated by WLS 5.1 does not use any password, and can therefore not be
    used with 7.0
    Do I have to generate a new private key and order a new SSL certificate, or
    is there a way I can assign a password to my existing private key so I can
    continue using this ??
    Thanx in advance !!!
    Jan Espen Hansen

    Thanks a lot Tony !!!!! This solved my problem.
    JEH
    "Tony" <TonyV> wrote in message news:[email protected]..
    Incorrect PEM headers/footers can confuse the tool.
    Double check that the header and footer for your PEM file match thecontents
    of the
    data in the file.
    If it was an unprotected RSA private key, the header and footer shouldlook
    like
    this:
    -----BEGIN RSA PRIVATE KEY-----
    -----END RSA PRIVATE KEY-----
    It should not say it is a certificate (which is the default for theder2pem
    utility), and it
    should not say it is an encrypted private key.
    Tony
    "a" <[email protected]> wrote in message news:3f9f7705$[email protected]..
    Hi, and thank you for your answer. I've tried the tool you mention, but
    I
    get the following error message:
    "Error parsing BER private key data 3000"
    Since my private key is in .der format I have first run the weblogicutil
    utils.der2pem on it, but I still get this error message.
    Any ideas ??
    JEH
    "Tony" <TonyV> wrote in message news:[email protected]..
    You should not have to generate a new key.
    There is a native tool that is supplied on the WLS kit that can
    protect
    an
    unprotected private key for you:
    wlkeytool inputkey.pem outputkey.pem
    It will prompt for passwords, I believe that will do what you want.
    Tools such as OpenSSL should also be able to protect the private key.
    Tony
    "Janne K" <[email protected]> wrote in message
    news:[email protected]..
    Hi, we're currently upgrading from WebLogic server 5.1 to 7.0. Theprivate
    key generated by WLS 5.1 does not use any password, and can
    therefore
    not
    be
    used with 7.0
    Do I have to generate a new private key and order a new SSL
    certificate,
    or
    is there a way I can assign a password to my existing private key so
    I
    can
    continue using this ??
    Thanx in advance !!!
    Jan Espen Hansen

Maybe you are looking for