[ https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s... ] Pete Muir commented on SEAMINTL-7: ---------------------------------- I am checking on the state of JBoss Logging 3 code base, and will post when I have worked through it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s... ] Dan Allen commented on SEAMINTL-7: ---------------------------------- Here's an example of how it might look (revised from Pete's slides) @StatusReporter public interface BookingStatusReporter { @ReportStatusMessage(level = INFO, defaultText = "You are booked to stay at the {0} on {1,date}", during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(Hotel hotel, Date date); } @Inject @StatusReporter BookingStatusReporter status; ... status.bookingConfirmed(booking.getHotel(), booking.getCheckinDate()); @StatusReporter specializes the functionality of @MessageBundle by stating the intent to register a status message rather than return a string. It's like @MessageLogger from weld extensions. If we want to reuse the @Message annotation from JBoss Logging, then the message method would instead be: @Message(level = INFO, value = "You are booked to stay at the {0} on {1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(Hotel hotel, Date date); In the second case, the @ReportStatus a) makes it a status message, b) has some additional settings (such as when to add the message) (btw, INFO is the default level, it's just shown for completeness) I'd really like to see EL evaluation supported in the message string to make it possible to reference property values. As you can see the above example assumes that Hotel#toString() returns the name of the hotel. Instead we might do: @Message(level = INFO, value = "You are booked to stay at the #{argv[1].name} on {1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(Hotel hotel, Date date); I use the index of 1 for the first argument because I'm thinking argv[0] can hold the name of the message key (i.e., method) As an alternative, we could allow named arguments by annotating the method parameters. @MessageParam assigns the method argument to the variable specified in the annotation's value. Then you can reference it in the message string. @Message(level = INFO, value = "You are booked to stay at the #{hotel.name} on {1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(@MessageParam("hotel") Hotel hotel, Date date); The @MessageParam stuff should probably go into JBoss Logging. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s... ] Dan Allen edited comment on SEAMINTL-7 at 11/9/10 11:36 PM: ------------------------------------------------------------ I forgot about the fact that status messages may need to have a target (i.e., the input to which it applies). This can be solved in three ways. Assume we have the following status reporter definition: @StatusReporter public interface RegistrationStatusReporter { @Message(level = WARN, value = "Username taken!") @ReportStatus void duplicateUsername(String username); } 1. Add target to message definition @Message(level = WARN, value = "Username taken!") @ReportStatus(target = "username") void duplicateUsername(String username); 2. Qualify the reporter at the injection point (much like selecting a locale) @Inject @StatusReporter @ForTarget("username") RegistrationStatusReporter usernameStatus; ... usernameStatus.duplicateUsername(username); 3. Using a selector (when the target is dynamic) @Inject @Any @StatusReporter Instance<RegistrationStatusReporter> status; ... status.select(new ForTargetLiteral(clientId)).get().duplicateUsername(username); was (Author: dan.j.allen): I forgot about the fact that status messages may need to have a target (i.e., the input to which it applies). This can be solved in three ways: 1. Defined in message @Message(level = WARN, value = "Username taken!") @ReportStatus(target = "username") void duplicateUsername(String username); 2. Qualify the reporter at the injection point (much like selecting a locale) @Inject @StatusReporter @ForTarget("username") RegistrationStatusReporter usernameStatus; ... usernameStatus.duplicateUsername(username); 3. Using a selector (when the target is dynamic) @Inject @Any @StatusReporter Instance<RegistrationStatusReporter> status; ... status.select(new ForTargetLiteral(clientId)).get().duplicateUsername(username); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s... ] Lincoln Baxter III commented on SEAMINTL-7: ------------------------------------------- I think what you've got there is actually really good. I just worry that folks are going to think it's too verbose, so I think we need a very simple default, too. Or rather, a very simple approach to compliment it. One that doesn't require implementing an interface, annotating it, injecting the interface with a special wrapper + annotation, then calling get() in order to get the implemented interface proxy to display the message. That's a lot of work. nice when it's done, yes, but I think we can provide an incremental approach to sort of let people get there if they want to. So, you can start out simple, then very easily "upgrade" to the strongly typed messages, etc. For example: I think the StatusReporter<?> interface should serve much like an Instance<?> wrapper, and should provide both the basic status message builder APIs, and also the strongly typed message APIs if the generic type is provided: public class Example { @Inject StatusReporter basic; @Inject StatusReporter<RegistrationStatusReporter> status; @Inject RegistrationStatusReporter registration; public void method() { basic.info().targets("foo").message("This is a message built using a non-typed StatusReporter") status.info().message("This is a custom message that is not strongly typed, still available."); status.getTyped().userRegistered(user); registration.userRegistered(user); } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s... ] Lincoln Baxter III edited comment on SEAMINTL-7 at 11/10/10 12:28 PM: ---------------------------------------------------------------------- I think what you've got there is actually really good. I just worry that folks are going to think it's too verbose, so I think we need a very simple default, too. Or rather, a very simple approach to compliment it. One that doesn't require implementing an interface, annotating it, injecting the interface with a special wrapper + annotation, then calling get() in order to get the implemented interface proxy to display the message. That's a lot of work. nice when it's done, yes, but I think we can provide an incremental approach to sort of let people get there if they want to. So, you can start out simple, then very easily "upgrade" to the strongly typed messages, etc. For example: I think the StatusReporter<?> interface should serve much like an Instance<?> wrapper, and should provide both the basic status message builder APIs, and also the strongly typed message APIs if the generic type is provided: public class Example { @Inject StatusReporter basic; // [1] most basic builder, no strong typing requested @Inject StatusReporter<RegistrationStatusReporter> status; // [2] introducing strong types @Inject RegistrationStatusReporter registration; // [3] pure strongly-typed access public void method() { // [1] basic.info().targets("foo").message("This is a message built using a non-typed StatusReporter") status.info().message("This is a custom message that is not strongly typed, still available."); // [2] status.getTyped().userRegistered(user); // [3] registration.userRegistered(user); } } was (Author: lincolnthree): I think what you've got there is actually really good. I just worry that folks are going to think it's too verbose, so I think we need a very simple default, too. Or rather, a very simple approach to compliment it. One that doesn't require implementing an interface, annotating it, injecting the interface with a special wrapper + annotation, then calling get() in order to get the implemented interface proxy to display the message. That's a lot of work. nice when it's done, yes, but I think we can provide an incremental approach to sort of let people get there if they want to. So, you can start out simple, then very easily "upgrade" to the strongly typed messages, etc. For example: I think the StatusReporter<?> interface should serve much like an Instance<?> wrapper, and should provide both the basic status message builder APIs, and also the strongly typed message APIs if the generic type is provided: public class Example { @Inject StatusReporter basic; // most basic builder, no strong typing requested @Inject StatusReporter<RegistrationStatusReporter> status; //introducing strong types @Inject RegistrationStatusReporter registration; // pure strongly-typed access public void method() { basic.info().targets("foo").message("This is a message built using a non-typed StatusReporter") status.info().message("This is a custom message that is not strongly typed, still available."); status.getTyped().userRegistered(user); registration.userRegistered(user); } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s... ] Dan Allen edited comment on SEAMINTL-7 at 11/11/10 2:23 PM: ------------------------------------------------------------ Here's an example of how it might look (revised from Pete's slides) @StatusReporter public interface BookingStatusReporter { @ReportStatusMessage(level = INFO, defaultText = "You are booked to stay at the {0} on {1,date}", during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(Hotel hotel, Date date); } @Inject BookingStatusReporter status; ... status.bookingConfirmed(booking.getHotel(), booking.getCheckinDate()); @StatusReporter specializes the functionality of @MessageBundle by stating the intent to register a status message rather than return a string. It's like @MessageLogger from weld extensions. If we want to reuse the @Message annotation from JBoss Logging, then the message method would instead be: @Message(level = INFO, value = "You are booked to stay at the {0} on {1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(Hotel hotel, Date date); In the second case, the @ReportStatus a) makes it a status message, b) has some additional settings (such as when to add the message) (btw, INFO is the default level, it's just shown for completeness) I'd really like to see EL evaluation supported in the message string to make it possible to reference property values. As you can see the above example assumes that Hotel#toString() returns the name of the hotel. Instead we might do: @Message(level = INFO, value = "You are booked to stay at the #{argv[1].name} on {1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(Hotel hotel, Date date); I use the index of 1 for the first argument because I'm thinking argv[0] can hold the name of the message key (i.e., method) As an alternative, we could allow named arguments by annotating the method parameters. @MessageParam assigns the method argument to the variable specified in the annotation's value. Then you can reference it in the message string. @Message(level = INFO, value = "You are booked to stay at the #{hotel.name} on {1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(@MessageParam("hotel") Hotel hotel, Date date); The @MessageParam stuff should probably go into JBoss Logging. was (Author: dan.j.allen): Here's an example of how it might look (revised from Pete's slides) @StatusReporter public interface BookingStatusReporter { @ReportStatusMessage(level = INFO, defaultText = "You are booked to stay at the {0} on {1,date}", during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(Hotel hotel, Date date); } @Inject @StatusReporter BookingStatusReporter status; ... status.bookingConfirmed(booking.getHotel(), booking.getCheckinDate()); @StatusReporter specializes the functionality of @MessageBundle by stating the intent to register a status message rather than return a string. It's like @MessageLogger from weld extensions. If we want to reuse the @Message annotation from JBoss Logging, then the message method would instead be: @Message(level = INFO, value = "You are booked to stay at the {0} on {1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(Hotel hotel, Date date); In the second case, the @ReportStatus a) makes it a status message, b) has some additional settings (such as when to add the message) (btw, INFO is the default level, it's just shown for completeness) I'd really like to see EL evaluation supported in the message string to make it possible to reference property values. As you can see the above example assumes that Hotel#toString() returns the name of the hotel. Instead we might do: @Message(level = INFO, value = "You are booked to stay at the #{argv[1].name} on {1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(Hotel hotel, Date date); I use the index of 1 for the first argument because I'm thinking argv[0] can hold the name of the message key (i.e., method) As an alternative, we could allow named arguments by annotating the method parameters. @MessageParam assigns the method argument to the variable specified in the annotation's value. Then you can reference it in the message string. @Message(level = INFO, value = "You are booked to stay at the #{hotel.name} on {1,date}") @ReportStatus(during = TransactionPhase.AFTER_SUCCESS) void bookingConfirmed(@MessageParam("hotel") Hotel hotel, Date date); The @MessageParam stuff should probably go into JBoss Logging. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s... ] Dan Allen commented on SEAMINTL-7: ---------------------------------- I talked to David Llyod while in Antwerp about: 1. reusing the @Message annotation 2. adding the EL functionality 3. moving @Message to the org.jboss.i18n package He was firm about keeping JBoss Logging as simple as possible. He suggested that we create our own, simplified annotations rather than trying to reuse the annotations from JBoss Logging. Plus, one annotation is a much simpler API than two from the user's perspective. So I'm in favor of either @StatusMessage or @ReportStatusMessage. I'm not sure if "Log" in @LogMessage is meant to be read as an action (verb) or not. If it is, then that's what @ReportStatusMessage is meant to parallel. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s... ] Dan Allen commented on SEAMINTL-7: ---------------------------------- The problem I have is that: a) Message is in the org.jboss.logging package, that's strange b) We need EL interpolation in the Message, which perhaps is possible, but we can't simply delegate to JBoss Logging then c) Using two annotations is weird, IMO (though if that's the pattern, so be it) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s... ] Dan Allen commented on SEAMINTL-7: ---------------------------------- In that case, what name to you prefer for the complement to @LogMessage? Do you prefer @ReportStatusMessage, @StatusMessage or something else? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin.s... ] Dan Allen commented on SEAMINTL-7: ---------------------------------- Excellent. Let's move forward ;) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin... ] Dan Allen commented on SEAMINTL-7: ---------------------------------- 2) How would we support the text of a message residing in either property files, database or some other resource? I think we draw from a proposal Pete once put together: http://in.relation.to/Bloggers/StoringYourMessagesInADatabase And another for CDI by a couple different people: http://in.relation.to/Bloggers/AnotherNicePortableExtension https://github.com/softwaremill/softwaremill-common/blob/master/softwarem... http://www.andygibson.net/blog/article/injecting-string-resource-services... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin... ] Dan Allen commented on SEAMINTL-7: ---------------------------------- @Message should be kept simple. It's just for specifying the text (and perhaps plural forms). It also has a formatter option, though even that could be pushed to somewhere else. I like the plural stuff, I like the key idea. While we work on this, let's get James Perkins involved to help understand how we tool it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin... ] Ken Finnigan updated SEAMINTL-7: -------------------------------- Fix Version/s: 3.0.0.Beta2 (was: 3.0.0.Beta1) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin... ] Ken Finnigan updated SEAMINTL-7: -------------------------------- Summary: Provide TypeSafe Messaging API (was: Rewrite Messages API along the lines of JBoss Logging 3) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin... ] Ken Finnigan updated SEAMINTL-7: -------------------------------- Original Estimate: 2 days Remaining Estimate: 2 days Affects Version/s: 3.0.0.Final Affects: [Documentation (Ref Guide, User Guide, etc.)] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin... ] Jason Porter commented on SEAMINTL-7: ------------------------------------- Is this done? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin... ] Jason Porter commented on SEAMINTL-7: ------------------------------------- Any chance we can get it done for 3.1.0.Beta4? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMINTL-7?page=com.atlassian.jira.plugin... ] Ken Finnigan commented on SEAMINTL-7: ------------------------------------- Maybe, but not sure -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira