osgi failures in master
by Alexey Loubyansky
Current master is failing to build with the following permanent errors:
Failed tests:
testBundleContextInjection(org.jboss.as.test.smoke.osgi.SimpleBundleContextTestCase):
BundleContext injected
Tests in error:
testClientDeploymentAsArchive(org.jboss.as.test.smoke.osgi.SimpleArquillianDeployerTestCase)
Tests run: 124, Failures: 1, Errors: 1, Skipped: 2
14 years
cache java.lang.Proxy?
by Bill Burke
is it pretty bad to call:
java.lang.Proxy.newInstance(...) often? Does it create a new class each
and every time? Can't believe I forgot about this one...I'm a f'n idiot.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
14 years
read-only configs
by Kabir Khan
Brian asked me to get some feedback on this.
The following commit https://github.com/jbossas/jboss-as/commit/435c862b9514bfcf0a036bb2b916ac... implements the following new command line switches for https://issues.jboss.org/browse/AS7-4764:
Standalone:
--read-only-server-config
Domain:
--read-only-host-config
--read-only-domain-config
These work much the same as their 'standard' counterparts, e.g. --server-config etc. apart from:
*They allow an absolute path in addition to the relative path supported by --server-config etc.
*The file passed in will never be overwritten, however the other history files do get persisted as usual so you can make changes to the config and copy the standalone.last.xml file to use that the next time you want to boot from a read-only config
The reload operations now take the following parameters:
-- use-current-domain-config (domain controller only)
-- use-current-host-config (domain and host controllers)
-- use-current-server-config
The default value for all of these is false, and these parameters are only taken into account if --read-only-xxx-config was used. If false, the reloaded process is started with the initial, unchanged config that was passed in to --initial-xxx-config. If true, it uses the current model for the reloaded process (using the corresponding .last.xml file). The idea for the 'true' path being that you might want to reboot into admin-only mode to make some changes which should take effect once the process is put back into normal mode.
14 years
Setting JPA ClassTranformer and how can a service be started before any DUPs start scanning deployment classes?
by Scott Marlow
I need to start the JPA persistence unit service
(javax.persistence.EntityManagerFactory), before the deployments classes
have been read. Currently, POST_MODULE_INJECTION_ANNOTATION and other
DUPs can read application classes before the persistence unit service is
started.
I tried changing the JPA related DUPs to start as early as possible but
that doesn't help since the JPA persistence unit service doesn't
actually start until the INSTALL phase (well after the
POST_MODULE_INJECTION_ANNOTATION has already read application classes).
If we were to create the javax.persistence.EntityManagerFactory during
an early PHASE (probably in a "first time access" phase after the module
is defined), we would also need the datasource to be available early (to
handle certain cases that require it (e.g. creating database tables or
checking JDBC DatabaseMetaData.)
Is there a way to get early (equivalent to PHASE.POST_MODULE time)
access to a datasource?
https://github.com/scottmarlow/jboss-as/tree/AS7-4996_class_transformer_p...
contains some hacks that I started and the current JPA datasource access
code is at
https://github.com/scottmarlow/jboss-as/blob/AS7-4996_class_transformer_p...
AS7-4996 is the jira for this change and contains an IRC transcript from
a conversation last fall about getting JPA class transformers to work.
The changes that we made last fall, worked for the simple test case but
not all applications.
Scott
14 years
automated response
by richard
Hei,
jeg har sommerferie og er tilbake i jobb mandag 30. juli.
Generelle henvendelser kan sendes til post(a)hmskontoret.no. Du finner ytterligere informasjon om hvordan du kontakter HMS Kontoret i ferien her: www.hmskontoret.no.
God sommer!
14 years
Re: [jboss-as7-dev] Configuration of expression and system-properties (ejb3 subsystem)
by Jaikiran Pai
There are 2 issues here:
1) The expression value validation isn't allowing empty values. So
internally it results in:
org.jboss.as.controller.OperationFailedException [ "JBAS014704: '' is an
invalid value for parameter default-distinct-name. Values must have a
minimum length of 1 characters" ]
2) This real exception isn't reported during server startup and I don't
know the reason why.
Please create separate JIRAs for this. I believe a fix for #1 would
involve overriding the String type attribute validator with an custom
validator which allows empty strings (since for default-distinct-name a
empty string is a valid value).
-Jaikiran
On Thursday 05 July 2012 11:46 AM, Wolf-Dieter Fink wrote:
> No,
> If I configure the EJB subsystem with a correct distinct-default
> everything works (see initial mail, "If I set property to XX...")
>
> My intention was to set the default-distinct name with an expression
> and use the default "",
> so it it possible to use the same profile for different server-groups
> and configure the distinct name with a property.
>
> This works as long as I have a default different from "" or overwrite
> with a property different from "".
> But if I don't want the distinct name and set "", no difference
> whether default or property, a execution with "no distinct name" will
> not work.
>
> I've looked into the source and play around with expressions and
> properties and it looks like that ${XY:} will set "" as I want and a
> property with value="" works either.
> So I don't understand at the moment why this don't work for distinct
> name !?
>
> - Wolf
>
> On 07/05/2012 07:34 AM, Jaikiran Pai wrote:
>> Sorry, I don't completely understand the issue. Are you saying that
>> whatever distinct name you specify in the EJB3 subsystem is not being
>> used by the deployed EJBs?
>>
>> -Jaikiran
>> On Wednesday 04 July 2012 07:59 PM, Wolf-Dieter Fink wrote:
>>> I want to set
>>> <default-distinct-name value="${server.distinct.name:}"/> <!--
>>> default to "" empty -->
>>> for the ejb3 subsystem.
>>>
>>> If I look into the sources for ModelNode this should work, also do a
>>> simple mail-class test ;)
>>>
>>> Also if I set later in the server-group
>>> <system-properties><property name="server.distinct.name" value=""/>
>>>
>>> The result is the same:
>>> EJBCLIENT000025: No EJB receiver available for handling
>>> [appName:apptwo,
>>> moduleName:ejb, distinctName:]
>>>
>>> If I set property to "XX" or default-distinct-name to
>>> "${server.distinct.name:XX}" (and don't set property)
>>> everything works fine.
>>>
>>> I suppose that there is something wrong with the setting for the
>>> receiver, but I don't see anything in TRACE level that give me an idea.
>>>
>>> Does anybody can help?
>>>
>>> - Wolf
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
14 years
What are the *-next branches in github?
by Brian Stansberry
The $subject question comes up from time to time, with developers
wondering if they should do anything with those branches.
Simple answer is, no, you should completely ignore them.
They exist solely as a convenience in testing pull requests prior to
merging them. Often we want to test multiple pull requests in one lot
(mostly to save time.) To do that we can merge the PRs onto the relevant
*-next branch, force push the result out to github, and the lightning
test server will automatically detect the change to that branch and run
a full test.
DO NOT base your own work on these *-next branches as we make no promise
about maintaining a linear flow of commits. If some pull request fails
testing, the next time we use the *-next branches we'll simply make the
offending commits disappear.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years
Configuration of expression and system-properties (ejb3 subsystem)
by Wolf-Dieter Fink
I want to set
<default-distinct-name value="${server.distinct.name:}"/> <!--
default to "" empty -->
for the ejb3 subsystem.
If I look into the sources for ModelNode this should work, also do a
simple mail-class test ;)
Also if I set later in the server-group
<system-properties><property name="server.distinct.name" value=""/>
The result is the same:
EJBCLIENT000025: No EJB receiver available for handling [appName:apptwo,
moduleName:ejb, distinctName:]
If I set property to "XX" or default-distinct-name to
"${server.distinct.name:XX}" (and don't set property)
everything works fine.
I suppose that there is something wrong with the setting for the
receiver, but I don't see anything in TRACE level that give me an idea.
Does anybody can help?
- Wolf
14 years
Does work @WebService with @Interceptor on AS 7.1.1.Final ?
by Marcelo Zabalet
I'm trying to use interceptors in conjuntion with webservices on AS
7.1.1.Final as the example shows below. The interceptor intercepts well
until it is combined with @WebService. Is this supposed to work? Am I
missing something?
----Binding---
@InterceptorBinding
@Target({METHOD, TYPE})
@Retention(RUNTIME)
@Inherited
public @interface SomeInterceptorBinding { }
---Interceptor---
@SomeInterceptorBinding
@Interceptor
public class SomeInterceptor {
@AroundInvoke
public Object handle(InvocationContext ctx) throws Exception {
return ctx.proceed();
}
}
---WebService---
@SomeInterceptorBinding
@WebService
public class AWebService {
@WebMethod
public void someMethod() {
...
}
}
---beans.xml---
<?xml version="1.0" encoding="UTF-8"?>
<beans ...>
<interceptors>
<class>com.xyz.SomeInterceptor</class>
</interceptors>
</beans>
14 years
