Feature pack provisioning
by Marko Strukelj
Currently wildfly-server-provisioning-maven-plugin always generates a full Wildfly distribution. For Keycloak project we have three different cases of provisioning, and it would be great to be able to cover it with a common wildfly provided tool:
1) full server distribution
2) overlay distribution (unzip into existing OOTB Wildfly distribution - your problem if you use unsupported Wildfly version)
3) provision into existing Wildfly server detecting version mismatches, and configuring existing and additional subsystems for Keycloak to run properly.
First one is what’s currently supported, and what we use.
Second one is what we currently hack up by extracting modules directory from (1) - it would support this use case better if wildfly-server-provisioning-maven-plugin could generate 'modules only' for example.
The third one requires a CLI installer tool. I’m not aware that currently there is something for that, and we are loath to develop one from scratch.
Is it realistic to expect 2) and 3) in not so distant future?
- marko
10 years, 3 months
WFLY-4200 WAR MDB cannot obtain superclass on module classpath
by Eduardo Sant´Ana da Silva
I was looking at :WFLY-4200 WAR MDB cannot obtain superclass on module
classpath
This is what I posted about it:
"I believe that the problem is because
AnnotatedEJBComponentDescriptionDeploymentUnitProcessor executes in the
parse phase:
Phase.PARSE,Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS
Since the dependencies will be resolved at Phase.DEPENDENCIES, your build
will not work.
Regarding WFLY, my suggestion is not throw the
EjbLogger.ROOT_LOGGER.mdbDoesNotImplementNorSpecifyMessageListener(beanClass)
only bring up some flag that the required interfaces were not yet resolved,
some attachment could be useful, just to retain the super class name. When
the dependencies were solved, the class will be present on the class index
and the test against the annotation should be performed again. Since that
work will be done twice, to verify the required interfaces, this requires
some experts advice."
Thanks,
--
__________________________
Eduardo Sant'Ana da Silva
10 years, 8 months
SimpleRoleGroup#roles
by Philippe Marschall
Hi
I’m aware this may no technically be the right list to discuss this but
this list is impacted by this and fairly active.
During load testing of our application we found a case we spend 10% of
your CPU time in SimpleRole#equals (see attachment). This is because
SimpleRoleGroup uses an ArrayList to maintain a unique set of roles. As
a result it has to call ArrayList#contains a lot, which is itself O(n).
In fact because that’s done when iterating over all the roles it becomes
O(n^2). In our case our principals can have up to 200 roles. I don’t
know if this is exceptionally many or a common case.
We would like to work on a patch but we need your guidance. There are
several possible solutions and it all comes down to whether we can
change the List in the RoleGroup interface to a Collection. All the
users we searched for in WildFly only used the return value for
iterating over, nobody used the index. In fact they all used it an a
for-each loop so the change would even be source compatible but
unfortunately not binary compatible. If we can change the interface then
we can just change the ArrayList in SimpleRoleGroup to a HashSet and be
done with it. If the order is important the we can either use a TreeSet
or a LinkedHashSet.
If changing the RoleGroup interface is not possible then there are two
other possibilities. The first is only internally using a Set but in
getRoles perform a copy. This would produce more garbage. The second
option would be a having a Set and List (to avoid having to do copies)
in SimpleRoleGroup. This would avoid having to do a copy and the Set can
be used for contains checks. Only removeRole would still be O(n) due to
the scan over ArrayList. The only user we found was
OptionsRoleMappingProvider.
All of these would change the serialized form. If it is important to
support reading old instances that could be added as well.
Cheers
Philippe
10 years, 8 months
Wildfly Redis infinispan cache store
by Simon Paulger
Hi,
My company uses JBoss AS 7 (before Wildfly I know). We also use Redis cache
store for PHP stacks and I'd like to be able to do the same for Wildfly
(I'm considering upgrade paths).
I see there is an old JIRA enhancement issue raised here:
https://issues.jboss.org/browse/ISPN-3465
I was wondering what the appetite for creating a Redis cache store is. If
this were something I were to develop in both inifinispan and wildfly,
would it be well received by the JBoss community?
Regards,
Simon
10 years, 9 months
Metrics & runtime attribute registration
by Tomaž Cerar
Hey guys,
We had interesting discussion with Brian on
https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986
about how we register runtime/metric attribute on resources.
There are many cases where subsystems only register attributes / resources
only when server is booting into normal mode.
but if it server is booted only to "admin mode" all that runtime/metrics
attributes are not registered and as such not seen in the model.
Registering runtime attributes only in normal mode can cause that results
of :read-resource-description/read-resource
wouldn't return attributes that are on resources if server is started in
admin mode or even CLI standalone.
Our metadata already provides information if attributes is
runtime/metric/configuration.
This can cause problems for tooling that relies on output of those two
operations.
Looking at current state of the code, we do use both ways of registering
attributes either conditionally or always.
This probably originates from times where there was no good api/way to mark
attribute/resource as runtime.
I am personally am in favor of always registering runtime attributes as
this makes sure that user isn't surprised by some extra/missing
attributes based on fact how it is starting the server.
What do you guys think? Should we always register it or have it
conditionally?
--
tomaz
10 years, 11 months
Using a custom module to preview "next-gen" Hibernate versions on WildFly 9
by Sanne Grinovero
Hi all,
I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1
to use a preview of Hibernate ORM version 5.
It seems the JPA deployer isn't allowing me to run such experiments:
# First experiment - providerModule set to custom module
In my first attempt, I create a custom set of jboss modules which
include the snapshot builds of ORM 5, add them to my standalone WF9
instance and set the persistence.xml property:
jboss.as.jpa.providerModule = my-custom-module-name
and then get:
Caused by: java.util.ServiceConfigurationError:
org.hibernate.integrator.spi.Integrator: Provider
org.hibernate.envers.boot.internal.EnversIntegrator not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51]
at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51]
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
[rt.jar:1.7.0_51]
at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51]
at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341)
at org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57)
at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188)
at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45)
at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57)
at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38)
at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173)
at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243)
at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60)
at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118)
... 7 more
Clearly it looks like I'm being served classes from the bundled
Hibernate 4.x implementation - on top of those from the module I'm
requesting. This isn't what the deployer should be doing, right?
# Second experiment - use the "application provided"
In this case I hope to hint the JPA deployer to not add the default
implementor but look for a JPA implementation within my deployment,
but still package my custom Hibernate build as a module.
- use the same custom module containing Hibernate ORM 5 (a preview snapshot)
- Add a "Dependency:" section to the manifest to import (and export)
my custom module
- set the "jboss.as.jpa.providerModule" property to value "application"
This gets me:
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException:
WFLYJPA0027: Persistence provider module load error application (class
org.hibernate.jpa.HibernatePersistenceProvider)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131)
at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
[wildfly-server-1.0.0.CR1.jar:1.0.0.CR1]
... 5 more
Caused by: org.jboss.modules.ModuleNotFoundException: application:main
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236)
[jboss-modules.jar:1.4.3.Final]
at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65)
at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978)
... 10 more
Remarks:
- it's attempting to load the "application:main" module?! that's not
what I'd expect from reading [1]
- the provider should be available to the deployment classpath, so
I'm not sure why it's not finding the Provider? (I'm even exporting
it, although I'm not sure if that was required).
Any suggestions to get this running please?
Also I wonder if some of these should warrant opening a JIRA, but I'm
not sure how far I misunderstood the intentions of these JPA deployer
properties.
Thanks,
Sanne
[1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere...
10 years, 12 months
sun.misc.Unsafe usage, etc.
by Scott Stark
In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley.
I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread.
Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why.
The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement.
11 years
Capabilities enabled by attributes
by Brian Stansberry
I would like to propose a requirement that if a particular type of
resource CAN provide a capability, then it MUST provide that capability
if it is created. There will be no such thing as a resource providing or
not providing a capability based on the value of one of its attributes.
My question to subsystem developers is whether they have a situation in
their configuration model where this will be a problem?
For any case where there is such an attribute, the requirement would
mean that a child resource would need to be created instead, and that
child resource would provide the capability. There are tricks we can use
to preserve the existing attribute to provide management API compatibility.
The only case I'm aware of where this is a factor is the 'jts' attribute
in the subsystem=transactions resource.
The reason for this requirement is we want tooling to be able to inspect
the types of resources that are available for use, see what capabilities
they provide and what requirements they have, and work out what
resources need to be present in a configuration in order to have a
consistent set of capabilities. That task is significantly more complex
if the presence of a capability is determined by some arbitrary
attribute value. David Lloyd described allowing attributes to control
this as being "like creating an RDBMS where you have foreign keys that
only exist if some function evaluates in a certain way."
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
11 years
Handling Unsafe as an optional dependency
by Sanne Grinovero
Hi all,
while checking dependencies of some Hibernate projects for usage of
sun.misc.Unsafe I've found that Apache Avro uses it, but it's
"optional".
When allowing it to use Unsafe it will be more efficient. Avro
automatically attempts to use it, and in case of failure hide the
exception and store this information in a static field, to
consistently resort to Reflection API as a fallback.
For this to work at all I guess I should be adding the module
dependency to "sun.jdk".
Shall I add this dependency to benefit from it as long as it's an
option, or just have it forget about Unsafe already?
We could also set the property avro.disable.unsafe=true to avoid the
usage attempt.
Thanks,
Sanne
11 years
