[forge-issues] [JBoss JIRA] (FORGE-2281) toString generation shouldn't take injected fields into account

Antonio Goncalves (JIRA) issues at jboss.org
Sun Mar 15 04:54:18 EDT 2015


     [ https://issues.jboss.org/browse/FORGE-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Antonio Goncalves updated FORGE-2281:
-------------------------------------
    Description: 
Today, when we create an injected field to a class, the toString method takes it into account. For example, the following script generates a Java class, one injected field with no toString (--updateToString=false), and then a second field with a toString:

{code}
project-new --named test
cdi-setup
java-new-class --named MyClass
java-new-field --named attnoget --generateGetter=false --generateSetter=false --updateToString=false
java-add-annotation --annotation javax.inject.Inject --onProperty attnoget 
// Until this point there is no toString
java-new-field --named att               
// Here the toString is generated with both att and attnoget                                                                                    
{code}

The generated code generates a toString with both attributes :
{code}
more MyClass.java
package org.test;

import javax.inject.Inject;
import java.lang.Override;

public class MyClass
{

   @Inject
   private String attnoget;
   private String att;

   public String getAtt()
   {
      return att;
   }

   public void setAtt(String att)
   {
      this.att = att;
   }

   @Override
   public String toString()
   {
      String result = getClass().getSimpleName() + " ";
      if (attnoget != null && !attnoget.trim().isEmpty())
         result += "attnoget: " + attnoget;
      if (att != null && !att.trim().isEmpty())
         result += ", att: " + att;
      return result;
   }
}
{code}

It would be good if the toString generation would be aware of injection field. For example, a field with @Inject, @PersistenceUnit, @PersistenceContext, @EJB, @WebServiceRef would not be taken into account in the toString.

Or something easier, the toString generation could use the getters instead of the fields.

  was:
Today, when we create an injected field to a class, the toString method takes it into account. For example, the following script generates a Java class, one injected field with no toString (--updateToString=false), and then a second field with a toString:

{code}
project-new --named test
cdi-setup
java-new-class --named MyClass
java-new-field --named attnoget --generateGetter=false --generateSetter=false --updateToString=false
java-add-annotation --annotation javax.inject.Inject --onProperty attnoget 
// Until this point there is no toString
java-new-field --named att               
// Here the toString is generated with both att and attnoget                                                                                    
{code}

The generated code generates a toString with both attributes :
{code}
more MyClass.java
package org.test;

import javax.inject.Inject;
import java.lang.Override;

public class MyClass
{

   @Inject
   private String attnoget;
   private String att;

   public String getAtt()
   {
      return att;
   }

   public void setAtt(String att)
   {
      this.att = att;
   }

   @Override
   public String toString()
   {
      String result = getClass().getSimpleName() + " ";
      if (attnoget != null && !attnoget.trim().isEmpty())
         result += "attnoget: " + attnoget;
      if (att != null && !att.trim().isEmpty())
         result += ", att: " + att;
      return result;
   }
}
{code}

It would be good if the toString generation would be aware of injection field. For example, a field with @Inject, @PersistenceUnit, @PersistenceContext, @EJB, @WebServiceRef would not be taken into account in the toString



> toString generation shouldn't take injected fields into account
> ---------------------------------------------------------------
>
>                 Key: FORGE-2281
>                 URL: https://issues.jboss.org/browse/FORGE-2281
>             Project: Forge
>          Issue Type: Enhancement
>          Components: Java EE
>    Affects Versions: 2.15.1.Final
>            Reporter: Antonio Goncalves
>             Fix For: 2.x Future
>
>
> Today, when we create an injected field to a class, the toString method takes it into account. For example, the following script generates a Java class, one injected field with no toString (--updateToString=false), and then a second field with a toString:
> {code}
> project-new --named test
> cdi-setup
> java-new-class --named MyClass
> java-new-field --named attnoget --generateGetter=false --generateSetter=false --updateToString=false
> java-add-annotation --annotation javax.inject.Inject --onProperty attnoget 
> // Until this point there is no toString
> java-new-field --named att               
> // Here the toString is generated with both att and attnoget                                                                                    
> {code}
> The generated code generates a toString with both attributes :
> {code}
> more MyClass.java
> package org.test;
> import javax.inject.Inject;
> import java.lang.Override;
> public class MyClass
> {
>    @Inject
>    private String attnoget;
>    private String att;
>    public String getAtt()
>    {
>       return att;
>    }
>    public void setAtt(String att)
>    {
>       this.att = att;
>    }
>    @Override
>    public String toString()
>    {
>       String result = getClass().getSimpleName() + " ";
>       if (attnoget != null && !attnoget.trim().isEmpty())
>          result += "attnoget: " + attnoget;
>       if (att != null && !att.trim().isEmpty())
>          result += ", att: " + att;
>       return result;
>    }
> }
> {code}
> It would be good if the toString generation would be aware of injection field. For example, a field with @Inject, @PersistenceUnit, @PersistenceContext, @EJB, @WebServiceRef would not be taken into account in the toString.
> Or something easier, the toString generation could use the getters instead of the fields.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


More information about the forge-issues mailing list