February 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Portal] - Re: DB test matrix

by prabhat.jha＠jboss.com

Testsuite build failed because of deploymet issue with wsrp-producer. 2007-02-06 11:06:35,628 INFO [org.jboss.system.ServiceConfigurator] Problem configuring service portal.wsrp:service=RegistrationManager org.jboss.deployment.DeploymentException: Exception setting attribute javax.management.Attribute: name=Policy value=MBeanProxyExt[portal.wsrp:service=RegistrationPolicy] on mbean portal.wsrp:service=Registr\ ationManager; - nested throwable: (java.lang.RuntimeException: Error creating MBeanProxy: portal.wsrp:service=RegistrationPolicy) ..... Caused by: javax.management.InstanceNotFoundException: portal.wsrp:service=RegistrationPolicy is not registered. at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523) at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:666) at org.jboss.mx.util.MBeanProxyExt.init(MBeanProxyExt.java:407) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011995#4011995 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011995

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by timfox

"clebert.suconic(a)jboss.com" wrote : | | It's okay... as long we don't create a string parsing hell on the code. There are no strings involved. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011994#4011994 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011994

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by clebert.suconic＠jboss.com

Answering your post sent on "PostPosted: Tue Feb 6, 2007 10:48 AM Post subject: Re: JMS specific columns in DB" It's okay... as long we don't create a string parsing hell on the code. It's not that I really want normalized DBs. I had to deal with dynamic models before in my life and that created a hell on the persistent code. The database was beautiful but the code suffered to keep the schema dynamic. And that's my only concern. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011991#4011991 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011991

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by timfox

There is already a column that stores the headers called coreheaders. I am just suggesting putting jmsdestination, jmstype and jmscorrelationid in there with the other headers. I can see there is value in joining on jmsdestination for, for example reports, but this isn't lost, you can still get the jms destination in a query by joining channel id with channel mapper. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011990#4011990 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011990

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by clebert.suconic＠jboss.com

"timfox" wrote : "clebert.suconic(a)jboss.com" wrote : | | anonymous wrote : | | | If you have 100 systems... it's better to have 100 columns than a single column with 100 substrings to deal with. :-) | | | | | | | Who said you'd have to deal with substrings? | | | | From the original post: | | anonymous wrote : I am considering removing those columns and just storing those values as core headers in the message. | | I understood you would remove these columns and store them in a single field called header. Maybe I didn't understand how you would do it. | | If you have the single field... you would have to break down the string (or the header) when using the information. | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011989#4011989 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011989

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by clebert.suconic＠jboss.com

I would prefer a normalized database as I have stated before. By normalized I mean.. just having these fields on the table. On my understanding these tables are the tables for our current JMS implementation. (look at those table names... JMS_message, JMS_reference ...) Adding a new field on the database doesn't mean you are adding dependency to your code. The day we need another system, we will change the JDBCPersistenceManager or implement a new one. To me JDBCPersistenceManager is like a hibernate that maps our columns to databases. If some day we need extra data... we change the persistenceManager. If some day we have pluggable systems... I would say we will implement plugable persistence managers. and having columns created according to what's plugged/needed. So.. in another words... if we have a new system... we just implement a new PersistentManager View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011982#4011982 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011982

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMS specific columns in DB

by timfox

Let me-reiterate. The point of this task is to get the schema to a stable state so we don't have to writing migration scripts every time we do a release. The columns I am considering removing are vestigial, they are not used in any joins. Also they more than likely negatively effect performance due to the extra unnecessary number of tables the database has to deal with. If someone wants to find out the actual jms destination they can join the channel id to the channel mapper table. If we're not going to remove them now, we will probably do so a few months down the line anyway, in which case we will have to write a migration script, and will have customers with a messy straggling database with some columns used, some columns not used. I.e. a support head ache. If everyone is using the same db schema then it makes a hell of a lot easier. If we make changes to the schema as I suggest this means we can support pretty much any message type without changing the format. So we have stability, performance, future proofing, clarity and conciseness. If someone really wants a normalised JMS specific database as Clebert would like, then they can create a JDBCPersistenceManager that does this. Yes, this will be as slow as a tortoise on crutches, but it's possible. IMO the default out of the box schema should be simple and performant and not contain redundant that seem to server no real purpose. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011980#4011980 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011980

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - ProfileServiceUnitTestCase tests failing

by charles.crouch＠jboss.com

When running ProfileServiceUnitTestCase I'm getting two failures: Testcase: testProfileKeys took 3.505 sec | Testcase: testDeploymentNames took 0.231 sec | Testcase: testNoSuchProfileException took 0.11 sec | Testcase: testDataSourceDeploymentType took 0.1 sec | Testcase: testListDataSourceComponents took 3.164 sec | Caused an ERROR | null | java.lang.NullPointerException | at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.getTestDataSource(ProfileServiceUnitTestCase.java:264) | at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testListDataSourceComponents(ProfileServiceUnitTestCase.java:120) | | Testcase: testAddDataSource took 0.431 sec | Testcase: testRemoveComponent took 0.06 sec | Testcase: testUpdateDataSource took 0.05 sec | Caused an ERROR | null | java.lang.NullPointerException | at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.getTestDataSource(ProfileServiceUnitTestCase.java:264) | at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testUpdateDataSource(ProfileServiceUnitTestCase.java:206) because mgtView.getComponentsForType below is returning null: ComponentType dsType = new ComponentType("DataSource", "LocalTx"); | Set<ManagedComponent> dsComps = mgtView.getComponentsForType(dsType); Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011973#4011973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011973

19 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by adrian＠jboss.org

"weston.price(a)jboss.com" wrote : | Obviously this is not the only reason for the repository, but I can't quite see how we can get away with getting rid of the RAR names from our deployments. | If you are doing this in two phases (parse/runtime) it should be automatic? The parsing stage populates the repository, the runtime stage (the actual construction/configuration of the MBeans/Pojos) should have all the parsed rar information in the repository by then? What you really need is something I've not yet done in the MC which is the "write your own dependency". Basically allowing users to define and implement their own DependencyItem. You can sort of already do it with a bit of hacky code. e.g. for MBeans you can subclass ServiceDependencyMetaData to implement something more dynamic in the visitor callback but you need to update the ServiceMetaData by hand with your new dependency. But what I'd really like is for the dependencies to support wildcards, e.g. | <mbean code="MCF"> | <depends xmlns="urn:jboss-jca:5.0" rar-name="some.rar"/> | </mbean> | Where urn:jboss-jca:5.0:depends will unmarshal to a dependency implementation that knows how to look at the rar metadata repository at runtime. The attributes of this dependency could then have all the query parameters we'd like to support for looking up implementations, e.g. give me a rar that supports JmsXA outbound (not such the hardwired rar name). If nothing supports it (yet), you just return false from isResolved() in your DependencyItem implementtaion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011966#4011966 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011966

19 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: DB test matrix

by prabhat.jha＠jboss.com

Last night's portal-db testsuite build had failed. I have forced another build and if it happens again, I will do a RCA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011961#4011961 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011961

19 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2007