[JBoss JIRA] Created: (SEAMFORGE-88) Provide the ability to add @Option Converters for custom types
by Lincoln Baxter III (JIRA)
Provide the ability to add @Option Converters for custom types
--------------------------------------------------------------
Key: SEAMFORGE-88
URL: https://issues.jboss.org/browse/SEAMFORGE-88
Project: Seam Forge
Issue Type: Enhancement
Components: Plugin API, Shell
Affects Versions: 1.0.0.Alpha2
Reporter: Lincoln Baxter III
This process should be encapsulated with a Forge interface API, adapter, and ServiceLoader for extension.
void init(@Observes final Startup event, final PluginCommandCompleter pluginCompleter) throws Exception
{
BooleanConverter booleanConverter = new BooleanConverter();
addConversionHandler(boolean.class, booleanConverter);
addConversionHandler(Boolean.class, booleanConverter);
addConversionHandler(File.class, new FileConverter());
addConversionHandler(Dependency.class, new DependencyIdConverter());
addConversionHandler(URL.class, new URLConverter());
...
}
public interface OptionValueConverter<T> {
public boolean supports(Class<?> type);
public T convert(Object value);
}
This interface should support injection.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (SEAMFORGE-79) When using the new-field command, the getters and setters should be separated from the field to make it more readable.
by Pablo Martinez (JIRA)
When using the new-field command, the getters and setters should be separated from the field to make it more readable.
----------------------------------------------------------------------------------------------------------------------
Key: SEAMFORGE-79
URL: https://issues.jboss.org/browse/SEAMFORGE-79
Project: Seam Forge
Issue Type: Feature Request
Components: Brainstorming
Affects Versions: 1.0.0.Alpha2, 1.0.0.Alpha1, 1.0.0.Alpha3
Reporter: Pablo Martinez
Priority: Optional
When using the new-field command, the getters and setters should be separated from the fields, to make the java class more readable after using seamforge.
An idea is to separate every java class in 4 parts: Field block, Constructor block, Getter/Setter block and Method block, using some arbitrary sintax (for easy parsing maybe?), for example something like:
@Entity
public class User {
/* [FIELDS] */
private int id;
private String username;
private String password;
/* [CONSTRUCTORS] */
public User() {
}
public User(String username, String password) {
}
/* [GETTERS/SETTERS] */
public String getUsername() {
return this.username;
}
public void setUsername(final String username) {
this.username = username;
}
//etc...
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (SEAMFORGE-80) Configurable classpaths for Forge
by Shane Bryzak (JIRA)
Configurable classpaths for Forge
---------------------------------
Key: SEAMFORGE-80
URL: https://issues.jboss.org/browse/SEAMFORGE-80
Project: Seam Forge
Issue Type: Feature Request
Reporter: Shane Bryzak
Currently Forge automatically scans the lib folder for libraries, however in the Seam bundled distribution there are also separate primary module libraries contained in the artifacts folder, which may be required by Forge. Directory structure looks something like this:
/seam-3.0.0.CR3
/artifacts
seam-catch.jar
seam-faces.jar
seam-solder.jar
(etc)
/forge
forge
forge.bat
/lib
(all other libraries)
It would be nice to be able to configure additional locations for Forge to scan. One suggestion for doing this might be to allow a file called forgeclasspath.conf in the /forge directory, which the forge bootstrap can read to determine other paths to scan.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
JLine Unsupported Terminal Bug?
by Lincoln Baxter, III
Hi Jason,
Sorry to bug you here again. If you know where I can find the JLine issue
tracker, could you let me know? Thanks.
Until then ;) I believe I've found a bug in JLine's handling of unsupported
terminals. Currently, when reading the input stream, when EOF is
encountered, JLine will return empty string "". I believe it should return
null in order to maintain consistency with supported terminal handling:
*The current implementation:*
/**
* Read a line for unsupported terminals.
*/
private String readLine(final InputStream in) throws IOException {
StringBuilder buff = new StringBuilder();
while (true) {
int i = in.read();
if (i == -1 || i == '\n' || i == '\r') {
return buff.toString();
}
buff.append((char) i);
}
// return new BufferedReader (new InputStreamReader (in)).readLine
();
}
*Should probably be updated to:*
/**
* Read a line for unsupported terminals.
*/
private String readLine(final InputStream in) throws IOException
{
StringBuilder buff = new StringBuilder();
while (true)
{
int i = in.read();
if (i == -1)
{
return null;
}
else if (i == '\n' || i == '\r')
{
return buff.toString();
}
buff.append((char) i);
}
// return new BufferedReader (new InputStreamReader (in)).readLine ();
}
Also, if performance is a reason for using the StringBuilder here, why not
use a *static final EMPTY_STRING = "";* and return that?
*The downstream issue, for reference:*
https://issues.jboss.org/browse/SEAMFORGE-77
Thanks for your time.
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
13 years, 9 months