jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Portlet intercommunication

[<roy...@jb...>]

WSRP 2.0 will be implemented in JBoss Portal in the next version - 2.2. Our Novell team will be handling the ins and outs, since I stubbornly refuse to read the WSRP spec. ;-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877410#3877410

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877410

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Build Repository Structure

[<sco...@jb...>]

Right, assuming by manifest you mean the repository component-info.xml import statements?

We do need to figure out to handle the multiple version mismatches that will show up. As part of generating the license-info.xml from the thirdparty repository references, detection of version conflicts will be flagged. That should in fact be a custom cruisecontrol action that results in an email to qa and the development list. Maybe its best to require the version on component-info.xml import statements rather than trying to default to the latest to start with in the absence of such info to start with.

As you say I don't see any magic resolution. There needs to be testing and lead on the component using the older version consulted to see if the changes look to be problematic. This gets back to exactly what should be in the thirdparty repository. Release notes, source and patches would seem to be a good minimum in addition to the binaries.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877406#3877406

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877406

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Build Repository Structure

[<ad...@jb...>]

What do you do if two components specify different versions
of the same dependency? 

My guess is to take the latest and warn the developer if there is nothing
saying a component has been tested with that version.

This would then lead to a QA task where they test it and either:
1) update the manifest to say that version is ok
2) choose a later version of the component in question that has been tested
3) get the component developer(s) to fix any problems found from the testing

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877405#3877405

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877405

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Build Repository Structure

[<sco...@jb...>]

As was mentioned in this post which spawned the JBBUILD-72 issue, its not practical for the component user to have to know the dependencies of the component. Case 1, hibernate depends on cglib and asm, neither of which are used anywhere else in jbossas. In creating the top level build I only know I need hibernate 3.0.3. The component-info.xml for hibernate 3.0.3 needs to tell the synchronize process that cglib and asm are also needed.

This should not be in the jbossas build component list, because hibernate 3.0.4 may no longer have these dependencies. A given components dependeices should be a listing of those apis that are actually used.

I'll take a look at import addition and assign myself the task as I am looking at how the build actually works currently.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877404#3877404

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877404

[Jboss-dev-forums] [Design of Mail Services] - Re: Failure on Win2K

[wobbet <nu...@jb...>]

I do a netstat -a and get...

P:\>netstat -a

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    machinename:http     machinename:0  LISTENING
  TCP    machinename:epmap    machinename:0  LISTENING
  TCP    machinename:https    machinename:0  LISTENING
  TCP    machinename:microsoft-ds  machinename:0  LISTENING
  TCP    machinename:1098     machinename:0  LISTENING
  TCP    machinename:1099     machinename:0  LISTENING

That implies to me that nothing is listening below port 80 (http) which implies the basic SMTP config for the mail.ear/mail.sar/jboss-service.xml isn't loading up for whatever reason.

The machine is Win2K and doesn't have the firewall software.

The SMTP service is disabled...

I go to the networks control panel for the ethernet adapter, go to TCP/IP settings and then go to advanced. Select IP filtering, enable filtering and allow all traffic. Re-boot and...

No dice. Connection times out. 

I re-run netstat and get the same results.

This is my test machine for my integration of jASEN :(

Any clues?

rjsjr

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877398#3877398

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877398

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Build Repository Structure

[<rya...@jb...>]

Currently, the version metadata is only used when synchronizing, and this only at the toplevel build.  This was purposeful, because I assumed that the toplevel build should have a complete manifest of all versions used in the build, and that there should only be one version of each component used.   

At the component level, you don't need to resolve imported component versions because they have already been specified and downloaded by the toplevel build.  The component uses whatever is in thirdparty/component-id.

If we were using the component definitions to synchronize, we would need to do as you suggest.  What am I missing???

I agree the import mechanism should support a version for the purposes of flagging unmet version requirements.

I'm not working on the import functionality currently.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877396#3877396

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877396

[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - cluster deployment question

[dhill <nu...@jb...>]

 2 jboss servers installed on 2 SLES9 machines
1. From server 1, copy EAR file and datasource file to farm directory
2. start server 1, EAR was deployed
3. start server 2, it joined cluster, but EAR file didn't propagate on server 2

If change the ear file on server1 while server 2 was still running, EAR propagated on server 2 .


can someone explain #3, why it isn't deployed or is this the way it was designed ?

Thanks

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877384#3877384

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877384

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ad...@jb...>]

In case it isn't clear from the above posts.

The Map stuff is working now, but I'd appreciate it if you know a better way to
handle what I'm trying to do.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877383#3877383

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877383

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ad...@jb...>]

