My MBeans are annotated using Spring annotations as follows:
#ManagedAttribute(description = "returns the name")
public String getName() {
return name;
}
Now, whenever I open a JMX Console (be it VisualVM or JConsole), I can see the attributes of my beans in the Attributes tab, but I can also see the getName() method exposed in the Operations tab. Is there a way in which I can only see the attribute in the Attribute tab (i.e. hide it from the Operations tab)?
AbstractReflectiveMBeanInfoAssembler has this code since 2008:
// Attributes need to have their methods exposed as
// operations to the JMX server as well.
If you see the descriptor part of the javax.management.modelmbean.ModelMBeanOperationInfo, you'll see that there are parameters role=getter and visibility=4, which should (it depends on application that displays attributes/operations) be hidden somehow.
See more details under https://jira.spring.io/browse/SPR-4232.
Related
I have created a Model and i want to access model data annotation like DisplayName.
I have access model through WCF service layer. But WCF service remove all the Data annotation of the model.
[DisplayName("Student Name")]
public virtual string StudentName
{
get
{
return this.m_StudentName;
}
set
{
this.m_StudentName= value;
}
}
I want to access Display Name in the View but always I get null value in the DisplayName method in through the Property
A WCF service does not remove anything. However, building a service reference is making a copy of all the classes you have. And that copy is the smallest set neccessary to run the service.
If you need your full classes, put all those classes and interfaces you want shared into a common library that both your service and your client reference. This is commonly called a contract assembly. You can then either call the service directly through code or if you want to keep the wizard, you can use the checkbox that says "use classes in this project" when generating new types.
Let's assume following basic Project-Setup:
- Core
-- Attributes
--- CustomDisplayNameAttribute : DisplayNameAttribute
- UI
UI represents the MVC Web interface, the core implements all the domain business objects, including self written attributes like CustomDisplayNameAttribute. This attribute contains additional dependencies like a language resolver, which e.g. deals with fallback orders. Hibernate sessions would be another possible dependency.
In earlier projects, these attributes did a global request in order to get the resolver. This is IMO ugly and should be handled differently. Furthermore, Core should stay without HttpContext: since the language-resolver is required per request, it might end up in HttpContext Items Collection.
Now I am quite a beginner with Ninject, and I am not sure if it is the right tool in order to get such dependencies into something like a CustomDisplayNameAttribute?
In words it would be something like this:
If the attribute is created, populate the additional language resolver property with the language resolver from HttpContext Items Collection
If there is no HttpContext (e.g. testing, quartz jobs etc.), get it from somewhere else.
Thx for any inputs
Edit: Sample-Code
namespace Core.Attributes
{
public class CustomDisplayNameAttribute : DisplayNameAttribute
{
private string textCode;
/// <param name="textCode">According to this Text-Code, we will load
/// and resolve the text.</param>
public DeimosDisplayNameAttribute(string textCode)
{
this.textCode = textCode;
}
/// <summary>
/// Load and resolve Text according to Text-Code
/// </summary>
public override string DisplayName
{
get
{
// Load - Ooops: First global access
// --> How can it be injected with IoC?
TextbausteinRepository repo = Root.GetTextBausteinRepository();
var textItem = repo.GetText(textCode);
// Resolve - Ooops: Second global access
// --> How can it be injected with IoC?
TextResolver resolver = Root.GetTextResolver();
return resolver.resolve(textItem);
}
}
}
}
Edit 2: In that context, it seems that there is no way around a global access, like a registry pattern or similar. UI would register the needed data in there, and the attributes would access it from there. We started to think about storing it in ThreadLocal<T>, but this seems not really save due to the fact that there is a possibility of thread-swapping during the life-cycle. So there seems no way around storing HttpContext in the registry layer. For more info about this subject, see [Cup(Of T)][1].
I don't think this is possible, because data attributes are not run-time dispatched like filters are. As such, there's no place to intercept the creation and inject what you're looking for.
I have a question with respect to returning data inside Struts2 .
Inside my Action class as shown below , i am getting the Records and setting them inside ArrayList .
But could anybody please tell me , how can i return the Obtained ArrayList to the JSP Page ? because with the syntax of the Action class execute method , it allows us to return only a String ?
public class DBDisplay extends ActionSupport{
private String name ;
List list = null;
public String execute() throws Exception
{
list = DBClass.getInstance().list();
Iterator it = list.iterator();
while(it.hasNext())
{
name = (String) it.next();
}
setName(name);
}
public String getname()
{
return name;
}
public void setName(String name)
{
this.name = name;
}
}
Action classes return a string to name the result, not to return data. Data is exposed via either action properties (like the name you already expose) or a model instance (if implementing ModelDriven).
Access to the list is the same as name–by providing a public accessor to the list:
public class DBDisplay extends ActionSupport {
private List list;
public List getList() { return list; }
// Rest of class elided.
}
Then from the JSP, for example:
<s:iterator value="list">
<s:property /><br/>
</s:iterator>
The iterator tag "value" attribute refers to the list action property, and will call getList() on the action. The property tag will access the value on the top of the stack if given no "value" attribute.
You may wish to spend some time looking over the Struts 2 "nutshell" documentation.
One of the fundamental design goals of Struts 2 framework is to bring MVC (Model-View-Controller) design pattern into the Web application development. MVC pattern enables separation of concerns and allows for the clean and loosely coupled code which is easy to maintain.
MVC pattern consists of 3 distinct pieces. Model, View and Controller. Let us see how these three elements are implemented in Struts 2.
Controller (StrutsPrepareAndExecuteFilter) – Controller is the component which handles co-ordination of various requests. In a Web application, different user requests needs to be served by different application components and this decision is taken by the Controller component. In Struts 2, every request to the Web application first reaches the front controller class – StrutsPrepareAndExecuteFilter. This inspects the incoming requests and then routes the request to the appropriate class (known as Action class in Struts) configured to handle the request.
Model (Action) – Model is the component which is responsible for executing application’s business functionality. It is the core of the application. It represents the state of the application and includes business logic and business data. In Struts 2, action classes act as the gateway to an application’s model. These classes are responsible for handling every user request and then delegates business logic to other classes written by the application developer.
Having different action classes for different user requests ensures that we have clean code which can be easily maintained. But what about functionality that is required across different user requests(such as application logging)?. For such cross cutting concerns, Struts 2 has a different component called interceptors.
View (Result) – View in an MVC architecture is the component responsible for the presentation(user interface). View component makes use of the Model component to get data and then display it. Struts 2 supports multiple technologies such as JSP, Velocity templates, FreeMarker, XSLT for View component. In Struts 2 terminology, View is know as the Result. The action class (Model) determines what Result (View) should be presented to the user.
User accesses a Struts 2 application functionality by accessing the application URL in a browser. The request always comes to the StrutsPrepareAndExecuteFilter controller(Since it is configured in the web.xml of all Struts 2 applications). StrutsPrepareAndExecuteFilter looks for the Action class to call in the struts.xml file. Alternatively it can guess it using conventions. Action class execute() method is then invoked which in turn calls the business logic classes.
Action classes can specify the view to display using annotations or it can be specified in the struts.xml file. Either way Struts 2 knows which View (Result) is to be invoked for displaying the data back to the user. Another important thing to note here is that the objects in the Action class is available to the View component. Hence Actions not only determine which View(Result) to display but also provides data required by the View.
The valueStack(it's combination of objectStack and contextMap) OGNL is used to store the action and other objects. You can use OGNL to access the objects stack and Context Map.
OGNL
Bind the elements to modal objects and converts values from one type to another
Bind generic tags with modal objects.
Create lists and maps on the fly, to be used with GUI methods
Invoke methods. you can invoke any method, not only getters and setters.
The Converter property in the code from the blog post, Silverlight MultiBinding solution for Silverlight 4, is not a dependency property, so I can't bind it with a converter (that for technical reasons must be instantiated as part of Unity injection earlier in the application rather than as a simple static resource as part of a user control).
How can I modify the MultiBinding code to accept a bound converter? I tried to make it a dependency property:
public IMultiValueConverter Converter { get { return (IMultiValueConverter)GetValue(ConverterProperty); } set { SetValue(ConverterProperty, value); } }
public static DependencyProperty ConverterProperty = DependencyProperty.Register("Converter", typeof(IMultiValueConverter), typeof(IMultiValueConverter), null);
but I got
DependencyProperty System.Windows.Data.IMultiValueConverter. Converter cannot be set on an object of type ...Binding.MultiBinding.
If this is not a viable option, how can I bind the ConverterParameter property or get something to simulate bindings of a converter to a MultiBinding?
I solved this using the "simulated bindings" route, though that's not my preference if someone has another answer. What I did instead was not build up the converter via dependency injection, but instead had it use service location to get it's needed dependencies. Generally I prefer dependency injection to service location. The "service location" was a matter of storing the Unity container in the application's global resources; from there it's not difficult to get what I need.
I'm working with JSF 2.0
I have a form in my admin section where I am going to select some users in a list.
The form (selectusers.xhtml) is adding these users to a list in a bean (SelectUsers.java).
After I have selected some user(s), I will pass the list of the user(s) from SelectUsers.java to another bean (AddAddressBean.java) and continue add information in another form (addadress.xhtml) which set other properties related to AddAddressBean for each user.
I do not know how to implement it. I would like that AddAddressBean.java shall be independent (so I can use it together with other beans), so I prefer that AddAddressBean.java shall not know about other beans.
Can you please help me? =)
B.R Carl
Several quick things come to mind :
Perhaps you could have a single bean only for those related pages, using #SessionScoped or the shorter CDI's #ConversationScope, or and this is the best of the three, the DeltaSpike #ViewAccessScoped
When clicking the button on page 1 where it'll take you to page 2, in the 1st bean, you can make use of Flash object to store objects you want to pass, and in the second bean's #PostConstruct method, you could get all the objects from the Flash object
If you dont mind using session scope, you can still have 2 beans, and one bean can refer to another bean using the jsf way(#ManagedProperty), or the Java EE inject way(#Inject) or the spring way if you use spring (#Autowired)
This how i implemented (used ConversationScoped as #bertie said ).
bean 1:
#Named("conversationBean1")
#ConversationScoped
public class ConversationBean1 implements Serializable {
//---start conversation----
}
bean 2:
#Named("conversationBean2")
#ConversationScoped
public class ConversationBean2 implements Serializable
{
#Inject
private ConversationBean1 conversationBean1;
}