[Design of POJO Server] - Re: Moving forward with the profile service mgmt api
by adrian＠jboss.org
I've updated the Deployers with support for retrieving ManagedObjects.
See org.jboss.test.deployers.managed.test.DeployerManagedObjectUnitTestCase
which includes some TODOs (I've included some TODOs where I added the new api).
This means that jboss-managed.jar and jboss-metatype.jar need to be included
in the next mc snapshot for JBossAS. Although there isn't anything using this api
at runtime yet, the MainDeployer and DeployerWrapper import the ManagedObject interface.
Now you can retrieve the corresponding ManagedObjects for a deployment's
Attachments if the deployer has been coded to implement
org.jboss.deployers.spi.managed.ManagedObjectBuilder
I also updated the ManagedObject api with a
String getName();
Serializable getAttachment();
Where the getName() is the name of the attachment in the Attachments map(s)
of the DeploymentContext.
So there are some basic links between the
Deployer, DeploymentContext, Attachment and ManagedObject
but no real code (besides mock tests) that construct ManagedObjects
The rest of the basic Attachment/ManagedObject handling
(excluding non-redeployment runtime changes) should be handled by the profile service?
I'm going to go back to working on the ManagedObject generation now. :-)
Though you probably first need a "hand-written" ManagedObjectBuilder implementation
in the datasource deployer to complete the basic end-end tests?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995782#3995782
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995782
19 years
[Design of POJO Server] - Re: ManagedObjects of ManagedObjects, etc.
by adrian＠jboss.org
The version of ManagedProperty that I have is just a wrapper for
arbitrary Fields (like a JMX descriptor).
It would clearly be trivial to add a Fields.CONTEXT as a standard one.
The plan is that the additional fields will really be annotations on the metadata classes,
making them trivial to maintain and easy to keep up-to-date.
There are a number of reasons for keeping the metadata/underlyingManagedObjects
seperate for the different attachments (e.g. ejb-jar, jboss.xml), while still providing
a unifying ManagedObject for ease use.
The most important is that you can marshall them back into the xml from the attachments.
Once you've merged them into a single view, this is not in general possible.
Another is that an admin console can "follow the links" to navigate through
complex models, e.g. following an ejb-link to the target ejb.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995780#3995780
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995780
19 years
[Design of JBossCache] - Re: Buddy state transfer
by manik.surtani＠jboss.com
I too agree that, from a manageabillity + intuitiveness standpoint, we should use the same process, but here's more food for thought (hope you're hungry!) :-)
"bstansberry(a)jboss.com" wrote :
|
| 2) A and B now have to independently request state rather than C doing a single push. Don't know if there are any issues with the coordination involved there. Now that we are using anycast, the network utilization is likely the same either way.
|
|
Even with anycast, it is not the same. Currently, anycast forces a unicast to the members individually. IIRC, if the transport is UDP and multicast is enabled, this is achieved by multicasting and only named recipients accepting the comms (Bela or Vlad, perhaps you could confirm this?).
If this is true, then the pull approach is more expensive on UDP/multicast, even with anycast.
Another cost with the pull approach is processing time building the state transfer payload. And also the concurrency cost on the data owner, locking the tree to generate this payload. This happens once with push, n times with pull.
Both of these gets more expensive (O(n)) based on number of buddies though, so with just 1 buddy per node (the default) this should not be any more expensive.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995761#3995761
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995761
19 years
[Design of POJO Server] - Re: ManagementView changes
by scott.stark＠jboss.org
"charles.crouch(a)jboss.com" wrote :
| Agreed. This mapping seems to be the biggest point for discussion currently. Lets see if we can determine how to move forward in the JBAS5 meeting tomorrow.
|
| I want to try to stick to solving this problem for DataSources first and try to avoid getting swept out into the sea of complexity. To continue the water metaphor, I think we're just learning to paddle, so anywhere other than the shallow end (i.e. simple use cases) is not going to be helpful right now.
Fundamentally the only diff between a DataSource and arbitrary ear should be the depth of the ManagedObject graphs, and the number of views that are available. What I would like to come up with in terms of the mapping is something simple, and yet sufficient to allow for the various extremes we are talking about. I have a view of what the mapping data might look like that I'm working to flesh out for discussion. I'll try to get this out tonight.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995758#3995758
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995758
19 years
[Design of POJO Server] - Re: ManagementView changes
by scott.stark＠jboss.org
"charles.crouch(a)jboss.com" wrote : "scott.stark(a)jboss.org" wrote :
| | Part of the property mapping definition should be a classification of the property from the perspective of an admin tool. In reality a property may be in multiple view/perspectives if we start talking about view likes "Server Ports", "Clustering", "Network Interfaces".
| |
|
| I'm not sure I fully understand this. Take for example two properties on a DataSource: the jndiName, and maxConnectionPoolSize. Would both of these properties get mapped to the /DataSource context?
| Say I had two datasources deployed A and B, and I searched specifying the "/DataSource" context, would I get four property instances back? Two jndiName's and two maxConnectionPoolSize's? How would the jndiName and maxConnectionPoolSize for DataSource A get linked?
|
The querying of the view has not been defined. If it was a tree "DataSource/{Pool,Security}" and you asked for the DataSource tagged properties, you should get all. If you asked for the DataSource/Pool properties, you would only get the pool oriented properties.
If we want to query across deployments by view (and that certainly makes sense for many view, DataSources included), then yes, we should be returning 4 properties tied back to the 2 ManagedObjects for the 2 deployments.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995757#3995757
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995757
19 years
[Design of EJB 3.0] - EmbeddedEJB3 issue
by Simoling
I want to use jboss-EJB-3.0_Embeddable_ALPHA_8-patch1 in tomcat5.5.17
I puted embedded-war standalone in tomcat when it start up it shows this
WARN 22-12 09:04:08,795 (BeanSchemaBinding.java:init:227) -You should use the
2.0 version of the Microcontainer xml. xmlns='urn:jboss:bean-deployer:2.0'
WARN 22-12 09:04:36,185 (Log4JLogger.java:warn:104) -Persistence provider call
er does not implements the EJB3 spec correctly. PersistenceUnitInfo.getNewTempCl
assLoader() is null.
and then I accessed the http://127.0.0.1:8082/standalone/EmbeddedEJB3.jsp
ERROR 22-12 09:12:51,427 (Log4JLogger.java:error:119) -Servlet.service() for se
rvlet jsp threw exception
javax.naming.NameNotFoundException: org.jboss.tutorial.embeddedwar.CustomerDAOLo
cal not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:626)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:588)
at javax.naming.InitialContext.lookup(Unknown Source)
at org.apache.jsp.EmbeddedEJB3_jsp._jspService(EmbeddedEJB3_jsp.java:143
)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
14)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p
rocessConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
int.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol
lowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
ool.java:684)
at java.lang.Thread.run(Unknown Source)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995749#3995749
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995749
19 years