So the problem is two fold:

1) The need to specify a concrete type in startElement

2) My desire to have a less verbose API in the common case

  | <entry><key class="java.lang.Integer>1</key><value>x</value></entry>
  | 
instead of

  | <entry><key><value class="java.lang.Integer">1</value></key><value>x</value></entry>
  | 
The later is closer to the underlying object model, but obviously more tedious.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877381#3877381

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877381

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ad...@jb...>]

I've figured out what the problem is with the expression of the Map and Key/Value.
The issue is with the polymorphism, my attempts to reduce the
verbosity of the xml and the parsing API.

Essentially, the problem is that to get the polymorphism to work,
I have to introduce a type binding, in this case
key -> valueType
value -> valueType
where valueType can be collection/array/list/ANY/etc.

But this then requires an extra object to be constructed to model the polymorphic behaviour:


  |       // value binding
  |       TypeBinding valueType = schemaBinding.getType(valueTypeQName);
  | 
  |       configureValueBindings(valueType); // <------ subelements
  | 
  |       valueType.setHandler(new DefaultElementHandler()
  |       {
  |          public Object startElement(Object parent, QName name, TypeBinding type)
  |          {
  |             return new AbstractValueMetaData(new StringValueMetaData());
  |          }
  | etc.
  | 

Then later I have to unwrap the extra AbstractValueMetaData

  |             AbstractMapMetaData map = (AbstractMapMetaData) parent;
  |             MapEntry entry = (MapEntry) child;
  |             AbstractValueMetaData entryKey = (AbstractValueMetaData) entry.key;
  |             if (entryKey == null)
  |                throw new IllegalArgumentException("No key in map entry");
  |             AbstractValueMetaData entryValue = (AbstractValueMetaData) entry.value; 
  |             if (entryValue == null)
  |                throw new IllegalArgumentException("No value in map entry");
  |             map.put(entryKey.getValue(), entryValue.getValue());
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877380#3877380

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877380

[Jboss-dev-forums] [Design of JBoss Build System] - Re: Build Repository Structure

[<sco...@jb...>]

I'm not following how that lone source element triggers imports.

Going through this currently for the 4.0 thirdparty, the unversioned import still leaves open the problem of what version is being referenced. We can build a graph of components and attempt to resolve the components, but I see a number of components that have references to components only used by them (dom4j to jaxen, cglib to asm). We can attempt to taken the latest version of each unversioned reference, but this requires a latest link pointing to latest, or an index of the components so that it can be computed.

The import should also support a version in the case that there is an explicit version requirement. Are you working on adding the import addition Ryan? If not, I'll look at this since I need to complete it to finish the thirdparty build.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877379#3877379

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877379

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - PER_CLASS, PER_VM aspects with ejbs

[mikeg123 <nu...@jb...>]

Hello,
just wanted to get some info.

1. Would not PER_VM instance of an aspect create some bottlenecks?
2. Is there any benefit in using PER_CLASS vs PER_INSTANCE aspect with stateless ejbs? (I assume when ejb goes back to the pool instance of an aspect is not destroyed)
 
                                      Thanks Michael.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877376#3877376

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877376

[Jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Synchronous vs. asynchronous NACK when client refuses de

[timfox <nu...@jb...>]

Hi All-

Further to the discussion regarding asynchronous ACKs, here are some thoughts on how we can implement QueueBrowsing on the core classes and how it all works together.

The assumption here is that we want to be able to browse any messages in a queue where delivery has not been attempted. We don't want to browse those messages where the message has been delivered but the JMS client has NACKed it.

Currently the core classes don't allow us to distinguish those messages that have not had delivery attempted and those that have.

A proposal would be modify the return value of Receiver.handle() from a boolean to one of three states:

ACK - the message has been handled sychronously and acknowledged.
NACK-DeliveryAttempted - the message is not (yet) acknowledged but delivery is being attempted. 
NACK-DeliveryNotAttempted - the message is not acknowledged and delivery has not been attempted.

The acknowledgement store would also be modified to allow us to distinguish between NACK-DeliveryAttempted and NACK-DeliveryNotAttempted. I.e. it needs to store the tuple <receiver_id, message_id, nack_type (- one of delivery attempted or delivery not attempted)>

For the case of a queue:

If the queue has no consumers and messages arrive, nacks are stored with state NACK-DeliveryNotAttempted and the messages are stored.

The QueueBrowser will only browse NACKed messages with state NACK-DeliveryNotAttempted, so it sees these messages.

A consumer is now added to the queue, causing deliver() to be triggered. Messages with either of the two NACK states are sent for delivery. The consumer starts to accept messages for delivery, returning NACK-DeliveryAttempted to the router.

A QueueBrowser will not see the messages with state NACK-DeliveryAttempted.

As messages are asynchronously acknowledged a callback from the client to the server causes the corresponding NACK to be removed from the acknowledgement store. Currently this is done with a callback interface on the Consumer object (AcknowledgementHandler) which gets invoked from the client, I guess it could also be done by implementing this interface on the Destination classes (??)

Messages can be asynch. acknowledged due to either auto acknowledgement, manual acknowledgement, lazy acknowledgement or session commit.

For session commit, and potentially lazy acknowledgement and manual acknowledgement I think we also need to extend the Acknowledgement interface to take a batch of acknowledgements as opposed to a single acknowledgement, since the acks must be processed as an atomic unit for transacted sessions, and for the other cases this could help reduce network traffic (although it is probably to early for optimisations at this stage).

This also means I think we need to extend the acknowledgement store to be able to process a batch of ACKs (i.e. forget a batch of NACKs) as an atomic unit, otherwise if only some are reliably persisted because of failure in mid operation we have a problem.

Message re-delivery should only happen when the consumer (re)connects to the queue, Session.recover() is invoked or transacted session rollback occurs (Is that all cases?), so there should be no problem with the message being redelivered when it's already in mid delivery.

If a client dies, then its consumer can be removed, and when it reconnects the nacked messages are redelivered.

The behaviour of a durable subscription on a Topic should be almost identical I believe. Actually this should give us, (if we wanted to do some kind of JBoss specific JMS extension), the ability to browse durable subscribers too.

Non durable subscriptions shouldn't be affected since we don't store anything.

-Tim

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877372#3877372

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877372

[Jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Socket Connection State

[akilsubramanian <nu...@jb...>]

Hi All

I am new to Jboss Remoting.I just read the  documentation .

Can somebody tell me,if the Jboss Remoting can take care of the Socket connection state.

Is there a way to find in the JMX console or the web console of jboss ,the state of the socket connection on the particular port.

Thanks



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877362#3877362

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877362

[Jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Re: org.jboss.remoting.CannotConnectException (ejb3)

[<tom...@jb...>]

The port that ejb3 uses is defined by the org.jboss.remoting.transport.Connector configuration.  In ejb3, looks like this is 3873.  You can double check by looking for the jboss-service.xml in your ejb3 distro and seeing what it is set to within that.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877360#3877360

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877360

[Jboss-dev-forums] [Design of JBoss Portal] - Re: Running JBossportal-2.0 RC with JbossWebLoader=false

[<ju...@jb...>]

Swarn,

JBoss Portal 2.0 final release will work with JBoss 4.0.2 which has the model you need by default.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877356#3877356

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877356

[Jboss-dev-forums] [Design of JBoss Portal] - Running JBossportal-2.0 RC with JbossWebLoader=false

[sdhaliwal <nu...@jb...>]

We have a requirement where we must support per webapp class loading because multiple applications use different versions of the same class. The way to accomplish that seems to be changing the following configuration setting :

file = jboss\server\default\deploy\jbossweb-tomcat55.sar\META-INF\jboss-service.xml

setting = 
<!-- A flag indicating if the JBoss Loader should be used. This loader
           uses a unified class loader as the class loader rather than the tomcat
           specific class loader.
      -->
      false

When this change is made portal-forums app does not come up cleanly complaining that an exception was thrown in the init().

In addition, our JAAS module which works fine with the default setting 
(true) is never invoked in the portal environment.  

Are there any configuration and/or code changes  need to be made to behave the portal correctly without using the JBossWebLoader.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877354#3877354

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877354

[Jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - org.jboss.remoting.CannotConnectException (ejb3)

[mhaerdi <nu...@jb...>]

Hello 
When trying to connect to jboss (behind firewall) from a java client outside, i get a 

org.jboss.remoting.CannotConnectException: Can not get connection to server. Pr 
oblem establishing socket connection. 
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(Soc 
ketClientInvoker.java:232) 
at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.jav 
a:117) 
at org.jboss.remoting.Client.invoke(Client.java:201) 
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemot 
eInterceptor.java:39) 
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation. 
java:66) 
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPr 
opagationInterceptor.java:44) 
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation. 
java:66) 
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityC 
lientInterceptor.java:38) 
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation. 
java:66) 
at org.jboss.aspects.remoting.IsLocalInterceptor.invoke(IsLocalIntercept 
or.java:32) 
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation. 
java:66) 
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteP 
roxy.java:82) 
at $Proxy1.getAllDomains(Unknown Source) 
at ch.own.fdomaintab.client.FDomaintabService.(FDomaintabService.j 
ava:26) 
at ch.own.fdomaintab.client.FDomaintabService.inst(FDomaintabService.jav 
a:45) 
at ch.own.immo.client.LiegenschaftTypPanel.initComponents(LiegenschaftTy 
pPanel.java:43) 
at ch.own.immo.client.LiegenschaftTypPanel.(LiegenschaftTypPanel.j 
ava:33) 
at ch.own.immo.client.LiegenschaftWizard.(LiegenschaftWizard.java: 
38) 
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct 
orAccessorImpl.java:39) 
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC 
onstructorAccessorImpl.java:27) 
at java.lang.reflect.Constructor.newInstance(Constructor.java:494) 
at java.lang.Class.newInstance0(Class.java:350) 
at java.lang.Class.newInstance(Class.java:303) 
at ch.own.fclient.panels.FDesktop$2.run(FDesktop.java:233) 
at ch.own.fclient.thread.foxtrot.AbstractWorkerThread$2.run(AbstractWork 
erThread.java:49) 
at java.security.AccessController.doPrivileged(Native Method) 
at ch.own.fclient.thread.foxtrot.AbstractWorkerThread.runTask(AbstractWo 
rkerThread.java:45) 
at ch.own.fclient.thread.foxtrot.workers.DefaultWorkerThread.run(Default 
WorkerThread.java:153) 
at java.lang.Thread.run(Thread.java:595) 
Caused by: java.net.ConnectException: Connection timed out: connect 
at java.net.PlainSocketImpl.socketConnect(Native Method) 
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) 
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) 
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) 
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:364) 
at java.net.Socket.connect(Socket.java:507) 
at java.net.Socket.connect(Socket.java:457) 
at java.net.Socket.(Socket.java:365) 
at java.net.Socket.(Socket.java:178) 
at org.jboss.remoting.transport.socket.SocketClientInvoker.getConnection 
(SocketClientInvoker.java:450) 
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(Soc 
ketClientInvoker.java:228) 
... 29 more 


