[Design of JBossXB] - about JBMETA 198/199
by jeff.zhang
anonymous wrote :
| > > The problem is there is no way to specify the namespace for the root
| > > element. So, this approach (hack in fact) will only work for DTDs and
| > > schemas with default namespace. Which is not your case.
| > > You can continue hacking by wrapping your metadata classes (I think just
| > > wrapping the root class will be sufficient) and bind these wrappers to
| > > the default namespace and then use that in the -beans.xml binding file.
|
1. extend the JCA15MetaData and JBossRAMetaData classes and create 2 wrap classes. in which I define the namespace in the class by using annotation @JBossXmlSchema, is it correct?
2. define SchemaConfig that binding xsd file and metadata class, like
| <entry>
| <key>connector_1_5.xsd</key>
| <value>org.jboss.metadata.rar.spec.JCA15MetaData</value>
| </entry>
|
In metadata project, we don't import MC project, so I can add this bind into MetaDataSchemaResolverFactory class like:
| resolver.mapLocationToClass("connector_1_5.xsd", JCA15MetaData.class);
|
but the map key "connector_1_5.xsd" is used, how could I bind xsd file into new wrap class?
thanks a lot
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4231558#4231558
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4231558
16 years, 10 months
[Design of Clustering on JBoss] - Re: API modifications for better extensibility ?
by deruelle_jean
"bstansberry(a)jboss.com" wrote : Hi Jean,
|
| The code freeze for AS 5.1.0.GA is tomorrow and I'm on vacation, so the following is significantly colored by that. I can think about this more in a couple weeks when I get back, but once 5.1.0.GA is done there may not be a 5.2 as we move on to AS 6.
|
| For AS 6 please open a JIRA to have another look at this design. I'm not comfortable with all these protected methods.
|
Thanks Brian ! Here it is https://64.74.196.157/jira/browse/JBAS-6933
"bstansberry(a)jboss.com" wrote :
| I do not want to expose startUnembedded. That is to support running in standalone Tomcat, which was a JIRA started in 2005 and never officially finished, not significantly tested in years etc. I don't want to make it part of this API. Does Mobicents run in standalone Tomcat?
|
| Would prefer not exposing startEmbedded either.
|
| If you *really need* start(Un)Embedded exposed, go ahead on Monday, but assume that there would be some change in AS 6; i.e. you and I will redesign this. And please be extremely careful as it's the code cutoff. :)
|
We run in standalone Tomcat indeed, but clustering is not advertised as supported or tested for it only for JBoss versions so we are fine and let it as is then.
"bstansberry(a)jboss.com" wrote :
| AbstractJBossCacheService
|
| * make the storeSessionOwners protected so that we can reuse it
|
| Feel free to make this a protected static method. However this change will not be in AS 5.1.0.GA as this would require a component update and we are past the deadline for component updates. A later Mobicents release of course could replace this jar with a later version. Which is why it's a separate jar. :)
|
Actually, I needed a different signature for this method for Mobicents so this is not needed anymore (sorry about the noise here)
"bstansberry(a)jboss.com" wrote : The above changes are svn r88986 in Branch_5_x. Not ported to trunk yet.
Thanks :-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4231518#4231518
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4231518
16 years, 10 months
[Design of Clustering on JBoss] - Re: API modifications for better extensibility ?
by bstansberry@jboss.com
Hi Jean,
The code freeze for AS 5.1.0.GA is tomorrow and I'm on vacation, so the following is significantly colored by that. I can think about this more in a couple weeks when I get back, but once 5.1.0.GA is done there may not be a 5.2 as we move on to AS 6.
For AS 6 please open a JIRA to have another look at this design. I'm not comfortable with all these protected methods.
"deruelle_jean" wrote :
| * initSnapshotManager to be made protected so that it can be overriden (so that we can set our own converged snapshotManager)
Done.
anonymous wrote :
| * getSnapshotManager() and setSnapshotManager() public methods or snapShotManager_ field to be made protected
Added a protected getter/setter. I don't want it public.
anonymous wrote :
| * installValves and installValve methods to be made protected so that they can be overriden (we need that to install our custom JVMRouteValve)
Done.
anonymous wrote :
| * Ideally, methods such as start/stopEmbedded and UnEmbedded and the methods they use internally should be made protected too
I renamed initCacheProxy() to initDistributedCacheManager() and made it protected. Also made initClusteredSessionNotificationPolicy() and initializeUnloadedSessions() protected.
Also added protected void startExtensions() and stopExtensions() which are a hook into the start/stop process for subclasses.
I do not want to expose startUnembedded. That is to support running in standalone Tomcat, which was a JIRA started in 2005 and never officially finished, not significantly tested in years etc. I don't want to make it part of this API. Does Mobicents run in standalone Tomcat?
Would prefer not exposing startEmbedded either.
If you *really need* start(Un)Embedded exposed, go ahead on Monday, but assume that there would be some change in AS 6; i.e. you and I will redesign this. And please be extremely careful as it's the code cutoff. :)
anonymous wrote :
| AbstractJBossCacheService
|
| * make the storeSessionOwners protected so that we can reuse it
|
Feel free to make this a protected static method. However this change will not be in AS 5.1.0.GA as this would require a component update and we are past the deadline for component updates. A later Mobicents release of course could replace this jar with a later version. Which is why it's a separate jar. :)
anonymous wrote :
| IntervalSnapshotManager
|
| * make the fields protected
This is a simple enough class, and you now have the hooks to install whatever SnapshotManager you like, so please just keep your own version.
The above changes are svn r88986 in Branch_5_x. Not ported to trunk yet.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4231472#4231472
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4231472
16 years, 10 months