My configuration: 
jboss 4.0.2RC1 
ejb3 preview 4
firewall ports forwarded to jboss: 
1098 1099 4444 4445 3528 (all TCP&UDP) 

I did not change any jboss config file 
I start jboss with run.bat -c all -Djava.rmi.server.hostname=<outer-ip-addr> -Djava.rmi.server.useLocalHostanme=false 

The client is behind a firewall too, but all ports are open in lan->wan direction 

Thanks in advance 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877353#3877353

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877353

[Jboss-dev-forums] [Design of JBossXB] - Re: Need advice for AOP/Microcontainer XML integration

[<sco...@jb...>]

There already is multiple namespace support in JBossXB. I use it in 4.0 for a login-config.xml document:


  | <?xml version="1.0" encoding="UTF-8"?>
  | <!-- A login-config.xml example that uses the extended schema and jbossxb
  | to marshall non-trival module-options.
  | -->
  | <policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  |    xmlns="http://www.jboss.org/j2ee/schema/jaas"
  |    targetNamespace="http://www.jboss.org/j2ee/schema/jaas"
  |    >
  | 
  |    <application-policy name="testXMLLoginModule">
  |       <authentication>
  |          <login-module code="org.jboss.security.auth.spi.XMLLoginModule" flag="required">
  |             <module-option name="userInfo">
  |                <lm:users xmlns:lm="http://www.jboss.org/j2ee/schemas/XMLLoginModule">
  |                   <lm:user name="jduke" password="theduke">
  |                      <lm:role name="Role1"/>
  |                      <lm:role name="Role2"/>
  |                      <lm:role name="Echo"/>
  |                      <lm:role name="callerJduke" group="CallerPrincipal" />
  |                   </lm:user>
  |                   <lm:user name="scott" password="echoman">
  |                      <lm:role name="Echo"/>
  |                      <lm:role name="ProjectUser"/>
  |                      <lm:role name="callerScott" group="CallerPrincipal" />
  |                   </lm:user>
  |                   <lm:user name="stark" password="javaman">
  |                      <lm:role name="Java"/>
  |                      <lm:role name="Coder"/>
  |                      <lm:role name="callerStark" group="CallerPrincipal" />
  |                   </lm:user>
  |                   <lm:user name="jdukeman" password="anotherduke">
  |                      <lm:role name="Role2"/>
  |                      <lm:role name="Role3"/>
  |                      <lm:role name="callerJdukeman" group="CallerPrincipal" />
  |                   </lm:user>
  |                   <lm:user name="invoker" password="invoker">
  |                      <lm:role name="HttpInvoker"/>
  |                   </lm:user>
  |                   <lm:user name="admin" password="admin">
  |                      <lm:role name="JBossAdmin"/>
  |                   </lm:user>
  |                </lm:users>
  |             </module-option>
  |             <module-option name="unauthenticatedIdentity">guest</module-option>
  |          </login-module>
  |       </authentication>
  |    </application-policy>
  | 
  | 

This is parsed using the org.jboss.security.auth.login.LoginConfigObjectModelFactory factory.

The issue is getting to a stable xsd driven version. In terms of something is stable and usable now, we may need to simply freeze/fork an ObjectModelFactory based implementation for use.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877349#3877349

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877349

[Jboss-dev-forums] [Design of JBossXB] - Need advice for AOP/Microcontainer XML integration

[<bil...@jb...>]

I'm currently writing a JBossXB implementation for AOP XML and wondering what approach I should take.  Should I use the ObjectModelFactory or the SchemaBinding approach(what MC uses)?  

What I think will end up happening is that we'll mix two schema's together.  AOP will use the bean-deployer XSD to embed bean definitions of Aspect Factories.  The MC will use the AOP XSD to embed AOP constructs into bean metadata.  It looks like this kind of arrangement would require a SchemaBinding model?

Also, any clue when multiple namespace support will be available in JBossXB so I can finish this?

Thanks.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877348#3877348

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877348

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<sco...@jb...>]

I don't see a problem with needing to create holder objects. The main advantage is that they give you a type explicit representation of the stack as opposed to having to know the types and order of the stack. An example I have that has a clean ObjectModelFactory view is the org.jboss.security.auth.login.LoginConfigObjectModelFactory.

Here the javax.security.auth.login.AppConfigurationEntry that is represented in the xml config cannot be constructed incrementally as a java bean because it has no setters. All data must be passed in via the ctor. There is an example of such a document with the associated xsds in jboss-head/testsuite/src/resources/xml/mbeanserver:


  | [starksm@banshee9100 jboss-4.0]$ ls -l jboss-head/testsuite/src/resources/xml/mbeanserver/
  | total 10
  | drwxrwxrwx+ 2 starksm None    0 May  3 18:12 CVS/
  | -rwxrwxrwx  1 starksm None 1879 May  3 18:14 login-config2.xsd*
  | -rwxrwxrwx  1 starksm None 1599 May  3 18:14 mbean-service_1_0.xsd*
  | -rwxrwxrwx  1 starksm None 3370 May  3 18:14 testObjFactory.xml*
  | -rwxrwxrwx  1 starksm None 1040 May  3 18:14 user-roles.xsd*
  | 

I think the general extension to jaxb that we need is the notion of a holder object that is a java bean which can be constructed via standard jaxb rules or customizations + a mapping of that holder into the actual object. The mapping could be specified via simple transform/factory interface. The authentication type in the login-config2.xsd could be customized using something like:


  | <xs:complexType name="authentication">
  |    <xs:annotation>
  |       <xs:appinfo>
  |          <jbossxb:factory
  |             name="org.jboss.security.auth.login.LoginConfigFactory"
  |             holderClass="org.jboss.security.auth.login.AppConfigurationEntryHolder"
  |             />
  |       </xs:appinfo>
  |    </xs:annotation>
  | ...
  | 


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877347#3877347

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877347

[Jboss-dev-forums] [Design of JBoss Portal] - Re: (Problem in the) New version of jboss portal

[sdhaliwal <nu...@jb...>]

try running jboss with jre/jdk 1.5

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877342#3877342

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877342

[Jboss-dev-forums] [Design of JBoss Portal] - Re: (Problem in the) New version of jboss portal

[lnhf <nu...@jb...>]

Hi, 
I put more details.

When I try to connect to the portal page : http://localhost:8080/portal/, I have this error : 


  | 
  | type Exception report
  | 
  | message 
  | 
  | description The server encountered an internal error () that prevented it from fulfilling this request.
  | 
  | exception 
  | 
  | javax.servlet.ServletException: org/apache/jsp/nodesk/index_jsp (Unsupported major.minor version 49.0)
  | 	org.jboss.portal.core.servlet.TransactionFilter.doFilter(TransactionFilter.java:86)
  | 	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
  | 
  | 
  | root cause 
  | 
  | javax.servlet.ServletException: org/apache/jsp/nodesk/index_jsp (Unsupported major.minor version 49.0)
  | 	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:244)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	org.jboss.portal.server.theme.LayoutDispatcher.execute(LayoutDispatcher.java:69)
  | 	sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	java.lang.reflect.Method.invoke(Method.java:324)
  | 	org.jboss.portal.server.servlet.CommandFilter.doFilter(CommandFilter.java:54)
  | 	org.jboss.portal.server.theme.LayoutDispatcher.include(LayoutDispatcher.java:84)
  | 	org.jboss.portal.core.servlet.CoreServlet.render(CoreServlet.java:237)
  | 	org.jboss.portal.server.servlet.AbstractMainServlet.invoke(AbstractMainServlet.java:81)
  | 	org.jboss.portal.server.servlet.AbstractMainServlet.doGet(AbstractMainServlet.java:71)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	org.jboss.portal.core.servlet.TransactionFilter$1.run(TransactionFilter.java:79)
  | 	org.jboss.portal.common.transaction.Transactions.requiresNew(Transactions.java:149)
  | 	org.jboss.portal.core.servlet.TransactionFilter.doFilter(TransactionFilter.java:75)
  | 	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
  | 
  | 
  | root cause 
  | 
  | java.lang.UnsupportedClassVersionError: org/apache/jsp/nodesk/index_jsp (Unsupported major.minor version 49.0)
  | 	java.lang.ClassLoader.defineClass0(Native Method)
  | 	java.lang.ClassLoader.defineClass(ClassLoader.java:537)
  | 	java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
  | 	java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
  | 	java.net.URLClassLoader.access$100(URLClassLoader.java:55)
  | 	java.net.URLClassLoader$1.run(URLClassLoader.java:194)
  | 	java.security.AccessController.doPrivileged(Native Method)
  | 	java.net.URLClassLoader.findClass(URLClassLoader.java:187)
  | 	org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:156)
  | 	org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:69)
  | 	org.apache.jasper.JspCompilationContext.load(JspCompilationContext.java:548)
  | 	org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:136)
  | 	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:307)
  | 	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
  | 	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	org.jboss.portal.server.theme.LayoutDispatcher.execute(LayoutDispatcher.java:69)
  | 	sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  | 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
  | 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  | 	java.lang.reflect.Method.invoke(Method.java:324)
  | 	org.jboss.portal.server.servlet.CommandFilter.doFilter(CommandFilter.java:54)
  | 	org.jboss.portal.server.theme.LayoutDispatcher.include(LayoutDispatcher.java:84)
  | 	org.jboss.portal.core.servlet.CoreServlet.render(CoreServlet.java:237)
  | 	org.jboss.portal.server.servlet.AbstractMainServlet.invoke(AbstractMainServlet.java:81)
  | 	org.jboss.portal.server.servlet.AbstractMainServlet.doGet(AbstractMainServlet.java:71)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
  | 	javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
  | 	org.jboss.portal.core.servlet.TransactionFilter$1.run(TransactionFilter.java:79)
  | 	org.jboss.portal.common.transaction.Transactions.requiresNew(Transactions.java:149)
  | 	org.jboss.portal.core.servlet.TransactionFilter.doFilter(TransactionFilter.java:75)
  | 	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
  | 
  | 
  | note The full stack trace of the root cause is available in the Apache Tomcat/5.0.28 logs.
  | 
  | 
  | 

thanks, 
lnhf

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877341#3877341

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877341

[Jboss-dev-forums] [Design of JBoss's Web Services Implementation] - how to switch off multiref usage in soap message

[dfreer21 <nu...@jb...>]

How can I switch off the multiref usage in soap messages ? I'am using JBoss 3.0.x and axis.
The setting style="rpc" and use="literal" in the service definition of web-service.xml seems to be ignored. 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877340#3877340

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877340

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: Retain ProtectionDomain for instrumented classes

[<sco...@jb...>]

The following issue has been created to validate or reject this:
http://jira.jboss.com/jira/browse/JBAOP-126

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877338#3877338

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877338